World: r3wp

And do dis' meant toward grandma.  I would have guessed she had IQ, 
many times it is a family trait.  ;)

Write it yourself. Use a user-defined junk! string type, and your 
own LOAD to work with it. It's easy (for experts). I've rewritten 
LOAD several times in the last week, twice today :)

Ahh, not the point!   ;)  It has to be part of REBOL out of the box. 
 It'll be the linguist's attractor, the physist's accelerator, the 
word of mouth advocacy ticket.

You don't want LOAD to be relaxed by default - that would be a debugging 
nightmare. I think that an optional user-provided fallback function 
would be a better choice. I'll look into retrofitting LOAD with one 
once we get LOAD/next working.

You certainly don't want a junk! type by default.

hummm  seems to me like the recycle word becomes obscure .... hehehe 
load junk!  or recycle data   ;-)

Well, to be honest, junk! would be the worst of names; foreign!  
maybe.  But now, I've ranted far longer than promised.  I'll wait 
two months before pestering again.

And re debugging, no I don't think so.  touching junk! would throw, 
and throw hot perhaps.  But it could float around in a block happily 
waiting to be analyzed or triggered.


Dang, another promise broken in under a minute.   One thing, REBOL 
can sure induce passion!   Now, there is a name for a datatype!

to me, I'd just add an /ALLOW refinemenet  to allow  unknown!   data.

parse is intimidating for the majority of rebolers... 

supporting the unknown! data makes it easier to just :

data: load/allow %somedata
foreach item data [
	switch type?/word item [
		...
	]
]


This makes handling external data, which is often 90% compatible, 
sooo simple.

for people learning the language and for many short scripts... the 
able is a simple no-brainer, which just works.

The debugging problem is that the locality of the error is lost. 
By allowing invalid data to be loaded, you put a timebomb in your 
data to be triggered at some later time, by code that doesn't see 
it coming. You want errors in your scripts to be triggered as soon 
as possible, and as close to the source of the error as possible, 
or you'll never find it.

Errors are the best friend a proigrammer can have.

See, there was an error in that message, and I regret it already.

that error is your friend

That's why I think fallback processing is a better solution.

depends what your problem is... really. 


 I've had scientific data which was 100% compatible with rebol expect 
 that it used "," to separate things.


having to use parse for that was both tedious, and for me at the 
time, extremely complicated.

but my load dialect compensated

and having to create a callback for it would also have been much 
harder than just not doing anything with it.

note brian, that I do agree with you in principle!

its just that many throw away code and system-based coding occurs 
with very controled input, which doesn't have errors. its just not 
completely compatible with rebol.

and giving a dead-simple way to ignore or trap it is in line with 
rebol's kiss philosophy IMHO.  


but I do think that for serious *parsing* and dialecting, your proposal 
is much better.

both Brians aren't talking about the same kind of issues, both requiring 
an "ideal" (and different :-)  approach.

(that's how I see it anyways :-)

just a thing, as far i know, "comma" are used no where in rebol values 
(except in replacement of points) why are they not handled by load 
as a separator like tab or blank

there could be a /separator refinement also!  btw.

For a fallback option, I'm thinking a function argument which takes 
one parameter (the input at the point of failure), or perhaps one 
of a set of words that denote standard handling strategies (like 
'skip).

there could be by default, who use comma as decimal point in amounts 
?

The comma was prohibited on purpose, to prevent people from using 
it.

noone

datatypes and real world data don't match exactly ... just close 
enough to be frustrating.

exsaping them is better than throwing errors

*escaping

*skiping

it  should be the default behavior

You mean that programming language syntax and data syntax don't match 
exactly. LOAD is for REBOL syntax, and we want those errors for REBOL 
syntax. Those thrown errors help you clean up your bugs.

debuging behavior should not be the default one (as you stated previously 
Brian)

Yeah, by default bugs in your REBOL syntax should throw errors as 
loudly as possible, so they get fixed. Including extra commas :)

but load can also understand just about all human readable ascii 
data ALSO.

which is one of the nicest features of REBOL

comma are like tab or newline, they should be simply skiped by the 
VM, they are not syntax errors, they are decorations

Prohibiting commas was a deliberate design choice, one I agree with. 
REBOL is not C or English.

we allll agree to that.

You can't see a tab or newline (not really).

only when molding values, but what the prob ?

We have code to parse syntax with commas - string PARSE, for instance. 
The problem is that if we allow people to use commas, they will use 
commas.

block: [a,b,c,d,e,f]; should be allowed with comma as blank separator

not within rebol code.

but when loading from a string yes.

ahah