Re: $^a, $^b, and friends
Larry Wall wrote in perl.perl6.language :
>
> Such a grammar switching routine could operate either over a lexical
> scope or over the rest of the file. The only restriction is that
> one module not clobber the grammar of a different module.
>
> Basically, we're trying to make the opposite mistake of the one
> we made with source filters. :-)
I see that. But should it be possible to import grammar rules,
to allow :
use Some::Module::That::Modifies::A::Grammar::Rule;
# continue to parse the perl program with the modified grammar
or even :
{
use Some::Module::That::Modifies::A::Grammar::Rule;
# continue to parse the block with the modified grammar
}
And what about switching to a different or modified tokenizer ?
Re: Tail Recursion optimization
> : Piers Cawley writes:
> :
> : So, here I am working on a Scheme interpreter in Perl 6, and I'm
> : trying to write it in a (for want of a better description)
> : 'Scheme-like' fashion with lots of recursion.
> :
> : The trouble is, unless Perl6 is going to be guaranteed to do
> : optimization of tail calls, this is going to lead to horribly slow
> : code. So, do I bite the bullet and recast some of the functions in an
> : iterative vein, or do I trust that Perl6 will do tail call optimization?
> :
> : Larry?
>
> Larry Wall responds:
>
> Why not? The only casualty is caller()'s semantics, and I think we
> can live with that, or disable the optimization on routines that use
> caller().
Carp.pm is implemented with caller(), does that mean:
sub forever {
my $depth = shift;
croak "I got bored"
if $depth == 1000;
forever($depth + 1);
}
will have its optimizations disabled? Or is that fair game; considering you have to
play a little
more intimately with Carp to croak from the right place?
Mental note:
1. Don't use recursion in Perl, it'll be much slower than an iterative approach
2. If in doubt, refer to note 1.
Jonathan Paton
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: Tail Recursion optimization
"Jonathan E. Paton" <[EMAIL PROTECTED]> writes:
>> : Piers Cawley writes:
>> :
>> : So, here I am working on a Scheme interpreter in Perl 6, and I'm
>> : trying to write it in a (for want of a better description)
>> : 'Scheme-like' fashion with lots of recursion.
>> :
>> : The trouble is, unless Perl6 is going to be guaranteed to do
>> : optimization of tail calls, this is going to lead to horribly slow
>> : code. So, do I bite the bullet and recast some of the functions in an
>> : iterative vein, or do I trust that Perl6 will do tail call optimization?
>> :
>> : Larry?
>>
>> Larry Wall responds:
>>
>> Why not? The only casualty is caller()'s semantics, and I think we
>> can live with that, or disable the optimization on routines that use
>> caller().
>
> Carp.pm is implemented with caller(), does that mean:
>
> sub forever {
> my $depth = shift;
>
> croak "I got bored"
> if $depth == 1000;
>
> forever($depth + 1);
> }
>
> will have its optimizations disabled? Or is that fair game;
> considering you have to play a little more intimately with Carp to
> croak from the right place?
Hmm... I'd hope croak would do the right thing without having to break
the tail call optimization. Personally, I think the best bet is to
alter caller's semantics slightly (in fact I think that the
optimization will make it more likely that caller(1) will return the
right thing.)
> Mental note:
>
> 1. Don't use recursion in Perl, it'll be much slower than an
>iterative approach
> 2. If in doubt, refer to note 1.
Certainly will be slower in Perl 5. Hopefully what won't be the case
in Perl 6 (having had to recast code from tail recursive form
explicitly iterative form, I'd really rather not have to do that in
the general case.)
--
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: Tail Recursion optimization
> >> : Piers Cawley writes:
> >> : ...
> >> : The trouble is, unless Perl6 is going to be guaranteed to do
> >> : optimization of tail calls, this is going to lead to horribly slow
> >> : code. So, do I bite the bullet and recast some of the functions in an
> >> : iterative vein, or do I trust that Perl6 will do tail call optimization?
> >> :
> >> : Larry?
> >>
> >> Larry Wall responds:
> >>
> >> Why not? The only casualty is caller()'s semantics, and I think we
> >> can live with that, or disable the optimization on routines that use
> >> caller().
Anything that touches string evaluation (Perl5's eval"") could harbour
caller(), this wouldn't matter unless there was a way to proprogate
exceptions out of an eval"" - and I bet someone already has the
appropriate RPC written.
=head Taking of pragmas...
I spotted another ape returning values from functions using package
globals. Can we have another strict type:
use strict 'asylum';
should stop programmers trying that one ;-)
=cut
> > Carp.pm is implemented with caller(), does that mean:
> >
> > sub forever {
> > my $depth = shift;
> >
> > croak "I got bored"
> > if $depth == 1000;
> >
> > forever($depth + 1);
> > }
> >
> > will have its optimizations disabled? Or is that fair game;
> > considering you have to play a little more intimately with Carp to
> > croak from the right place?
>
> Hmm... I'd hope croak would do the right thing without having to break
> the tail call optimization. Personally, I think the best bet is to
> alter caller's semantics slightly (in fact I think that the
> optimization will make it more likely that caller(1) will return the
> right thing.)
And all eyes are now on Larry...
> > Mental note:
> >
> > 1. Don't use recursion in Perl, it'll be much slower than an
> >iterative approach
> > 2. If in doubt, refer to note 1.
>
> Certainly will be slower in Perl 5. Hopefully what won't be the case
> in Perl 6 (having had to recast code from tail recursive form
> explicitly iterative form, I'd really rather not have to do that in
> the general case.)
Will function calls be faster in Perl 6, in general? Using a simple
benchmark, an empty subroutine called with no arguments took around
1500 machine cycles to execute on Perl 5. Surely a nice new JIT and
better VM should make function calls less expensive, tight loops in
general are a bad idea in Perl 5 - no inlining.
Jonathan Paton
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: $^a, $^b, and friends
At 2:34 PM -0700 4/5/02, Luke Palmer wrote: > > You can do anything you like if you mess with the parser. Changing >> the rules for recognizing an identifier would be trivial. > >Does this refer to messing with the parser... compile time (that is, when >Perl compiles, not when Perl is compiled)? Or are you actually talking >about screwing with the Perl source? That'd sure be cool (albeit a little >weird) to change parsing rules at compile time. Don't forget, we already change parsing rules at compile time. Perl's got three (maybe four) different sets of rules as it is: *) Normal perl *) Regexes *) Double-quoted strings *) Single-quoted strings Adding another, or changing those, isn't a big deal. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tail Recursion optimization
At 11:45 PM +0100 4/5/02, Piers Cawley wrote: >So, here I am working on a Scheme interpreter in Perl 6, and I'm >trying to write it in a (for want of a better description) >'Scheme-like' fashion with lots of recursion. > >The trouble is, unless Perl6 is going to be guaranteed to do >optimization of tail calls, this is going to lead to horribly slow >code. So, do I bite the bullet and recast some of the functions in an >iterative vein, or do I trust that Perl6 will do tail call optimization? If you don't mind emitting bytecode directly, Parrot's calling conventions are such that tail calls and tail recursion works OK. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Questions about private variables
Piers Cawley writes: : Um... there'd be a syntax error before that. "\\=" should be "//=" surely? The //= operator is spelled \\= on Windows. ;-) Larry
Re: $^a, $^b, and friends
Rafael Garcia-Suarez writes:
: Larry Wall wrote in perl.perl6.language :
: >
: > Such a grammar switching routine could operate either over a lexical
: > scope or over the rest of the file. The only restriction is that
: > one module not clobber the grammar of a different module.
: >
: > Basically, we're trying to make the opposite mistake of the one
: > we made with source filters. :-)
:
: I see that. But should it be possible to import grammar rules,
: to allow :
:
: use Some::Module::That::Modifies::A::Grammar::Rule;
: # continue to parse the perl program with the modified grammar
:
: or even :
: {
: use Some::Module::That::Modifies::A::Grammar::Rule;
: # continue to parse the block with the modified grammar
: }
Well, it's kind of klunky to do an import every time. More likely
you'd import a special subroutine once that you can use like this:
Java {
whatsit.blorf.unnecessary.bletch.extra.something.whatever(1);
}
Perl 5 is restricted to doing compile-time actions using BEGIN or use.
In Perl 6 there will be some way of marking a normal subroutine as as
grammatically active, so that it's called immediately, even before its
arguments are parsed. Our hypothetical Java subroutine above could
switch to a Java grammar, parse its block, and then restore the Perl
grammar at the end.
: And what about switching to a different or modified tokenizer ?
It's not clear that the lexer is a separate entity any more. Lexers
were originally invented as a way of abstracting out part of the
grammar so that it could be done in a separate pass, and to simplify
the grammar for the poor overworked parser. But you can write a
grammar for an identifier just about as easily as for an if-then-else.
More easily, if we're basing it on regexes. If we're viewing all
grammar through the lens of regexes, we're really starting out closer
to Lexerland anyway, and generalizing toward parsing, a traditionally
weaker area for Perl. And that's an odd weakness for a text
processing language.
Larry
Re: Tail Recursion optimization
=?iso-8859-1?q?Jonathan=20E.=20Paton?= writes:
: > : Piers Cawley writes:
: > :
: > : So, here I am working on a Scheme interpreter in Perl 6, and I'm
: > : trying to write it in a (for want of a better description)
: > : 'Scheme-like' fashion with lots of recursion.
: > :
: > : The trouble is, unless Perl6 is going to be guaranteed to do
: > : optimization of tail calls, this is going to lead to horribly slow
: > : code. So, do I bite the bullet and recast some of the functions in an
: > : iterative vein, or do I trust that Perl6 will do tail call optimization?
: > :
: > : Larry?
: >
: > Larry Wall responds:
: >
: > Why not? The only casualty is caller()'s semantics, and I think we
: > can live with that, or disable the optimization on routines that use
: > caller().
:
: Carp.pm is implemented with caller(), does that mean:
:
: sub forever {
: my $depth = shift;
:
: croak "I got bored"
: if $depth == 1000;
:
: forever($depth + 1);
: }
:
: will have its optimizations disabled? Or is that fair game; considering you have to
:play a little
: more intimately with Carp to croak from the right place?
No, I don't thing calling something that uses caller should disable the
optimization. In fact, considering what croak uses caller for, it
would only make croak all the more efficient. croak uses caller to
search backward for who called into forever() in the first place, so
chopping out the recursion cuts its work down from O(n) to O(1).
: Mental note:
:
: 1. Don't use recursion in Perl, it'll be much slower than an iterative approach
: 2. If in doubt, refer to note 1.
Recursion is beautiful, but computers don't really grok beauty.
Larry
Re: Tail Recursion optimization
=?iso-8859-1?q?Jonathan=20E.=20Paton?= writes:
: Anything that touches string evaluation (Perl5's eval"") could harbour
: caller(), this wouldn't matter unless there was a way to proprogate
: exceptions out of an eval"" - and I bet someone already has the
: appropriate RPC written.
Well, eval pessimizes a number of possible optimizations, but I don't
think it really needs to pessimize this one. Many uses of caller would
tend to appreciate not having to deal with recursion anyway. The only
possible exception I can think of is doing a stack trace in the debugger,
and most people would prefer to have the recursion compressed there
as well, I imagine. Maybe if tail recursion under the debugger was
smart enough to keep track of how deep the recursion was, that'd be
useful. But tail recursion tends to be data driven, so examining the
current arguments to the routine would typically tell the debuggor
how deep the recursion is even without the explicit count.
: =head Taking of pragmas...
:
: I spotted another ape returning values from functions using package
: globals. Can we have another strict type:
:
: use strict 'asylum';
:
: should stop programmers trying that one ;-)
:
: =cut
:
: > > Carp.pm is implemented with caller(), does that mean:
: > >
: > > sub forever {
: > > my $depth = shift;
: > >
: > > croak "I got bored"
: > > if $depth == 1000;
: > >
: > > forever($depth + 1);
: > > }
: > >
: > > will have its optimizations disabled? Or is that fair game;
: > > considering you have to play a little more intimately with Carp to
: > > croak from the right place?
: >
: > Hmm... I'd hope croak would do the right thing without having to break
: > the tail call optimization. Personally, I think the best bet is to
: > alter caller's semantics slightly (in fact I think that the
: > optimization will make it more likely that caller(1) will return the
: > right thing.)
:
: And all eyes are now on Larry...
Thanks, I love attention. :-)
: > > Mental note:
: > >
: > > 1. Don't use recursion in Perl, it'll be much slower than an
: > >iterative approach
: > > 2. If in doubt, refer to note 1.
: >
: > Certainly will be slower in Perl 5. Hopefully what won't be the case
: > in Perl 6 (having had to recast code from tail recursive form
: > explicitly iterative form, I'd really rather not have to do that in
: > the general case.)
:
: Will function calls be faster in Perl 6, in general? Using a simple
: benchmark, an empty subroutine called with no arguments took around
: 1500 machine cycles to execute on Perl 5. Surely a nice new JIT and
: better VM should make function calls less expensive, tight loops in
: general are a bad idea in Perl 5 - no inlining.
Except for constants.
Perl 6 should be much better in this regard, provided you make use of
the formal parameter syntax. The old way of setting up @_ with default
read/write parameters is one place that slows down Perl 5 subroutine
calls, so the newer signatures that default the argument list to being
constant should help the optimizer out a great deal, since it can then
just pull arguments straight from wherever they're stored, whether
stack or register. The JIT (which already exists!) will also help,
hopefully.
Larry
Re: Tail Recursion optimization
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 11:45 PM +0100 4/5/02, Piers Cawley wrote: >>So, here I am working on a Scheme interpreter in Perl 6, and I'm >>trying to write it in a (for want of a better description) >>'Scheme-like' fashion with lots of recursion. >> >>The trouble is, unless Perl6 is going to be guaranteed to do >>optimization of tail calls, this is going to lead to horribly slow >>code. So, do I bite the bullet and recast some of the functions in an >>iterative vein, or do I trust that Perl6 will do tail call optimization? > > If you don't mind emitting bytecode directly, Parrot's calling > conventions are such that tail calls and tail recursion works OK. I know. When I do the parrot version of this I'm going to be taking every advantage of it. (Once I've worked out how to detect that I'm about to make a tail call). -- 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: $^a, $^b, and friends
Larry Wall <[EMAIL PROTECTED]> writes:
> Rafael Garcia-Suarez writes:
> : Larry Wall wrote in perl.perl6.language :
> : >
> : > Such a grammar switching routine could operate either over a lexical
> : > scope or over the rest of the file. The only restriction is that
> : > one module not clobber the grammar of a different module.
> : >
> : > Basically, we're trying to make the opposite mistake of the one
> : > we made with source filters. :-)
> :
> : I see that. But should it be possible to import grammar rules,
> : to allow :
> :
> : use Some::Module::That::Modifies::A::Grammar::Rule;
> : # continue to parse the perl program with the modified grammar
> :
> : or even :
> : {
> : use Some::Module::That::Modifies::A::Grammar::Rule;
> : # continue to parse the block with the modified grammar
> : }
>
> Well, it's kind of klunky to do an import every time. More likely
> you'd import a special subroutine once that you can use like this:
>
> Java {
> whatsit.blorf.unnecessary.bletch.extra.something.whatever(1);
> }
>
> Perl 5 is restricted to doing compile-time actions using BEGIN or
> use. In Perl 6 there will be some way of marking a normal
> subroutine as as grammatically active, so that it's called
> immediately, even before its arguments are parsed. Our hypothetical
> Java subroutine above could switch to a Java grammar, parse its
> block, and then restore the Perl grammar at the end.
In a use.perl post not far away I sketched out something like the following:
module foo is Mixin {
sub category($category, &block) {
&block.abstract_syntax_tree.walk_with -> $node {
when AST::Method {
.attrib(category => $category) if .parent =~ █
}
}
}
Actually, my naming choices were rather worse, I originally suggested
'optree', but the optree is really too low level for a lot of things.
# Which leads to thoughts of:
macro Java(&block is rw) {
&block = &block.source.parse_with( Parser::Java )
}
}
(The idea here is that 'macro' would get the block 'earlier' while the
raw source is still lying around, and before perl has started to throw
syntax errors.)
> : And what about switching to a different or modified tokenizer ?
>
> It's not clear that the lexer is a separate entity any more. Lexers
> were originally invented as a way of abstracting out part of the
> grammar so that it could be done in a separate pass, and to simplify
> the grammar for the poor overworked parser. But you can write a
> grammar for an identifier just about as easily as for an if-then-else.
> More easily, if we're basing it on regexes. If we're viewing all
> grammar through the lens of regexes, we're really starting out closer
> to Lexerland anyway, and generalizing toward parsing, a traditionally
> weaker area for Perl. And that's an odd weakness for a text
> processing language.
I am *so* looking forward to Apocalypse 5...
--
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: $^a, $^b, and friends
Piers Cawley writes:
: In a use.perl post not far away I sketched out something like the following:
:
: module foo is Mixin {
:
: sub category($category, &block) {
: &block.abstract_syntax_tree.walk_with -> $node {
: when AST::Method {
: .attrib(category => $category) if .parent =~ █
: }
: }
: }
I don't entirely understand what you're trying to do. Pretty code, though. :-)
: Actually, my naming choices were rather worse, I originally suggested
: 'optree', but the optree is really too low level for a lot of things.
:
: # Which leads to thoughts of:
: macro Java(&block is rw) {
: &block = &block.source.parse_with( Parser::Java )
: }
: }
:
: (The idea here is that 'macro' would get the block 'earlier' while the
: raw source is still lying around, and before perl has started to throw
: syntax errors.)
Hmm, I think most macros with arguments would want to assume the
arguments to be Perl code, and not delay parsing till the macro call.
The abstraction of having an argument to the macro that's not really
there when you call it seems a bit odd. Why return a value through the
argument? I'd rather look at it as an argumentless macro that just
happens to harvest additional text from the input stream. Then return
the block as part of what the macro ordinarily returns. Seems cleaner
to me.
: > : And what about switching to a different or modified tokenizer ?
: >
: > It's not clear that the lexer is a separate entity any more. Lexers
: > were originally invented as a way of abstracting out part of the
: > grammar so that it could be done in a separate pass, and to simplify
: > the grammar for the poor overworked parser. But you can write a
: > grammar for an identifier just about as easily as for an if-then-else.
: > More easily, if we're basing it on regexes. If we're viewing all
: > grammar through the lens of regexes, we're really starting out closer
: > to Lexerland anyway, and generalizing toward parsing, a traditionally
: > weaker area for Perl. And that's an odd weakness for a text
: > processing language.
:
: I am *so* looking forward to Apocalypse 5...
Mmm. You wanna write it for me? :-)
'Course, all the hard bits will likely be deferred to Apocalypse 18 or so...
Larry
Re: $^a, $^b, and friends
Dan Sugalski wrote in perl.perl6.language : > > Don't forget, we already change parsing rules at compile time. Perl's > got three (maybe four) different sets of rules as it is: > >*) Normal perl >*) Regexes >*) Double-quoted strings >*) Single-quoted strings > > Adding another, or changing those, isn't a big deal. Strictly speaking, the last three are handled by perl 5's tokenizer. An insteresting case of compile-time parsing rules modification is given by prototypes : the perl 5 statement foo 1, 2 is parsed differently if foo() has ($) or (@) as prototype.
Re: $^a, $^b, and friends
Larry Wall wrote : > > It's not clear that the lexer is a separate entity any more. Lexers > were originally invented as a way of abstracting out part of the > grammar so that it could be done in a separate pass, and to simplify > the grammar for the poor overworked parser. Indeed. Another benefit of lexers is to allow contextual constructs, like the qq/.../ operator, where the separators can be an arbitrary character. (well, a non-contextual grammar can describe this, if you enumerate all possible separators in separate grammar productions, and you'll end up with a gigantic transition table.) > But you can write a > grammar for an identifier just about as easily as for an if-then-else. > More easily, if we're basing it on regexes. If we're viewing all > grammar through the lens of regexes, we're really starting out closer > to Lexerland anyway, and generalizing toward parsing, a traditionally > weaker area for Perl. And that's an odd weakness for a text > processing language. This sounds really cool. The word 'regular' goes more and more unappropriate...
Re: $^a, $^b, and friends
Larry Wall <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
> : In a use.perl post not far away I sketched out something like the following:
> :
> : module foo is Mixin {
> :
> : sub category($category, &block) {
> : &block.abstract_syntax_tree.walk_with -> $node {
> : when AST::Method {
> : .attrib(category => $category) if .parent =~ █
> : }
> : }
> : }
>
> I don't entirely understand what you're trying to do. Pretty code,
> though. :-)
Heh. I didn't think it was that tricky.
..abstract_syntax_tree gets the blocks Syntax Tree.
..walk_with iterates over the tree passing each node into the block it
gets called with.
-> $node {
when AST::Method { ... }
}
a single argument callback function. Yeah, I could have used
{
given $^node {
when AST::Method {...}
}
}
But I liked the C<-> $node {...}> notation better in this case. And
then the callback decorates every method defined at the top level of
the block with a category attribute. So, I know I'm stretching on the
AST thing, but we're not far off being able to do this sort of thing
right now with B::Optimize and B::Utils.
> : Actually, my naming choices were rather worse, I originally suggested
> : 'optree', but the optree is really too low level for a lot of things.
> :
> : # Which leads to thoughts of:
> : macro Java(&block is rw) {
> : &block = &block.source.parse_with( Parser::Java )
> : }
> : }
> :
> : (The idea here is that 'macro' would get the block 'earlier' while the
> : raw source is still lying around, and before perl has started to throw
> : syntax errors.)
>
> Hmm, I think most macros with arguments would want to assume the
> arguments to be Perl code, and not delay parsing till the macro
> call. The abstraction of having an argument to the macro that's not
> really there when you call it seems a bit odd. Why return a value
> through the argument? I'd rather look at it as an argumentless
> macro that just happens to harvest additional text from the input
> stream. Then return the block as part of what the macro ordinarily
> returns. Seems cleaner to me.
Good point. However, I'd like to see a mechanism that allows one to
use an entirely different parser a la Inline.
macro Java is raw { ... } # Gets untokenized, unparsed source
macro PerlDialect { ... } # Gets some sort of syntax tree?
> : I am *so* looking forward to Apocalypse 5...
>
> Mmm. You wanna write it for me? :-)
Hell no. I'd volunteer to do tech review, but I'm sure that with
Damian, Dan, Hugo, Jon, Gnat and Co. on your case already you don't
really need another pair of eyes; I'd just slow you down.
> 'Course, all the hard bits will likely be deferred to Apocalypse 18
> or so...
By which time it'll all seem obvious and/or inevitable. One hopes.
--
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: Ex4 smart match question
John A asked: > > This new turbo-charged 'smart match' operator will also work on arrays, > > hashes, and lists: > It's very cool--but why is it $key =~ %hash but $value =~ @array rather > than one way or the other? Because it's *both* ways. Perl 6's C<=~> operator is reversible. So you can write: $key =~ %hash or: %hash =~ $key and: $value =~ @array or: @array =~ $value depending on how the muse takes you. Damian
Re: classes, interfaces, properties and 'is'
Melvin Smith wrote:
> I see the potential for another Perl 'non-warning' bug, where
> someone typed:
>
> class Appliance {
> ...mucho lines of code...
> }
>
> class Toaster is appliance {
> ...
> }
That's probably an "Undefined property 'appliance' ascribed to class Toaster" error.
> It scares me to be able to _declare_ a new attribute with the same operator
> that I typically use to _inherit_ an existing class or property.
This is a good point. I suppose that, instead of just:
class Derived is Base {...}
the syntax might end up as:
class Derived is inheriting(Base) {...}
or:
class Derived is subclass_of(Base) {...}
or even just:
class Derived is a(Base) {...}
Larry?
> Why not make 'is' a little tidier; require us to declare attributes inline, and
> let us tag _objects_ (not classes) at runtime with different notation?
Err...okay. How about C instead of C for objects?
See .
Damian
Re: Ex4 smart match question
At 10:34 AM 4/7/02 +1000, Damian Conway wrote: > > It's very cool--but why is it $key =~ %hash but $value =~ @array rather > > than one way or the other? > >Because it's *both* ways. Perl 6's C<=~> operator is reversible. > >So you can write: > > $key =~ %hash > >or: > > %hash =~ $key > >and: > > $value =~ @array > >or: > > @array =~ $value > >depending on how the muse takes you. Why give up the chance to let things that look different behave differently? What do @left =~ @right %left =~ %right do? One can imagine useful default interpretations that are not commutative. -- Peter Scott Pacific Systems Design Technologies
Unary dot
Whilst I've been hacking the perl 6 scheme interpreter I've found
myself using code like the following
method get_token( $self: ) {
given $self.get_char {
when !defined { fail IOException: msg=> "EOF" }
when /\s/ { $self.get_token }
when '(' { $the_left_paren }
when ')' { $the_right_paren }
when '"' { $self.read_string }
when /\d/ { $self.read_number($_) }
default { $self.read_identifier($_) }
}
}
Initially, that got written as:
method get_token {
given .get_char {
...
default { # Hang on, how do I call a method on myself now?
}
}
}
The issue here is that, if you ever want to use a topicalizer inside a
method definition, and you're going to want to call a method on
yourself from inside the scope of that topicalizer then you can't
really make use of implicit self references.
And because topicalizers are such a powerful tool (believe me; I don't
think I've written a single 'if' statement anywhere in the scheme
interpreter, it's starting to feel clumsy), you're going to end up
with almost all your method declarations looking like:
method foo($self: ... ) {...}
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
(I'm sure we'll be able to write 'object_name', I'm just hoping that
it'll come as part of the core distribution)
--
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?
