World: r3wp

Not to mention 2+ year old regressions that came in the 2.6.3 to 
2.7.0 update - Steeve found one in the last week.

Yes, I will share.

Well, of all the people that can complain; one of the people fixing 
them is worthy I guess.

Yeah, I suppose :)

Just discovered today in R2: LOAD/header has two errors.

- LOAD/header of a directory should fail with a syntax error, but 
doesn't.

- LOAD/header "rebol []" or the script equivalent should return the 
header object in a block, but instead returns it straight.

The /header option is being checked at a lower priority than it should 
be. Fixed in R3 today though.

sounds like some good stuff to put in notes and upload to the 2.7.7 
world

Notes, yes, or at least RAMBO.

LOAD is a mezzanine in R3. You have no idea how cool this is :)

Yes definately Rambo those things.

I submitted the week's bugs to RAMBO.

Re; LOAD; well yeah ... TRANSCODE can be used to support junk! now. 
 ;)  You'll love it Brian, really.  You can have your grandma asking 
you questions about deep deep PARSE problems as she dances around 
the console analyzing her grocery list, while you point out that 
the total is actually wrong due to a lexical problem with some of 
the money! values.  Then, 4 months later, she'll teach you something 
that her new perspective and point of view made possible as she unveils 
the world's greatest home management software ... like evv-a.   :)

Oh, I love TRANSCODE already, but it is not finished, so I can't 
yet use it to implement R3's LOAD/next.

My grandma is smart enough to program if she wants to, but for now 
she doesn't see the value of internet access for her.

I'd rather get my dad programming - he's smarter than I am in some 
ways :)

Sorry BH, I meant junk!  and a version of REBOL that loads any value 
any time any place by anybody.

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