working Edison, a couple of collection modules, and typing troubles
Whatever happened to Edison? I want to play with it and the one in the HFL cvs repository won't build for me (and uses flat names). I was trying my hand at writing some collection classes myself and I can't figure out a good typing for map that will let me make Map an instance of my Collection class... I'm attaching what I have so far. I don't much like the head of Mapping. I expect oleg will have some crazy type-system trick up his sleeve. -- Thankful-in-advance-ly yrs, Sam
On Wed, 2005-05-25 at 15:23 -0400, Samuel Bronson wrote:
Whatever happened to Edison? I want to play with it and the one in the HFL cvs repository won't build for me (and uses flat names).
I was trying my hand at writing some collection classes myself and I can't figure out a good typing for map that will let me make Map an instance of my Collection class...
In my opinion, if this Collection class is the root class, it is not
general enough, and it is very difficult to get Maps to fit nicely into
such a class. If you look at Java Classpath for example, the Maps are
not instances of Collection, mainly because it is illogical to have an
add function (which just takes an element value) for a Map. I don't like
the tuple method (although I've used it myself) because I don't think it
accurately represents what the element type of a Map is and won't retain
function type backward compatibility (e.g. for insert).
I think what you really need to do is abstract further, layering another
class on top of Collection, and have Collection just contain empty (or
null) and size. This way it applies to any data-structure with multiple
elements and a starting value (e.g. Stacks). Then you can have a class
called say AbstractMap which contains the lookup, addition and deletion
function relevant to Maps, one called AbstractSet which contains set
based operations and so on.
-Si.
--
Simon David Foster
On 26/05/05, Simon David Foster
On Wed, 2005-05-25 at 15:23 -0400, Samuel Bronson wrote:
Whatever happened to Edison? I want to play with it and the one in the HFL cvs repository won't build for me (and uses flat names).
I was trying my hand at writing some collection classes myself and I can't figure out a good typing for map that will let me make Map an instance of my Collection class...
In my opinion, if this Collection class is the root class, it is not general enough, and it is very difficult to get Maps to fit nicely into such a class. If you look at Java Classpath for example, the Maps are not instances of Collection, mainly because it is illogical to have an add function (which just takes an element value) for a Map. I don't like the tuple method (although I've used it myself) because I don't think it accurately represents what the element type of a Map is and won't retain function type backward compatibility (e.g. for insert).
Would you believe that I actually wrote the Mapping class first and factored most of it out into Collection, changing the signatures as I went? I admit that breaking backwards compatability is a pain, but that doesn't make it always a bad idea. Even if this by some freak chance made it into the standard library, we wouldn't have to export the new functions from Data.Map (etc.) right away, so it wouldn't be that bad.
I think what you really need to do is abstract further, layering another class on top of Collection, and have Collection just contain empty (or null) and size. This way it applies to any data-structure with multiple elements and a starting value (e.g. Stacks). Then you can have a class called say AbstractMap which contains the lookup, addition and deletion function relevant to Maps, one called AbstractSet which contains set based operations and so on.
Hmm, I don't know if that would give me what I set out to get in the first place. Namely, not having one thing (which thing is []) hog all the good names. It sounds complicated, too, but then again I guess that is what I get for opening this can of worms again. I wish there was nice darcs hosting somewhere so I could put this up and we could play with it...
participants (2)
-
Samuel Bronson -
Simon David Foster