8-Feb-2010 - Plans for A98 with Host Kit changes [0307]
If you have inputs regarding the R3 Host Kit, please make sure we know about them. Actually, it would help if we can get someone collect and sort developer comments, notes, and any changes... otherwise something may get missed. This includes inputs/changes on the R3 makefile (e.g. Kaj's feedback). The sooner we get the list organized, the sooner we can get A98 out.
Don't post the list here, upload it as a text file to the R3 Chat #358 topic "R3/Plans/Priorities". (Reminder: To post a file use the submit command while within the 358 topic.)
6-Feb-2010 - Comma as a delimiter in some special cases? [0306]
As you know, REBOL does not use commas. This design decision is critical to the foundation of the language.
In REBOL we write:
[1 2 3]
not:
[1, 2, 3]
Why? Simple, because we want to write:
[1 + 2]
not:
[1, +, 2]
Think about that carefully. In REBOL data can be code, and code can be data. Commas would prevent that concept from working properly. This property makes REBOL quite special and unique in the world of programming languages. So, it's fundamental.
Now, ticket #537 requests a change to the lexical analyzer to give higher strength to commas. Several people have asked for it over the years. What's desired is if someone provides data in the form:
a, b, c
We can easily use the REBOL scanner to parse it without too much trouble.
I spent some time today looking into this request. It's possible, but non-trivial.
While comma doesn't have any special significance in the lexicon, it is used for non-English style decimal points... worldwide. That is, in REBOL:
1.23 = 1,23
People in the USA freak out on that, but if they travel to say, Paris, after the initial shock, they get the idea. I suppose it works the opposite direction as well.
Anyway, comma is not a delimiter in REBOL, it's just a special character used for numbers.
Now that all that's clear, can comma be made a bit stronger to act more like a delimiter? Perhaps. But, we'd need to resolve this ambiguous case:
[abc,123]
Which of these lines would be the correct result?
[abc 123]
[abc 0.123]
**error: comma found in expression
Now, what happens if we write:
[abc,123,456]
Hmmm. You begin to see the problem, and it's non-trivial because comma means two different things here.
So, after some thought, I think we're better off leaving such lines to be processed as strings by parse and keeping the REBOL lexical analyzer as it is.
However, we do want to allow this common markup usage in a sensible way:
>> [<b>word</b>]
== [<b> word </b>]
So, that's even more tricky to scan.
Now, all this being said, we know there are a few minor bugs related to arrows in the scanner. They are listed in the R3 CureCode bug database, and they will be fixed.
For example, we need to allow lit-word quoting of arrow words:
>> if word = '< [...]
** Syntax error: invalid "word-lit" -- "'"
** Near: (line 1) if word = '< [...]
But, I simply wanted to point out this issue, so it is understood that arrows are not general-usage word characters.
