World: r3wp

Really? Works for me, or at least it works for the ODBC extension.

yes, will try it. I used a different code, so this one should work, 
I think

That reminds me, I should see if EXTEND is implemented in the most 
efficient way...

I guess it is as efficient as it can be and still support objects, 
maps, blocks and parens. There are more efficient methods if you 
only need to support objects, maps, or blocks and parens.
Objects:  set bind/new :word obj :val
Maps:  obj/word: :val
Blocks and parens:  reduce/into tail obj [to-set-word word :val]

Sprry, that last one should be:  reduce/into [to-set-word word :val] 
tail obj

BTW, I am a bit annoyed by needing to bind a user-supplied block, 
and having to always recreate a function because of that. I would 
prefer to just BIND, as in R2, which is technically possible, just 
unsupported.

Wait, in what circumctances? Binding to what?

(bad typing day)

like this: f: make function! [a b] [parse blk]

the BLK is user-supplied, and I have to always recreate the function 
instead of being able to just bind it

(it is not a correct code,but, I guess, that you have the idea)

Do you mean so that the 'a and 'b are bound in the block? You can 
bind to a function context by using one of its argument words as 
a referent. Or do you mean as in cases like the KEEP function in 
COLLECT ?

You can bind to a function context by using one of its argument words 
as a referent.

 - well, actually, I can do that only when the function is actually 
 running

(which is what annoys me)

What I wanted to do was to be able to do it even when the function 
is not running.

Yup. But 'a and 'b are only defined when the function is running. 
I can see how you'd find that annoying if you're used to R2's behavior, 
though I find R3 to make more sense.

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?