I'll show you mine...

[Piers Cawley]

Okay, this is the beginnings of Scheme in Perl6. I'm sure there's
stuff I'm getting wrong. I've not written the parser yet for instance
and I'm toying with waiting for A5 before I do. Also, I've not yet
implemented such important stuff as proper closures/lambda or the
environment chain, but the underpinning structure is there.

I'm also deeply uncertain about the workings of overloading and of
operator declaration so those bits are probably wrong.

---SNIP---

module SchemeInterpreter;

class SchemeExpr {
  use overload 
'""' => 'raw_string',
'0+' => 'to_number',
fallback => 1
  ;

  my SchemeExpr $.value;

  method new($proto: $val) {
my $s = $proto.SUPER::new but true;
$s.set_value( $val );
$s;
  }

  method value { $.value }
  method set_value($s: SchemeExpr $val) { $.value = $val; $s }

  method raw_string { "$.value" }
  method display_string { .raw_string }

  method evaluate($s: $context) { $s } 

  method AUTOLOAD {
my($method) = ($AUTOLOAD =~ m/.*::(.*)/);
my $self = shift;
$self."NEXT::$method"(*@_) unless $method =~ /^is_/;
return;
  }
}

class SchemeBoolean is SchemeExpr {
  my($t, $f);

  method new($proto: $val) {
given $val {
  when '#t' { $t //= $proto.SUPER::new($val) }
  when '#f' { $f //= $proto.SUPER::new($val) but false }
  default { $proto.new( $val ?? '#t' :: '#f' ) }
}
  }

  method is_boolean { 1 }
}

class SchemeNumber is SchemeExpr {
  my sub apply($self: $target, $rhs, &block) {
if $is_rhs { $self.new(+ &block( $target, $self.value )) }
else   { $self.new(+ &block( $self.value, $target )) }
  }
   
  method operator:+ { apply(*@_, {$^a + $^b}) }
  method operator:* { apply(*@_, {$^a * $^b}) }
  method operator:- { apply(*@_, {$^a * $^b}) }
  method operator:/ { apply(*@_, {$^a * $^b}) }

  method is_number { 1 }
}

class SchemePair is SchemeExpr {
  my $nil //= class is SchemeExpr {
method is_nil {1}
method car { fail Exception:
 msg => "car: expects argument of type , given ()" }
method cdr { fail Exception:
 msg => "cdr: expects argument of type , given ()" }
  }.new('()');

  method new($proto: PAIR $val) { $proto.SUPER::new($val) }

  method cons($proto: SchemeExpr $car, SchemeExpr $cdr) {
$proto.new( $car => $cdr )
  }

  method car { .value.key }
  method cdr { .value.value }
  method is_pair { 1 }

  method as_array($s:) {
my @ary;
my $l = .cons($nil, $s);

while ($.is_pair) {
  push @ary, $l.car;
  $l = $l.cdr;
}
push @ary, $l;
return @ary;
  }
  
  method raw_string {
my @ary = .as_array;
if @ary[-1].is_nil { @ary.pop; "(@ary)" }
else { my $last = @ary.pop; "(@ary . $last)" }
  }

  method evaluate($self: $context) {
$context.eval_list($self)
  }

  method length($self:) {
my @ary = $self.as_array;
unless @ary[-1].is_nil {
  fail Exception:
msg => "length: expects argument of type ; given $self";
@ary.length - 1;
  }

  method AUTOLOAD {
.NEXT::AUTOLOAD unless $AUTOLOAD =~ /:?c([ad]+)r$/;
my @ops = reverse split '', $1;
my $val = $_[0];
for @ops -> $type {
  $val = $val."c${type}r";
}
return $val;
  }
}

class SchemeSymbol is SchemeExpr {
  my %symcache;

  method new($name) {
%symcache{"$name"} //= .SUPER::new("$name");
  }
  method is_symbol { 1 };
  method evaluate($self: $context) {
$context.eval_symbol($self);
  }
}

class SchemePrimitive is SchemeExpr {
  method new($proto: PAIR $val) {
$proto.SUPER::new($val)
  }

  method is_primitive { 1 };
  method raw_string { "#" }
  
  method apply($self: SchemeExpr $expr, $context) {
$self.value.value($expr, $context)
  }
}
  


class SchemeEnvironment is HASH {
  my $the_null_envt = class {
method exists { }
method bind { fail "You can't bind anything in the null environment" }
method set { fail "You can't set anything in the null environment" }
method get($symbol) { fail "reference to undefined identifier: $symbol" }
  }.new;

  method init {
.{__parent__} //= $the_null_envt;

  method new_scope($self:) { ref($self).new(__parent__ => $self) }

  method bind_primitive($name, &func) {
.bind(SchemeSymbol.new($name), 
  SchemePrimitive.new( $name => &func ));
  }

  my method parent { .{__parent__} }
  
  method set($self: SchemeSymbol $key, SchemeExpr $value) {
given .exists($key) {
  when defined { .value($value) }
  default { fail "cannot set undefined identifier: $key" }
}
return $self;
  }

  method bind($self: SchemeSymbol $key, SchemeExpr $val) {
.{$key} = $value;
return $self;
  }
}  

class MathEvaluator {
  method evaluate($self: SchemeExpr $expr) {
$expr.evaluate($self);
  }

  method eval_list($self: SchemePair $list) {
my($op, $a, $b, @rem) = $list.as_array;

fail Exception:
  msg => "Malformed expression $list. Expect (  )"
if @rem.length;

$a.evaluate($self); $b.evaluate($self);

giv

Re: Bracekets

[Mark J. Reed]

On Wed, Apr 10, 2002 at 04:03:29PM +1000, Damian Conway wrote:
> My understanding was that perl6 would default to Perl 6 (*not* Perl 5), unless
> the first thing it encountered was a:
> 
>   package Whatever;
> 
> statement. 
If so, that's a change, at least from what I gleaned by following this list
and reading the Apocalypses/Exegeses.

My understanding was that Perl6 is supposed to run Perl5 scripts with
no change in the way they're invoked (that is, still #!/usr/bin/perl, not
#!/usr/bin/perl5compat or #!/usr/bin/perl -5 or anything like that).
Under that requirement, the compatibility can't be switched on by
the 'package' declaration, because the 'package' declaration is optional
in Perl5.   So instead Perl5 was going to be the default until a 
Perl6 keyword - such as 'module' or 'class' -  indicates that the program
being parsed is Perl6.

On the other hand, I can see why there might have been a change of heart
about this, since while the logic works fine for modules, it means that
quick one-off scripts, including one-liners, have to include something like
'module main;' or some new command-line switch to turn on Perl6 mode.  

Darn that backwards compatibility, anyway . . .
-- 
Mark J. REED<[EMAIL PROTECTED]>

Re: I'll show you mine...

[Piers Cawley]

In message <[EMAIL PROTECTED]>, I wrote:
> [ A huge wodge of possible perl 6 code ]

I'm getting that Warnock's Dilemma feeling here... Did I stun you all
into silence?

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: I'll show you mine...

[Dan Sugalski]

At 3:03 PM +0100 4/10/02, Piers Cawley wrote:
>In message <[EMAIL PROTECTED]>, I wrote:
>>  [ A huge wodge of possible perl 6 code ]
>
>I'm getting that Warnock's Dilemma feeling here... Did I stun you all
>into silence?

Nah. You just can't hear the people running away screaming from there. ;-P
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: I'll show you mine...

[Aaron Sherman]

On Wed, 2002-04-10 at 10:03, Piers Cawley wrote:
> In message <[EMAIL PROTECTED]>, I wrote:
> > [ A huge wodge of possible perl 6 code ]
> 
> I'm getting that Warnock's Dilemma feeling here... Did I stun you all
> into silence?

On my clock, your original message arrived at 04:23, and your followup
at 10:03. On the west coast of the US, that would be 01:23 to 07:03.
That's probably the time you're least likely to get responses.

Personally, I'm a little stunned. I wish I could load it into a
debuggger ;-)

Your idea at the end of regugitating the code back out as Parrot or Perl
is just slightly stunning on its own.

Still digesting

Re: I'll show you mine...

[Piers Cawley]

Aaron Sherman <[EMAIL PROTECTED]> writes:

> On Wed, 2002-04-10 at 10:03, Piers Cawley wrote:
>> In message <[EMAIL PROTECTED]>, I wrote:
>> > [ A huge wodge of possible perl 6 code ]
>> 
>> I'm getting that Warnock's Dilemma feeling here... Did I stun you
>> all into silence?
>
> On my clock, your original message arrived at 04:23, and your
> followup at 10:03. On the west coast of the US, that would be 01:23
> to 07:03.  That's probably the time you're least likely to get
> responses.

Ah yes. Timezones. But I confess I was hoping for a reaction from any
European contingent.

> Personally, I'm a little stunned. I wish I could load it into a
> debuggger ;-)

Me too. I'm *sure* it's full of mistakes 'cos wetware sucks for this
sort of thing. But it was fun to write.

> Your idea at the end of regugitating the code back out as Parrot or Perl
> is just slightly stunning on its own.

I thought that was the easy bit. The compiler just (for appropriate
values of 'just' of course) walks the syntax tree and uses an
appropriate code generator to output appropriate source, which is what
compilers have been doing since the year dot surely.

> Still digesting

 Patches welcome.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: I'll show you mine...

[Dan Sugalski]

At 3:49 PM +0100 4/10/02, Piers Cawley wrote:
>Aaron Sherman <[EMAIL PROTECTED]> writes:
>  > Your idea at the end of regugitating the code back out as Parrot or Perl
>>  is just slightly stunning on its own.
>
>I thought that was the easy bit. The compiler just (for appropriate
>values of 'just' of course) walks the syntax tree and uses an
>appropriate code generator to output appropriate source, which is what
>compilers have been doing since the year dot surely.

We're going to have to put the asm keyword in for you, aren't we? :)

(Or maybe attributed string eval, like:

 $foo = eval.Parrot <

Re: Unary dot

[Allison Randal]

On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote:
> Larry Wall <[EMAIL PROTECTED]> writes:
> 
> > We're talking about how to make .foo mean self.foo regardless of the
> > current topic.
> 
> Are we? I was looking for a way to unambgiously access the current
> object in such a way that topicalizers would still work...

I think we were talking about both.

Okay, now that thith hath had a chanth to thteep in my brain for a day
or tho... Here's a twist to another perspective:

The thing with this "invocant" is, you're essentially creating another
$_. It's an accessible named thing that acts as a noun and automatically
receives a value in a particular context. It may be implemented as a
macro, but will be perceived as a variable, another named alias to the
value, since it can be used in all the same contexts as a "full"
variable. Because of this, I'd like to see it keep the sigil, not by
choice, but by requirement:

use invocant "self";
...
method ical {
$self.method_call();
...
}

It's similar to the old concept of topic, before topic and $_ were
unified. Maybe we now have "invocantalizers"? ;)

Some of the issues:

- The .method_call() syntax is not nearly as appealing if you can't use
  it consistently, 

but,
- It is desirable, from a language learning/use perspective, for
  .some_call() to always act the same within a C when the topic
  is an object, whether the construct is within a method or not (or at
  least default to acting the same).

- The natural question, once you realize Perl is holding this
  automatically generated value for you (which seems almost, but not
  quiet, identical to $_), is "Why can't I default to it?", 

but,
- One of the reasons for merging $_ and topic was to avoid the confusion
  of multiple defaults (and to avoid deprecating $_ to "the default
  default"). Invocants might add that complexity back.

I see two directions the solution could go in. Direction 1 is "if you
don't like it, lump it". If you're going to need to access an outer
topic within a nested topicalizer, you should define a named
variable/parameter ("method icial ($self:..."). This is the path we've
taken with other nested topicalizers. 

Direction 2 moves into the more exciting but scarier realm of alternate
defaults. I would suggest that if we do add a) the ability to
automatically populate variables (or macro accessed values) other than
$_ and b) the ability to default to these variables (or macro accessed
values), that we separate the two concepts, either by using two separate
pragmas, or by making the "invocant as default" an option on the
invocant pragma. I don't think defining a blank "" invocant name, or
leaving off the name is ostentatious enough to do justice to the drastic
change of altering the topic structure within the scope of all methods
in the class (this is related to the linguistic principle of "given vs.
new information", new information is typically "marked", more
prominent). Here are a few possibilities:

use invocant "self";
use method_default "self";

use invocant "self" is method_default;

my $self is invocant is method_default;

None of these is quite satisfying. All have associated problems: the
first because the "method_default" pragma couldn't quite stand alone,
the second because of the non-standard use of C, the third because
you don't quite want to declare a variable, just specify a default.
Hmm...  possibly:

use invocant $self is method_default;

Which solves the first problem, by being a single statement, the second
problem by making the "is method_default" a property of the variable (or
more literally, a property that is pre-defined to be associated to the
variable when it is instantiated in a method), and totally bypasses the
third problem.

The choice of "method_default" is intended to specify that the unique
behaviour only affects .method_call() defaults, not the hoi polloi,
garden-variety defaulting constructs, but a better name could be found.

Allison

Re: I'll show you mine...

[Melvin Smith]

At 09:23 AM 4/10/2002 +0100, Piers Cawley wrote:
>Okay, this is the beginnings of Scheme in Perl6. I'm sure there's
>stuff I'm getting wrong. I've not written the parser yet for instance

Very nice! Quite a sample, maybe Larry/Damian can use this
in one of the next $(A,E)'s


>   my SchemeExpr $.value;

I haven't been keeping up in the back, I've a wedding bearing down on me.

What is the significance of the . in the declaration? I think I paid attention
enough to know a little about the unary dot but I'm still confused.
We are able to use .foo to mean self.foo, but I would assume foo would be
declared with my Foo $foo, not my Foo $.foo ?

>   method car { .value.key }
>   method cdr { .value.value }

Maybe its the C++ in me but why the use of the unary . inside methods
of the current class who's scope includes C already?

Isn't this like using C in C++ from inside a non-static method?

I'll await your ruler on my knuckles, but overall; very impressed here.

-Melvin

Re: Unary dot

[Glenn Linderman]

Allison Randal wrote:
> 
> On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote:
> > Larry Wall <[EMAIL PROTECTED]> writes:
> >
> > > We're talking about how to make .foo mean self.foo regardless of the
> > > current topic.
> >
> > Are we? I was looking for a way to unambgiously access the current
> > object in such a way that topicalizers would still work...
> 
> I think we were talking about both.

> I see two directions the solution could go in. Direction 1 is "if you
> don't like it, lump it". If you're going to need to access an outer
> topic within a nested topicalizer, you should define a named
> variable/parameter ("method icial ($self:..."). This is the path we've
> taken with other nested topicalizers.

Yes, yes, be explicit.  If the current topic is an object, its methods
get invoked by unary dot, be it inside a method or outside a method.

> Direction 2 moves into the more exciting but scarier realm of alternate
> defaults.

It could, but how about an alternative?

Need there be a unary dot to specify invocation of an alternate method
in the same class as the method being compiled?  In other words, the
following rules:

1) A method implicitly defines the default topic to be the object on
which it was invoked.

2) Unary dot uses the default topic as the object on which to invoke
methods.  If the default topic is not an object, an exception results.

3) The function call name space within a method is first other methods
of the same class, then other functions.  (This is similar to C++, I
believe)

Hence, given a class containing two methods m1 and m2...

method m1
{
   m2;  # calls method m2 in the same class
   & m2;  # this should do the same, if the & is still permitted
   .m2;  # syntax error
   given ( $other_object )
   {
   when m2 { ... }   # invokes method m2 in the same class
   when .m2 { ... }  # invokes $other_object.m2
   when $_.m2 { ... }  # invokes $other_object.m2
   when $self.m2 { ... }  # syntax error, unless some "use invocant
self"
  # directive is included somewhere in the
scope
  # If it is, then invokes method m2 in same
class
   }
}

-- 
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.

Re: Unary dot

[Mark J. Reed]

On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> method m1
> {
>m2;  # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant?  If the former, how would you
do the latter?

>.m2;  # syntax error
Doesn't that violate your stated rule that"the default topic within a
method be the invocant?  Shouldn't .m2 be equivalent to $_.m2?


-- 
Mark J. REED<[EMAIL PROTECTED]>

RE: Unary dot

[David Whipp]

Mark J. Reed wrote:
> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > method m1
> > {
> >m2;  # calls method m2 in the same class
> Yes, but does it call it as an instance method on the current invocant
> or as a class method with no invocant?  If the former, how would you
> do the latter?

I would expect the the "m2()" call would use the invocant of m1.
If m1 is a called as a class method, then m2 would, also.

If every object has a C method (C?), then you could
always call class-methods as class.m2().


Dave.

Re: Unary dot

[Glenn Linderman]

"Mark J. Reed" wrote:
> 
> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > method m1
> > {
> >m2;  # calls method m2 in the same class
> Yes, but does it call it as an instance method on the current invocant
> or as a class method with no invocant?  If the former, how would you
> do the latter?

Should both be allowed to exist?  Do both exist?  Why do both exist? 
(with the same name).  If only one exists, then that would be the one
that gets called.

> 
> >.m2;  # syntax error
> Doesn't that violate your stated rule that"the default topic within a
> method be the invocant?  Shouldn't .m2 be equivalent to $_.m2?

Oops. Yep, got me there.  I should have wrapped a  "given $non_object"
around that one.  Thanks.

-- 
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.

Re: Unary dot

[Mark J. Reed]

On Wed, Apr 10, 2002 at 10:50:52AM -0700, Glenn Linderman wrote:
> > Yes, but does it call it as an instance method on the current invocant
> > or as a class method with no invocant?  If the former, how would you
> > do the latter?
> 
> Should both be allowed to exist?  Do both exist?  Why do both exist? 
> (with the same name).  If only one exists, then that would be the one
> that gets called.
Making the decision based on existence implies a requirement that
Perl6 methods be explicitly declared as either class or instance.
Not that there's anything wrong with that; I'm just not aware of
that decision having been made.  I guess we won't find out for sure
until either Apoc6 or Apoc12?


-- 
Mark J. REED<[EMAIL PROTECTED]>

Re: Unary dot

[Glenn Linderman]

David Whipp wrote:
> 
> Mark J. Reed wrote:
> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > > method m1
> > > {
> > >m2;  # calls method m2 in the same class
> > Yes, but does it call it as an instance method on the current invocant
> > or as a class method with no invocant?  If the former, how would you
> > do the latter?
> 
> I would expect the the "m2()" call would use the invocant of m1.
> If m1 is a called as a class method, then m2 would, also.
> 
> If every object has a C method (C?), then you could
> always call class-methods as class.m2().
> 
> Dave.

Thanks, Dave, that's an excellant idea.

-- 
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.

Re: Unary dot

[Melvin Smith]

At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
>"Mark J. Reed" wrote:
> >
> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > > method m1
> > > {
> > >m2;  # calls method m2 in the same class
> > Yes, but does it call it as an instance method on the current invocant
> > or as a class method with no invocant?  If the former, how would you
> > do the latter?
>
>Should both be allowed to exist?  Do both exist?  Why do both exist?
>(with the same name).  If only one exists, then that would be the one
>that gets called.

I'd hope it would assume "instance" method until told otherwise,
since static methods (class methods) are seldom used in OOP.

Also there are issues when just assuming if m1() is a class method,
I call m2() as a class method because m2() may access instance
data that wouldn't exist if it were called staticly.

-Melvin

Re: I'll show you mine...

[Piers Cawley]

Melvin Smith <[EMAIL PROTECTED]> writes:

> At 09:23 AM 4/10/2002 +0100, Piers Cawley wrote:
>>Okay, this is the beginnings of Scheme in Perl6. I'm sure there's
>>stuff I'm getting wrong. I've not written the parser yet for instance
>
> Very nice! Quite a sample, maybe Larry/Damian can use this
> in one of the next $(A,E)'s
>
>
>>   my SchemeExpr $.value;
>
> I haven't been keeping up in the back, I've a wedding bearing down on me.
>
> What is the significance of the . in the declaration? 

  class Class {
my $class_variable;
my $.instance_variable;

...
  }

Easy eh?

> I think I paid attention enough to know a little about the unary dot
> but I'm still confused.  We are able to use .foo to mean self.foo,
> but I would assume foo would be declared with my Foo $foo, not my
> Foo $.foo ?
>
>>   method car { .value.key }
>>   method cdr { .value.value }
>
> Maybe its the C++ in me but why the use of the unary . inside methods
> of the current class who's scope includes C already?

Consider 

  class SpecializedPair is SchemePair {
method value {...}
  }

If you've written 'cdr' without the unary . it will attempt to
dispatch to a *subroutine* in the same context, ie
SchemePair::value. Even assuming that we play nice and allow confusion
between methods and subroutines (which I'm personally not keen on),
it's still apparent that, in the case of a SpecializedPair, car and
cdr would use the wrong &value.

> Isn't this like using C in C++ from inside a non-static method?

Don't ask me. I know nothing about C++ -- Objective C (Looong ago),
Perl 5, Smalltalk and Ruby for me.

> I'll await your ruler on my knuckles, but overall; very impressed
> here.

Thanks. Wait for the next version though, I'm busy implementing
lexical scopes at the moment. 

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Unary dot

[Piers Cawley]

Melvin Smith <[EMAIL PROTECTED]> writes:

> At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
>>"Mark J. Reed" wrote:
>> >
>> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
>> > > method m1
>> > > {
>> > >m2;  # calls method m2 in the same class
>> > Yes, but does it call it as an instance method on the current invocant
>> > or as a class method with no invocant?  If the former, how would you
>> > do the latter?
>>
>>Should both be allowed to exist?  Do both exist?  Why do both exist?
>>(with the same name).  If only one exists, then that would be the one
>>that gets called.
>
> I'd hope it would assume "instance" method until told otherwise,
> since static methods (class methods) are seldom used in OOP.

Um... don't you use factory methods? I know I do.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Unary dot

[Graham Barr]

On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > method m1
> > {
> >m2;  # calls method m2 in the same class
> Yes, but does it call it as an instance method on the current invocant
> or as a class method with no invocant?  If the former, how would you
> do the latter?

This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?

Graham.

Re: Unary dot

[Glenn Linderman]

Graham Barr wrote:
> 
> On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> > > method m1
> > > {
> > >m2;  # calls method m2 in the same class
> > Yes, but does it call it as an instance method on the current invocant
> > or as a class method with no invocant?  If the former, how would you
> > do the latter?
> 
> This may be a case of keep up at the back, but if that is a method call,
> how do I call a subroutine from within a method ?

The same way.  If there is a name conflict between subroutine and
methods, then you qualify the subroutine name...

::m2; # calls global subroutine main::m2
main::m2; # calls global subroutine main::m2

-- 
Glenn
=
Remember, 84.3% of all statistics are made up on the spot.

Re: Unary dot

[Piers Cawley]

Graham Barr <[EMAIL PROTECTED]> writes:

> On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
>> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
>> > method m1
>> > {
>> >m2;  # calls method m2 in the same class
>> Yes, but does it call it as an instance method on the current invocant
>> or as a class method with no invocant?  If the former, how would you
>> do the latter?
>
> This may be a case of keep up at the back, but if that is a method call,
> how do I call a subroutine from within a method ?

And anyone who says "You don't" will receive a good hard talking to
from me. Being able to declare private subroutines within classes is
really useful, witness:

class SchemeNumber is SchemeExpr {
  my sub apply($self: $target, $rhs, &block) {
if $is_rhs { $self.new(+ &block( $target, $self.value )) }
else   { $self.new(+ &block( $self.value, $target )) }
  }
   
  method operator:+ { apply(*@_, {$^a + $^b}) }
  method operator:* { apply(*@_, {$^a * $^b}) }
  method operator:- { apply(*@_, {$^a * $^b}) }
  method operator:/ { apply(*@_, {$^a * $^b}) }

  method is_number { 1 }
}

Yes, I know there's several different ways I could do it, but this
approach feels right.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Unary dot

[Piers Cawley]

Glenn Linderman <[EMAIL PROTECTED]> writes:

> Graham Barr wrote:
>> 
>> On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
>> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
>> > > method m1
>> > > {
>> > >m2;  # calls method m2 in the same class
>> > Yes, but does it call it as an instance method on the current invocant
>> > or as a class method with no invocant?  If the former, how would you
>> > do the latter?
>> 
>> This may be a case of keep up at the back, but if that is a method call,
>> how do I call a subroutine from within a method ?
>
> The same way.  If there is a name conflict between subroutine and
> methods, then you qualify the subroutine name...
>
> ::m2; # calls global subroutine main::m2
> main::m2; # calls global subroutine main::m2

This is looking more and more horrible Glenn.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Unary dot

[Mark J. Reed]

On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote:
> > ::m2; # calls global subroutine main::m2
> > main::m2; # calls global subroutine main::m2
> 
> This is looking more and more horrible Glenn.
I think we need to back off of unmarked subroutines becoming a method 
call.  That one extra '.' in front isn't too much, is it?

I like the following, assumed to be within method m1:

..m2();# call m2 the same way m1 was called, instance or class
$_.m2();   # same thing?  Does the class become the topic in a static method?
..class.m2: # call static m2 within m1's class, regardless of how m1 was called
m2()   # call subroutine m2 with no arguments, implied or otherwise


-- 
Mark J. REED<[EMAIL PROTECTED]>

Re: Unary dot

[Allison Randal]

On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> Allison Randal wrote:
> > 
> > Direction 2 moves into the more exciting but scarier realm of alternate
> > defaults.
> 
> It could, but how about an alternative?
 
Ah-ha, yet a third Direction!

> Need there be a unary dot to specify invocation of an alternate method
> in the same class as the method being compiled?  In other words, the
> following rules:
> 
> 1) A method implicitly defines the default topic to be the object on
> which it was invoked.
 
As has been mentioned, this is already true.

> 2) Unary dot uses the default topic as the object on which to invoke
> methods.  If the default topic is not an object, an exception results.
 
Well, since all the variable types are now objects, which have methods,
this wouldn't happen. But you would get some sort of exception if there
was no method of that name for the current object.

> 3) The function call name space within a method is first other methods
> of the same class, then other functions.  (This is similar to C++, I
> believe)
> 
> Hence, given a class containing two methods m1 and m2...
> 
> method m1
> {
>m2;  # calls method m2 in the same class
>& m2;  # this should do the same, if the & is still permitted
>.m2;  # syntax error
>given ( $other_object )
>{
>when m2 { ... }   # invokes method m2 in the same class
>when .m2 { ... }  # invokes $other_object.m2
>when $_.m2 { ... }  # invokes $other_object.m2
>when $self.m2 { ... }  # syntax error, unless some "use invocant
> self"
>   # directive is included somewhere in the
> scope
>   # If it is, then invokes method m2 in same
> class
>}
> }
> 

I kind of like the idea of having both "topic" and "invocant" available
at all times. But, I am concerned at having such a huge semantic
difference (which object you're using) relying on the subtle visual
distinction between m2() and .m2(). I can see a large opportunity for
coder error and newbie misunderstanding. You also lose the visual cue
that says "this is a method call, not a subroutine or a built-in
function". In the end I think that might be more confusing than it's
worth.

Allison

Re: Unary dot

[Mark J. Reed]

On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
> ..class.m2: # call static m2 within m1's class, regardless of how m1 was called
Typo.  That should be just .class.m2, only one leading '.'.


-- 
Mark J. REED<[EMAIL PROTECTED]>

RE: Unary dot

[David Whipp]

Mark J. Reed wrote
> On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
> > ..class.m2: # call static m2 within m1's class, regardless 
> of how m1 was called
> Typo.  That should be just .class.m2, only one leading '.'.

Wouldn't that be the current topic's class?


Dave.

Re: Unary dot

[Mark J. Reed]

On Wed, Apr 10, 2002 at 12:12:56PM -0700, David Whipp wrote:
> Mark J. Reed wrote
> > On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
> > > ..class.m2: # call static m2 within m1's class, regardless 
> > of how m1 was called
> > Typo.  That should be just .class.m2, only one leading '.'.
> 
> Wouldn't that be the current topic's class?
.. . . and not necessarily the class in which m1 was declared.  Good point.
I was assuming a simpler, inheritance-free case.

-- 
Mark J. REED<[EMAIL PROTECTED]>

Re: Avoiding the deadlands

[Dan Sugalski]

At 4:54 AM -0400 4/9/02, Michel J Lambert wrote:
>  > So, I think #2 is the way to go. We'll add a new flag,
>>  (BUFFER|PMC)_stay_of_execution_FLAG or something, that gets added to
>>  allocated PMCs and Buffers. It'll be treated the same way as the
>>  constant/immortal flag is treated for DOD purposes, with one
>>  difference--there'll be an op which specifically clears the flags.
>>  Since the flag is *not* valid to be set across ops, we're fine.
>
>Sounds good to me. This requires that we manually insert this
>clear_soe_flag op in code, where we want it. If we don't insert it, we
>effectively make everything immortal/immune, forever.

Right. A good spot for it is in either explicit DOD request ops, or 
we require it as one of the ops run at block exit or something. We 
may do a sweep when an exception's triggered as well.

>Finding 'proper'
>places to insert this could be hard to do for the compiler writer, imo.

Nah, I don't think so. There are plenty of reasonable places, and 
odds are it won't affect many structures anyway, so if we defer it a 
lot there's no harm nor foul there.

>The larger the amount of code in a loop, the more likely this op is to
>exist inside the loop? Not sure what other heuristics there would be.

Don't

>  > Only those functions that *must* set it will, and they are also
>>  required to make sure the stay_of_execution_count interpreter
>>  variable is set to the proper number (or at least large enough) on
>>  abnormal exit. (That way we can keep the flag clearing op from
>>  actually running if there's no reason)
>
>Aren't most functions going to be required to set it, indirectly?

No.

>new_*_header seems like an ideal place to set the SOE flag, and increment
>the internal counter.

Gah! No, absolutely not! The *only* place it should be set is in 
those functions that both:

1) Allocate structs
and
2) Can't guarantee those structs are reachable when calling a 
function that may trigger the GC.

That's a rather vanishingly small number of functions, really. I 
think we'll be OK, and we might add in a counted version of 
new_*_header to atomically request multiple PMC/Buffer/STRING structs 
which would alleviate many of the problems as well. (Which still 
leaves us with the issue of maintaining non-deathness across 
allocations of multiple struct types)

Most of the functions that allocate structs are leaf-node type 
functions, so I think we'll be OK there.

Also, the functions that set it should probably reset it when they're 
done, though I could argue against requiring that one for speed 
purposes. I think I'd want benchmarks for it, though.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Patches, patches, patches...

[Dan Sugalski]

To forestall potential incidents of Warnock's Dillemma...

I'm about to apply a whole heap 'o patches to Parrot. (With 
appropriate [APPLIED] responses, I hope) If, at the end of the day, I 
have *not* applied or commented on a patch you've sent, it means I've 
Officially Missed It, so give another try.

Sorry 'bout this. Too much mail in the mailbox, and going back in 
time is tricky, as it can miss subsequent discussions on patches 'n 
stuff.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: PMC confusion

[Dan Sugalski]

At 12:47 AM -0500 4/2/02, Will Coleda wrote:
>I can't concat strings to a PerlString, I have to assign the constant
>string to another PerlString to do the concat...
>
>Is this just that a suitable entry in perlstring.pmc needs to be
>created?

Yep.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: [PATCH] Parrot_(re)allocate_buffer

[Dan Sugalski]

At 6:52 PM -0500 4/3/02, Bryan C. Warnock wrote:
>On Wednesday 03 April 2002 16:55, Michel J Lambert wrote:
>>  > Why add new functions instead of patching the current ones?
>>
>>  I didn't know if the original functions still had a purpose. Perhaps you
>>  would want to Parrot_allocate for something non-bufferish? Thinking about
>>  it, that seems evilly wrong, so I guess that is not a valid reason. Doing
>>  this would make mem_realloc and Parrot_reallocate_buffer a little bit more
>>  difficult, since they'd have to allocate a temporary buffer on the stack
>>  to call the function, or stash away the values of the incoming buffer
>>  before it gets overwritten, so it can later memcpy.
>>
>>  Should I resubmit a patch removing the _buffer suffix, and removing
>>  mem_realloc?
>
>The concern is that both functions are still using the same arenas, which
>means the original problems still wouldn't be solved, and we'd still have to
>do all the workarounds around them.  ;-)

That should be OK. Calling Parrot_reallocate in the middle of a GC 
run will take the new memory from the new pools, since the GC 
switches pool pointers at the start of its compaction phase.

I'm going to go in and make Parrot_reallocate take Buffers, which is 
what it should've done in the first place. Parrot_allocate too.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Patches, patches, patches...

[Melvin Smith]

At 12:40 PM 4/10/2002 -0400, Dan Sugalski wrote:
>To forestall potential incidents of Warnock's Dillemma...
>
>I'm about to apply a whole heap 'o patches to Parrot. (With appropriate 
>[APPLIED] responses, I hope) If, at the end of the day, I have *not* 
>applied or commented on a patch you've sent, it means I've Officially 
>Missed It, so give another try.
>
>Sorry 'bout this. Too much mail in the mailbox, and going back in time is 
>tricky, as it can miss subsequent discussions on patches 'n stuff.

To maybe give you some help, I applied:

2 of my own patches that I sent to the list, 1st was the register frame
stack bug fix, 2nd was to make stacks keep their size.

1 of Mike Lambert's large patches that fixed several GC bugs titled:
  "Complete, Mainly-GC Patch"

Steve applied Mike's large computed goto patch.

The rest I didn't touch as I was unsure about.

I think there is at least one outstanding patch from Brian Warnock called:
"stacks.c"

one from Peter Gibbs and Mike Lambert named:
"Parrot_(re)allocate_buffer"

This is not all, I'm sure but I hope this helps you sift the mound.

-Melvin

Re: Patches, patches, patches...

[Dan Sugalski]

At 12:53 PM -0400 4/10/02, Melvin Smith wrote:
>At 12:40 PM 4/10/2002 -0400, Dan Sugalski wrote:
>>To forestall potential incidents of Warnock's Dillemma...
>>
>>I'm about to apply a whole heap 'o patches to Parrot. (With 
>>appropriate [APPLIED] responses, I hope) If, at the end of the day, 
>>I have *not* applied or commented on a patch you've sent, it means 
>>I've Officially Missed It, so give another try.
>>
>>Sorry 'bout this. Too much mail in the mailbox, and going back in 
>>time is tricky, as it can miss subsequent discussions on patches 'n 
>>stuff.
>
>To maybe give you some help, I applied:

[Snip]

>This is not all, I'm sure but I hope this helps you sift the mound.

Yes, rather a lot--thanks.

I really need to hassle Qualcomm about putting in threaded sorting to Eudora...

-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Memory allocation changes

[Dan Sugalski]

Okay, having seen the discussion and now realized that my initial cut 
was too rough, here are some changes:

Parrot_allocate now takes a Buffer pointer and allocates into it, 
setting the length to what was really allocated.

Parrot_reallocate takes a Buffer pointer and a size, and resizes things.

Parrot_realloc is dead.

I'm currently not thinking that any sort of plain "get me GC memory 
but I'm not going to anchor it" routine is a good idea, but I can be 
convinced otherwise.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

[PATCH] PerlString fixes (and tests)

[Simon Glover]

 The enclosed patch makes a number of changes to perlstring.pmc, to bring
 it in line with my understanding of how PMCs are supposed to work.
 Specifically, unless we _know_ the type of the source and destination PMCs,
 we should always access them through their get_... and set_... methods.

 In practical terms, this means that in arithmetical ops, for instance,
 we shouldn't change the vtable of the destination PMC: the only thing
 that does that should be its own set_... ops (if changing the vtable is
 appropriate). It also means that in concat ops, we should be assigning
 directly to dest->data, as we have no idea what's actually stored there.

 This patch makes the appropriate changes for add, sub, mul, div and
 the concat_... ops; I haven't looked at the others in any detail yet.

 In addition to the above, I also fix up the indentation in a few places
 -- I can send this as a separate patch if necessary.

 Finally, I also include a patch to perlstring.t that substantially
 extends the test suite by providing basic tests for all of the
 aforementioned ops.

 Simon

--- classes/perlstring.pmc.old  Tue Apr  9 14:26:06 2002
+++ classes/perlstring.pmc  Wed Apr 10 14:35:55 2002
@@ -24,7 +24,7 @@

 void init (INTVAL size) {
SELF->data = string_make(INTERP,NULL,0,NULL,0,NULL);
-SELF->flags = PMC_is_buffer_ptr_FLAG;
+SELF->flags = PMC_is_buffer_ptr_FLAG;
 }

 void clone (PMC* dest) {
@@ -49,12 +49,12 @@

 INTVAL get_integer () {
STRING* s = (STRING*) SELF->data;
- return string_to_int(s);
+return string_to_int(s);
 }

 FLOATVAL get_number () {
STRING* s = (STRING*) SELF->data;
- return string_to_num(s);
+return string_to_num(s);
 }

 STRING* get_string () {
@@ -62,7 +62,7 @@
 }

 BOOLVAL get_bool () {
- return string_bool(SELF->data);
+return string_bool(SELF->data);
 }

 void* get_value () {
@@ -141,27 +141,28 @@

 void add (PMC * value, PMC* dest) {
if(value->vtable == &Parrot_base_vtables[enum_class_PerlInt]) {
-   dest->vtable = &Parrot_base_vtables[enum_class_PerlInt];
-dest->vtable->set_integer_native(INTERP, dest,
-   SELF->vtable->get_integer(INTERP, SELF) +
+dest->vtable->set_number_native(INTERP, dest,
+   SELF->vtable->get_number(INTERP, SELF) +
 value->cache.int_val
 );
}
else if(value->vtable == &Parrot_base_vtables[enum_class_PerlNum]) {
-   dest->vtable = &Parrot_base_vtables[enum_class_PerlNum];
 dest->vtable->set_number_native(INTERP, dest,
SELF->vtable->get_number(INTERP, SELF) +
 value->cache.num_val
 );
}
-   else {
+   else {
+dest->vtable->set_number_native(INTERP, dest,
+   SELF->vtable->get_number(INTERP, SELF) +
+value->vtable->get_number(INTERP,value)
+);
}
 }

 void add_int (INTVAL value, PMC* dest) {
-   dest->vtable = &Parrot_base_vtables[enum_class_PerlInt];
-dest->vtable->set_integer_native(INTERP, dest,
-   SELF->vtable->get_integer(INTERP, SELF) +
+dest->vtable->set_number_native(INTERP, dest,
+   SELF->vtable->get_number(INTERP, SELF) +
 value
 );
 }
@@ -170,7 +171,6 @@
 }

 void add_float (FLOATVAL value, PMC* dest) {
-   dest->vtable = &Parrot_base_vtables[enum_class_PerlNum];
dest->vtable->set_number_native(INTERP, dest,
SELF->vtable->get_number(INTERP, SELF) +
 value
@@ -185,27 +185,28 @@

 void subtract (PMC * value, PMC* dest) {
if(value->vtable == &Parrot_base_vtables[enum_class_PerlInt]) {
-   dest->vtable = &Parrot_base_vtables[enum_class_PerlInt];
-dest->vtable->set_integer_native(INTERP, dest,
-   SELF->vtable->get_integer(INTERP, SELF) -
+dest->vtable->set_number_native(INTERP, dest,
+   SELF->vtable->get_number(INTERP, SELF) -
 value->cache.int_val
 );
}
else if(value->vtable == &Parrot_base_vtables[enum_class_PerlNum]) {
-   dest->vtable = &Parrot_base_vtables[enum_class_PerlNum];
 dest->vtable->set_number_native(INTERP, dest,
SELF->vtable->get_number(INTERP, SELF) -
 value->cache.num_val
 );
}
else {
+dest->vtable->set_number_native(INTERP, dest,
+   SELF->vtable->get_number(INTERP, SELF) -
+value->vtable->get_number(INTERP, value)
+);
}
 }

 void subtract_int (INTVAL value, PMC* dest) {
-   dest->vtable = &Parrot_base_vtables[enum_class_PerlInt];
-dest->vtable->set_integer_native(INTERP, dest,
-   SELF->vtable->get_integer(INTERP, SELF) -
+dest->vtable->set_number_native(INTERP, dest,
+   SELF->vtable

Re: Unary dot

[Allison Randal]

On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
> On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote:
> > > ::m2; # calls global subroutine main::m2
> > > main::m2; # calls global subroutine main::m2
> > 
> > This is looking more and more horrible Glenn.
> I think we need to back off of unmarked subroutines becoming a method 
> call.  

Yeah.

> I like the following, assumed to be within method m1:
> 
> ..m2();  # call m2 the same way m1 was called, instance or class

This has already been semi-rejected. I agree with the reasoning. Not
that it wouldn't be nice to have a way to code the concept, just that
the ".." symbology isn't right for the job.

> $_.m2();   # same thing?  Does the class become the topic in a static method?

If ..m2() were the same as $self.m2(), $_.m2() would only be the same
until you entered the scope of another topicalizer.

> m2() # call subroutine m2 with no arguments, implied or otherwise

Agreed.

Allison

Re: none

[Piers Cawley]

Ashley Winters <[EMAIL PROTECTED]> writes:

>>  Patches welcome.
>
> Excellent...
>
> Forgive any formatting errors, I have mail issues.

Thanks, applying. With a few caveats.

> @@ -62,6 +62,7 @@
>  class SchemePair is SchemeExpr {
>my $nil //= class is SchemeExpr {
>  method is_nil {1}
> +method is_pair {0}
>  method car { fail Exception:
>   msg => "car: expects argument of type , given
> ()" }
>  method cdr { fail Exception:

That change isn't necessary. If you look you'll see that the anonymous
class of which $nil is the only instance is a subclass of SchemeExpr,
not SchemePair.

> @@ -77,12 +78,13 @@
>method car { .value.key }
>method cdr { .value.value }
>method is_pair { 1 }
> +  method is_nil { 0 }

SchemeExpr's AUTOLOAD handles that automagically.

>method AUTOLOAD {
>  .NEXT::AUTOLOAD unless $AUTOLOAD =~ /:?c([ad]+)r$/;
> -my @ops = reverse split '', $1;
> -my $val = $_[0];
> +my @ops = reverse split '', $1;   # $1? Apocalypse 5...
> +my $val = @_[0];

YARGH! I thought I'd got rid of all those 5isms.
>  
>method new_scope($self:) { ref($self).new(__parent__ => $self) }
>  
> -  method bind_primitive($name, &func) {
> -.bind(SchemeSymbol.new($name), 
> -  SchemePrimitive.new( $name => &func ));
> +  method bind_primitive(PAIR @primitives) {
> +for @primitives -> $primitive {
> +  .bind(SchemeSymbol.new($primitive.key), 
> +SchemePrimitive.new( $primitive ));

Hmm... does that declaration syntax work? I really hope so 'cos it's
lovely.


>}
>  
>my method parent { .{__parent__} }
>
>method set($self: SchemeSymbol $key, SchemeExpr $value) {
>  given .exists($key) {
> -  when defined { .value($value) }
> +  when defined { .{key} = $value }

D'oh. Should be C<.{$key}> thought.

> -  '+' => $expr, $context -> {
> +  '+' => -> $expr, $context {

Oops. C *@_ }> anyone?

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Unary dot

[Mark J. Reed]

On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote:
> > I like the following, assumed to be within method m1:
> > 
> > ..m2();# call m2 the same way m1 was called, instance or class
> 
> This has already been semi-rejected. I agree with the reasoning. Not
> that it wouldn't be nice to have a way to code the concept, just that
> the ".." symbology isn't right for the job.
MUA/MTA quoting seems to be getting in the way here - someone's prepending a
'.' to avoid sending the SMTP end-of-message sentinel and it's not getting
stripped off properly.  That was supposed to be a single '.' in front of
the m2().  In other words, unary . is the same as binary . with $_ as
the LHS, so .m2() would be the same as $_.m2(). Which would have the
semantics in my comment above, assuming that the class becomes the topic
in static methods.

-- 
Mark J. REED<[EMAIL PROTECTED]>

Re: Unary dot

[Piers Cawley]

"Mark J. Reed" <[EMAIL PROTECTED]> writes:

> On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote:
>> > ::m2; # calls global subroutine main::m2
>> > main::m2; # calls global subroutine main::m2
>> 
>> This is looking more and more horrible Glenn.
> I think we need to back off of unmarked subroutines becoming a method 
> call.  That one extra '.' in front isn't too much, is it?
>
> I like the following, assumed to be within method m1:
>
> ..m2();  # call m2 the same way m1 was called, instance or class

Can't say I'm keen on that at all. We already have a '..' operator
(admittedly it's binary), and this new, unary .. doesn't really do
anything remotely similar (cf unary dot, unary _ and unary +, which
have behaviours which are obviously related to the binary forms.).

And haven't we done this discussion already?

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

RE: Unary dot

[David Whipp]

Piers Cawley 
> > This may be a case of keep up at the back, but if that is a 
> method call,
> > how do I call a subroutine from within a method ?
> 
> [...]
> 
> Yes, I know there's several different ways I could do it, but this
> approach feels right.

I think this comes does to huffmann encoding: which things are
common, and which are less common. This probably depends on
what you are doing (what paradigm you are following), so its
really a question about the nature of perl.

The things I've heard people wanting to do are:

 call method on current topic
 call method on current invocant
 call class method on invocant's class
 call private subroutine defined in current class
 call global subroutine

The following syntaxes have been seen:

 foo()
 .foo()
 ..foo() ## rejected because ".." is different binary op
 class.foo()
 FooClass.foo()
 ::foo()
 Package::foo()
 $foo()
 $_.foo()

I see 2 partionings:

 * by scope: topic, self, named package, global
 * by invocant: instance, class, none

My suggested resolutions:

By Scope: global/ named package use the existing
Foo::bar syntax; Topic uses unary . syntax; self
uses nothing

By invocant: infer from current invocant/topic; use
&foo() for no invocant

Thus, the perl5 transalations would be:

  foo() => $self->foo()
  .foo() => $_->foo()
  &foo() => foo()
  ::foo() => ::foo()
  Bar::bar() => Bar::bar()

  class.foo() => ref($self)->foo()
  .class.foo() => ref($_)->foo()

  &foo(self) => foo($self->self)
 => $self->self->foo()

This assumes that C and C are defined in
UNIVERSAL


Dave.

Re: Unary dot

[Piers Cawley]

"David Whipp" <[EMAIL PROTECTED]> writes:

> Piers Cawley 
>> > This may be a case of keep up at the back, but if that is a 
>> method call,
>> > how do I call a subroutine from within a method ?
>> 
>> [...]
>> 
>> Yes, I know there's several different ways I could do it, but this
>> approach feels right.
>
> I think this comes does to huffmann encoding: which things are
> common, and which are less common. This probably depends on
> what you are doing (what paradigm you are following), so its
> really a question about the nature of perl.
>
> The things I've heard people wanting to do are:
>
>  call method on current topic
>  call method on current invocant
>  call class method on invocant's class
>  call private subroutine defined in current class
>  call global subroutine
>
> The following syntaxes have been seen:
>
>  foo()
>  .foo()
>  ..foo() ## rejected because ".." is different binary op
>  class.foo()
>  FooClass.foo()
>  ::foo()
>  Package::foo()
>  $foo()
>  $_.foo()
>
> I see 2 partionings:
>
>  * by scope: topic, self, named package, global
>  * by invocant: instance, class, none
>
> My suggested resolutions:
>
> By Scope: global/ named package use the existing
> Foo::bar syntax; Topic uses unary . syntax; self
> uses nothing
>
> By invocant: infer from current invocant/topic; use
> &foo() for no invocant
>
> Thus, the perl5 transalations would be:
>
>   foo() => $self->foo()
>   .foo() => $_->foo()
>   &foo() => foo()
>   ::foo() => ::foo()
>   Bar::bar() => Bar::bar()
>
>   class.foo() => ref($self)->foo()
>   .class.foo() => ref($_)->foo()
>
>   &foo(self) => foo($self->self)
>  => $self->self->foo()
>
> This assumes that C and C are defined in
> UNIVERSAL

For reasons that I can't quite put my finger on at the moment, I
really, really don't like that approach. One of the really nice things
about perl 4 was that we didn't have to use & any more. Making it
essential seems like a horribly retrograde step. I suppose you could
require the & only when calling subroutines from within a method/class
definitions, but I still don't like it.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Unary dot

[Me]

> The following syntaxes have been seen:
> 
>  foo()
>  .foo()
>  ..foo() ## rejected because ".." is different binary op
>  class.foo()
>  FooClass.foo()
>  ::foo()
>  Package::foo()
>  $foo()
>  $_.foo()

With a nod to Piers, and with apologes if this is silly in
the context of Perl 6 syntax, what about:

$.foo

--
ralph

Re: Unary dot

[Allison Randal]

On Wed, Apr 10, 2002 at 03:49:44PM -0400, Mark J. Reed wrote:
> On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote:
> > > I like the following, assumed to be within method m1:
> > > 
> > > ..m2();  # call m2 the same way m1 was called, instance or class
> > 
> > This has already been semi-rejected. I agree with the reasoning. Not
> > that it wouldn't be nice to have a way to code the concept, just that
> > the ".." symbology isn't right for the job.
> MUA/MTA quoting seems to be getting in the way here - someone's prepending a
> '.' to avoid sending the SMTP end-of-message sentinel and it's not getting
> stripped off properly.  That was supposed to be a single '.' in front of
> the m2().  

Then, Agreed.

> In other words, unary . is the same as binary . with $_ as the LHS, so
> .m2() would be the same as $_.m2(). Which would have the semantics in
> my comment above, 

Yes, until you used a C or a C, etc. Then .m2() would be the
same as $_.m2() (at least it would be if we don't make any of the
changes we're talking about), but wouldn't be called the same way m1 was
called, it would be called on the current topic.

> assuming that the class becomes the topic in static methods.

Larry Wall wrote in A4:
> > Any method definition is a topicalizer within the body of the
> > method, and will assume a "given" of its $self object (or whatever
> > you have named it).

I would hope that static methods wouldn't be *too* different from
instance methods.

Allison

Re: I'll show you mine...

[raptor]

great idea :")

I've just tried gnuCash program and think it is very cool  (i've enjoyed to take 
first steps in double-entry accounting, i was always wondering what the hell is this 
:") )...
http://www.ncsysadmin.org/july2001/ncsa-gnucash-talk.html#toc1 
(very entertaining intro :") )

Meanwhile during browsing the docs i found that there was a way to extend the program 
but via Scheme (it had possiblity to be extended via perl at the begining but now not, 
for some their reason !!!). And so I wanted always to learn Prolog & Lisp and so now 
I'm reading the Scheme online book :
http://www.scheme.com/tspl2d/index.html

It looks very cool, so go for it... i hope i will  learn it :")

=
iVAN
[EMAIL PROTECTED]

PS. Before a couple of years I was using happily Windows and one my friend told me 
(arguing constantly ) do u know that Linux is very cool (no matter it used Win 
:")) .. so i got a book and started to learn Linux, i read about awk and started to 
write a report program (parsing IIS,proxy etc.. logs), meanwhile i constantly saw Perl 
examples in the same book, and also precaution that Perl is much more powerfull and 
hard to learn, so be prepared to spend alot of time. so one day i decided this awk 
is cute but what if i try Perl ? And on the third week my program much more 
featurefull was ready :") (up to this time i used only pascal & basic)
The good things always happen acidently .. 
So ... Thank you very much.

Re: Unary dot

[Allison Randal]

On Wed, Apr 10, 2002 at 09:23:23PM +0100, Piers Cawley wrote:
> "David Whipp" <[EMAIL PROTECTED]> writes:
> 
> > Thus, the perl5 transalations would be:
> >
> >   foo() => $self->foo()
> >   .foo() => $_->foo()
> >   &foo() => foo()
> >   ...
> 
> For reasons that I can't quite put my finger on at the moment, I
> really, really don't like that approach. One of the really nice things
> about perl 4 was that we didn't have to use & any more. Making it
> essential seems like a horribly retrograde step. I suppose you could
> require the & only when calling subroutines from within a method/class
> definitions, but I still don't like it.

I agree. It makes an exception where none is needed (&foo() required
instead of foo()) just to re-use the syntax for a less common
construction that could just as easily be represented any number of
other ways.

Allison

Re: Unary dot

[Allison Randal]

> > "David Whipp" <[EMAIL PROTECTED]> writes:
> > 
> > > Thus, the perl5 transalations would be:
> > >
> > >   foo() => $self->foo()
> > >   .foo() => $_->foo()
> > >   &foo() => foo()
> > >   ...

Alternative:

   $self.foo() => $self->foo() # and can be .foo() when $self is $_
   .foo() => $_->foo() # but might be altered by a pragma
   foo() => foo()

Allison

Re: Unary dot

[Luke Palmer]

> > $.foo
> 
> It's already defined as an instance variable.
 
I don't think I like that. Instance variables are far more common that 
class variables, so why not just $foo, and you could  use a compile-time 
property for class variables. Like C as discussed. That or 
C. I think the latter makes more sense.

Or is there some reason this wouldn't work?

Luke

Re: Unary dot

[Damian Conway]

Allison wrote:
> 
> > > "David Whipp" <[EMAIL PROTECTED]> writes:
> > >
> > > > Thus, the perl5 transalations would be:
> > > >
> > > >   foo() => $self->foo()
> > > >   .foo() => $_->foo()
> > > >   &foo() => foo()
> > > >   ...
> 
> Alternative:
> 
>$self.foo() => $self->foo() # and can be .foo() when $self is $_
>.foo() => $_->foo() # but might be altered by a pragma
>foo() => foo()


And welcome back to where we started! ;-)

However, having circumnavigated the alternatives, we now have a better
perspective on the trade-offs and hidden costs.

The original idea of topicalizing the invocant in methods was that it makes
very simple methods even simpler:

method name { .assigned_name // .std_name // "???" }

For anything more complex than "very simple" (i.e. anything with internal
topicalizers), one names the invocant explicitly:

method rank ($self:) {
given ($.status) {
when "covert"   { return "Special operative" }
when "detached" { return "Field operative" }
default { return $self.actual_rank }
}
}

or, if the class has many such methods, implicitly:

use invocant 'invocant'; 

method rank () {
given ($.status) {
when "covert"   { return "Special operative" }
when "detached" { return "Field operative" }
default { return invocant.actual_rank }
}
}

The problem that this discussion has highlighted is that using a
bare .foo in a method means the reader/maintainer has to track what
the current topic is in order to know who the current invocant is.
That would seem to be a (potentially expensive) hidden cost of this idiom.

Reflecting on this, it seems that it would be useful if methods
implicitly did their default topicalization-of-invocant like so:

-> $self

rather than just:

-> $_

That is, that as well as aliasing the invocant to $_, they also alias it
to some standard variable name.

Then one would be guaranteed an invariant name (across all OO Perl!)
for the invocant, even under internal topicalizations.

Of course, the problem is then: what should the name of this topicalizer
variable be? The main options are:

$self
$me
$I
$this
$invocant
$object
$obj

And frankly, that's a very minor issue. Someone (i.e. Larry) should just
pick one and then we can all move on.

Damian

Re: Unary dot

[Allison Randal]

On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote:
> Allison wrote:
> > 
> >$self.foo() => $self->foo() # and can be .foo() when $self is $_
> >.foo() => $_->foo() # but might be altered by a pragma
> >foo() => foo()
> 
> 
> And welcome back to where we started! ;-)
 
Exactly! :)

> The problem that this discussion has highlighted is that using a bare
> .foo in a method means the reader/maintainer has to track what the
> current topic is in order to know who the current invocant is.  That
> would seem to be a (potentially expensive) hidden cost of this idiom.
 
But possibly less expensive than providing a means to default to
something other than topic.

> That is, that as well as aliasing the invocant to $_, they also alias it
> to some standard variable name.
> 
> Then one would be guaranteed an invariant name (across all OO Perl!)
> for the invocant, even under internal topicalizations.
 
I'm in favor of the standardized variable name. It is a restriction, but
not an onerous one. I've never used anything but $self, and I'm sure it
would be easy to adapt to whatever else was chosen. Are there any
statistics availble on current usage of $self vs. $this vs. whatever? It
might be easiest to go with what the majority find most comfortable.

Allison

Non-anchored GC memory?

[Dan Sugalski]

Can anyone think of a good enough reason to allow unanchored GCable 
memory? I can see it being useful for really temporary allocations 
that later get dropped, but that seems horribly error-prone, and I'm 
not sure I want to set us up for tracking down that sort of thing for 
the rest of eternity.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Worst-case GC Behavior?

[Dan Sugalski]

At 9:39 AM +0200 4/9/02, Peter Gibbs wrote:
>One option might be a
>threshold - if, after the DOD run, there is still less than N headers
>available, allocate more even though we can satisfy the immediate
>requirement. This would improve performance by reducing the number of DOD
>runs, but at the cost of additional memory - a classic tradeoff!

Yep.

That's one of the reasons I put the counters into the GC system--I 
expect some sort of feedback system that dynamically modifies the 
allocation quantities for memory and various interpreter structures 
is in order.

Anyone care to write one? :) (I went for the simple and relatively 
naive way to start mainly just to get something done)
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Worst-case GC Behavior?

[Michel J Lambert]

> >One option might be a
> >threshold - if, after the DOD run, there is still less than N headers
> >available, allocate more even though we can satisfy the immediate
> >requirement. This would improve performance by reducing the number of DOD
> >runs, but at the cost of additional memory - a classic tradeoff!
>
> Yep.
>
> That's one of the reasons I put the counters into the GC system--I
> expect some sort of feedback system that dynamically modifies the
> allocation quantities for memory and various interpreter structures
> is in order.
>
> Anyone care to write one? :) (I went for the simple and relatively
> naive way to start mainly just to get something done)

Well, this sounds like it all goes inline with the use less "memory"
pragmas. Should the interface to the GC be raw, low-level vars that this
pragma would manually set? Or should the interface be a high-level
optimize-for-this variable which the GC uses internally?

I believe this discussion has happened before, but no consensus was
reached.

(And no, this isn't me volunteering, at least not yet. ;)

Mike Lambert

Re: Worst-case GC Behavior?

[Dan Sugalski]

At 4:38 PM -0400 4/10/02, Michel J Lambert wrote:
>  > >One option might be a
>>  >threshold - if, after the DOD run, there is still less than N headers
>>  >available, allocate more even though we can satisfy the immediate
>>  >requirement. This would improve performance by reducing the number of DOD
>>  >runs, but at the cost of additional memory - a classic tradeoff!
>>
>>  Yep.
>>
>>  That's one of the reasons I put the counters into the GC system--I
>>  expect some sort of feedback system that dynamically modifies the
>>  allocation quantities for memory and various interpreter structures
>>  is in order.
>>
>>  Anyone care to write one? :) (I went for the simple and relatively
>>  naive way to start mainly just to get something done)
>
>Well, this sounds like it all goes inline with the use less "memory"
>pragmas. Should the interface to the GC be raw, low-level vars that this
>pragma would manually set? Or should the interface be a high-level
>optimize-for-this variable which the GC uses internally?
>
>I believe this discussion has happened before, but no consensus was
>reached.

That was a different discussion. Related, but different. :)

>(And no, this isn't me volunteering, at least not yet. ;)

Oh, sure, duck the decision. :) I'll think on this a bit, and see 
what we might do. Then I'll do it, and we can mock it appropriately 
after.

-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: Non-anchored GC memory?

[Steve Fink]

On Wed, Apr 10, 2002 at 03:52:09PM -0400, Dan Sugalski wrote:
> Can anyone think of a good enough reason to allow unanchored GCable 
> memory? I can see it being useful for really temporary allocations 
> that later get dropped, but that seems horribly error-prone, and I'm 
> not sure I want to set us up for tracking down that sort of thing for 
> the rest of eternity.
> -- 

You know those places where the documentation says "if you call X()
without doing Y, the behavior is undefined"? Well, make X() return a
pointer to unanchored GCable memory in those cases. :-)

I submit for your aproval . . .

[Roman Hunt]

Hey guys:
  Here is what I have so far of the string_nprintf function.  As of now it
 only handles C string backslash escape sequences and regular chars
from the format string.  My primary concern is whether I am using
BUFFER_immobile_FLAG the correct way to protect myself from GC.  I also
dont know if the syntax I am using to convert the format string is
correct (It seems like it should be). adding in the rest is only a matter
of time if this method works {btw, I appologize for not submitting a
complete function but I was concerned that I might be running down the
wrong road and wanted to check }

also  I think
encoding_lookup() should accept an argument of "native".


Roman


Index: string.c
===
RCS file: /cvs/public/parrot/string.c,v
retrieving revision 1.67
diff -u -d -r1.67 string.c
--- string.c9 Apr 2002 03:51:45 -   1.67
+++ string.c10 Apr 2002 22:19:27 -
@@ -801,7 +801,148 @@
 NULL, 0, NULL);
 }
 
+/*=for api string_nprintf
+ * print formated output of len
+ * chars/glyphs to dest, allocating
+ * new string if dest is NULL, and
+ * mimicking sprintf if len == 0.
+ */
+
+
+STRING* 
+string_nprintf(struct Parrot_Interp *interpreter, STRING* dest, UINTVAL len, const 
+char *format, ...)
+{
+va_list ap;
+va_start(ap, format);
+
+if(!dest)
+dest = string_make(interpreter, NULL, len, NULL, 0, NULL);
+
+return (string_vnprintf(interpreter, dest, len, format, ap));
+}
+
+/* for previous function */
+STRING*
+string_vnprintf(struct Parrot_Interp *interpreter, STRING* dest, UINTVAL len, const 
+char *format, va_list ap)
+{
+STRING *b_trans;
+STRING *temp_str;
+STRING** destp;
 
+
+INTVAL grow_total;
+
+unsigned char sprintf_emu, transcode;
+char c, *cp;
+
+transcode = 0;
+sprintf_emu = (len ? 0 : 1);
+grow_total = (sprintf_emu ? 0 : len);
+
+destp = &dest;
+cp = &c;
+
+temp_str = string_make(interpreter, NULL, 0, dest->encoding, 
+BUFFER_immobile_FLAG, dest->type);
+
+/* test for native */
+if(dest->encoding != encoding_lookup("singlebyte"))
+transcode = 1;
+
+for (; *format ; ++format) {
+/* print reg reg chars */
+if (*format != '\\' && *format != '%') {
+if (sprintf_emu)
+++grow_total;
+if (sprintf_emu || (len-- != 0)) {
+b_trans = string_make(interpreter, format, 1, NULL,
+  BUFFER_immobile_FLAG, NULL);
+(void)string_concat(interpreter, temp_str, b_trans, transcode);
+string_destroy(b_trans);
+}
+}
+else if (*(format++) == '\\') {
+if (sprintf_emu)
+++grow_total;
+if (*format == 'n') {
+c = '\n';
+if (sprintf_emu || (len-- != 0)) {
+b_trans = string_make(interpreter, cp, 1, NULL,
+  BUFFER_immobile_FLAG, NULL);
+(void)string_concat(interpreter, temp_str, b_trans,
+transcode);
+string_destroy(b_trans);
+}
+}
+else if (*format == '\\') {
+c = '\\';
+if (sprintf_emu || (len-- != 0)) {
+b_trans = string_make(interpreter, cp, 1, NULL,
+  BUFFER_immobile_FLAG, NULL);
+(void)string_concat(interpreter, temp_str, b_trans,
+transcode);
+string_destroy(b_trans);
+}
+}
+else if (*format == 'r') {
+c = '\r';
+if (sprintf_emu || (len-- != 0)) {
+b_trans = string_make(interpreter, cp, 1, NULL,
+  BUFFER_immobile_FLAG, NULL);
+(void)string_concat(interpreter, temp_str, b_trans,
+transcode);
+string_destroy(b_trans);
+}
+}
+else if (*format == 'a') {
+c = '\a';
+if (sprintf_emu || (len-- != 0)) {
+b_trans = string_make(interpreter, cp, 1, NULL,
+  BUFFER_immobile_FLAG, NULL);
+(void)string_concat(interpreter, temp_str, b_trans,
+transcode);
+string_destroy(b_trans);
+}
+}
+else if (*format == 't') {
+c = '\t';
+if (sprintf_emu || (len-- != 0)) {
+b_trans = string_make(interpreter, cp,

Re: I submit for your aproval . . .

[Dan Sugalski]

At 6:29 PM -0400 4/10/02, Roman Hunt wrote:
>Hey guys:
>   Here is what I have so far of the string_nprintf function.  As of now it
>  only handles C string backslash escape sequences and regular chars
>from the format string.  My primary concern is whether I am using
>BUFFER_immobile_FLAG the correct way to protect myself from GC.  I also
>dont know if the syntax I am using to convert the format string is
>correct (It seems like it should be). adding in the rest is only a matter
>of time if this method works {btw, I appologize for not submitting a
>complete function but I was concerned that I might be running down the
>wrong road and wanted to check }

I've not poked around at it much, but out of curiosity does this do 
something that the sprintf functions in misc.c don't do?

>also  I think
>encoding_lookup() should accept an argument of "native".

Good point, they should. OTOH, that makes some of this interesting, 
since which characters you use for various things depend on the 
encoding and charset.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

Re: I submit for your aproval . . .

[Tom Hughes]

In message 
  Dan Sugalski <[EMAIL PROTECTED]> wrote:

> At 6:29 PM -0400 4/10/02, Roman Hunt wrote:
> 
> >also  I think
> >encoding_lookup() should accept an argument of "native".
> 
> Good point, they should. OTOH, that makes some of this interesting,
> since which characters you use for various things depend on the
> encoding and charset.

We already have string_native_type which points to the CHARTYPE structure
for the native character type and that structure includes default_encoding
which is the name of the default encoding for the native character type.

I guess string_init could also set up string_native_encoding by looking
up the name of the default encoding for the native character type.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

Re: Unary dot

[Melvin Smith]

At 07:40 PM 4/10/2002 +0100, Piers Cawley wrote:
>Melvin Smith <[EMAIL PROTECTED]> writes:
>
> > At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
> >>"Mark J. Reed" wrote:
> >> >
> >> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> >> > > method m1
> >> > > {
> >> > >m2;  # calls method m2 in the same class
> >> > Yes, but does it call it as an instance method on the current invocant
> >> > or as a class method with no invocant?  If the former, how would you
> >> > do the latter?
> >>
> >>Should both be allowed to exist?  Do both exist?  Why do both exist?
> >>(with the same name).  If only one exists, then that would be the one
> >>that gets called.
> >
> > I'd hope it would assume "instance" method until told otherwise,
> > since static methods (class methods) are seldom used in OOP.
>
>Um... don't you use factory methods? I know I do.

Sure I do, but it doesn't comprise more than 5% of the methods I call
on objects. And in C++ or Java, when I need a class method, I
specify it with the keyword 'static'. Along with it comes the restrictions
of not accessing instance data, etc. etc.

I will admit my applied usage of OOP is biased by the C++/Java
lense. :)

While I may be misunderstanding Perl6 syntax, I'm not misunderstanding
OOP, these are basic concepts to C++ and Java and how many
other languages; granted, I'll try to play catchup with reading the Apocs and
Exegeses over, but it appears from the discussion thread that people
are discussing class/instance method mixing as if this were a new
concept to OOP. My feeling is you ask yourself: "What makes sense and what
does the compiler and runtime engine have to do based on the given
rules that we choose".

Its clear if invocant of foo() is the class, and not the instance, calling
an instance method from class scope without creating an object to work
with should either be disallowed, or analyzed to check whether it actually uses
instance data. I'd choose former which is what C++ and Java does.

-Melvin

Re: Unary dot

[Melvin Smith]

At 07:54 PM 4/10/2002 +0100, Piers Cawley wrote:
>Graham Barr <[EMAIL PROTECTED]> writes:
>
> > On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
> >> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
> >> > method m1
> >> > {
> >> >m2;  # calls method m2 in the same class
> >> Yes, but does it call it as an instance method on the current invocant
> >> or as a class method with no invocant?  If the former, how would you
> >> do the latter?
> >
> > This may be a case of keep up at the back, but if that is a method call,
> > how do I call a subroutine from within a method ?
>
>And anyone who says "You don't" will receive a good hard talking to
>from me. Being able to declare private subroutines within classes is
>really useful, witness:
>
> class SchemeNumber is SchemeExpr {
>   my sub apply($self: $target, $rhs, &block) {
> if $is_rhs { $self.new(+ &block( $target, $self.value )) }
> else   { $self.new(+ &block( $self.value, $target )) }
>   }
>
>   method operator:+ { apply(*@_, {$^a + $^b}) }
>   method operator:* { apply(*@_, {$^a * $^b}) }
>   method operator:- { apply(*@_, {$^a * $^b}) }
>   method operator:/ { apply(*@_, {$^a * $^b}) }
>
>   method is_number { 1 }
> }
>
>Yes, I know there's several different ways I could do it, but this
>approach feels right.

I agree, however you passed in the invocant so there is no
ambiguity in your case.

Calling a class method off of an object, I've found use for.
Calling an instance method from a class invocant scope doesn't
make sense to me which is what I _think_ Graham's example
was implying.

I suppose this would be akin to:

if(typeof(self) is 'class') {
...
}
else {  # instance
...
}

I think that would be just plain bad design, but I'd be happy if someone
showed me a use for it. :)

-Melvin

Re: Unary dot

[Melvin Smith]

At 08:04 AM 4/11/2002 +1000, Damian Conway wrote:
>And welcome back to where we started! ;-)

Wow there is a lot of blood on the ground here. Must have been messy... :)

>Of course, the problem is then: what should the name of this topicalizer
>variable be? The main options are:
>
> $self
> $me
> $I
> $this
> $invocant
> $object
> $obj
>
>And frankly, that's a very minor issue. Someone (i.e. Larry) should just
>pick one and then we can all move on.

I'm waiting for Larry to say, "We have decided to use $me, $myself and $i.

-Melvin

RE: Unary dot

[David Whipp]

Melvin Smith wrote
> I think that would be just plain bad design, but I'd be happy 
> if someone showed me a use for it. :)

well, I've been known to do

  sub UNIVERSAL::debug
  {
my $self = shift;
my $msg = "@_";
eval {$self=$self->name} if ref($self);
my $timestamp = ...;
my $caller = ...;
print "DEBUG [$timestamp] '$self' $caller: $msg\n";
  }

  sub UNIVERSAL::debugf { shift->debug(sprintf @_) }

which can then be called as:

  $class->debug("hello");

or

  $self->debugf("world, %d", 42);

or even

  hello->debug(world);


You are right. This is just plain bad design. But it can be useful.


Dave.

Defaulting params

[Miko O'Sullivan]

The current plans indicate that a subroutine's params should be defaulted
like this:

   sub load_data ($filename ; $version / /= 1) {...}

(The space between / and / is on purpose, my emailer has problems if they
are together.)  If that's the technique, how does the caller indicate that
the second param is *supposed* to be undef?  If I were to call a sub like
this:

  load_data ($filename, undef);

then I would expect that means that I am explicitly saying the second
argument is supposed to be undef.  However, if I call it like this:

  load_data ($filename);

then I'm not sending the second param and it can be whatever the default is.
Ergo, I propose that / /= and simply = are both allowed and mean slightly
different things:

   # $version is 1 if the second param isn't sent at all
   sub load_data ($filename ; $version = 1) {...}

   # $version is 1 if the second param is undef
   sub load_data ($filename ; $version / /= 1) {...}

(Yes, this is a repeat of an earlier suggestion.  It was suggested I might
repost reworded.)

-Miko

Re: Unary dot

[Allison Randal]

On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote:
> 
> Reflecting on this, it seems that it would be useful if methods
> implicitly did their default topicalization-of-invocant like so:
> 
>   -> $self
> 
> rather than just:
> 
>   -> $_
> 
> That is, that as well as aliasing the invocant to $_, they also alias it
> to some standard variable name.
> 
> Then one would be guaranteed an invariant name (across all OO Perl!)
> for the invocant, even under internal topicalizations.

H... this being the case, is there any reason we should ever need to
name the invocant explicitly? If Perl has already provided a named alias
implicitly, why specify redundant information when other parameters
follow? Leave the parameter lists for parameters that change from method
to method, not for the one that will always be there.

You get short parameter lists, and a truly invariant name for the
invocant.

method foo ($bar, $baz) {
$self.boo; # $self always exists in a method
}

There's no conflict with Perl 5 since C is a new keyword.

Also, the invocant pragma becomes unnecessary if you can always access
the current object via $self (or $this, or $me, or whatever, as long as
it's not $invocant ;).

My, my, my, I *am* playing the devil's advocate today. :)

Allison

Re: Unary dot

[Damian Conway]

Allison Randal wrote:

> H... this being the case, is there any reason we should ever need to
> name the invocant explicitly?

Yes. To make it read-writable. 

Perl makes that much easier than most other languages, because you can pass
the invocant by (writable) reference, so you don't need to pass a separate
$parent pointer:

method Tree::delete(Tree $self is rw:) {
if $.left_child {
$.left_child.insert($.right_child) if $.right_child;
$self = $.left_child
}
elsif $.right_child {
$self = $.right_child
}
$.right_child = $.left_child = undef;
}

Damian

Re: Unary dot

[Allison Randal]

On Thu, Apr 11, 2002 at 12:01:58PM +1000, Damian Conway wrote:
> Allison Randal wrote:
> 
> > H... this being the case, is there any reason we should ever need to
> > name the invocant explicitly?
> 
> Yes. To make it read-writable. 
 
Curses! Foiled again! :)

> Perl makes that much easier than most other languages, because you can pass
> the invocant by (writable) reference, so you don't need to pass a separate
> $parent pointer:

Devil's advocate role aside, that is a very cool feature. Another thing
you would lose is the ability to rename the parameter if you wanted (you
could use assignment or binding, but it would be infinitely ugly).

Allison

Re: Unary dot

[Melvin Smith]

At 04:01 PM 4/10/2002 -0600, Luke Palmer wrote:
> > > $.foo
> >
> > It's already defined as an instance variable.
>
>I don't think I like that. Instance variables are far more common that
>class variables, so why not just $foo, and you could  use a compile-time
>property for class variables. Like C as discussed. That or
>C. I think the latter makes more sense.
>
>Or is there some reason this wouldn't work?

I totally agree here. The common case is going to make code
look ugly with $.foo everywhere. Please don't let this come into being. :(

I think it is arguable that a closure is a class for a subroutine object,
and in subs we will still use my $foo for lexicals. However we must
remember in class scope to use $.foo for the default, instance variable,
and a normal $foo for the less typical static or class variables.

Yucky.

Reserve the ugly syntax for the less common case.
Plase.

-Melvin

Re: Patches, patches, patches...

[Bryan C. Warnock]

On Wednesday 10 April 2002 12:53 pm, Melvin Smith wrote:
> I think there is at least one outstanding patch from Brian Warnock called:
> "stacks.c"

Hmmm, looking in my outbox, I see only one recent patch of mine
that mentions stacks.c, and its been applied.  (Although I don't know when.  
It could have been applied recently.)

Did I sneak one in somewhere else that I can't find?

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Patches, patches, patches...

[Melvin Smith]

At 10:40 PM 4/10/2002 -0400, Bryan C. Warnock wrote:
>On Wednesday 10 April 2002 12:53 pm, Melvin Smith wrote:
> > I think there is at least one outstanding patch from Brian Warnock called:
> > "stacks.c"
>
>Hmmm, looking in my outbox, I see only one recent patch of mine
>that mentions stacks.c, and its been applied.  (Although I don't know when.
>It could have been applied recently.)
>
>Did I sneak one in somewhere else that I can't find?

I checked, I see a resources.c on the same date but non other, so
I was the one that missed it. I just didn't want it to be forgotten and
was too lazy to check the cvs log.

-Melvin

What I'm working on before I go offline for 2 weeks

[Melvin Smith]

I'm getting married Saturday and going on honeymoon for 10 days.
So I'll just update you guys on what I'm working on just in case I
fall of the face of the earth for the next 2 weeks, I have a lot of
unflushed stuff.

Parrot:
1) Porting to WinCE for PocketPC
The first cut will be posted as a link where we can see what
 was required to get it to work, then we can systematically apply it
 to the up to date snapshot in an orderly approach.
2) A networking layer for the IO system. (compiles on Linux/Solaris and
Win32 for now, should be done on CE soon.)
3) Going to fixup the IO system to be more Parrot like, including stringifying
and making a real PMC out the PIO object.
Dan I did send you an initial PDD for IO which you acknowledged but 
then
I think you ate it. Still need lots of discussion on the async 
stuff but I think
everyone is busy enough to put async off for a while more.

Cola:
1) A redesign of the intermediate code generator and support for real
   classes, namespaces and arrays on any supported Parrot type.
2) Working on an accurate C# grammar to replace the toy one I have now.
  I think the feedback from the compiler will be invaluable as we develop
  the assembler and bytecode format to support non-Perl type of languages.

These are all at various stages, I've been overwhelmed by the wedding
planning + job and have been lucky just to get in an hour a day. When I get
back I'll hit the ground running.

I'm also chipping away at a certain unnamed company to donate an AIX box
for official testbed, and possibly contribute otherwise to the project, this
will likely take a while though.

Lastly, as I promised Brent, I have a Sun Sparc Ultra10 that I'm going to
open up to any developer that is trusted with CVS access, for those less
fortunate who do not have access to anything besides Windows and/or Linux.

Thanks guys, you are all a great team to work with and I am proud to
learn from people more intelligent than I; and I think Parrot is coming
right along. :)

-Melvin

Re: Unary dot

[Piers Cawley]

Damian Conway <[EMAIL PROTECTED]> writes:

[...]

> Reflecting on this, it seems that it would be useful if methods
> implicitly did their default topicalization-of-invocant like so:
>
>   -> $self
>
> rather than just:
>
>   -> $_
>
> That is, that as well as aliasing the invocant to $_, they also alias it
> to some standard variable name.
>
> Then one would be guaranteed an invariant name (across all OO Perl!)
> for the invocant, even under internal topicalizations.
>
> Of course, the problem is then: what should the name of this topicalizer
> variable be? The main options are:
>
>   $self
>   $me
>   $I
>   $this
>   $invocant
>   $object
>   $obj
>
> And frankly, that's a very minor issue. Someone (i.e. Larry) should just
> pick one and then we can all move on.

Nailing my colours to the mast here, I choose '$self'. I will confess
to suggesting the C syntax not because I
thought it was a desperately good idea, but because I didn't want to
get into arguing about what colour to paint the bikeshed before we'd
actually decided whether or not to build the bikeshed in the first
place.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Unary dot

[Piers Cawley]

Luke Palmer <[EMAIL PROTECTED]> writes:

>> > $.foo
>> 
>> It's already defined as an instance variable.
>  
> I don't think I like that. Instance variables are far more common that 
> class variables, so why not just $foo, and you could  use a compile-time 
> property for class variables. Like C as discussed. That or 
> C. I think the latter makes more sense.

Ah, but I think the mnemonic value of the '.' more than earns its keep
here. C is doing a slightly different job
anyway. And instance variables are *not* the same as 'normal'
variables, they hang off a different symbol table (or syte, to use
Damian's oh so clever term from Perl 5+i) and I'm all for things that
are different *looking* different.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Defaulting params

[Piers Cawley]

"Miko O'Sullivan" <[EMAIL PROTECTED]> writes:
> The current plans indicate that a subroutine's params should be defaulted
> like this:
>
>sub load_data ($filename ; $version / /= 1) {...}
>
> (The space between / and / is on purpose, my emailer has problems if
> they are together.)  If that's the technique, how does the caller
> indicate that the second param is *supposed* to be undef?  If I were
> to call a sub like this:
>
>   load_data ($filename, undef);
>
> then I would expect that means that I am explicitly saying the
> second argument is supposed to be undef.  However, if I call it like
> this:
>
>   load_data ($filename);
>
> then I'm not sending the second param and it can be whatever the
> default is.  Ergo, I propose that / /= and simply = are both allowed
> and mean slightly different things:
>
># $version is 1 if the second param isn't sent at all
>sub load_data ($filename ; $version = 1) {...}
>
># $version is 1 if the second param is undef
>sub load_data ($filename ; $version / /= 1) {...}
>
> (Yes, this is a repeat of an earlier suggestion.  It was suggested I might
> repost reworded.)

I think you're right that this is a valid distinction, I'm just not
sure if it's not a little too subtle and that the two different
notations won't cause confusion. I *think* that the //= case is going
to be the more common one, and one could always handle the first case
more explicitly by doing:

   sub load_data ($filename; $version) {
  $version = 1 if @_.length < 2;
  ...
   }

Yes, it is undoubtedly uglier, but I don't think it's a common enough
case that that worries me.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Unary dot

[Luke Palmer]

> Ah, but I think the mnemonic value of the '.' more than earns its keep
> here. C is doing a slightly different job
> anyway. And instance variables are *not* the same as 'normal'
> variables, they hang off a different symbol table (or syte, to use
> Damian's oh so clever term from Perl 5+i) and I'm all for things that
> are different *looking* different.
> 

Well, I certainly don't like the aesthetic value of them. They are ugly 
as Perl 4. But, I have been caught in C++ making all my private variables 
_named _like _this, so I suppose it's analogous. But I don't like being 
forced to do it that way.

What if you just want a simple struct-like thing? That's when it becomes 
really ugly and dislikable. Erm... wait a minute, how would you do that?

$foo = new Foo;
$foo..instancevar = 7;

I doubt that's it.

$foo.instancevar = 7;

And that's unclear, if we refer to it as $.instancevar inside the 
function. Or, actually, I do think it's clear.

Wow, I was arguing my point and I came to like the syntax. Hmm Ok, 
take your once-ugly syntax and run with it! I understand it now.

Luke

Re: Defaulting params

[Luke Palmer]

On Thu, 11 Apr 2002, Piers Cawley wrote:

> "Miko O'Sullivan" <[EMAIL PROTECTED]> writes:
> > The current plans indicate that a subroutine's params should be defaulted
> > like this:
> >
> >sub load_data ($filename ; $version / /= 1) {...}
> >
> > (The space between / and / is on purpose, my emailer has problems if
> > they are together.)  If that's the technique, how does the caller
> > indicate that the second param is *supposed* to be undef?  If I were
> > to call a sub like this:
> >
> >   load_data ($filename, undef);
> >
> > then I would expect that means that I am explicitly saying the
> > second argument is supposed to be undef.  However, if I call it like
> > this:
> >
> >   load_data ($filename);
> >
> > then I'm not sending the second param and it can be whatever the
> > default is.  Ergo, I propose that / /= and simply = are both allowed
> > and mean slightly different things:
> >
> ># $version is 1 if the second param isn't sent at all
> >sub load_data ($filename ; $version = 1) {...}
> >
> ># $version is 1 if the second param is undef
> >sub load_data ($filename ; $version / /= 1) {...}
> >
> > (Yes, this is a repeat of an earlier suggestion.  It was suggested I might
> > repost reworded.)
> 
> I think you're right that this is a valid distinction, I'm just not
> sure if it's not a little too subtle and that the two different
> notations won't cause confusion. I *think* that the //= case is going
> to be the more common one, and one could always handle the first case
> more explicitly by doing:
> 
>sub load_data ($filename; $version) {
>   $version = 1 if @_.length < 2;
>   ...
>}
> 
> Yes, it is undoubtedly uglier, but I don't think it's a common enough
> case that that worries me.

Indeed, and with the //= thing, you can let parameters in the middle 
default. The only other language that lets you do that is VB, and I 
actually kinda liked it. (Not insinuating that VB is actually a language 
or anything...)

Luke

Re: Defaulting params

[Damian Conway]

Piers wrote:

> one could always handle the first case
> more explicitly by doing:
> 
>sub load_data ($filename; $version) {
>   $version = 1 if @_.length < 2;
>   ...
>}

Err...no. If you specify named parameters, you don't get @_.

It could be handled by overloading though:

sub load_data ($filename) { load_data($filename, 1) }

sub load_data ($filename, $version) {...}

Damian

Re: Defaulting params

[Piers Cawley]

Damian Conway <[EMAIL PROTECTED]> writes:

> Piers wrote:
>
>> one could always handle the first case
>> more explicitly by doing:
>> 
>>sub load_data ($filename; $version) {
>>   $version = 1 if @_.length < 2;
>>   ...
>>}
>
> Err...no. If you specify named parameters, you don't get @_.
>
> It could be handled by overloading though:
>
>   sub load_data ($filename) { load_data($filename, 1) }
>
>   sub load_data ($filename, $version) {...}

Ooh. Multiple dispatch is definitely in then? Did I miss something?
But *great*.

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

Re: Defaulting params

[Damian Conway]

> Ooh. Multiple dispatch is definitely in then?

Not definite yet. That was a subjunctive "could". ;-)

But I'm very hopeful, since it's hard to user-implement things like
C unless you can give a subroutine several distinct signatures.


Damian