World: r3wp

Gabriele, that "security feature" argument was always more of a "look 
on the bright side" thing, not really countering the argument that 
it may be a bug. However, more functions are usable in R3 after being 
built with #function! ...] than were with R2 - apparently references 
to the "global" environment are bound, and then the function-local 
environment. I have yet to figure out how, but I'm working on it; 
a clue is that there is no real "global" environment. That means 
you lose the security benefits of the non-feature in R3, so enjoy 
the get-path and SELECT security enhancements that more than compensate 
for such things.

Ladislav, you, Gabriele and I are not the kind of users that MOLD 
is trying to be friendly to. Try newbies.

Apparently the particular "global" context bound to serialized functions 
in R3 is the system context, not the user context. Or maybe it's 
the exports context - hard to distinguish them right now, since system 
and exports is currently the same object (it's a work in process). 
So that makes serialized functions minimally useful in R3, instead 
of not useful at all as in R2. Interesting.

Try newbies

: unless I find out you are right, I do not have any reason to believe 
you (I remember, that I was a newbie once too)

The trouble is, that the situation is worse, as far as I am concerned. 
To me, MOLD is quite "hostile" actually

You are the type of programmer who will look up the IEEE754 standard 
to determine math behavior, or will write in C if necessary. You 
are not MOLD's target market :)

Wrong, I *am* MOLD's target market currently, without having any 
other choice: console forces me to read that nonsense

That is why I wrote #1634

You are misunderstanding the difference between a "market" and a 
"target market". That ticket was a good idea though.

Brian: I insist that the "newbie" argument is silly at best, dangerous 
for the language at worst.

i also think that mold/all would be better for newbies than simple 
mold, but i guess that's a matter of opinion, since nodoby did any 
experiments with a group of newbies.

I think as a newbie I try mold .. when it doesn't work, i ask here 
and the gurus say, use mold/all :)

rather than newbie, I use "the principle of least surprise"

Yep, I also think the "newbie" argument is bogus.

Oh my, more stuff to read!

Carl is trying to "undefine" ODD? EVEN? and COMPLEMENT for floating-point 
pairs. I guess, that nobody would really miss these functions for 
FP pairs. I even think, that ODD? and EVEN? are not used (of little 
use) for decimals as well. Any different opinions?

I think that I had some code somewhere that once used odd or even... 
but it's not important, because it is so rare, a person can convert 
to integer first if they want.

So, no problems. Added ROUND, which is more interesting.

Regarding all the above discussion regarding MOLD... there is an 
assumption, once that I do not believe.


The assumption is this: that any function of REBOL could ever produce 
the perfect output storage format for all data.


Or, stated another way: part of the design of building all applications 
that store persistent data is to build the storage formatters (savers) 
and storage loaders.


I don't think there's any way around this, because storage formats 
have specific requirements, such as speed of loading, indexing keys, 
resolution of references (words or other), construction of contexts, 
etc.

once = one, TTF (typing too fast)

Yes, I do agree with you, that is why I restricted my notes (or at 
least tried to) to just script preprocessing.

...and in that case we have the LOAD function, and its counterpart 
should be the SAVE/ALL function, not the SAVE function (that is essentially 
what I wanted to underline/document somewhere)

Yes, a good point.  But, and furthermore, even using LOAD instead 
of LOAD/all can be a problem for users due to its method of removing 
the outer block. An odd problem.

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