World: r3wp

I'm OK with not having a /with, but I'm sold on having an APPLY-style 
/only option.

That sounds tricky ... if you're reading two input streams .. to 
substitute ... you need to know when a %n is intended not to be replaced

What if "%%" was always interpreted as "%"? Then the way that you 
signify %n as not being a replacement is to write it as %%n.

This is what happens in MS dos

shell

Yup.

The main advantage to APPLY reducing its argument is that it doesn't 
necessarily have to allocate an intermediate block. This might be 
tricky though if you want to implement SUBSTITUTE as a command. Can 
you DO/next in a command?

And I guess my next question is, do you really need "n" ?  Why not 
prepare the arguments in order and just use them as in SQL dialect?

The current proposal allows me to write:

["%%1" "%1"]


to obtain the "%%1" string. With your proposal I would need to write 
it as

["%%%%1"]

, so, I do not think I gain any advantage.

Yes, it's more flexible

Why not prepare the arguments in order
 - that is not suitable for translation

Graham, the %n method supports switching template strings between 
languages with different sentence ordering.

(thranslation should be able to adjust the order according to the 
language requirements)

Sounds then the cases are quite different and should have different 
functions

Ladislav, the advantage would be that you don't have to allocate 
a substitution argument for that % escaping, especially if some of 
your template strings might need a %1 in them and others might not.

I am thinking of the code-generation posibilities, where instead 
of Russian you are generating ASP or something.

Or RSP if you like.

the advantage would be that you don't have to allocate a substitution 
argument for that % escaping

 - yes, understood, I was originally for that alternative, but, Cyphre 
 convinced me, that for human writers, actualy the substitution is 
 more readable

Ah, sticking to the natural language translation usage model, even 
though you are allocating a more generally applicable name to the 
function.

substitute ( "%1" "translate" )

Well, yes, the name may be conflicting, sure

But, "translate" is not a good name, since the translation is what 
is being performed as well, besides the substitution

Well, given my current business needs I would use SUBSTITUTE more 
for code generation than for translation, but it would be useful 
for generating English as well.

Sure, I expect there *are* other uses. As for the %% case, I am still 
not sure, it might be intersting to know what would Robert prefer.

In general, I do not expect the #"%" character to be contained in 
the texts being followed by a digit. At least not frequently enough 
to normally matter.

But, sure, in strings that are not meant to communicate something 
to humans, the frequency of "%" may be higher.

Hi, I found the following text part in the Replacement article: "ENLINE 
any-block!,". Forgive my ignorance, please. What exactly is ENLINE 
meant to do in case its SERIES argument is a block?

I am especially curious, if it really qualifies as non-modifying 
function in that case.

aha, nevermind, I just used some tests to find out what it does

I really wish the ENLINE/with ticket would be implemented. I could 
use this function daily.

In R3 we have got the

    system/state/last-error


, which is great for convenience. Is there a corresponding variable 
in R2?

If it does not, it would be great to have this feature backported...

Today's Moment of REBOL Zen:

>> s: "A"
== "A"
>> lowercase s
== "a"
>> s
== "a"
>> c: #"A"
== #"A"
>> lowercase c
== #"a"
>> c
== #"A"

:-)

I hope you know why?

Yes, I do.

And I'm thinking, if it would be an idea to let functions like that 
take word arguments handling them like call-by-reference. Then it 
would be possible to change chars too.

You mean also
>> i: 5
== 5
>> multiply i 4
== 20
>> i
== 20 (?)

That would be
	multiply 'i 4

then. Maybe not too useful in that case. Or though, the ++ operation 
(function) could use this too. Which then reminds me, that NEXT should 
be used for what ++ does. :)

There was a discusson in Carl's blog about this long time ago.

move-next 'series
 looks ok but multiply looks weird.
but ++ already works for series as you say.

++ : "Increment an integer or series index."

Has anyone said the following before?

call-by-word

I didn't hear that before.

I suggest: skip ++ and use NEXT with call-by-word to do the same. 
Less functions to remember that way.

using NEXT with call-by-word (I like the name :) ) looks ok to me, 
but I remember that, "guru"s may say "it leads performance overhead 
for next, as it is a native and used a lot. it should check the argument 
and get-value if it is a word."

I'm not too sure about additional overhead, depending on how NEXT 
is implemented today. My guess is, NEXT already test for different 
datatypes, as it can handle blocks, strings, etc. To in that SWITCH 
(guessiong) in the source code, it just have to include the word! 
type also and handle that, and default: give the error.

To -> So

and *guessing* :) Getting late = more typing errors.

Then we could have things like:

>> a: 41
>> next a
== 42
>> a
== 41
>> next 'a
== 42
>> a
== 42

NEXT already test for different datatypes, as it can handle blocks, 
strings, etc.

But it's all series type. So no type checking I think. It supports 
only series and port values.