World: r3wp

Janko: If you right-click the URL, it says "Copied to clipboard" 
- it means the X clipboard, which you paste from in Linux by using 
middle-click

Izkata: wow .. it works! :)

Oldes: I read the discussion on mailing list. Obviously I agree with 
you (in fact our reasoning is like copied:)

Gabriele interestingly subverted your reasoning by "you can't expect 
REBOL to be able to parse into REBOL values any syntax", but that 
is not the reasoning here :) . Reasoning is simple why rebol isn't 
more consistent and

(pressed the submit by accident).. reasoning is:

If consistency good?

if . is word why isn't ,?
you mentioned that it's because:
>> ,012
== 0.012

but that fails since this also works :)
>> .012
== 0.012

but I know there are more prominent things to change/fix (if any 
will get fixed at all) that I don't realistically expect anything 
changed about this in near future (but that sql dialect would be 
much cooler if it werent for , exception)

index.html is a useful word, index,html is not.

there has to be a place where you draw the line... will you ask for 
$ next? what about #? What about ' ? or : ? or even ; ?

some characters are reserved for a reason. if you're parsing another 
language, use string parsing. LOAD is supposed to parse REBOL, not 
other languages.

' can be used in words like:

>> can't: 42
== 42
>> can't
== 42

Some would argue, comma is kinda the same.

there is a behaviour difference for LAST function on blocks and lists:
>> b: next next [1 2]
>> last b
** Script Error: Out of range or past end  ;which is ok

>> a: next next make list! [1 2]
>> last a
== 2

But it is not same for FIRST
>> first a ;(or first b)
** Script Error: Out of range or past end ;same for both.

>> a
== make list! []
>> last? a
== false

I'd say its a bug with the list! datatype.

I guess so, because reverse is changing the internal position also:
>> a: make list! [1 2 3]
== make list! [1 2 3]
>> reverse a
== make list! [3 2 1]
>> a
== make list! [1]

it goes to last item in the list. But it doesn't work like that for 
block! values.
>> b: make block! [1 2 3]
== [1 2 3]
>> reverse b
== [3 2 1]
>> b
== [3 2 1]

There is a bug report on Rambo for reverse on list!
http://www.rebol.net/cgi-bin/rambo.r?id=4420&

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))