Re: order of execution
- From: "Paul Houle" <asmguru@xxxxxxxxx>
- Date: Mon, 3 Jul 2006 23:59:15 -0700
"James J. Weinkam" <jjw@xxxxxxxxx> wrote in message
news:h4nqg.101973$A8.40767@xxxxxxxxxxx
Paul Houle wrote:
"James J. Weinkam" <jjw@xxxxxxxxx> wrote in message
news:6Wdqg.38599$B91.12775@xxxxxxxxxxx
Andrew Nikitin wrote:
"Doug White" <gwhite@xxxxxxxxxxxx> wrote in message
I was looking at some program and it had V[...V<-...] where V is the
local variable declared in function header and that was the first line
This is one area where the original APL spec was open for
interpretation
(sorry, I couldn't resist). I had to port a lot of IBM mainframe code
to
APL*PLUS/PC, and there were a lot of functions with order of execution
quirks like this.
Apprently aplse (which is mostly equivalent to apl*plus/pc or that is
what
I've heard) does calculate index before the array
V<-'ABCDEF'
V[V<-{rot}{iota}4]
gives results in 1 2 3 4 rather than 'DCBA'. The problem seems to be
that V
is undefined value and if it is assigned some doummy value in some
previous
line, the whole expression works as intended by the author.
In APL2 for OS/2, with v undefined:
v[3{drop}{iota}{rho}v{is}'abcdefgh']
defgh
Obviously, this is a stupid way to do 3{drop}v{is}'abcdefgh', but that
isn't the point.
The point is that the interpreter should not inquire into the binding of
the leftmost v until it is ready to apply the bracket index.
The fact that we all agree that something is a poor programming practice
doesn't mean that it's ok for the interpreter not to work right if a
programmer decides to do it anyway.
If one chooses to write code like that they deserve what they get.
Balderdash. The code is perfectly clear, even if it is a round about way
of accomplishing the objective. Give us an algorithm to identify the
constructions you don't approve of and are going to have your interpreter
do something arbitrary with out of spite. Such an interpreter would be
useless.
Congratulations, you made it not work everywhere.... you get a Gold Star
for being confusing.
Huh?
Read what I wrote. Besides, there's nothing confusing about it. Look at
the code. Here's what happens: (assume {quad}IO=1 for definiteness)
1 'abcdefgh' is assigned to v
2 {rho}'abcdefgh' is computed yielding intermediate result 8
3 {iota}8 is computed yielding intermediate result 1 2 3 4 5 6 7 8
4 3{drop}1 2 3 4 5 6 7 8 is computed yielding intermediate result 4 5 6 7
8
5 The current value of v is consulted and found to be 'abcdefgh'
6 'abcdefgh'[4 5 6 7 8] is computed yielding final result 'defgh'
What's so mysterious or confusing?
Whether you approve of it or not, every step of the way is legitimate APL
and if an interpreter does not do what I said then the interpreter is
wrong, full stop. There is no room for argument or compromise.
Based on the OP's second contribution, it appears that the buggy
interpreter erroneously inserts a step
0 See if v has a value and raise a value error if it doesn't
just for the hell of it, since giving v a dummy value makes the statement
work correctly.
You just won't get (as nice as it would be) every interpreter past and
present to handle dangerously written code the same way.
Kindly give a rigorous definition of "dangerously written code." The fact
that some interpreters don't get it right merely proves that some
interpreters have bugs.
If it were written
in a more straightforward manner (i.e. separate statements) it would workGood grief. How are you going to make this, I hesitate to say concept,
the same since the code was, well, more straightforward and the
interpretation of it not prone to..... misinterpretation :-).
let's just call it a vague idea, rigorously defined?
Perhaps I was being a bit inflammatory. Sorry about that. I get that way
at times.
Code like that is just offensive to me, having managed so much offensive
code.
I think earlier a similar thing was called "porno coding" or somesuch. Boy
is that right on.
Like objectionable material, maybe community standards are hard to define?
I might start by asking one not to redefine a name that is currently
involved in an ongoing operation.
( V <- /*whatever*/ ) + V
or V[V <- /*whatever*/ ]
or name {Quad}FX /*definition of name*/
etc.
(Please don't nitpick what I mean by "ongoing.")
But that's just off the top of my head. It doesn't really matter what the
language is; I've seen
such arguably ambiguous code countless times. If you have to scratch your
head,
or be a language expert, to understand what is going on, and/or read the
manual to bone up on precedence and binding and all that, it's bad. Someone
other than you might have to look at (or
even worse, work on) that stuff someday. Break it up. Make it clear. Help
out the guy who
isn't as clever or up-to-snuff as you. You might even thank yourself some
day down the road
when you have to look at it again.
"Balderdash? The code is perfectly clear?" Not to me.
Remember there is other code around it. V might already have a value.
Stuff like that is almost intentionally bad. I repeat, one deserves what
they get.
I think way back in the day APL/360 was defined such that it always would
evaluate parenthized
expressions first; or (perhaps later on) that there was no guarantee the
order of such execution --
to allow for parallel processing -- to nowadays in APL isn't it the first
function where all
operands are available? I don't know, but the point is why even leave it in
question?
.
- Follow-Ups:
- Re: order of execution
- From: Andrew Nikitin
- Re: order of execution
- References:
- order of execution
- From: Andrew Nikitin
- Re: order of execution
- From: Doug White
- Re: order of execution
- From: Andrew Nikitin
- Re: order of execution
- From: James J. Weinkam
- Re: order of execution
- From: Paul Houle
- Re: order of execution
- From: James J. Weinkam
- order of execution
- Prev by Date: Re: order of execution
- Next by Date: Re: order of execution
- Previous by thread: Re: order of execution
- Next by thread: Re: order of execution
- Index(es):
Relevant Pages
|
|