1. commabominations
- Posted by George Henry <ghenryca at hotmail.com>
Jan 20, 2001
-
Last edited Jan 21, 2001
This came out in a recent personal message. Thought I'd air it to the list
as well.
In natural language, commas are used to separate items in a list. Fine and
dandy. In natural language we do not frequently modify lists that look like
this: { A, B, C } to look like this: { A, B, C, D } or this:
{ A, B }. Not as frequently as we do in programming, anyway.
Now suppose we did. We might be tempted, in order to avoid juggling commas,
to end all our lists with ", etc."
The point is this:
The way Euphoria and most other languages treat/use/handle commas leads to
syntactic abominations, such as I have seen in the latest win32lib, and (I
report unhappily) have even adopted myself:
<excerpt from win32lib_full.ew>
integer
riCleanUp -- the "clean up" routine
, ri_getClientRect -- routine_id for getClientRect()
, riPause -- routine_id for Pause Key processing
, riBreak -- routine_id for Break Key processing
</excerpt>
This should not happen, should not be necessary. Commas are not used that
way in natural language. It's ugly.
Okay, then what's a reasonable solution? I have actually seen a C compiler
that let you do this, in initializers: { A, B, C, } which is using the comma
more as a terminator than as a separator, or it is blurring the
terminator/separator distinction. Either way, I'd like to see something of
the sort allowed by Euphoria (or any language I use on a regular basis).
Pascal used the semicolon as a separator between statements, but did not
complain of "syntax error" if you used one just prior to an "end." Same
idea.
How about just a generic keyword "end" that means nothing, but lets you end
a list with ", end" - as in:
constant
alpha=120,
beta=26,
gamma=1382,
end
integer
riCleanUp, -- the "clean up" routine
ri_getClientRect, -- routine_id for getClientRect()
riPause, -- routine_id for Pause Key processing
riBreak, -- routine_id for Break Key processing
end
so you can add to or subtract from the list without adding and deleting
commas, and without sticking the commas in front of the identifiers - thus
reducing readability (similarity to natural language)?
You don't have to break any existing code to implement this. ", end" would
be strictly optional at the end of a list of constants or variable names.
(I'd also like to see a trailing comma before the closing curly brace
tolerated in a sequence.)
This may seem a small thing, but "the devil's in the details," and that
little comma has horns and a tail, as far as I'm concerned.
What do y'all think?
George
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
2. Re: commabominations
Regarding Rett's suggested use of "null", like all made-up variable names it
would tend to be redeclared, which is an error. So what do you do, reach for
names like null01, null02, etc? Sorry, I don't find that approach satisfying
either, although I like the word "null" in this context better than the
others that have been mentioned.
George
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
3. Re: commabominations
At 05:03 21/01/01 -0000, someone wrote:
<snip>
>All true, but it becomes burdensome:
>
>global constant X0 = 42
>global constant X1 = 305
>...
>global constant x127 = 61
>
>and like that. That's why we were given the ability to put 'em in a
>comma-separated list in the first place.
</snip>
So:
constant X1 = 27, X2 = 31, X3 = 35, X4 = 39, X5 = 43, X6 = 47, X7 = 51, X8
= 55, X9 = 59, X10 = 63, X11 = 67, X12 = 71, X13 = 75, X14 = 79, X15 = 83
if more readable/editable than:
constant X1 = 27
constant X2 = 31
constant X3 = 35
constant X4 = 39
constant X5 = 43
constant X6 = 47
constant X7 = 51
constant X8 = 55
constant X9 = 59
constant X10 = 63
constant X11 = 67
constant X12 = 71
constant X13 = 75
constant X14 = 79
constant X15 = 83
Ok I totally concede that this is simply a style preference but,
personally, I have always gone for the:
constant X1 = 27
constant X2 = 31
constant X3 = 35
format simply because a later cut/paste/edit to the source is less likely
to trip things up if the first and/or last item is involved.
Generally my solution to this whole "separator or terminator" issue is to
avoid separator or terminator issues by ignoring the facility. If you
can't trust yourself with a sharp knife then don't use it. I can't so I
don't.
And yes I'd probably be happy living in a cave too :-]
Regards,
Andy Cranston.
>
>Given the choice of declaring each item separately or dealing with the
>irregularities in the use of commas, as is often the case I might be willing
>to do more typing if it will make life easier overall.
>
>Glad you broght up that alternative.
>
>George
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
