HaloO,

Jonathan Lang wrote:
At its core, a type is nothing more than a constraint on the objects
that a given variable is allowed to handle; this would put C<where>
clauses at the center of the type system, with roles coming in a very
close second due to the implicit use of ".does()" in the compact
syntax.


Great idea! I like the unification of everything typish under the
umbrella of (type) constraints. These predicates then need to be
amenable to subsumption and entailment forming the dispatch lattice.
Of course the sublanguage for where clauses has to be a restricted
subset of full Perl 6. Otherwise you can't do machine proofs. This
view is shared by mmd-draft.txt, it states that conceptually all
dispatch relevant informations are predicates.

Hmm, having regular expressions in where clauses already raises
the question if one can treat them programatically. E.g. a
'where /^aa.*bb$/' is strictly more specific than 'where /^a.*b$/'.
But can that be calculated in a deterministic fashion? Would
dispatch at least work on a case by case basis? Or would we get
ambiguity errors because of principal incomparability of the two
clauses? IOW, I fear this could only be put to work with two subset
declarations

  subset ab of Str where /^a.*b$/;
  subset aabb of ab where /^aa.*bb$/;

and the notion that the second subset by virtue of constraining
the possible values further produces a more specific subtype for
dispatch. That is nominal subtyping.

BTW, the above example is a good case for introducing the subtype
relation operator <: because we have aabb <: ab <: Str but do we
also have aabb.does(ab) and ab.does(Str)? Could we also state that
aabb (<) ab (<) Str?


Regards, TSa.
--

Reply via email to