World: r3wp

Before I read this I was going to add ...

Feeling a little bit responsible for being this argument to the rebol 
community, in a small attempt to advocate for more users ...  I'd 
also like to say, that push come to shove; if the argument gets to 
a point of driving away the likes of Nenad, or Gabriele in some sense 
of disgust at the un-understanding of some of us versus the potential 
of a few thousand new faceless strangers that may be attracted to 
a "garbage loading dialect" language.  I'd vote to keep Doc and Gab 
happy and skip the faceless masses.   ;)

Check out TRANSCODE/error.

But ... I still don't see the performance hit of a lexical scanner 
that defaulted to "make foreign!" and continue whenever a position 
in the code would trigger a syntax error?  Or as Anton states ... 
is this an amazing lack of comprehension?


I've been working with Bison and Flex ... and from what I understand, 
this would not make the parse tree any more complex.  It would simply 
change the runtime semantics to "make foreign!" at every point where 
the scanner would fail.

We want that failure in LOAD though - it's what makes it trustworthy 
and fast. Check out TRANSCODE/error, but keep in mind that code to 
cope with foreign data is much more complex than regular code. Beginners 
should stick to REBOL data.

Or to data loaded by codecs called by DECODE.

Again ... I'll side with Doc, push come to shove ... but ... it can't 
be more complex than throwing a runtime error in an action! when 
given invalid datatypes, no?   foreign! on action! or evaluation 
would trigger a throw.  The only operation I'd allow is  to string! 
 or a test such as foreign?   But I'll now try and hold my tongue 
for another 2 months.   ;)

In regards to my "Why not load as a string! ?" comment, I was thinking 
of some sort of load/safe refinement

LOAD is safe already. The fact that it throws an error on bad data 
is what makes it safe.

We changed it to be even more strict in R3 to make it even safer.

The "more strict" is making LOAD/header actually require a REBOL 
script, if not the header itself.

I haven't followed this thread

Ok, fine two minutes then.   ;)   "bad data" would be a new foreign! 
datatype.  No longer "bad".  It'd be no more a code hassle than doing 
email! + url!      Take the hit then.  But you still have a "valid 
REBOL series!" to play with.  Even with a $$10,000.00\\  floating 
around in the series ... semantically equivalent to email! or file! 
 out of context for those functions that require particular datums.

but usually you want to parse data knowing what datatypes you are 
expecting.

would it be possible to do a to-block on that data accepting only 
certain datatypes and anything else is coerced to string?

eg telephone numbers are recognized as invalid time values

>> to-block "  345-6789  "
** Syntax Error: Invalid date -- 345-6789
** Near: (line 1) 345-6789
>>

Foreign data will have codecs. No need to try to treat it like REBOL 
data. The foreign! type is the worst possible situation, since it 
would take the overhead of dealing with foreign data away from the 
actual input proces, and add that overhead to every bit of REBOL 
code that called LOAD, because LOAD would no longer be trustworthy.

or perhaps rebol by adding a telephone number data type

fix rebol

Right now you can count on LOAD returning REBOL data, or an error. 
This is what makes LOAD trustworthy enough for DO.

seems a significant omission ...

Really? Do you mean #1-773-555-1212 ?

how many times do you see phone numbers like that in real data ?

In REBOL data, plenty. I thought we were talking about LOAD, not 
input processing.

to block is clearly evaluating

Processing UTF-8 to parse REBOL data, yes.

I say UTF-8 because this is R3 LOAD we are talking about - R2's LOAD 
won't change again.

Listen, we had this discussion before and the compromise endied up 
being TRANSCODE/error (added in alpha 39).

Is the r3 group?

this

didn't know that

Yes, I've noticed the same arguments put forward as before.

Oh well, we need a FAQ then !

This discussion pertains to R3, since it is a request for changes 
to REBOL. R2 isn't changing.

I'll do the same thing in another 2 months or so ...  It's a new 
quirk of mine Anton.   ;)  I'll continue to do so until the kids 
on compsci.ca see REBOL as a worthy thing to study, instead of writing 
it off with comments like  "I can't stand the syntax".

That gets really tiresome.

someone will accuse you of trolling

some of us just have short memories!

No Brian, you won't because Carl already made the change in alpha 
39, and is currently writing DECODE.

Even my compromise from the last time you brought this up was rejected. 
TRANSCODE/error and codecs is what we got. Live with it.

I'm doing it with well meaning intent.  I really do struggle trying 
to get young up and coming university students to give REBOL the 
chance I know it deserves.  And sorry Brian, I've haven't tried A39 
yet.  I'm still running the A33 for Linux.

Well, I already rewrote LOAD to take advantage of the TRANSCODE changes. 
It should go in the next build.

This includes LOAD/next, btw.

Like LOAD/header, it is better than R2 :)

This is very cool news ... I'll crank up wine again on an a40.exe 
to see ... time to catch up with recent developments again.

I think upgrade works with the Linux version now, and there are Linux 
builds on the releases page.

Even cooler news from the upcoming LOAD:
>> load ["print 'hello" "print 'there"]
== [[print 'hello] [print 'there]]
Works with files and urls too - Carl's idea :)

uh ?

I've been trying upgrade ... just did a minute ago ... it stashed 
an r3-a40.exe  so I wouldn't have bothered to look ... but am now 
as you made me all keen and curious.   And yes, the releases page 
has updates I didn't notice.

Thanks Brian