World: r3wp

Modules in binary compressed format - http://www.rebol.net/r3blogs/0274.html

A90 now also for Linux and OSX

Both fine on my Untu and XP. Whatever.. BTW, was there ever a chat 
about assert {}   I am spending some time in Groovy and thinking 
about the errors in a Rebol book: the Manny Groovy book was generated 
so at least the code examples run ... groovy uses assert a a good 
deal ... which got me to thinking about REBOL  comment {}  which 
seems to suggest that we could have an assert {}  which is evaluated 
only when a REBOL option is set. and have it default to OFF

Oops - so funny - I went to look at rebol.org for any use of an assert 
but there it is  assert  in the R3  docs   missed it ...  but can 
it be flipped not to run?  Or would you just  set assrt: :assert 
 and wrap it?

assert is used like any/all to quickly provide integrity tests.

we had assert back in Smalltalk SUnit ... ;-)

Let's comment on the compression format - http://www.rebol.net/r3blogs/0275.html

To not to be able anymore to reduce this [( )] at this [ ], is really 
annoying.

I have to clean my reduced blocks from unset! values returned by 
called functions.

Really, I don't  understand such modified behavior in R3, what's 
the gain, what the purpose ?

WHAT?  this is totally unusable.  ALL of my code depends on the  
"reduce this [( )] at this [ ]" philosophy at some point.

is the same with compose?

No, it's ok with compose, but i can't change the reduced blocks to 
composed blocks, it would destroy the sake of my project

I just want Carl or someone explain to us what is the gain of such 
change.
It's just causing wrackings currently

I see absolutly no interest.

this is really annoying and like you, I see absolutely no real-world 
usage ... it sounds more like an oversight on carl's behalf.

like... oops ... forgot to remove unset values in reduce native.

in the meantime, you can just make reduce a mezz , call the native 
inside of it and remove unset values... at least its going to be 
done automatically... although it will slow down your code a bit.

you should post on curecode for this.

it's what i doing currently, a remove-each of the unset! values

did you post this to curecode?  carl will definitely give aheads 
up on the issue quickly.

(Arghh !!! Stupid busy Altme, it lost my note again)

Not a bug

why is this not a bug?

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.