RE: Perl 6 modules plan

[Garrett Goebel]

From: Graham Barr [mailto:[EMAIL PROTECTED]]
 On Mon, Aug 13, 2001 at 04:38:43PM -0700, Nathan Wiger wrote:
  And allow flexible calling styles. For example, you might say:
  
 # import args() for argument validation
 use Module::Interface qw/args/;
  
 sub my_func (@) {
 my %args = args({ positional = [qw/name email 
 phone/] }, @_);
 }
  
  Which would allow you to call your function two different ways:
  
 my_func($name, $email, $phone);
 my_func(name = $name, email = $email, phone = $phone);
 
 This is the king of thing that CGI does, and IMO is exactly 
 what we don't want.
 
 There should be ONE calling style for each sub/method. 
 Allowing this _will_ cause different people to use different
 calling styles and also possible confusion.

TOW of Perl?

What about RFC128? http://dev.perl.org/rfc/128.html

Subroutines: Extend subroutine contexts to
include name parameters and lazy arguments 

It gives us a cleaner way to mix and match order dependant and named
parameter lists. Not to mention the potential for optimization hints,
parameter type checking and constraints (no auto-vivication), lazy
evaluation, etc.

I don't have the experience to make well balanced judgements in language and
library design, but I would hope that RFC128 style function signatures would
be required. I'm sure modules which prioritize on performance would chose
ordered parameter lists, but higher level ones would benefit from a heavier
reliance on named parameters. And if people'd RTFM on RFC128, perhaps
calling style confusion would be minimal.

RE: Perl 6 modules plan

[Garrett Goebel]

From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
 On Tue, Aug 14, 2001 at 09:55:37AM -0500, Garrett Goebel wrote:
   There should be ONE calling style for each sub/method. 
   Allowing this _will_ cause different people to use different
   calling styles and also possible confusion.
  
  It gives us a cleaner way to mix and match order dependant and named
  parameter lists. Not to mention the potential for 
  optimization hints, parameter type checking and constraints
  (no auto-vivication), lazy evaluation, etc.
 
 I think you misunderstand.  This isn't named parameters vs prototyped
 parameters vs args as list.  The problem is the idea that functions
 should accept *multiple styles by default* which the proposed
 Module::Interface does.

I don't think I'm misunderstanding. -There's a first!

Why do we need a Module::Interface when RFC128 covers all this ground and
more? It provides for required, optional, and type-checking of positional
and named parameters. (and more).

 
 foo($this, $that, $whatever);
 
 foo( this = $this,
  that = $that,
  whatever = $whatever
);

Or per RFC128,

sub foo (INTEGER $this, STRING $that, FLOAT $whatever) {
  printf TMT %d %s, just my \$%.2f\n, $this, $that, $whatever
}
foo(1, 'way', 0.02);
foo(whatever: 0.02, this: 1, that: 'way');


 Saying that most core functions should be callable both ways is
 overkill.

I didn't say that. 

What I did say is that I hoped RFC128 style function signatures would be
required. That doesn't mean you have to use named parameters. Just that a
function signature would be required.

Graham stated that multiple calling styles are confusing... And I'd agree
that Module::Interface and existing modules like CGI.pm could easily lead to
confusion. But I don't see how that applies to the syntax proposed in
RFC128.

I suppose whether or not it is overkill to allow for both, will depend on
the overhead involved in how it is implemented. According to RFC128, named
parameters can be optionally specified. Either way, positional parameters
will always work. So per Perl6 w/ RFC128, it'll be positional parameters or
positional-and-named parameters.


 This is what CGI.pm does (for historical reasons, I
 believe, and not by design).  It's unnecessarily confusing and
 requires a not insignificant amount of life-support to make work.

CGI.pm does a lot of things for the convenience of its users. Like Tk and
File::Spec, CGI's functions can be called procedurally or as methods. But
lets not go there.

If RFC128 flies... I don't see why this would be confusing or require any
significant life-support. It'll be a language detail instead of an
implementation nightmare. Just because it is an issue now doesn't mean it
has to be one in Perl6.


 Having Module::Interface around to do this sort of thing when desired
 is nice, but please don't cannonize it.

No. I've kludged together similar things when I thought I need it. -But
RFC128 isn't a kludge. Though I'd so hoped that it would create world peace
;) 

Will subroutine signatures apply to methods in Perl6

[Garrett Goebel]

Any word from on high whether subroutine signatures will apply to methods in
Perl6? There's RFC128 and RFC97... but they both mostly dodge the issue of
methods.

The absense of method signatures for specifying required, optional, and
named parameters... not to mention type-checking for validation and dispatch
are why we've ended up with an assortment of parameter handling modules with
conflicting styles.