develooper Front page | perl.perl5.porters | Postings from July 2012

Re: Allowing named arguments in prototypes

Thread Previous | Thread Next
From:
Reini Urban
Date:
July 1, 2012 07:21
Subject:
Re: Allowing named arguments in prototypes
Message ID:
CAHiT=DFsbL35UEAVzbD9h_VFvPR6qh=eTWZOdq-TfGBHVD87fg@mail.gmail.com
On Sat, Jun 30, 2012 at 4:25 AM, Peter Martini <petercmartini@gmail.com> wrote:
> On Jun 30, 2012 5:17 AM, "Nicholas Clark" <nick@ccl4.org> wrote:
>>
>> On Sat, Jun 30, 2012 at 04:01:07AM -0500, Jesse Luehrs wrote:
>> > On Sat, Jun 30, 2012 at 08:32:07AM +0100, Nicholas Clark wrote:
>> > > 2) Defining a syntax which allows only simple scalars followed
>> > > optionally by
>> > >    a slurpy list prohibits a whole bunch of options on expansion
>> > > (possibly
>> > >    *all* of them). So we'd need to be pretty confident that this was
>> > > the
>> > >    best possible solution, and accept that we're ruling out doing
>> > > anything
>> > >    better.
>> >
>> > This isn't necessarily true - any proposal is almost certainly going to
>> > include this as a subset, so I'm not sure that implementing the bare
>> > minimum locks us out of things in the future. The main thing to be
>> > careful of is any features beyond just naming the parameters.
>>
>> Sort of.
>>
>> What I was trying to say was that any part *is* defined can't (easily,
>> quickly) be contradicted if a bigger plan needs it for something
>> different.
>>
>> *Designing* a workable fuller proposal but only implementing a useful
>> subset
>> initially is one thing.
>>
>> Designing and implementing a minimal system without specific thought for
>> where it could go next is another, as it runs the risk of closing off
>> avenues that are useful.
>>
>> An example of the latter would be to have sub ($foo, $bar) { ... } mean
>> read-write parameters, and then later decide that actually read-only
>> aliasing
>> would have been a better default. At which point it's not possible to do
>> this
>> because existing code out in the wild relies on the old behaviour.
>>
>> Nicholas Clark
>
> It doesn't though - M::S uses that syntax and can specify other per
> parameter attributes.
>
> sub foo($bar, $baz)
> sub foo($bar :ro, $baz)
> sub foo($bar is ro, $baz)
> sub foo(const $bar, $baz)
>
> Anything with a sigil is a name, anything without a sigil is a modifer; what
> modifier to use is another matter, but M::S and Mo[ou]se seem to have
> converged.

Yes.

I am prototyping this:
  https://github.com/rurban/perl/blob/typed/ro/pddtypes.pod
with this the pod of the types and const subset:
  https://github.com/rurban/perl/blob/typed/ro/pod/perltypes.pod

See *Declare function signatures and types (target 5.20)* and
and "Return type declarations".
prototypes and names parameters were designed to coexist easily.

There where just no good designs and implementations of named parameters,
solving the problems Nicholas explained. There should be no quick adhoc
shot into the dark without considering the implications.
Types arguments and return types were not even mentioned in this thread yet.

You have prototypes, names, types and type┬┤qualifiers (usually attributes,
but attributes are not yet usable compile-time). Then there are also
lexical subs
and return type declarations.
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About