assignment expression peeve

[Alex Martelli]

Ah, I _knew_ there had to be some response -- just like Usenet to delay
its delivery.  Darn.  OK, here goes -- sorry for the repetition...:

Carl Banks wrote:
   ...
>> Once upon a time, in a Kingdom far, far away, there was a
>> strong, corageous prince, who we'll call Richard, and his weak,
   ...
> 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.

We disagree on this general principle -- which I guess makes the
whole discussion somewhat moot, but I'm more interested in the
specific disagreement about your contention that assignment - as -
expression has no analog in 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.

That's the thesis on with Perl was designed -- by Larry Wall, whose
background, I believe, is in linguistics.  Ambiguities resolved by
context, _pronouns_ (!) such as $_, chaotic redundancy just like in
natural language -- the works.  I do not find the result very readable
at all, even though I do concede that the resemblance to the maddening
wonderful chaos of natural language IS occasionally quite amazing.

> 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

I can posit this if it helps discussion -- I may not fully agree but
quibbling would be distracting and irrelevant here.

> 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.

Ditto.


> 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

I agree on both scores.

> 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.

Not very relevant, because the syntactic and semantic parallels
in natural language (as well as, where expressions and "single
assignment" are concerned, in programming languages) between the
declarative and imperative moods are SO close.


> 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

Programmers whose early training was in copy-semantics languages
may have such trouble, but that's got nothing to do with the issue.
(And I strongly doubt that copy vs reference semantics makes a
huge difference anyway, see sundry counterexamples passim).

In reference-semantics languages such as Python, the right way to
read "a = ..." is "in the following we'll use name 'a' to mean ...",
or more succint readings when meaningful in context, e.g. I've heard
people read
    mean = total / number_of_items
as "The mean IS the total divided by the number of items", i.e. as
if the statement was reminding the reader of what "mean" MEANS.

> consider a declarative clause to be an analogue of an assignment; it
> is both syntactically and semantically different.

You may substitute the declarative "we'll use name X to mean ..."
with the imperative "use name X to mean ..." without any substantial
change in either semantics OR syntax.  "Assignment" to a name *means this*,
in either declarative or imperative moods as you prefer, in
reference-semantics languages such as Python.

And what about "the total of this column, which you must also copy
at the start of the Liabilities column for further computation which
we'll explain later, must be underlined with a thick red pen".  This
is copy semantics (quite explicitly) and even an "indexing" -- yet,
while you may not find this the clearest way to explain this specific
tidbit of book-keeping, you can hardly deny it's natural language.

underline_with(pen(red, thick), Liabilities[0] := sum(thiscolumn))

is the rough equivalent, assuming := as Rubin did to mean "assignment
within expression" -- though of course it reads right to left, as
function calls so often do, since their arguments, which we write to
the right of the function name, are to be evaluated BEFORE the call
(strict ordering) so it may be convenient in a NL equivalent to
mention them before the action (different NL's have different
verb / noun ordering preferences, of course -- I hope you're not
claiming that German programmers prefer RPN beause of this?-).

Particularly in Romance languages, and in learned moods of discourse,
we tend to use a LOT more parenthetical and subordinate phrases than
you may be used to in contemporary English (my own style typically
betrays that -- even though I think in English when I write in English,
it's an English with VERY intricate, Romance-like phrase structure;-).
A historical and cultural accident, nothing very deep: read (ah joy!)
Gibbons, or Adam Smith, or (eek) Ricardo, to see how learned English
prose could be in the 18th century... not noticeably less intricate
in phrase-structure than Romance languages (indeed, some _French_
authors of that time -- though no Italian ones -- had snappier and 
simpler phrase structure than their British contemporaries, IMHO).

MOST definitely, nothing ANYWHERE as deep that you can justify your
exaggerated claims about "assignment expressions" being so utterly
foreign to natural language!!!


> 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.

I'm not sure what relative clauses have to do with this all.  We're
talking about an imperative to use name X for an object that is being
described and about which other imperatives are expressed within the
same sentence; that will typically be a parenthetical (set off with
either commas or parentheses in written language, but pronounced in
just about the same way in spoken, i.e. really natural, language,
and playing just the same rome anyway).  "Make sure the discounted
net present value, call it NPV for short, looks very appetizing, to
avoid the suits laughing in your face, since it's by NPV alone you
will set their minds in motion".  Or if you're so stuck on word-order
(silly when making generalized claims about natural languages, since
NOTORIOUSLY different natural languages have such different preferred
word orderings!), "The NPV, always call discounted net present
value that!, you must make very appetizing", or "Do present
a very appetizing NPV, always call discounted net present value
that way!, to make the suits happy".

Etc, etc.  It seems truly ridiculous to see you trying to deny
the close analogies between all of these usages and "assignment
expressions" with irrelevant quibbles on declarative vs imperative
and the like.


> 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."

Nope!  "use a as the name for b", "a, which is the name you must
use for b,", "a, and remember to use that name for b," etc, etc.  
That's in reference-semantics language such as Python.  If you're
keen on word order, "speed, which is distance divided by time, you
must keep under 50 MPH on this road to avoid a fine" -- half
imperative, half declarative / explanatory, it doesn't matter --
the term being assigned-to (defined) at the start, then the
assignment (definition of the term), then the imperative.

Come on, you just can't SENSIBLY keep denying this is natural
language!  "Agent X, for which role you'll hire Mr Smith, you'll
liaise daily with" -- these are instructions to a secret agent
and are no less imperative than any snippet of programming, and
even though the future tense means some syntactical ambiguity
between commands and predictions, no natural language speaker
will understand this sentence any different than the two.
"1. hire Mr Smith as Agent X; 2. liaise daily with Agent X".
So much for your attempt at strict imperative/declarative
distinction in natural language... the distinction is in fact
NOT very strong at all in more cases than not!  Much of the
clues about what's a command and what's a statement of facts
as they are, an explanation of why they are that way, etc, are
in NL utterances' context (and pragmatics, including social
distinctions between speaker and listener, etc, etc).

"The blond guy, who wants to be called Bob, you must not kill",
vs "The blond guy, call him Bob, you must not kill", "Do not
kill Bob, the blond guy", etc, etc -- all perfectly good NL
sentences, all with obviously identical semantics, minor and
irrelevant changes in surface syntax (word order etc).  And
all perfectly good examples of "assignment expressions".

> 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.

Yeah, right, "QED".  You just cannot speak of "the blond guy
(remember to call him Bob!)", etc, wherever you could speak
of "the blond guy", right?  "Fiddlesticks" is putting it mildly.

 
> [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.

I think you're being so utterly and totally unreasonable by 
denying the "blond guy (call him Bob!)" strict NL analogy to
assignment expressions, that I'm having to make a very deliberate
effort to not start LIKING assignment expressions just to make
you sorry about being so unreasonable:-).  I won't, but I'll
keep arguing against you just because...:-).

Giving a local name to some value has no "side effects" that
are any less "contained" than your "not opposed to" example:

> 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

In fact, as long as you never RE-bind a name ("single assignment"),
giving something a name is perfectly OK even in the purest functional
NO-such-thing-as-a-side-effect language.

> expressions are, of course, the epitome of both at the same time,
> which is the real reason I have such a distaste for them.

"Side effect" is the mutation of some state.  A name is not a state
(unless you object specifically to *RE-binding* names -- quite a
different issue).  I see Donn already suggested you look into Haskell,
with "state changing" closely limited to monads.  But if you do,
you'll probably have to drop any illusions about this having just
about anything to do with natural language analogies!

If you think of "results" and "side effects" of instructions being
given in natural language and faithfully followed, you'll be hard
put to draw any distinction -- because it's a distinction that
belongs more to the realm of _maths_, than to the messy real world
and the messy natural language evolved to deal with the real world.
Any RW action has N consequences, and sometimes discerning which of
those are (intended) "results" and which (unintended or deemed to
be unimportant) "side effects" is close to impossible, requiring
mind-reading perhaps all the way to the subconscious (I go get a
coffee, with the "results" of getting caffeine in me and the "side
effect" of taking a short break from work -- hmmm.... are you SURE
that "side effect" was as unintended and accidental as all that...?-).


> 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.

I think it's an issue of doing things in a rigorous mathematic
framework, and that Ada's failure, like many other language's, is
to try to be "rigorous" in what's really a very ad-hoc way.
Python doesn't really try to be rigorous and has good pragmatical
reasons for such limitations as the expression/statement schism
(though sometimes they may feel confining, of course, depending
on what one was previously used to).  IMHO, of course.


Alex