World: r3wp

Isn't this just a special case of printf ..  so why not implement 
printf instead? - it does not have anything in common with printf, 
except for the superficial similarity

I agree with Robert .. why would you want to perform an extra reduce 
?
 - exactly because the REDUCE is performed at a different time

The substitution has to be performed always at the translation time, 
while REDUCE just when you need to create the substitution

Not to mention, that it is safer to have substitutions as data files, 
than to allow code

err. susbstitutions as data values is what I mean

there is no argument string?

 - the %0 is the substitution string (the first one), just as a curiosity, 
 it may not be needed

(you do not have to use %0 if you don't need to)

KISS in this instance means default reduce, and use a refinement 
if you don't want this behaviour

 - well, that is very much like saying, that e.g. for the TEXT widget 
 in the Laout dialect you prefer to use a code block, which should 
 (re)generate the string to be displayed every time it is SHOWn. While 
 possible, it is not KISS

I have to repeat, that the goal here is to represent text, that needs 
to be translated, and we found out, that "generated strings" cannot 
be represented as strings to be translatable.

As an example, check this:


["You do not have sufficient rights to delete the '%1" file." "database.r"]


This is easy to translate, since only the substitution strings needs 
a translation, while the argument does not. If you know how to translate 
the substitution string, the argument string does not matter at all.

So, the TRANSLATE function just replaces the substitution string 
by a different language version, leaving the argument as-is, e.g.:


["Sie verfuegen nicht die ausreichende Zugriffsrechte fuer das File 
'%1' zu loeschen." "database.r"]

(forgive my attempt, I bet it is not a correct German)

Originally, the block might have been generated by something like:


my-substitution: reduce ["You do not have sufficient rights to delete 
the '%1" file." to string! file]

But that does not matter, until it need the translation, which happens 
during run-time when the user chooses a different display language 
for widgets.

You need to realize, that the TRANSLATE function will have to be 
applied as often as the user requires, and that the substitution 
happens only as the last step, just before the string is SHOWn.

I like the SUBSTITUTE proposal, as-is. I sort of like that only strings 
are supported, because there's no default translation from datatypes 
to strings - we don't have anything like OOP asstring methods. Different 
methods of string formatting are appropriate in different circumstances. 
The moment that you pick one conversion method as the default, people 
will ask for options for other conversion methods to be supported, 
gradually making SUBSTITUTE so complex that it becomes slow, as it 
goes through the process at runtime of determining what the programmer 
wants it to do. If you decide to manage that complexity with composition 
instead, the decision-making process is done at development time, 
not runtime, and you can have unbounded complexity with no overhead.

I also like that it doesn't reduce by default, for security reasons. 
If it reduces by default then its argument needs to be treated like 
code, with all the security implications and special handling, rather 
than like data.

Actually, I think, that the "only strings" approach is best for your 
favourite security theme. The most secure approach for the SHOW code 
is not to execute everything "thrown" at it, but, instead, insist 
on the text to be strings, or very much like strings.

ah, sorry, you just mentioned that as well...

Yup :)

What about my R3 error related question, above? Do you know how to?

(or, is it even possible?)

Yeah. Here's how it's done in the ODBC extension:

unprotect system/catalog/errors
extend system/catalog/errors 'ODBC make object! [
    code: system/catalog/errors/access/code + 50
    type: "ODBC error"
    error: [arg1]
]
protect system/catalog/errors


Of course that assumes that PROTECT-SYSTEM was run, which is not 
the case in current R3 builds. You might be able to extend it without 
unprotecting it.

You can extend any of the existing error class objects, or add your 
own.

Well, I remember that I tried, but did not succeed

(did not even get any error, as far as I remember)

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.