On Fri, Mar 14, 2003 at 05:21:46PM +0100, Aldo Calpini wrote:
: 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, [EMAIL PROTECTED] is rw ) {...};
: sub mygrep( Block &block, [EMAIL PROTECTED] is rw ) {...};
: sub mygrep( Routine &block, [EMAIL PROTECTED] is rw ) {...};
: sub mygrep( Sub &block, [EMAIL PROTECTED] is rw ) {...};
: sub mygrep( Method &block, [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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

Reply via email to