On Sun, Nov 27, 2005 at 08:47:54PM +0000, Rob Ennals wrote:
On 11/23/05, David Roundy <droundy@abridgegame.org> wrote:
3. "Safe" getters for multi-constructor data types: ditto
I think either you misunderstood my meaning by "safe", or I misunderstood your paper. I meant that if I write
data FooBar = Foo { foo :: String } | Bar { bar :: String }
there shouldn't be accessors of type
foo :: FooBar -> String bar :: FooBar -> String
I did indeed misunderstand what you meant by "safe". Bottom is indeed a nasty thing.
Perhaps such definitions should generate a warning? (banning them outright would cause compatability issues)
Yeah, issuing a warning (which can become an error with -Werr) is a nice option. The other option would be some sort of syntax to declare that a particular record is unordered. Or I suppose to just give up on backward compatibility. Any of these three alternatives would be fine with me.
7. Unordered records: yep (if I understand the problem correctly)
I don't think you understood correctly.
I was thinking along the same lines as Wolfgang : don't export the internal representation of the type, but do expose the field manipulator functions.
This needn't prevent the use of pattern matching, provided the desugaring of patterns is consistent with the rest of the system.
E.g. I was assuming that
case e of { x = 3, y = 4} -> ...
would desugar to
case e of _ | x z = 3 && y z = 4 -> ...
Note that this pattern matching syntax will continue to work, even if 'x' and 'y' are reimplemented as normal functions, rather than fields.
Indeed, it hadn't occurred to me to make pattern matching work this way. It actually sounds a lot like pattern guards, since you're suggesting this sugar could be applied to any sort of object? So your desugarer would allow a function like islong :: [a] -> Bool islong {length = l} = l > 10 -- David Roundy http://www.darcs.net