bracing for a firestorm

[Grant Edwards]

On Tue, 22 May 2001 15:27:11 +1200, Greg Ewing <see at my.signature> wrote:
>Grant Edwards wrote:
>> 
>> I'd much rather there were tuple delimiters.
>
>Well, it would be fairly easy to change the grammar
>so that parentheses were always required around tuple
>constructors. But then you'd still have a special
>case for 1-tuples.

If parens were tuple-delimiters, then (foo) would be a 1-tuple.

But since parens are also overloaded for two other things,
making them tuple-delimiters is problematic.

>Fixing *that* would require a dedicated set of brackets just
>for tuples.

Yup.

>Maybe with Unicode we'll one day have some more types of
>brackets to play with -- ASCII just doesn't have enough!

Exaclty!  We need at least two more sets: Assuming we leave
parens for expression grouping, we need another set of
delimiters for tuples and one for the
function-parameter-delimiter-and-postfix-call-operator.

Commas would be used to seperate an unabiguously delimited
series of "things".

For example:

 []  [foo]   [a,b,c,d]            lists 
 {}  {foo:1} {a:1, b:2, c:3}      dictionaries
 <>  <foo>   <a,b,c,d>            tuples [1]
x() x(foo)  x(a,b,c,d)            function calls[2]

[1] OK, those _look_ like the less-than, greater-than
    operators, but in _my_ world they would be another set of
    delimiters and wouldn't be the same characters as gt/lt.

[2] Same here -- these wouldn't be the same characters as
    parens used for expression grouping.  

This may sound like I'm headed down a slippery slope towards
APL where all conceivable keywords and operators are a single
character, but I'd be happy with just a couple more sets of
delimiters.

Honest.

-- 
Grant Edwards                   grante             Yow!  Do you have exactly
                                  at               what I want in a plaid
                               visi.com            poindexter bar bat??