assignment expression peeve

[Carl Banks]

Alex Martelli wrote:
> 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.

Very well.


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

Yes, I've read about this.  I don't object to that approach, but I do
object to the priorities.  I would advocate having a simple, minimal
grammar that stays inside the set of natural grammatical structures.
Obviously, that's not what Perl is doing.


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

Well, the thing is, you could find any similarity you want and claim
it's an analogy.  But I say not any analogy will do.  If a programmer
reads "a=b" and parses it as an imperative, then imperative is the
only analogue that works here (according to my contention, which you
don't agree with, making this whole discussion moot), no matter how
close the syntax or semantics are to the declarative case.

To be honest, I'm not so sure I used the right word in "analogue."
I'm looking more for an exact verbal description of the code, using
the same syntax (noun phrase for an expression, etc.) as programmer
internally parses it as when he reads.

My contention makes a lot more sense when you use this as the
definition of analogue.


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

Yes.

I suspect most people see "a=b" and internally parse it as something
simple like "set a to b" or "let a equal b", filling in the semantic
details afterwards.  That's why I haven't been careful not to say "set
a to b" when I should be saying "set a to the value of b".

In that light, the semantics (copy or reference or whatever) of
assignment are irrelevant to my argument.  The only thing that's
relevant is what goes on in a person's head when reading "a=b".


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

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

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


[snip]
> 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?

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


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

Well, that's what you used.


> 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".
[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
sound quite as good in an exact verbal description.  I also think the
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.

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

    "observe a--set it to b"

Doesn't sound to good to me--it sounds as if you could set a before or
after observing it--so it's not likely to be how a programmer would
parse the code.  It also happens to violate the drop-in argument.


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


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

No, right now I'm denying that these are analogous.


[snip more stuff claiming that declarative and imperative are the same]
>> 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.

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.
Not only that, rewording it changes the syntax in a non-trivial way.
Consider the following rewording:

    if a, which the computer sets to b, is equal to 0

Notice that a is in the if-clause, whereas b and the assignment are in
the relative clause.  A verbal analogue with the same syntax should
have a in relative clause along with b and the assignment, because
that's what assignment expressions do:

    if (a = b) == 0

The analogous code to the rewording would look like this:

    if a (= b) == 0

I actually find this slightly more readable, even though the syntax is
less familiar.  I believe the reason for this is the odd grouping
actually suggests to me to parse it like the relative-clause-based
rewording.  (Of course, I'm self-conscious now.)

Do you understand what I mean by drop-in replacement now?


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

Well, sorry.  Obviously, if one has a very loose definition of
analogy, one can make language do just about anything.  The problem
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?



[snip rest of philosophying which I mostly agree with]


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