At 15:33 17/06/04 -0700, John Meacham wrote:
I think it was a couple things, Pattern guards were introduced which were conceptually a whole lot simpler and provided a way to do many of the things views did. http://research.microsoft.com/~simonpj/Haskell/guards.html
I like that proposal. In response to: [[ Is this a storm in a teacup? Much huff and puff for a seldom-occurring situation? No! It happens to me ALL THE TIME. The Glasgow Haskell Compiler is absolutely littered with definitions like clunky. I would really welcome feedback on this proposal. Have you encountered situations in which pattern guards would be useful? Can you think of ways in which they might be harmful, or in which their semantics is non-obvious? Are there ways in which the proposal could be improved? And so on. ]] I'll say that in my programming, I would find that feature really useful. For example, in my work on Network.URI, I found I had to change the underlying data type. While I don't think this proposal would deal with the legacy problem, I do think it would make it easier to define an interface that better supports future changes. I notice some similar potential issues with the XML library I'm currently working on: the algebraic data types comprise a considerable part of the package interface, which is not always satisfactory. And a small thought: a current convenience with algebraic data types is the facility to export/import the constructors with (..) notation. I think it would be useful to extend this to accessor functions that are somehow bound to the ADT definition. Hmmm... would this make any sense?: [[ data URI = URI { uriScheme :: String , uriAuthority :: Maybe URIAuth , uriPath :: String , uriQuery :: String , uriFragment :: String } deriving Eq where scheme (URI {uriScheme=""}) = Nothing scheme (URI {uriScheme=a}) = Just a : etc. ]] The idea here being that functions declared in the 'where' block would be included in any export/import of URI(..). Then, also, some way to hide the individual field labels might also be useful to hide the internal structurte from that exposed. ... The other problem I've noticed with ADTs (which I think has been discussed before) is that field labels work like functions to access fields, but there's no corresponding mechanism for selective update using the same name. I could imagine something like: scheme :: a -> b -> (a,b) scheme a' u@(URI {uriScheme=a}) = (a,u {uriScheme=a'}) with auxiliaries: get :: (a -> b -> (a,b)) -> b -> a get f = fst . f undefined update :: (a -> b -> (a,b)) -> a -> b -> b update f a = snd . f a hence s = get scheme uri and uri' = update scheme s uri ... #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact