Changes between Version 8 and Version 9 of ExistingRecords


Ignore:
Timestamp:
Mar 5, 2006 9:57:16 AM (8 years ago)
Author:
malcolm.wallace@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ExistingRecords

    v8 v9  
     1[[PageOutline]] 
     2= Tweaks to the existing record system = 
     3 
    14This page is used to discuss _minor_ tweaks to the existing record system if it is decided that it will be left in basically unchanged. radical or brand new record systems should be discussed elsewhere. 
    25 
    3  * reallow punning, Foo {x,y,z} would be interpreted as Foo {x = x, y = y, z = z} in both declaration and pattern matching contexts. 
     6== Punning == 
     7Reallow punning, Foo {x,y,z} would be interpreted as Foo {x = x, y = y, z = z} in both declaration and pattern matching contexts. 
    48 
    5  * update syntax should not bottom out when fields are undefined. as in 
     9== Update == 
     10Update syntax should not bottom out when fields are undefined. as in 
    611 
    712   {{{ 
     
    2025   }}} 
    2126 
    22  
    23  * label-based pattern matching 
     27== Label-based pattern-matching == 
    2428 
    2529   the function: 
     
    4145   something we really want in the end anyhow.  Not sure how to fix this.  val@{x="foo")? 
    4246 
    43  * first class update and setting syntax (more advanced, needs better syntax) 
    44  
    45    A syntax for updating and setting fields should be allowed. 
    46  
    47    some possibilites are  
     47== First-class syntax == 
     48First class update and setting syntax (more advanced, needs better syntax). 
     49A syntax for updating and setting fields should be allowed.  Some possibilites are  
    4850 
    4951   {{{ 
     
    6163   }}} 
    6264 
    63  * polymorphic record update 
     65== Polymorphic record update == 
    6466 
    6567   Given a record like: 
     
    7678 
    7779 
    78 == open statement == 
     80== 'Open' statement == 
    7981 
    8082having the ability to 'open' a record bringing all its values into scope would be useful for techniques such as first class modules when combined with PolymorphicComponents. a proposal is 
     
    100102open x would be allowed at the top level, in a let binding, or in a where binding. 
    101103 
    102 == abstraction == 
     104== Abstraction == 
    103105 
    104106It is often useful to limit the ability of users to fill in or access parts of a data type arbitrarily to maintain invariants, instituting the following rule would let you enforce that to some degree: 
     
    107109 
    108110This would insure that by not exporting a field label, it cannot be gotten around by using positional notation. 
     111This fix would also require the polymorphic setting ability mentioned above and would partially mitigate the need for ReadonlyConstructors 
    109112 
    110 this fix would also require the polymorphic setting ability mentioned above and would partially mitigate the need for ReadonlyConstructors 
     113= Meta-Proposal = 
     114 
     115Due to a lack of experience with alternative record systems, the consensus seems to be that we should stick with the current system, perhaps with a few of the minor tweaks mentioned above.  (Which ones is a question still open for discussion.) 
     116 
     117However, the main reason for there being little use of alternative 
     118candidates, would seem to be that they are not compatible with current Haskell. 
     119Thus, it would be useful to have some mechanism for experimental 
     120records to be tried out in real Haskell implementations before the 
     121next language committee (Haskell-double-prime) starts its work.  Then there might be a possibility of one of them being accepted. 
     122 
     123A concrete suggestion is that we separate out everything from the Report to do 
     124with named-field records into something like a self-contained addendum. 
     125Whilst still an official part of the language standard, it might also be 
     126marked as a possibility for future removal.  This would make it clear 
     127what parts of the language could be changed (or re-used without conflict) 
     128in an alternative records system.  The re-use part is especially important, since taking some of the same syntax to mean something different is pretty-much essential for useability.