Front page | perl.perl6.language |
Postings from March 2005
Larry Wall wrote:
> One can always mixin a "does LinearInterpolation" at run time in the
> body of the sub to get the effect of a directive, so I think the most
> useful thing is to treat roles in signatures as constraints where
> they can be used to select for MMD.
Further questions concerning MMD:
1) How are the classes of
a) the container
b) the value
used in dispatch? Note that 'Array of Num' in other languages
is more like a parameter on the template/generic: Array[Int].
Does it hold for Perl 6 in general that the 'of' is syntactic
sugar for (container) class specialisation? E.g. could Damian's
example of Source[Perl] be written as 'Source of Perl'?
Should the programmer get the chance to define if the type parameter
is either covariant or contravariant like the extends/super in Java5
generics?
2) how are the where clauses used in MMD relative to roles and classes?
3) I guess the distance function is not specified yet, right? Is it at
least symmetric, so that it avoids the surprises that CLOS has in store
with its linearisations? The multiple inheritance resolution is also
relying on user intervention and not calculating a class precidence
list as Dylan does. Symmetic means the following:
with
class Base {...}
class Left is Base {...}
class Right is Base {...}
there are at most three binary multis allowed
multi sub foo ( Base $x, Base $y ) {...}
multi sub foo ( Left $x, Left $y ) {...}
multi sub foo ( Right $x, Right $y ) {...}
otherwise a call like foo( Base.new, Right.new ) would be ambigous.
In other words a conflict where one multi is more specific here and
another there is reported and not somehow "resolved".
4) what's the intent of trait_auxiliary:shall?
> : I still wonder how the type system really works...
>
> Me too. If it's any comfort, just think of the design of Perl 6 as
> a genetic algorithm running on a set of distributed wetware CPUs.
> We'll just keep mutating our ideas till they prove themselves adaptive.
At the very heart a type system is something simple: it defines an order.
Or actually two intertwinned ones: the subtype relation and the inheritance
relation. The typechecker, the optimizer and the dispatcher use this order
to enlighten or annoy the programmer, to decide what code to generate and
which method to call respectively.
With junctive values on types it should be easy to define a lattice that
consists of user specified and calculated nodes. This is what I tried
to explain elsewhere---without having clear vision how that fits into the
Perl 6 Genom :)
Last not least the parametric polymorphism should be accompanied by a
constraints system to get CBP (Constraint-Bounded Polymorphism) which
is a superset of F-Bounded Polymorphism. This proposal is polymorphic
as well: some consider it Hell others Heaven---with roles flipped when
it comes to excessive use of (implicit) Any ;)
MfG
--
TSa (Thomas Sandlaß)
Thread Previous
|
Thread Next