Re: Smart match table
On 10/02/06, Stuart Cook <[EMAIL PROTECTED]> wrote: > IIRC, that rule exists so you can create when-clauses that don't > involve the current topic, without having to explicitly throw it away. > This is useful when using given/when to replace a sequence of elsifs, > when not all of them use $_. (In light of David's response, it seems what I wrote is not 100% correct, so please ignore.) Stuart
Re: Smart match table
On 09/02/06, Mike Guy <[EMAIL PROTECTED]> wrote: > Robin Houston <[EMAIL PROTECTED]> wrote > > Any Code()simple closure truth match if $b->() (ignoring $a) > > I obviously missed that when it went past on p5p. Surely that should > read > > Any Code()predicate(value) match if $b->($a) > > meaning that $a satisfies the predicate implemented by the code $b? > > Ignoring $a seems a completely stupid thing to do. IIRC, that rule exists so you can create when-clauses that don't involve the current topic, without having to explicitly throw it away. This is useful when using given/when to replace a sequence of elsifs, when not all of them use $_. The problem, as I see it, is that you can't really have all three of the following: 1) Sensible (symmetric, non-ignoring) behaviour of `~~` 2) Simple correspondence between `when` and `~~` 3) Sensible (dwimmy) behaviour of `when` Currently, it's (1) that's been lost. Now, personally I wouldn't mind exchanging it for (2), but there certainly are valid reasons for wanting to keep (2). Stuart
Re: Smart match table
On 2/8/06, Mike Guy wrote: I obviously missed that when it went past on p5p. Surely that should read Any Code()predicate(value) match if $b->($a) meaning that $a satisfies the predicate implemented by the code $b? Ignoring $a seems a completely stupid thing to do. Well, the ~~ table includes both: Any Code<$> scalar sub truth match if $b($a) Any Code<>simple closure truth match if $b() (ignoring $a) so if the code takes a single argument, it will use $a; if it doesn't, then, well, it won't. -David "feeling singularly argumentative today" Green
Re: overloading the variable declaration process
Stevan Little wrote:
> Jonathan Lang wrote:
> > OK; apparently, what I meant when I asked "what methods and attributes
> > does ^Dog have?" is what you're talking about when you speak of which
> > methods ^Dog will respond to. To me, an object has whatever methods
> > that it responds to.
>
> I disagree, an object is an instance of a class. A class "has" the
> methods that the object will respond too. You would not want to store
> all the methods in each instance, it would not make sense. Each
> instance needs to share a set of methods, and those methods are stored
> in the class.
I think that we're talking past each other: you're trying to educate
me on how a programmer should think about objects and classes; I'm
trying to figure out how a non-programmer thinks of them.
To non-programmers (and amateur programmers), objects aren't instances
of classes; classes are categories of related objects. Objects have
behaviors and characteristics; classes are a convenient shorthand for
describing behaviors and characteristics common to a set. Objects
come first, while classes are thought of in the context of objects.
The same implementation can be used for both perspectives: "dogs can
bark; Spot is a dog; therefore, Spot can bark" is a form of reasoning
that underlies using the class-and-instance model for the "back-end"
implementation of the object-and-category paradigm.
"classes have methods; objects respond to them" is part of the
classes-and-instances paradigm; but that isn't really how people
think.
In terms of practical differences: under the classes-and-instances
paradigm, if you want to create an object whose behavior differs
slightly from a given class, you need to create a subclass that has
the desired behavior and to create the object as an instance of that
subclass. With the object-and-category paradigm, there's nothing that
insists that every object's behavior must conform precisely to the
behaviors described by its classes; the latter are "merely" rules of
thumb to apply to the former until you learn differently, and
behaviors can be added, removed, or tweaked on an individual basis.
This is why (last I checked) "but" creates a behind-the-scenes
'singleton' subclass for the new object instead of demanding that a
new subclass be explicitly created, and why I suggested the
possibility of adding, replacing, or removing methods for individual
objects as well as for classes (which, presumably, would also be
implemented under the hood by replacing the object's class by a
'singleton' subclass).
> > > ^Dog.name # Dog
> > > ^Dog.version # 0.0.1 (or something similiar of course)
> > > ^Dog.authority # cpan:LWALL or email:[EMAIL PROTECTED]
> > >
> > > ^Dog.identifier # returns the string Dog-0.0.1-cpan:LWALL
> >
> > Would it be valid to speak of ^$spot? If so, what would ^$spot.name be?
>
> There is no such thing as a ^$spot.
OK. The only reason I was thinking in those terms was because of the
possibility that $spot might be based on one of those
behind-the-scenes customized subclasses that I mentioned earlier: if
my Dog $brutus but cannot("bark");
How do you access the subclass of Dog that $brutus is the instance of?
> > IIRC, you can always create a new method for a class, even outside of
> > its definition, simply by ensuring that the first parameter to be
> > passed in will be an object of that type:
> >
> > method bark (Dog $_) { ... }
>
> I don't think this is true unless it is a multi method, in which case
> it is not actually a method of the of the class, but instead just
> DWIMs because of MMD and the fact we allow an invocant calling style
> freely.
I was under the impression that the distinction between a method and a
multi-method was how many of the parameters get used to dispatch:
methods aren't really "owned" by classes, any more than class
definition is a declarative process; it just looks that way on the
surface. Am I wrong about this?
> > or maybe
> >
> > method Dog.bark () { ... }
>
> Yes that works too. But TIMTOWTDI, and each has it's own benefits.
I'm aware of that, and was proposing this as Another Way.
> Your above approach works fine while you are writing the code, but is
> not as useful for dynamically adding a method at runtime (unless you
> use eval(), but that gets ugly).
I was under the impression that class definition was fundamentally a
functional process dressed up as a declarative process. "method
Dog.bark () { ... }" would seem to me to be a means of continuing that
process "after the fact" - that is, adding a method to a class after
you've left the class definition block. It seems to serve exactly the
same purpose as using the metaclass API. That is, I see it as being
alternate syntax for "^Dog.add_method(bark => method () { ... })".
> > To fetch a method, why not have .can() return a reference to the
> > method upon success? I might even go so far as to treat can() as an
> > lvalue, using the assignment of a coderef as an alternate way
Re: Smart match table
Robin Houston <[EMAIL PROTECTED]> wrote > Any Code()simple closure truth match if $b->() (ignoring $a) I obviously missed that when it went past on p5p. Surely that should read Any Code()predicate(value) match if $b->($a) meaning that $a satisfies the predicate implemented by the code $b? Ignoring $a seems a completely stupid thing to do. Mike Guy
Re: overloading the variable declaration process
On 2/9/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Stevan Little wrote:
> > Jonathan Lang wrote:
> > > OK. To help me get a better idea about what's going on here, what
> > > sorts of attributes and methods would ^Dog have?
> >
> > Well, a metaclass describes the behaviors and attributes of a class,
> > and ^Dog is an *instance* of the metaclass. So actually ^Dog would not
> > actually have attributes and methods since it is an instance.
>
> Huh? A dog can bark; so the Dog class should have a method called
> 'bark'. Or does 'can' not mean what it seems to mean?
^Dog is an instance of the MetaClass, while Dog (no ^ sigil) is the
"class" (actually it's a prototypical instance of the class which the
metaclass ^Dog describes, but you dont really need to know that to use
it).
^Dog.can(bark) # false
Dog.can(bark) # true
This is a very important distinction. Saying "Dog class has a method
called 'bark'", implies the following statements are true
- Dog will respond to the method called "bark".
- Given my Dog $spot, $spot will respond to the method called "bark".
- ^Dog (the metaclass instance which describes a class called "Dog")
does *not* respond to the method called "bark".
- ^Dog (since it describes the class called "Dog") manages all of the
methods which Dog and $spot will respond too, one of which is called
"bark".
There is a clear line between the meta-level (where ^Dog lives) and
the user-level (where Dog and $spot) live. This is a line which is
heavily blurred in Perl 5, and in many OO languages (aside from
Smalltalk, CLOS and a few others) the meta-level is just not
accessible at all from user-land.
> > That said, I think ^Dog would probably respond to methods like
> > these (some of which are described in S12):
>
> OK; apparently, what I meant when I asked "what methods and attributes
> does ^Dog have?" is what you're talking about when you speak of which
> methods ^Dog will respond to. To me, an object has whatever methods
> that it responds to.
I disagree, an object is an instance of a class. A class "has" the
methods that the object will respond too. You would not want to store
all the methods in each instance, it would not make sense. Each
instance needs to share a set of methods, and those methods are stored
in the class.
Well what is a class?
In Perl 5 a class is simply a package, and the subs in that package
are methods. In Perl 6 however, a class will be an instance of another
class, the MetaClass. These two things are really not that different
when you think about it.
- A Perl 5 package holds methods for you by storing them in the symbol
table. You can add, get, remove these methods from the symbol table
using the symbol table API.
- A Perl 6 class holds methods for you by storing them inside an
instance variable in an instance of the MetaClass, and you can add,
get, remove these methods by using the methods of MetaClass.
Of course you have a conceptual circulatiry issue now because well,..
what is a MetaClass? Well it could be an instance of a MetaMetaClass,
but what is that an instance of? This could go on forever (turtles all
the way down as it is sometimes called).
But in practice you either just stop and say "this is as far as it
goes", or you bootstrap your class model somehow and "tie the knot".
I prefer the boostrapping as it is much more elegant and tends to
allow for much more flexibility.
> > ^Dog.name # Dog
> > ^Dog.version # 0.0.1 (or something similiar of course)
> > ^Dog.authority # cpan:LWALL or email:[EMAIL PROTECTED]
> >
> > ^Dog.identifier # returns the string Dog-0.0.1-cpan:LWALL
>
> Would it be valid to speak of ^$spot? If so, what would ^$spot.name be?
There is no such thing as a ^$spot. The ^ is the "class" sigil, and
will hold metaclass instances only, just as variables with % will
only holds hashes, and variables with @ will only holds arrays, etc.
> > I would like to see some methods like this:
> >
> > # dynamically add a method that
> > # Dog and $spot would respond to
> > ^Dog.add_method(bark => method () { ... });
> >
> > Which would be like doing this in Perl 5:
> >
> > no strict 'refs';
> > *{'Dog::bark'} = sub { ... };
>
> IIRC, you can always create a new method for a class, even outside of
> its definition, simply by ensuring that the first parameter to be
> passed in will be an object of that type:
>
> method bark (Dog $_) { ... }
I don't think this is true unless it is a multi method, in which case
it is not actually a method of the of the class, but instead just
DWIMs because of MMD and the fact we allow an invocant calling style
freely.
> or maybe
>
> method Dog.bark () { ... }
Yes that works too. But TIMTOWTDI, and each has it's own benefits.
Your above approach works fine while you are writing the code, but is
not as useful for dynamically adding a method at runtime (unless you
use eval(), but that gets ugly). Using the metaclass API dynamically
adding a method to a class at runtime is trivial, ag
Re: overloading the variable declaration process
Stevan Little wrote:
> Jonathan Lang wrote:
> > OK. To help me get a better idea about what's going on here, what
> > sorts of attributes and methods would ^Dog have?
>
> Well, a metaclass describes the behaviors and attributes of a class,
> and ^Dog is an *instance* of the metaclass. So actually ^Dog would not
> actually have attributes and methods since it is an instance.
Huh? A dog can bark; so the Dog class should have a method called
'bark'. Or does 'can' not mean what it seems to mean?
> That said, I think ^Dog would probably respond to methods like
> these (some of which are described in S12):
OK; apparently, what I meant when I asked "what methods and attributes
does ^Dog have?" is what you're talking about when you speak of which
methods ^Dog will respond to. To me, an object has whatever methods
that it responds to.
> ^Dog.name # Dog
> ^Dog.version # 0.0.1 (or something similiar of course)
> ^Dog.authority # cpan:LWALL or email:[EMAIL PROTECTED]
>
> ^Dog.identifier # returns the string Dog-0.0.1-cpan:LWALL
Would it be valid to speak of ^$spot? If so, what would ^$spot.name be?
> I would like to see some methods like this:
>
> # dynamically add a method that
> # Dog and $spot would respond to
> ^Dog.add_method(bark => method () { ... });
>
> Which would be like doing this in Perl 5:
>
> no strict 'refs';
> *{'Dog::bark'} = sub { ... };
IIRC, you can always create a new method for a class, even outside of
its definition, simply by ensuring that the first parameter to be
passed in will be an object of that type:
method bark (Dog $_) { ... }
or maybe
method Dog.bark () { ... }
> And of course if you can add a method, you will need to be able to
> fetch and delete them as well, so a &get_method and &remove_method
> would be in order as well.
To fetch a method, why not have .can() return a reference to the
method upon success? I might even go so far as to treat can() as an
lvalue, using the assignment of a coderef as an alternate way of
adding or changing the object's behavior on the fly:
method bark (Dog $_:) { ... };
Dog.can("bark") = method () { ... }; # Teach the dog a new trick
Dog.can("bark") = true; # inform the dog that it ought to know how
to bark, without telling it how, yet; equivalent to a literal "=
method { ... }".
Dog.can("bark") = false; # tell the dog to forget how to bark.
Dog.can("bark") = undef; # Ditto.
(Doing this to Dog DWIMs to modifying the behavior of all dogs at once
- you're declaring that "dogs can bark" or "this is how dogs bark",
whereas doing it to $spot DWIMs to modifying the behavior of $spot
only: "$brutus.can('bark') = false": my best friend's pet dog seems to
have lost the capacity to bark in its old age; that doesn't mean that
dogs in general can't bark.)
Similar things might be done with .has (for attributes), .isa (for
superclasses), and .does (for roles).
--
Jonathan "Dataweaver" Lang
Re: overloading the variable declaration process
On 2/8/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Stevan Little wrote:
> > Yes, that is correct, because:
> >
> > Dog.isa(Dog) # true
> > $spot.isa(Dog) # true
> > ^Dog.isa(Dog) # false
> >
> > In fact ^Dog isa MetaClass (or Class whatever you want to call it).
> >
> > At least that is how I see/understand it.
>
> OK. To help me get a better idea about what's going on here, what
> sorts of attributes and methods would ^Dog have?
Well, a metaclass describes the behaviors and attributes of a class,
and ^Dog is an *instance* of the metaclass. So actually ^Dog would not
actually have attributes and methods since it is an instance. That
said, I think ^Dog would probably respond to methods like these (some
of which are described in S12):
^Dog.name # Dog
^Dog.version # 0.0.1 (or something similiar of course)
^Dog.authority # cpan:LWALL or email:[EMAIL PROTECTED]
^Dog.identifier # returns the string Dog-0.0.1-cpan:LWALL
I would like to see some methods like this:
# dynamically add a method that
# Dog and $spot would respond to
^Dog.add_method(bark => method () { ... });
Which would be like doing this in Perl 5:
no strict 'refs';
*{'Dog::bark'} = sub { ... };
And of course if you can add a method, you will need to be able to
fetch and delete them as well, so a &get_method and &remove_method
would be in order as well.
And if you can add methods, surely you can add attributes, so
&(add|get|remove)_attribute would be needed.
^Dog.add_attribute(:label<$fur>, :access);
Would be equivalent to saying this:
class Dog is reopened {
has $fur is rw;
}
And ^Dog would also provide access to infromation about super and
subclasses as well. So &superclasses and &subclasses methods would
make sense too. We would also need methods to deal with Role
relationships as well.
So, given the above items, the class MetaClass might look something like this:
class MetaClass {
has $name is rw;
has $version is rw;
has $authority is rw;
has @superclasses;
has @subclasses;
has %methods;
has %attributes;
method identifier { ... }
method superclasses { ... }
method subclasses { ... }
method add_method { ... }
method get_method { ... }
method remove_method { ... }
method add_attribute { ... }
method get_attribute { ... }
method remove_attribute { ... }
}
So given this, you could almost look at this code:
class Foo-0.0.1-cpan:JRANDOM {
has $bar is rw;
method baz (Foo $self:) { ... }
}
As being roughly equivalent to the following code:
^Foo := MetaClass.new();
^Foo.name('Foo');
^Foo.version(0.0.1);
^Foo.authority(:cpan);
^Foo.add_attribute(:label<$bar>, :access);
^Foo.add_method(baz => method (Foo $self) { ... });
Of course this is mostly unspecced, and it is still unclear exactly
how much of this meta-level API will be accessible in Perl 6 itself.
And as far the the Pugs work on this goes, we plan to have something
similar to the above available in the next release (6.28.0).
Hope this helps.
Stevan
Re: A proposition for streamlining Perl 6 development
On Wed, Feb 08, 2006 at 12:37:05 -0800, chromatic wrote: > On Tuesday 07 February 2006 23:55, Yuval Kogman wrote: > > > Does this imply that we should think up this process? > > Go ahead. We'll start at the Israel hackathon, with a little preamble. > The last time someone tried to set forth a complete specification in a > particular order was the Perl 6 documentation project. That didn't work > then. I doubt it'll work now, either... Here is my reply on #perl6 to your discussion on Perl 6: My reply: http://colabti.de/irclogger/irclogger_log/perl6?date=2006-02-09,Thu&sel=11 Your discussion: http://colabti.de/irclogger/irclogger_log/perl6?date=2006-02-08,Wed&sel=348#l558 > I have doubts that specifying a complete compiler and toolchain > without at least some trial and error will work, but I could be wrong. Trial and error is always required, and a very good tool for innovation in the hands of the community. I don't think Big Bang design is ever good, but I also believe a rough plan with easy to understand milestones (as opposed to a daunting cliff) are required, even if not formal or even on paper. Also, I am trying to formulate a plan that will help us write most of the parts in Perl 6, *NOT* Haskell, because I, like you, despite my love for Haskell, think it's just too inaccessible. What I'd like is to optimize the modularization such that Pugs serves as a bootstrap parser/interpreter/compiler - a good solid tool to help us write: The Perl 6 standard library in Perl 6 (with stubs for IO, system calls, and other things that cannot be defined in a "pure" language) The Perl 6 compiler toolchain in Perl 6 (the linker, compiler, emitters, and an interpreter, too). And then eventually refactor the current state of pugs into a haskell runtime, and and possibly a historical parser/compiler that we can use to compare things to. The way things are headed now, we are just shy of being able to write good tools in Perl 6 using pugs - it's too slow, the object model is not finalized, the grammar is not extensible, etc etc. These are many things that are mentioned in the synopses but not described in enough detail, and if we want the other parts to be in Perl 6 we need these done in haskell first, and then rewritten. If we get them later, we'll have to write the other parts in haskell too. > Maybe the right place to start is to gather a list of all of the questions > you > need to have answered and all of the features people want, and then try to > unify them into a Perl 6-ish whole. Yes, that's an excellent start, and in fact, I think this is what Audrey plans on starting with at the prehackathon, when she arrives in Israel and works with Gaal. Unfortunately for myself, I will be unable to follow this discussion as of ~14:00 GMT, today (Feb 9th) as I'm going to visit my grand parents in Austria, and try not to die while snowboarding. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me tips over a cow: neeyah!! pgpat242mSYfq.pgp Description: PGP signature
