World: r3wp

Given the subject of this group, I figured that knowing *why* these 
decisions were made might be helpful :)

yes, it's good to know and it is true that rebol can be very fastly 
typed when you get into zone (although I don't have US kyb layout)

What intrigues me is, that hardly anybody thinks it makes sense to 
radically change e.g. the syntax of C or other languages, that are 
much more "rigid" than REBOL. Knowing how flexible REBOL is, there 
are (IMO) too many people trying to make it "more flexible". Did 
they really consider whether such an effort would be reasonable, 
giving us something worth it?

You really need to consider that there already *are* valid reasons 
why REBOL looks the way it does.

And, BTW, I still don't understand, why the #"," character being 
handled differently than e.g. the #"'" character is "inconsistent". 
For me, there is not inconsistency if we decide to handle some characters 
differently than others. Similarly, I am content with the #"[" and 
#"]" character handling. I do like that the characters are handled 
as delimiters, not as "regular characters",since it enhances readability.

For me, the

    f (a,b + c,d)


example is exactly the case which is not worth having in REBOL taking 
into account how much "nonstandard" it would need to be.

Similarly, the 

    a[b c]d


already has some "meaning" in REBOL, and I do not think anybody is 
able to come with a good enough reason for me to agree it should 
be changed.

the problem with "," is the expectations based on what it means in 
other languages, in rebol its replaced by the space.  


myself, I'd just treat them like whitespaces and be done with this 
endlessly recurring debate.   Its just a style issue, it *may* help 
readability, nothing more... just like when we manually control the 
new-line property within blocks.   


Carl and most of us hate using "," (in any language) but sometimes, 
it really would help readability on some long expressions, without 
having to use parens which actually have a cost and may have side-effects 
(like within compose blocks).   


Peer negative pressure, is enough to have this character very rarely 
(and/or wisely) used anyways.

even though I can agree, that the typographical rules are, that the

    a[b c]d

should be prerably written as

    a [b c] d

it also means much more data formats can be read natively by rebol. 
 which is not a negative thing either.

As Gabriele already noted, you cannot "read data formats" as "native 
REBOL" anyway, so such a goal is not reasonable.

Ladislav, are you trying to say you can't write wierd code with characters 
that are "allowed" now with f (a,b + c,d) ? :)

(I mean if you really want to?)

Still don't understand your question

if you show example where #"," is confusing then #"," should be forbidden 
(you the programmer can't make a choice yourself). I am sure I can 
make confusing examples of code with stuff  that is allowed if I 
tried. Look I am not fightinh this, just reacting to what you say. 
I have no hard feelings in game.

(I am trying to explain what I meant).. let mi find you a wierd alowed 
example

well, considering that many times, this simple little whitespace 
equivalency would have reduced coding file parsers by half the time 
or more.  I do think its reasonable.   :-P


not allowing "," to be a whitespace is a simple Carl pet peeve, he's 
stated it before (and often ;-).  


The only result of this is that it makes REBOL less useful as an 
integration tool.  Allowing "," whitespaces has no objective downsides. 
 its a case where there are no practical reasons against, only a 
subjective decision which goes against REBOL's simplicity statement. 
  


It's like saying, lets make *sure* our data loader can't use ANY 
data out there.  yeah, that's really reasonable.

Maxim, your idea to make the #"," character a whitespace character 
is interesting. But, you need to realize, that the above proposals 
requested a different behaviour. Moreover, no language known to me 
treats the #"," character as a whitespace.

For me, there are too many disadvantages to handling the #"," as 
a whitespace character, sorry.

((just btw: Ladislav: Clojure treats #"," as whitespace))

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.