A6: objects and/or types (was: P6FC)
Aldo Calpini
> ...and I don't know if macros are actually objects and can be tossed
> around, or if they're just part of the compilation process.
they have their proper place in the diagram Larry put in A6.
furthermore, he says:
"These syntactic forms correspond the various Routine types in the
Code type hierarchy"
so Macro seems to be at least a type. which leads me to the question:
is Macro "also" a class? and which is the difference between a type
and a class? hm, I guess this will be answered in A12, so I'll
probably have to wait on this.
I also have another question (probably related, and probably also for
later). consider this:
sub mygrep( Code &block, *@list is rw ) {...};
sub mygrep( Block &block, *@list is rw ) {...};
sub mygrep( Routine &block, *@list is rw ) {...};
sub mygrep( Sub &block, *@list is rw ) {...};
sub mygrep( Method &block, *@list is rw ) {...};
is something like this allowed? and what is the meaning then? if logic
serves me correctly, this shouldn't work:
sub mygrep( Routine &block, *@list is rw ) {...};
mygrep { $_ < 2 }, 1, 2, 3;
because { $_ < 2 } is a Block, not a Routine! it should be written
like this:
sub smaller_than_two ($value) { return $value < 2 }
mygrep smaller_than_two, 1, 2, 3;
but this doesn't seem to make much sense. one should probably have
said 'Code &block' (or '&block' alone, which I suppose is just the
same), but then what's the use of 'Routine', 'Sub', 'Method' etc. as
types?
also, it's not clear to me the distinction between isa-relationship
and namespace. I see that 'Rule' (and I presume 'Sub', 'Routine',
'Code', etc.) are all type names, but I wonder if 'Bare' is a type of
its own -- or it is 'Block::Bare'? the latter sounds much better :-)
in my class hierarchy I mixed 'probable' isa-relationships (eg. Sub
isa Routine isa Code) with 'probable' proper namespace hierarchy (eg.
Exception::Control::return, not return isa Control isa Exception).
and this is probably very, very wrong.
or maybe I'm just playing with dangerous toys that aren't intended for
a little kid like me :-)
> I think Type should be called Value, and that arrays should possibly
> be a mixin of lists, but apart from that it looks fine. Oh, and you
> missed out Grammars; ...
thanks, applied :-)
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Larry Wall
: Simon Cozens wrote:
: > ...and I don't know if macros are actually objects and can be tossed
: > around, or if they're just part of the compilation process.
:
: they have their proper place in the diagram Larry put in A6.
: furthermore, he says:
:
: "These syntactic forms correspond the various Routine types in the
: Code type hierarchy"
:
: so Macro seems to be at least a type. which leads me to the question:
: is Macro "also" a class? and which is the difference between a type
: and a class? hm, I guess this will be answered in A12, so I'll
: probably have to wait on this.
Well, I'm using the terms type and class pretty much interchangeably
there, so don't put too much weight on that. But Perl 6 may well
distinguish classes from types. Classical classes can only add
capabilities when you derive (yes, you can redefine methods to do less,
but the interface is still there). When I think of types, I'm thinking
of parameterizing a class with some constraints. In the Ada world,
that's called "subtyping". Whether these contraints are mathematical
("must be an even number") or structural ("must have dimensions
(3,3,3)"), they still cut down on the allowed set of values for the
base type.
It's possible to get along with just classes, if you say that subtyping
is done only by setting various attributes (such as the dimensions of
the array) on each individual object. But even if subtyping ends up
implemented that way under the hood, it's a very convenient way to
abstract a set of potential values and operations in the user's head,
and to communicate the exact intent to whoever has to maintain the
code later. You may know that this Int has to be an even number, but
it helps to be able to declare it as Even. And to the extent that
the computer can help you enforce the constraints, you get better
invariants.
If you say
$foo.isa(Even)
it doesn't just check to see if $foo is a member of class Int,
but it also checks the constraints on type Even, and returns false
unless $foo is an even integer.
We could still call Even a class if we wanted to, but it seems useful
to me to distinguish classes that work "right" from classes that
engage in hanky-panky. I think of types as being "semi-instantiated".
In a sense, this is currying of classes.
: I also have another question (probably related, and probably also for
: later). consider this:
:
: sub mygrep( Code &block, *@list is rw ) {...};
: sub mygrep( Block &block, *@list is rw ) {...};
: sub mygrep( Routine &block, *@list is rw ) {...};
: sub mygrep( Sub &block, *@list is rw ) {...};
: sub mygrep( Method &block, *@list is rw ) {...};
:
: is something like this allowed? and what is the meaning then? if logic
: serves me correctly, this shouldn't work:
:
: sub mygrep( Routine &block, *@list is rw ) {...};
: mygrep { $_ < 2 }, 1, 2, 3;
:
: because { $_ < 2 } is a Block, not a Routine! it should be written
: like this:
:
: sub smaller_than_two ($value) { return $value < 2 }
: mygrep smaller_than_two, 1, 2, 3;
:
: but this doesn't seem to make much sense. one should probably have
: said 'Code &block' (or '&block' alone, which I suppose is just the
: same), but then what's the use of 'Routine', 'Sub', 'Method' etc. as
: types?
Those types are mostly for dynamic activities like chasing up your
call stack and doing smart matching.
: also, it's not clear to me the distinction between isa-relationship
: and namespace. I see that 'Rule' (and I presume 'Sub', 'Routine',
: 'Code', etc.) are all type names, but I wonder if 'Bare' is a type of
: its own -- or it is 'Block::Bare'? the latter sounds much better :-)
No, they're derived classes, not inner packages.
: in my class hierarchy I mixed 'probable' isa-relationships (eg. Sub
: isa Routine isa Code) with 'probable' proper namespace hierarchy (eg.
: Exception::Control::return, not return isa Control isa Exception).
: and this is probably very, very wrong.
Whether derived classes should be hidden within their base class is
not a simple question. It really depends on Huffman to some extent.
Most control exception types aren't used all that often, at least
not explicitly. In contrast, the Code classes are likely to be used
frequently in signatures.
: or maybe I'm just playing with dangerous toys that aren't intended for
: a little kid like me :-)
The Code classes are likely to be MISused frequently in signatures. :-)
Larry
Chromatic
> If you say
>
> $foo.isa(Even)
>
> it doesn't just check to see if $foo is a member of class Int, but it also
> checks the constraints on type Even, and returns false unless $foo is an even
> integer.
>
> We could still call Even a class if we wanted to, but it seems useful to me to
> distinguish classes that work "right" from classes that engage in hanky-panky.
> I think of types as being "semi-instantiated". In a sense, this is currying of
> classes.
Is isa() the right name?
Distinguishing between type and class seems very useful. A type signature says
"I want something that has these traits". Checking isa says "I want something
that has this place within a class hierarchy."
Attaching type information to a class makes sense -- you've got downwards
substitutability there, but checking "is it this class or a descendant" when all you really
mean is "does it have these traits" is way too specific and prevents a lot of
substitutability.
It's a subtle distinction. Allomorphism, anyone?
-- c