World: r3wp

By default, it will be an error. The default will be when the /on-error 
option is not used.

Otherwise you will be *required* to specify a strategy for dealing 
with the data, perhaps as a function or code block if you like.

you know what i mean, i'm talking about a default conversion when 
the option is selected

There will be no default - the parameter will be required.

It's either specify the option or don't.

like for parse.
default use: parse data none
with specific separators: parse date "..."

You are passing a parameter there - it's not the same thing. If we 
allow a none parameter (which we shouldn't), it should mean 'skip.

However, there should be a 'local parameter for localized numbers 
and dates.

we don't need to skeep, the only skiped chararcters are the separators

*skip

Yeah, you should definitely skip separators. Use load/on-error data 
'skip if you are expecting separators, as REBOL doesn't have them.

Except for whitespace, of course.

see the sqlab code, it's exactly how it should behave

his load-all, we don't need more fonctionnalities

No, that won't work. It will break on nested structures.

The whole point oif LOAD is handling the whole data syntax of REBOL.

oif -> of

i  talking about the functionnalities not about his implementation

So am I. That functionality won't work, for reasons Doc most recently 
explained.

we just need a list of separators when a wrong loadable value is 
encountered to continue the loading

reasons Doc exposed are false

We have a list of separators: Whitespace. Anything else requires 
special handling that will need to be specified. The only problem 
with Doc's comment is not getting that part of the LOAD/else proposal.

anyway if your objective is to build a mezzanine it's useless, it 
will be slow, i will continue with my own pre-parsing process

LOAD is a mezzanine, but it calls natives. My goal is to make LOAD 
useful.

Please contine to do your preparsing. I was doing this on btiffin's 
suggestion, and he seems to be afraid of PARSE :)

Umm, yes and no on the fear.  Yes fear kept me from holding a lecture 
on the subject, but I usually PARSE from reading the pretty print 
code.  That's how my locate utility works.  But I'm not concerned 
with us.  I'm concerned with construction bosses and non-tech professors 
having access to a programming language and learning maybe one or 
two tricks a week.  I'm also on the side of the gurus in terms of 
correctness and concise coding, but I'd like to see REBOL ,the system, 
that out of the box would be a robust battle tank.


Add taint to the fuel, it would still function; perhaps not gracefully, 
but the big guns would still fire.  Today, the slighest spoonful 
of sugar and our tank dies on the field, no movement, no guns.


foreign! and Steeve's suggestion of scan till whitespace (and yes, 
some source code would load as almost all completely foreign! gibberish 
if a quote was out of place, but so, we can take that and fix it). 
 But at least REBOL wouldn't die; the data/code would be loaded and 
inspectable.  And yes, this could lead to the odd rare catastrophic 
failure, but we get that potential with "clean" datatype! scripts 
too.  I think the slight increased risk is worth the new group of 
users this could attract.

Sorry if I misrepresented your position Brian, I was trying to be 
humorous. I've just put in a request to tweak TRANSCODE's handling 
of commas. If that request goes through, I will be able to add the 
/else option to LOAD. With a few more tweaks I can increase the speed, 
make more of the process native, etc. This is not preventing REBOL 
from dying - it is just allowing you to provide a defibrillator :)

In case you wondered about the origin of CTRL-ALT-DELETE - this is 
actually kinda funny http://www.flixxy.com/computer-history-ctrl-alt-del.htm

There will be everywhere soon - the revolution of the TIRE http://www.flixxy.com/car-tire-technology.htm

Oh Brian.   I take few thingsseriously ... well, except my belief 
systems.  ;)   Me too, I forgot the smiley after ... pretty print 
code.


And Yayy.   Now if this can be out-of-the-box REBOL for linguistic 
profs and science types  ... woohoo!

btiffin - did you read R3 'transcode description? It seems to have 
relaxed execution, returning error as an arror. Not sure it would 
be what you want, but maybe? http://www.rebol.net/wiki/Transcode

Actually, that is exactly what we need. One problem though:

>> transcode "a,"
== [make error! [
        code: 200
        type: 'Syntax
        id: 'invalid
        arg1: "word"
        arg2: "a,"
        arg3: none
        near: "(line 1) a,"
        where: [transcode]
    ] ""]

I've requested that this be changed to:
>> transcode "a ,"
== [a ","]

putting off the error until the next call. That change would be enough 
to do LOAD/else.

All it would require is to make "," a delimiter in the scanner - 
a trivial change for Carl.

Sorry, two messages back: "a ," -> "a,"

in the second example.

Pekr;  I think a convo we had on the blog wayy back was partly why 
Carl relaxed TRANSCODE  ;)

We went through a phase of trying to name the junk! datatype, and 
very real issues were raised about where the lexical scan should 
restart after.  Then someone discussed the linguistic analytic potential 
and another very real concern about polluting the semantics of REBOL 
datatypes was raised.  Carl may have been afraid we'd all run off 
and produce "any old crap that works", where I aim to provide a console 
that takes "any old crap" and works.  ;)  Leaving Gabriele and others 
free to use the ever cool true semantic meaning of data and code 
and leave junk! that floats for analysis of real world information 
sans REBOLification.


Part of that conversation lead to and is included in http://www.rebol.net/cgi-bin/r3blog.r?view=0078#comments

BrianH: ... then I expect you will propose the change to Carl, to 
enable load/else? :-)

any known rebol datatype should be recognised, and the rest should 
be assigned under junk! or similiarly named datatype. What is AI 
about that?

 Telling the different between a REBOL value and "the rest" is AI. 
 If you can without AI, then "the rest" is defined with a specific 
 parse rule... then you can just use string parsing, and it's not 
 a human language anymore but a specific language you just designed.

Right, I misunderstood LOAD/else proposal, I thought you could supply 
your own parsing rules to be used from the point where LOAD fails. 
But I still can't see the point of using LOAD on non-REBOL data, 
instead of string parsing or LOAD/next. LOADing a whole book would 
most probably blow out REBOL words limit. If it all boils down to 
splitting untrusted input into whitespace separated tokens, why no 
just use PARSE data "" ? Is there a real benefit for the programmer 
of having LOAD not stop on syntax errors?

Doc; no not really a benefit to programmers and rebol-by-nature types; 
 The goal is non-rebol types and creating ease of use that attracts 
those types to become rebol-by-nature.  But I've sure wasted a lot 
of good rebol time already, so ... 

Go Doc Go and Do Gabriele Do    Ok ... and Yay Brian!    ;)

Pekr, I have already proposed the TRANSCODE change, and I can start 
the implementation of LOAD/else asap (which will likely be after 
the release). LOAD/else will work without the TRANSCODE fix, but 
will work better with the fix.

About VPS: Looks like it could be Linode for me. Slicehost is pretty 
on the surface, but it appears that customers are a bit happier with 
Linode. Also Slicehost was recently purchased by Rackspace, and some 
customers reported a lower service quality after that. That might 
be a bad sign.

doc, its faster to let rebol do what is does best in binary and let 
us take over on those tokens it can't recognise.  just ignoring comma 
would have allowed me use scientific data more than once directly 
 without having to dare understand parse intricacies.


remember that parse IS NOT EASY.  I didn't use it for over 6 years, 
cause everytime I dared, it just blew up in my face.  this would 
provide a simple entry point for more people to support DSL and leverage 
the rich datatype system in rebol, without the need to be a guru 
level reboler.

the point is not to replace REBOL's syntax, but allow REBOL to cope 
better with the rest of the world's data, IMHO.

IMO, designing a good DSL is far more difficult than writing parse 
rules.


I think that ppl here are underestimating the complexity of implementing 
a jump-over-foreign-data feature that would work in the general case. 
REBOL syntax is not based only on whitespaces, but on delimiters 
too : double-quotes, curly and square brackets, parenthesis,.... 


So it's perfectly valid to not use whitespaces at some places, like 
in : "either conditon [true][false]". So what should LOAD do in case 
of, e.g. : "either condition [f,o,r,e,i,g,n,0,1][false]" ? IMHO, 
besides reporting a syntax error at "f," , there's no much point 
returning [either condition "[f,o,r,e,i,g,n,0,1][false]"]. And if 
you think that LOAD could just return [either condition ["f,o,r,e,i,g,n,0,1"][false]], 
then you just jumped over the complexity by creating some syntax 
rules in your mind, but LOAD can't do that. Once LOAD has passed 
the syntax error point, it has no sure way to determine where the 
foreign data ends and where REBOL correct syntax starts again. That 
would require at least, an AI engine (like Gabriele stated above). 
I'm not even sure that all possible cases could be covered that way.


Btw, does such feature exists in any other programming language? 
I've personally never seen or read about such feature elsewhere, 
maybe for a good reason.

load-foreign works well to me in R3.

alpha: charset [#"a" - #"z" #"A" - #"Z"]
chars: union alpha charset [#"0" - #"9" "-_"]
word: [alpha any chars]


probe load-foreign "either condition [f,o,r,e,i,g,n,0,1][false;]" 
[
		;**keep words with comma as trings
	[word some [#"," any chars]]		[keep &]	
		;**remove ";" at the end of words
	[word #";"]				[keep to-word head remove back tail &]	
]

>> [either condition ["f,o,r,e,i,g,n,0,1"] [false]]

I still vote for foreign!  as a datatype.  Sure there will still 
be reasons for throwing errors on evaluation on foreign! but I don't 
like the fact that the errors occur on load.

Give linguists a tool that out-of-the-box can load a poem and let 
them count characters, words, and transitions.


Let REBOL pros worry about the hassles of evaluation.   Re: where 
the foreign data ends; Skip AI, just go with delimiters.  Whitespace 
or quotes or any of the braces etc.  And if a missing quote causes 
a script to fail ... well bad on the coder for not testing before 
release.  If the English professor gets wonky counts, well let them 
figure it out, but give them the wonky counts not a LOAD failure. 
 IMHO it really would open the door to so many more uses and users. 
 


And with Steeve's example ... build something like that into the 
product.  Don't make poor Professor Keating try and figure out why 
most of the Dead Poet's prose can't be analysed with REBOL's nifty 
cool block data functions.


And as long as REBOL had foreign! as a native datatype, writing a 
LINT would be dirt easy.

And I could LOAD %cobol.cob  and do all kinds of super cool preprocessing. 
 Or at least wait for Sunanda to write a super cool preprocessor 
and live vicariously through rebol of the year candidates.  ;)


REBOL could be the JavaDoc, EpyDoc, Doxygen, ..., ReST besting documentation 
super tool of tomorrow.

doc, the point is that I and others HAVE had ,many situations where 
this would have saved HOURS even given new reasons to use rebol at 
some jobs.  the point is not to allow new rebol dialects, its just 
that in MANY cases it would work..  we all know that this isn't a 
replacement for parse.  but allowing me to import external data through 
load is just faster than parsing.  You still have to tailor the extension 
to the dataset anyways.

We could load things like C code directly, and then parse it using 
block dialecting instead. way faster.