World: r3wp

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.

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.