assignment expression peeve

[Carl Banks]

Alex Martelli wrote:
> Carl Banks wrote:
>   ...
>> The real reason is that assignment expressions lead to all kinds of
>> ugly and unreadable code.  This is because there is no linguistic
>> analogue for assignment as an expression.  Things that work as
> 
> """
> Once upon a time, in a Kingdom far, far away, there was a
> strong, corageous prince, who we'll call Richard, and his weak,
> cowardly, but cunning younger brother, who we'll call John,
> secretly hated and feated Richard and envied his strength.
> One day, Richard and John set out on a fateful hunt in the woods
> ...
> """
> 
> Those clauses "who we'll call Richard" and "who we'll call John"
> are exact natural-language equivalents of assignment-as-expression
> (in a computer language with reference, not copy, semantics, of
> course - but Python qualifies in this regard), or as close as
> anything in natural language ever gets to computer languages.
> 
> Basically, I'm parentethically affixing a name to some entity
> I'm describing, just so I can later use the name, rather than
> some periphrasis, or a pronoun, with the well-known problems
> that these can cause (computer languages don't have pronouns,
> unless you want to consider perl's $_ as such perhaps...:-).

Ok, I disagree that this is a suitable analogue.  I'll explain.

My contention is that a large part of what makes something "readable"
in code is that is it resembles, to some degree, natural language.
This is because we can use the parts of our brain that parse natural
language to help us parse code.  Makes sense, pretty obvious.

The thing is, these analogues have to match syntactically as well as
semantically.  In other words, if the language construct in question
does not have an analogue that matches syntactically, then we have to
acquire the ability to parse it.  Furthermore, if it turns out that
our "language circuits" are not able to internalize an unusual syntax,
then parsing it will always require intellectual effort.  (Whether
this is true of assignment expression I won't speculate at this
moment.)  In the end, we have something that is at least harder to
learn, and possibly takes more effort to read.

Now, your example does manage to communicate the semantics of
assignment expression (unlike Rubin's example, which didn't
communicate that anything was being assigned).  However, I would say
your example still is not a proper analogy, for a very simple reason:
most people read computer programs as imperative, while your example
is declarative.

I hope I don't have to argue the point that most people think of
programming as imperative.  I believe programmers think of "a=b" as
"Set a to b," not "a's value becomes b's value".  Therefore, I don't
consider a declarative clause to be an analogue of an assignment; it
is both syntactically and semantically different.

Now, the question is, is there any way, syntactically, to have an
imperative in a relative clause?  If so, can it be set in a relative
clause such that the object is also the antecedent?  Certainly you
could *communicate* that with a detailed enough explanation, but can
you do it with analogous syntax?  I would say no.

Another argument is the drop-in argument.  In programming languages,
you are typically able to drop an expression anywhere an expression is
valid.  The natural langauge analogue of an expression is a noun
phrase, and as in programming languages, it is syntactically valid to
drop a noun phrase anywhere a noun is expected.

What about assignment expression?  If you think of the programming
language as imperative, "a=b" would parse as "Set a to the value of
b."  If declarative, "a=b" would parse as "a gets the value of b."
You cannot use either phrase as a noun phrase (you would have to
change them around).  It follows that "a=b" is not suitable as an
expression.


[snip]
> I'm not necessarily dissenting with your detestation of
> assignment-as-expression (although gradually I'm getting some
> doubts about the general, overall wisdom of Python's strong
> distinction between expressions and statements, that's a more
> general and problematic issue).  But I _am_ dissenting with
> your specific claim that "there is no linguistic analogue"
> for it in natural language.


Well, sorry, I'm standing by it.  However, it got me to thinking.
Even if it did have a solid linguistic analogue, I still wouldn't like
it.

When I look at a statement or an expression, I prefer that I can look
at it and know that exactly ONE thing happens.  Either it has a side
effect, or it returns a value: not both.  (Although I'm not opposed to
stuff like readline(), which affect its file object and returns a
value, as long as the side effects are contained.)  Assignment
expressions are, of course, the epitome of both at the same time,
which is the real reason I have such a distaste for them.

It would be really nice (generally, not Python in particular) if we
could have all things that return values be expressions, and all
things that have side effects be statements, AND be able to implement
it in a practical way.

I'm not sure if it's practical, thought; Ada does (or tries to do)
something like it, and it went a little too far.


-- 
CARL BANKS                   http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her." 
          --Laurel Fortuner, Montendre, France 
            1992 Bulwer-Lytton Fiction Contest Winner