assignment expression peeve

[Paul Rubin]

OK, I want to scan a file for lines matching a certain regexp. I'd
like to use an assignment expression, like

for line in file:
if (g := re.match(pat, line)):
croggle(g.group (1))

Since there are no assignment expressions in Python, I have to use a
temp var. That's a little more messy, but bearable:

for line in file:
g = re.match(pat, line)
if g:
croggle(g.group (1))

It gets annoying when there are 4 different regexps that the line
might match, and I want to do something different depending on which
one matches. That's not that uncommon a text scanning situation.
With assignment expressions, it's a very natural if/elif chain:

for line in file:
if g := re.match(pat1, line):
croggle(g.group (1), 17)
elif g := re.match(pat2, line):
x = mugwump(g.group (3))
y = wumpus(g.group( 2))
return defenestrate(x, y+3)
elif g := re.match(pat3, line):
# do something completely different with groups of g
elif g := re.match(pat4, line):
# more of the same

Without assigment expressions, it gets unspeakably ugly. You have to
use a deeply nested if/else if sequence where you match the regexp and
test the result on 2 separate lines at each branch, or reorganize the
code to use some kind of dispatch table (good if there's a lot more
than 4 regexps, but overkill for just 4), or whatever. I ended up
creating a special class instance just to match a regexp and remember
the result, so I could write in the if/elif style.

This kind of regexp matching is a common pattern and I keep wanting
assignment expressions whenever I code it, and end up crocking up some
silly workaround.

[Ben Finney]

Re: assignment expression peeve

On 14 Oct 2003 21:12:29 -0700, Paul Rubin wrote:[color=blue]
> It gets annoying when there are 4 different regexps that the line
> might match, and I want to do something different depending on which
> one matches.[/color]

If you want to do lots of different things, you really should be placing
them in different functions:

def deal_with_line_ type_A():
# do stuff for lines of type A

def deal_with_line_ type_B():
# do stuff for lines of type B

This allows the tasks to be completely different for each type of line,
without cramming it into one structure.

Then, having defined what to do with each line type, map the regex to
the function for each type:

line_action = {
'AAA': deal_with_line_ type_A,
'BBB': deal_with_line_ type_B,
}

The dictionary then acts as the switchboard:

for regex in line_action:
match = re.match( regex, line )
if( match ):
line_action[regex](match)

Extending the range of lines is a matter of adding items to
line_actions, and writing the resulting function. The decision code
remains the same.

--
\ "Self-respect: The secure feeling that no one, as yet, is |
`\ suspicious." -- Henry L. Mencken |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Paul Rubin]

Re: assignment expression peeve

Ben Finney <bignose-hates-spam@and-benfinney-does-too.id.au> writes:[color=blue]
> If you want to do lots of different things, you really should be placing
> them in different functions:[/color]

Yeah, I mentioned I could do something like that, but that it was
overkill for such a small list. Really, anywhere you have an
if/elif/elif/elif chain of any kind, you can probably replace it with
a lookup table. But the if/elif/elif idiom exists because a lot of
the time, it's the most natural and clear and correct way to write the
code. And this is just an obvious one of those instances, except it's
thwarted by a Python language deficiency that I hope will get
corrected someday.

[Ben Finney]

Re: assignment expression peeve

On 14 Oct 2003 22:19:07 -0700, Paul Rubin wrote:[color=blue]
> Ben Finney <bignose-hates-spam@and-benfinney-does-too.id.au> writes:[color=green]
>> If you want to do lots of different things, you really should be
>> placing them in different functions:[/color]
>
> Yeah, I mentioned I could do something like that, but that it was
> overkill for such a small list.[/color]

The example you gave was contrived, sure. But even it was getting
complex enough that it was hard to parse visually -- and using a switch
or case structure wouldn't have made it easier. The problem was the
fact that each case was doing something completely different.

Once each case is more complex than a smple statement or two, it makes
more sense to handle them in separate functions. If a task expands to
several statements, the likelihood is that it will keep expanding.
Better that it do so in a separate function rather than bloating some
monstrous switch structure.
[color=blue]
> But the if/elif/elif idiom exists because a lot of the time, it's the
> most natural and clear and correct way to write the code.[/color]

Yes, when each case is trivially simple and easy to read along with all
the others, it does make sense to keep them together. The if/elif/else
structure works fine there.

That's not so for the example you gave, where each case was more complex
and differed sufficiently from the others that they were hard to see as
a single structure. Thus why I recommended using separate functions if
you want to do lots of different things.

--
\ "There is more to life than increasing its speed." -- Mahatma |
`\ Gandhi |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Carl Banks]

Re: assignment expression peeve

Paul Rubin wrote:[color=blue]
> Without assigment expressions, it gets unspeakably ugly.[/color]

The designers of Python believe that assignment expressions are bad
news (which I agree with), and they will NEVER make assigments into
expressions just to avoid this little problem.

Frankly, I think assignment expressions would cause far more
unspeakable ugliness than they would prevent.

There's workarounds. Live with them.


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

[Alex Martelli]

Re: assignment expression peeve

Paul Rubin wrote:
[color=blue]
> OK, I want to scan a file for lines matching a certain regexp. I'd
> like to use an assignment expression, like
>
> for line in file:
> if (g := re.match(pat, line)):
> croggle(g.group (1))
>
> Since there are no assignment expressions in Python, I have to use a
> temp var. That's a little more messy, but bearable:[/color]
...[color=blue]
> This kind of regexp matching is a common pattern and I keep wanting
> assignment expressions whenever I code it, and end up crocking up some
> silly workaround.[/color]

Indeed, this is one case where I have in fact used the pattern I
showed in more generic context in the Cookbook, something like (typing
the code back in from memory):

class Matcher(object) :
def __init__(self, pat, *args):
self.re = re.compile(pat, *args)
self.mo = None
def __nonzero__(sel f):
return bool(self.mo)
def match(self, astr):
self.mo = self.re.match(a str)
return self.mo
def __getattr__(sel f, name):
return getattr(self.mo , name)

I'd rather inherit from the match object's type, but _sre doesn't
allow that; this containment + delegation is OK, anyway.

Note that my use is somewhat different from yours -- I prefer to
compile my re's at the start anyway, so what I do here is e.g.

ma1 = Matcher(pat1)
ma2 = Matcher(pat2)
for line in file:
if ma1.match(line) : croggle(ma1.gro up(1))
elif ma2.match(line) : plakke(ma2.grou p(2))

i.e., I prefer to keep separate matchers, one per re pattern.
If you prefer to have just one matcher:

ma = Matcher()
for line in file:
if ma.match(pat1, line): croggle(ma.grou p(1))
elif ma.match(pat2, line): plakke(ma.group (2))

that's perhaps even easier to arrange:

class Matcher(object) :
def match(self, repat, astr):
self.mo = re.match(repat, astr)
return self.mo
def __getattr__(sel f, name):
return getattr(self.mo , name)

no need for __init__ or __nonzero__ (actually I'm not quite
sure WHY I had __nonzero__ last time I coded this -- maybe I
was also testing the matcher itself, not just the return of its
match method).


Alex

[Daniel Dittmar]

Re: assignment expression peeve

Paul Rubin wrote:[color=blue]
> OK, I want to scan a file for lines matching a certain regexp. I'd
> like to use an assignment expression, like
>
> for line in file:
> if (g := re.match(pat, line)):
> croggle(g.group (1))[/color]
[...][color=blue]
> It gets annoying when there are 4 different regexps that the line
> might match, and I want to do something different depending on which
> one matches. That's not that uncommon a text scanning situation.
> With assignment expressions, it's a very natural if/elif chain:[/color]
[...][color=blue]
> This kind of regexp matching is a common pattern and I keep wanting
> assignment expressions whenever I code it, and end up crocking up some
> silly workaround.[/color]

If this is a common pattern in your code, then write an iterator class that
reads lines from a file and spits out the match object (+ tag, so you know
which regular expression was matched.
So your code becomes:

for match, tag in LineMatcher (...).parseFile (fname):
if tag == tag1:
action1
elif tag == tag2:
action2

cons: you have to invent names for every pattern
pros: patterns are compiled and thus more efficient

Daniel

[Alex Martelli]

Re: assignment expression peeve

Carl Banks wrote:
...[color=blue]
> 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[/color]

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

Of course there are alternatives (aren't there always, most
particularly in natural language?), such as claiming that you're
just informing the reader of the prince's "actual" name (but if
the kingdom was so far away, it's believable that the prince's
actual name was too hard to pronounce for us and "Peter" is just
a pseudonym you're using for convenience;-) -- but values in
computer languages don't have "actual names", in this analogy,
just "pseudonyms " anyway.

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.


Alex

[Paul Rubin]

Re: assignment expression peeve

Carl Banks <imbosol@aerojo ckey.invalid> writes:[color=blue][color=green]
> > Whatever. You're the only programmer I've ever encountered who claims
> > to have actual trouble understanding assignment expressions.[/color]
>
> I really don't appreciate you putting words in my mouth, and I'm sorry
> you feel the need to resort to dishororable tactics.
>
> I claim assignment expressions are counterintuitiv e, and hard to read,
> because they go against the grain of natural language. They require
> more effort because we can't use the language parts of our brains to
> help.[/color]

What does it mean to be hard to read? Your eyes can't make out the
characters on the screen? Or your eyes can make out the characters,
but the meaning conveyed isn't immediately clear to you. If the
latter, that means you claim to have trouble understanding the
expressions.
[color=blue]
> They require more effort because we can't use the language parts of
> our brains to help.[/color]

Some of us either manage to limit our use them to ways where this
isn't a problem, or else it just isn't an issue to begin with.

Frankly your thing about no natural language analog sounds like hot
air to me. Have you got an analysis of every natural language ever
spoken in the world, that finds no construct like that? And even if
you do, where is the slightest evidence that it makes any difference?
Even if it does take an extra millisecond of mental effort to parse
the assignment expression, a workaround resulting from not using it
(such as defining a new class and making an instance of it and calling
some operation on it), being may take 100 times as much effort.

[Carl Banks]

Re: assignment expression peeve

Alex Martelli wrote:[color=blue]
> Carl Banks wrote:
> ...[color=green]
>> 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[/color]
>
> """
> 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...:-).[/color]

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][color=blue]
> 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.[/color]


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

[Carl Banks]

Re: assignment expression peeve

Paul Rubin wrote:[color=blue]
> Carl Banks <imbosol@aerojo ckey.invalid> writes:[color=green][color=darkred]
>> > Whatever. You're the only programmer I've ever encountered who claims
>> > to have actual trouble understanding assignment expressions.[/color]
>>
>> I really don't appreciate you putting words in my mouth, and I'm sorry
>> you feel the need to resort to dishororable tactics.
>>
>> I claim assignment expressions are counterintuitiv e, and hard to read,
>> because they go against the grain of natural language. They require
>> more effort because we can't use the language parts of our brains to
>> help.[/color]
>
> What does it mean to be hard to read? Your eyes can't make out the
> characters on the screen? Or your eyes can make out the characters,
> but the meaning conveyed isn't immediately clear to you. If the
> latter, that means you claim to have trouble understanding the
> expressions.[/color]

No. Go look up the word understand. Whether assignment expressions
are easy to read, or hard to read, I can UNDERSTAND them just fine.

[color=blue][color=green]
>> They require more effort because we can't use the language parts of
>> our brains to help.[/color]
>
> Some of us either manage to limit our use them to ways where this
> isn't a problem, or else it just isn't an issue to begin with.[/color]

Some of us have programmed in C or Lisp for a long time, and don't
realize how counterintuitiv e and awkward the construction is.

[color=blue]
> Frankly your thing about no natural language analog sounds like hot
> air to me.[/color]

Go back a few posts, and you'll see I implored you to take my
linguistic argument as you would. You evidently felt it was
reasonable enough to argue with. If you'd like to dismiss it as crap,
be my guest. I'm here to defend my views, not to change your mind.


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

[Paul Rubin]

Re: assignment expression peeve

Carl Banks <imbosol@aerojo ckey.invalid> writes:[color=blue]
> No. Go look up the word understand. Whether assignment expressions
> are easy to read, or hard to read, I can UNDERSTAND them just fine.[/color]

You're not making any sense. To understand an expression, you have to
read it first. So if it's hard to read, it's hard to understand.
[color=blue]
> Some of us have programmed in C or Lisp for a long time, and don't
> realize how counterintuitiv e and awkward the construction is.[/color]

Then after you've programmed in C or Lisp for a while, maybe the
construction stops being counterintuitiv e and awkward, hmm? Sort of
like putting the adjective after the noun instead of before it is
counterintuitiv e for English speakers, but becomes intuitive if you
speak French for a while? If Python had those expressions too, they
would also become intuitive and non-awkward for Python programmers.

(Btw, I remember the exact moment when assignment expressions in C
became natural to me: When I first started learning C from Brian
Kernighan's C tutorial that explained

while ((c = getchar()) != '\0')
do stuff with c;

I had to spend a few moments understanding what was happening, but
then it made perfect sense. No long period of counterintuitio n or
awkwardness for me, thanks. So there's another counterexample to your
theory. In fact I had an "aha" when I saw that "a = b = c;" is also
an assignment expression in C and worked automatically for that
reason. In Python, of course, it's a special syntactic kludge with,
um, no natural language analog, not that that matters.)
[color=blue][color=green]
> > Frankly your thing about no natural language analog sounds like hot
> > air to me.[/color]
>
> Go back a few posts, and you'll see I implored you to take my
> linguistic argument as you would. You evidently felt it was
> reasonable enough to argue with. If you'd like to dismiss it as
> crap, be my guest. I'm here to defend my views, not to change your
> mind.[/color]

OK then, based on the decades of experience of millions of C and Lisp
programmers, I'll take your advice and dismiss your linguistic view as
crap. If you want to continue to embrace it, be my guest. Happy
crapping.

[Donn Cave]

Re: assignment expression peeve

In article <6ZWjb.49$Vf7.3 4@nwrdny02.gnil ink.net>,
Carl Banks <imbosol@aerojo ckey.invalid> wrote:
....[color=blue]
> 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.[/color]

This part is less obvious. Syntactical relationships are learned,
and arguably learned in a very context sensitive way. Computer
programming languages are relatively simple and regular, and it
is not clear that they depend a lot on congruence with some natural
language.
[color=blue]
> 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.[/color]

If we stipulate that we are talking about Python programmers, maybe.

In more general terms, though, I think it could be argued that
assignment actually doesn't play much of a role in natural speech
anyway, whether in the declarative or imperative sense. Unless
you count lexical function, but you're talking about syntax.
This should be bad news for Python, but by the time people get
here it doesn't matter much.

Moreover, I think you should probably quit while you're ahead,
because I have a hunch that the point you're pushing there would
actually work against you if it were more patently true. Suppose
the syntax actually were "set a to b", or of course more like
"set `a b" because this isn't Applescript or Cobol. Borrow the
time machine and make it so. Now, will this turn out to be an
expression? Very good odds, because now it's just a function.
Functions can be imperative, and they're certainly expressions.

Basically, I don't think you want to tie the quality of a computer
programming language to its congruence with English syntactical
forms. If there were a clear case for that, I think the FPL crowd
would come out way ahead.
[color=blue]
> 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.[/color]

Probably didn't go near far enough. You have to get a look at
Haskell. Whether it's practical is endlessly debatable, and
I'm not sure it exactly does what you say there ... or maybe
you'd have to program in Haskell to see what you're saying.
But it is rather rigorous in this respect.

Donn Cave, donn@u.washingt on.edu

[Paul Rubin]

Re: assignment expression peeve

"Donn Cave" <donn@drizzle.c om> writes:[color=blue]
> But when you can say
>
> if g := match(a, b):
>
> then I suspect you will also be able to say things like -
>
> if not (dv := start() and f := nfile(dv)
> and ((t := f.find("--") > 0 and fx = f[:t]) or (fx = f))):
> print "Well, bless me!"[/color]

Well, yes, you can write messy code in any language. There will
always be some need for tastefulness in programming. Language
designers can't make that need go away.

[Carl Banks]

Re: assignment expression peeve

Donn Cave wrote:[color=blue]
> In article <6ZWjb.49$Vf7.3 4@nwrdny02.gnil ink.net>,
> Carl Banks <imbosol@aerojo ckey.invalid> wrote:
> ...[color=green]
>> 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.[/color]
>
> This part is less obvious. Syntactical relationships are learned,
> and arguably learned in a very context sensitive way.[/color]

Well, I can assure you that it's at least harder to learn, seeing that
learning a new syntax is always harder than using syntax similar to
what you already know. (Otherwise, explain why Spanish is easier to
learn for English speakers than Japanese.)

As for the argument that it could take more effort, let's just
remember that our internal language circuits cannot handle arbitrary
syntax. Simple as assignment expressions are, I'm not so sure our
language circuits can parse a syntax which doesn't exist in any
language I know of (and I suspect doesn't exist in any language). If
we cannot parse an assignment expression though ordinary language
processing, then it follows that it takes more effort to read it.

(I sense we're getting dangerously close to introducing Chomsky into
this discussion; if so, I'm outta here.)

[color=blue]
> Computer
> programming languages are relatively simple and regular, and it
> is not clear that they depend a lot on congruence with some natural
> language.[/color]

I highly disagree with this statement, however.

Relatively simple and regular has nothing to do with it. Assembly
language is relatively simple and regular. Intercal is relatively
simple and regular. Perl is relatively simple and regular. And
they're all unreadable messes. (Even still, all of them rely on a
smittering of resemblance to natural language.)

There's a reason hardly any successful programming languages eschew a
resemblance to human language: because humans are good at thinking in
terms of language.

[color=blue][color=green]
>> 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.[/color]
>
> If we stipulate that we are talking about Python programmers, maybe.
>
> In more general terms, though, I think it could be argued that
> assignment actually doesn't play much of a role in natural speech
> anyway, whether in the declarative or imperative sense.[/color]

You're completely missing the point.

I'm not trying to claim that assignment, per se, plays a role in
natural speech. My claim is that assignment is a command. When a
programmer writes a=b, he's commanding the computer to set a to b.
Commands do play a role in natural speech, and only the imperative
mood conveys it (without descriptive circumlocations ).

Which is (getting back to the point) why I think Martelli's example
was incorrect.


[snip][color=blue]
> Basically, I don't think you want to tie the quality of a computer
> programming language to its congruence with English syntactical
> forms. If there were a clear case for that, I think the FPL crowd
> would come out way ahead.[/color]

Basically, I think you're missing the whole point of what I'm saying,
and are therefore ill suited to judge the strength of my position.


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