Home > Archive > Scheme > October 2004 > define order for procedure application, not for LET
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
define order for procedure application, not for LET
|
|
| Bruce Lewis 2004-10-07, 4:00 pm |
| I'm not totally following the thread on order of evaluation, but I did
p in and see one post asking what everybody thought. I don't care
enough about it to discuss ad infinitum, but I have an opinion.
In (f a b c) I think f, a, b and c should be evaluated left to right,
consistent with the left-to-right order of BEGIN and LAMBDA bodies.
Consistency and principle of least surprise are applicable here.
Computer languages are not for defining objective mathematics, but for
the creation of a human-computer interface, where subjective
considerations are important.
I do think there should be a special syntax to indicate that expressions
can be evaluated in any order, allowing for more optimization than is
normally possible. This syntax should be LET.
(let ((a e1) (b e2) (c e3)) (f a b c))
This would indicate that e1, e2 and e3 could be evaluated in any order
the compiler wishes. Programmers who want a specific order should use
LET*.
Extra verbiage is justified when you're getting into
micro-optimizations. For something like this:
((eval (read)) (read) (read) (read))
I think the behavior should be whatever suprises the fewest newbies. I
haven't done a controlled study, but I expect left-to-right evaluation
would be the least surprising.
| |
| Shriram Krishnamurthi 2004-10-07, 4:00 pm |
| Bruce Lewis <brlspam@yahoo.com> writes:
> I do think there should be a special syntax to indicate that expressions
> can be evaluated in any order, allowing for more optimization than is
> normally possible. This syntax should be LET.
>
> (let ((a e1) (b e2) (c e3)) (f a b c))
>
> This would indicate that e1, e2 and e3 could be evaluated in any order
> the compiler wishes. Programmers who want a specific order should use
> LET*.
Minor sin: You're destroying the LET -> ((LAMBDA equivalence. But you
know that. And perhaps that's not such a big deal.
Major sin: You're confusing two different issues: order-of-evaluation
and scope. The real difference between LET and LET* is that they have
different scope rules. You'd need a third construct, LET/ORDERED,
which preserves the scope of LET but allows ordering. (The fourth
combination, LET*/UNORDERED, doesn't make sense... but its
first-cousin, LET*/PARTIAL-ORDERED, does. Any programmer who uses
this construct should be summarily hauled out to the woodshed.)
> I think the behavior should be whatever suprises the fewest newbies. I
> haven't done a controlled study, but I expect left-to-right evaluation
> would be the least surprising.
At least if you aren't from the Middle East (though at least in
Arabic, the numbers march rightwards -- dunno any Hebrew).
Shriram
| |
| Matthias Blume 2004-10-07, 4:00 pm |
| Shriram Krishnamurthi <sk@cs.brown.edu> writes:
>
> At least if you aren't from the Middle East (though at least in
> Arabic, the numbers march rightwards -- dunno any Hebrew).
Let's say it should match the directionality of how programs are
written as strings of characters.
In other words, in the language emehcS where the identify function is
written
(x (x) adbmal)
I can see that one would want right-to-left order(*).
:-)
Matthias
(*) Or should that have been
)x )x( adbmal(
?
Or, maybe,
(x (x) abdmal)
??
:) :)
| |
| Antoun Kanawati 2004-10-07, 4:00 pm |
| Bruce Lewis wrote:
> I'm not totally following the thread on order of evaluation, but I did
> p in and see one post asking what everybody thought. I don't care
> enough about it to discuss ad infinitum, but I have an opinion.
>
> In (f a b c) I think f, a, b and c should be evaluated left to right,
> consistent with the left-to-right order of BEGIN and LAMBDA bodies.
> Consistency and principle of least surprise are applicable here.
> Computer languages are not for defining objective mathematics, but for
> the creation of a human-computer interface, where subjective
> considerations are important.
For function calls, left-to-right is not necessarily the right thing
to do, even without optimization.
A simple order of evaluation for applications would be: right-to-left;
the procedure's value is the last thing you need, and keeping it around
while you're evaluating the args is just a waste of register and/or
temporary space.
Then, there are macros and special forms, where the leftmost symbol
controls everything about the rest of the expression. But, to the naked
eye, they look exactly like applications, but depending on how they
expand, the order of evaluation can be arbitrary relative to the
original positions of the expressions.
Also, the language provides special notation for asserting sequence;
like begin and let*.
So, there is little surprise involved: everything is arbitrary order,
unless you use one of the sequence asserting forms.
Basically, left-to-right imposes unreasonable restraints on the
some aspects of implementation, right-to-left would do so for others.
You can also see this issue in languages like C/C++. The
argument evaluation sequence is related to the expected
stack layout on the callee side, and not on the textual
sequence of the arguments at the call site. The stack layouts
(first arg on top, or last arg on top) dictate different
evaluation sequences, if you're trying to keep things simple.
For example: foo(1, 2, 3) is either:
push 1 ; pascal style
push 2
push 3
call foo
or
push 3 ; C-style
push 2
push 1
call foo
depending on foo's calling conventions.
If you fix the order of evaluation, one of the above alternatives
becomes more complex and usually more expensive at runtime.
--
A. Kanawati
NO.antounk.SPAM@comcast.net
| |
| Matthias Blume 2004-10-07, 4:00 pm |
| Antoun Kanawati <NO.antounk.SPAM@comcast.net> writes:
> the procedure's value is the last thing you need, and keeping it around
> while you're evaluating the args is just a waste of register and/or
> temporary space.
I'm not sure what you mean. In a call-by-value setting, you need all
the things in the call -- every argument and also the function. There
is no "it's the last thing you need".
In a call-by-need (lazy) setting, it is even worse: The function is
the /first/ thing you need, and it might be the /only/ thing you need.
> Then, there are macros and special forms, where the leftmost symbol
> controls everything about the rest of the expression. But, to the naked
> eye, they look exactly like applications, but depending on how they
> expand, the order of evaluation can be arbitrary relative to the
> original positions of the expressions.
This is one of the problems with macros, indeed.
> Basically, left-to-right imposes unreasonable restraints on the
> some aspects of implementation, right-to-left would do so for others.
"Unreasonable" is in the eye of the beholder. I dispute that the
constraints are unreasonable. Leaving the order unspecified, however,
does constrain the programmer. Personally, I find those constraints
annoying, if not outright unreasonable.
> You can also see this issue in languages like C/C++.
Oh boy. Now we are defending language design based on what? C and
C++?
> The argument evaluation sequence is related to the expected stack
> layout on the callee side, and not on the textual sequence of the
> arguments at the call site.
That's an implementation detail which I, as a programmer in a
high-level language, should not have to worry about.
Matthias
| |
| Shriram Krishnamurthi 2004-10-07, 4:00 pm |
| Antoun Kanawati <NO.antounk.SPAM@comcast.net> writes:
> Basically, left-to-right imposes unreasonable restraints on the
> some aspects of implementation, right-to-left would do so for others.
Can you name three Scheme implemenetations that actually exploit the
fact that they aren't being "unreasonably constrained"?
Shriram
| |
| Barry Margolin 2004-10-07, 8:57 pm |
| In article <nm9u0t6fu22.fsf@no-knife.mit.edu>,
Bruce Lewis <brlspam@yahoo.com> wrote:
> Computer languages are not for defining objective mathematics, but for
> the creation of a human-computer interface, where subjective
> considerations are important.
You seem to be forgetting that Scheme was created primarily for
pedagogic purposes. Thus, the objective mathematical aspects of the
language are considered important.
If you want a more practical language, use Common Lisp.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Taylor Campbell 2004-10-08, 3:57 am |
| Shriram Krishnamurthi <sk@cs.brown.edu> wrote in message news:<w7d4ql64gfy.fsf@cs.brown.edu>...
> Antoun Kanawati <NO.antounk.SPAM@comcast.net> writes:
>
>
> Can you name three Scheme implemenetations that actually exploit the
> fact that they aren't being "unreasonably constrained"?
SISC (which does all loops backwards, i.e. uses a right-to-left order,
because comparison to zero may be faster), T with Orbit (which permutes
arguments as desired by their cost to minimize shuffling of registers &
the stack for temporary storage), Larceny with Twobit (for parallel
assignment optimization), and LIAR of MIT Scheme also, I believe,
performs some argument ordering analysis, though I know nothing about
it except its existence. (I list four because I doubt you'd consider
T/Orbit a useful answer.)
| |
| William D Clinger 2004-10-08, 3:57 am |
| > > Basically, left-to-right imposes unreasonable restraints on the
>
> Can you name three Scheme implemenetations that actually exploit the
> fact that they aren't being "unreasonably constrained"?
>
> Shriram
Yes. What is your point?
Will
| |
| Shriram Krishnamurthi 2004-10-08, 3:57 am |
| cesuraSPAM@verizon.net (William D Clinger) writes:
>
> Yes. What is your point?
I didn't know of modern Scheme implementations other than Larceny that
actually do exploit this.
People could defend unspecified ordering as a matter of principle, but
many do so as a matter of pragmatics. I wanted to know what the true
pragmatics of the situation was, ie, how many blazingly fast Scheme
compilers blaze a little faster because of this convenience. (I would
be especially interested in hearing just how much faster they run, but
that's asking a lot of someone who doesn't have the data handy. This
goes to the unreasonableness of the constraint.)
Shriram
| |
| Abdulaziz Ghuloum 2004-10-08, 3:57 am |
| Shriram Krishnamurthi wrote:
> cesuraSPAM@verizon.net (William D Clinger) writes:
>
>
>
>
> I didn't know of modern Scheme implementations other than Larceny that
> actually do exploit this.
>
> People could defend unspecified ordering as a matter of principle, but
> many do so as a matter of pragmatics. I wanted to know what the true
> pragmatics of the situation was, ie, how many blazingly fast Scheme
> compilers blaze a little faster because of this convenience. (I would
> be especially interested in hearing just how much faster they run, but
> that's asking a lot of someone who doesn't have the data handy. This
> goes to the unreasonableness of the constraint.)
>
> Shriram
I would like to note that Chez Scheme is another implementation that
rearranges the arguments to achieve better register allocation.
<quote section=2.3>
By not fixing the order of evaluation for arguments before register
allocation, the compiler can determine an ordering that requires a
minimal amount of shuffling, and sometimes it can avoid shuffling
altogether.
</quote>
Also,
<quote section=3.1>
Finding the ordering of arguments that minimizes the number of
temporaries is NP-complete. We tried an exhaustive search and found that
our greedy approach works optimally for the vast majority of all cases,
mainly because most dependency graph cycles are simple. In our
benchmarks, only 7% of the call sites had cycles. Furthermore, the
greedy algorithm was optimal for all of the call sites in all of the
benchmarks excluding our compiler, where it was optimal in all but six
of the 20,245 call sites, and in these six it required only one extra
temporary location.
</quote>
See:
Robert G. Burger, Oscar Waddell, R. Kent Dybvig: Register Allocation
Using Lazy Saves, Eager Restores, and Greedy Shuffling. PLDI 1995: 130-138
| |
| Abdulaziz Ghuloum 2004-10-08, 3:57 am |
| Abdulaziz Ghuloum wrote:
>
> I would like to note that Chez Scheme is another implementation that
> rearranges the arguments to achieve better register allocation.
>
Arghhh. Not rearrange the arguments. Rather, arrange the order of
evaluation.
| |
| Antoun Kanawati 2004-10-08, 9:10 am |
| Shriram Krishnamurthi wrote:
> Antoun Kanawati <NO.antounk.SPAM@comcast.net> writes:
>
> Can you name three Scheme implemenetations that actually exploit the
> fact that they aren't being "unreasonably constrained"?
Nope, I cannot. I was commenting from an 'any-language' perspective.
And, in general (hand waving and all that stuf), it is often considered
"unreasonable" to ask for anything that may, under some circumstances,
cost a few extra cycles, or inhibit optimization.
It may be that in Scheme things are so different, that fixing order
of evaluation is a totally cost-free option, and I am completely
wrong.
Anyway, it was just an opinion, given lightly, not an authoritative
assertion that needs to be footnoted and all that.
--
A. Kanawati
NO.antounk.SPAM@comcast.net
| |
| Antoun Kanawati 2004-10-08, 9:10 am |
| Shriram Krishnamurthi wrote:
> People could defend unspecified ordering as a matter of principle, but
> many do so as a matter of pragmatics. I wanted to know what the true
> pragmatics of the situation was, ie, how many blazingly fast Scheme
> compilers blaze a little faster because of this convenience. (I would
> be especially interested in hearing just how much faster they run, but
> that's asking a lot of someone who doesn't have the data handy. This
> goes to the unreasonableness of the constraint.)
While I have not studied the various implementations of Scheme in
detail, I've had enough training in languages to know that a fixed
order of evaluation is not a cost-free option. And, it is my
experience (and that's totally subjective) that cost is often
considered unreasonable unless there is something seriously
broken.
So, is unspecified order so broken that it is worth using more
registers, or more instructions, etc...?
--
A. Kanawati
NO.antounk.SPAM@comcast.net
| |
| Matthias Blume 2004-10-08, 9:10 am |
| Antoun Kanawati <NO.antounk.SPAM@comcast.net> writes:
> So, is unspecified order so broken that it is worth using more
> registers, or more instructions, etc...?
Yes.
(By the way, in VSCM I also tried to take advantage of the fact that
OoE is not specified. I have repented since.)
Matthias
| |
| Marcin 'Qrczak' Kowalczyk 2004-10-08, 3:58 pm |
| Antoun Kanawati <NO.antounk.SPAM@comcast.net> writes:
> While I have not studied the various implementations of Scheme in
> detail, I've had enough training in languages to know that a fixed
> order of evaluation is not a cost-free option.
It has a cost when evaluation of some arguments requires calls to
unknown code, while evaluation of others is expanded inline and is
known to not clobber registers, e.g. variable references. Arguments
of the latter kind should be evaluated last.
But if the compiler performs an analysis to see which variables
are ever reassigned, then it matters only for reassigned variables.
Constant variables can be evaluated at any time without changing
the semantics.
I would guess that Scheme implementations which perform some
optimizations at all do perform such analysis for local variables
(it's useful to choose the representation of closures), but they
rarely perform it for global variables because it would require
whole-program analysis - unless they disallow rebinding variables
imported from other modules, where it again can be done locally.
--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
| |
| Joe Marshall 2004-10-08, 3:58 pm |
| Shriram Krishnamurthi <sk@cs.brown.edu> writes:
> cesuraSPAM@verizon.net (William D Clinger) writes:
>
>
> I didn't know of modern Scheme implementations other than Larceny that
> actually do exploit this.
MIT Scheme
| |
| William D Clinger 2004-10-09, 3:56 am |
| Perhaps a simple example of common subexpression elimination
would help. Consider
(define (f g x)
(if (null? x)
'()
(cons (list (g (car x)) (car x))
(f g (cdr x)))))
With R5RS semantics, this definition says that a programmer
or compiler is free to transform the definition into
(define (f g x)
(if (null? x)
'()
(cons (let ((cx (car x)))
(list (g cx) cx))
(f g (cdr x)))))
With a fixed left-to-right order of evaluation, that
transformation would be illegal unless we knew quite a
bit about g. The R5RS semantics allowed the programmer
to tell us what we needed to know about g simply by
writing the first definition. With a fixed left-to-right
order of evaluation, that information could be expressed
by a comment, but most programmers wouldn't bother, and
a comment wouldn't help the compiler anyway.
So this is a very simple example of what people mean when
they claim that the R5RS semantics is more expressive than
a fixed order of evaluation. It is possible to argue that
this information shouldn't be expressible, or that the
value of expressing it in this way isn't worth the harm,
or that programmers are so unreliable that we shouldn't
trust their programs (and should burn programs instead of
compiling them), but it is wrong to argue that the R5RS
semantics doesn't allow this information to be expressed.
Will
| |
| William D Clinger 2004-10-09, 3:56 am |
| By the way, I should credit Marcin 'Qrczak' Kowalczyk
<qrczak@knm.org.pl> for the example of my previous post.
Marcin wrote:
>
> It has a cost when evaluation of some arguments requires calls to
> unknown code, while evaluation of others is expanded inline and is
> known to not clobber registers, e.g. variable references. Arguments
> of the latter kind should be evaluated last.
My example is a counterexample to that.
> But if the compiler performs an analysis to see which variables
> are ever reassigned, then it matters only for reassigned variables.
My example is also a counterexample to that. It matters for
mutable data structures as well as mutable variables. Lists
are, alas, mutable in Scheme.
> Constant variables can be evaluated at any time without changing
> the semantics.
This is true, of course.
> I would guess that Scheme implementations which perform some
> optimizations at all do perform such analysis for local variables
> (it's useful to choose the representation of closures), but they
> rarely perform it for global variables because it would require
> whole-program analysis - unless they disallow rebinding variables
> imported from other modules, where it again can be done locally.
This is also true.
Will
| |
| Matthias Blume 2004-10-09, 3:56 am |
| cesuraSPAM@verizon.net (William D Clinger) writes:
> Perhaps a simple example of common subexpression elimination
> would help. Consider
>
> (define (f g x)
> (if (null? x)
> '()
> (cons (list (g (car x)) (car x))
> (f g (cdr x)))))
>
> With R5RS semantics, this definition says that a programmer
> or compiler is free to transform the definition into
>
> (define (f g x)
> (if (null? x)
> '()
> (cons (let ((cx (car x)))
> (list (g cx) cx))
> (f g (cdr x)))))
You just got lucky here (although I'm pretty sure you saw to it that
you would get lucky).
Try this minor modification:
(define (f g h x)
(if (null? x)
'()
(cons (list (g (car x)) (h (car x)))
(f g h (cdr x)))))
Now it is suddenly no longer true that...
> ... The R5RS semantics allowed the programmer
> to tell us what we needed to know about g simply by
> writing the first definition.
Yes, fewer programs are legal, so by a simple information-theoretic
argument it is obvious that having a legal program carries more
information. But I can't see how a believable case can be made that
the whole thing really is worth any trouble.
Matthias
| |
| Ron Garret 2004-10-09, 3:56 am |
| In article <fb74251e.0410081952.7696e6d5@posting.google.com>,
cesuraSPAM@verizon.net (William D Clinger) wrote:
> Perhaps a simple example of common subexpression elimination
> would help. Consider
>
> (define (f g x)
> (if (null? x)
> '()
> (cons (list (g (car x)) (car x))
> (f g (cdr x)))))
>
> With R5RS semantics, this definition says that a programmer
> or compiler is free to transform the definition into
>
> (define (f g x)
> (if (null? x)
> '()
> (cons (let ((cx (car x)))
> (list (g cx) cx))
> (f g (cdr x)))))
>
> With a fixed left-to-right order of evaluation, that
> transformation would be illegal unless we knew quite a
> bit about g.
Actually, I'm pretty sure that this transformation is illegal unless you
know quite a bit about CAR. If I do:
(define (car x) (set! y (+ y 1))
or
(define car display)
then that transformation changes the program semantics rather radically.
On the other hand, if you assume that CAR means what it usually means,
then the transformation preserves the program semantics regardless of
the order of evaluation and regardless of what G does.
In any case, this example seems like a red herring to me.
rg
| |
| Thant Tessman 2004-10-09, 4:23 pm |
| Matthias Blume wrote:
[...]
> Yes, fewer programs are legal, so by a simple information-theoretic
> argument it is obvious that having a legal program carries more
> information. [...]
I don't understand this. If the information is about whether a program
is legal, and given the supposition that it is less likely that a given
program is legal, then yeah, you know more if you know a given program
is legal. But if you view the program as a means of encoding information
where it's the execution of a program that decodes the information, then
my intuition tells me that fewer legal programs implies fewer possible
ways of encoding information, which means in some sense you know less.
Eh?
-thant
| |
| Thant Tessman 2004-10-09, 4:23 pm |
| Thant Tessman wrote:
> Matthias Blume wrote:
>
> [...]
>
>
>
> I don't understand this. If the information is about whether a program
> is legal, and given the supposition that it is less likely that a given
> program is legal, then yeah, you know more if you know a given program
> is legal.
And of course the point with respect to the rest of this topic is that
merely declaring OofE unspecified by itself tells you nothing about
whether a given program suddenly becomes illegal.
-thant
| |
| William D Clinger 2004-10-09, 4:23 pm |
| Ron Garret <rNOSPAMon@flownet.com> wrote:
> Actually, I'm pretty sure that this transformation is illegal unless you
> know quite a bit about CAR....
That's true. I thought that went without saying, since there
are very few opportunities for CSE in Scheme unless the
programmer informs the compiler that certain primitives won't
be redefined. There is no standard way for the programmer to
say that, but the ability to say that is so important that
every Scheme compiler I know about provides some way to say it.
> On the other hand, if you assume that CAR means what it usually means,
> then the transformation preserves the program semantics regardless of
> the order of evaluation and regardless of what G does.
That's not true.
Will
| |
| Taylor Campbell 2004-10-09, 4:23 pm |
| (Sorry about the huge load of quoted text, but I felt it necessary to
keep the original context.)
Ron Garret <rNOSPAMon@flownet.com> wrote in message news:<rNOSPAMon-8551ED.21365408102004@nntp1.jpl.nasa.gov>...
> In article <fb74251e.0410081952.7696e6d5@posting.google.com>,
> cesuraSPAM@verizon.net (William D Clinger) wrote:
>
>
> Actually, I'm pretty sure that this transformation is illegal unless you
> know quite a bit about CAR. If I do:
>
> (define (car x) (set! y (+ y 1))
>
> or
>
> (define car display)
>
> then that transformation changes the program semantics rather radically.
Most reasonable Scheme compilers have some way to specify that all the
standard names are bound to their standard values. More sophisticated
ones using reasonable module systems make the information simpler to
acquire, as long as the module system allows assignment only to module-
local variables (i.e. none of those imported from the R5RS module).
> On the other hand, if you assume that CAR means what it usually means,
> then the transformation preserves the program semantics regardless of
> the order of evaluation and regardless of what G does.
G may modify the input list. Although it gets only the CAR of the
current X, it may be a closure whose environment contains a reference
to some earlier cell in the original input list.
| |
| Ron Garret 2004-10-09, 4:23 pm |
| In article <fb74251e.0410090654.76528761@posting.google.com>,
cesuraSPAM@verizon.net (William D Clinger) wrote:
>
> That's not true.
Ah, you're right, my mistake. Ironically, by forcing me to think harder
about this you have managed to convince me of exactly the opposite of
what you were trying to show.
Consider this simple variation of your original example:
(define (f g h x)
(if (null? x)
'()
(cons (list (g (car x)) (h (car x)))
(f g h (cdr x)))))
Now CSE is illegal even under an unspecified OoE unless you know, as you
put it, quite a bit about both g and h. What's more, the only way to
"express" the fact that G and H are such that CSE is legal is to do the
CSE manually.
So I used to believe that unspecified OoE *did* add expressiveness to
the language, but now I am not at all certain that this is so.
rg
| |
| William D Clinger 2004-10-09, 4:23 pm |
| > But I can't see how a believable case can be made that
> the whole thing really is worth any trouble.
>
> Matthias
I agree. This entire issue isn't worth the bickering. I'm
seeing people I respect snipe at each other. I'm seeing
relatively uninformed people insulting some of the most
experienced and thoughtful people in this newsgroup.
Ralph London would call this a paper-clip issue. In large
organizations, small groups of experts routinely decide things
that have enormous consequences for the organization. When it
comes time to order paper clips, however, everyone wants in on
the decision, because everyone has experience with and thinks
they understand paper clips. If the organization allows
everyone who has an opinion on paper clips to get involved,
they'll never agree on what kind of paper clips to order.
If we could eliminate the bickering by changing the language,
I'd be for it. The problem is that, while there are quite a
few people saying we should change the language, they aren't
agreeing on how the language should be changed.
I have seen people saying that all they want is a syntactic
sugar for imposing some fixed order of evaluation on the
subexpressions of a procedure call, and would be happy so
long as that syntactic sugar is just as convenient as the
existing notation for procedure calls, which would remain
in the language (with unspecified order of evaluation).
I have seen people saying they want to impose some fixed
order of evaluation on the subexpressions of a procedure
call, while preserving the unspecified order of evaluation
for LET expressions. Hence this thread.
I have seen people saying we ought to have several different
standard modes, with different order-of-evaluation semantics
for each mode.
I have seen people saying they want to fix the order of
evaluation for everything, and are opposed to features that
allow programmers to express a "don't care" attitude toward
the order of evaluation.
I have seen people saying they would be happy with a fixed
order of evaluation for everything, provided the order of
evaluation is so irregular and/or obscure as to discourage
programmers from relying upon it deliberately.
I have seen people saying that a true left-to-right order of
evaluation is the most intuitive and least surprising.
I have seen people saying that arguments should be evaluated
from left to right, followed by evaluation of the procedure
expression. This is probably the order of evaluation that
would be least surprising to beginners, but I have seen some
evidence (even within this thread) that it is what many more
experienced programmers are likely to expect as well.
I have tried to make some sense of what people have been
saying in these threads, but it is difficult. Saying that
the semantics of Scheme ought to be changed, in the absence
of agreement on how the semantics ought to change, is not
helpful. It is better to say that the semantics of Scheme
can be changed, but we must first arrive at some sense of
agreement on the advantages and di vantages of proposed
changes, and then build some degree of consensus in favor
of some specific proposal. Bickering doesn't get it done.
Will
| |
| Pascal Costanza 2004-10-09, 4:23 pm |
|
William D Clinger wrote:
> If we could eliminate the bickering by changing the language,
> I'd be for it. The problem is that, while there are quite a
> few people saying we should change the language, they aren't
> agreeing on how the language should be changed.
(declaim (evaluation-order unspecified))
; explicitly allows the compiler to do
; whatever it thinks is most suitable
; must be accepted by all Scheme implementations
(declaim (evaluation-order left-to-right))
; evaluates everything from left to right
; if not supported, must signal an error
(declaim (evaluation-order shuffle))
; chooses a random evaluation order on each
; function call, for pedagogical or testing purposes
; if not supported, must signal an error
(declaim (evaluation-order params-l2r-then-function))
; ...
; if not supported, must signal an error
etc.
Maybe there is even a way to say this:
(declaim (evaluation-order (lambda lst ...)))
"declaim" is probably too Common-Lispish, but you get the idea...
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
| |
| David Rush 2004-10-11, 4:00 pm |
| Antoun Kanawati <NO.antounk.SPAM@comcast.net> writes:
> For function calls, left-to-right is not necessarily the right thing
> to do, even without optimization.
>
<chop/>
>
> Then, there are macros and special forms, where the leftmost symbol
> controls everything about the rest of the expression. But, to the naked
> eye, they look exactly like applications, but depending on how they
> expand, the order of evaluation can be arbitrary relative to the
> original positions of the expressions.
This is the gripping hand in this argument. For redundancy's sake: As
long as we have macros in the language you have no guarantee of
argument evaluation ordering in the general case.
david rush
--
Scheme: Because everything is a function.
-- Anton van Straaten (the Scheme Marketing Dept from c.l.s)
| |
| Matthias Blume 2004-10-11, 4:00 pm |
| David Rush <kumoyuki@gmail.com> writes:
> This is the gripping hand in this argument. For redundancy's sake: As
> long as we have macros in the language you have no guarantee of
> argument evaluation ordering in the general case.
So shall we also drop the requirement that all arguments be evaluated
before the function call? You know, we have IF in the language, and
as long as we have IF in the language you have no guarantee of
arguments being evaluated at all in the general case.
Matthias
| |
| Joe Marshall 2004-10-12, 3:58 pm |
| Ron Garret <rNOSPAMon@flownet.com> writes:
> Consider this simple variation of your original example:
>
> (define (f g h x)
> (if (null? x)
> '()
> (cons (list (g (car x)) (h (car x)))
> (f g h (cdr x)))))
>
> Now CSE is illegal even under an unspecified OoE unless you know, as you
> put it, quite a bit about both g and h. What's more, the only way to
> "express" the fact that G and H are such that CSE is legal is to do the
> CSE manually.
Yep. You can write code where you cannot perform CSE.
But what about Will's original example?
| |
| Ron Garret 2004-10-12, 8:57 pm |
| In article <hdp0m198.fsf@ccs.neu.edu>, Joe Marshall <jrm@ccs.neu.edu>
wrote:
> Ron Garret <rNOSPAMon@flownet.com> writes:
>
>
> Yep. You can write code where you cannot perform CSE.
>
> But what about Will's original example?
What about it?
rg
| |
| William D Clinger 2004-10-13, 3:57 am |
| Ron Garret <rNOSPAMon@flownet.com> quoting Joe Marshall:
>
> What about it?
As a matter of logic, the fact that CSE is not always possible
has no bearing on the fact that CSE is more often possible with
some semantics than with others.
A very few people, who may have cared more about understanding
the issues than in winning some kind of flame war, asked for
examples that might help them to understand why an unspecified
order of evaluation offers more opportunities for optimization
than a left-to-right order of evaluation. My example satisfies
that request. Ron's does not.
Will
| |
| Ron Garret 2004-10-13, 3:57 am |
| In article <fb74251e.0410122042.19d20f43@posting.google.com>,
cesuraSPAM@verizon.net (William D Clinger) wrote:
> Ron Garret <rNOSPAMon@flownet.com> quoting Joe Marshall:
>
> As a matter of logic, the fact that CSE is not always possible
> has no bearing on the fact that CSE is more often possible with
> some semantics than with others.
That was never in dispute.
> A very few people, who may have cared more about understanding
> the issues than in winning some kind of flame war, asked for
> examples that might help them to understand why an unspecified
> order of evaluation offers more opportunities for optimization
> than a left-to-right order of evaluation. My example satisfies
> that request. Ron's does not.
My example serves to illustrate that the instances in which unspecified
OoE permits CSE may be more restricted than one might suppose from
seeing Will's example in isolation.
rg
| |
| Bradd W. Szonye 2004-10-21, 8:57 pm |
| Antoun Kanawati writes:
Matthias Blume wrote:[color=darkred]
> Yes.
If it were a great source of defects, you might reasonably argue that
the lost productivity and bugfixing costs outweighed the modest
opportunities for optimization. However, you've recently agreed that
unspecified order causes nigh /zero/ defects. How do you reconcile this?
--
Bradd W. Szonye
http://www.szonye.com/bradd
|
|
|
|
|