Changes between Version 3 and Version 4 of Ticket #86


Ignore:
Timestamp:
Feb 3, 2006 2:40:24 AM (8 years ago)
Author:
flippa
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #86 – Description

    v3 v4  
    55There are some further possible extensions to this idea: 
    66 
    7  1. Allow _ in class contexts to mean one or both of "and additional constraints" or "some type variable that will be inferred". 
     7 1. Allow _ in class contexts to mean one or both of "and additional constraints" or "some type variable that will be inferred". Currently this isn't a well-developed idea, I haven't thought much about it - I like the idea of having a way to say "please don't fall over if I missed out a constraint" though. 
    88 1. Allow "metavariables" (no longer actually meta due to being in the type system, of course) which might be written _a and appear multiple times in the same annotation always meaning the same type. 
    99  * Add some kind of binder for metavariables and give them lexical scope much as can be done with ordinary type variables. If we do this, top-level bindings would also make sense and allow us to name types we'd like inferred for us before using them as part of type declarations 
    1010  * Allow some kind of constraints between metavariables (Frank Atanassow mentioned this to me on #haskell-blah) 
     11 
     12Pros: 
     13 
     14 * Allows type annotations to convey information they need to without forcing the programmer to infer things the compiler should for them 
     15 * Can be used to get a complete type before filling in a permanent annotation 
     16 * Helps scale type annotations to cope with increasingly large types 
     17 * Metavariables provide similar readability benefits to type annotations while being more change-resistant due to inference 
     18 
     19Cons:  
     20 
     21 * It's a new and untested feature 
     22 * It could encourage sloppy programming style 
     23 * Readability benefits are also untested