Joe Gottman writes:
>
>Not really. A variable declared with can be accessed from
> anywhere in the program, just by redeclaring it or calling it with the
> "package::" syntax.A variable declared with can be accessed outside
> its scope only if the user returns a reference to it.
Uri Guttman writes:
> talking about nested subs brought up another related idea, static (not
> on the stack) lexicals inside subs. the current solution in p5 is to
> declare them in a surrounding block and that is slightly ugly. and if
> you want multiple subs to share them they all have to be in
Chris Dutton <[EMAIL PROTECTED]> writes:
> On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
>
> > ==QUESTION
> > - Page 8 says "In some languages, all methods are multimethods." I
> > believe that Java is one of these. Is that right and what are some
> > others? (This is really just
On Sun, Mar 16, 2003 at 10:08:41PM -0500, Chris Dutton wrote:
> On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
>
> > ==QUESTION
> > - Page 8 says "In some languages, all methods are multimethods." I
> > believe that Java is one of these. Is that right and what are some
> > others?
OK, I've recently spent some intimate time with Apocalypse 5 and it has
left me with a few issues and questions.
If any of this has already been discussed, I'd appreciate some links (I've
searched google groups but haven't found anything applicable)
1. Sub-rules and backtracking
#
> ==QUESTION
> - Given the following code, what is called by $ride.current_speed()?
>
> class Vehicle {
> my $speed;
> method current_speed() { return $speed; }
> method set_speed($n) { $speed = $n; }
> }
>
> class Car {
> submethod current_speed() {
>
> 1. Sub-rules and backtracking
>
> > # call rule, passing Perl args
> >{ .name(expr) } # same thing.
>
> ># call rule, passing regex arg
> >{ .name(/pat/) } # same thing.
>
> Considering perl can't sanely know how to backtrack into a closure, woul
On Sun, Mar 16, 2003 at 04:22:27PM +0200, arcadi shehter wrote:
: it's interesting that "has" have more or less required scope -- its
: visible only from object methods and it keeps its value , so maybe
: something like this :
:
: sub foo() {
: has $s //= 0;
: $s ++ ;
: }
:
: print foo,
> Nick --
>
> I've been thinking of it like this:
>
> class int isa intlike; # and isa value or whatever
> class Int isa intlike; # and isa Object or whatever
>
> class num isa numlike; # and isa value or whatever
> class Num isa numlike; # and isa Object or whatever
>
> ...
>
> cl
On Mon, Mar 17, 2003 at 11:17:21AM -0700, Luke Palmer wrote:
> # call rule, passing Perl args
>{ .name(expr) } # same thing.
Considering perl can't sanely know how to backtrack into a closure,
wouldn't { .name(expr) } be equal to : instead?
Nope. : is equivalent to { .n
On Mon, Mar 17, 2003 at 10:56:51AM -0700, Luke Palmer wrote:
> Assuming the obvious inheritance, Vehicle.set_speed() would be called.
Ok good, that's what I thought. Thanks.
> No. Rules fit better in a grammar than subs, and help the psychology
> of people in various ways. For instance:
>
>
On Monday, March 17, 2003, at 10:35 AM, Luke Palmer wrote:
I've been thinking of it like this:
class int isa intlike; # and isa value or whatever
class Int isa intlike; # and isa Object or whatever
class num isa numlike; # and isa value or whatever
class Num isa numlike; # and isa Object
On Mon, Mar 17, 2003 at 10:52:26AM -0800, David Storrs wrote:
sub identifier {m{ <[\w]-[\d]> \w+ }}
rule identifier { <[\w]-[\d]> \w }
I personally don't see a lot of difference between those two, but I'll
go with you on the "helps people know that $match should be a regex"
point. Good eno
> On Mon, Mar 17, 2003 at 11:17:21AM -0700, Luke Palmer wrote:
> >> > # call rule, passing Perl args
> >> >{ .name(expr) } # same thing.
> >>
> >> Considering perl can't sanely know how to backtrack into a closure,
> >> wouldn't { .name(expr) } be equal to : instead?
>
On Mon, Mar 17, 2003 at 07:49:36PM +0100, Matthijs van Duin wrote:
(blah blah I wrote on closures and rule-invocation)
I'm not saying rules will be implemented in such a way, but it's the first
thing that comes to mind.
Before anyone replies, I just realized I should probably just first browse
a
class Scalar isa intlike, numlike, ...; # and isa Object or whatever
Qoting A6: "Perl makes a distinction between the type of the variable,
and the type of the value"
If we view Scalar as the type of a variable, not value, then we could
cease to need all this cleverness with inheritance. Peopl
> On Mon, Mar 17, 2003 at 07:49:36PM +0100, Matthijs van Duin wrote:
> >(blah blah I wrote on closures and rule-invocation)
> >
> >I'm not saying rules will be implemented in such a way, but it's the first
> >thing that comes to mind.
>
> Before anyone replies, I just realized I should probably j
On Mon, Mar 17, 2003 at 12:14:00PM -0700, Luke Palmer wrote:
Before anyone replies, I just realized I should probably just first browse
around in parrot since regex is already implemented ;-)
No---you shouldn't do that. Regex (in languages/perl6) is a naive and
is due for a rewrite.
And I just re
Larry wrote:
: sub foo() {
: has $s //= 0;
: $s ++ ;
: }
:
: print foo, foo, foo;
This is interesting, but I think it would be a mistake to give C two
unrelated meanings -- and I think we'd have to stretch our concepts of objects
a little too far to consider these two meanings related
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Larry wrote:
>> : sub foo() {
>> : has $s //= 0; : $s ++ ;
>> : }
>> : : print foo, foo, foo;
DC> Futhermore, this approach opens another vermiferous can. I would argue
DC> that C is the wrong way to initialize it,
Uri Guttman wrote:
but that is a good name IMO. $s is static vs dynamic (on the stack).
I don't think that names that describe implementation are nearly as good as
names that describe behaviour. Not in a Very High Level Language, like Perl.
other overloaded meanings of static from c/c++ are bag
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Uri Guttman wrote:
>> but that is a good name IMO. $s is static vs dynamic (on the stack).
DC> I don't think that names that describe implementation are nearly as
DC> good as names that describe behaviour. Not in a Very High Leve
> to me static IS a behavior. its value is static from call to call.
> >> other overloaded meanings of static from c/c++ are baggage we can drop.
I can see the potental for alot of ambiguaty between the meaning of 'is Static' and
'is Constant' (unless your a c/c++ programmer so your mind is al
23 matches
Mail list logo
