World: r3wp

that reasoning doesn't invalidate my initial question

 - I do not think it is reasonable to try to "invalidate" your initial 
 question: "why is , not valid word?"


The question is perfectly valid, and, in my opinion, the correct 
answer is, that there are too many conventions out there stating 
that , is not a word at all

I guess, that Carl, when designing REBOL, especially took into account 
the fact, that the #"," character is usually interpreted as a delimiter.

so maybe we would like to use it as some special meaning delimiter 
in our wierd dialects? like he uses #"|" in parse dialect, maybe 
in some dialect that carl didn't predict 10 years ahead #"," would 
be more elegant delimiter?

Max's proposal above is actually compatible with the "the #"," character 
is a delimiter", but, unfortunately, there are other issues making 
it too complicated to be generally useful.

that is all was saying, why make an exception and forbid.

'like he uses #"|" in parse dialect' - That is an error, in the Parse 
dialect, the | word is used as an operator keyword, not as a delimiter.

I don't know the definitions of delimiter and operator. Isn't delimitors 
sometimes operator that concatenates things to a list?

A delimiter is "used to specify the boundary between separate, independent 
regions in plain text or other data streams". That means, that when 
using e.g.

    a,b


, and using the #"," as a delimiter, we get just two words a and 
b, the #"," being used only as a delimiter separating the words, 
not having any additional meaning.


As opposed to that, the | word in the Parse dialect is interpreted 
as the "choice operator".

(and the #"|" character is not used as a delimiter at all)

but doesn't the "choice operator" "specify boudaries between separate, 
independent" choices? :)

No, if you write

    a|b


you get just one word, i.e. the #|" character is not used as a delimiter 
at all

but we are talking about usage in a parse where #"|" (single character) 
is a word which means an operator in that dialect

In fact I don't even know what are we talking about. You obviously 
deferentiate between operators and delimiters, which is your perfect 
right and I don't see such hard difference which is mine.

Parse dialect examples:

    a: #"a"
    b: #"b"


    parse "a" [a | b] ; == true (the | word used as the choice operator, 
    not as a delimiter)

>> parse "a" [a|b]
** Script Error: a|b has no value
** Near: parse "a" [a|b]

no delimiting at all as far as the #"|" character is concerned

true (the | word used as the choice operator, not as a delimiter)
 

yes, I said I agree with you it's used as a operator in *parse* dialect 
, and it's nothing in *do* dialect.. 

I don't know what you are trying to show with second example.

what are we discussing about now exactly?

As I see it, we were discussing your initial question.

My understanding is that our last discussion was that you say it's 
a different game because "," is a delimiter and "|" is an operator, 
I say I don't see mayor difference... who f* cares .. you think your 
way and I'll think my way. I just work on hayfield for 2 hours and 
this "," issue is the smallest of things I care about. Even if I 
limit on Rebol it's unimportant. Especially in the light that R3 
(which fixes tons of issues I have with rebol) might not ever materialize 
for all I know.


I respect you, you wrote closure (and a bunch of other wizard level 
stuff) for R2 which I am ***very*** happy I can use, and I still 
hope I will get your Bindology when I get time to read it. Let's 
move on.


Same for Gabriel. But if you will keep writing why "," must be forbidden 
and I will see (what are in my oppinion) flaws in your reasoning, 
I will reply with my counterpoints. If I have time.

I can do string parsing in any language with getchar() while()
 - oh well, but PARSE is no getchar(). :-)


You guys make it sound like block parsing is an order of magnitude 
easier than string parsing. Actually, it's the same, if you can get 
block parsing to work, you can definitely get string parsing to work 
as well. The level of difficulty is exactly the same. (Actually... 
I think I could write a translator from a block parsing rule to a 
string parsing one.)

doesn't the #

," now behave the same in all cases as #"." (in numbers) except that 
it's forbidden?" - btw, as I said above, I think the only reason 
. is not forbidden is because of the use case in file! value paths.

You guys make it sound like block parsing is an order of magnitude 
easier than string parsing. Actually, it's the same

That I don't agree with. Examples:

>> parse [42]Ê[integer!]
== true
>> parse "42" [integer!]
== true		; seem to be as easy, but
>> parse [42 #42 [a b c]] [integer! issue! block!] 
== true
>> parse "42 #42 [a b c]" [integer! issue! block!]
== false			; it's not

'you say it's a different game because "," is a delimiter and "|" 
is an operator' - I prefer to speak for myself

'who f* cares' - I thought you did: 'why is , not valid word?', but 
taking the 'who f* cares' into account, I just have to admit that 
I was fooled by the form understanding it as a question

Ladislav: I said "My understanding is that our last discussion was"

Geomol: that example is a bit silly, isn't it? IF all what is in 
the string is REBOL values, THEN you just use LOAD and block parsing.


But, even in a case like above... You just have to define the rules 
for integers, issues and blocks, which are not more difficult than 
any other parse rules, and can be done *once and for all* and put 
in rebol.org or in whatever other place for anyone to use.

Imagine a string, where some of it is loadable, some isn't.

String parsing is not as easy as block parsing.

What makes it harder is not necessarily the level at which you're 
parsing, but the fact that you have to design the language you want 
to parse. The mechanics aren't any harder. That may be Gabriele's 
point. If you want to parse something that is *almost* REBOL, the 
design work is almost done. :-)

Geomol, I don't see how something like (simplified):

integer-rule: [some digits]
issue-rule: [#"#" some non-blanks]
value-rule: [integer-rule | issue-rule | block-rule]
block-rule: [#"[" any value-rule #"]"]


is "not as easy as block parsing". Even if you had to spend one week 
to complete a REBOL parser, one person has to do this once and then 
everyone can use it.


But, if you have a string that is not really REBOL, most likely it'll 
just have integers and strings and maybe words. Most likely the strings 
won't be escaped as REBOL does so you need a custom parser anyway. 
I don't see how this can take more than one day to implement, and 
I've written REBOL parsers in languages that don't have PARSE.


I'm starting to suspect that the people claiming that this is hard 
have simply never tried...

Let me try to open your eyes, so you may see it then.


E.g. in [some digits], how is DIGITS defined? Using charset, which 
again make a bitset!. The user has to deal with and understand those 
constructs. That is adding complexity to string parsing, so string 
parsing become more complicated than block parsing.

Maybe our understanding of what's "easy" is different?


If your last sentence is targeted at me, then you're way off. Look 
at my different projects, that's based on parsing, like NicomDoc, 
postscript, xmlrpc, 6502 ASM, and probably a few more, I can't remember 
off my head.

Oops, "xmlrpc" should have been "RebXML".

Links to some of those projects:
http://www.fys.ku.dk/~niclasen/rebol/language/asm6502.r
http://www.fys.ku.dk/~niclasen/nicomdoc/
http://www.fys.ku.dk/~niclasen/postscript/
http://www.fys.ku.dk/~niclasen/rebxml/rebxml-spec.html

Related; bparse.r is REBOL block parsing as a function:
http://www.fys.ku.dk/~niclasen/rebol/libs/bparse.r

Why didn't I make a string parse function yet?
Because block parsing is easier than string parsing. :-)

Some of those projects use blocks parsing, some string parsing.

the mental mindset in completely different when doing block vs string 
parsing.


in my experience the length of implementing any parse rule which 
can be LOADed and then block parsed is always much simpler than the 
same rule which is done using string parsing.

I agree with Geomol that block parsing is much more easier than string 
parsing, especially when you are a newbie. That's also the main reason 
why REBOL/Flash dialect is using block parsing as well. The true 
also is, that today, when I'm more experianced, I would use different 
ways probably.

Also I can clearly understand, why Janko needs the delimiter in his 
dialect. It simplifies a lot when you can delimit values, where some 
of the values can be functions requiring arguments. Without the delimiter 
you must add pretty large complexity which will provide info, how 
many args require each funcion.

I don't like #'." as a delimiter imho. I would use #"|" instead when 
#"," is not available.

String parsing under REBOL is the reason, many people ask, why regexp 
is not available. It just shows that parsing is by default quite 
hard to do, especially, when the underlying mechanism for parsing 
never has been described properly. Gabriele's issue is that he is 
just too good at it, so he doesn't see a problem with it.

the underlying mechanism for parsing never has been described properly
 - this is false

Janko needs the delimiter in his dialect

 - in fact, he requested the #"," to not behave as a delimiter, which 
 defies his goal in a way

Geomol, so your point is, that since string parsing uses bitset!, 
which is not used in block parsing, then it is much more difficult 
to do string parsing?

Henrik, my problem is that is see block and string parsing as equally 
difficult, especially for newbies that have probably never heard 
of the concept, and that have no experience in designing languages, 
BNF rules and grammar parsers. if you can get block parsing to work, 
then you figured out the hard part already, and can get string parsing 
to work with only minor extra effort.

String parsing may be hard, but so is block parsing.

BNF rules

 - I do not think it is necessary to know anything about them, since 
 REBOL PARSE is, in fact, an analytic grammar, unlike BNF

Gabriele, that's one point, not the only point.

this is false

 - please point to the exact documentation that describes in depth 
 what parse does.

http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Parse

The problem is that it only describes what each command does in PARSE. 
What I really would like, is a source description of PARSE to learn 
how the "machine" works. That makes it much easier for me to have 
a model of PARSE in my head, rather than having to learn PARSE by 
rote.

What I really would like, is a source description of PARSE
- that is not what "complete description" means.

If you know the source, you kinda know all there is to it, right? 
So that's pretty complete, I would say.

when you have the source, you can generate the complete description