why ; ?

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:fvt3r2$2qfj$1 at digitalmars.com...
> Walter Bright:
>> Those things are fine for scripting language programs that are fairly
>> short (like under a screenful). It gets increasingly bad as the size of
>> the program increases.
>
> You may look at Zope (written in Python), that codebase is a bit more than 
> a screenful long; so evidence shows you may be wrong.
>

Just because a large program *has* been written in such a language doesn't 
mean it's a good idea in general. I could write a large mission-critical 
program in Perl or a graphics library in brainfuck if I really wanted to, 
just like a builder could put up a house by using a big rock instead of a 
hammer. Still doesn't mean it's the right tool for the job.

> Note that the "auto" of D too removes redundancy, and once it has caused 
> me a little bug, quickly fixed, I think "auto" is very useful still.
>

I'd argue that the metric of "with/without redundancy" is a little bit 
misleading, simply because we can all come up with obscure counter-examples 
(ex: A language that requires you write an exact duplicate of every source 
file, just like when creating a password. Wheee!). The way I see it, the 
real issue is whether the alleged productivity enhancement helps the 
programmer make mistakes, or helps the programmer catch/avoid mistakes. 
Typically that takes the form of some sort of redundancy, but the key is 
"Mistakes: Nurtured Or Inhibited?". That's just the way I see it, anyway.

>> How should:
>>    f()
>>     *g()
>> parse?
>
> Like this:
> f();
> *g();
>
> That's a call to f() followed by what it seems an error.

Depends on the specific manner in which semicolons are made optional. If 
they're just flatout made optional by having "end-of-statement" somehow be 
inferred by statement semantics, then the code is totally ambiguous (But I'm 
not sure anyone was really advocating this method anyway, were they?) If, 
however, newline either becomes the new "end-of-statement" or shares the 
"end-of-statement" role with semicolon, then yea, it gets interpreted as two 
unrelated function calls, the second of which is attached to a unary prefix 
"*" operator. In the case of newline being a/the "end-of-statement", then 
multi-line statements would be either impossible, or require a "C 
Macros"/"Visual Basic"-style symbol for "continue statement on next line" 
(which is perfectly doable, but not something I'm personally a big fan of 
for reasons I mentioned in an earlier post in this thread.)

Maybe I just stated the obvious there, I dunno. But I thought it should said 
that there are those different possible meanings for "optional semicolons", 
each with their own implications.