At 18:18 22/04/04 -0400, Mark Carroll wrote:
I have data objects where each component is a labelled field through which I access or modify it.
Wading into the labelled field debate... I have found that using the labelled field update syntax can lead to difficulties in changing the underlying implementation of a type. I found this in particular when re-implementing the Network.URI module: I found that I needed to change the internal representation of the URI type in order to satisfy the recently clarified URI specification. The knock-on effect of this was mitigated to some extent by implementing the original field names as functions to extract values corresponding to the original components. But I found when porting the HXml Toolbox and/or HTTP code to use this new implementation that while field references would still work as intended, occurrences of the field update syntax had to be re-coded; there remained external dependencies on the internal structure of URI that could not be "shimmed" away with new functions. This leads me to ask, if new syntax approaches for labelled fields are being considered, if it would be possible to adopt an approach in which the field name works like a function for both access *and* updating of a field record. A clumsy example of this might be a field name used as a query-and-set function: data record { field :: atype, ... } yields field :: record -> (atype -> atype) -> (record,atype) then arecord :: record arecord = ... fval = snd field arecord id -- returns value of field rval = fst field arecord (const newval) -- returns updated record (this is to illustrate a desideratum, not a serious suggestion. Something is tickling the back of my mind about possibly doing this with a Monad.) With a field name working as a function (the same function) for both access and update, it is then possible to change the internal structure of a record yet retain the possibility of presenting a backwards-compatible interface. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact