On Sat, Sep 10, 2005 at 12:22:29PM +0100, Nicholas Clark wrote:
: I might have missed this somewhere in the documentation, but is Perl 6 going
: to have any documented notion of things like sequence points, undefined
: behaviour, etc?
I don't claim to be the expertest expert on sequence points, but
we've said a few things unofficially that should probably get baked
into Synopses at some point if they aren't already. The general
approach has been that there are some places we guarantee sequence,
and several places we guarantee the lack of sequence, and everything
in the middle is negotiable until 6.0.0 comes out, which is probably
saying that the Perl 6 translation of Pugs (along with its test suite)
will end up being the de facto standard where we haven't been explicit.
But we can say a few things we know now.
: Is it going to mandate that function arguments are evaluated
: in any particular order (eg left to right)?
Depends on what you mean by "evaluated", of course. Anyone making a
call to a function has to marshall the arguments in a Lazy structure
of some kind for binding to the eventual formals, and presumably
that marshalling happens left-to-right. But the actual evaluation
of the arguments might not happen at that point if what you're
marshalling is intrinsically lazy.
But Perl 6 makes a fundamental distinction between "item" parameters
and "list" parameters. Item (scalar) bindings are not lazy by default,
so as soon as you know you're binding to a scalar, you can evaluate
completely (though not past the Ref level). I've tried to define the
semantics of binding such that these scalar parameters can be bound
left to right, even in the presence of named parameters, by saying
that the named parameters are interrogated repeatedly each time a
positional parameter is being filled in but appears to be "missing".
The named parameters are not required to be evaluated unless bound,
I suspect, but I could be wrong on that.
List parameters are *not* forced to evaluate even when bound, though
some of the arguments may be naturally eager and evaluated themselves
when marshalled into the Lazy. The lazy pieces of the slurpy array are
forced to evaluate in the order they're demanded, which is typically
left to right, but not necessarily. You can pop the slurpy array,
and even if there are infinities in it, if the innards of the Lazy
can figure out how to give you the last value, they will.
You can force left-to-right evaluation at call time via **.
Junctional and hyper arguments are specifically allowed to be evaluated in
any order, and it is erroneous for the program to depend on the order.
: Is it going to fix the behaviour if you modify a variable more than
: once in an expression?
Doubt it. But it's hard to detect it in the general case (and no,
side-effect free languages are not the general case :-), so we just
probably call it erroneous, and encourage people to use a programming
style that limits side effects to one per statement, if not fewer.
Certainly I foresee a number of people adopting a pure-ish discipline
of only writing
my $x ::= stuff();
which can presumably can be treated as completely definitional
if stuff() can be presumed to have no side effects. (And the ::=
implies that if there are side effects, they happen at compile time.)
Of course, for provably pure stuff you can get away with
my $x := stuff();
or even
my $x = stuff();
And maybe there's even a way to enforce it under "use Monads", but I ain't
writing that module...
: Currently Perl 5 makes no written guarantees on many things, yet everyone has
: come to expect the current implementation's choices to be the way things must
: be. Is Perl 6 going to do the same, or will it be an explicit goal that
: anyone can implement a clean room Perl 6 compiler/runtime with only the
: written spec, without needing to match specific case behaviour encoded
: solely in regression tests?
We are not good enough spec writers to get away with that, and even
if we were, nobody's paying us enough to do it. :-)
I suspect the validation suite will have to serve as the spec for at
least some of the behavior. That being said, we can certainly do a
lot towards writing the tests in a sufficiently literate style that
they are almost as accessible as a spec, and maybe have more chance
of actually being right than a spec would have.
Maybe if we work the XP aspects right, the spec emerges from the tests.
: Perl 5 is also lets C's undefined behaviour poke through to the language
: level. Should Perl 6 avoid this completely? What's 1 << -1 in Perl 6?
Those sorts of things should be nailed down as much as possible.
We need a consistent semantics more than we need to squeeze every
last ounce of optimization out of the resulting assembly code.
Specialized code can do specialized things with pragmas and types,
but by default we need to be general whenever we can get away with it.
Larry
