RE: Export lists in modules
On 23 February 2006 01:48, John Meacham wrote: On Wed, Feb 22, 2006 at 05:11:26PM -, Simon Marlow wrote: Indeed, the distinction between data newtype should be a completely private property, so we certainly shouldn't distinguish those in exports/imports. It's less clear to me whether type and data/newtype should be distinguished or not, which is why I asked the question. I'm not sure I agree with John's answer, I'd rather just say 'type' or 'data', using 'data' for both data and newtype, like Haddock does. my best argument against this is to try to compile the following under ghc in strict haskell 98 mode class Foo a instance Foo IOError oops! Actually I wanted to distinguish type and data, and type and newtype, but not data and newtype (my lanugage was ambiguous, sorry about that). Even if the restriction on synonyms in instance heads is lifted, being able to use type synonyms to give true aliases for types is important part of writing interfaces that can evolve and encapsulating implementation details. But more importantly, The haskell module system has a nice philosophy of just being about controlling the namespace of what is in scope in a module. Conflating representation details with it would just confuse things. I'd say use 'type' for everything in the type namespace, class for everything in the class namespace, value (or nothing) for things in the value namespace and so forth. We want the module system to describe precicely what names are in scope and what entities names in a module map too, nothing more. It is also a much simpler set of rules to remember and much more straightforward to specify. That's a fair point. I agree it's a nice property that the module system just talks about *names* and nothing else, and on that basis you're right that distinguishing type synonyms from other type constructors in export specifiers would be inconsistent. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Export lists in modules
On 22 February 2006 17:27, Malcolm Wallace wrote: However, I would be equally happy to combine type/newtype/data into a single keyword for exports. for the record, I am in favour of tagging export specifiers with 'class' or 'type' (using 'type' for all type constructors, in light of yours and John's points). I'm not in favour of adding type signatures to export lists. It's a half way solution to specifying interfaces, and I'd rather design it properly from scratch. If modules are to contain interfaces, I don't think extending the export list is the way to do it. I'd rather do something like: -- modules M exports class Eq a where (==) :: a - a - Bool data T :: * - * f :: T - Int mkT :: Int - T where -- implementation below here data T a = C a Int f = ... -- Not a proposal by any means, and I don't think that Haskell' should tackle this, but this seems the right direction to me. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Ketil Malde [EMAIL PROTECTED] wrote: I would solve this problem by reducing the Prelude to just a core. List function could go, for example, (mostly) into Data.List. If this means that you must import Data.List almost everywhere, this won't change anything - only add yet another import to every file. People often overlook the useful facility of the module system to group multiple common imports into a single re-exporting super-module. With my proposal, you would simply replace the implicit import Prelude with an explicit import Prelude.Standard (or use a build flag like -fimplicit-prelude, or +98). The idea is that backward compatibility with the old Prelude is preserved as much as possible, but the experimental ability to replace or remove parts of the Prelude is gained. Over time and through experience, a new consensus about what should be included might emerge. I know most - if not all - of my modules use lists, but just in case, I checked with the darcs sources - 95 of 107 source files appear to use lists. Ignoring the : and ++ operators (looking for null, map, and filter) the count is 76 files. Some data-structures people (e.g. Chris Okasaki) are of the opinion that lists tend to be over-used (because they are built-in), when other datatypes might be much more appropriate. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Export lists in modules
On 23 February 2006 10:28, Jean-Philippe Bernardy wrote: I lost track of what is the issue being tackled here. What's broken with the current way of specifying exported entities? Imho it's the best system that I've seen (across all languages I know). A lot of language chose to separate interface from implementation in source files. (eg. Ada) I find this annoying because to change a single thing you have very often to edit two files. The counter-argument is that the user of a module wants to see only the interface. However, with modern tools like haddock, one doesn't look at the source code any more to understand the interface of a module, but some specifically processed version of the sources, so this argument is void. So, again, please keep implemenation and interface as close as possible. Public modifiers permit this adequately, but they don't fit with haskell syntax style very well. The current export list being 1. very light 2. optional and 3. allowing to re-order presentation in haddock (or such a similar tool) makes it the very best solution for haskell, imho. I certainly sympathise with this point of view. It's a difficult call, there are good arguments on both sides. For interfaces: - separately declaring interfaces is generally considered good software engineering; stops you accidentally changing the interface - having an interface in the source code makes browsing the code that much easier - replaces the export list - makes mutually recursive modules easier to implement (maybe) Against interfaces: - good tool support lets you browse interfaces anyway, and could tell you when you break an existing interface - makes life harder for the implementer: interface and documentation are separated from the implementation, or are duplicated with the implementation. Code is less agile. - more complication in the language definition and compiler Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Simon Marlow [EMAIL PROTECTED] wrote: However, I would be equally happy to combine type/newtype/data into a single keyword for exports. for the record, I am in favour of tagging export specifiers with 'class' or 'type' (using 'type' for all type constructors, in light of yours and John's points). For the sake of avoiding confusion, perhaps we should choose a keyword (or better, a reserved identifier with no meaning outside of the export/import list) that is none of type, data, or newtype? How about datatype, tycon, or the like? Then it would be clearer that there is no relationship between the way the type is defined, and how its namespace is notated in the export list. If modules are to contain interfaces, I don't think extending the export list is the way to do it. I'd rather do something like: -- modules M exports class Eq a where (==) :: a - a - Bool data T :: * - * f :: T - Int mkT :: Int - T where -- implementation below here -- But, apart from adding fuller signatures than I proposed, that is exactly the same as an export list, modulo some very minor syntactic differences! Not a proposal by any means, and I don't think that Haskell' should tackle this, but this seems the right direction to me. I agree that full interface specs are beyond Haskell'. JPBernardy's argument that tools (Haddock, compilers) can already extract the interface automatically is quite persuasive too. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Module System
On 22 February 2006 13:09, David Roundy wrote: On Tue, Feb 21, 2006 at 03:50:29PM +, Henrik Nilsson wrote: I'm already somewhat unhappy about the way most present Haskell tools map module names to path names (I'd generally prefer to have the possibility to flatten my file hierarchies by, say, using dots in my file names), but at least these assumptions are not in the Haskell 98 language definition. I'd like to second this. I've been annoyed by the fact that ghc requires extra subdirectories in order to use hierarchical modules, and would be doubly annoyed if the language definition declared that this couldn't be fixed. jhc's behavior sounds nicer, but I'd rather there were the possibility of naming our haskell files whatever we liked. Actually in GHC you can name your source files whatever you like, as long as you tell GHC the names of all the source files on the command line and use --make. eg. ghc --make My.Dotted.Module.hs Main.hs works fine. Similarly with GHCi. It's only when GHC has to actually *find* a source file for a module that the hierarchical naming convention comes into play. There are two reasons we don't allow the dotted convention: one is simplicity (the description of where GHC looks for files is already a bit complex), and the other is performance - GHC does a lot of looking for interface files, and looking in more places might slow things down (I haven't measureed it, though). Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Export lists in modules
On 23 February 2006 11:14, Malcolm Wallace wrote: Simon Marlow [EMAIL PROTECTED] wrote: However, I would be equally happy to combine type/newtype/data into a single keyword for exports. for the record, I am in favour of tagging export specifiers with 'class' or 'type' (using 'type' for all type constructors, in light of yours and John's points). For the sake of avoiding confusion, perhaps we should choose a keyword (or better, a reserved identifier with no meaning outside of the export/import list) that is none of type, data, or newtype? How about datatype, tycon, or the like? Then it would be clearer that there is no relationship between the way the type is defined, and how its namespace is notated in the export list. Yes, I suppose you could have another keyword. In fact, a keyword is unnecessary, as long as classes are identified with the 'class' keyword, there's no need to tag type constructors too. This is the most minimal extension, and avoids both the confusion of referring to synonyms and datatypes in the same way, and taking a new keyword. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Malcolm Wallace [EMAIL PROTECTED] writes: you would simply replace the implicit import Prelude with an explicit import Prelude.Standard (or use a build flag like -fimplicit-prelude, or +98). Why not keep it implicit? If you want the alternative behavior, you know where to get it (import Prelude (), -fno-implicit-prelude, etc). This way, you avoid breaking a lot of existing code, and also a lot of hello world-class programs could be written without any explicit imports or special tricks. Any programs written to use a more granular set of Prelude modules, would likely need an array of imports anyway, so the loss would be less in that case. Some data-structures people (e.g. Chris Okasaki) are of the opinion that lists tend to be over-used (because they are built-in), when other datatypes might be much more appropriate. Hmm...so the best way to educate programmers about this is to make lists harder to use? :-) Anyway, I'll see your Okasaki, and raise you one Simon Thomson (since The Craft.. is the only Haskell book I have on my desk at the moment). Lists aren't mentioned until chapter 4, but chapter 4 and 5 discuss lists, chapter 5 is called Generalization, but as far as I can tell, still talks exclusively about lists, and in the remaining chapters, there are lists on nearly every page. Over-used, perhaps, but the fact is that lists are - like it or not - a staple of FP in general, and Haskell in particular. Now, I'm sure a lot of uses for List could be replaced by more specific and appropriate types: Stack, LazyStream, IterationMonad, Deque, FingerTree etc etc. But this adds complexity to your program - if a list does the job well enough, why not use it? I'm reminded of one of the XP idioms: always first try to solve the problem in the simplest way that can possibly work. /hubris :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Module System
Hello Simon, Thursday, February 23, 2006, 2:21:22 PM, you wrote: SMghc --make My.Dotted.Module.hs Main.hs SM works fine. Similarly with GHCi. i don't known that. we should add this to faq SM It's only when GHC has to actually *find* a source file for a module SM that the hierarchical naming convention comes into play. There are two SM reasons we don't allow the dotted convention: one is simplicity (the SM description of where GHC looks for files is already a bit complex), and SM the other is performance - GHC does a lot of looking for interface SM files, and looking in more places might slow things down (I haven't SM measureed it, though). 1) ghc's startup speed (before it compiles any module) is good enough at this moment 2) that will slower search only for modules that use this advantage. modules that don't use new naming scheme (including all std library modules) will be found in just the same time -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: minimal Prelude (was Re: Export lists in modules)
On Wed, Feb 22, 2006 at 05:12:47PM +, Malcolm Wallace wrote: Everything else that is currently in the Haskell'98 Prelude is re-distributed across a variety of small modules. Where a syntactic desugaring rule currently uses an entity from the Prelude, the new interpretation is that it uses whatever binding of that entity is in scope - if there is no such entity in scope, it is an error. For compatibility, we define a wrapper module called Prelude.Standard which re-exports the original Haskell'98 Prelude: module Prelude.Standard ( module Prelude , module Prelude.Num , module Prelude.Comparison , module Prelude.Monad , module Prelude.List , module Prelude.Maybe , module Prelude.Either , module Prelude.Tuple , module Prelude.IO , module Prelude.Text ) It would be nice if there was an easy way to import an entire Haskell98 prelude hiding only Prelude.List.* stuff (for example). This would be possible if all Prelude.* modules would be imported automatically, but I guess it's not what you propose. Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: Export lists in modules
Bulat Ziganshin [EMAIL PROTECTED] wrote: MW With my proposal, you would simply replace the MW implicit import Prelude with an explicit import MW Prelude.Standard import Prelude ($) can't solve this problem? One of the problems with the current mechanism for overriding Prelude definitions, is that every module that /uses/ such an entity must also explicitly hide the original Prelude: module NewMap (map) where import Prelude () map = ... module User where import Prelude hiding (map) import NewMap By forcing the H' Prelude to be explicit by default, it removes this nuisance. Instead, you just change which Prelude you import. module Prelude.NewMap (module Prelude.Haskell98, map) where import Prelude.Haskell98 hiding (map) map = ... module User where import Prelude.NewMap Note that, my suggestion is that compilers which continue to support the Haskell'98 language will continue to give you the original implicit Prelude in that mode. It is only Haskell-prime programs that would be affected. Yes, many trivial programs would acquire one extra import decl - is that such a big deal? Especially for beginners, I'm thinking that some teachers might /prefer/ to remove lots of the current Prelude, and build up students' knowledge gradually, by allowing them to write map, fold, curry, etc for themselves, without name clashes. Later, they could switch on more of the language, like numeric classes, by need. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
public/private module sections (was Re[2]: Export lists in modules)
modules M exports class Eq a where (==) :: a - a - Bool data T :: * - * f :: T - Int mkT :: Int - T where -- implementation below here -- SM The main difference is that I'm doing away with parentheses, commas, and SM export specifiers, and using layout and full declaration syntax instead. SM (I don't really want to discuss this very rough idea any more though, SM it's just a distraction, and I'm not sure I like it anyway). let's have a closer look before we dump this again, shall we?-) if you'd go one step further, you'd replace the public/private modifiers with public/private module sections. I don't like the modifiers, and I'm uncertain about the intermediate form you suggested, but I might be able to live with two-section modules: nothing is duplicated, the public and private items are clearly grouped. if you like to make the public section look more like an interface, you only use short definitions in it (could this be made to work for data type constructors/class members?). another neat consequence not available with the other alternatives: instances could be private (without having to be named), instead of flooding into importing modules. proper interfaces would still be nice (and useful!), but the general opinion seems to be that they're beyond Haskell' (what isn't, really?-). about tools: tools can relieve some of pressure on the language design (which is why I'm more in the camp a language definition should not ignore tools now!-). but the wrong language design can make the tools' job awkward, so it may be useful to look at what a tool can/cannot do: 1 ides may let you browse interfaces, but they don't give a standard form of printing those interfaces with the modules they belong to, nor even a standard form of those interfaces.. 2 ides let you see different locations in your sources in a single window (I use this whenever I need to modify the imports while editing in the middle of my module; I sometimes use this to see the definition of the data types I'm working on). that means that the link between definitions and import lists can be implicit, and browsing may bypass import lists/ export interfaces entirely. that holds for both browsing and navigation. 3 ides can add/remove items from the imports remotely (HaRe does this). they can also generate explicit export/import lists (even my old Hugs.vim supported that), and add types in comments, but if they do so, it is not clear what to do with comments already present (update any types in them? what if they were meant to document alternative/ old/comming versions..; leave any unidentified comments alone? then we'll duplicate type comments as soon as someone adds any text to the automatically generated non-interface..) 4 ides can use tooltips to tell you whether the stuff you're looking at is exported or not, but again, that won't usually make it into printouts. look at the problem from this perspective, and you see that - haskell98 fails 1/4, profits from (and really needs) 2, doesn't support 3 all that well - public/private modifiers only help with 4, part of their job is covered by 3 already - public/private sections solve 1/4, may still use 2/3 so, public/private sections seem to support all pragmatic issues, and since they're still just haskell code, don't suffer from duplication/scoping/.. issues, either. in fact, we might end up simplifying the syntax be removing export lists! but exposing only some data constructors of a data type would be awkward? cheers, claus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Simon Marlow [EMAIL PROTECTED] writes: The main difference is that I'm doing away with parentheses, commas, and export specifiers, and using layout and full declaration syntax instead. (I don't really want to discuss this very rough idea any more though, it's just a distraction, and I'm not sure I like it anyway). I like this general idea, I was thinking about something similar a long time ago. But in case of a large datatype, e.g. an AST, we certainly don't want to duplicate it in whole. It should be sufficient in the export section. So perhaps what is really needed is the ability to split a module into a public part and a private part, and allowing to duplicate certain definitions in a partial form, e.g. have both 'data Foo' and 'data Foo = Con1 | Con2' in the same module. The details are not obvious though because the syntax has not been designed with this in mind. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Malcolm Wallace wrote: An explicit interface would be useful for many purposes besides machine-checked documentation. For instance, it could be used to eliminate the hs-boot or hi-boot files used by some compilers when dealing with recursive modules. Why *does* ghc require hs-boot files? What can be gleaned from an hs-boot file that couldn't be expressed in the corresponding hs file? For example, why doesn't ghc simply require that at least one module in a recursive group contain an explicit export list mentioning only explicitly typed symbols? -- Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Capitalized type variables (was Re: Scoped type variables)
I wrote: What I don't like is that given a signature like x :: a - a there's no way to tell, looking at it in isolation, whether a is free or bound in the type. [...] Here's a completely different idea for solving this. It occurs to me that there isn't all that much difference between capitalized and lowercase identifiers in the type language. One set is for type constants and the other for type variables, but one man's variable is another man's constant, as the epigram goes. In Haskell 98 type signatures, the difference between them is precisely that type variables are bound within the type, and type constants are bound in the environment. Maybe scoped type variables should be capitalized. At the usage point this definitely makes sense: you really shouldn't care whether the thing you're pulling in from the environment was bound at the top level or in a nested scope. And implicit quantification does the right thing. As for binding, I suppose the simplest solution would be explicit quantification of the capitalized variables, e.g. f :: forall N. [N] - ... f x = ... or f (x :: exists N. [N]) = ... Really, the latter binding should be in the pattern, not in the type signature, but that's trickier (from a purely syntactic standpoint). What do people think of this? I've never seen anyone suggest capitalized type variables before, but it seems to make sense. -- Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Implicit Prelude (was Re: Export lists in modules)
On 2/23/06, Ben Rudiak-Gould [EMAIL PROTECTED] wrote: In fact, this suggests a compromise: how about implicitly importing the Prelude only if the module header is omitted? That way there'll be no impact on short (single-module) programs. +1 -- Taral [EMAIL PROTECTED] Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: public/private module sections (was Re[2]: Export lists in modules)
let's go through 5.2 Export Lists to see what would be missing if we tried to replace the export list with a separation of a module into a public (exported) and a private (local) part: --- module M exports body where body -- 1. value, field name, or class method, whether declared in the module body or imported, may be named by giving the name of the value as a qvarid the easiest way to do that is to put the definition of that name or a synonym for it in the export section. to reexport names from other modules, import those names in the export section. that approach gets awkward if we only want to export some field names of a data type. [ISSUE 1] 2. algebraic datatype T declared by a data or newtype declaration - The form T names the type but not the constructors or field names. declare T itself in the local section, declare a type synonym for T in the export section - The form T(c1,...,cn), names the type and some or all of its constructors and field names. declare T in the local section, and synonyms for T and for some of its fields/constructors in the export section. again, the latter is awkward. worse, it doesn't work when constructors are used in patterns. [ISSUE 2] - The abbreviated form T(..) names the type and all its constructors and field names declare T in the export section 3. A type synonym T declared by a type declaration declare T in the export section 4. A class C with operations f1,...,fn declared in a class declaration - The form C names the class but not the class methods. declare C in the local section. declare a synonym for C in the export section. (it is strange that Haskell 98 allows us to export a class without its methods, yet without restricting its use; instantiating such a class would only make sense if all hidden methods had default definitions, wouldn't it? so perhaps the class synonym would only need to be one-sided: for use, not for adding instances?). - The form C(f1,...,fn), names the class and some or all of its methods. declare C in the local section, declare a partial synonym for C, including some of its methods, in the export section. (again, it doesn't seem to make much sense to make that more than a one-sided synonym; see previous point). - The abbreviated form C(..) names the class and all its methods declare C in the export section 5. The form module M names the set of all entities that are in scope with both an unqualified name e and a qualified name M.e. for re-exports M, import M in the export section. for the current module: ?? the current module seems to need syntax at first, until we realize that this case is already handled by the split into export/local section. for imports we don't want to re-export, import them in the local section (so imports need to be allowed in two places, at the beginning of the exported section and at the beginning of the local section (but that seems to be no problem, more relaxed versions of import have been suggested here). note that it is no longer possible to export a module M that has not been imported. so the description of that error in the report can be removed --- so far, so good, if we can resolve the issues mentioned above, there is a lot of simplicifation in return: - no export lists (so the language definition becomes simpler, and if some future standard tackles module interfaces, they won't have to compete with overlaps between export lists and interfaces) - no need to duplicate features of import lists in export lists, as import lists in export sections serve the same purpose - less potential for errors but that's not the end of the advantages: compared to other proposals on the table, there is no duplication of type signatures, nor of export information, and whether or not an item is exported is directly visible from its presence in either section. moreover: 6. (cf. 5.4 importing and exporting instances) to export an instance, declare it in the export section. to avoid exporting an instance, declare it in the local section. to import instances for re-export, import them in the export section. to import instances *without re-exporting* them, import them in the local section! (hooray!-) this is not a perfect success, however: we have selective export of instances, but not selective import - we have no chance to import names from a module M without importing its exported instances as well. [ISSUE 3] the more I think about it, the more I like it (which probably means that there is some ugly part of it that I'm not thinking about;-). the outstanding
Re: Export lists in modules
On Thu, 2006-02-23 at 21:04 +0100, Marcin 'Qrczak' Kowalczyk wrote: Simon Marlow [EMAIL PROTECTED] writes: The main difference is that I'm doing away with parentheses, commas, and export specifiers, and using layout and full declaration syntax instead. (I don't really want to discuss this very rough idea any more though, it's just a distraction, and I'm not sure I like it anyway). I like this general idea, I was thinking about something similar a long time ago. But in case of a large datatype, e.g. an AST, we certainly don't want to duplicate it in whole. It should be sufficient in the export section. So perhaps what is really needed is the ability to split a module into a public part and a private part, and allowing to duplicate certain definitions in a partial form, e.g. have both 'data Foo' and 'data Foo = Con1 | Con2' in the same module. The details are not obvious though because the syntax has not been designed with this in mind. It might be useful for people who are interested in this idea to look at Mercury's module system. It is very similar to the one proposed. Also, Mercury is quite close to Haskell (type classes and so on). Incidentally, I'm told that the design was influenced by Ada. Cheers, Bernie. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
On 2006-02-21, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Dienstag, 21. Februar 2006 04:41 schrieb John Meacham: on this note, I thought it would be nice to do a 'mostly unqualified' import. import Foo qualified(foo,bar) which will have the effect of import Foo hiding(foo,bar) import qualified Foo(foo,bar) since usually you can import a whole module unqualified except for a few troublemakers. John On the other hand, sometimes it makes sense to have a mostly qualified import. For example, if you import Data.Set or Data.Map you might want only the type constructors to be imported unqualified and the rest to be imported qualified. import qualified Foo unqualify1 = Foo.unqualify1 unqualify2 = Foo.unqualify2 ... (That is, this is already pretty easy to do.) -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
