World: r3wp

The speed of datatypes comes from the fixed action list. It allows 
the dispatch to be a simple retrieval from a fixed offset into a 
function table, no lookup required. It is not the same thing as general 
class-based methods, which in a language with dynamically typed variables 
would need to do a lookup to figure out where to find the method 
to call, same as with instance-based methods.

- Lets programmers used to imperative programming code using algorithms 
they already know

 - there is no algorithm you cannot use in REBOL even now, those are 
 mainly C idioms as far as I can tell?

I meant style I suppose, though even C is expression-based. The idioms 
would actually be more assembler-like than C-like, for 2-address 
instruction sets like x86. Still, this wouldn't add anything to the 
language that isn't there through other means, except speed. And 
while it wouldn't complicate the interpreter, it would complicate 
the semantics of REBOL, making it harder to explain, debug or reimplement.

agreed

http://www.rebol.com/priorities.htmlIn the green little box, there 
is an item called "Deci". What's that?

A new deci! datatype for storing floating point numbers in BCD (Binary 
Coded Decimal) format.

Tanks Anton.

=> Thanks

good news about the STACK function: http://www.rebol.net/cgi-bin/r3blog.r?view=0075

hah! A percent datatype as well. :-)

yes... singing with Queens... I want it all, I want it all,I want 
it all, and I want it now:]

Oldes, how spooky, I have a Queen song running in the background!

I agree Queen songs are spooky ;-)

:-) Good to be back!

Hi Peter, sadly, this isn't reddit. I so want to vote your comment 
up :-D

Minor Bitsets - http://www.rebol.net/r3blogs/0077.html

is it just me or is it obvious R3 is about giving us what we always 
asked for and need? so far, all I read is user requests coming to 
life.


If people think 100% open source is the universal panacea...  I think 
its time people looked at how REBOL is evolving.


I think R3 might be the middle ground which allows much of the "open" 
discussion to be irrelevant.  user types,  open  linking and compilation, 
 lexical allowance for unrecognised tokens, somehow, this seems like 
we will be able to mold (sorry for the pun) REBOL into what we need, 
finally, rather than molding what we do to what REBOL (the interpreter) 
wants  :-)

pekr, I think you're going to have to book a flight to paris... to 
much of what you and I have criticised about  for you not to show 
up.  ;-)

Make sure you comment on the relaxed lexical parsing.  I've been 
working around this one for a long time...but it may hold traps my 
giddy little mind is missing today.

I guess I'm getting annoying with all my comments  ;-)  this really 
is a subject I have been wishing for about 5 years and am constantly 
reminded how usefull extending lexical analysis would be.

Yep, agreed (not about the annoying part - keep them coming)  The 
comment from Norm caught my eye.  If REBOL can attract the attention 
of the academia...why we might get paid to be rebols.  :)

Maxim, I really like your load/extension way. It would be very useful.

Sorry to take so long to reply - I was sidetracked. I've put an alternate 
idea to relaxing the lexical rules on the comments. Take a look.

The idea is to add a LOAD directive to the PARSE string dialect. 
LOAD would treat the sequence of characters at the current position 
as a REBOL value, and then check it against a block-dialect rule. 
If it is not a valid REBOL value or if the check fails, the directive 
fails and triggers any appropriate backtracking. If you are not interested 
in checking the value, just use SKIP for the rule. If you want the 
value, use SET (or COPY perhaps?) before the LOAD to assign it to 
a word.

The problem with relaxing the lexical rules of the LOAD function 
is that REBOL can't handle natural language syntax, particularly 
punctuation. You would need to convert a word to a string to tell 
the similarity between "Hello" and "Hello,", at which point you are 
doing string parsing again, but slower.

It makes sense to be able to parse REBOL values in the middle of 
non-REBOL text, but not as much the other way around.

Nonetheless, I can see the advantage to having a comma! datatype 
that would be a syntactical noop, so you can put one anywhere in 
REBOL code and it would be ignored by the standard dialects. Then 
we can give these commas meaning in our own dialects, or ignore them 
too.

Why not parse/load ? Would it be possible to parse the code as it's 
loaded? if load fail, I know position in the string so I  could modify 
the string and continue.

load/next would be enough  as proposed by Carl iirc

load/next is already available

But I'm not sure if proposed load/relaxed can help me. It's one more 
pass for me. 1. load, 2. check for invalid types, 3. parse

and I don't  want much, I want just << to be loadable in my dialect.

brian I like your idea VERY much.

I just posted a second vote with an example of how brian's idea actually 
is exactly like the load/extension.

Keep going guys.  This feature is going to rock if it gets implemented...in 
any form.  But I'm leaning towards Carl's original load/relax (load/lazy) 
:) with an invalid? or nonsense? test.  Mainly because my brain hurts 
thinking about parse too deeply.

but look at my last post and the code example  its VERY simple... 
if I had had THAT 5 years ago, I would have been able to build up 
from REBOL to be able to at least support an array of data from the 
start and then try to understand the concept of the grammar tree.

the issue with learning Parse is that you have to implement everything, 
from scratch... just escaping strings is not trivial for many parse 
newcommers... so all the rest becomes such a mountain.

block parsing is easier, obviously, but then you need a lot of REBOL 
knowledge about binding, evaluation (and how NOT to evaluate ;-) 
 so even that becomes a bit hard for most newbies...

Yep. Agreed.

Jonesin' for R3 now.  Way more than three days ago...

Even though I like the lexical extension to LOAD I have concerns 
with the approach.

As Carl noted handling the different quoting possibilis  is going 
to be a problem, specially those that intefere with REBOL native 
lexical values.

For example how to use the new functionality to deal with KSH scripts.

Another issue is what use is to have an alien value?

It is very limited. After you get some input you want to be able 
to operate on the input as value. So alien should be just a flag 
in transition to a conversion to either a native value or an extended 
value.

yes exactly.

The extended value should then belong to a class where you can define 
its MOLDIN and the operations that you can excercise over this value.

its an intermediate "can be recovered" value as I see it.

But this implies the the object system should move from prototypes 
to CLASSES.

those are datatypes Jaime.