assignment expression peeve

[Alex Martelli]

Carl Banks wrote:
   ...
>> 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.
> 
> First of all, the command here is a command to the computer, not to
> us.  So the declarative sentence with the same semantics would be "the
> computer uses X to mean ...".

"The computer" is wildly inappropriate here.  "This program", or
"this scope of this program", maybe.  But "we" is far closer to
how natural language speakers would normally express themselves --
joining the listener and the teller in a plural is a good and
very basic trick of storytelling.  Plus, if you want imperative
mood, "Take X to mean..." (slightly more specific than "use")
may be fine.


> Second, although I was in error to claim it was semantically
> different, the same is not true of syntax.  Imperative and declarative
> are different syntaxes: similar, parallel, but different.  This must

Take Italian (or is it "not a natural language", or do you deem it
"too alien"?!).  "Prendi il treno": it's impossible to say from this
sentence whether I'm instructing / pleading / advising ("take the
train" in English) or simply describing ("you take the train" in
English).

Come to think of it, "you take the train" in English can quite well
be imperative -- "you take the train, I will fly", the boss said to
the lowly employee; so "you take the train" by itself could quite
well be imperative, depending on the context and the pragmatics, just
as well as declarative.  So could (as a parenthetical) be just "take
the train", as soon as it's in a linguistic environment where it IS
permissible to drop the pronoun (as Italian lets you do almost always,
English and French more rarely):
"Many people each day drive their cars, take the train, or walk to work".
Yes, sure, you're assumed to implicitly mentally repeat the "many people"
subject just before the "take the train", but it need not be spelled
out.  Or, consider "you will hire Mr Smith" -- imperative or descriptive?
Impossible to tell without context and pragmatics -- syntactically
undistinguishable (some might still take the will/shall distinction
as paradigmatic here, but is that still living English...?)

The boundaries of imperative and declarative are FAR thinner -- particularly
in real natural languages, as opposed to the half-baked theorizations
thereupon concocted by theorists in the last few millennia -- than you
claim.  Much more depends on context and pragmatics than on syntax, in
REAL natural-language use even more, but in "theoretical" grammar too.

> be reflected, I say, in the analogous phrasing.
> 
> 
>>  "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"
> 
> I wouldn't call it a rough equivalent.  In fact, I'd say the text you
> gave doesn't even have an equivalent--since it's not an exact verbal
> description of any code.  As I said, that it what I think needs to be
> for it to be considered analogous (for the purposes of my contention).

I consider your (attempt at) redefinition of the word "analogue" quite
Humpty-Dumpty-ish, inappropriate, and unusable for the purpose of
reaching any practical conclusion.  Many phrasings of the same
command or description -- which may differ in surface syntax, e.g in
word-order, partly depending on exactly what natural language they're
using, are perfectly equivalent and easily parsed as such by native
speakers of the respective languages.  You can't [1] blithely ignore the
last century-plus of linguistics and claim "no analogue" between, e.g,
"give John the bread", "give the bread to John", "To John, give the bread",
"The bread, give to John", &c.  Prepositions and conjunctions may be needed
in one turn of phrase, optional in another, dropped in yet another, but
that makes no deep difference to the phrases' understandability to native
speakers -- more often than not, alternative surface syntax may just carry
different connotations (as opposed to denotations), emphasizing one aspect
rather than another, as appropriate in pragmatics and by context.

[footnote 1]: well of course you CAN blithely ignore whatever you wish,
but you sure cannot do so AND seriously hope to maintain any shred of
credibility at one and the same time.

So, if I choose to read, e.g., the code (with the usual hypothetical
:= to denote assignment-in-expression, a la Rubin):

kill( john := guy('tall', 'blond', 'near window') )

as

"Kill John, the guy who's tall and blond, there near the window"

I claim I have the strictest "analogue" anybody can wish between a
programming language notation and a natural language sentence, even
though in the latter I've had to use different punctuation and insert
fillers such as "the", "who's", "and", "there".  The reading of the
subexpression
    <name> := <identification>
as "<name>, <identification>" is perfectly natural in context -- few
translations from computer to natural language can POSSIBLY be more
spontaneous and obvious than this, an "assigment expression".

So, ANY part of your case against assignment expressions that rests
on "lack of analogue in natural language" is entirely bogus, and indeed
totally counter-productive, as I'm pretty sure I'm not the only one
who, starting out with diffidence against assignment expressions, is
gradually coming to find them more and more acceptable, just because
of the need to argue against this totally bogus contention and the
wealth of absolutely obvious counterexamples that totally demolish it.


>> MOST definitely, nothing ANYWHERE as deep that you can justify your
>> exaggerated claims about "assignment expressions" being so utterly
>> foreign to natural language!!!
> 
> It's not so much that it can't be done, so much as it is that it won't
> be done.
> 
> Sure, your examples are very close semantically and syntactially--but
> when a human reader sees such code, will they think that way?  In
> other words, faced with an embedded assignment expression, will the
> reader deftly change what they normally think of as an imperative to a
> declarative on the fly, so that it works syntactially while
> maintaining the semantics?

To reiterate: you're making a mountain out of the molehill of the
distinction between imperative and declarative, trying to shore up
a crumbly contention that most definitely doesn't deserve to be --
doesn't deserve anything else than to die a shameful death.

When the ordinary person reads
    print max(amounts)
they read "print the maximum of the amounts"; they don't have ANY
problem switching from imperative "print" to descriptive "the
maximum of", nor need they make any attempt to turn this around
to "compute the maximum of the amounts and then print it" in order
to ``maintain'' your cherished ``imperative'' throughout.

So, any claim that "kiss cinderella, the fairest of them all"
is not an "analogue" to
    kiss( cinderella := fairest(themall) )
_just doesn't wash_.  The "mood switch" imperative -> declarative
is far easier than you suppose and already needed to read the plain
    kiss( fairest(themall) )
as "kiss the fairest of them all" rather than "compute/determine the
fairest of them all and then kiss her/him/it" which would be rather
periphrastic AND require the introduction of a pronoun which just
isn't there in computer languages [except in Perl, if you coded
    &fairest(@themall) and kiss $_
I suppose:-)].

The "assignment expression" is a perfectly natural parenthetical
which adds no difficulty at all.  There are MANY other constructs
in Python which would present FAR worse difficulties if one were
to accept that laughable idea of "analogue" which you presented,
yet give no difficulty whatsoever in practical use.

> Perhaps the flowery among us can do that easily enough; perhaps you
> can.  In that case, I have no objection to your counterexamples
> (except to point out that a flowery person will still have to learn
> when to adjust his thinking).
> 
> Personally, I don't.  I think I usually parse embedded assignments
> using some sort of recapitualtion, like this:
> 
>     "if [let] a equal b, that quality, is equal to zero..."
> 
> That recapitulation, of course, produces a hiccup in my reading,
> requiring more effort.  I can read the following a lot easier:
> 
>     "[let] a equal b.  If a is equal to zero..."

If "a=b" is to be read "let a equal b", then how can you possibly
manage to contort your brain around such Pythonisms as
    foo(bar=23, baz=45)
???  Using sensible 'transliterations', you'd read "if (a:=b+c)==0:" as:
    if a, which is b+c, equals zero, ...
and that call to foo as something like
    [call] foo, naming as 'bar' 23, [and] naming as 'baz' 45

If you can't read "a=b" as anything but "let a equal b" you have a
lot of problems finding "analogues" to many other Python constructs
already -- and if you insist in reading the hypothetical new
"naming" operator := in just the same way as you read "=", well,
then the problem is clearly with your flexibility in finding sensible
transliterations.  Having taught many newbies, I can assure you that
this is the least of their problems.


>> 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".
> [snip rest-no I'm not stuck on word order]
> 
> Again, not an exact verbal description.  These sort of embedded
> commands have an idiomatic air to them (to me, at least), and don't

Being idiomatic _IS_ typical of well-used natural language!  So
how can you possibly claim assignment expressions "have no natural
language analogue"?!?!?!

> sound quite as good in an exact verbal description.  I also think the

It doesn't sound FORMAL, not in the context I put it in, of course.
I can just as easily find a perfectly formal-sounding context:

"Ensure that your posts' bogosity, which is verbosity times pomposity
divided by gist, is below the laughability threshold, defined as 74.6,
to avoid excessive derision.  If the bogosity exceeds twice the laughability
threshold, run for your life".

There -- formal enough for you?  Of course, in a formal mood you'd use
such formal-sounding phrasings as "X, defined as Y, ..." rather than such
informal-sounding ones as "Y, call it X, ...".  But both formal AND
informal moods are perfectly good parts of natural language, and why
"informal" is often more easily readable to a reader sharing cultural
traits with the writer, "formal" may in fact be easier in certain cases
where such sharing can't be assumed (I'm reminded of a "Jeeves and
Wooster" tidbit -- Jeeves, visiting the US, orders a glass of juice, the
waitress replies "you've got it!", and Jeeves, quite perplexed, starts
looking around the counter and objects that, no, he _hasn't_!-).


> parenthetical nature of it communicates the idea that it could have
> been uttered anytime; yet in the case of assignment expressions,
> that's not true.

The parenthetical does indicate that the sentence COULD have been
broken.  "One day John, who was a just and fair King, went to chase
bears in the woods", versus
  1. John was a just and fair King
  2. One day John went to chase bears in the woods
and similarly: "Ensure that bogosity, defined as XYZ, is below Z"
could be rephrased:
  1. Bogosity is defined as XYZ
  2. Ensure that bogosity is below Z
and _IN STRICT ANALOGUE_ for assignment expressions, you can write
  ensure( (bogosity:=verbosity*pomposity/gist) < laughability )
OR quite equivalently
  bogosity = verbosity*pomposity/gist
  ensure( bogosity < laughability )

The parallels are SO strict it's mind-boggling to see them denied.
Even your cherished "imperative mood" is easily maintained throughout
if one makes a fetish of it:
  "Ensure that bogosity (compute it as ...) is below laughability"

And YES, there are PLENTY of passages like this, in the yearly
instructions on how to compute one's sundry taxes, that the average
Italian citizen has to contend with.  And I've seen plenty like that
in all other natural languages I know, too.

Of course being able to NEST can be abused -- the Zen of Python's
"flat is better than nested" DOES matter.  But just as you can NEST,
e.g.,
   foo(bar=baz+fie)
so would the potential for clarity remain with assignment expressions,
side by side with the potential for obfuscation.  Anyway, the point
in your argument that I find completely unacceptable is the "no natural
language analogue" part -- natural language has the potential for
obfuscation FAR more than computer languages to, partly because the
PURPOSE of NL utterances IS sometimes to obfuscate and befuddle rather
than to clarify, after all.


> How would "observe(a:=b)" be done using parentheticals, while keeping
> it to be an exact verbal descrption?

"observe a, which is b".


>> 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.
> 
> Sorry, hopefully I've stated my reasons for this more clearly.  The
> analogies have to be very close analogies, i.e., exact verbal
> descriptions, because they're supposed to reflect how a person parses
> the code.

I suspect they're supposed to reflect how YOU parse the code WITH
all your allegedly-etched-in-stone prejudices such as "set a to b"
as the only natural transliteration of "a=b" (which would also make
OTHER Python constructs quite a mess to read).


>>> 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!
> 
> No, right now I'm denying that these are analogous.

I hope this is a last-ditch defense of a contention into which you've
invested far too much energy and emotion to easily admit it's untenable.

"if distance divided by time, call it speed, is above 50 MPH, decelerate"

and, since you HAVE claimed you're not stuck on word-order

"if (speed := distance/time) > 50: decelerate()"

how CAN you claim these are ANYTHING *BUT* ANALOGOUS?!



>> 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.
> 
> You've misunderstood me here, I think.
> 
> Take the following two pseudo-code lines:
> 
>     a = b
>     if a == 0
> 
> Here are their Engligh exact verbal descriptions (remember, I don't
> care about assignment semantics):
> 
>     set a to b
>     if a is equal to 0
> 
> Now, if a=b is an expression, you could substitute a=b for a, like so:
> 
>     if (a=b) == 0
> 
> What I'm saying is, if assignment is an expression, then, like every
> other expression, it should work as a drop-in replacement in its
> natural language analogue (read: exact verbal description).  However,
> it does not:
> 
>     if set a to b is equal to 0
> 
> The only way to make this grammatically correct is to reword the
> assigment, and when you do that, it's no longer a drop-in replacement.

Say that, as Rubin wished, we use := rather than = for assignment
when it's in an expression.  Then, any claim that "a=b" and "a:=b"
should or would be read the same way is OBVIOUSLY false.  You can
always read "a:=b" as "a, which is b," since it cannot occur by
itself (yes, Python generally accepts free-standing expressions, but
it's easy to make it NOT accept the hypothetical "a:=b", should we
add it, as stand-alone).  So, you have all the drop-in replacement
you want, and, were your objection TRULY based on this line of thought,
you should now be jumping to campaign FOR assignment expressions
as long as they were spelled "a:=b"...?-)


>> keep arguing against you just because...:-).
> 
> Well, sorry.  Obviously, if one has a very loose definition of
> analogy, one can make language do just about anything.  The problem

I accept the dictionary definitions, say American Heritage, both
the "normal everyday language one":

1a. Similarity in some respects between things that are otherwise
dissimilar. b. A comparison based on such similarity. See synonyms at
likeness.

and the specialistic one in Linguistics, as we're talking about languages:

4. Linguistics The process by which words or morphemes are re-formed or
created on the model of existing grammatical patterns in a language, often
leading to greater regularity in paradigms, as evidenced by helped
replacing holp and holpen as the past tense and past participle of help on
the model of verbs such as yelp, yelped, yelped.

> is, these loose definitions don't really mean much when trying to
> compare them to code readability.
> 
> You disagreed with my contention; and frankly, with your idea of what
> a natural language analogy is, I don't blame you.  Understanding
> better my idea of what it is, does my contention make more sense?

Sorry, but [a] "my idea" is, essentially, the American Heritage's
Dictionary's, and [b] I don't think it makes any sense to use your
newfangled humpty-dumptyish redefinition of "analogy", because if
you try to apply it just as strictly to all existing Python constructs
it repeatedly falls to pieces.

I think you're trying to argue for "I want to read 'a:=b' EXACTLY LIKE
the different construct 'a=b', and THEREFORE ..." and I don't see
that it makes any sense to express this as "analogy to natural language"
or lack thereof -- particularly when the construct "a=b" is already
best read in very different ways, depending on context, in the
language as it stands!

I hope I can drop out of this thread now, hopefully BEFORE I become
the keenest paladin in the world for assignment-expressions due to
having to defend them against totally absurd charges!-)


Alex