Long names are doom ?

[John Roth]

"Rainy" <sill at optonline.net> wrote in message
news:slrn9gvetd.4j1.sill at sill.silmarill.org...
> On Sat, 26 May 2001 00:51:42 -0600, Andrew Dalke <dalke at acm.org> wrote:
> > Nick Perkins wrote:
> >>what if you wanted to name, say, a function
> >>with a string so that you could include spaces?
> >  ...
> >>...just a silly idea.
> >>ok, i'll go to bed now.
> >
> > Something like that came up last year, with
> > the proposed syntax of
> >
> >   obj."attribute with spaces in the name"
> >
> > As I recall, people thought it interesting, but that's
> > as far as it went.  I don't think there were any
> > definite implementation reasons against it.  But no one
> > could get a solid reason to have it, and for those
> > few cases where that functionality was needed
> >
> >   getattr(obj, "attribute with spaces in the name")
> >
> > works.
> >
> > BTW, in your proposal,
> >   fn['my special function']()
> >
> > the [] syntax could be confused with list/dict lookup.
> >
> >                     Andrew
> >                     dalke at acm.org
>
> What's the big problem with implementing this:
>
> my varibable = 2
>
> my result = my variable * 3
>
> def my function(some variable):
>     return some variable / 8
>
> ?
>
> I know there is something seriously wrong with this, because otherwise
> it'd be done already in some language (and afaik it isn't).

Early versions (and possibly current versions) of Fortran allowed
spaces **anywhere** and squeezed them out in the first stage of
processing the program.

> So what
> exactly is wrong? I'm asking because typing up a name with underscores
> feels_awkward and separatingByCapitalLettersLooksAwkward. I can't remember
> any situation where a space is needed to separate one variable from
another,
> and syntax characters aren't allowed in variable names.. What am I missing
> here? :-)
>

Current language design separates parsing and lexing. That is, there is a
separate
component that is responsible for breaking the input up into logical parts,
or
words. The problem is cleanly separating keywords from names, since there's
nothing (like a special character) to distinguish them. If you can't do it
cleanly,
the problem becomes non-deterministic, which kills your compile time and
opens you up to very hard to understand syntax errors.

Fortran managed to do it because it has a very strict pattern where it is
(or was)
impossible to have a legal statement with two adjacent names. They had to be
separated by an operator or some kind of special character, or the program
simply wasn't legal Fortran. The exception was the keyword at the front of
the
statement. I can remember any number of programs that contained ten-liners:
single statements that occupied ten lines with no spaces for readability,
and with
line breaks in the middle of names.

Also, I don't consider names with spaces very readable either. My personal
preferance is to keep them as short as possible, consistent with clarity.
Clarity
takes a nosedive when you have to break a statement across multiple lines
because someone decided that very long names were somehow "better
documentation"
than short, well chosen names.

A cursory look at one of the Python books shows these lines:

for dict in dictlist:
if not keylist:

I would think that reserved function words like "in" "not" "and" or "or"
would
be rather natural parts of names.

John H. Roth Jr.
> >
> >
> >
>
>
> --
> Lucifer Sam Siam cat
> Always sitting by your side
> Always by your side
> That cat's something I can't explain
>         - Syd