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. --
