Re: Sane (less insane) pair semantics

[Stuart Cook]

On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> So to pass a hash that has one element requires using the hash
> keyword?

I don't see a hash in your example, so I'm not sure what you're
referring to here.

> Specifically, if I say:
>
>   @args = (a => 1, get_overrides());
>
> Then can I say
>
>   foo([EMAIL PROTECTED]);

Not if you want that a=>1 to be a named argument.

Under the proposal, the only ways to pass a named argument are:
1) By using a literal pair in the syntactic top-level of the arg list
2) By splatting a pair, hash, or arg-list-object

> Or will I, in the case of no overrides, get a positional pair instead of
> named a =>1 ?

The overrides have nothing to do with it.  That a=>1 will *always* be
a positional, because by the time it reaches the argument list, it's a
value (not a syntactic form).  The only way to use a pair-value as a
named argument is to splat it directly, or splat a hash or
arg-list-object containing it.  Splatting an array *never* introduces
named arguments, only positionals.


Stuart

Re: Sane (less insane) pair semantics

[Juerd]

Stuart Cook skribis 2005-10-10 22:58 (+1100):
> >   @args = (a => 1, get_overrides());
> >   foo([EMAIL PROTECTED]);
> Not if you want that a=>1 to be a named argument.
> Under the proposal, the only ways to pass a named argument are:
> 1) By using a literal pair in the syntactic top-level of the arg list
> 2) By splatting a pair, hash, or arg-list-object

I find this counterintuitive, and also want arrays to be included in
option 2.

It is consistent with the idea that * expands its RHS and evaluate it as
if it was written literally.

I'd like @_ or @?ARGS or something like that to be a *-able array that
will be guaranteed to be compatible with the current sub's signature.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Juerd]

Miroslav Silovic skribis 2005-10-10 15:04 (+0200):
> >>Under the proposal, the only ways to pass a named argument are:
> >>1) By using a literal pair in the syntactic top-level of the arg list
> >>2) By splatting a pair, hash, or arg-list-object
> >I find this counterintuitive, and also want arrays to be included in
> How would you splat an array of pairs if you want to preserve the pairs?

By adding parens, because by this proposal (if I read it correctly),
only pairs on the topmost level of arguments (not in any parens) are
parsed as named arguments.

foo(([EMAIL PROTECTED]));
foo ([EMAIL PROTECTED]);

This doesn't allow for combining named and positional pairs. I do not
think that is necessary at all, for arrays. I think that combining
the two on the same level is a recipe for disaster anyway, and should
perhaps even emit a warning.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Juerd]

Juerd skribis 2005-10-10 15:20 (+0200):
> only pairs on the topmost level of arguments (not in any parens) are

s/not in any parens/not in any grouping parens/, to exclude .()


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Miroslav Silovic]

[EMAIL PROTECTED] wrote:


Stuart Cook skribis 2005-10-10 22:58 (+1100):
 


 @args = (a => 1, get_overrides());
 foo([EMAIL PROTECTED]);
 


Not if you want that a=>1 to be a named argument.
Under the proposal, the only ways to pass a named argument are:
1) By using a literal pair in the syntactic top-level of the arg list
2) By splatting a pair, hash, or arg-list-object
   



I find this counterintuitive, and also want arrays to be included in
option 2.
 


How would you splat an array of pairs if you want to preserve the pairs?


It is consistent with the idea that * expands its RHS and evaluate it as
if it was written literally.

I'd like @_ or @?ARGS or something like that to be a *-able array that
will be guaranteed to be compatible with the current sub's signature.

 

This sounds nice, though. Maybe it suggests that the 'named splat' 
should be something other than *?


   Miro

Re: Sane (less insane) pair semantics

[Larry Wall]

Interestingly, I had already written almost exactly the same thing
into my version of S06, but I've been holding off on checking it in
while I mull over Luke's theory theory.  Regardless of the actual
syntax we end up with, I think everyone can assume that the compiler
will be able to determine at compile time which pairs are intended
to be named arguments and which ones positional parameters, and pass
them as separate entities through whatever structure supplies all the
arguments to a call so that the caller doesn't have to worry about
making the distinction based on type.

It still has to figure out how to reconcile the named arguments
with the positional parameters, of course, unless someone has
made sufficient representation to the compiler that all calls to
a particular short name have particular named parameters that are
guaranteed to be in the same position everywhere, in which case the
compiler is allowed to simply translate them to positionals on the
call end.

Perhaps it would be useful to allow a stubbed multi to declare the
required names of positional parameters in some scope or other.  This
might be generalized to a translation service for calls outside the
scope, where the current scope could even be the current language
as a whole.  That might alleviate cultural differences if one language
always uses $left and $right where another uses x and y, for instance.

Of course, I haven't eaten breakfast yet, so maybe that's impossible.

Larry

Re: Sane (less insane) pair semantics

[Austin Hastings]

Stuart Cook wrote:

>On 10/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
>  
>
>The overrides have nothing to do with it.  That a=>1 will *always* be a 
>positional, because by the time it reaches the argument list, it's a value 
>(not a syntactic form).  The only way to use a pair-value as a named argument 
>is to splat it directly, or splat a hash or arg-list-object containing it.  
>Splatting an array *never* introduces named arguments, only positionals.
>  
>

That seems like a huge error. Arrays are the only thing (that I know of)
that can store the positional part of an arglist as well as storing the
pairs. If there's not some mechanism for getting the entire arglist, and
if there's not some simple inversion of that simple mechanism for
passing the args along to some other victim, then ... well ... I don't
know. But it's bad!

So since you keep saying "arg-list-object" as though it was something
not an array, I'll bite:

What's an arg-list-object, and how is it different from an array?


=Austin

Re: Type annotations

[TSa]

HaloO,

I fear I'm addicted...

Luke Palmer wrote:

On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:


On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote:



No, you can't overload assignment at runtime because you can't
overload assigment at any time, so says the language spec (well, not
any formal spec; so says Larry as far as I remember).


Again, I don't care *how* I accomplish it, as long as I don't have to
root around in the source code of Perl 6 itself to make it work.



That's easy.  Define coerce: (Int --> Array) {...}.  Don't define
it after CHECK is run.


But that makes MMD at most a second class concept.
Worse is that this hinders the concrete formulation
of abstract concepts into which designers can hook their
stuff. Assignment to me is a non-commutative, or if you
like that better, asymmetric binary operator. The asymmetry
beeing that the LHS takes the burden to keep the connection
to the value of the RHS at that time.

I call the thing that Larry wants to preserve a slot call.
That is

  $x = $y;

actually means

  $x.STORE( $y.FETCH );

where I would write the .STORE and .FETCH methods with
adverbial pair syntax :STORE and :FETCH because they
are looked up from the things that $x and $y contain or
refer to at runtime while the dot forms are dispatched
on the type. In other words the generated code is different
in both cases. But usually the net result is the same because
the .STORE method has the same targets for the usual types
of $x as the vtbls that different types of $x carry around.

BUT you can break that symmetry *either* by changing the entries
in the method *or* some vtbls! And if you want to base your
decision which route to take on *both* the participants you
write a *multi* method for infix:{'='}.

And only if none of the above is satisfactory messing with the
parser/grammar should be considered. I have the impression that
Perl 6 pulls out this rather heavy-weight tool too early in many
cases.
--
$TSa.greeting := "HaloO"; # mind the echo!

Re: Sane (less insane) pair semantics

[Austin Hastings]

Miroslav Silovic wrote:

> [EMAIL PROTECTED] wrote:
>
>> * expands its RHS and evaluate it as if it was written literally.
>>
>> I'd like @_ or @?ARGS or something like that to be a *-able array that
>> will be guaranteed to be compatible with the current sub's signature.
>>
> This sounds nice, though. Maybe it suggests that the 'named splat'
> should be something other than *?


How about "perl should DWIM"? In this case, I'm with Juerd: splat should
pretend that my array is a series of args.

So if I say:

foo [EMAIL PROTECTED];

or if I say:

foo([EMAIL PROTECTED]);

I still mean the same thing: shuck the array and get those args out
here, even the pairs.

It's worth pointing out that perl does know the list of declared named
args, though that may not be enough. If the pair.key matches an expected
arg, then splat should collapse it for sure. If it doesn't match...I dunno.

Is there a list() operator for converting hashes into lists of pairs?
That might make parsing foo([EMAIL PROTECTED], *%_) more palatable, but I'd 
still
prefer to get pairs in @_ if I don't explicitly ask for *%_...

=Austin

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Austin Hastings wrote:
> How about "perl should DWIM"? In this case, I'm with Juerd: splat
> should pretend that my array is a series of args.

Yep.

> So if I say:
> 
> foo [EMAIL PROTECTED];
> 
> or if I say:
> 
> foo([EMAIL PROTECTED]);
> 
> I still mean the same thing: shuck the array and get those args out
> here, even the pairs.

Right, you name it: you get *pairs* out of the array, not named
parameters. Under the proposal, a Pair object doesn't have any special
magic -- it's simply

class Pair { has $.key; has $.value is rw }

Thus:

my @array = (42, "hi", (a => 23));
foo [EMAIL PROTECTED];  # same as

foo 42, "hi", (a => 23);  # three positional params (Int, Str, Pair)

> It's worth pointing out that perl does know the list of declared named
> args, though that may not be enough. If the pair.key matches an
> expected arg, then splat should collapse it for sure. If it doesn't
> match...I dunno.

But that's exactly the problem. You shouldn't have to worry about any
special magic when dealing with [EMAIL PROTECTED] Consider:

sub foo ($a, $b, $c, ?$d) {...}

my @array = (1, 2, (key => "value"));
foo [EMAIL PROTECTED];  # fine, no problem, $c will receive (key => "value")

my @array = (1, 2, (d => "value"));
foo [EMAIL PROTECTED];  # oops! $a = 1, $d = "value"
  # "Required argument 'c' not given!"

> Is there a list() operator for converting hashes into lists of pairs?

my @array_of_pairs = %hash;  # short for
my @array_of_pairs = list %hash;


--Ingo

Re: Sane (less insane) pair semantics

[Dave Whipp]

Austin Hastings wrote:


How about "perl should DWIM"? In this case, I'm with Juerd: splat should
pretend that my array is a series of args.

So if I say:

foo [EMAIL PROTECTED];

or if I say:

foo([EMAIL PROTECTED]);

I still mean the same thing: shuck the array and get those args out
here, even the pairs.


The trouble is, an array doesn't contain enough information:

Compare:
  foo( (a=>1), b=>2 );

With
  @args = ( (a=>1), b=>2 );
  foo( [EMAIL PROTECTED] );

If we have an arglist ctor, then we could have

  @args = arglist( (a=>1), b=>2 );
  foo( [EMAIL PROTECTED]);

  say @args.perl
## (
##   (a=>1) but is_positional,
##   (b=>2) but is_named,
## )


but without such a constructor, it would be difficult to DWIM correctly.

Of course, for the case of $?ARGS, constructing the array with 
appropriate properties wouldn't be a problem.

Re: Sane (less insane) pair semantics

[Mark Reed]

On 2005-10-10 13:36, "Ingo Blechschmidt" <[EMAIL PROTECTED]> wrote:
> Under the proposal, a Pair object doesn't have any special
> magic 

Right.  So under this proposal, the "key => value" syntax is overloaded: in
some contexts it creates a Pair object, and in others it assigns a value to
a named parameter, and parentheses are the disambiguating mechanism to get
the former behavior in the latter context.  Meanwhile, a reference to a Pair
object occurring in an argument list does not interact with the
named-parameter mechanism at all.

At least, not by default.  It would be desirable to have a way to flatten a
hash/list of Pairs/whatever in such a way that it *does* map key names to
named parameters.

Re: Sane (less insane) pair semantics

[Juerd]

Ingo Blechschmidt skribis 2005-10-10 19:36 (+0200):
> my @array = (42, "hi", (a => 23));

It is worth pointing out that the inner parens here are merely for
grouping: this information is lost afterwards, hence this:

> foo [EMAIL PROTECTED];  # same as

shouldn't be

> foo 42, "hi", (a => 23);  # three positional params (Int, Str, Pair)

but instead

foo 42, "hi", a => 23  # two positional args, one named.

OR pairs need to remember whether they were originally in parens. This
is very doable, but whether we want or need it is very arguable.

(Very little sidenote: parameters are expected, arguments are passed. In
the signature, you have parameters, in the call, you have arguments.
However, in the case of a named argument, it does make some sense to
call the name parameter and the value argument, resulting in having both
in the call.)


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Mark Reed wrote:
> On 2005-10-10 13:36, "Ingo Blechschmidt" <[EMAIL PROTECTED]> wrote:
>> Under the proposal, a Pair object doesn't have any special
>> magic
> 
> Right.  So under this proposal, the "key => value" syntax is
> overloaded: in some contexts it creates a Pair object, and in others
> it assigns a value to a named parameter, and parentheses are the
> disambiguating mechanism to get
> the former behavior in the latter context.  Meanwhile, a reference to
> a Pair object occurring in an argument list does not interact with the
> named-parameter mechanism at all.

Exactly.

> At least, not by default.  It would be desirable to have a way to
> flatten a hash/list of Pairs/whatever in such a way that it *does* map
> key names to named parameters.

Yep:

foo *%hash;  # keys of %hash taken as named parameters
foo *hash(@array_of_pairs);
 # @array_of_pairs's pairs taken as named parameters


--Ingo

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Dave Whipp wrote:
> Austin Hastings wrote:
>> How about "perl should DWIM"? In this case, I'm with Juerd: splat
>> should pretend that my array is a series of args.
>> 
>> So if I say:
>> 
>> foo [EMAIL PROTECTED];
>> 
>> or if I say:
>> 
>> foo([EMAIL PROTECTED]);
>> 
>> I still mean the same thing: shuck the array and get those args out
>> here, even the pairs.
> 
> The trouble is, an array doesn't contain enough information:
> 
> Compare:
>foo( (a=>1), b=>2 );
> 
> With
>@args = ( (a=>1), b=>2 );
>foo( [EMAIL PROTECTED] );

my @args = ( (a => 1), b => 2 );  # is sugar for
my @args = ( (a => 1), (b => 2) );
# We can't stuff named arguments into an array, only pairs.
# Named arguments are neither objects nor some other data type,
# they're purely syntactical.

> If we have an arglist ctor, then we could have
> 
>@args = arglist( (a=>1), b=>2 );
>foo( [EMAIL PROTECTED]);
> 
>say @args.perl
> ## (
> ##   (a=>1) but is_positional,
> ##   (b=>2) but is_named,
> ## )
> 
> 
> but without such a constructor, it would be difficult to DWIM
> correctly.

Yep, see Luke's tuple proposal [1]:

my $tuple = ( (a => 1), b => 2 );
foo *$tuple;  # same as
foo( (a => 1), b => 2 );  # one positional argument (a Pair) and
  # the named parameter "b"


--Ingo

[1] http://svn.openfoundry.org/pugs/docs/notes/theory.pod
/Tuples

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 19:36 (+0200):
>> my @array = (42, "hi", (a => 23));
> 
> It is worth pointing out that the inner parens here are merely for
> grouping: this information is lost afterwards, hence this:
> 
>> foo [EMAIL PROTECTED];  # same as
> 
> shouldn't be
> 
>> foo 42, "hi", (a => 23);  # three positional params (Int, Str,
>> Pair)
> 
> but instead
> 
> foo 42, "hi", a => 23  # two positional args, one named.
> 
> OR pairs need to remember whether they were originally in parens. This
> is very doable, but whether we want or need it is very arguable.

Luckily, this is not needed, see my response to Dave [1]:

Because named arguments are purely syntactic (i.e., they are not objects
or some other kind of data type), you can't stuff them into an array
(or a scalar, for that matter).

# (assuming => binds thighter than =)
my $scalar = a => 1;  # sugar for
my $scalar = (a => 1);

my @array = (42, a => 1);  # sugar for
my @array = (42, (a => 1));

Named arguments can -- under the proposal -- only ever exist in calls.


--Ingo

[1] http://www.nntp.perl.org/group/perl.perl6.language/23438

Re: Sane (less insane) pair semantics

[Juerd]

Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
> Named arguments can -- under the proposal -- only ever exist in calls.

Which leaves us with no basic datastructure that can hold both
positional and named arguments. This is a problem because in a call,
they can be combined.

An array could hold both, but with only one small and minor
inconvenience: pairs are either all positional, or all named. I
sincerely believe that this is a feature, not a problem, because arrays
are singledimensional, and having pairs mean two different things on the
same level is, as this new proposal also indicates, confusing at best.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Juerd]

Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
> my @args = ( (a => 1), b => 2 );  # is sugar for
> my @args = ( (a => 1), (b => 2) );

Please, no. Please let the pair constructor be =>, not (=>). There is
really no need for this operator to consist of both infix and circumfix
parts. Please leave the parens for grouping (and in calls: breaking
recognition).


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
>> my @args = ( (a => 1), b => 2 );  # is sugar for
>> my @args = ( (a => 1), (b => 2) );
> 
> Please, no. Please let the pair constructor be =>, not (=>). There is
> really no need for this operator to consist of both infix and
> circumfix parts. Please leave the parens for grouping (and in calls:
> breaking recognition).

Err, of course! The parens around "b => 2" should make clear that "b =>
2" is not a named argument, but a pair. Outside of calls, the parens
are only for grouping:

my @args = (b => 2);# same as
my @args = ((b => 2));  # same as
my @args = b => 2;


--Ingo

Re: Sane (less insane) pair semantics

[Uri Guttman]

> "J" == Juerd  <[EMAIL PROTECTED]> writes:

  J> Ingo Blechschmidt skribis 2005-10-10 19:59 (+0200):
  >> my @args = ( (a => 1), b => 2 );  # is sugar for
  >> my @args = ( (a => 1), (b => 2) );

  J> Please, no. Please let the pair constructor be =>, not (=>). There is
  J> really no need for this operator to consist of both infix and circumfix
  J> parts. Please leave the parens for grouping (and in calls: breaking
  J> recognition).

he isn't saying that. the example shows the b => 2 is fine and will be
parsed as if it were ( b => 2 ). the point is how pairs in an array are
splatted or not to names args. and if i get it right, *hash( @args ) is
what is needed to convert an array of pairs to be used as named params.

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: Sane (less insane) pair semantics

[Ingo Blechschmidt]

Hi,

Juerd wrote:
> Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
>> Named arguments can -- under the proposal -- only ever exist in
>> calls.
> 
> Which leaves us with no basic datastructure that can hold both
> positional and named arguments. This is a problem because in a call,
> they can be combined.

Very true. This is why we need Luke's Tuple proposal [1]. Basically:

my $tuple = (a => 1, (b => 2)):{ ...block... };  # $tuple.isa(Tuple)
# Tuples are ordinary objects -- they can be stored
# in scalars, arrays, etc.

# But splatting tuples unfolds their magic:
foo(*$tuple);  # same as
foo(a => 1, (b => 2)):{ ...block...};
   # named arg "a", positional pair (b => 2),
   # adverbial block { ...block... }

# (Yep, under the current proposal, tuple construction conflicts
# with list/array construction. FWIW, I'd be fine with
# using Tuple.new(...) as the tuple constructor.)


--Ingo

[1] http://svn.openfoundry.org/pugs/docs/notes/theory.pod

Re: Roles and Trust

[Piers Cawley]

Ovid <[EMAIL PROTECTED]> writes:

> Apocalypse 12 has the following to say about roles and trust
> (http://www.perl.com/pub/a/2004/04/16/a12.html?page=10)
>
>   It's not clear whether roles should be allowed to grant
>   trust. In the absence of evidence to the contrary, I'm 
>   inclined to say not.
>
> In Perl 5, I recently found myself in the annoying position of having a
> method which could accept scalar, array, or hash references.  My
> primary code looked similar to this (simplified for clarity):
>
>   sub _attributes {
> my ($self, $attrs) = @_;
> return $$attrs if UNIVERSAL::isa( $attrs, 'SCALAR' );
>
> my @attributes = UNIVERSAL::isa( $attrs, 'HASH' ) 
>   ? %$attrs : @$attrs;
> return unless @attributes;
> # more code here
>   }
>
> This was a private method, but $attrs is an argument that is passed in
> by the person using my class.  It would be nice if I could just assign
> an "attributes" role to the SCALAR, ARRAY, and HASH classes and say
> that only my class could see the method(s) it provides.  Thus, my
> caller would be blissfully unaware that I am doing this:
>
>   $attrs->attributes; # even if it's an array reference

How about:

  my method SCALAR::attributes($self:) { $$self }
  my method HASH::attributes(%self:) { %self.kv }
  my method ARRAY::attributes(@self:) { [EMAIL PROTECTED] }

  method _attributes($attrs) {
my @attributes = $attrs.attributes
return @attributes[0] if @attributes == 1;
...
  }

Assuming it's legal.

-- 
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/

Class Methods, Eigenclasses and $?CLASS

[Stevan Little]

Evening all,

So I am in the process of adding class-methods into the meta-model  
using eigenclasses. Eigenclasses are a ruby thing (and also a CLOS  
thing IIRC), in which an anon-class is inserted between an instance  
and it's class, essentially replacing the instance's class. The anon- 
class then adds the original class to it's superclass list. This is  
best shown visually I think:


 ::Class
^
:  <-- eFoo is a subclass of Class
:
 ::eFoo   # eFoo is also an instance of Class
|
|  <-- eFoo is the class of Foo
V
  ::Foo

The dispatching of instance methods is still the same, and everything  
"just works". Well... almost everything.


There is a slight issue/inconsitency with how $?CLASS works.

class Foo {
method bar (Class $c:)  { $?CLASS }
method baz (Foo $self:) { $?CLASS }
}

Within the &bar class-method, the natural inclination is to think  
that $?CLASS will refer to ::Foo. However, in order to be consistent  
it actually refers to the eigenclass between ::Foo and ::Class, lets  
call it ::eFoo. This is because methods are associated with the class  
which contains them. In the &baz instance-method, $?CLASS does refer  
to ::Foo, since ::Foo is the class which contains &baz.


It seems to me that this inconsistency could be very problematic,  
especially since eigenclasses should really be an invisible  
implementation detail.


I am not 100% sure of what is the correct approach here, so I thought  
I would ask the group. Any thoughts guys/gals?


Thanks,

Stevan

This week's summary

[The Perl 6 Summarizer]

The Perl 6 Summary for the week ending 2005-10-09
Hello, and welcome to the first Perl 6 Summary to be published on my
website rather than its former home at 

This week in perl6-compiler
  PGE error on failing subrules
Allison broke the resounding silence of the last two weeks by posting
about some PGE errors she was seeing. No reply yet.



  Tests converted from pugs' rules.t to Parrot::Test::PGE
Yuval Kogman announced that he'd written a script to convert pugs's
rules tests into Parrot tests. The resulting test suite still needs some
attention, and he outlined what was needed. No response so far on the
list.



Meanwhile, in perl6-internals
  Variable registers
Klaas-Jan Stol wondered about how the new lexical scheme was going to
work. In particular, he wanted to know what was happening to
scratchpads. Leo gave a very brief overview of the new scheme, which
uses register frames for static lexicals and more conventional
scratchpads for dynamic lexicals. As I understand it, they'll look
pretty much the same from the PIR writer's point of view. Leo promised a
PDD from Chip in the nearish future which would thrash out the details.



  Exception handlers and calling conventions
Roger Browne wanted to know if exception handling had changed at the
same time as the calling conventions. He presented some code that
behaved differently depending on the Parrot version. Leo replied that
exceptions still wind up in P5 and Roger had found a bug. So Leo fixed
it.



  Parrot 0.3.0 TODO
Having successfully got Parrot building on his Cygwin installation,
Robert Eaglestone was casting around for something to do and listed a
few possibilities. Will Coleda replied that he'd quite like to see a
working Parrot equivalent to Perl 5's $0.



  Parrot 0.3.0 and Tru64
Jarkko Hietaniemi posted a bunch of issues with Parrot on the Tru64
architecture. Leo addressed them. I'm not sure they're all fixed yet
though.

  TCL - Compiling
Will Coleda announced that ParTcl is now a compiler. Some tests are
failing but Will claimed that this is because Jerry Gay was getting
bored with all the tests passing. Jerry was delighted. As Will said
later in the thread, the current iteration is doing the bare minimum
needed to be called a compiler, but of course that will change over
time. Good work Will.



  BROKEN.pod
Hey, now he's no longer my editor, I don't have to worry about making
sure I don't put his name at the beginning of a sentence! Anyhow,
chromatic posted a first cut at BROKEN.pod, the big list of broken
stuff. There followed some discussion of how this should be organised in
the future, particularly on the RT side. After discussion, it was
decided to keep it as a single file for now, but to aim for generating
it from multiple RT tickets in the future.



  Stack call directives are deprecated
Using ".param", ".arg", ".return", ".result" and "call" to do stack
based calling conventions is now deprecated. Use "save", "restore",
"bsr" and "ret" instead. Or, ideally, use the standard Parrot calling
conventions.



  Deprecation of rx ops
Brent Royal-Gordon confirmed that he was happy enough to see his
experimental regular expression specific ops removed from Parrot.

They've not been removed yet, but they're certainly deprecated.



  Software Architecture of Parrot
Klaas-Jan Stol informed us that his Software Architecture professor had
approved his proposal to write a paper on the architecture of Parrot. He
outlined his plans for the paper and hoped that he would be able to
count on people for proof-reading when the time came. Leo thought it was
a marvellous idea (so do I come to that, but I didn't say anything on
the list.)



  ParTcl command line options, etc
Will Coleda kept us abreast of his progress with ParTcl in this thread,
initially announcing the new "-e" flag which allowed for writing one
liners. After a certain amount of havering before a final interface
arrived, ParTcl also acquired a --pir flag, which dumps the results of
compilation to a PIR file.



  BASIC compiler
Will Coleda (does the man never sleep?) announced that the BASIC
compiler is (sort of) working again with Parrot 0.3.0. There are still
problems with the windows display code (the offending code is simply
commented out), but code that doesn't need that appears to be working
now. He noted that BASIC could really use a decent test suite, right now
he was simply working to get programs like eliza2.bas and wumpus.bas
working

Re: Class Methods, Eigenclasses and $?CLASS

[Luke Palmer]

On 10/10/05, Stevan Little <[EMAIL PROTECTED]> wrote:
>   ::Class
>  ^
>  :  <-- eFoo is a subclass of Class
>  :
>   ::eFoo   # eFoo is also an instance of Class
>  |
>  |  <-- eFoo is the class of Foo
>  V
>::Foo
>
> The dispatching of instance methods is still the same, and everything
> "just works". Well... almost everything.

How do you explain this:

class Foo {
method bar (Class $class:) { "class method" }
}
say Foo.bar;# class method
my $foo = Foo.new;
say $foo.bar;   # class method

Assuming that that is valid Perl.

Luke

Re: Class Methods, Eigenclasses and $?CLASS

[Stevan Little]

Luke,

On Oct 10, 2005, at 7:47 PM, Luke Palmer wrote:

How do you explain this:

class Foo {
method bar (Class $class:) { "class method" }
}
say Foo.bar;# class method
my $foo = Foo.new;
say $foo.bar;   # class method

Assuming that that is valid Perl.


It is "valid" Perl 5, however (IMHO) it is *not* valid Perl 6.

To start with, the type of the invocant is Class, which $foo is not  
derived from (it is an instance of something which itself is an  
instance of Class).


I think that

  $foo.class.bar()

should work. And changing the method defintion to be

  method bar (Class|Foo $class:) { ... }

should work, but the code as you wrote it should not. Which means  
that when we deal with Perl 5 classes within Perl 6, we should likely  
give them an implied signature of (Class|Foo $self:) or some other  
weirdness (I haven't thought that far down the line yet).


Class methods are strange creatures, in Perl 5 they were nothing  
different than instance methods. In Java (static methods), they are  
really just odd functions which need to be qualified by a class name.  
Python doesn't even really have them (you have to jump through odd  
hoops to make the method "callable"). Ruby uses Eigenclasses, and  
CLOS uses something akin to eigenclasses. I am not sure how Smalltalk  
handles things, but my guess is that class methods on Foo are  
instance methods of classFoo, or some such.


They are ugly beasties no matter what, but eigenclasses (so far) seem  
to be the prettiest of the uglies.


Stevan