Re: routine arrow syntax and return/of types

2009-03-22 Thread Jon Lang
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

2009-03-20 Thread Darren Duncan

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



routine arrow syntax and return/of types

2009-03-19 Thread Darren Duncan

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


Re: routine arrow syntax and return/of types

2009-03-19 Thread Larry Wall
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


Re: routine arrow syntax and return/of types

2009-03-19 Thread Darren Duncan

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

2009-03-19 Thread Jon Lang
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