World: r3wp

I suggested my friend to use: call "rebol.exe -si my-script.r"

better option I think as launch is really problematic.

LAUNCH, RUN, and CALL make things confusing. I almost always use 
CALL now.

Composing a lit-path:

>> f: [b d e f]
== [b d e f]
>> i: 2
== 2

It would be nice that instead of this:

>> compose 'f/(i)
== f/(i)

you would get:

== f/2

Doesn't work in R3 either.

I think that it should throw error, because 'compose should accept 
only block! value.

lit-path is a series, so I think the argument is sound for the latter 
result.

It gets rid of a workaround, where I must store a path, where some 
values in the path can't be determined until storage, the moment 
where COMPOSE needs to act. The workaround is to create the path 
as a block, and then TO-PATH it on use.

>> f: [b d e f]
== [b d e f]

>> i: 2
== 2

>> my-path: rejoin [to path! [] 'f i]
== f/2

or, in R2:

    my-path: rejoin [#[path! []] 'f i]

or
>> append to-path 'f i

A fast way is:
>> to path! reduce ['f i]
== f/2

(Maybe the fastest?)

But yes, Henrik, COMPOSE should maybe work on path too, as it is 
a series. And maybe also on parens (also a series), where COMPOSE 
should work on parens inside.

REBOL handles parens in paths today. I can see the usefulness of 
having that evaluation return a composed path.

>> equal? make object! [] make object! []
== false

is this intentional?

It may be because they are considered to have distinct 'self's

    a: make object! []
    b: make object! []
    equal? a b
    == false
    equal? (first  a) (first b)
    == true
    equal? (second  a) (second b)
    == false
    equal? (third  a) (third b)
    == true
    a/self = b/self
    == false

and it's more useful than the other way I think. Once I wrote a function 
to test if two object is similar. It looks a bit silly but works 
for me. Can be extended to test values also:

similar?: func [
    {Returns true if both object has same words in same types.}
    o [object!] p [object!] /local test
][

    test: [if not equal? type? get in o word type? get in p word [return 
    false]]
    foreach word sort first o test
    foreach word sort first p test
    true
]

>> similar? make object! [] make object! []
== true

There's some (fixable) bugs in R3 related to equality of objects, 
and some different (unfixable) bugs in R2. In R3 at least:
>> equal? make object! [] make object! []
== true

R2's behavior in this may not be intentional, but it's not fixable 
because of backwards compatibility :(

ok, interesting, thanks.

Today's Long Moment of REBOL Zen:


When making an object, code in the block argument is executed. I 
found, BREAK stops further execution:

>> o: context [a: 1 break b:2]
>> ? o
O is an object of value: 
   a               integer!  1


So the B assignment isn't carried out. Ok, what about a RETURN in 
object creation then? I'll use MAKE OBJECT! instead of CONTEXT, so 
the RETURN is not handled by CONTEXT, which is a function:

>> o: make object! [a: 1 return 0 b:2]
>> ? o
O is an object of value: 
   a               integer!  1


It seems like, making objects can handle returns ... in R2 at least. 
This has changed in R3, where the result is:

>> o: make object! [a: 1 return 0 b: 2]
** Throw error: return or exit not in function


This seems reasonable. What if I use CONTEXT and use RETURN in the 
object creation? In R2 CONTEXT doesn't have a THROW function attribute, 
so my guess is, RETURN will return from CONTEXT, and the rest of 
the object isn't made, and this is what happens:


>> o: context [print "before return" return 0 print "after return"]
before return


Ok, I now want to fix CONTEXT by putting the THROW attribute in, 
and then test it by making an object using CONTEXT, but this time 
inside a function:

>> context: func [[throw] blk] [make object! blk]

>> f: does [context [print "before return" return 0 print "after 
return"] print "still in f"]


When running F, I would expect to just see the words "before return", 
but

>> f
before return
still in f


I see, that THROW doesn't work as intended, when making objects. 
This is the same in R3, where CONTEXT also doesn't have THROW, and 
when trying to fix that by changing CONTEXT, it's still the same 
behaviour as in R2.

There is not yet any equivalent to R2's [throw] attribute in R3, 
and there have been many tickets and much discussion related to this 
issue, none of which have yet led to any changes, though that may 
change.

As for your attempt to fix R2's CONTEXT using the [throw] attribute, 
you do manage to fix CONTEXT, but there's no fixing the MAKE object! 
it calls catching the RETURN when it shouldn't. So only one of the 
bugs is fixed, not the other. Guess that's why CONTEXT didn't have 
a [throw] attribute already.

MAP-EACH under R3:
>> map-each v [] [v]
== []

MAP-EACH under R2:

>> map-each v [] [v]
** Throw Error: Return or exit not in function
** Where: map-each

OK, already ramboed in #4394.

is there a fix for this?

Certainly there is. In R2 it is a mezzanine, which can be corrected.

The easiest way would be to remove the RETURN in the source

e.g. by using EITHER

ok, Ladislav, are we sure that it will not affect any sources in 
NLPP?

Why should it, if done right?

the incorrect behavior won't necessarily cause a crash, but of course, 
it's probably not likely that map-each is used that way.

Hmm, if somebody relies on the incorrect behaviour, then it is good 
if such a mistake is revealed

There is a fix in R2/Forward already. I'll post it here.

Unfortunately, this is an old problem with an old fix, but not as 
old as the last version of R2.

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

This is from the Feb 23 version of R2/Forward.

I am not sure which group to choose for this poll for REBOL preprocessing 
directives. I hope this one can be used, but wait for a moment before 
going ahead to allow for objections.

OK, since nobody objected, I shall proceed with the preprocessing 
directives user-poll:


- in the current INCLUDE, the PREBOL directives are made standard, 
while other directives, like COMMENT are made "user-defined", which 
means, that they are defined "on-demand" only


Since in RMA, we actually used the COMMENT directive as "standard" 
for quite some time, there is a suggestion (by Cyphre) to make it 
standard as well. Any other opinions on which preprocessing directives 
should be made "standard" and which ones should be "user-definable"?


Just a note - switching this in the code is trivial, it is more of 
a standardization issue, than a problem of work in my side.

Also, once the directives are defined, there is no difference between 
"standard" and "user-defined" as far as the speed or other issues 
are compared.

(that is because all directives use the same way how they are defined, 
using the SET-INCLUDE-DIRECTIVES function, the only difference is 
*when* the directives are defined, and whether it is by default, 
or whether additional action is needed)

Thanks for the update, including the great docs Ladislav. I will 
try to give it more thought, and incorporate the new version in my 
work. In the meantime, here are some quick comments.


Have a naming convention for scripts that define include directives. 
e.g. %localize.r could be %#localize.r or %incl-directive-localize.r. 
Short is good, but special characters may affect portability.


If a directive doesn't require per-script or environment specific 
changes, like #comment, make it standard. And the way you designed 
#localize is very nice, in that it gives you control. Do you have 
helper functions for updating 'translate-list? I might call it translation-list, 
since 'translate sounds like an action.

A note to "%incl-directive-localize.r" - you may not have noticed 
yet, but %localize.r defines four localization directives, and string 
handling, not just one directive.

But, certainly, naming convention may be important, although, in 
this specific case, we do not have any alternative for localization. 
Certainly, if Robert agrees, we can easily change the name to a more 
descriptive one.

The COMMENT directive really looks general enough, so it is meaningful 
to make it standard. Funnily enough, its spelling is:

    COMMENT


, i.e. it is the old word, Robert just wanted to be able to strip-out 
the COMMENTs from the code, that is why I made it an INCLUDE directive 
as well. This shows, that currently you can make anything an INCLUDE 
directive, not just issues.

Making the COMMENT and INCLUDE directive, we actually keep compatibility 
with old code, being able to strip-out the COMMENTs from it when 
wished.

Of course, I can imagine a case when the COMMENT directive would 
be incompatible with the COMMENT function. See e.g. the following:

    COMMENT 1 + 1


if it is a function (not being stripped out), the expression *is* 
evaluated as a COMMENT argument. If handled as a directive, and stripped 
out, it ends up like this:

    + 1


(the COMMENT 1 part being stripped out), which looks unexpected. 
But, I was not afraid of such strange things, since nobody uses the 
COMMENT function like that.

Regarding the translation functions: yes, the directives do not suffice 
to supply all the necessary functionality. Other code is needed to 
handle the run-time translation of "marked" strings. That code was 
written by Cyphre and is influencing the behaviour of RebGUI widgets 
to show the currently required language version of the text.

err: "Making the COMMENT *an* INCLUDE directive..." is what it should 
have been in the text above