headers
Bradd W. Szonye | 22 Mar 2004 01:01

Re: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Anton van Straaten wrote:
> It's not just about implementations and compilers, though.  Code
> involves communication to other humans, also, and this is often the
> more difficult part of its job, or at least the one it does less well
> (since by some accounts, too much effort has been put into doing
> compilation well).

I agree that communicating with other humans is much more important than
giving hints to a mechanical optimizer, although I'm loath to completely
ignore the latter. The LET vs LET* thing is nice because it lets the
programmer encode his intent for the benefit of both humans and the
compiler.

> The unspecified eval order constructs allow programmers to document
> their intent, and that can be important.  If they make an error and
> their documented intent doesn't match the program's actual semantics,
> that's an error.

That's how I see it too.

> The concern is that this sort of error is a difficult one to catch,
> and from a formal semantics perspective it's a doozy, which raises
> bogeyman terms like unsafe, unsound, unpredictable, unverifiable and
> non-deterministic (in the bad sense).

Yeah, it's ugly, but it's a trade-off. If you allow "sequence doesn't
matter" constructs, you can end up with ambiguous program behavior. But
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Schlie | 22 Mar 2004 01:14
Picon

Re: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Felix, Thanks for the clarification, however regardless of the "belief" that
a programmer may have with respect to the relative independence of a
collection of expressions, they may none the less actually have potentially
subtle interdependencies which may not clearly express themselves until
executed within an environment which chooses to evaluate them in a different
order; which will result in an otherwise needless unanticipated failure.

No mater how I look at it (and have honestly tried to identify any redeeming
virtue of the present scheme [pun intended] may have), I still arrive at the
conclusion that expression evaluation order should be clearly defined.

Where then personally (although likely minimally controversial, if not
possibly simply a bad idea for a number of reasons), I'd simplify scheme to
supporting only a sequentially evaluated non-recursively defined let, and a
sequentially evaluated recursively defined let* (effectively retiring the
historical let* let-rec constructs); but not willing to argue for it.

-paul-

> From: Felix Klock's PLT scheme proxy <pltscheme@...>
> Date: Sun, 21 Mar 2004 18:20:11 -0500
> To: Paul Schlie <schlie@...>
> Cc: "Bradd W. Szonye" <bradd+plt@...>, <plt-scheme <at> list.cs.brown.edu>
> Subject: Re: [plt-scheme] to define, or to let
> 
> Paul-
>
(Continue reading)

Permalink | Reply | 26 comments |
headers
Bradd W. Szonye | 22 Mar 2004 01:20

Re: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Paul Schlie wrote:
> Felix, Thanks for the clarification, however regardless of the
> "belief" that a programmer may have with respect to the relative
> independence of a collection of expressions, they may none the less
> actually have potentially subtle interdependencies which may not
> clearly express themselves until executed within an environment which
> chooses to evaluate them in a different order ....

That's hardly unique to this feature. The root cause of the problem here
is that the program's code does not match its design. No matter how you
spin it, it's still a programming error.

> ... which will result in an otherwise needless unanticipated failure.

The failure might be unanticipated, but I disagree that it's needless.
Given a program where the code does not match the design or the
programmer's intent, I would much rather see it fail than have it
"accidentally" succeed.
--

-- 
Bradd W. Szonye
http://www.szonye.com/bradd
Permalink | Reply | 25 comments |
headers
Paul Schlie | 22 Mar 2004 01:49
Picon

Re: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

The corollary would then be, in order to detect programmer errors enabled
by an inherently error prone ambiguously evaluated function, let, let*, and
let-rec constructs, to require that their parameters to be exhaustively
evaluated for interdependencies which would otherwise result in ambiguous
results when evaluated in different implementations; as opposed to giving
the implementation the liberty to conduct as complete as analysis as desired
to enable the parallelization of otherwise safe and simple sequential
evaluation semantics.

(The latter seems more practical to me, doesn't it to you?)

-paul-

> From: "Bradd W. Szonye" <bradd+plt@...>
> Date: Sun, 21 Mar 2004 16:20:51 -0800
> To: plt-scheme@...
> Subject: Re: [plt-scheme] to define, or to let
> 
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> Paul Schlie wrote:
>> Felix, Thanks for the clarification, however regardless of the
>> "belief" that a programmer may have with respect to the relative
>> independence of a collection of expressions, they may none the less
>> actually have potentially subtle interdependencies which may not
>> clearly express themselves until executed within an environment which
(Continue reading)

Permalink | Reply | 20 comments |
headers
Anton van Straaten | 22 Mar 2004 01:58

RE: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Bradd W. Szonye wrote:
> Paul Schlie wrote:
> > Felix, Thanks for the clarification, however regardless of the
> > "belief" that a programmer may have with respect to the relative
> > independence of a collection of expressions, they may none the less
> > actually have potentially subtle interdependencies which may not
> > clearly express themselves until executed within an environment which
> > chooses to evaluate them in a different order ....
>
> That's hardly unique to this feature.

Right.  For example, you could make the exact same argument for static
typechecking:

"Regardless of the 'belief' that a programmer may have with respect to the
types of expressions, they may none the less actually have potentially
subtly different types which may not clearly express themselves until
executed with a particular set of inputs ... which will result in an
otherwise needless unanticipated failure."

PLT Scheme experiences such a "needless" unanticipated failure every time it
produces a runtime type error.  Languages and programs that are not
statically typed have various disturbing semantic properties of their own,
but some of us like to put up with those, because we care more about the
other side of the tradeoff, to the point where we're willing to take a risk
that we know can be entirely eliminated, at a cost.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Anton van Straaten | 22 Mar 2004 02:21

RE: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

> The corollary would then be, in order to detect programmer errors
> enabled by an inherently error prone ambiguously evaluated function,
> let, let*, and let-rec constructs, to require that their parameters
> to be exhaustively evaluated for interdependencies which would
> otherwise result in ambiguous results when evaluated in different
> implementations; as opposed to giving the implementation the liberty
> to conduct as complete as analysis as desired to enable the
> parallelization of otherwise safe and simple sequential evaluation
> semantics.
>
> (The latter seems more practical to me, doesn't it to you?)

I don't see the connection between the two points.  The first point assumes
that a requirement is being imposed to automatically detect such errors
statically, or at least prior to normal execution.  That's an arbitrary
requirement, however, and there's certainly no need for the compiler to be
involved in this.

Re compiler analysis, compilers are in no way constrained by function or
LET-style constructs with unspecified evaluation order.  By definition, they
are free to compile those constructs in any order they see fit, without any
analysis whatsoever.  Nor are they unnecessarily constrained by sequencing
constructs, since where they can prove that sequence does not in fact
matter, they are as free to rearrange the sequence as they would be in any
other situation.

Looking at things from a compiler-centric perspective, I would be satisfied
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul Schlie | 22 Mar 2004 02:35
Picon

Re: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

However one represents an example of a program's failure to behave as
desired within the true breadth of it's range and domain; the other
is an example of scheme's failure to specify it's semantics sufficiently
to warrant a program's equivalent behavior differing, yet "compliant",
environments.

(the later can be easily remedied; solve the former, and you'll be wealthy.)

-paul-

> From: "Anton van Straaten" <anton@...>
> Date: Sun, 21 Mar 2004 19:58:27 -0500
> To: <plt-scheme@...>
> Subject: RE: [plt-scheme] to define, or to let
> 
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> Bradd W. Szonye wrote:
>> Paul Schlie wrote:
>>> Felix, Thanks for the clarification, however regardless of the
>>> "belief" that a programmer may have with respect to the relative
>>> independence of a collection of expressions, they may none the less
>>> actually have potentially subtle interdependencies which may not
>>> clearly express themselves until executed within an environment which
>>> chooses to evaluate them in a different order ....
>>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bradd W. Szonye | 22 Mar 2004 02:43

Re: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Paul Schlie wrote:
> However [a type error] represents an example of a program's failure to
> behave as desired within the true breadth of it's range and domain;
> the other is an example of scheme's failure to specify it's semantics
> sufficiently to warrant a program's equivalent behavior differing, yet
> "compliant", environments.

Scheme doesn't fail to specify the semantics of LET. It deliberately
specifies non-sequential semantics. You call it a failure; I call it a
feature.

Also, I don't know what you're trying to say in the first clause of your
sentence. A type error is still an example of a program's code failing
to match its design, and it's likely to result in the same kind of
mysterious errors.
--

-- 
Bradd W. Szonye
http://www.szonye.com/bradd
Permalink | Reply | 0 comments |
headers
Bradd W. Szonye | 22 Mar 2004 02:45

Re: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Paul Schlie wrote:
> The corollary would then be, in order to detect programmer errors
> enabled by an inherently error prone ambiguously evaluated function,
> let, let*, and let-rec constructs ....

How are non-sequential constructs "inherently error prone"? They aren't
even ambiguous. The order of evaluation isn't specified, but that's the
whole point of using such a construct!

By the way, please do not Cc: me when you reply. I already get a
perfectly good copy of the e-mail from the list software.
--

-- 
Bradd W. Szonye
http://www.szonye.com/bradd
Permalink | Reply | 10 comments |
headers
Anton van Straaten | 22 Mar 2004 02:55

RE: to define, or to let

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Paul Schlie wrote:
> However one represents an example of a program's failure to behave
> as desired within the true breadth of it's range and domain; the
> other is an example of scheme's failure to specify it's semantics
> sufficiently to warrant a program's equivalent behavior differing,
> yet "compliant", environments.

Correction: "...to warrant an *erroneous* program's equivalent behavior...".
And that, as I see it, is the crucial point here.  There's no reason that
erroneous programs should behave in a reliable way across implementations,
and many do not.

Anton
Permalink | Reply | 0 comments |

Gmane