Re: syntax question: "method close is export ()" On Tue, Aug 05, 2008 at 05:43:57PM +0800, Audrey Tang wrote:
> John M. Dlugosz æå°:
>> Does that mean that traits can come before the signature?  Or should it 
>> be corrected to
>>     method close () is export { ... }
>
> It's a simple typo.  Thanks, fixed in r14572.

The strange thing is that we might have to support that order if we want
to allow user-defined operators in the signature, since

    sub infix:
	($x, $y, :$z = $x foo $y bar 1)
	is equiv(&infix:)
	{...}

would not know the precedence soon enough to know whether foo is tighter
or looser than bar.  Whereas

    sub infix:
	is equiv(&infix:)
	($x, $y, :$z = $x foo $y bar 1)
	{...}

could presumably attach that information in a timely fashion to the
definition of the foo operator.  'Course, there are workarounds in the
current scheme of things:

    sub infix:
	is equiv(&infix:)
	is sig(:($x, $y, :$z = $x foo $y bar 1))
	{...}

    sub infix:
	($x, $y, :$z = infix:($x, $y) bar 1)
	is equiv(&infix:)
	{...}

but I'm inclined to simplify in the direction of saying the signature
syntax is just a trait variant so the order doesn't matter.  The one
remaining question I see is whether it's possible to declare a sub
with the name "is":

    sub is is foo {...}

and if so, whether it's possible to have an anonymous sub with traits
and no signature:

    sub is foo {...}

I suspect we should bias it towards the first case on the grounds that
you can write the latter with an explicit "missing sig" sig as

    sub (*@_ is rw) is foo {...}

Though, of course, we could solve it the other direction with an
explicit "I am not a sub name" sub name.  Not sure which side least
suprise works on, but the fact that we already have a representation
for "no sig" seems to say we don't need an explicitly anonymous name.
But maybe such a name would be more generally useful, which would
make it a wash.  One obvious candidate for a null name:

    sub () is foo {...}

is of course not possible.  I suppose we could nudge things in a
direction that

    sub & is foo {...}

would work, since that'd be much like

    state $ = do { "I am a fake START block" }

But if we allow "sub &foo" then people will wonder what "sub @foo" means...

Larry


