Changes between Version 1 and Version 2 of PartialTypeSigs

Jan 25, 2006 11:02:56 AM (9 years ago)



  • PartialTypeSigs

    v1 v2  
    66== Brief Explanation == 
    8 I am not quite sure what this page is supposed to be about, but I guess it concerns the possibility of leaving 
    9 out parts of type signatures which is an issue I would like to raise. Reasons for doing this include 
    10 that parts of a signature can be obvious and bulky, and thus just would add clutter. 
    11 One could imagine allowing e.g. an underscore to be used as an anonymous type variable. However, unlike 
    12 a normal type variable, no attempt would be made to generalize it to a universally quantified variable. 
     8The possibility to omit parts of type signatures. 
     10Support a 'wildcard' type (probably written "_" to  match the pattern-matching syntax) that matchs any inferred type (an ''anonymous'' type variable), without requiring any actual degree of polymorphism the way a real type variable does.  I.e. Unlike a normal type variable, no attempt would be made to generalize underscore to a universally quantified variable. 
    1311It stands for a specific but unspecified type. 
    15 Similarly, it would sometimes be convenient to be able to leave (part of) a context unspecified. 
     13This  allows 'partial' annotations, making it easier to provide the type system with extra information, but without having to supply potentially complicated parameters that it can infer itself. Possibly the same thing can also be used in a type context to indicate zero or more predicates other than those specified. 
     15Reasons for doing this include that parts of a signature can be obvious and bulky, and the consequent clutter can obscure the important or interesting part of the signature. 
     17== Questions == 
     18  * does _ only work for types, or also for class contexts? 
     19  * how would the exact syntax be? 
     20  * if you have multiple underscores, they're all different, I guess; 
     21    but wouldn't you want also to be able to say that a type is 
     22    "_a -> _a" for some "_a"? 
     23  * are there any interactions with typechecking of rank-n types or 
     24    GADTs? 
    1726== References == 
    1928== Pros == 
    2029 * Convenience 
     30 * The disadvantage of the current Haskell solution is that it is so much 
     31   "all or nothing". You cannot have the benefits of inference without 
     32   losing the benefits of documentation. For complex class contexts (and 
     33   even more for implicit parameters), it would be extremely helpful to 
     34   have the possiblity to omit parts of a type signature, and even in 
     35   normal situations it can be helpful. 
    2237== Cons ==