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.


Reply via email to