World: r3wp

Did you even try to realize what you would need to do to adjust REBOL 
to treat #"," as whitespace?

here comes my allowed horrible example: 
>> a: 1000
== 1000
>> a=1.0|a: 100
== 100
>> +a: 50
== 50
>> a+2*: func [ a b ] [ a + b ]

and the resulting code that makes all sense:

>> a=1.0|a + a+2* a +a
== 1150

That all sounds like a rather theoretical discussion. If you really 
need to load data as "REBOL" and the only thing that prevents you 
from using LOAD is some additional #"," you'd like treated as whitespace, 
just preprocess that data using REPLACE/all data #"," #" ". Problem 
solved.

Meaning. I don't need #"," to make confusing code, if I really want 
to.

Andreas, almost... the issue being ignoring this in strings  ;-)

Andreas: "Problem solved" - yes, for you, and for me, but I doubt 
it is what is requested, in fact.

Well, if you want to discern occurrences where you don't want to 
tread #"," as whitespace, you'll have to write your preprocessor 
as a string parser, as Gabriele already mentioned at least twice.

Andreas:  for my particular case, I just asked why #"," isn't word 
as #"." is. I needed it to be word. And I am embeding that code/DSL 
with rebol code (It's not a separate file or string) so I can't string 
replace.


But I don't care, OK. I already used . instead and it's not perfect, 
but it's ok for me. I am just replying on what people here write 
( I think ).

Janko - you do not understand what I wrote, as it looks. I do not 
mind to "forbid" something. What I do mind is to "íntroduce" something 
that does not make any sense.

There's always a tradeoff how far in-situ dialects (i.e. embedded 
DSLs) can go until they clash with the host language's needs. E.g. 
Factor is very picky about whitespace.

Janko: you can, in general, use string parsing for EDSLs. Use {..} 
to delimit your code blocks instead of [..], and a different set 
of lexical limitations will apply.

Janko: "I needed it to be word." - it is obvious, that your requirement 
is in conflict with Maxim's requirement. I do not doubt it to be 
in conflict with requirements of other users as well.

the problem here is that allowing the "," as whitespaces changes 
absolutely nothing in current REBOL, a part for a subjective style 
decision.

wrting string parsers IS NOT easy.  even for experienced parsers 
like myself.  its tedious, error prone, and makes a simple job a 
lot more complex, when you know that 90% of the time, those pesky 
"," are all that stand in between you and easy to use native rebol 
data .


did I also mention that LOADING data is blazingly fast, even when 
compared to using parse?

I will repeat: I just asked why #"," is treated differently than 
#"."? I didn't see technical reason for it

Because it is no technical decision, but a design decision.

Maxim, having #"," as whitespace changes quite a bit: 1,2 is a valid 
decimal!.

I|MHO its because in other languages its treated as a delimiter... 
so it would be confusing to let it be a word in REBOL.

in REBOL " " is the main delimiter (with a few others)

In Czech or German, 1,2 is a number, the #"," being a decimal separator, 
not a delimiter.

yes I see, it's a design decision. And then Gabrielle and tried to 
show why , should not be in hands of programmer and I replied with 
my views. So I don't see a problem

(and Ladislav and ..)

andreas, unfortunately.
  

though I understand that "," is the decimal notation point in some 
countries, in programming languages its always "." 


to allow both always stood out as a very bad design decision.  its 
like if Carl added decimal point as way to make its use later on 
impossible... enforcing his style decision within a syntax rule.

("," decimal point)

Max: "decimal notation point" - that is an incorrect notion. As noted 
above it actually is not "decimal notation point", it is a "decimal 
separtor".

err: "decimal separator"

that is what I meant.

I think it's technically really a radix point (which is commonly 
called a decimal point), but you (Ladislav) are the mathematician 
:)

but anyways... its a moot discussion as Carl fears commas like the 
plague so there will never be a way to handle them  ;-)>

(Called a decimal point only if your radix is ten, of course :)

Well, Andreas, since it is not a "point", and since you mention "radix" 
(which generalizes the separator to different radixes than 10), in 
general it can be called "radix separator", not "radix point".

But that is hardly relevant in this case.

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.