World: r3wp

You are missing the point, I guess. The MAKE function binds the function 
body when the function is not running. The restriction to BIND is 
just artificial, and circumventable. I do not use the circumvention 
not because it is not possible, but because it looks "ugly".

(I do know at least two ways how to do it, to be exact, but both 
look uglier than what I normally like)

I wouldn't mind BIND accepting function! for its context argument, 
as long you still have the error on referring to any of the bound 
words when the function isn't running. But not closure! though, since 
that context is different every time.

So, I rather always regenerate the function using MAKE, which, of 
course, does the binding for me

Your substitute function is similar to the dialect used for sql .. 
except it doesn't reduce, and it uses % instead of ?

I don't mind the SQL dialect reducing, because that block is always 
code anyways, so you already have to treat it carefully. However, 
the method for treating code carefully is different than the methods 
for treating REBOL code carefully, so it doubles the analysis and 
screening. It's best to just resign yourself to not accepting SQL 
code blocks from unknown sources.

And is there a %n ... or is it just %0 and %1 ?

Anyway, sounds like a duplicate functionality .. that could wrapped 
into one function with a refinement

Maybe SUBSTITUTE should have an /only option that works like APPLY/only: 
reduce by default, don't reduce with /only.

At present everyone is rolling their own substitute function for 
writing sql in R3 .. so it would be useful to have an official function

Not forgetting that the R2 sql substitute functionaiity is bugged

That SUBSTITUTE function wouldn't work well for SQL, since most SQL 
dialects use % as a wildcard character in like expressions.

Aha, this was not meant for that specific purpose, being optimized 
for the translation. But, nevertheless, do you think that the #"?" 
character is better than the % character in general?

%0 and %1 - no, %123456 can be used as well

Certainly not for anything other than SQL. Regular language uses 
? for regular punctuation. Does SUBSTITUTE need an escape character 
option?

I don't want to make it too complex, but that seems like a low-overhead 
option.

Cyphre was against it, and, in fact, it is not needed, since you 
can substitute so, you can generate any string you like this way.

for example, the "%1%2" string can be generated as follows:

["%1" "%1%2"]

Well, you can't use % in SQL and can't use ? in English (and some 
other european languages). If we want to code to be more flexible, 
an escape char option would have low overhead for a lot of benefit.

substitute/with

That would be in keeping with how /with is used in other functions.

I suggested the #"%" character as an escape, but, Cyphre is right, 
that it is, in fact, not needed.

For example, if the #"%" were handled as an escape character, you 
could write

["%%"]


to obtain the "%" string, but the current version allows you to write 
just 

["%"]

So, how do you prevent %1 from being substituted?

I do not need to, if I want to obtain %1 somewhere, I can write:

["this is a string containing '%1'" "%1"]

, and I get it (although substituted)

Yup, it's only needed if you want SUBSTITUTE to be used for more 
than just translated strings. And something like SUBSTITUTE using 
? is only needed for SQL dialects that we implement ourselves, not 
for server access where they do their own parsing of prepared statements.

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.