World: r3wp

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.

I wrap most things, properly (usually) but it's nice to let bosses 
be bosses without having to tell them that money has to be typed 
in with ticks instead of commas.

I understand. Only thing I am saying is that you can accomplish this 
without needing LOAD/lazy.

Yeah, but not in one-line of code  :)

Jaime; Just so ya know.  Keep up the counter-arguments.  This is 
an issue that needs to be thought through upside down and backwards. 
 So far it's mostly been all pro few cons, and I probably have blinders 
on regarding the bigger pictures.  I have two very specific items 
in mind.

Well that and the coolness of being able to  load %random.txt

I hear you the "Script way".

But there is going to be a price for this one liner. Either in load 
time, security, size, and others.

I'm more of the PARSE/LOAD camp.

Agreed.  About there being a price, wherever it hides.

If I get my wish and you can parse ports in R3, that would deal with 
the major advantage that LOAD has over PARSE, that you can LOAD files 
and urls directly. PARSE on ports with a LOAD directive would be 
the best of both worlds. I only wonder how backtracking will be handled 
on direct ports.


I hope that you will be able to LOAD ports too, particularly LOAD/NEXT.

yes to all of the above, wrt backtracking, its not impossible, but 
its a hell of a complex algorythm.

Jaime, Maxim - please put your concerns into blog, so we can hear 
Carl's opinion on the topic ...

pekr, did you look at the blog?  I filled it up with (too) many comments, 
brian had a very good insight in modifying one concept I proposed.

Maxim; Never too many comments.