Re: Optional binding

[Larry Wall]

On Mon, Mar 07, 2005 at 03:03:08AM +0200, Yuval Kogman wrote:
: On Sun, Mar 06, 2005 at 02:13:09 -0700, Luke Palmer wrote:
: > What is output:
: > 
: > sub foo($x, ?$y, [EMAIL PROTECTED]) {
: > say "x = $x; y = $y; z = @z[]";
: > }
: > 
: > my @a = (1,2,3);
: > foo($x, @a);
: 
: And is
: 
:   $a ==> foo $x;
: 
: The same?

Nope, that's part of why we came up with pipes in the first place,
You example (assuming you meant @a there) is equivalent to 

foo($x, undef, @a);

or
foo $x <== @a;

or

foo $x, z => [EMAIL PROTECTED]

Larry

Comma in (sub) traits?

[wolverian]

Hello all,

while writing some experimental code with Pugs, I realised that it is a
bit hard for me to parse the following type of declaration:

sub greeting (Str $person) returns Str is export {
"Hello, $person"
}

Specifically, the 'is export' trait is too buried. Reformatting it like
this helps:

sub greeting (Str $person)
returns Str is export {
"Hello, $person"
}

But I really do not like the vertical alignment of the traits and the
body of the sub. So we're back to the first situation. We could also put
the 'returns' on the first line, after the signature (and strictly
speaking it at least can be a part of the signature), and the traits on
successive lines after that, but the alignment problems kicks in again.

There are other ways to format the declaration, like indenting the
traits line:

sub greeting (Str $person) returns Str
is export {
"Hello, $person"
}

This looks distinctly odd to me, although I think it works better than
the aligned version. Moving the traits line to column 0 is even weirder.

I think it is clear that I do not want to put the { on its own line. :)

The problem can be alleviated a bit by giving each trait a more
separable visual identity:

sub greeting (Str $person) returns Str, is export {
"Hello, $person"
}

The above works better for me than either of the previous examples. So
my question is: can this be legal Perl 6 code (and will it DWIM)? There
are ways to format this I didn't think of, I'm sure, so I'd like to know
too what the recommended style is. (perl6doc perlstyle...)

This same problem (well, it is a problem to me) applies to other places
where traits are used as well, but I'm specifically asking in the
context of named subroutine declarations, since parsing the comma seems
at least possible there. The visual distinction in a regular 'my'
declaration brought by the comma might also look too much like a list.
(It probably is a list.)

Sorry if this has been discussed before, or even in the design
documents. I'm also sorry if this is too rambling for the list. It's not
that important, just a thought.

Cheers,
wolverian


signature.asc
Description: Digital signature

Re: [RELEASE] Parrot 0.1.2 "Phoenix" Released!

[[EMAIL PROTECTED]]

Leo, you (or someone) might want to:

s/Poicephalus/Phoenix/

on parrotcode.org etc.

When you get a spare minute ;-)

-- 
Ciao
Richard Foley
Ciao - shorter than aufwiedersehen

http://www.oreilly.com/catalog/perldebugpr/ 

-Original Message-
> Date: Sun,  6 Mar 2005 16:57:38 +0100
> Subject: [RELEASE] Parrot 0.1.2 "Phoenix" Released!
> From: Leopold Toetsch <[EMAIL PROTECTED]>
> To: Perl 6 Internals 

> On behalf of the Parrot team I'm proud to announce the release of
> Parrot 0.1.2.
> 
> What is Parrot?
> 
> Parrot is a virtual machine aimed at running Perl6 and other dynamic
> languages.
> 
> Parrot 0.1.2 contains a lot of new stuff:
> 
> - New string handling code. Strings now have charset and encoding
> - Parts of a generational garbage collector
> - Better Python support, separated into dynclasses
> - Parrot Grammar Engine
> - Improved test coverage and documentation
> - and a lot more
> 
> After some pause you can grab it from
> .
> 
> As parrot is still in steady development we recommend that you
> just get the latest and best from CVS by following the directions at
> .
> 
> Turn your web browser towards  for more
> information about Parrot, get involved, and:
> 
> Have fun!
> leo
> 
>

Re: Comma in (sub) traits?

[Thomas Sandlaß]

wolverian wrote:
There are other ways to format the declaration, like indenting the
traits line:
Yes, I like:
 sub greeting( Str $person )
 returns Str
 is export
 {
 "Hello, $person"
 }
With the sub-line as some kind of intro and the block as the terminator.
A longer signature would be aligned after the opening paren---and along
the zone markers.
Regards,
--
TSa (Thomas Sandlaß)

Re: Comma in (sub) traits?

[Aldo Calpini]

wolverian wrote:
Hello all,
while writing some experimental code with Pugs, I realised that it is a
bit hard for me to parse the following type of declaration:
sub greeting (Str $person) returns Str is export {
"Hello, $person"
}
don't know if it helps, but I guess that you can also write it like 
this, if you prefer:

sub greeting(Str $person) {
returns Str;
is export;
"Hello, $person";
}
(this guess is based on something I recall having read in A12 about 
classes; if my guess is wrong, I'll be happy to stand corrected :-).

cheers,
Aldo

Re: Optional binding

[David Storrs]

On Sun, Mar 06, 2005 at 11:58:43PM -0800, Larry Wall wrote:
> On Sun, Mar 06, 2005 at 02:13:09AM -0700, Luke Palmer wrote:
> : What is output:
> : 
> : sub foo($x, ?$y, [EMAIL PROTECTED]) {
> : say "x = $x; y = $y; z = @z[]";
> : }
> : 
> : my @a = (1,2,3);
> : foo($x, @a);
> 
> I think it should say something like:
> 
> Use of undefined value at foo line 2
> x = ; y = 1 2 3; z = 
> 
> Optional parameters are greedy, and @a means [EMAIL PROTECTED] in a scalar 
> context.
> 
> Larry

Urk. I, for one, will definitely find this surprising.  I would have
expected:

  x = ; $y = 1; z = 2 3

But I suppose it's all a question of learning to love the Brave New
World in which arrays are actually objects (sort of).

--Dks

-- 
[EMAIL PROTECTED]

Re: [RELEASE] Parrot 0.1.2 "Phoenix" Released!

[David Storrs]

On Sun, Mar 06, 2005 at 04:57:38PM +0100, Leopold Toetsch wrote:
> On behalf of the Parrot team I'm proud to announce the release of
> Parrot 0.1.2.

First:  Congratulations to everyone for this release!

Second: What will it take before Parrot moves to a 0.2 (0.3, 0.4...)
release?  

--Dks

Re: Comma in (sub) traits?

[David Storrs]

On Mon, Mar 07, 2005 at 03:43:19PM +0100, Aldo Calpini wrote:

> don't know if it helps, but I guess that you can also write it like 
> this, if you prefer:
> 
> sub greeting(Str $person) {
> returns Str;
> is export;
> "Hello, $person";
> }
> 
> (this guess is based on something I recall having read in A12 about 
> classes; if my guess is wrong, I'll be happy to stand corrected :-).

On reflection, I see why that probably works.  I also pray that I
never have to maintain code that uses it, because it seems very
misleading. .

--Dks
-- 
[EMAIL PROTECTED]

Re: Optional binding

[Aldo Calpini]

David Storrs wrote:
Urk. I, for one, will definitely find this surprising.  I would have
expected:
  x = ; $y = 1; z = 2 3
to obtain what you have expected, you need to explicitly treat the array 
as a list of values with the unary splat:

foo($x, [EMAIL PROTECTED]);
But I suppose it's all a question of learning to love the Brave New
World in which arrays are actually objects (sort of).
more to the point, arrays are automagically referenced in scalar context:
@a = @b;  # same as perl5
$a = @b;  # means $a = [EMAIL PROTECTED] in perl5
$a = [EMAIL PROTECTED]; # means $a = @b in perl5 (more or less)
another thing that may surprise you (it still surprises me, somehow):
sub bar($x, $y, $z) { ... }
  # ^ note x is scalar here!
my @coords = (1.0, 3.0, 5.0);
bar(@coords); # wrong
  # x => [EMAIL PROTECTED], y => undef, z => undef
bar([EMAIL PROTECTED]); # ok
but then, you could define:
multi sub bar($x, $y, $z) { ... }
multi sub bar(@coords is shape(3)) {
my($x, $y, $z) = @coords;
return bar($x, $y, $z);
}
bar(@coords); # ok now
cheers,
Aldo

Re: Comma in (sub) traits?

[Larry Wall]

On Mon, Mar 07, 2005 at 12:55:49PM +0200, wolverian wrote:
: Hello all,
: 
: while writing some experimental code with Pugs, I realised that it is a
: bit hard for me to parse the following type of declaration:
: 
: sub greeting (Str $person) returns Str is export {
: "Hello, $person"
: }
: 
: Specifically, the 'is export' trait is too buried.

Here are some alternatives you don't seem to have considered:

sub greeting (Str $person) is export returns Str {
"Hello, $person";
}

sub greeting (Str $person) is export
  returns Str {
"Hello, $person";
}

sub greeting (Str $person)
  is export
  returns Str {
"Hello, $person";
}

sub greeting (Str $person)
  returns Str
  is export {
"Hello, $person";
}

my Str sub greeting (Str $person) is export {
"Hello, $person";
}

my Str
sub greeting (Str $person) is export {
"Hello, $person";
}

: Reformatting it like this helps:
: 
: sub greeting (Str $person)
: returns Str is export {
: "Hello, $person"
: }
: 
: But I really do not like the vertical alignment of the traits and the
: body of the sub. So we're back to the first situation. We could also put
: the 'returns' on the first line, after the signature (and strictly
: speaking it at least can be a part of the signature), and the traits on
: successive lines after that, but the alignment problems kicks in again.
: 
: There are other ways to format the declaration, like indenting the
: traits line:
: 
: sub greeting (Str $person) returns Str
: is export {
: "Hello, $person"
: }
: 
: This looks distinctly odd to me, although I think it works better than
: the aligned version. Moving the traits line to column 0 is even weirder.
: 
: I think it is clear that I do not want to put the { on its own line. :)

That's how I started out in C, and then eventually mutated to a form
in which I put the { on its own line only if I had multiple lines in
the signature.  In that case I decided the consistency was overrated.
I basically do the same with any bracketing construct now--if the front
stuff rates more than one line, then I pull the brack out front on its
own line, and not otherwise.  It seems the least insane approach to me,
but I realize the inconsistency will bug some people more than others.

Anyway, this policy works for me, and for more than just sigs--it makes
it possible to split up the parameters when they are long and
complex, so I can happily write anything from

sub Foo foo (Bar $bar) is export {
...
}

to

method foo ( $self:
 $odd returns Int where { $_ % 1 },
 $even return Int where { not $_ % 1 },
 Block ?&permutator,
 [EMAIL PROTECTED]
   )
   returns Footype
   is good
   is bad
   is ugly
{
...
}

or maybe

method foo ( $self:
 $odd returns Int where { $_ % 1 },
 $even return Int where { not $_ % 1 },
 Block ?&permutator,
 [EMAIL PROTECTED] )
returns Footype
is good
is bad
is ugly
{
...
}

Well, that's not exactly pretty, but I figure that if you've blown
that many lines on the signature, another line for the opening curly
isn't that much, and makes it visually easy to find where the code
actually starts.  Anyway, I think it's more important to have a style
that can mutute from horizontal to vertical form than it is to have
a consistent style.

: The problem can be alleviated a bit by giving each trait a more
: separable visual identity:
: 
: sub greeting (Str $person) returns Str, is export {
: "Hello, $person"
: }
: 
: The above works better for me than either of the previous examples. So
: my question is: can this be legal Perl 6 code (and will it DWIM)? There
: are ways to format this I didn't think of, I'm sure, so I'd like to know
: too what the recommended style is. (perl6doc perlstyle...)
: 
: This same problem (well, it is a problem to me) applies to other places
: where traits are used as well, but I'm specifically asking in the
: context of named subroutine declarations, since parsing the comma seems
: at least possible there. The visual distinction in a regular 'my'
: declaration brought by the comma might also look too much like a list.
: (It probably is a list.)

Yes, that's the basic problem with comma, and the declaration of traits
on "my" and "sub" is one thing I *would* like to keep consistent.  I'm
not consistent about consistency, you see, except when I am...

And I try to believe six foolish consistencies before breakfast each day. :-)

Larry

Re: Comma in (sub) traits?

[Larry Wall]

On Mon, Mar 07, 2005 at 08:27:10AM -0800, David Storrs wrote:
: On Mon, Mar 07, 2005 at 03:43:19PM +0100, Aldo Calpini wrote:
: 
: > don't know if it helps, but I guess that you can also write it like 
: > this, if you prefer:
: > 
: > sub greeting(Str $person) {
: > returns Str;
: > is export;
: > "Hello, $person";
: > }
: > 
: > (this guess is based on something I recall having read in A12 about 
: > classes; if my guess is wrong, I'll be happy to stand corrected :-).
: 
: On reflection, I see why that probably works.  I also pray that I
: never have to maintain code that uses it, because it seems very
: misleading. .

Yes, and it wouldn't work at all if you ever wanted to autoload anything.
If we ever get to where we're autoloading class bodies, they'd have the
same problem with embedded declarations.  The compiler can't work with
information that isn't there.

Larry

Re: Comma in (sub) traits?

[Thomas Sandlaß]

Larry Wall wrote:
Yes, and it wouldn't work at all if you ever wanted to autoload anything.
If we ever get to where we're autoloading class bodies, they'd have the
same problem with embedded declarations.  The compiler can't work with
information that isn't there.
This is something that is blurry to me: how does one separate declaration
and implementation. It is clear that a declaration has got a {...} block
and an implementation doesn't. But does that mean that there are package
files that function like header files in C++ or like interface files in
Ada and Modula?
Or does that work more like Cecil signature declarations which can be
spread out as needed and actually express a callers expectations which
can be matched with the implementation side?
MfG
--
TSa (Thomas Sandlaß)

Re: Optional binding

[Larry Wall]

On Mon, Mar 07, 2005 at 05:36:08PM +0100, Aldo Calpini wrote:
: but then, you could define:
: 
: multi sub bar($x, $y, $z) { ... }
: multi sub bar(@coords is shape(3)) {
: my($x, $y, $z) = @coords;
: return bar($x, $y, $z);
: }
: 
: bar(@coords); # ok now

Or, assuming you might want to generalize to N dimensions someday, just

sub bar ([EMAIL PROTECTED]) {...}

and deal with it as in Perl 5 as a variadic list.  I suppose one could say

sub bar ([EMAIL PROTECTED] is shape(3)) {...}

and get checking on the argument count.

Larry

Re: How are types related to classes and roles?

[Thomas Sandlaß]

HaloO,
another self-reply :)
I've added a little hack that classifies strings
into these areas 0 to 3 to illustrate my idea of
a type lattice on which composes the background
of the Perl 6 Type System. Pattern matching and
type systems are related but the question for
Perl 6 is: how exactly?
The topmost type Any has a very nice mnemonic: it's
the any-junction of all types that have no direct
supertype---their lub. Likewise there could be a None
that is the none-junction of all types that have no
subtype---their glb.
This means the Any actually depends on the loaded
program. If it only uses e.g. the unrelated types
A, B and C then Any is A|B|C. Likewise for programs
that implicitly handle strings and do numerics one
gets Any = Str|Num.
BTW, are Num and Int distinct or is there a
relation: Int is/does Num?
Regards,
--
TSa (Thomas Sandlaß)
#! /usr/bin/perl

$s = @ARGV[0];

if ($s =~ /(^aa.*$)|(^.*bb$)/) # perl6: $s ~~ m:overlap/(^aa.*$)|(^.*bb$)/
{
   print "success:  <$1>  <$2>\n"; 
}
else
{
   print "match:  <$1>  <$2>\n";
}

if  ($s =~ /^aa.*$/  || $s =~ /^.*bb$/ || $s =~ /^.*aa.*bb.*$/) { print "<:  A|B\n";  }
if  ($s !~ /^aa.*$/  && $s !~ /^.*bb$/ && $s !~ /^.*aa.*bb.*$/) { print "<: none(A,B)\n"; }

if (($s =~ /^aa.*$/  && $s !~ /^.*bb$/) ||
($s !~ /^aa.*$/  && $s =~ /^.*bb$/)   ) { print "<:  A^B\n";  }
if  ($s =~ /^aa.*$/){ print "<:  A\n";}
if  (   $s =~ /^.*bb$/) { print "<:B\n";  }
if  ($s =~ /^aa.*$/  && $s =~ /^.*bb$/) { print "<:  A&B\n";  }


print "===\n";

if  ($s =~ /(aa.*)/) { print "aa = $1\n"; }
if  ($s =~ /(.*bb)/) { print "bb = $1\n"; }

if  ($s =~ /aa.*/ || $s =~ /.*bb/)  { print "<:  A|B\n";  }
if  ($s !~ /aa.*/ && $s !~ /.*bb/)  { print "<: none(A,B)\n"; }

if (($s =~ /aa.*/  && $s !~ /.*bb/) ||
($s !~ /aa.*/  && $s =~ /.*bb/)   ) { print "<:  A^B\n";  }
if  ($s =~ /aa.*/)  { print "<:  A\n";}
if  ( $s =~ /.*bb/) { print "<:B\n";  }
if  ($s =~ /aa.*/  && $s =~ /.*bb/) { print "<:  A&B\n";  }

Re: Comma in (sub) traits?

[Juerd]

Larry Wall skribis 2005-03-07  8:40 (-0800):
> method foo ($self: $odd returns Int where { $_ % 1 }, $even
> return Int where { not $_ % 1 }, Block ?&permutator, [EMAIL PROTECTED])
> returns Footype is good is bad is ugly { ... }

That someone took the time to bring this up pleases me. I'm very strict
when it comes to indenting and what I find most readable and thus
prefer. Of course, everyone should have their own style and there's no
shame in having something that some consider ugly. Still, for my own
code, I wish to keep things the way they are.

I indent in two situations. The first is continuation of a statement,
when things don't fit in 80 characters. I try to do this after an infix
operator, or before it if the infix operator is or/and/xor/||/$$/->. The
only thing changing there is the addition of ^^, // and err. And of
course that -> is now spelled ..

The second place where I allow myself to indent is within nested
brackets, or sometimes some other circumfix delimiter. If an { belongs
to a certain control statement, it should not have its own line. If any
newline is in the delimiters, even the first and last elements in them
should be on their own lines.

Indentation is always 4 columns. Never 8, never 2. The only exception is
vertical alignment. Outdents exist only to naturally end indentation.

Subs are a problem in Perl 6, because their declaration can be very long
and easily span multiple lines.

With my current "rules", I'd end up with

method foo (
$self:
$odd  returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) returns Footype is good is bad is ugly {
...
}

The { is not really on the same line as "method", but at least it's not
on its own.

But it is indeed hard to parse a list of things that have no well
visible separator. I could break my one-space-max rule:

method foo (
$self:
$odd  returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) returns Footype  is good  is bad  is ugly {
...
}

But that feels like there really are commas, but they were made
invisible. I could also break my continued-lines-are-indented rule:

method foo (
$self:
$odd  returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) 
returns Footype
is good
is bad
is ugly {
...
}

But then, the other way around is prettier:

method foo
returns Footype
is good
is bad
is ugly (
$self:
$odd  returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) {
...
}

Not that I like ") {", but I'm used to seeing it from Perl 5's if. This
makes "method foo" look much less important than it is. But with
indentation, the block is no longer clearly visible:

method foo
returns Footype
is good
is bad
is ugly (
$self:
$odd  returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) {
...
}

Or { needs to go on its own line, which really disturbs me if the { is
not the beginning of a term. And this style is wrong because either ()
or {} need to not line up.

The thing missing is indeed the comma. Looking for other places where
comma is "missing", I thought of qw, or its new <> variant. Isn't the
following a neat solution for the problem we're faced with?

method foo (
$self:
$odd  returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) returns Footype, is  {
...
}

Okay, I cheated by still adding a comma. How about allowing this then:

method foo (
$self:
$odd  returns Int where ...,
$even returns Int where ...,
Block ?&permutator,
[EMAIL PROTECTED]
) :returns :is {
...
}

I'm not sure what to think of my own suggestion. I find this neat and
ugly at the same time. Ugly, because now something that used to be
barewordish/keywordish now feels like strings, beatiful because it solves
a problem, neat because it's syntax that exists elsewhere too. 

I think allowing comma or finding another character that can replace it
is the best option, but I think we're low on ASCII characters. Backticks
can be beatiful, but not for this :)

Hm, infix +? If I understand things correctly, it's invalid in the
current design anyway. It communicates that things all belong together,
but it looks really weird:

method foo + returns Footype + is good + is bad + is ugly

And it really screams for allowing different order:

is good + returns Footype + method foo + is bad + is ugly

So that is probably not a good idea. Infix & has the same

Re: Comma in (sub) traits?

[Larry Wall]

On Mon, Mar 07, 2005 at 05:53:23PM +0100, Thomas Sandlaß wrote:
: Larry Wall wrote:
: >Yes, and it wouldn't work at all if you ever wanted to autoload anything.
: >If we ever get to where we're autoloading class bodies, they'd have the
: >same problem with embedded declarations.  The compiler can't work with
: >information that isn't there.
: 
: This is something that is blurry to me: how does one separate declaration
: and implementation. It is clear that a declaration has got a {...} block
: and an implementation doesn't. But does that mean that there are package
: files that function like header files in C++ or like interface files in
: Ada and Modula?

In theory, yes, though I would hope more like Ada than C++.  #include
is a rotten way to do business.  The idea of Perl's "use" is that you're
essentially calling a subroutine in the package that gives you as much
of the definition as you need.  The fact that it might define a whole bunch
of other stuff at the same time is immaterial to you.  As in happens,
it might have already been declared by a previous "use", as well as later
in a lazy fashion.  It's really the import function that is managing the
interface though.  The import mechanism might be different in Perl 6, but
the underlying idea that you execute real Perl code to define things
is certainly going to carry over from Perl 5.

: Or does that work more like Cecil signature declarations which can be
: spread out as needed and actually express a callers expectations which
: can be matched with the implementation side?

I am not familiar with Cecil, but in Perl 6 caller expectations
are primarily expressed through the actual types you feed to MMD.
If the compiler can figure out more based on your own declarations,
that's fine, but the bias is definitely toward late binding.

I suppose if a user defines an normal inner sub that redispatches to
an outer set of multi subs, it functions a bit like a user-defined
expectation.  We don't currently have a way of directly mapping a set
of inner multis to a set of outer multies without going through an
interposed non-multi.

We also give a bit of user-defined interface control in letting the user
tell the module which version it wants to act like.  In the degenerate
case, that means it just picks the right file, but we should recognize
that the version we specify in a use is maybe an interface version, and
multiple interfaces could be served up by a single back-end implementation.
That approach might help with resource collisions between different versions
of the same module.

Beyond that, we provide the user with aliasing and delegation and
wrappers, at least on a sub/method level.  But given that all code
that executes is a sub on some level, there can probably hooks to
wrap classes and modules too, if ordinary inheritance, composition,
and delegation aren't up to the task.  But at some point you just
give up and call it cheating, er, I mean, AOP.  :-)

Basically, once you realize the compiler is not longer doing the
compilation, but just helping the program compile itself by running
odd bits of code here and there, the door is open to turn Perl into
any other language you like.  The only question is what discipline
the culture will enforce around the complete mayhem that is possible.
It is at this point that I am placing my trust in the Perl community.
(But then, my definition of "community" is somewhat Darwinian...)

Larry

Adding linear interpolation to an array

[Dave Whipp]

I was trying to work out how to get non-integer indexes working for an 
array -- initially using linear interpolation, though perhaps later it 
would be generalized. Can anyone comment on whether this simple role 
would work as I expect. Does defining the invocant as "Num @self is 
constant" constrain the application of the role to read-only uses of 
indices? Does the explicit indexing by an "int" typed value ensure that 
it'll be non-recursive under MMD?

  role LinearInterpolation
  {
multi method Num postcircumfix:«[]» (
Num @self is constant : Num $real_index)
{
   int $integer_index = int $real_index;
   Num $first_value = @self[$integer_index];
   return $first_value if $integer_index == $real_index;
   Num $second_value = @self[$integer_index+1];
   Num $delta = $second_value - $first_value;
   Num $weight = $real_index - $integer_index;
   return $first_value + $delta * $weight;
}
  }
  my @test does LinearInterpolation;
  @test[0] = 1;
  @test[1] = 3;
  assert @test[0] == 1;
  assert @test[0.5] == 2;
  assert @test[1] == 3;
If I later decare a sub as
  sub foo ( @in does LinearInterpolation ) { ... }
Would I be able to pass a normal (non-interpolating) array to this sub, 
and then access it using non-integer indices (i.e. is the data in the 
array independent of the interface through wich it is accessed).

Dave.

Re: Optional binding

[Aldo Calpini]

Larry Wall wrote:
Or, assuming you might want to generalize to N dimensions someday, just
sub bar ([EMAIL PROTECTED]) {...}
and deal with it as in Perl 5 as a variadic list.  I suppose one could say
sub bar ([EMAIL PROTECTED] is shape(3)) {...}
and get checking on the argument count.
if I understand correctly, without using multi subs:
sub bar(@coords is shape(3)) { ... }
bar(@xyz); # ok
bar( [$x, $y, $z] ); # ok
bar($x, $y, $z); # compile-time error
while:
sub bar([EMAIL PROTECTED] is shape(3)) { ... }
bar(@xyz); # ok
bar( [$x, $y, $z] ); # ok
bar($x, $y, $z); # ok
bar <== $x, $y, $z; # still ok
am I right?
cheers,
Aldo

Re: Adding linear interpolation to an array

[Aldo Calpini]

Dave Whipp wrote:
Does defining the invocant as "Num @self is constant" constrain the application 
> of the role to read-only uses of indices?
I don't think you need "is constant". arguments are readonly by default, 
unless you give them the "is rw" trait. I guess that "is constant" means 
that you can specify the index only using a literal, not a variable, eg:

@test[1]; # ok, 1 is a costant
my $idx = 1;
@test[$idx]; # nok, $idx is not a constant
but I may be wrong.
Does the explicit indexing by an "int" typed value ensure that 
it'll be non-recursive under MMD?
you mean "Num" typed value? if so, I guess using an explicitly 
non-integer index would make it win under MMD. on the other hand, your 
method could even not be called at all with an integer index.

If I later decare a sub as
  sub foo ( @in does LinearInterpolation ) { ... }
Would I be able to pass a normal (non-interpolating) array to this sub, 
and then access it using non-integer indices (i.e. is the data in the 
array independent of the interface through wich it is accessed).
I don't think so. I'm afraid you have to do something like:
sub foo (@in) {
my @_in = @in;
if(! @in.does(LinearInterpolation) ) {
@_in does LinearInterpolation;
}
# go ahead using @_in
...
}
cheers,
Aldo

Re: Adding linear interpolation to an array

[Dave Whipp]

Aldo Calpini wrote:
I don't think you need "is constant". arguments are readonly by default, 
unless you give them the "is rw" trait. I guess that "is constant" means 
that you can specify the index only using a literal, not a variable, eg:

@test[1]; # ok, 1 is a costant
my $idx = 1;
@test[$idx]; # nok, $idx is not a constant
What I was trying to do is to prevent using fractional indices in lvalue 
context. I.e. my role wouldn't be considered for "@x[0.5] = 2".

but I may be wrong.
Does the explicit indexing by an "int" typed value ensure that it'll 
be non-recursive under MMD?

you mean "Num" typed value? if so, I guess using an explicitly 
non-integer index would make it win under MMD. on the other hand, your 
method could even not be called at all with an integer index.
That's what I'm hoping. Because my code does integer indexing, and I 
wouldn't want it to call itself. I guess could be explicit:

  $value = @self.Array::postcircumfix«[]»($index);
If I later decare a sub as
  sub foo ( @in does LinearInterpolation ) { ... }
Would I be able to pass a normal (non-interpolating) array to this 
sub, and then access it using non-integer indices (i.e. is the data in 
the array independent of the interface through wich it is accessed).

I don't think so. I'm afraid you have to do something like:
sub foo (@in) {
my @_in = @in;
if(! @in.does(LinearInterpolation) ) {
@_in does LinearInterpolation;
}
# go ahead using @_in
...
}
I don't see why I need the conditional there. If I'm going to copy the 
array, I might as well declare up front the that darget does 
LinearInterpolation:

sub foo (Num @raw_in)
{
   my Num @in does LinearInterpolation = @raw_in;
   ...
}
Or perhaps even
sub foo (Num @in is copy does LinearInterpolation)
{
   ...
}
Dave.

Re: Optional binding

[David Storrs]

On Mon, Mar 07, 2005 at 05:36:08PM +0100, Aldo Calpini wrote:
> David Storrs wrote:
> >Urk. I, for one, will definitely find this surprising.  I would have
> >expected:
> >
> >  x = ; $y = 1; z = 2 3
> 
> to obtain what you have expected, you need to explicitly treat the array 
> as a list of values with the unary splat:
> 
> foo($x, [EMAIL PROTECTED]);
>
> >But I suppose it's all a question of learning to love the Brave New
> >World in which arrays are actually objects (sort of).
> 
> more to the point, arrays are automagically referenced in scalar context:
> 
> @a = @b;  # same as perl5
> $a = @b;  # means $a = [EMAIL PROTECTED] in perl5
> $a = [EMAIL PROTECTED]; # means $a = @b in perl5 (more or less)


Yes, I know.  That's what I meant by "...arrays are objects...(sort
of)."  They are objects in the sense that they are sort of references
and sort of not and that they have behavior built into them
(e.g. C<.length>). They won't actually have a class (I don't
think...type Array is not the same as a hypothetical class Array,
right?), but otherwise they quack awfully much like an object.


> another thing that may surprise you (it still surprises me, somehow):
> 
> sub bar($x, $y, $z) { ... }
>   # ^ note x is scalar here!
> 
> my @coords = (1.0, 3.0, 5.0);
> bar(@coords); # wrong
>   # x => [EMAIL PROTECTED], y => undef, z => undef
> 
> bar([EMAIL PROTECTED]); # ok


Yep, I am pretty sure that's going to trip me up endlessly for the
first 6 months or so.  


To be perfectly honest, there are steadily more things I don't like
about the way Perl 6 is going, especially when it comes to signatures.
They are excessively verbose, they lead to (what I think is, and what
I suspect most Perl 5 programmers will think is) weird behavior like
that described above, and the type system feels like a straitjacket.
I know all these features are optional, but they WILL be used, which
means I have to know them so that I can maintain other people's code.
Essentially, it feels like we're turning our beautiful language into
something that has all the fun of Java but without Sun's marketing
budget.

 
But, every time I find myself thinking these things I take a deep
breath, put my faith in Larry, and assume that it will work out--I
really do have an amazing degree of faith in his ability to pull off
miracles.  Hopefully, after I have a chance to play with the
production version of P6 for a while, all of these things that
currently seem like effluent will start to see like useful tools.

Fingers crossed,

--Dks

-- 
[EMAIL PROTECTED]

Re: Optional binding

[Larry Wall]

On Mon, Mar 07, 2005 at 10:29:58PM +0100, Aldo Calpini wrote:
: Larry Wall wrote:
: >Or, assuming you might want to generalize to N dimensions someday, just
: >
: >sub bar ([EMAIL PROTECTED]) {...}
: >
: >and deal with it as in Perl 5 as a variadic list.  I suppose one could say
: >
: >sub bar ([EMAIL PROTECTED] is shape(3)) {...}
: >
: >and get checking on the argument count.
: 
: if I understand correctly, without using multi subs:
: 
: sub bar(@coords is shape(3)) { ... }
: 
: bar(@xyz); # ok
: bar( [$x, $y, $z] ); # ok
: bar($x, $y, $z); # compile-time error

Yes.

: while:
: 
: sub bar([EMAIL PROTECTED] is shape(3)) { ... }
: 
: bar(@xyz); # ok
: bar( [$x, $y, $z] ); # ok
: bar($x, $y, $z); # ok
: bar <== $x, $y, $z; # still ok
: 
: am I right?

The second one might fail, I think.  The declaration says that @coords
as a whole has shape(3), not each individual element.  On the other
hand, if you interpret the shape size as a maximum and not an exact match,
then you could end up with a value of [[$x,$y$z],undef,undef], though
of course, that would fail if you had declared it to be an array of int.

In fact, we really haven't specified what happens when you say

my Int @a is shape(3) := [1,2];
my Int @b is shape(3) := [1,2,3,4];

A strict interpretation requires both to be errors, but I can warp my
brain around to thinking either or both is okay.  The first is kinda
okay because @a[2] can represent undef, and the array as a whole
successfully holds the whole value.  The second is kinda okay
because the @b presents a view into a portion of the bound value,
and there aren't any parts of it that map onto nothingness.

But I also have this nagging feeling that the user wouldn't have
specified shape(3) unless they actually meant it.  The question is
what they meant.  It could be argued that shape(3) is just a storage
directive saying that we'll emulate the more general array semantics
with 3 elements.  But I suspect that in the typical case, they really
do want a 3-element vector, nothing more, nothing less.

Our notation doesn't differentiate those intents, however.  Let's
assume the strict intent, and if a different strategy is intended with
looser binding semantics, we can always use a different trait name.
I think a strict interpretation of shape gives a lot more information
to the optimizer.

Larry

Re: Optional binding

[Larry Wall]

On Mon, Mar 07, 2005 at 02:20:47PM -0800, David Storrs wrote:
: Yes, I know.  That's what I meant by "...arrays are objects...(sort
: of)."  They are objects in the sense that they are sort of references
: and sort of not and that they have behavior built into them
: (e.g. C<.length>). They won't actually have a class (I don't
: think...type Array is not the same as a hypothetical class Array,
: right?), but otherwise they quack awfully much like an object.

No, they're real objects.  (Though it's .elems rather than .length, since
we've banished the "l" word from our vocabulary.)

: > another thing that may surprise you (it still surprises me, somehow):
: > 
: > sub bar($x, $y, $z) { ... }
: >   # ^ note x is scalar here!
: > 
: > my @coords = (1.0, 3.0, 5.0);
: > bar(@coords); # wrong
: >   # x => [EMAIL PROTECTED], y => undef, z => undef
: > 
: > bar([EMAIL PROTECTED]); # ok
: 
: 
: Yep, I am pretty sure that's going to trip me up endlessly for the
: first 6 months or so.  
: 
: 
: To be perfectly honest, there are steadily more things I don't like
: about the way Perl 6 is going, especially when it comes to signatures.
: They are excessively verbose, they lead to (what I think is, and what
: I suspect most Perl 5 programmers will think is) weird behavior like
: that described above, and the type system feels like a straitjacket.
: I know all these features are optional, but they WILL be used, which
: means I have to know them so that I can maintain other people's code.
: Essentially, it feels like we're turning our beautiful language into
: something that has all the fun of Java but without Sun's marketing
: budget.
: 
:  
: But, every time I find myself thinking these things I take a deep
: breath, put my faith in Larry, and assume that it will work out--I
: really do have an amazing degree of faith in his ability to pull off
: miracles.  Hopefully, after I have a chance to play with the
: production version of P6 for a while, all of these things that
: currently seem like effluent will start to see like useful tools.

And I have put my faith in the Perl community, and assume it will work
out, because I have an amazing degree of faith in the ability of the
community to recognize the real effluent and avoid it.  :-)

: Fingers crossed,

Niy ygsy ,sjra uy s ;py gsefre yp ytor///

:seet

Re: Optional binding

[David Storrs]

On Mon, Mar 07, 2005 at 04:58:29PM -0800, Larry Wall wrote:
> 
> In fact, we really haven't specified what happens when you say
> 
> my Int @a is shape(3) := [1,2];
> my Int @b is shape(3) := [1,2,3,4];
> 
[...]
> But I also have this nagging feeling that the user wouldn't have
> specified shape(3) unless they actually meant it.  But I suspect
> that in the typical case, they really do want a 3-element vector,
> nothing more, nothing less.

I agree that this is undoubtedly what they meant.  I wonder though, if
there is then any way to explicitly leave off an element.  Can I do
this:

sub foo( Int @a is shape(3) ) { ... }
foo(1, 2, undef);


--Dks

-- 
[EMAIL PROTECTED]

Re: Optional binding

[David Storrs]

On Mon, Mar 07, 2005 at 05:15:14PM -0800, Larry Wall wrote:
> On Mon, Mar 07, 2005 at 02:20:47PM -0800, David Storrs wrote:
> : Yes, I know.  That's what I meant by "...arrays are objects...(sort
> 
> No, they're real objects.  (Though it's .elems rather than .length, since
> we've banished the "l" word from our vocabulary.)

Ah, ok.  I've got to scrape up the tuits to go back and reread the
A&Es.  

Actually, I guess they would have to be...can you apply a role to a
bare type?

 my int does SelectOutputFile;  # I would expect this to fail 
 my Int does SelectOutputFile;  # I would expect this to work


> : But, every time I find myself thinking these things I take a deep
> : breath, put my faith in Larry, and assume that it will work out--I
> : really do have an amazing degree of faith in his ability to pull off
> : miracles.  Hopefully, after I have a chance to play with the
> : production version of P6 for a while, all of these things that
> : currently seem like effluent will start to see like useful tools.
> 
> And I have put my faith in the Perl community, and assume it will work
> out, because I have an amazing degree of faith in the ability of the
> community to recognize the real effluent and avoid it.  :-)

I think I've just been very, very gently poked. :>

For the record--just because I personally dislike these things doesn't
make them bad, or even bad for the language.  I didn't even say that
they WERE effluent, just that right now they seem that way to me
personally...and I'm trying to get past it.  As I said, I'm confident
it will all work out well in the end.

> 
> : Fingers crossed,
>
>Niy ygsy ,sjra uy s ;py gsefre yp ytor///
>
>:seet

At first I thought I had annoyed you enough that you were attempting
to summon an Elder God through my terminal.  Then I realized that it
works out to:

  But that makes it a lot harder to type...
  Larry

Owie...stop making my head hurt! :>

--Dks

-- 
[EMAIL PROTECTED]

Re: Optional binding

[Larry Wall]

On Mon, Mar 07, 2005 at 05:56:12PM -0800, David Storrs wrote:
: On Mon, Mar 07, 2005 at 05:15:14PM -0800, Larry Wall wrote:
: > On Mon, Mar 07, 2005 at 02:20:47PM -0800, David Storrs wrote:
: > : Yes, I know.  That's what I meant by "...arrays are objects...(sort
: > 
: > No, they're real objects.  (Though it's .elems rather than .length, since
: > we've banished the "l" word from our vocabulary.)
: 
: Ah, ok.  I've got to scrape up the tuits to go back and reread the
: A&Es.  

Bear in mind the As have [Update] sections but the Exegeses do not.
The Ss should be relatively up-to-date though.

: Actually, I guess they would have to be...can you apply a role to a
: bare type?
: 
:  my int does SelectOutputFile;  # I would expect this to fail 
:  my Int does SelectOutputFile;  # I would expect this to work

The latter always works.  The former can probably be made to work in
the case of roles that only add methods and don't change the storage
representation, since the vtable is associated with the class and
not the object.

:seet, er, I mean, Larry

Perl 6 Summary for 2005-02-22 though 2005-03-07

[Matt Fowles]

Perl 6 Summary for 2005-02-22 though 2005-03-07
All~

Welcome to yet another fortnight summary. Once again brought to you by
chocolate chips. This does have the distinction of being the first
summary written on a mac. So if I break into random swear words, just
bear with me.

  Off list development
In more related news, It has been pointed out to me that development
goes on off list on places like IRC. I briefly contemplated, quitting my
job and tracking such things full time, but then I decided that it would
be better if I just accepted brief submissions for the summary. Thus I
will be adding a fourth section to the summaries based on contributions.
If you would like to make a contribution, email me with a brief summary.
Please include the name by which you would like to be attributed (sadly
the process I use is likely to mangle any unicode characters). Please
make all links full, I will shorten them. Thanks

  Perl 6 Language
   not()
It turns out that "not()" (with no arguments) made perl 5 core dump for
a while, and it took us five years to figure that out. In perl 6 it will
be a list op and calling it with no arguments will return a null list or
an undef depending on context.



   junctions and threading
I had hoped that last week the concerns about threading would have been
addressed. I was mistaken. A new crop of concerns surfaced and died down
fairly quickly (as the chief proponent, Damien, was away).



   serializing to various languages
Somehow the discussion of junctions morphed into a discussion of sets,
which morphed back into junctions, which morphed into a discussion of
serialization to different languages. Interesting stuff, but I wouldn't
hold me breath for it...



   Performance Analysis and Benchmarks
Adam Preble posted an offer to develop some benchmarks for perl 6.
Unfortunately, I think he posted it to google groups. Also, he probably
should have posted it to p6c or p6i as the language folk tend to wave
their hands and say "magic occurs but correctness is preserved" when it
comes to optimization.



   send + more = junctions
Autrijus posted an example using junctions, instead of parents, to solve
the classic

SEND MORE + = MONEY

problem. Markus Laire asked for a clarification, and Rod Adams pointed
out that he felt that it would not work as the interdependence of the
"e"s was not captured. This does lead to the question of how one should
right prolog like code (including unification and backtracking) in Perl
6. No answers were offered.



   Pairs as lvalues
Ingo Blechschmidt wondered what the behavior of pairs as lvalues would
be. The answer is that you would get an error for attempting to modify a
constant.



   Perl 6
Roberto Bisotto wanted to know where he could download perl 6 to start
playing with it. We embarrassedly told him that a full implementation
was not yet available, but pugs was gaining ground quickly.



   hash keys
Autrijus wanted to know if hash keys were still just strings or if they
could be more. The answer is that by default they would be strings, but
they could be declared as having a different " shape ". This led to a
discussion of hashing techniques such as the .bits, .canonicalize, or
.hash methods.



   Dynamically scoped dynamic scopes
Dave Whipp wanted to make "dynamically scoped dynamic scopes". My head
hurt, but apparently Larry's didn't as he replied "piece of cake, the
syntax [and implementation] are left as an exercise to for the would be
module author".



   Parameters to rules
Rod Adams asked how he could specify arguments to rules so they could be
more function like. Larry explained that there were several syntaxes
each of which would coerce its arguments in slightly different ways. He
then mused that perhaps there were too many, I agree there are too many.



   compile time signature checking
Ahbijit Mahabal wondered how type checking would work for cases where it
was not easy to determine the types at compile time. The answer:
checking will be defered to runtime. In the end it seems that Perl 6
will blur the line between runtime and compile time heavily. Perhaps it
will provide nifty support for staged programming, meta-perl6 here we
come...



   %*CONFIG and %?CONFIG
Brian Ingerson asked about the CONFIG hash and what sort of secondary
sigil it would have. Larry explained that $?CONFIG held to config for
the machine compiling the program and $*CONFIG held the config for the
machine running the program. Then 

Re: Optional binding

[Larry Wall]

On Mon, Mar 07, 2005 at 05:37:53PM -0800, David Storrs wrote:
: On Mon, Mar 07, 2005 at 04:58:29PM -0800, Larry Wall wrote:
: > 
: > In fact, we really haven't specified what happens when you say
: > 
: > my Int @a is shape(3) := [1,2];
: > my Int @b is shape(3) := [1,2,3,4];
: > 
: [...]
: > But I also have this nagging feeling that the user wouldn't have
: > specified shape(3) unless they actually meant it.  But I suspect
: > that in the typical case, they really do want a 3-element vector,
: > nothing more, nothing less.
: 
: I agree that this is undoubtedly what they meant.  I wonder though, if
: there is then any way to explicitly leave off an element.  Can I do
: this:
: 
:   sub foo( Int @a is shape(3) ) { ... }
:   foo(1, 2, undef);

That's illegal unless you either * the @a or [] the list.  By itself an
@a declaration is always looking to bind a single parameter.  Arguably,
1,2,undef could be interpreted as a single parameter, forcing the
scalar comma to auto-enreference a [1,2,undef] as it does when you say

$foo = (1,2,undef);

but then we lose argument count checking on any sig ending in an
array, and the meaning of comma subtly changes without warning at
a place other than the expected scalar/variadic boundary.  So we
require splats to make that clear.  I'd also note that

foo((1,2,undef))

would work in this case because parens in scalar context make all the args
into one arg.  (In list context they would flatten, as they do in Perl 5.)
However, it's a lot clearer to say

foo([1,2,undef])

if that's what you mean.

Larry

Re: Optional binding

[David Storrs]

On Mon, Mar 07, 2005 at 07:50:47PM -0800, Larry Wall wrote:
> On Mon, Mar 07, 2005 at 05:37:53PM -0800, David Storrs wrote:
> : On Mon, Mar 07, 2005 at 04:58:29PM -0800, Larry Wall wrote:
> : Is
> : there is then any way to explicitly leave off an element.  Can I do
> : this:
> : 
> : sub foo( Int @a is shape(3) ) { ... }
> : foo(1, 2, undef);
> 
> That's illegal unless you either * the @a or [] the list.  

Argh.  My bad, I meant to * the @a.  Ok, rewrite; is THIS legal?:

sub foo( Int [EMAIL PROTECTED] is shape(3) ) { ... }
foo(1, 2, undef);

The sense I'm trying to convey is:

"Here is my sub.  It takes three ints."

"Here is me calling the sub.  I am giving you only two ints and
explicitly telling you [by explicitly passing undef] that I meant
to do that so just take it and be quiet."

To put it another way...in perl5, a sub that was prototyped to take 
three scalar args will throw an error when you pass only two but will
accept it if you pass two plus an explicit undef.  On the other hand,
if it was prototyped to take an array there is no way to tell the
difference between an explicitly-passed undef and a too-short arg
list.  How will P6 handle these two scenarios?

--Dks

finding the name of &$SUB ?

[David Storrs]

Is there a way to find the name of  &?SUB  ?  It would be useful for
error-logging and -reporting.

--Dks

Re: finding the name of &$SUB ?

[Larry Wall]

On Mon, Mar 07, 2005 at 09:49:04PM -0800, David Storrs wrote:
: Is there a way to find the name of  &?SUB  ?  It would be useful for
: error-logging and -reporting.

$?SUBNAME, I think, unless &?SUB just stringifies to that.  I guess
it's a good question whether &foo should stringify to "foo" or
"&foo" or something else including the signature.  In which case,
&?SUB might stringify to a lot of info, and $?SUBNAME would more
reliably be just the short name.  Maybe we also need a way to get
the long name explicitly.

Larry

Re: finding the name of &$SUB ?

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW> On Mon, Mar 07, 2005 at 09:49:04PM -0800, David Storrs wrote:
  LW> : Is there a way to find the name of  &?SUB  ?  It would be useful for
  LW> : error-logging and -reporting.

  LW> $?SUBNAME, I think, unless &?SUB just stringifies to that.  I guess
  LW> it's a good question whether &foo should stringify to "foo" or
  LW> "&foo" or something else including the signature.  In which case,
  LW> &?SUB might stringify to a lot of info, and $?SUBNAME would more
  LW> reliably be just the short name.  Maybe we also need a way to get
  LW> the long name explicitly.

why not leave it as $?SUB but it is an object and you use the .name
method? this way you won't clutter the namespace and you can add more
methods like .signature, .returns, etc.

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: finding the name of &$SUB ?

[Larry Wall]

On Tue, Mar 08, 2005 at 01:55:07AM -0500, Uri Guttman wrote:
: why not leave it as $?SUB but it is an object and you use the .name
: method?

Uh, yeah.  Obviously, 11 pm is still to early in the day for me...

: this way you won't clutter the namespace and you can add more
: methods like .signature, .returns, etc.

In which case $?SUB and &?SUB are probably just different names for
the same object, or we just go with &?SUB, and assume people will be
able to figure out from the lack of parens that &?SUB.name is not
calling the subroutine.  Or I suppose we could go with straight $?SUB.
Or both.  Or one.  Or the other.  Or both.  Or...

Larry

Re: Optional binding

[Larry Wall]

On Mon, Mar 07, 2005 at 08:58:44PM -0800, David Storrs wrote:
: Ok, rewrite; is THIS legal?:
: 
:   sub foo( Int [EMAIL PROTECTED] is shape(3) ) { ... }
:   foo(1, 2, undef);

Yes, since Int can represent undef.

: The sense I'm trying to convey is:
: 
: "Here is my sub.  It takes three ints."
: 
: "Here is me calling the sub.  I am giving you only two ints and
: explicitly telling you [by explicitly passing undef] that I meant
: to do that so just take it and be quiet."
: 
: To put it another way...in perl5, a sub that was prototyped to take 
: three scalar args will throw an error when you pass only two but will
: accept it if you pass two plus an explicit undef.  On the other hand,
: if it was prototyped to take an array there is no way to tell the
: difference between an explicitly-passed undef and a too-short arg
: list.  How will P6 handle these two scenarios?

Could use "exists", maybe.  Though for an array with shape(3)
it's possible that exists(@a[2]) is always true regardless of the
bound value.  On the other hand, binding an array that is too short
is going to be a type mismatch, so you probably can't get into the
situation of a shaped array being too short to begin with.  It'll
either fail immediately in the case of a normal sub, or it'll
go off looking for something else to MMD to that doesn't violate
any type constraints, and fail if it doesn't fine one.

Larry

Re: finding the name of &$SUB ?

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW> On Tue, Mar 08, 2005 at 01:55:07AM -0500, Uri Guttman wrote:
  LW> : why not leave it as $?SUB but it is an object and you use the .name
  LW> : method?

  LW> Uh, yeah.  Obviously, 11 pm is still to early in the day for me...
   ^^

or too late? :)

(i wouldn't normally spellcheck you but you are usually very accurate
and this must mean something)

and 2am is bedtime for me now.

  LW> : this way you won't clutter the namespace and you can add more
  LW> : methods like .signature, .returns, etc.

  LW> In which case $?SUB and &?SUB are probably just different names for
  LW> the same object, or we just go with &?SUB, and assume people will be
  LW> able to figure out from the lack of parens that &?SUB.name is not
  LW> calling the subroutine.  Or I suppose we could go with straight $?SUB.
  LW> Or both.  Or one.  Or the other.  Or both.  Or...

burble! i know how you feel. now slowly back away from the keyboard and
say nighty night to us all. we need a refreshed larry and not one who
pulls all nighters like some college kid (or damian :).

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org