Home > Archive > Scheme > October 2004 > order of evaluation?
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 |
order of evaluation?
|
|
|
| Given the expression (foo (bar 3) baz (bing 8)), what is the order
of evaluation? I can see some interpreters that will parse the tree
to the lowest element/atom, start puting the values on some stack,
and work backwards:
8 <-
-> bing
baz <-
3 <-
-> foo
I can also see this expression:
(if (= foo 1) (bar 3) (baz 4))
that is is more efficient to evalute the '(=', then evaluate the
'(if', and let the if evaluate the selected expression.
Which way is it done?
Mike
| |
| Anton van Straaten 2004-09-30, 8:59 pm |
| Mike wrote:
> Given the expression (foo (bar 3) baz (bing 8)), what is the order
> of evaluation? I can see some interpreters that will parse the tree
> to the lowest element/atom, start puting the values on some stack,
> and work backwards:
>
> 8 <-
> -> bing
> baz <-
> 3 <-
> -> foo
>
> I can also see this expression:
>
> (if (= foo 1) (bar 3) (baz 4))
>
> that is is more efficient to evalute the '(=', then evaluate the
> '(if', and let the if evaluate the selected expression.
>
> Which way is it done?
There are a few related questions implicit above...
> (foo (bar 3) baz (bing 8))
Scheme calls ordinary functions using a call-by-value approach, in which all
a function's arguments are evaluated before a function is ever called, so if
foo is an ordinary function (as opposed to e.g. a macro), you know that (bar
3), baz, and (bing 8) will all be evaluated before foo is called.
However, the order in which these arguments are evaluated happens is not
specified in R5RS, and varies between Scheme implementations. Some do it
left to right, some do it right to left, and other orders are possible. A
parallel implementation of Scheme might even evaluate the arguments
concurrently. This means that if you want to write Scheme code that's at
all portable, you should avoid depending on order of evalutation within
ordinary expressions. If you need to specify an order of evaluation, you
should use an appropriate form such as LET* or BEGIN, which sequences its
contents.
> (if (= foo 1) (bar 3) (baz 4))
>
> that is is more efficient to evalute the '(=', then evaluate the
> '(if', and let the if evaluate the selected expression.
The IF construct in Scheme is not an ordinary function. In a call-by-value
language like Scheme, using an ordinary function for IF would mean that both
its branches would have to be evaluated, even though the result of only one
is used. Aside from performance issues, this could cause problems if the
unneeded branch has side effects. To address this, IF is built-in syntax in
Scheme, and it works as you say: the condition is evaluated first, and then
either the consequent or the antecedent is evaluated, depending on the
result of the condition.
In general, if you need to define operations in Scheme which don't use call
by value, you can do it by defining a macro. IF behaves like a macro,
although whether it's actually implemented as one depends on the Scheme
implementation. (It's possible to implement IF as a macro in terms of COND,
or vice versa, but usually one or the other, or some other means of making a
choice, is needed at a primitive level.)
Anton
| |
|
| In article <Zi_6d.5610$ls6.1752@newsread3.news.atl.earthlink.net>, Anton van Straaten wrote:
> Mike wrote:
>
> There are a few related questions implicit above...
>
>
> Scheme calls ordinary functions using a call-by-value approach, in which all
> a function's arguments are evaluated before a function is ever called, so if
> foo is an ordinary function (as opposed to e.g. a macro), you know that (bar
> 3), baz, and (bing 8) will all be evaluated before foo is called.
>
> However, the order in which these arguments are evaluated happens is not
> specified in R5RS, and varies between Scheme implementations. Some do it
> left to right, some do it right to left, and other orders are possible. A
> parallel implementation of Scheme might even evaluate the arguments
> concurrently. This means that if you want to write Scheme code that's at
> all portable, you should avoid depending on order of evalutation within
> ordinary expressions. If you need to specify an order of evaluation, you
> should use an appropriate form such as LET* or BEGIN, which sequences its
> contents.
>
>
> The IF construct in Scheme is not an ordinary function. In a call-by-value
> language like Scheme, using an ordinary function for IF would mean that both
> its branches would have to be evaluated, even though the result of only one
> is used. Aside from performance issues, this could cause problems if the
> unneeded branch has side effects. To address this, IF is built-in syntax in
> Scheme, and it works as you say: the condition is evaluated first, and then
> either the consequent or the antecedent is evaluated, depending on the
> result of the condition.
>
> In general, if you need to define operations in Scheme which don't use call
> by value, you can do it by defining a macro. IF behaves like a macro,
> although whether it's actually implemented as one depends on the Scheme
> implementation. (It's possible to implement IF as a macro in terms of COND,
> or vice versa, but usually one or the other, or some other means of making a
> choice, is needed at a primitive level.)
>
> Anton
>
>
Wonderful explanation and just what I was asking for.
Mike
| |
| M. Paradis 2004-10-01, 8:57 pm |
| Is there any utility to the order of evaluation being unspecified?
Is it :
a) that a fixed order would produce some unwanted theoretical effect?
b) to discourage some programming methods?
c) because the choice of the order of evaluation would be arbitrary?
d) because no consensus have been reached regarding this issue?
e) something else?
I'm no scheme expert, far from it, but I use it everyday, and I
wondered : is this ambiguity responsible for the only circumstances
where one can look at valid R5RS scheme code, and not be able to
predict the result of the evaluation ?
Thanks, M.P.
| |
| Nic Ferrier 2004-10-01, 8:57 pm |
| mathieu.paradis@logik3d.com (M. Paradis) writes:
> Is there any utility to the order of evaluation being unspecified?
> Is it :
> a) that a fixed order would produce some unwanted theoretical effect?
> b) to discourage some programming methods?
> c) because the choice of the order of evaluation would be arbitrary?
> d) because no consensus have been reached regarding this issue?
> e) something else?
>
> I'm no scheme expert, far from it, but I use it everyday, and I
> wondered : is this ambiguity responsible for the only circumstances
> where one can look at valid R5RS scheme code, and not be able to
> predict the result of the evaluation ?
I think the point is that you are supposed to write code that does not
depend on any one order of evaluation, so your code will always
execute the same no matter what Scheme you're using.
This is quite a common requirement in high level languages, or at
least it used to be. Others that follow this are:
C, BCPL, Ada and Pascal I seem to remember
Maybe this is Algol's fault.
AFAIK the reason for this is that it frees compiler implementors to
pursue different compilation strategys. For example, with Scheme it
can be quite efficient to evaluate function call arguments from right
to left (ie: backwards to the way westerners read code).
Having said that, IMHO the time for such efficiencies is past and
Scheme should be speced as evaling from left to right.
One of the practical things that makes Java popular is that the order
of eval is speced left to right. It does make it simpler for the
programmer.
--
Nic Ferrier
http://www.tapsellferrier.co.uk
| |
| Ray Dillinger 2004-10-01, 8:57 pm |
| M. Paradis wrote:
> Is there any utility to the order of evaluation being unspecified?
> Is it :
> a) that a fixed order would produce some unwanted theoretical effect?
> b) to discourage some programming methods?
> c) because the choice of the order of evaluation would be arbitrary?
> d) because no consensus have been reached regarding this issue?
> e) something else?
I think it's mostly (d), because there were right-to-left
and left-to-right schemes when that spec was first written,
and still are. But it stays in the standard too, because
f) by choosing an arbitrary order of evaluation, a compiler
can often find optimizations that cut as much as 10% off the
time required to evaluate an expression.
Bear
| |
| Daniel C. Wang 2004-10-01, 8:57 pm |
| Ray Dillinger wrote:
{stuff deleted}
still are. But it stays in the standard too, because
>
> f) by choosing an arbitrary order of evaluation, a compiler
> can often find optimizations that cut as much as 10% off the
> time required to evaluate an expression.
Citation? I strongly suspect this really is no longer the case on modern
out-of order RISC machines with lots of registers.
| |
| Scott G. Miller 2004-10-02, 3:56 am |
| Daniel C. Wang wrote:
> Ray Dillinger wrote:
>
> {stuff deleted}
>
> still are. But it stays in the standard too, because
>
>
>
> Citation? I strongly suspect this really is no longer the case on modern
> out-of order RISC machines with lots of registers.
>
>
Ack, I sense a repeated flame fest beginning. Please read the thread
starting at:
http://groups.google.com/groups?sel...its.indiana.edu
.... before beginning.
Scott
| |
| Andreas Krey 2004-10-02, 8:59 am |
| * Nic Ferrier (nferrier@tapsellferrier.co.uk)
....
[Argument evaluation order]
>
> This is quite a common requirement in high level languages, or at
> least it used to be. Others that follow this are:
>
> C, BCPL, Ada and Pascal I seem to remember
>
Actually C does not even require the arguments to be evaluated
one at a time. In (the C equivalent of)
(e (d (a)) (c (b)))
the functions may be invoked in alphabetical order. Is that
allowed in Scheme, too?
Andreas
--
np: 4'33
| |
| Matthias Blume 2004-10-04, 4:06 pm |
| mathieu.paradis@logik3d.com (M. Paradis) writes:
> Is there any utility to the order of evaluation being unspecified?
> Is it :
> a) that a fixed order would produce some unwanted theoretical effect?
Depends on what you want. (The answer is "yes" if, e.g., you don't
like unambiguous semantics.)
In any case, as I have said many times before: Every program that is
legal and correct under unspecified evaluation order is obviously
legal and correct under a specified order. The opposite is not true,
and it is difficult to establish trough testing which programs are the
ones that make up the difference. (That's because most
implementations actually do implement some fixed order, so it is
difficult to test other legal schedules which your compiler happens to
not use.)
> b) to discourage some programming methods?
Supposedly, according to some. I don't believe it one second, though.
(I'm NOT going to again about this again! Bradd, did you hear me?)
> c) because the choice of the order of evaluation would be arbitrary?
Many other things are "arbitrary", too.
> d) because no consensus have been reached regarding this issue?
That's definitely a large part of the story.
> e) something else?
Some compilers can squeeze out some extra performance from some
programs.
> I'm no scheme expert, far from it, but I use it everyday, and I
> wondered : is this ambiguity responsible for the only circumstances
> where one can look at valid R5RS scheme code, and not be able to
> predict the result of the evaluation ?
Note quite, but arguably it is the most serious reason.
Matthias
| |
| Matthias Blume 2004-10-04, 4:06 pm |
| Matthias Blume <find@my.address.elsewhere> writes:
> (I'm NOT going to again about this again! Bradd, did you hear me?)
s/again/argue/
| |
| Bradley J Lucier 2004-10-04, 4:06 pm |
| In article <m1brfi4jj1.fsf@tti5.uchicago.edu>,
Matthias Blume <find@my.address.elsewhere> wrote:
>(That's because most
>implementations actually do implement some fixed order, so it is
>difficult to test other legal schedules which your compiler happens to
>not use.)
The Gambit compiler processes function arguments in reverse order. This has
the effect of causing each build of the system from the Scheme source to
reverse the order arguments are processed in the interpreter---first
left-to-right, then right-to-left, etc.
I did use this once to find some places where I should have used a let*
instead of a let. (The let looked something like:
(let ((a (read ...))
(b (read ...))
(c (read ...)))
( )
so you can see what the problem was.)
Brad
| |
| Anton van Straaten 2004-10-04, 4:06 pm |
| M. Paradis wrote:
> Is there any utility to the order of evaluation being unspecified?
> Is it :
> a) that a fixed order would produce some unwanted theoretical effect?
> b) to discourage some programming methods?
> c) because the choice of the order of evaluation would be arbitrary?
> d) because no consensus have been reached regarding this issue?
> e) something else?
The above omits (f), which is "some combination of all of the above,
depending on the observer's perspective".
However, there's only one underlying reason to leave evaluation order
unspecified: it allows the distinction between code which depends on
evaluation order, and code which is not intended to depend on a specific
evaluation order, to be expressed in a language.
Being able to express this distinction has at least two broad consequences:
it allows tools like compilers to treat the two types of code differently;
and it communicates information to human readers of the code.
Fixing evaluation order, without otherwise changing the language, removes
the ability to express this distinction, resulting in a less expressive
language.
One confusing point which tends to feed the occasional flamewars on this
topic is that the type of expressivity in question doesn't affect the
behavior of the program with respect to its "primary" specification -- the
program's behavior doesn't change due to fixing evaluation order (unless
possible performance changes are considered significant).
Matthias Blume expressed this by saying "every program that is legal and
correct under unspecified evaluation order is obviously legal and correct
under a specified order." However, "legal and correct" are not the only
requirements that real-world programs have. There are plenty of legal and
correct but entirely obfuscated programs, for example. There is no strictly
semantic argument you can make against such programs, yet they are not
considered desirable or even acceptable in real-world environments.
Real-world programs have to be maintained, often by a changing group of
people over time, and in such environments, the ability of a language to
express more information is usually advantageous.
In programs which are written in a largely functional style, the majority of
a program may not depend on an order of evaluation, and in those pieces that
do, it can be important to be aware of that. Having a language treat all
code as though it depends on a specific order of evaluation can thus remove
a large amount of information from a program, information which can be
useful when maintaining code.
As so often happens in programming languages, available languages offer us
two extremes in this area, neither of which is an ideal solution. On the
one hand, unspecified evaluation order creates theoretically ambiguous
semantics, and in general is a rather unsatisfactory way of asserting a
property of programs. On the other hand, languages with fixed evaluation
order deal with this unsatisfactoriness in a naive King Solomon-like way, by
simply removing a certain kind of expressivity from the language.
(Wise King Solomon threatened to cut a disputed baby in half, to determine
who the real mother was. Naive King Solomon would actually cut the baby in
half. In this case, perhaps it's really just a matter of a few fingers and
toes.)
In an ideal world, with ideal programmers, we could perhaps all just use a
language with fixed evaluation order, but agree to only depend on that order
in certain constructs such as (in Scheme) LET*, BEGIN, etc., and perhaps a
few more to satisfy some of the other reasonable requirements for
order-dependence. But in practice, being able to rely on fixed evaluation
order anywhere in a program means that at least some people will do just
that. This has a severe negative impact on the ability to use such a
convention to encode information. The bogeyman of unpredictable results,
a.k.a. ambiguous semantics, is just the easiest way, under the
circumstances, to "enforce" the convention, even though violations may only
be detected and reported in one of the most capricious ways imaginable, e.g.
with unpredictable results which usually occur only when switching
compilers.
> I'm no scheme expert, far from it, but I use it everyday, and I
> wondered : is this ambiguity responsible for the only circumstances
> where one can look at valid R5RS scheme code, and not be able to
> predict the result of the evaluation ?
Code for which evaluation has unpredictable results is only "valid" if its
specification says that the results of evaluation should be unpredictable.
Since this kind of unpredictability is not usually part of a program's
specification, what the above quote really says is that there are some buggy
programs which R5RS doesn't consider invalid. However, the same is true for
many other kinds of program bugs.
Anton
| |
| Thant Tessman 2004-10-04, 9:05 pm |
| Anton van Straaten wrote:
[...bunch o' stuff...]
Everything Anton van Straaten said that might be interpreted as a
defense of leaving the order of evaluation of function arguments
unspecified has been addressed (and in my not-so-objective opinion,
thoroughly refuted) in a previous thread already referenced.
-thant
| |
| Anton van Straaten 2004-10-04, 9:05 pm |
| Thant Tessman <thant@acm.org> wrote:
> Anton van Straaten wrote:
>
> [...bunch o' stuff...]
>
> Everything Anton van Straaten said that might be interpreted as a
> defense of leaving the order of evaluation of function arguments
> unspecified has been addressed (and in my not-so-objective opinion,
> thoroughly refuted) in a previous thread already referenced.
"Refuted" is an unsupportable claim in this context, at least by any
evidence provided thus far. In the end, in the absence of a solution which
addresses all concerns satisfactorily, it comes down to subjective
perspectives and priorities. In the prior thread, such perspectives were
expressed by statements such as your own:
"I just don't believe for a moment that being able to rearrange argument
evaluation is anywhere near as
important to someone maintaining code than knowing that the order of
evaluation is fixed."
I assume you recognize that such statements of belief don't qualify as
refutations. If you'd like to point out any actual refutations, as opposed
to subjective opinions, please do so. Failing that, it must be acknowledged
that there are in fact valid arguments on both sides of this issue, no
matter how much you may not like some of them, and no matter what weights
you might personally assign to some of them.
Anton
| |
| Matthias Blume 2004-10-04, 9:05 pm |
| bjl@cs.purdue.edu (Bradley J Lucier) writes:
> In article <m1brfi4jj1.fsf@tti5.uchicago.edu>,
> Matthias Blume <find@my.address.elsewhere> wrote:
>
> The Gambit compiler processes function arguments in reverse order. This has
> the effect of causing each build of the system from the Scheme source to
> reverse the order arguments are processed in the interpreter---first
> left-to-right, then right-to-left, etc.
>
> I did use this once to find some places where I should have used a let*
> instead of a let. (The let looked something like:
>
> (let ((a (read ...))
> (b (read ...))
> (c (read ...)))
> ( )
>
> so you can see what the problem was.)
Yes. I guess I should have said "a small number of fixed orders".
Also, there are systems (and if there aren't they would be relatively
easy to produce) that arrange for exhaustively searching through all
possible schedules. I doubt that an exhaustive search would be very
practical. Of course, most actual problems can probably be discovered
with just a few (e.g., 2) schedules -- if those schedules differ in
the right place.
Matthias
| |
| Thant Tessman 2004-10-04, 9:05 pm |
| Anton van Straaten wrote:
> [...] If you'd like to point out any actual refutations, as opposed
> to subjective opinions, please do so. [...]
The statement in your post that goaded me into referencing the previous
thread was this one:
"In programs which are written in a largely functional style, the
majority of
a program may not depend on an order of evaluation, and in those pieces that
do, it can be important to be aware of that. Having a language treat all
code as though it depends on a specific order of evaluation can thus remove
a large amount of information from a program, information which can be
useful when maintaining code."
There is no "information" being conveyed by the fact that
function-argument order-of-evaluation is unspecified. There are only
assumptions on the part of compilers and maintainers that may or may not
be valid. Maybe the code writer was trying to convey their intention
that order of evaluation was deliberately unspecified, or maybe they
didn't care. Maybe they did care but the code is buggy and has
order-of-evaluation dependency bugs anyway. If you want OofE to be
irrelevant, use a language in which functional style is enforced. If you
want to mix functional and imperative styles, use a language in which
the functional sections can be demarked by way of a type system. If you
want to deliberately specify that OofE is unspecified, as one might in
the case of a threading mechanism of some sort, introduce an explicit
construct for that. Beyond that, this claim that information useful
when maintaining code is somehow lost when order of evaluation is
specified is total nonsense. It was never really there to begin with--at
least not in any sense that isn't outdone by a simple comment.
-thant
| |
| Ron Garret 2004-10-04, 9:05 pm |
|
FWIW, here's my take on this.
IMHO:
1) One of the central principles of good programming language design is
the principle of least surprise.
2) Most people are surprised when a single program in an ostensibly
deterministic language with no external interactions behaves in two
different ways on two different occasions.
3) Leaving order of evaluation unspecified in a language that also has
side effects makes such an occurrence all but inevitable.
Therefore, unspecified order of evaluation by default is a poor design
choice. A better choice would be to introduce language syntax that
allows a programmer to specify that order of evaluation doesn't matter,
e.g.:
(with-arguments-evaluated-in-any-order . forms)
or
(call-with-arguments-evaluated-in-any-order thunk . argforms)
which could, of course, have suitable abbreviations.
Also, even if OoE were specified, nothing would prevent the compiler
from rearranging the OoE (or parallelizing it) in situations where it
could prove that the resulting semantics are equivalent to the specified
fixed OoE, which would be the case for all programs written in a purely
functional style. (As a consequence of this one might confidently
predict that with-arguments-evaluated-in-any-order, if it existed, would
seldom be used.)
rg
| |
| Marcin 'Qrczak' Kowalczyk 2004-10-04, 9:05 pm |
| Ron Garret <rNOSPAMon@flownet.com> writes:
> Therefore, unspecified order of evaluation by default is a poor
> design choice. A better choice would be to introduce language syntax
> that allows a programmer to specify that order of evaluation doesn't
> matter,
The problem is that almost nobody would use it if it would be longer
than the default.
--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
| |
| Thant Tessman 2004-10-04, 9:05 pm |
| Marcin 'Qrczak' Kowalczyk wrote:
> Ron Garret <rNOSPAMon@flownet.com> writes:
>
>
>
>
> The problem is that almost nobody would use it if it would be longer
> than the default.
Which should be a pretty big clue about how important it really is in
practice.
-thant
| |
| Bradley J Lucier 2004-10-04, 9:05 pm |
| In article <rNOSPAMon-2F811C.15363504102004@nntp1.jpl.nasa.gov>,
Ron Garret <rNOSPAMon@flownet.com> wrote:
>1) One of the central principles of good programming language design is
>the principle of least surprise.
In my experience, the "principle of least surprise" almost always means
"I personally was surprised that such and such happened, so it shouldn't have
happened." Which immediately raises the question, was it reasonable for that
person to be surprised? So I usually find this "principle" to be of no use
at all.
Brad
| |
| Thant Tessman 2004-10-04, 9:05 pm |
| Bradley J Lucier wrote:
> In article <rNOSPAMon-2F811C.15363504102004@nntp1.jpl.nasa.gov>,
> Ron Garret <rNOSPAMon@flownet.com> wrote:
>
>
>
> In my experience, the "principle of least surprise" almost always means
> "I personally was surprised that such and such happened, so it shouldn't have
> happened." Which immediately raises the question, was it reasonable for that
> person to be surprised? So I usually find this "principle" to be of no use
> at all.
Imposing order of evaluation cannot surprise someone not expecting it.
So in this case the argument is asymmetrical.
-thant
| |
| Anton van Straaten 2004-10-05, 4:04 am |
| Thant Tessman <thant@acm.org> wrote:
> There is no "information" being conveyed by the fact that
> function-argument order-of-evaluation is unspecified.
Of course there is. The information exists by definition, in that there are
some parts of the code for which order of evaluation is unspecified, and
other parts for which it is specified, with the distinction in semantics
indicated by syntax. What allows you to distinguish those two types of code
merely by syntactic inspection, is the information present in the program -
information that is lost from every program if you eliminate that
distinction in the language.
Removing this information for every function call and other non-sequencing
expression in a program "can thus remove a large amount of information from
a program," to quote my original statement. So you were incorrect in being
goaded to a response by my statement. ;)
Of course, I think what you're really getting at is whether that information
is useful. You're also attempting to deprecate its usefulness to the point
where eliminating it is no loss, in other words, arguing about whether the
information "can be useful when maintaining code," as I claimed. That, as
I've said, is subjective, in the sense that some people consider it useful,
and others deny that usefulness, and in order to do either, you have to
assign subjective values to the issues under consideration.
> Beyond that, this claim that information *useful* when
> maintaining code is somehow lost when order of evaluation
> is specified is total nonsense.
I emphasized your "useful" above, just to underscore what I wrote above.
Now all I have to do is refute your claim of "total nonsense".
> There are only assumptions on the part of compilers and
> maintainers that may or may not be valid. Maybe the code
> writer was trying to convey their intention that order of
> evaluation was deliberately unspecified, or maybe they
> didn't care. Maybe they did care but the code is buggy
> and has order-of-evaluation dependency bugs anyway.
Many of these "maybes" can be clarified with reference to the context in
which the code is being examined. Given that context, information about
code having unspecified evaluation order can become useful. For example,
what tests have been run against the program? If you're modifying some
code, and have reason to believe that it's been well-tested for eval order
issues, then there are many safe rearrangements of terms which can be
performed in parts of the code with unspecified eval order. That
possibility alone refutes the "total nonsense" claim, and now we're back to
subjective values.
Note that given the ability to express the distinction between specified and
unspecified order, it becomes possible to test for eval order issues, e.g.
by running test suites under different eval orders. This demonstrates both
that the presence of the distinction adds information to a program, and also
demonstrates a concrete potential benefit - since it's not possible to test
fixed-eval-order code for unintended eval order dependencies. Although a
fixed-eval-order language cannot express the two distinct types of code, the
distinction nevertheless exists, and code with unintended eval order
dependencies can affect programs in such languages.
Context is a key issue here. The strongest versions of your claims rely on
a context-free scenario, in which no testing for eval order issues has been
or will be performed, and in which no other outside knowledge is available -
for example, if a bug is being investigated, was the code recently modified?
How well was the program working previously? Was a new compiler used? Were
terms in some expression recently rearranged? Or, have you just noticed an
order dependency in a piece of code with unspecified evaluation order?
It's easy to simplify this issue out of existence if you restrict your focus
sufficiently, but all that means is that the restricted world you create has
the properties you created it to have, it says nothing about the broader
world beyond that.
> If you want to mix functional and imperative styles, use a
> language in which the functional sections can be demarked
> by way of a type system.
This at least acknowledges the underlying issue, and goes so far as to
allocate an entire class of programming languages to address it. That's
most generous, but would you mind enumerating some of the languages in this
class? In any case, Scheme is a language in which mixing functional and
imperative styles is accepted practice, and its type system isn't up to the
task you've set it. There are also non-pure functional languages with rich
type systems, like OCaml, which don't fix evaluation order in their language
specification. (Presumably, you consider this a mistake on the part of the
language designers.)
What this should all tell you is that this is not a settled issue, no matter
how much you would like it to be. You'll notice that my original post
didn't argue that the current situation in Scheme (and C, C++, OCaml etc.)
is perfect - far from it, I used strong language against it: "ambiguous
semantics", "unsatisfactory", "capricious". You seem to be arguing for
perfect solutions, which is admirable, and I'm all for that, but I was
answering the OP's question of whether there is "any utility to the order of
evaluation being unspecified" in Scheme. The Scheme standard doesn't
currently specify an evaluation order, and in this context, effectively
saying "if you want to do that, use some other language" is part of an
entirely different discussion.
> [The information] was never really there to begin with--at
> least not in any sense that isn't outdone by a simple comment.
Again, you're implicitly acknowledging the presence of the information in
question, while at the same time attempting to brush it under the rug. It
certainly makes no sense to provide comments for every occurrence of eval
order independence - any normal program, even an imperative one, would be
dominated by such comments. It would make more sense to comment areas where
eval order is depended on. But there's no need to do this within sequencing
constructs like LET* and BEGIN. So are you suggesting the "simple comments"
be placed outside sequencing constructs, wherever eval order is depended on?
I addressed that in my original post: "in practice, being able to rely on
fixed evaluation
order anywhere in a program means that at least some people will do just
that. This has a severe negative impact on the ability to use such a
convention to encode information."
Anton
| |
| Anton van Straaten 2004-10-05, 4:04 am |
| Ron Garret <rNOSPAMon@flownet.com> wrote:
>
> FWIW, here's my take on this.
>
> IMHO:
>
> 1) One of the central principles of good programming language design is
> the principle of least surprise.
Although it's often touted in informal contexts, that's a controversial
principle, mainly because it's too vague. You certainly won't find it in
many semantics texts!
> 2) Most people are surprised when a single program in an ostensibly
> deterministic language with no external interactions behaves in two
> different ways on two different occasions.
If that's not the expected behavior, then you're describing a buggy program.
That's nothing to do with principle of least surprise - bugs happen, they
get reported, and fixed.
> 3) Leaving order of evaluation unspecified in a language that also has
> side effects makes such an occurrence all but inevitable.
Having side effects at all makes an entire class of otherwise avoidable bugs
inevitable, yet we still tolerate them for some reason, even in languages
like SML/NJ.
> Therefore, unspecified order of evaluation by default is a poor design
> choice.
I think the premises need work before a "therefore" can be inserted. ;)
> A better choice would be to introduce language syntax that
> allows a programmer to specify that order of evaluation doesn't matter,
> e.g.:
>
> (with-arguments-evaluated-in-any-order . forms)
>
> or
>
> (call-with-arguments-evaluated-in-any-order thunk . argforms)
>
> which could, of course, have suitable abbreviations.
Syntax like that would dominate any normal program, even an imperative one.
Even in traditional imperative languages, most function call argument lists
and most expressions don't depend on order of evaluation. The software
world would be in far worse shape if that weren't the case.
It would be better to switch the default around, and provide forms to
support sequencing, when required. Which, of course, is the situation in
Scheme.
> Also, even if OoE were specified, nothing would prevent the compiler
> from rearranging the OoE (or parallelizing it) in situations where it
> could prove that the resulting semantics are equivalent to the specified
> fixed OoE, which would be the case for all programs written in a purely
> functional style. (As a consequence of this one might confidently
> predict that with-arguments-evaluated-in-any-order, if it existed, would
> seldom be used.)
That might be true if the only beneficiary of OoE information was the
compiler. However, humans have to work with code too, and in fact their
needs are usually considered paramount. If your smart compiler were to
annotate the source code, or highlight it in an IDE, to allow the two to be
distinguished reliably without any human effort, that would be a step
forward. But in general, it's difficult to do that, across e.g. module
boundaries, especially in a latently-typed language like Scheme.
In any case, none of these speculative possibilities addresses the question
asked by the OP, "Is there any utility to the order of evaluation being
unspecified?" My response to that was that the answer is yes, there is
utility in it, although opinions differ as to exactly how much. The
responses I've received so far merely underscore my answer. :)
Anton
| |
| Matthias Blume 2004-10-05, 4:04 am |
| "Anton van Straaten" <anton@appsolutions.com> writes:
> [ ... ] it's not possible to test
> fixed-eval-order code for unintended eval order dependencies.
False. You can run all the same tests. Maybe you find that they fail
more often because, as you say yourself, people might actually take
advantage of the language guarantees. But to say that you can't run
the tests is nonsense. And if your convention is to encode the
information using certain coding conventions (as questionable a
practice as this may be), then those tests will point out where the
conventions were violated.
> I addressed that in my original post: "in practice, being able to
> rely on fixed evaluation order anywhere in a program means that at
> least some people will do just that. This has a severe negative
> impact on the ability to use such a convention to encode
> information."
And that's a good thing. It is an extremely clumsy and brittle way of
encoding this type of information. I can't believe anyone can
possibly defend it and keep a straight face.
Matthias
| |
| Matthias Blume 2004-10-05, 4:04 am |
| "Anton van Straaten" <anton@appsolutions.com> writes:
> Ron Garret <rNOSPAMon@flownet.com> wrote:
>
> Although it's often touted in informal contexts, that's a controversial
> principle, mainly because it's too vague. You certainly won't find it in
> many semantics texts!
.... because that's not the appropriate place for it. A text on
language design would be more like it.
>
> If that's not the expected behavior, then you're describing a buggy program.
> That's nothing to do with principle of least surprise - bugs happen, they
> get reported, and fixed.
We are arguing about different language semantics. The program is
buggy only with respect to one such semantics, with respect to another
it might be correct. And that was Ron's point.
It's like a winding mountain road without a guard rail. You basically
say that falling down the cliff is the motorists fault because he
should have driven more slowly and more carefully, fully knowing the
danger. And strictly speaking you are right -- but your answer is
completely besides the point if the question was whether it would have
been better to have a guard rail in place.
>
> Having side effects at all makes an entire class of otherwise avoidable bugs
> inevitable, yet we still tolerate them for some reason, even in languages
> like SML/NJ.
So just because we tolerate one source of bugs we are now required to
tolerate many others as well? The difference is that imperative
language features unquestionably have their utility, while not fixing
the evaluation order does not.
>
> I think the premises need work before a "therefore" can be inserted. ;)
Let me try again:
Unspecified order of evaluation by default is a poor design choice.
Better?
> Syntax like that would dominate any normal program, even an imperative one.
> Even in traditional imperative languages, most function call argument lists
> and most expressions don't depend on order of evaluation. The software
> world would be in far worse shape if that weren't the case.
Moreover, for most of these function argument lists it is completely
*obvious* even to unsophisticated compilers that this is the case.
Function arguments tend to be simple: literals, variables, simple
arithmetic expressions, etc. Only when they are not we might have
some problems. Those cases are rare (in my experience).
> That might be true if the only beneficiary of OoE information was the
> compiler. However, humans have to work with code too, and in fact their
> needs are usually considered paramount. If your smart compiler were to
> annotate the source code, or highlight it in an IDE, to allow the two to be
> distinguished reliably without any human effort, that would be a step
> forward. But in general, it's difficult to do that, across e.g. module
> boundaries, especially in a latently-typed language like Scheme.
Again, in the common case I expect there to be absolutely no problem.
What's obvious to the compiler (in the above sense) is also obvious to
the programmer.
In general, you are *way* overstating the problem. I can't remember a
single time when I asked myself "gee, I wonder which parts of this
argument list can be legally reordered without changing the semantics"
where the answer was so difficult that I needed help from a tool, or
worse, couldn't figure it out at all.
In the unlikely case that I can't get the answer easily, I would be
extremely nervous about the code being correct to begin with. And
this feeling would be even worse if evaluation order was not specified
by the language -- simply because then there are so many more ways in
which a complicated piece of code could go wrong.
In other words, I would not trust the programmer just because she
chose to use a function call rather than a LET*. That could have been
just a mistake. The only thing to calm me down in such a situation
would be a detailed comment with a proof sketch of why the code is
correct (or, if not a proof, then *explicit* reassurance that the
programmer was confident about this being correct).
> In any case, none of these speculative possibilities addresses the question
> asked by the OP, "Is there any utility to the order of evaluation being
> unspecified?" My response to that was that the answer is yes, there is
> utility in it, although opinions differ as to exactly how much.
It (the utility) is pretty much indistinguishable from zero. To
understand why I think so, see above.
(The cost, however, is definitely not zero.)
Matthias
| |
|
| Thant Tessman wrote:
> Imposing order of evaluation cannot surprise someone not expecting it.
> So in this case the argument is asymmetrical.
Not when writing code, that is true. Your suprise may vary when
reading someone else's code. And you may be constantly and unpleasantly
surprised when refactoring such code.
Ron Garrett wrote:
> Therefore, unspecified order of evaluation by default is a poor design
> choice. A better choice would be to introduce language syntax that
> allows a programmer to specify that order of evaluation doesn't matter,
> e.g.:
>
> (with-arguments-evaluated-in-any-order . forms)
.... except that this imposes an extra syntactic burden for the most common
case where order really does not matter, whereas the current status quo
reserves that burden, via let*, etc., for the more uncommon case.
A.
| |
| Joe Marshall 2004-10-05, 4:04 pm |
| Ron Garret <rNOSPAMon@flownet.com> writes:
> FWIW, here's my take on this.
>
> IMHO:
>
> 1) One of the central principles of good programming language design
> is the principle of least surprise.
Let's take this as an axiom.
> 2) Most people are surprised when a single program in an ostensibly
> deterministic language with no external interactions behaves in
> two different ways on two different occasions.
Ok.
> 3) Leaving order of evaluation unspecified in a language that also has
> side effects makes such an occurrence all but inevitable.
Ok.
> Therefore, unspecified order of evaluation by default is a poor design
> choice.
Whoops! You left off an antecedent:
4) Specifying the order of evaluation will reduce the surprise.
Unfortunately, that isn't always true. It is possible to have
order-of-evaluation bugs in languages that specify a deterministic
order of evaluation. Surprising, no?
So specifying the order of evaluation
a) doesn't fix the problem
b) leads to more surprises
> Therefore, unspecified order of evaluation by default is a poor design
> choice.
I agree, but I argue that specifying the order of evaluation by
default is *also* a poor design choice, and is no better than leaving
it unspecified.
| |
| Matthias Blume 2004-10-05, 4:04 pm |
| Joe Marshall <jrm@ccs.neu.edu> writes:
> 4) Specifying the order of evaluation will reduce the surprise.
>
> Unfortunately, that isn't always true. It is possible to have
> order-of-evaluation bugs in languages that specify a deterministic
> order of evaluation. Surprising, no?
Could you give an example?
> So specifying the order of evaluation
> a) doesn't fix the problem
> b) leads to more surprises
Claim b) is obviously false because all surprise-free programs under
unspecified order are also surprise-free under specified order.
>
> I agree, but I argue that specifying the order of evaluation by
> default is *also* a poor design choice, and is no better than leaving
> it unspecified.
<scratching head>
Hmm. Sounds like Zen to me. The opposite of a great thruth is also a
thruth...
</scratching head>
| |
| Matthias Blume 2004-10-05, 4:04 pm |
| Matthias Blume <find@my.address.elsewhere> writes:
> <scratching head>
> Hmm. Sounds like Zen to me. The opposite of a great thruth is also a
> thruth...
> </scratching head>
Ith works bethther witouth te authomathic TH-reflex... :-)
s/thruth/truth/g
| |
| Ron Garret 2004-10-05, 4:04 pm |
| In article <_Kp8d.3634$Vm1.2292@newsread3.news.atl.earthlink.net>,
"Anton van Straaten" <anton@appsolutions.com> wrote:
> Ron Garret <rNOSPAMon@flownet.com> wrote:
>
> Although it's often touted in informal contexts, that's a controversial
> principle, mainly because it's too vague. You certainly won't find it in
> many semantics texts!
I won't find it many physics texts either. And your point would be...?
>
> If that's not the expected behavior, then you're describing a buggy program.
> That's nothing to do with principle of least surprise - bugs happen, they
> get reported, and fixed.
Do they? How can I tell if I have a Scheme program whose semantics
depend on OoE? If I have a Scheme program which accepts no input from
the outside and has worked correctly on 99 runs, how can I be sure it
will work correctly on the 100th run?
>
> Having side effects at all makes an entire class of otherwise avoidable bugs
> inevitable, yet we still tolerate them for some reason, even in languages
> like SML/NJ.
We tolerate side effects because they are useful. The whole point of
having high level programming languages at all is to create a better
"impedance match" between the kinds of information that computers
process and the kinds of information human brains process. If we could
rely on programmers to follow conventions, recognize errors, RTFM, etc.
there would be no utility to high level languages at all. But they
don't, so there is. And for some reason, most people find it easier to
think in terms of side effects when they sit down to solve certain
classes of problems. That's just the way that the human brain seems to
be wired.
[Off-topic rant: I have mostly stayed out of the Bill Richter wars,
except to celebrate his temporary departure and quietly lament his
return. The main reason I find everything Bill writes to be utterly
irrelevant is that I reject his central tacit premise, that mathematics
has value above all else in CS. It doesn't. The study of programming
languages has as much to do with psychology, economics, and politics as
it does with math, a fact that lamentably few of its practitioners seem
to recognize.]
>
> I think the premises need work before a "therefore" can be inserted. ;)
>
>
> Syntax like that would dominate any normal program, even an imperative one.
I doubt that very much.
> Even in traditional imperative languages, most function call argument lists
> and most expressions don't depend on order of evaluation. The software
> world would be in far worse shape if that weren't the case.
It is true that most expressions etc. don't depend on OoE, but that is
simply a mathematical fact, and so it is nonsensical to speculate what
the consequences would be if it weren't true. What we are talking about
is how to treat those cases where it *does* (or might) matter.
(This is a rather crucial point, and I am beginning to wonder if those
who support unspecified OoE have simply missed it.)
>
> That might be true if the only beneficiary of OoE information was the
> compiler. However, humans have to work with code too, and in fact their
> needs are usually considered paramount. If your smart compiler were to
> annotate the source code, or highlight it in an IDE, to allow the two to be
> distinguished reliably without any human effort, that would be a step
> forward. But in general, it's difficult to do that, across e.g. module
> boundaries, especially in a latently-typed language like Scheme.
So what? I'm arguing that the principle of least surprise dictates that
the program semantics ought to be by default *as if* there were a fixed
OoE, not that it *actually* have a fixed OoE.
> In any case, none of these speculative possibilities addresses the question
> asked by the OP, "Is there any utility to the order of evaluation being
> unspecified?" My response to that was that the answer is yes, there is
> utility in it, although opinions differ as to exactly how much. The
> responses I've received so far merely underscore my answer. :)
I do not dispute that there is utility in having an unspecified OoE.
What I am arguing against is making this the case by default.
rg
| |
| Thant Tessman 2004-10-05, 4:04 pm |
| "Anton van Straaten" <anton@appsolutions.com> wrote in message news:<fHp8d.3632$Vm1.2561@newsread3.news.atl.earthlink.net>...
> Thant Tessman <thant@acm.org> wrote:
>
>
> Of course there is. The information exists by definition, in that there are
> some parts of the code for which order of evaluation is unspecified, and
> other parts for which it is specified, with the distinction in semantics
> indicated by syntax. [...]
There is no information about the intention of the programmer or the
actual behavior of the code with respect to argument order of
evaluation conveyed by the fact that argument order of evaluation is
unspecified. You simply have no way of knowing (without the programmer
telling you directly) whether the programmer understood and
deliberately took into account this subtle and not universally
intuitive aspect of Scheme's semantics. And even if you confirmed they
did, you have no way of knowing (again, without examining the code
directly) that they didn't unintentionally introduce
order-of-evaluation bugs that simply aren't revealed by a particular
implementation at a particular time.
There is no information lost by fixing argument order of evaluation.
-thant
| |
| Ron Garret 2004-10-05, 4:04 pm |
| In article <41629F72.E0600C94@het.brown.edu>,
Andre <andre@het.brown.edu> wrote:
> Ron Garrett wrote:
>
>
> ... except that this imposes an extra syntactic burden for the most common
> case where order really does not matter, whereas the current status quo
> reserves that burden, via let*, etc., for the more uncommon case.
>
> A.
No. I've made this point before, but I'll make it again: the mistake
made by proponents of unspecified OoE is that they only distinguish two
cases: where OoE matters, and where it does not. But in fact there are
*three* cases: 1) where OoE does not matter, 2) where OoE does matter,
and 3) where OoE *might* matter but in fact does not due to external
circumstances not manifested in the code.
Case 1 is indeed the most common, but it can further be broken down into
two sub-cases: 1a) where the compiler can tell that OoE does not matter
(i.e. in the case of a side-effect-free program) and 1b) where the
compiler cannot tell.
The proponents of unspecified OoE focus on the fact that case 1 is the
most common, which I will stipulate is correct. But then I claim that
case 1a is vastly more common than case 1b. So the real issue here is
the case where the compiler can't tell whether OoE matters. I claim
that in the vast majority of such cases, OoE does in fact matter.
Furthermore, the cost of being wrong if you assume that OoE matters is a
program that doesn't run as fast as it might. The cost of being wrong
if you assume that OoE doesn't matter is the constant risk that your
program will one day do something different from what it has done
before. IMHO, the latter is a vastly higher price to pay, and in some
lines of work (e.g. control software for nuclear power plants) it is in
fact (or at least ought to be) a show stopper.
rg
| |
| Joe Marshall 2004-10-05, 8:58 pm |
| Matthias Blume <find@my.address.elsewhere> writes:
> Joe Marshall <jrm@ccs.neu.edu> writes:
>
>
> Could you give an example?
Yes, but you won't like it.
I had a function that took three arguments, one caller had a hard time
computing the second argument. The caller looked a bit like this:
(foo (car baz)
(cond ((null? bar) (append (mapcar (lambda () ...))...))
((vector? x) (vector->list (assq (reverse! ...))))
((not (pair? y)) (if (null? y)
'(some list)
(use-default-y)))
(else (call-with-current-continuation
(lambda (c)
(invoke-blah-blah c ...)))))
(vector-ref quux 22))
It was hard to understand what was going on. The natural thing to do
was to lift this out into a let statement:
(let ((rather-hairy-thingy (cond ((null? bar) (append (mapcar (lambda () ...))...))
((vector? x) (vector->list (assq (reverse! ...))))
((not (pair? y)) (if (null? y)
'(some list)
(use-default-y)))
(else (call-with-current-continuation
(lambda (c)
(invoke-blah-blah c ...)))))))
(foo (car baz) rather-hairy-thingy (vector-ref quux 22)))
And this *usually* worked, but sometimes failed. The reason being
that one of the hairy subclauses called a function that caused a side
effect on BAZ.
I hadn't thought I was relying on order of evaluation, but I was, and
even though the order was specified as left-to-right (I was using
common lisp) I still got the bug.
>
> Claim b) is obviously false because all surprise-free programs under
> unspecified order are also surprise-free under specified order.
It's a meta-claim. If fixing the order of evaluation is supposed to
reduce surprise, then it is surprising that it fails to do so.
>
> <scratching head>
> Hmm. Sounds like Zen to me. The opposite of a great thruth is also a
> thruth...
> </scratching head>
| |
| Thant Tessman 2004-10-05, 8:58 pm |
| Andre <andre@het.brown.edu> wrote in message news:<41629F72.E0600C94@het.brown.edu>...
> Thant Tessman wrote:
>
>
> Not when writing code, that is true. Your suprise may vary when
> reading someone else's code. And you may be constantly and unpleasantly
> surprised when refactoring such code.
And this, as I pointed out in the previous thread, is the true
motivation behind the defense of unspecified argument order of
evaluation. Relying on OofE is not a bug in a language in which OofE
is specified. It is, however, according to some, really bad style--so
bad apparently that it must be punished. So important apparently is it
that this style of programming be punished, that even those whose
programs *unintentionally* depend on OofE must be penalized with
programs whose behavior is left unspecified and might change from one
implementation to the next, or even from one execution to the next.
[...]
-thant
| |
|
| Thant Tessman wrote:
>
> Andre <andre@het.brown.edu> wrote in message news:<41629F72.E0600C94@het.brown.edu>...
>
> And this, as I pointed out in the previous thread, is the true
> motivation behind the defense of unspecified argument order of
> evaluation. Relying on OofE is not a bug in a language in which OofE
> is specified. It is, however, according to some, really bad style--so
> bad apparently that it must be punished. So important apparently is it
> that this style of programming be punished, that even those whose
> programs *unintentionally* depend on OofE must be penalized with
> programs whose behavior is left unspecified and might change from one
> implementation to the next, or even from one execution to the next.
You may have misunderstood my statement. I was pointing out that
*fixed* evaluation order would *also* cause punishment.
The argument was that if Scheme had fixed evaluation order, since
more programs would then be written that actually depended on this fixed
order of evaluation, such (correct) programs would cause punishment to those
who have to read or refactor them. It is certainly arguable how much
of a problem this is and which kind of punishment is worse, and there
is certainly a strong case for determinism, but I think
everybody is motivated by a desire to *reduce* punishment, not
because anybody is secretly into S&M (not that there is anything wrong
with it).
A.
| |
| Adrian Kubala 2004-10-05, 8:58 pm |
| Thant Tessman <thant@acm.org> schrieb:
> You simply have no way of knowing (without the programmer telling you
> directly) whether the programmer understood and deliberately took into
> account this subtle and not universally intuitive aspect of Scheme's
> semantics.
By this argument, no scheme program can ever convey any information.
Because maybe when the programmer wrote (define (foo bar) baz), she
meant to define a function, maybe she didn't -- clearly we can't assume
she read R5RS and knows what the heck she's doing. Maybe she was just
banging her head on the keyboard in frustration? Maybe these words I'm
typing right now *seem* to convey some information based on your
understanding of English, but in reality I'm speaking a different
language with the same syntax and completely different semantics, and
this post merely expounds on the innate beauty of belly-button fuzz.
I think what you're really saying is that some features of the spec are
more likely to be applied meaningfully than others, but whether the
particular feature of unspecified OoE is *so* unintuitive that *nobody*
could possibly use it on purpose, is certainly a matter of subjective
opinion.
| |
| Ray Dillinger 2004-10-06, 4:00 am |
| Joe Marshall wrote:
> And this *usually* worked, but sometimes failed. The reason being
> that one of the hairy subclauses called a function that caused a side
> effect on BAZ.
>
> I hadn't thought I was relying on order of evaluation, but I was, and
> even though the order was specified as left-to-right (I was using
> common lisp) I still got the bug.
There is a problem with this argument.
Having an unspecified order of evaluation would not have
saved you from this bug.
Whatever possible order of evaluation manifests your bug,
a language with an unspecified order of evaluation can
do it.
Having a specified order of evaluation, on the other hand,
gives at least one order of evaluation that correct code
can rely on.
Having a specified order of evaluation also gives consistent
behavior in the case of OofE bugs; with a fixed OofE, such
buggy code will not run correctly on *ANY* systems. Because
of this consistency, it is easier to debug programs and
easier to be sure of their portability between
implementations.
Bear
| |
| Thant Tessman 2004-10-06, 3:59 pm |
| Adrian Kubala <adrian@sixfingeredman.net> wrote in message news:<slrncm6dvh.4i5.adrian@sixfingeredman.net>...
> Thant Tessman <thant@acm.org> schrieb:
>
> By this argument, no scheme program can ever convey any information. [...]
Of course it's important to try to understand the intention of the
programmer. But it's more important to understand the actual behavior
of the program regardless of the intention of the programmer. My point
is that attempting to divine the intention of the programmer from a
program whose behavior is by definition undefined is silly.
-thant
| |
| NJDSS Editorial Collective 2004-10-06, 3:59 pm |
| Adrian Kubala <adrian@sixfingeredman.net> writes:
> Thant Tessman <thant@acm.org> schrieb:
>
> By this argument, no scheme program can ever convey any information.
But arguably a yak can convey one to the scary devil monastery where
one can learn to apreciate the true lambda-nature inherent in all the
vain strivings bound to these contours of illusion. In fact this was
the cover article of the July issue of the Nepalese Journal for
Deconstructionist Sociologists and Sheep-herders, the premier academic
journal of Himalayan computing (among other topics).
> Because maybe when the programmer wrote (define (foo bar) baz), she
> meant to define a function, maybe she didn't -- clearly we can't assume
> she read R5RS and knows what the heck she's doing.
Such authoritarian appeals only demonstrate the lack of inner peace
that can only be acquired through a detailed study of mammalian
behaviors at altitude. It is clearly the case that nothing should be
assumed about the programmer's intention without a careful semiotic
analysis of the cultural factors implied by the development
process. Indeed careful attention should be paid in view of the
implied moral judgement conatined in the notion of development, when
in fact the whole corpus of instruction could simply be subject to
bit-rot.
> Maybe she was just
> banging her head on the keyboard in frustration?
What is the sound of one forehead typing?
> Maybe these words I'm
> typing right now *seem* to convey some information based on your
> understanding of English, but in reality I'm speaking a different
> language with the same syntax and completely different semantics, and
> this post merely expounds on the innate beauty of belly-button fuzz.
This was a particularly cogent post right which we werre considering
reprinting in the Nepalese Journal right up until the point where you
began writing a different language that had English lexical and
syntactic structure, but seemed to be considering some completely
different subject domain. The relevant clause was reviewed by the entire
Editorial Collective and found to be full of inexcusably unarguable
content. Should you amend your post we would like to discuss an
on-going contract for a periodic column in the NJDSS. Anton
VonStraaten has been so busy lately...
> I think what you're really saying is that some features of the spec are
> more likely to be applied meaningfully than others,
Implication is undoubtedly more important than application, no?
> but whether the
> particular feature of unspecified OoE is *so* unintuitive that *nobody*
> could possibly use it on purpose, is certainly a matter of subjective
> opinion.
And the whole subject/object relationship hasn't been adequately
explored in the Himalayan computing field (located 500 meters upslope
outside of our offices). It's entirely possible we could sponsor a
fellowship for advanced research if you would be so inclined...
The NJDSS Editorial Collective
--
There are no quality-control or safety standards for pedestrians
-- P.J. O'Rourke
_An Argument in Favor of Automobiles Instead of Pedestrians_
| |
| Thant Tessman 2004-10-06, 3:59 pm |
| Andre <andre@het.brown.edu> wrote in message news:<41631BF9.E28627A0@het.brown.edu>...
[...]
> You may have misunderstood my statement. I was pointing out that
> *fixed* evaluation order would *also* cause punishment. [...]
No, I didn't misunderstand your statement. I was merely trying to
point out that it's a different argument--although one that fails for
the same reason. Think about what kind of evidence one might use to
defend this argument. It would have to be an example of code that, due
to the fact that it deliberately relied on fixed OofE in a language
that specified fixed OofE, was somehow harder to understand or
refactor. No one has yet provided such an example in this forum (that
I've seen), but let's postulate the existence of one.
Here's the thing: That code example might be an example of bad style
in a language with fixed OofE, but it's simultaneously an example of
indeterminantly-busted code in a language with unspecified OofE. How
the latter is an improvement over the former has yet to be explained.
-thant
| |
| Thant Tessman 2004-10-06, 3:59 pm |
| I apologize for following up on my own post, but this thought deserves
finishing in order to preempt an anticipated response:
Thant Tessman wrote:
[...]
> Here's the thing: That code example might be an example of bad style
> in a language with fixed OofE, but it's simultaneously an example of
> indeterminantly-busted code in a language with unspecified OofE. How
> the latter is an improvement over the former has yet to be explained.
The difference between these two cases (already pointed out by both
sides of this debate) is that while the latter is either unintentional
or based on a misunderstanding of the language, the former might be
intentional. That's why I described this argument about unspecified OofE
as really being an argument about punishment of a thought crime.
-thant
| |
| William D Clinger 2004-10-06, 8:56 pm |
| NJDSS Editorial Collective <collective@njdss.org> wrote:
> But arguably a yak can convey one to the scary devil monastery where
> one can learn to apreciate the true lambda-nature inherent in all the
> vain strivings bound to these contours of illusion.
True. As less enlightened authorities have written:
If guns were outlawed, then only outlaws would have guns.
From which it follows that, if guns were not outlawed, having
guns would no longer be a conclusive indicator of outlawry.
What I'd like to know is: Would all the participants in this
thread be satisfied by a compromise in which guns are not
outlawed, but only outlaws have guns?
I'm serious about this. I really want to know. What I am
asking is: Would you would be happy with a language in which
the language's semantics imposes a fixed deterministic order
of evaluation upon implementors, but programs that depend on
this order of evaluation are regarded as buggy?
An approximation to this situation can be achieved by using
an extremely arcane fixed order of evaluation, which is not
defined except in the fine print of a codicil that no sane
non-implementor would read, and by warning programmers that
TO DEPEND UPON THE FIXED ORDER OF EVALUATION IS UNIVERSALLY
REGARDED AS EXTREMELY BAD STYLE; PERPETRATORS OF THIS STYLE
SHOULD BE DRAWN AND QUARTERED.
Will
| |
| Display Name 2004-10-06, 8:56 pm |
|
"William D Clinger" <cesuraSPAM@verizon.net> wrote
> I'm serious about this. I really want to know. What I am
> asking is: Would you would be happy with a language in which
> the language's semantics imposes a fixed deterministic order
> of evaluation upon implementors, but programs that depend on
> this order of evaluation are regarded as buggy?
>
> An approximation to this situation can be achieved by using
> an extremely arcane fixed order of evaluation
A brilliant compromise, which should satisfy those who have valid concerns
about nondeterminism in critical software. The order probably does not even
have
to be that arcane. I personally think right to left should be sufficient to
discourage
most unintentional errors and instances of bad style.
Andre
| |
| Jim Bender 2004-10-07, 3:59 am |
| "William D Clinger" <cesuraSPAM@verizon.net> wrote in message news:fb74251e.0410061616.4fd47535@posting.google.com...
> I'm serious about this. I really want to know. What I am
> asking is: Would you would be happy with a language in which
> the language's semantics imposes a fixed deterministic order
> of evaluation upon implementors, but programs that depend on
> this order of evaluation are regarded as buggy?
I am curious what it means to declare a program "buggy" when
(1) the intended behaviour of the program is consistent with the
language definition's fixed order of evaluation and (2) implementations
which wish to be regarded as compliant with that language definition
are compelled to correctly execute that program.
> An approximation to this situation can be achieved by using
> an extremely arcane fixed order of evaluation
I would have trouble with a fixed order of evaluation, where the
actual order can not be defended logically except as an attempt
to confound those who would write (f (read) (read) (read)).
On a somewhat separate note:
To the degree that an unspecified order of evaluation is desirable
because a compiler may produce faster code by re-ordering the
evaluation of a function's arguments, I wonder what proportion of
those re-orderings would be done where the compiler could tell
that re-ordering would make no difference to program's behaviour
vs. cases where the compiler has no clue?
Jim
| |
| Pascal Costanza 2004-10-07, 3:59 am |
|
William D Clinger wrote:
> TO DEPEND UPON THE FIXED ORDER OF EVALUATION IS UNIVERSALLY
> REGARDED AS EXTREMELY BAD STYLE; PERPETRATORS OF THIS STYLE
> SHOULD BE DRAWN AND QUARTERED.
Is there a canonical reference that discusses pros and cons of such a
style? (A paper, a textbook section, a wiki, whatever?)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
| |
| Anton van Straaten 2004-10-07, 3:59 am |
| Jim Bender <jim@benderweb.net> wrote:
> I would have trouble with a fixed order of evaluation, where the
> actual order can not be defended logically except as an attempt
> to confound those who would write (f (read) (read) (read)).
I don't really mean to pick on Jim, and I hope he will forgive me, but I
think that this discussion could be much more productive if some people
didn't try to paint it as so one-sided. "Can not be defended logically" is
not just an overstatement of the case - it's simply false.
The logical defense is that there's value in being able to communicate that
certain code does not depend on an order of evaluation, and that other code
in the same program does. The problem is, that's not an easy thing to do in
a way that addresses all the surrounding issues satisfactorily.
Some people complain that such an assertion is not statically checkable, and
even dynamic checkability is harder than usual to come by. However, we
don't usually check types statically in Scheme, either; and in practice,
experience in Scheme, C, C++, and OCaml indicates that the issues resulting
from unspecified evaluation order are certainly no more problematic than
those that arise from unintentional order dependencies in language with
fixed evaluation order (and arguably, less so). That's because evaluation
order issues can occur in any language with side effects, regardless of the
language's specified evaluation order.
Since examples such as (f (read) (read) (read)) are by far the exception,
rather than the rule, they could easily be dealt with by a convenient
special form. Something like that could be implemented via a macro, and
perhaps specified in a SRFI. It is much less easy to communicate
order-independence in these sorts of ways, because order-independent code in
argument lists and expressions dominates all useful programs, in most
languages. The idea that only some subset of this order-independent code
needs to be marked as order-independent doesn't fly - order-dependence is
the exception, and that's what needs to be flagged as exceptional.
The problem with the opposing positions here tends to be that even when they
acknowledge any value in the ability to specify order independence, they all
seem to take the basic stance that this ability is worth sacrificing, in
exchange for unambiguous semantics. No-one should be surprised that there's
opposition to this idea. It offers unambiguous semantics only for a less
expressive language, a language that cannot express certain properties of
the programs written in it.
Suggest a credible alternative to this, and I'm sure everyone will listen.
Otherwise, we're left fighting over whose preferences might get stomped on
in a future standard, which makes for a lot of heat, and unusually little
light.
I find it disappointing that because this is a difficult and subtle issue to
deal with, many smart people are so willing to simply dismiss or ignore it
in favor of an easy way out. Java did that. It's a pragmatic choice, for
an industrial language. It was also a pragmatic choice for SML. SML made a
number of other pragmatic choices: things like LET being equivalent to
Scheme's LET*, for example. In some of these kinds of ways, Scheme supports
the expression of finer distinctions in the programmer's intent than either
ML or even Haskell. As R5RS says, "Scheme would still be useful as a
notation for expressing computational methods even in the absence of a
mechanical implementation." Many papers have demonstrated this, and that
fine-grained ability to communicate the exact nature of a computation can be
useful. Personally, I enjoy using it in my own programs, even though there
are many times when less precise expression would do.
In this context, simply fixing evaluation order, and removing any penalty
for relying on it anywhere, would be quite counter to the common situation
in the Scheme world, where much attention has historically been paid to
resolving minutiae satisfactorily. Here Scheme is, in 2004 CE, about 30
years after its invention, without a standard module system, which almost
any other serious language has in some form or another. The funny thing is,
if you truly understand Scheme, you are likely to be aware of *good* reasons
for why this is the case. (Not that this situation shouldn't be corrected
in future.)
When Scheme gets a standard module system, it should be a good one. It
won't be the ad-hoc conflation of otherwise orthogonal features that you see
in the industrial languages. It will support staged computation (macros) in
ways that even advanced module systems in other functional languages do not.
Scheme has waited decades for this. In dealing with evaluation order,
however that is eventually done, we should try to do justice to the
tradition of Scheme.
Anton
| |
| Anton van Straaten 2004-10-07, 9:00 am |
| William D Clinger wrote:
> What I'd like to know is: Would all the participants in this
> thread be satisfied by a compromise in which guns are not
> outlawed, but only outlaws have guns?
>
> I'm serious about this. I really want to know. What I am
> asking is: Would you would be happy with a language in which
> the language's semantics imposes a fixed deterministic order
> of evaluation upon implementors, but programs that depend on
> this order of evaluation are regarded as buggy?
That seems acceptable to me. The important point is that it should be
possible to distinguish between code which is "allowed" to depend on
evaluation order, and code which is not allowed to do so. Aside from
communicating between humans, this also provides support for analysis by
tools.
> An approximation to this situation can be achieved by
> using an extremely arcane fixed order of evaluation
I agree with Andre, right-to-left order would be sufficiently arcane, and
has some precedent both in Scheme world (e.g. SISC and MIT) and elsewhere
(e.g. OCaml's implementation).
But I'd be concerned that along the way, this would get diluted into fixed
left-to-right order, leaving only the warning:
> TO DEPEND UPON THE FIXED ORDER OF EVALUATION IS
> UNIVERSALLY REGARDED AS EXTREMELY BAD STYLE;
> PERPETRATORS OF THIS STYLE SHOULD BE DRAWN
> AND QUARTERED.
The problem is that despite the "universally" claim, not everyone agrees
with this warning, and by itself, it would ultimately be ignored enough to
lose significant value. In any case, for me, the point is not so much the
"punishment of thought crimes" that has been raised in this thread, but
rather that the ability to communicate order of evaluation dependency
distinctions in code becomes lost, if there is no "enforcement" mechanism
whatsoever.
Anton
| |
| Anton van Straaten 2004-10-07, 9:00 am |
| Matthias Blume wrote:
> "Anton van Straaten" <anton@appsolutions.com> writes:
>
>
> False. You can run all the same tests. Maybe you find that they fail
> more often because, as you say yourself, people might actually take
> advantage of the language guarantees. But to say that you can't run
> the tests is nonsense.
The tests become worthless in practice when order is fixed, for the reason
you mention. You lose the ability to distinguish which code is supposed to
be independent of evaluation order when people take advantage of the
language guarantees outside of explicit sequencing constructs.
> And if your convention is to encode the information using certain
> coding conventions (as questionable a practice as this may be),
> then those tests will point out where the conventions were violated.
The convention loses significant value if it's not universally followed.
>
> And that's a good thing. It is an extremely clumsy and brittle way
> of encoding this type of information. I can't believe anyone can
> possibly defend it and keep a straight face.
My interest is in defending the ability to encode the information in
question, not in any specific technique for doing that. However, good
techniques seem in short supply. What alternative ways of encoding this
information do you suggest? Keep in mind that suggesting future
possibilities doesn't actually address the issue today, and that Scheme
currently does succeed in enforcing it in a way which some people find
satisfactory, if not ideal.
Also, as long as we're offering "let them eat cake" solutions, anyone
writing papers involving the semantics of Scheme can point out that their
results are based on a left-to-right dialect (or whatever), and all the
equivalences you've pointed out between unspecified order and fixed order
apply.
See also my reply to Jim Bender, dated today.
Anton
| |
| Anton van Straaten 2004-10-07, 9:00 am |
| Ron Garret wrote:
> In article <_Kp8d.3634$Vm1.2292@newsread3.news.atl.earthlink.net>,
> "Anton van Straaten" <anton@appsolutions.com> wrote:
>
is[color=darkred]
in[color=darkred]
>
> I won't find it many physics texts either. And your point would be...?
Let me come at that from the other direction. Where can I read up on this
principle, so that I can understand it as something other than a way to
defend some of the quirkier features of scripting languages?
program.[color=darkred]
they[color=darkred]
>
> Do they? How can I tell if I have a Scheme program whose semantics
> depend on OoE? If I have a Scheme program which accepts no input from
> the outside and has worked correctly on 99 runs, how can I be sure it
> will work correctly on the 100th run?
You can use an implementation with fixed evaluation order to be sure of
that. No-one (afaik) is suggesting that implementations should not be
allowed to offer fixed evaluation order. We're talking about the
specification here.
bugs[color=darkred]
languages[color=darkred]
>
> We tolerate side effects because they are useful.
You mean "we tolerate the bugs which side effects cause because side effects
are useful." The exact same argument applies to having the ability to
specify a distinction between code that depends on order of evaluation, and
code which does not.
> The whole point of
> having high level programming languages at all is to create a better
> "impedance match" between the kinds of information that computers
> process and the kinds of information human brains process. If we could
> rely on programmers to follow conventions, recognize errors, RTFM, etc.
> there would be no utility to high level languages at all. But they
> don't, so there is. And for some reason, most people find it easier to
> think in terms of side effects when they sit down to solve certain
> classes of problems. That's just the way that the human brain seems to
> be wired.
Oy. I think this belongs in c.l.l.
> [Off-topic rant: I have mostly stayed out of the Bill Richter wars,
> except to celebrate his temporary departure and quietly lament his
> return. The main reason I find everything Bill writes to be utterly
> irrelevant is that I reject his central tacit premise, that mathematics
> has value above all else in CS. It doesn't. The study of programming
> languages has as much to do with psychology, economics, and politics as
> it does with math, a fact that lamentably few of its practitioners seem
> to recognize.]
I agree that human factors are very important. In fact, the human factors
are central to this issue. The argument against "ambiguous semantics" is
primarily a semantic argument, not a human factors argument, and the
argument goes "we must restrict the language's expressivity in order to make
it tractable". But that's theoreticaly tractability, not practical
tractability. The argument can and has been made that fixed evaluation
order is less tractable in practice, because it leads to the masking of
fragile unintended order dependence.
one.[color=darkred]
>
> I doubt that very much.
Of course it would. See below.
lists[color=darkred]
>
> It is true that most expressions etc. don't depend on OoE, but that is
> simply a mathematical fact, and so it is nonsensical to speculate what
> the consequences would be if it weren't true. What we are talking about
> is how to treat those cases where it *does* (or might) matter.
>
> (This is a rather crucial point, and I am beginning to wonder if those
> who support unspecified OoE have simply missed it.)
The cases where it might matter include every function call whose argument
list itself contains a function call. That's quite a large set, and that
alone makes the approach you're suggesting unpalatable.
[re the compiler rearranging OoE:]
> So what? I'm arguing that the principle of least surprise dictates that
> the program semantics ought to be by default *as if* there were a fixed
> OoE, not that it *actually* have a fixed OoE.
My point was just that compiler optimizations are a secondary part of the
picture, which follow from having the ability in code to specify the
distinction between code that's order dependent and code that isn't. Having
the compiler be aware of some subset of order independent code "even if OoE
were specified" doesn't address any of my concerns.
question[color=darkred]
>
> I do not dispute that there is utility in having an unspecified OoE.
> What I am arguing against is making this the case by default.
That makes littel sense, given usage patterns in actual programs, including
imperative ones, and especially in a language in which everything other than
a macro/special form is a function call.
Anton
| |
| Anton van Straaten 2004-10-07, 9:00 am |
| "NJDSS Editorial Collective" <collective@njdss.org> wrote:
> Should you amend your post we would like to discuss an
> on-going contract for a periodic column in the NJDSS.
> Anton VonStraaten has been so busy lately...
True. Of course, it would help if the Collective would send me my author's
stipend more regularly.
> And the whole subject/object relationship hasn't been adequately
> explored in the Himalayan computing field (located 500 meters
> upslope outside of our offices). It's entirely possible we could
> sponsor a fellowship for advanced research if you would be
> so inclined...
I find this most interesting, since my work on the evanescent nature of
objects would be legendary, if not for the fact that the work in question
self-referentially demonstrates its subject, and thus does not enjoy the
sort of "concrete existence" which unenlightened modernists appeal to so
thoughtlessly.
If telecommuting is a possibility, my signed acceptance papers will be on
the next available yak.
Anton
| |
| Neelakantan Krishnaswami 2004-10-07, 4:00 pm |
| In article <3q69d.6979$Vm1.1407@newsread3.news.atl.earthlink.net>, Anton van
Straaten wrote:
>
> Some people complain that such an assertion is not statically checkable, and
> even dynamic checkability is harder than usual to come by. However, we
> don't usually check types statically in Scheme, either; and in practice,
> experience in Scheme, C, C++, and OCaml indicates that the issues resulting
> from unspecified evaluation order are certainly no more problematic than
> those that arise from unintentional order dependencies in language with
> fixed evaluation order (and arguably, less so). That's because evaluation
> order issues can occur in any language with side effects, regardless of the
> language's specified evaluation order.
That's not my experience. Every single order-of-evaluation-related bug
that I have ever had in a strict language has arisen when evaluation
was not left to right. (Not just in Scheme, but in Ocaml, too.) If you
fixed order of evaluation to left to right, I would never have ever
even seen a single instance of this kind of error.
I think there are some pretty good theoretical reasons for this, too.
If there is to be an isomorphism between the curried and uncurried
forms of functions (ie, (A x B) -> C and A -> B -> C) in an impure,
strict setting, then you must have have left-to-right order of
evaluation.
> Since examples such as (f (read) (read) (read)) are by far the exception,
> rather than the rule, they could easily be dealt with by a convenient
> special form.
No, this is literally the only source of order of evaluation bugs I've
ever had. I mean, I can see the pragmatic case not to declare a fixed
order -- it's not  to declare solid, existing implementations
non-conforming -- but I don't think there's any principled case
against fixing the order of evaluation to left to right.
--
Neel Krishnaswami
neelk@cs.cmu.edu
| |
|
| Neelakantan Krishnaswami wrote:
> I think there are some pretty good theoretical reasons for this, too.
> If there is to be an isomorphism between the curried and uncurried
> forms of functions (ie, (A x B) -> C and A -> B -> C) in an impure,
> strict setting, then you must have have left-to-right order of
> evaluation.
That is actually a very solid reason. I can feel myself being swayed.
>
> No, this is literally the only source of order of evaluation bugs I've
> ever had. I mean, I can see the pragmatic case not to declare a fixed
> order -- it's not to declare solid, existing implementations
> non-conforming -- but I don't think there's any principled case
> against fixing the order of evaluation to left to right.
I can contribute a (somewhat esoteric) bug that I have had
in the context of the Filinski encoding of monads in Scheme.
See the thread
http://groups.google.com/groups?sel...40het.brown.edu
where the following expression in the list monad
(reify (cons (reflect '(1 2))
(reflect '(5 6)))
would not give the correctly ordered answer.
Andre.
| |
| Matthias Blume 2004-10-07, 4:00 pm |
| "Anton van Straaten" <anton@appsolutions.com> writes:
> The problem with the opposing positions here tends to be that even when they
> acknowledge any value in the ability to specify order independence, they all
> seem to take the basic stance that this ability is worth sacrificing, in
> exchange for unambiguous semantics. No-one should be surprised that there's
> opposition to this idea. It offers unambiguous semantics only for a less
> expressive language, a language that cannot express certain properties of
> the programs written in it.
Hear, hear! Isn't that *precisely* the argument in favor of static
type systems? Fewer programs are legal, so having a legal program
carries more information. (The difference, of course, is that static
type systems are statically checkable, so the validity of the
information can be verified and does not have to be taken on faith.)
> Suggest a credible alternative to this, and I'm sure everyone will listen.
The alternative is to express this information some other way -- as
pragma annotations or something similar. Such a solution does not
compromise the semantics but can still give hints to programmers and
lint tools.
(Personally, I am perfectly happy with the obvious third alternative:
fix the evaluation order. That's because I personally consider the
loss of expressiveness so minor that I am constantly surprised how
people can get so worked up about this issue.)
> Otherwise, we're left fighting over whose preferences might get stomped on
> in a future standard, which makes for a lot of heat, and unusually little
> light.
Ok, just to make sure you realize that I do understand the issue, let
me put this whole thing a bit more formally:
Consider some programs p, p1, p2, ... and a correctness criterion C.
The correctness criterion depends on whether or not the language
specifies order of evaluation, so there really are two separate
criteria: Co and Cu (Ordered, Unordered).
The first question one certainly is interested in when considering
correctness is the basic one:
Co(p) ?
Cu(p) ?
I think we all agree that Cu(p) implies Co(p). In other words, more
programs are correct under specified order, so writing correct
programs under these rules might be a bit easier -- it certainly is no
harder.
Lemma: For all p, Cu(p) -> Co(p)
The second question, which captures the refactoring problem to some
extend, is this: Let there be two programs p1 and p2, perhaps related
in some way (e.g., p2 being a refactored version of p1). Does
correctness of p1 imply correctness of p2?
Co(p1) -> Co(p2) ?
Cu(p1) -> Cu(p2) ?
Let's abbreviate Co(p1) -> Co(p2) as CRo(p1,p2) and Cu(p1) -> Cu(p2) as
CRu(p1,p2).
Without doubt, there are cases where CRu(p1,p2) does not imply
CRo(p1,p2). This is what you are constantly arguing here: not
specifying the order makes fewer programs legal, therefore having a
legal program carries more information, and this extra information
might be the difference between being able to prove CRu(p1,p2) and not
being able to prove CRo(p1,p2).
There are at least two ways of arguing that this "advantage" might not
outweigh the advantage of Co(p) itself being strictly easier to
establish than Cu(p):
1. In the general case, CRo(p1,p2) and CRu(p1,p2) are, in fact,
unordered (i.e., neither implies the other).
However, one can imagine that p2 is restricted to programs where all
evaluation order is explicit (e.g., A-normal form), so by
definition we would have Cu(p2) = Co(p2). In this case, assuming
Co(p1) -> Co(p2), using the Lemma, we get:
Cu(p1) -> Co(p1) -> Co(p2) = Cu(p2)
For an important class of problems, it is indeed the case that
CRo(p1,p2) implies CRu(p1,p2).
However, if p2 is restricted in the way described, the "advantage"
for refactoring is lost after the first refactoring step.
Subsequent additional refactoring steps benefit nothing.
2. When actually refactoring code, I am not only interested whether
CRx(p1,p2) holds, but ultimately whether Cx(p2) holds. If all I
know is CRx(p1,p2) I have to either independently establish Cx(p1)
or Cx(p2). But that, according to the Lemma, is easier when x = o.
> SML made a number of other pragmatic choices: things like LET being
> equivalent to Scheme's LET*, for example.
False.
SML's "let" can express both Scheme's "let" and Scheme's "let*"
(ignoring order-of-evaluation guarantees):
let val x = ... works like Scheme's let*
val y = ...
let val x = ... works like Scheme's let
and y = ...
Although this has nothing to do with the argument at hand, incorrect
claims like this do not reflect well on your reasoning and might be
construed as evidence for a blind, uncritical bias towards the way
Scheme does things right now.
Matthias
| |
| Matthias Blume 2004-10-07, 4:00 pm |
| "Anton van Straaten" <anton@appsolutions.com> writes:
> [ ... ]but rather that the ability to communicate order of evaluation
> dependency distinctions in code becomes lost, if there is no
> "enforcement" mechanism whatsoever.
But in practice there currently is no enforcement mechanism. That's
my whole point: establishing that I did not violate the rules is too
difficult in general. That's why the rules are bad.
| |
| Matthias Blume 2004-10-07, 4:00 pm |
| "Anton van Straaten" <anton@appsolutions.com> writes:
> The convention loses significant value if it's not universally followed.
It isn't now.
> However, good techniques seem in short supply.
Nonsense. As I just wrote in a separate article, I can think of many
good ways of encoding this information. The fact that it hasn't been
done already is an indication that the problem might not be so
important after all. | | |