World: r3wp

Geomol, right, so, should we also allow # inside a word? Why not 
allow even [ then?


You have to draw a line somewhere, both to simplify the parser, and 
so that the language is readable. The , has a special meaning in 
basically every language, so it's hard to know what the consequences 
of allowing , would be, even assuming the parser is not affected 
by it.

ie. imagine having:

    f (a,b + c,d)

I suspect that'd confuse the hell out of most people.

You could trivially change the parser in Topaz to allow [ and ] inside 
words, and then write something like:

   a[b c]d


but, is that a good thing? So, what's the actual purpose of allowing 
a,b to be a word? So far, the only purpose has been "to parse other 
languages as if they were REBOL". That's not a good purpose, because 
they are *not* REBOL. If you need to parse other syntax, you need 
string parsing. block parsing is for REBOL dialects.


The only sensible reason I can imagine for , to be a word would be 
to use it as an operator so that:

    a , b

means

   also a b


but that has the same readability problems of using . as a "end of 
command marker" in dialects. a nice idea in abstract, but terrible 
in practice.

Gabriele: this discussion, at least from my side is totally futile. 
Futile in more than one way. 1 I am nobody in rebol-lang and nothing 
will change because of my oppinion. 2. it's a fact you are 10x better 
rebol programmer (and probably general programmer) and I know it, 
so there can even be no ego-goal here where I can prove I am more 
right than you (eg. smarter) :)

I can just take it as a game, and land some easy punches on places 
you exposed up-there :)

for example, you mention drawing the lines:
- I prefer consistency
easier parser
- consistend languages are often easier to parse 
various cases where it might look wierd
- f (a.b + c'd)  ~ is this better? this is valid now :)

allowing

- I like languages where creator makes a conceptually focused, clear, 
expandable, consistent "engine" and we can grow and combine that 
beyond what language maker was able to initially imagine.


This Guy (:)) talks about something like this: http://video.google.com/videoplay?docid=-8860158196198824415


REBOL is one of very few languages where this actually is possible, 
another language like this is Factor.


You ask if this could be a word a[ . And in Factor this is the case, 
and they also found a concrete use for this specific case. It's been 
more than year so I have to check where I have seen it. (Factor has 
compilation stage (live compilation too) so they have compile time 
macros where they can extend syntax in various ways).

I know they use it in peg parser [[ ]] means "special" block, but 
it's all done on the Library level

the use of weird constructs is something very usefull in macros. 
 


In C, I'd love to be able to provide more expressive macros, but 
the language still expects macros to be defined as valid C so its 
very hard to extend the syntax or semantics of C.

http://docs.factorcode.org/content/article-fry.html-- example where 
they use '[ parsing word 

http://paste.factorcode.org/paste?id=1723-- example of peg dialect

http://docs.factorcode.org/content/word-H%7B%2Csyntax.html -- I couldn't 
find the samples with [ I was looking for but I found more basic 
samples where they use H{ word to start hashtables V{ vectors and 
so on..

- about easier parser ~ consistency: 

afaik , and . are only used in decimals and they behave the same 
,001 == .001 so it means if , wasn't forbidden parser code would 
be the same for both, so it would be simpler


Factor can use any character as part of the word because it has a 
simple rule that every word must be separated with a space. Which 
is one thing I would love in a rebol-like language, because it brings 
clearness to coding and simplifies parser.

because of all this factor programmers developed various nice conventions 
where they use ! >> to better show what is going on: like int->string 
 or words that get values out of tupple (object)   person name>> 
.. etc (it's been more than a year since I did anything in factor, 
rebol replaced it)

well, nothing is ideal for all. I just hope I see R3, Red or Topaz 
in near future, with ot withouth ,: 1 :)

A lot of the syntax features of REBOL were specifically chosen, as 
opposed to the characters used for those features in other languages:

1) To be easier to type on a US English keyboard without having to 
use the shift key as much.
2) To be physically easier to read quickly.


The first means that REBOL is easy to write quickly even though it's 
more verbose than many other languages; it's just fast to type. This 
is why we use [ ] instead of ( ) or { }, lowercase identifiers, and 
- instead of _. The second is why we use / instead of . for path 
separators, and don't make the difference between . and , that important, 
because they are difficult to tell apart without slowing down your 
reading speed, and why more spaces are required between elements 
than are required in many other languages. This makes REBOL easier 
to debug and understand.


There's a ticket for the comma issue http://issue.cc/r3/537which 
also applies to other characters, but that ticket is likely to be 
dismissed. If the ticket were accepted, REBOL would be much more 
difficult to read and debug, which would make it slower and more 
awkward to program in. Not a good tradeoff.

No problem, I don't want to ruin anybodies rebol, and there are more 
important things to make fix probably :)

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.