World: r3wp

I just have my preferences, but don't know what the others prefer

It should put  a string in the position of one char :D
Its an programmer-error. Do we  need a runtime-check?

I guess, that it is simpler to silently ignore the refinement from 
the interpreter designer POV

Ok, I guess, I'm completely misunderstanding the problem. Volker, 
what do you mean by putting a string in the position of one char?

that is what insert/only a-string "ab" requests for, althought it 
cannot be done

ah, so it would replace the character at the position and then insert 
the string from there?

Henrik, look at how  it works with  blocks ;)

...and how it is described in its doc string

I know how it works with blocks, but I can't see how this would work 
with strings? You can't make strings inside other strings, unless 
you mean {"string"} or "{string}". And it's AFAIK not possible to 
control when to use one or the other?

Thats why i added the ":D" ;) Yes, its impossible. But theprogrammer 
said "do so"

Maybe the wrong emoticon?

Volker, I think I understood that, but I just fail to see the current 
behaviour with /only on strings as a problem, so I guess I have to 
vote for the current behaviour. :-)

Strictly iusing  it for strings is a bug. But not a problem.

And ignoring silly refinements  is done everywhere in natives.

ladislav, many funcs are intended to support all of a given set of 
types (numbers, series, etc).


we must not turn rebol into a "strict" language... the "looseness" 
in the case where some effects are irrelevent are not really bugs.

as opposed to calculus which has a definite and single true output 
value.  REBOL should give an error in those cases, cause then, the 
process of calculus is an error (like out of bounds, etc)

{the "looseness" in the case where some effects are irrelevent are 
not really bugs} - yes, I understand this POV and respect it. that 
is why I am not enforcing my POV in this case and prefer to ask you

I know its hard to put the line where loseness becomes a bug (like 
the few cases this kind of effect has been brought up before)

my idea was more in the sense: {insert/only "" "ab"} is a most likely 
a programmer error. therefore if the interpreter causes the error, 
it helps the programmer find the bug in his code. If the interpreter 
silently ignores the problem, then the programmer may be unable to 
find out there is probably something wrong

(so I saw it as a kind of debugging help)

but that depends where the "" comes from... your human sense sees 
this as a bug, but an algorythm merging a set of series of abstract 
types would not...  ;-)

well, if that algorithm really *needs* the string to occupy just 
one "place" in another string, then it may contain a bug, which may 
be revealed by testing, but not by evaluating this suspicious code

(Ladislav is the one thinking this to be suspicious ;-)  I have a 
merge func which could not care less, all it wants is to make sure 
that equal things get inserted equaly, string into string, blocks 
into blocks...  so in that sense, the above is not suspicious at 
all.  but if only reacted differently for string, then I'd have to 
add an ugly escape route for that case ;-)

But if  /ONLY reacted ...

but if you really want to do what you said, then you probably don't 
use the /only refinement, do you?

(just curious)

back later... off to lunch !

(well that was diner actually... but anyways ;-)

yes, cause I don't want merge to insert the content of the block 
which is being merged, I want it to merge the block itself... (if 
that is what is submitted) ex:


[ 1 2 3 ] [["one"] ["two"] ["three"]]  == [ 1 ["one"] 2 ["two"]  
3 ["three"]]

I see both possible behaviours balanced close to equally, except 
that keeping the "loose" behaviour is already here and has the benefit 
of not needing any changes.

this behaviour of tags differs from string behaviour:

    a: <0> 
    b: make tag! 0 
    insert b a 
    a == b ; == false

do you like it?

hum good catch. internally tags can hold other types, but I think 
it should be converted to string... for consistencie's sake.

>> a
== <0>
>> b
== <<0>>

>> insert b 1.000000
== <<0>>
>> b
== <1.0<0>>

Ok for me. datatype is translated to string, a tagto"<something>". 
and then inserted.

An issue raised by Joe in Core group 26-Nov-2006:
	launch {my-script.r param}

Joe wanted param to be parsed out and appear in system/script/args, 
however, it looks like instead the whole string is converted to a 
file and rebol tries to DO it.

Hmm.. there seem to be a few other LAUNCH issues in the Rambo database. 
I guess it's not as important as it used to be, now we have CALL.

Did he try the /as-is refinement to launch? That should solve the 
problem.

i just tried launch/as-is %t.r test   -- where t.r prints the args 
and it doesn't work !!

Did you try:
    launch/as-is {%t.r test}

After trying it myself, I get "Script Error: Feature not available 
in this REBOL". Is /as-is SD_-specific?

hmm, /as-is could be a /Link thing maybe.

I've never seen documentation for LAUNCH.

http://www.rebol.com/docs/words/wlaunch.html

Yes I have.

Nope, that page doesn't explain that error message, and the /as-is 
refinement doesn't say "reserved" like some of the others. So, launch 
is still undocumented.

Hmm, so is it worth posting a ticket (given that CALL is for free 
?) I suppose we still need LAUNCH for some of those options...

I guess I should post a ticket asking for clarification of LAUNCH 
options, especially argument handling.

Well, the advantage to launch is that it knows where to find the 
REBOL executable, so you don't need to hard-code that in your scripts. 
That is enough of an advantage to me over call to make this worth 
complaining about.

Doesn't system/options/boot let you find the rebol executable?

It does, but I guess it's still handy not to have to put that detail 
in.