World: r3wp

It's not, but it's kinda interesting.

To be a little more constructive (hopefully): This whole debate started 
because I had an idea to try making my backend programming system 
even more elegant. So I did this as an experiment and so far I haven't 
meet any problems (it automatically creates prepared statements so 
it's safe without you having to make ?'s and matching values). "dbfunc" 
accepts some validation dialect I have instead of arguments, as you 
can see content of functions is normal SQL issues are turned into 
prepared statement values... 


This is example of the code: http://paste.factorcode.org/paste?id=2321

( normal SQL with . instead of , )

easier parser: adding , does not make the parser easier. It would 
probably be trivial to allow it *inside* a word, ie. "a,b", but it's 
going to be more complicated to handle , alone and then worry about 
its usage within numbers.


f (a.b + c'd) - that will either immediately look weird to anyone 
used to other languages, or be easily seen as passing one argument. 
f (a,b + c,d) would instead be read as f (a) (b + c) (d) which it 
is not. This is a weak argument in the sense that people knowing 
REBOL will probably have little problem with this... but REBOL is 
"weird" enough already. :)


expandable: right, indeed you have string parsing, and you can do 
whatever you want with it. do you expect other languages to parse 
whatever is thrown at them? no they don't. you have to write the 
parser.


having anything in words: it remains to be proven whether this makes 
things better or worse. i suspect "worse".

Gabrielle and tried to show why , should not be in hands of programmer 
and I replied with my views

 - I'm not saying that it should not be in the hands of programmers, 
 I'm saying that from the point of view of the designer of the language, 
 "," creates more trouble than it is worth (it is worth basically 
 nothing :).


It can be argued that . should be removed as well. I think the only 
reason it's there is to allow this:

dir: %some/dir/
file: dir/file.html


notice that "file.html" is actually a word there. If I were to guess, 
I'd guess that Carl initially disallowed . in words, then added it 
because of the above use case. If such a strong use case existed 
for ",", then it would probably be added as well. Instead, Carl decided 
to "reserve" it for future use (eg. new datatypes).

Max: how can you argue about rebol handling more kinds of data formats 
(eg. 1-Jan-2011, 2011/01/01, etc.) to make parsing strings easier, 
and then argue that 1,2 should not be allowed?

This whole debate started because I had an idea to try making my 
backend programming system even more elegant.

 - actually, this is a recurring question / debate. We've been going 
 on about this with Oldes for like a decade. ;) So, it may seem to 
 you that we're overreacting, but it's just that this is a "common 
 issue".

I'm looking at 'Load being a data format interpreter, not a human 
text loader.  in all (or just about) computer languages and file 
formats, the dot is used for decimals, not the point... specifically 
because the "," is always used as a delimiter.      I find it a bit 
unfortunate that Carl decided to go against the complete CS industry 
on this.  that's all.      a large part of REBOL is based on practicality, 
not correctness. 


this is one case where reason went towards correctness (a principle) 
 rather than practicality (how can it be more useful in the majority 
of cases).

hehe....   not the point  == not the decimal.

Max, no, Carl always went toward humans in *all* cases. look at dates 
and times. look at the ' separator in numbers.


Whether this is a good idea or not is a separate discussion, but 
I don't see any inconsistency here.

> more complicated to handle , alone and then worry about its usage 
within numbers


doesn't the #"," now behave the same in all cases as #"." (in numbers) 
except that it's forbidden?

> (it is worth basically nothing :).


well not to you, but it's obviously  worth something to me and oldes


> right, indeed you have string parsing, and you can do whatever 
you want with it.


I can do string parsing in any language with getchar() while(), conditionals 
and ... That means any language from q-basic up.

(I mean forbidden in word context)


what if we say, it is like it is, we can't change it anyway. we also 
don't have to justify or dejustify it because it's no gain in it

it's obviously  worth something to me and oldes

 - I am pretty sure it is not. You should be honest and admit, that 
 you actually do not need words like

    a,b

please Ladislav, are you putting words into my mouth and not giving 
me the right to decide for myself what is worth something for me?

and where did I say I need words like a,b?

Aha, you are telling me, that you don't need words like

    a,b


? I was at leat guessing, that your request was worth it for you 
to specify it completely enough: "in word context" is what you requested 
above isn't it? But, if that is not what you want, then I cannot 
help but sum up that it is not worth to even specify what it is you 
propose.

in my specific dialect I wanted to use , (single char) as a word. 
Now I use . instead of it. It's ok solution..
http://paste.factorcode.org/paste?id=2321-- this is the example

But, what about the "in word context", how am I supposed to understand 
that?

maybe I didn't express my self exactly, I don't know how to call 
this officially.  For example #"." #"_" #"-" can be used as a word 
or a part of the word #"," can't. This is what I meant by "word context"

OK, you are being honest and admitting that you don't need words 
like

    a,b

That is OK with me, and I can stop with that finding.

ok , but I think that reasoning doesn't invalidate my initial question. 
but there is no reason we have to agree on everything.

so, peace :)

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.