World: r3wp

it's an willing change of the design from Carl, long time ago.
It's not recent.

but he never explained such change, IIRC

posting it to curecode is a good way for him to see that a change 
isn't beneficial in real world use.  he will comment it there, and 
it will be usefull as a reference for further users... I did a search 
for reduce on curecode, found a few things... but since curecode 
serves as a reference, this would be a good place to put your grievance.

IIRC, it's to optimize the dialect's parsers using the function DELECT

all changes are well explained in curecode tickets when people complain 
about them.

some tickets have VERY in-depth explanations of R3 quirks wrt R2. 
 this would be a good addition... cause it surely will come up again.

but i would rather prefer, a special reduce function for his dialects, 
instead of enforcing us with such drawback

suggest your preference.  as I said... curecode tickets are all handled 
seriously.  I'll second your grievance if you put it up there.

I must first calm down :)

hahaha

See, why i can't remplace reduce by compose.
I use such rule to parse draw blocks
>> box: [ 'box  origin destination]


when i use this rule, it's auto intialising the variables origin 
and destination.


The interesting thing is that, when i change the content of the variables 
somewhere else in my code,
i can revert back the content of the draw block, just doing a:
>> reduce ['box origin destination]


You see, i use the same block of defintion to parse and change-back 
a draw block.

i try to do bi-directional parser, if i can name it like that...

ah nice idea  :-)

It is beneficial for real-world use, because it makes the length 
of the block returned by REDUCE predictable. REDUCE [ three expressions 
] should return a block of length 3. A *lot* of code depends on this 
in R3. If you want unset to go away, use COMPOSE or REMOVE-EACH.

where do you see R2 removing unset! in reduce?

Arghh, It appears that I was arguing about a very old feature

I am not yet adapted to this change

I want a reduce/clean refinement T_T

Will map! have a literal notation?

You can use the serialized notation with map!, but it won't otherwise 
have literal syntax.

#[map! [a: 1]]

Afaik, we don't have any characters left that can be used for delimiters 
to surround some kind of literal value. [], (), <>, and {} are taken.

We don't want to go the Perl 6 route and start using Unicode symbols 
:(

but a prefix can be used to identify the delimiters, its already 
done by rebol in a few case... there surely is a combination left.

but the serialized notation isn't that bad in any case

yep, interesting notation, and underused.

>> mold/all reduce [next 'a/b]
== "[#[path! [a b] 2]]"

>> mold/all reduce [next [a b] ]
== "[#[block! [a b] 2]]"

A serialized serie keeps his index, not bad -)

yep.

Missing something till now.

The sharing of same series is lost when they are serialized. They 
are duplicated instead.

There is missing some internal unique surrogate in the serialized 
format of a serie.
It's why RIF can't be realized until now, i guess...

yep that is a limitation.  it would be easy to implement on top of 
it... because there is an explcit serialized form right in the language.

something like 
#[string! 1: "hahaha" 3]
#[string! :1 5]

they key being valid within one load session.

yep, something like this

it would be a big num, so a binary surrogate would be a better choice 
(more compact).
#[string! "hahaha" 3 #FF00FF00]
#[string! #FF00FF00 5 #FF00FF00]

we could even use this within source code, so that when it loads 
an application, shared strings are pre-linked without needing to 
do init code.

In all cases, it will be a wast of space for all the small series.

I mean in the source

but mold/ doesn't have to add surrogates if they aren't being shared. 
 The internals have reference counters to data, so it alerady knows 
if a value is shared.

you're right

it could even go a step further and check if the shared serie is 
used in the block of code being molded, but that would hamper speed 
a little bit... a /compact refinement could be used to switch this 
extra verification.

perhaps...

it sounds like an easy thing for carl to implement... it only modifies 
a very small subset of natives.

don't know :-)

Would be cool if REBOL interpreter could generate some form of symbol 
file for encapped scripts.

Not the interpreter per say but the REBOL encapsulator.

Even if we can't get that it would be cool to at least to get a some 
form of symbol file for the core.

Just think of how much more bugfixes could be made if that were the 
case.

The serialised would be acceptable, if that were the literal form 
too, instead of - make map! []


It's too bad there's no succinct way left to represent that (and 
objects for that matter)

MOLD/all generates the serialized form, and LOAD reads it. You can 
even write the serialized form literally in your scripts. For map! 
there is no problem with using the serialized form. For objects and 
functions, you'll have binding issues.