On Thu, Mar 19, 2009 at 02:18:35PM -0700, Darren Duncan wrote:
> I have a question and a request.
>
> In http://perlcabal.org/syn/S06.html#Named_subroutines it says:
>
> The general syntax for named subroutines is any of:
>
> my RETTYPE sub NAME ( PARAMS ) TRAITS {...} # lexical only
> our RETTYPE sub NAME ( PARAMS ) TRAITS {...} # also package-scoped
> sub NAME ( PARAMS ) TRAITS {...} # same as "our"
>
> The return type may also be put inside the parentheses:
>
> sub NAME (PARAMS --> RETTYPE) {...}
>
> In http://perlcabal.org/syn/S06.html#Subroutine_traits there is a
> distinguishing between 'of' and 'returns', such that 'of' is part of the
> external routine signature and 'returns' is just an internal constraint.
That bit was incorrect, "returns" should have been "as", to be consistent
with S02 "Hierarchical types".
> Now first of all I wanted to ask/clarify, are all of the above forms, the
> "RETTYPE sub" and "--> RETTYPE", equivalent to the "of" trait, meaning
> they are part of the external signature, and that none are like "returns"
> being internal to the routine only? That's how I hope it is.
Yes, --> is the "of" type, not the "as" type, as S02 I think says.
> Second, since the "sub NAME (PARAMS --> RETTYPE) {...}" form looks nice
> visually, I would like to request a variant of that form, that flips the
> arrow:
>
> sub NAME (RETTYPE <-- PARAMS) {...}
>
> I ask because I like to declare my result type before my parameters,
> since the declaration then reads in the same order as corresponding
> invocation items, as well as having the shorter and more important
> declaration appearing first (result type vs parameters):
>
> my $result = myfunc( $arg1, $arg2 );
>
> And at the same time it has the visually distinctive arrow syntax which
> is very easy to read.
>
> While "RETTYPE sub" and "of RETTYPE" provides the first advantage, it
> doesn't provide the second.
>
> Also providing both versions gives symmetry in the way that you have both
> of the <== and ==> feed operators so users can order operations visually
> as per their preference.
>
> I also don't believe you are already using <-- for anything so it is free.
>
> And I don't believe that there should be any problem incorporating this
> option given the other issues like named invocants or longname
> parameters; you just keep those with PARAMS as you did before, putting
> the lot on the right side of the <--.
>
> Note that this request is only useful to me if the existing --> means
> 'of' and not 'returns'.
>
> Thank you in advance for considering this request.
Well, yes, that would be pretty, but the big problem with it is that
it's terribly ambiguous, given that the other-ended form can also
start with a type. (I can think of at least five mechanisms to force
it to work, but they're all pretty ugly when we're trying to maintain
a predictive parser outside of opererator precedence expressions,
which this isn't one of.) It's also getting just a little dicey to
provide a *fourth* way to do something when we already have three.
Larry
