Re: routine arrow syntax and return/of types
Darren Duncan wrote: > Jon Lang wrote: >> Spitballing here: you drew an analogy to the feed operators. I wonder >> if that analogy could be taken further: use --> and <-- outside of >> signatures as feed operators - but instead of feeding arrays back and >> forth, have them feed capture objects and engage in some implicit >> currying. That is: >> >> foo <-- $capture >> $capture --> foo >> >> would both be equivalent to: >> >> foo :assuming(|$capture) >> >> ...or something to that effect. So instead of composing a series of >> functions by nesting them in each others' argument lists, you could do >> so by chaining them together using --> or <--. > > That could be interesting. But do you have an example use case or example > code illustrating its use? Perhaps something like: my $name = "jonathan"; $name --> capitalize --> say; Or: $y = acos 'degrees' <-- sin 'radians' <-- $x; -- Jonathan "Dataweaver" Lang
Re: routine arrow syntax and return/of types
Jon Lang wrote:
And AFAIK the token --> is used in exactly one place in perl 6: within
signature syntax, to mark the transition from the parameter signature
to the "return type" signature. As with Darren, I don't see why this
would be a big problem. The biggest stumbling block that I can think
of is that a return type cannot have an invocant, whereas the
parameter signature might be able to have one. May I inquire as to
the nature of the complications that I'm missing, for my own
edification? (If you can't afford the time, I'll understand.)
Unless there is some rule that an invocant has to be at the start of the
parenthetical routine signature list, I don't see a problem.
So we just have for example:
sub myfunc (Int <-- Int $self: Int $other) {...}
In fact I would expect any invocant to be after the <-- since it is really just
a parameter.
Spitballing here: you drew an analogy to the feed operators. I wonder
if that analogy could be taken further: use --> and <-- outside of
signatures as feed operators - but instead of feeding arrays back and
forth, have them feed capture objects and engage in some implicit
currying. That is:
foo <-- $capture
$capture --> foo
would both be equivalent to:
foo :assuming(|$capture)
...or something to that effect. So instead of composing a series of
functions by nesting them in each others' argument lists, you could do
so by chaining them together using --> or <--.
That could be interesting. But do you have an example use case or example code
illustrating its use?
As for the idea I raised to support <--, I have gone ahead anyway and designed
it into my cross-breed of Perl 6 and SQL called Muldis D (as of v0.62.2), as
"the" way of declaring a routine, rather than one of 4 ways. See the following
url for a bunch of example routine signatures demonstrating it:
http://search.cpan.org/dist/Muldis-D/lib/Muldis/D/Core/Routines.pod
At the same time I revamped my routine declaration format in other ways, and as
you can see this aspect of Muldis D now looks so much like Perl 6 they might be
indistinguishable at a glance, or regardless I think it can serve as reasonable
examples of how Perl 6 itself could look.
-- Darren Duncan
Re: routine arrow syntax and return/of types
Darren Duncan wrote:
> Maybe the problem is a technicality with the parser because ...
>
> I'm guessing that the problem is that until you see the <-- then what you've
> read so far on its left is ambiguous as to whether it is a result type or a
> parameter. I can understand that but I don't know if its a big problem.
>
> AFAIK the token <-- isn't used anywhere yet in Perl 6 and so its presence
> inside a parameterized list would be unambiguous once you've read up to it.
And AFAIK the token --> is used in exactly one place in perl 6: within
signature syntax, to mark the transition from the parameter signature
to the "return type" signature. As with Darren, I don't see why this
would be a big problem. The biggest stumbling block that I can think
of is that a return type cannot have an invocant, whereas the
parameter signature might be able to have one. May I inquire as to
the nature of the complications that I'm missing, for my own
edification? (If you can't afford the time, I'll understand.)
> Anyway, while I would appreciate if <-- worked, if it doesn't then I can
> live with one of the existing alternatives ('of' being my current
> preference). This is a "nice to have" but not something I would push as
> hard yet as some other issues.
Yeah; definitely not an urgent request. I wonder how hard it would be
to write a module that hacks the parser to enable this feature...
Spitballing here: you drew an analogy to the feed operators. I wonder
if that analogy could be taken further: use --> and <-- outside of
signatures as feed operators - but instead of feeding arrays back and
forth, have them feed capture objects and engage in some implicit
currying. That is:
foo <-- $capture
$capture --> foo
would both be equivalent to:
foo :assuming(|$capture)
...or something to that effect. So instead of composing a series of
functions by nesting them in each others' argument lists, you could do
so by chaining them together using --> or <--.
But, like Darren's request, this definitely isn't something that I'd
insist on for 6.0.0.
--
Jonathan "Dataweaver" Lang
Re: routine arrow syntax and return/of types
Larry Wall wrote:
On Thu, Mar 19, 2009 at 02:18:35PM -0700, Darren Duncan wrote:
Yes, --> is the "of" type, not the "as" type, as S02 I think says.
Good to know.
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) {...}
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.
Maybe the problem is a technicality with the parser because ...
I'm guessing that the problem is that until you see the <-- then what you've
read so far on its left is ambiguous as to whether it is a result type or a
parameter. I can understand that but I don't know if its a big problem.
AFAIK the token <-- isn't used anywhere yet in Perl 6 and so its presence inside
a parameterized list would be unambiguous once you've read up to it.
Anyway, while I would appreciate if <-- worked, if it doesn't then I can live
with one of the existing alternatives ('of' being my current preference). This
is a "nice to have" but not something I would push as hard yet as some other issues.
Thank you. -- Darren Duncan
Re: routine arrow syntax and return/of types
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
routine arrow syntax and return/of types
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.
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.
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.
-- Darren Duncan
