Re: [Haskell] Re: Data.Set whishes
I have always wondered why the module system is not used at all in these conventions. I mean, the function names seem to come straight from the Haskell 1.2 days when there was no module system! I used the module system in this way in the first version of the HGL (http://haskell.org/graphics/). For example, fonts, colours, etc all provided three operations 'create', 'delete' and 'select' instead of 'createFont', 'createColor', etc. If (as was common), you imported several of these modules, you would use 'Font.create', 'Color.create', etc. All seemed very clean. I deliberately switched away from this in the second release because it wasn't working very well. The problem is that most users don't want to have to write: import Font import Color import Window [about 10 such modules in total] they just want to write: import Graphics where the Graphics module imports Font, Color, Window, etc and re-exports them. The problem is that you can't use any of the 'create' functions if you import Graphics since any reference to 'Graphics.create' would be ambiguous. Haskell's module system provides a way for a module to merge multiple modules into one but provides no way to eliminate any ambiguities this may create. If we want to be able to use names like 'create' instead of 'createFont', we need to change the module system. The obvious fix would have some of the flavour of the ML module system where a module can export a structured list of names instead of exporting a flat list of names. -- Alastair Reid ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
Alastair Reid [EMAIL PROTECTED] wrote: Haskell's module system provides a way for a module to merge multiple modules into one but provides no way to eliminate any ambiguities this may create. If we want to be able to use names like 'create' instead of 'createFont', we need to change the module system. The obvious fix would have some of the flavour of the ML module system where a module can export a structured list of names instead of exporting a flat list of names. i'm not familiar with ml's module system so i don't know if my suggestion is the same or similar, but could a good solution be to allow modules to be exported as qualified modules? for example module Graphics ( module Font qualified, module Color qualified, module Window qualified, ... ) where ... chris moline ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
G'day all. Quoting Ketil Malde [EMAIL PROTECTED]: One could possibly argue that the right solution is to put the operations in classes? One could also argue that the right solution is first-class modules. :-) Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
G'day all. Quoting Koen Claessen [EMAIL PROTECTED]: I think Chris Okasaki did a nice job and made a good data structure library proposal with Edison (years ago). It uses both the qualified names trick and type classes. Why nobody uses it (or even knows about it) is a mystery to me. My personal take on why nobody uses it is that when you have a large library of data structures, all of which support various interfaces, the problem arises as to how you pick which one to use. Without looking, what is the difference between a BraunSeq and a BankersQueue? I've also found it hard to merge data structures which are embedded in a monad with data structures which are not. Getting a consistent interface there is hard. If you can think of a solution to either or both of these problems... Hereby, I call for a revival of Edison! :-) ...give me your sourceforge ID and I'll add you as a developer. :-) Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
| http://www.haskell.org/hierarchical-modules/libraries/library-design.html I have always wondered why the module system is not used at all in these conventions. I mean, the function names seem to come straight from the Haskell 1.2 days when there was no module system! What I mean is, instead of: newIORef, writeIORef, readIORef We could have: IORef.new, IORef.write, IORef.read (Or: new, write, read if all we use are IORefs.) And instead of: mapSet, emptySet, ... We have: Set.map, Set.empty, ... This is how Chris does it in Edison. Why isn't this used more? /Koen -- Koen Claessenhttp://www.cs.chalmers.se/~koen/ Chalmers University of Technology, Gothenburg, Sweden ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
I think it's because of tradition. Originally Haskell didn't have qualified names, only renaming. (Which, IMHO, was a wrong decision in the original Haskell design.) -- Lennart Koen Claessen wrote: | http://www.haskell.org/hierarchical-modules/libraries/library-design.html I have always wondered why the module system is not used at all in these conventions. I mean, the function names seem to come straight from the Haskell 1.2 days when there was no module system! What I mean is, instead of: newIORef, writeIORef, readIORef We could have: IORef.new, IORef.write, IORef.read (Or: new, write, read if all we use are IORefs.) And instead of: mapSet, emptySet, ... We have: Set.map, Set.empty, ... This is how Chris does it in Edison. Why isn't this used more? /Koen -- Koen Claessenhttp://www.cs.chalmers.se/~koen/ Chalmers University of Technology, Gothenburg, Sweden ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
Koen Claessen wrote: And instead of: mapSet, emptySet, ... We have: Set.map, Set.empty, ... This is how Chris does it in Edison. and Daan Leijen in DData: http://www.cs.uu.nl/~daan/ddata.html Christian (Well, Set.map is actually missing there) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
Am Freitag, 20. Februar 2004 10:23 schrieb Koen Claessen: http://www.haskell.org/hierarchical-modules/libraries/library-design.html I have always wondered why the module system is not used at all in these conventions. I mean, the function names seem to come straight from the Haskell 1.2 days when there was no module system! What I mean is, instead of: newIORef, writeIORef, readIORef We could have: IORef.new, IORef.write, IORef.read (Or: new, write, read if all we use are IORefs.) And instead of: mapSet, emptySet, ... We have: Set.map, Set.empty, ... This is how Chris does it in Edison. Why isn't this used more? /Koen Hello, the naming scheme you mention is nice, in my opinion. Alas, it has a problem with hierarchical module names. For example, you cannot write Set.empty but have to write Data.Set.empty instead. As modules get more and more nested, the qualified names get longer and longer. A solution would be if Haskell would allow partially qualified names, e.g., you import Data and are able to say Set.empty afterwards. Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Re: Data.Set whishes
Excuse my ignorance, but why can't you just say: import qualified Data.Set as Set Hello, the naming scheme you mention is nice, in my opinion. Alas, it has a problem with hierarchical module names. For example, you cannot write Set.empty but have to write Data.Set.empty instead. As modules get more and more nested, the qualified names get longer and longer. A solution would be if Haskell would allow partially qualified names, e.g., you import Data and are able to say Set.empty afterwards. Wolfgang - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
Am Freitag, 20. Februar 2004 12:51 schrieb Bayley, Alistair: Excuse my ignorance, but why can't you just say: import qualified Data.Set as Set You can do so. I knew itI'd have missed something. ;-) [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
Koen Claessen [EMAIL PROTECTED] writes: And instead of: mapSet, emptySet, ... We have: Set.map, Set.empty, ... This is how Chris does it in Edison. Why isn't this used more? One could possibly argue that the right solution is to put the operations in classes? There has from time to time been suggestions and discussion about doing this, but I guess there are significant obstacles -- surely, somebody must have tried to clean this up? Or is using MPTC (which possibly will be necessary?) regarded as too non-standard for a library? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
Wolfgang Jeltsch [EMAIL PROTECTED] writes: Am Freitag, 20. Februar 2004 10:23 schrieb Koen Claessen: http://www.haskell.org/hierarchical-modules/libraries/library-design.html What I mean is, instead of: newIORef, writeIORef, readIORef We could have: IORef.new, IORef.write, IORef.read Alas, it has a problem with hierarchical module names. For example, you cannot write Set.empty but have to write Data.Set.empty instead. Use module renaming: import Data.Set as Set A solution would be if Haskell would allow partially qualified names, e.g., you import Data and are able to say Set.empty afterwards. There was an optional part of the original proposal for hierarchical module names, that the last segment of the hierarchy be automatically regarded as a renaming. e.g. import X.Y.Z could be treated equivalent to import X.Y.Z import X.Y.Z as Z This has been implemented in nhc98 since 2001. Regards, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
| One could possibly argue that the right solution is to | put the operations in classes? The problem is that sometimes the type of an operation on a particular data structure is not completely according to the general structure. There might be extra restrictions on the type arguments for example (think of Set.map), or there might be an extra argument required or something. Nothing that stops you from having the same name! Also, I think the existence of a possibly better solution (using type classes) is no argument of having names like mapSet and newIORef all over the place. BTW, I realize that it is not easy to change the names of existing libraries, even if their naming scheme is horribly inconsistent, with Data.FiniteMap and Data.Set as good (?) examples. But there is no reason to make a fresh start when designing the naming scheme *standard* for (new) libraries. Why is the naming scheme standard, described at: http://www.haskell.org/hierarchical-modules/libraries/library-design.html still using Haskell 1.2 naming schemes? Do people simply not like qualified names? | There has from time to time been suggestions and | discussion about doing this, but I guess there are | significant obstacles -- surely, somebody must have tried | to clean this up? I think Chris Okasaki did a nice job and made a good data structure library proposal with Edison (years ago). It uses both the qualified names trick and type classes. Why nobody uses it (or even knows about it) is a mystery to me. (The reason Chris gave himself is that he did not completely populate his data structure library framework and that people rather implement their own data structures then instead of fitting them into his framework.) Hereby, I call for a revival of Edison! :-) Regards, /Koen ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Data.Set whishes
Koen Claessen wrote: [...] Why is the naming scheme standard, described at: http://www.haskell.org/hierarchical-modules/libraries/library-design.html still using Haskell 1.2 naming schemes? Do people simply not like qualified names? I think the reason is simply that SimonM copied the relevant section from some ancient hslibs documentation which I put together aeons ago... :-) Cheers, S. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Data.Set whishes
Am Montag, 16. Februar 2004 10:05 schrieb Ketil Malde: Wolfgang Jeltsch [EMAIL PROTECTED] writes: * subsetOf :: Ord element = Set element - Set element - Bool (Isn't isSubsetOf a better name?) So is isElementOf. I just said subsetOf to be consistent with elementOf. Well, the naming in the Data.* modules should generally undergo some changes. Would x `isSubsetOf` y = x `union` y == y do, or did you want something more efficient? It's unefficient if, e.g., the x sets are always very small but so are union, intersect etc. I think, at first a complexity of O(|x| + |y|) would be acceptable so that your definition would be fine. Maybe, the implementation of union, intersect etc. should be changed so that the complexity is more like O(min(|x|,|y|)). -kzm Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
