Changes between Version 14 and Version 15 of ExistentialQuantification


Ignore:
Timestamp:
Feb 1, 2006 10:57:46 AM (8 years ago)
Author:
malcolm.wallace@…
Comment:

make original proposal and extension more clearly separate

Legend:

Unmodified
Added
Removed
Modified
  • ExistentialQuantification

    v14 v15  
    8787 * The Omega language based on Haskell has an 'exists' keyword to denote an existential type. 
    8888 
    89 == Extension: better syntactic support == 
     89== Pros == 
     90 * offered by GHC, Hugs and Nhc98 for years, HBC even longer. 
     91 * typing rules well understood. 
     92 * quite handy for representations that delay composition or application, e.g. objects, various parser combinator libraries from Utrecht. 
     93 
     94== Cons == 
     95 * tricky to implement on implementations without a common runtime representation of values such as jhc. 
     96 
     97 
     98 
     99= Extension: better syntactic support = 
    90100 
    91101Discussion on the list in late January focussed on a [http://www.haskell.org//pipermail/haskell-cafe/2005-June/010516.html proposal from Johannes Waldmann] to add syntactic support for the use of existential types.  
    92102 
    93 === Background example === 
     103== Background example == 
    94104 
    95105The status quo is illustrated by the concrete example of geometrical figures, each of which is an instance of an interface given by the Haskell class 
     
    107117but boxing needs to be explicit. 
    108118 
    109 === First proposal === 
     119== First proposal == 
    110120 
    111121The extension proposed here is to hide the existence of the data type and constructor `EFigure`, just referring to `Figure` instead. The issue becomes one of conversion between the figure types `Circle` and `Rectangle` and the type `Figure`. A concrete example is given by 
     
    121131for instance.  
    122132 
    123 === Consensus proposal: an existential for each single parameter class === 
     133== Consensus proposal: an existential for each single parameter class == 
    124134 
    125135The consensus proposal based on the discussion is automatically to introduce an existential type for each single parameter type class. The type and class would have the same name, as in 
     
    130140}}} 
    131141Discussion focussed on whether there should or should not be automatic conversion from figure types into `Figure`; it was agreed that the `Figure` constructor could be used to do this, with the `Figure` instance providing the unboxing required. 
    132  
    133 == Pros == 
    134  * offered by GHC, Hugs and Nhc98 for years, HBC even longer. 
    135  * typing rules well understood. 
    136  * quite handy for representations that delay composition or application, e.g. objects, various parser combinator libraries from Utrecht. 
    137  
    138 == Cons == 
    139  * tricky to implement on implementations without a common runtime representation of values such as jhc. 
    140