On 25-May-1999, Koen Claessen [EMAIL PROTECTED] wrote:
Christian Maeder wrote:
| An abstract data type should not reveal its realization.
Indeed! And therefore, an abstract datatype should not impose silly
restrictions on the context where they are not needed. How I implement a
set (for
But what type does the selector 'item' have? Phil, Mark and Jeff think:
item :: Ord a = Tree a - a
This looks correct to me, too.
If an order is needed to construct a tree, say a search tree, the very same
order is (or may be) needed to select an item, e.g. by
Christian Maeder wrote:
| An abstract data type should not reveal its realization.
Indeed! And therefore, an abstract datatype should not impose silly
restrictions on the context where they are not needed. How I implement a
set (for example using ordered binary trees or a hash table), is part
Hi Phil!
| (Mark says it was very tricky to implement what Hugs does)
|
| I can't imagine why. Perhaps Mark can explain?
I should clarify. Arranging for constraints that appear in the types of
constructors to show up whenever that constructor is used --- whether in
an application or a
Folks,
Interesting! Phil, Mark, and Jeff all have a different interpretation of
how contexts on how data type declarations work than I did. So unless
some other people chime in, I will therefore adopt their interpretation,
since (a) I'm in the minority and (b) it's not a big deal at all.
But
Interesting! Phil, Mark, and Jeff all have a different interpretation of
how contexts on how data type declarations work than I did. So unless
some other people chime in, I will therefore adopt their interpretation,
since (a) I'm in the minority and (b) it's not a big deal at all.
I agree
Simon Peyton-Jones wrote:
| Speak now or put up with overloaded selectors!
I don't know if this is of any interest to this discussion, but
the way I like interpreting a definition like:
data Eq a = Set a = MkSet [a]
is that every set knows how to compare its elements. Unfortunately,
this
So doesn't my proposal give you precisely what you want, and no more?
Because my interest is as much in documentation as in constraints on
how the program executes (I admit your method achieves the latter).
If I write, say,
data Eq a = Assoc a b
then I'd like the signatures to ensure that
I'm happy with either of the following choices:
* Class constraints on constructors have effect everywhere
(as in Hugs).
* Class constraints on constructors are eliminated (call it a
typo if you must).
I'd be delighted to eliminate them, but we had a long H98 debate
about it (under
