World: r3wp

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.

but user types are still a mystery... there is no information leading 
use to beleive we will be able to complement the in-memory data with 
a molded form,  which can be loaded too.

I think datatypes is not enough as charaterization. You still want 
to encapsulate the methods related to a type.

R3 will have classes to... I just wonder why the artificial separation 
of prototypes, modules, datatypes and classes is needed in REBOL.

they can really all be one and the same, if the core system allows 
us to play with the internal accessors.   python does this beautifully. 
  you can make prototypes out of classes by implementing the accessors 
so they created a dict on each allocation, for example.

So this new lazy LOAD is kind of a PARSER of REBOL values + foreign. 
I think it maybe easier to provide  *rebol value rules*, so you can 
construct your PARSER as desired instead of triggering exceptions.

Just like default relust for alpha, digits, whitespace should be 
provided.

I look at this problem from two views.  wanting a forth style block 
editor and wanting to let a construction boss sit at home and edit 
his own data blocks.  The forth style CLI just needs strings...any 
string including something like  p [   putting an open bracket on 
a line by itself.  This can be done with string parsing and a dialect 
pass, but hey.  The other issue is a lot deeper.  I want the boss 
to type in $1,000,000 and not have to call me when load kakks and 
(when I'm not careful enough) breaking a script.

My reasoning is that the new feature is a mixed but I am afraid it 
doesn't really buy much.

which is what Brian and I are suggesting on the R3 blog.  brian's 
idea is to include LOAD within the parser as a directive.

I suggested supplying parse rules to load, but I feel his idea encompases 
mine but not the other way around.

mixed: "mix between scanner, parser, and interpreter".

read about it here, http://www.rebol.net/cgi-bin/r3blog.r?view=0078#comments

btiffin, You can always make a parser that stops at an invalid value.

And decide either to fail, or clean-and-continue.

Yeah, but that gets tedious, and being lazy, error prone when it 
is data dependant "bugs" that can break scripts.

Nah. That is easy to handle if you know how to construct your parsers 
properly. As easy an extra rule.