World: r3wp

The biggest problem with programmers is that they expect programming 
to be symmetric in all dimensions, but it's not even symmetric in 
it's simplest of elements.


Language (that is "expression") is not based on a pure math, nor 
is the world in general.


And, as in the world of thermodynamics (which covers most things), 
many processes are not reversible.


The oil flows from the well into the ocean of the Gulf. The process 
does not work in reverse.

it's = its, TTF

When trying to code D.J.Bernstein hashing function: forall key [hash: 
hash * 33 xor first key] I found that this simple notation is faster 
than traditional C like: forall key [hash: xor~ add shift hash 5 
hash first key]. (Note for real use it is necessary to shrink hash 
to 4 bytes.) seems shift and additioin is not faster than multiplication 
under Rebol?

The overhead of the Rebol interpreter is much greater than those 
fundamental instructions, so any savings in the fundamental instructions 
are swamped by the overhead of processing the rebol words.

can anyone explain this strange lexical analysis error to me?:

>> +10: "test"
** Syntax Error: Invalid time -- +10:
** Near: (line 1) +10: "test"


+ is a valid word character symbol and +10 is not supposed to a valid 
integer (as opposed to -10)... but why does it see a time! type?
same on R2 & R3

Because of this ?

>> +10:23

== 10:23
>> type? +10:23

== time!

but why is + associated to time?  10:23 is lexically valid there's 
no need for + there, or is there a situation where it is required?


I know that + is required when its preceded by a date... but on its 
own, this looks like it should be changed.

funny since I'd say that +10:23 is the Invalid time string.

+ is a special-cased word character symbol, not a regular one. It 
+ is at the beginning of a sequence of numbers, it is treated as 
part of a number. If a number has a : in it, it is treated as a time.

It + is -> If + is

Also note:
>> -10:23
== -10:23
>> type? -10:23
== time!

ok ... did a bit more inspection in the mean time and I get it now. 
 might be nice to put this somewhere in the datatype documentation...

Yup, same reason. There was a lot of blog/ticket-comment/chat about 
this recently for R3, and what was revealed applies to R2 as well. 
Though the precedences and rules have been tweaked for R3.

Am I wrong in remembering a version where +10 was an invalid token?

There is a CureCode ticket requesting that documentation, though 
it is syntax documentation, not datatype.

yeah, but my associative mind needs to know syntax related information 
based on a datatype, not the other way round  ;-)

Syntax precedence rules affect more than one datatype by their nature, 
so it should be better for the documentation of the affected datatypes 
to link to the syntax documentation.

yep... that's what I meant by association  :-D

If you read what I've been writing today, you'd understand why I 
am paying so much attention to organization of information :)

foreach allows you to step through a single series one at a time. 
 So, how would you step thru more than one series at a time?

a: [ n elements ]
b: [ n elements ]

foreach [ ofa ofb ] reduce [ a b ] [

] 

?

foreach [ofa ofb] join a b [...]

Aehem, nevermind.

use amartin's interweave or gabriele's nforeach

nforeach?? where is this?

http://www.rebol.it/giesse/utility.r

ahh... ok

I also found the relevant mailing list thread

http://www.mail-archive.com/[rebol-list-:-rebol-:-com]/msg18660.html

Anyreason why this can't be the default behaviour of 'foreach?

the one here might be newer (i don't remember and i didn't check 
:P): http://www.colellachiara.com/soft/libs/utility.r

they're both copyright 2003 and one is dated 2004, and the other 
more documented version is dated 2005  !

The most common case is iterating over a single block, so the current 
behavior makes sense. And while breaking compatibility is sometimes 
helpful in the long run, I hate to think how much code would break 
by changing FOREACH now. FOR, on the other hand, is not widely used 
IIRC, and I've said before I thought it would benefit from being 
a dialected func. Still, we can make our own under a new name and 
then campaign for it.

I guess my suggestion is that the current behaviour is for a single 
block, but it should be able to generalise *without* creating a new 
function.

In the same way 'for does ... where there is a skip counter from 
1 .. n

graham, i think you underestimate how hard it is to generalize FOREACH. 
:) the only thing i can think of is adding a /multi refinement or 
something like that, but then the way you pass arguments is not optimal.

But it's not impossible right?  :)

Why are you asking? You should rather provide a spec enhancement 
of Foreach, if you think it is possible

foreach opt [ integer! ]  [ word! block! ] [ block! ]  [ action block 
]


if the optional integer is missing, then assume it's just the one 
block of data you are working with
Otherwise the integer specifies how many data blocks

we could have that for 'for as well ... if the step integer is missing, 
assume one.

aha, so you are suggesting a completely incompatible function spec

not at all ...

completely backwards compatible ..

aha, it is compatible, since your proposed spec is variadic. OK, 
then it is a different problem: you are out of luck with variadic 
functions, not to mention that it is ugly (at least I do not like 
it)

in so much as I have to tell the interpreter how many parameters 
... yes

otherwise you have to use something which is different syntax

Anyway, I can't see that' it's any different from skip ... or other 
such

The main problem is, that except for DO we do not have (nor it is 
planned) any variadic function in R3

That's not a problem .. just different

Not a problem? For me it is a crucial problem.

Notice, that even MAKE was made strictly binary (i.e. not variadic 
as in R2) in R3

Ok, instead of usig an integer ..

if the first parameter of foreach is a block containing blocks, then 
consider it multiple data blocks