World: r3wp

I was working. I just fixed LOAD, DO and CLEAN-PATH, and they will 
be incorporated tomorrow. The current build has built-in functions 
to get to DocBase, RebDev and CureCode. We're really close to release.

cool

The LOAD function above is likely to be the release version. The 
commented out options aren't done yet :(

Anyways, I was working *here*. The fallback option is likely to get 
implemented :)

Thanks to the people who argued with me, you'll have better code 
as a result :)

am I alone thinking, that ability to load junk by default is utter 
nonsense?

No, you are not alone, I also think that and argued that point above 
:)

It almost seems like there is no rebol without such feature. Data 
have to be preformatted some way. I would never use anything but 
string parsing on free-format data. I don't agree that rebol native 
types provide more than 90% of worlds data formats :-)

At least as literals :)

Pekr;  I still don't get the counter argument.  What is the scary 
deal with  load "1 2 3 abc $10,000,000.00" returning a block of [integer! 
integer! integer! word! foreign!]  instead of a syntax error?  Why 
fear this?

load/anyway

Well, I don't know. I just never dared to parse anything non rebol 
via block parsing. You also give very pure example. I have NEVER 
seen written currency so cleanly as this. It can as well be junk 
as 1234.50 CZK ... separated by spaces, etc.

load/whatever

Sure, and it'll still be foreign!   so would 1212.12.1212.12121212.121212. 
  S'okay   still just foreign!   as would  $$$$12@@!@!@#3   just 
foreign!   instead of a syntax error during the make phase.

And tomc, yes,  unrefined load  is a poor choice of example   load/somerefinement 
 would be far better, but I still don't see the fear of foreign!

for me the biggest obstacle is national difference for decimal point 
representation. While your example might be valid for a number, in 
CZ we use comma as a decimal point separator. Is it stupid? Yes, 
of course it is ....

That is also why I asked Carl, if it would be possible to read national 
locale properties from OS, but I can imagine it could get tricky

well no   load/somerefine "$123,45"   would / should  still parse 
as   [money!] with $123.45 as the value, s'okay.

OK, but what do you gain? I would like to know, what is the usage 
case, other than being cool showing someone tricks directly in console? 
:-) You would have to parse the junk! datatype by string parsing 
later anyway, no?

just as today   $123,45  loads as $123.45   I'm ok with that.   REBOL 
reports the type as money! and math won't break.  math (and other 
ops) would reject foreign!  just as it does now for email! or url!

To state my position - I have nothing against adding such functionality 
(if it does not slow central rebol parser). I did not use it, and 
I would feel more safe with string parsing anyway :-) I just need 
Carl to implement Parse proposal enhancements, and even lamers like 
me would be able to create decent parsing schemas :-)

Gain?    load/whatever %kingjames.txt    now I can sort, do counts, 
analyze text files.   If I blindly do this block foreign! would throw 
error on eval, or use in math etc...

In your cases, I do:

result: copy []

foreach line read/lines %kinggames.txt [parse-the-line-and-append-to-result-structure]

I'm aiming to open up REBOL to "all data" analysis and I don't see 
where that should scare normal rebols from going about producing 
good clean parses just as today;  with the addition of a foreign! 
datatype that has semantics of "junk"

yeah parse-the-line-and ... is not code a History Professor may feel 
comfortable writing.   I want REBOL to open up new domains, and I 
don't think this change really hurts existing usage.

But now it's sack time for me and I've broken a promise that I'd 
keep quiet on the issue (for another 2 months ... then I'll whinge 
again)   ;)

OK, I don't mind either way. Talk to gurus, as i can't see the consequences. 
If it does not slow rebol code parser, then it is OK. And as BrianH 
said - 'load is a mezzanine. It can be patched. I think that adding 
one refinement would not hurt us ...

Well, a refinement and a datatype with semantics of junk, power in 
my opinion, scary REBOL breaking crud to others (others that I do 
respect the opinion of), but I can't see the fear of this datatype!

But anyway Petr; have a good day, I'm off

Pekr parse is a hell of a complex programming paradigm.

conceptually even more complex than regular expressions cause they 
are recursive and stacked, when you build real parsers.

the syntax is pretty, but the concept of parsing is like lisping... 
and how popular is lisp... hummm... try learning lisp to your mom...

rebol's litteral value handling within load is SOOOO fast. having 
to build to build your own parser to replicate what load does is 
NOT simple.  we always talk about simplicity, how beautifull it is...

you have to be kidding, right? Even lamer like me can write some 
parse expression. Not much complicated, but can. But I can't write 
a bit of regexp. Any person stating that regexp can be more easily 
tought to our mums needs a medicine :-)

I said the mechanics of it... not the syntax.

Where I had problem with parse was with some recursion, and variables 
not beeing local to the recursion level. That is going to be fixed 
with parse proposal. There are some really nice helpers suggested, 
so if we got them, parse is the king ...

but parsing is a hell of a complicated thing.  on the surface it 
looks easy, then you start trying stuff and the vast majority of 
people are stumped.

I think that if loading non rebol values would make many rebollers 
happy, and if there are no consequences to add such functionality 
to rebol, then there is not reason to actually not have it available 
...

not reason = no reason

I just think that adding some kind of classification to the current 
string type could be really usefull.

What do you mean by classification, please?

when parsing stuff, it would be fun to be able to assign some kind 
of meta tags or internal labels to litterals.

a bit like we can add invisible line-feeds in block.

so that you can assign an additional type to any value.
d

We need something like load/markup.....That splits a string into 
<tags> and "strings". The strings can then be processed separately 
from the tags.

So load/datatypes -- split a string into recognisable REBOL datatypes, 
and other! (aka Junk!)

a bit like saying that series is the super type of both string and 
block.

we could assign our own sub types to anything.

when parsing it could be usefull sometimes, to be able to assign 
a label to a block, so we can leave it where it lay and know later 
on that its a block of some type.

its like adding "meaning" to data, without adding any data to the 
source data.

Maxim - you can do so via added functionality, no? Adding some objects, 
storing them as references to pointed data ...

that means additional transformations, memory management, and in 
other setups, it means your labellin is outside of the data...