Re: Export lists in modules
On Wednesday 22 February 2006 15:53, Malcolm Wallace wrote: Simon Peyton-Jones [EMAIL PROTECTED] wrote: | I don't seriously propose for haskell-prime that signatures should | be required on exports. Just permitting them would be a large and | useful step up already. If this is to be a serious proposal, someone had better think what to do about classes, data types, instances and so on. As far as I can see, there is very little to change. Here is a concrete proposal. A qvar in an export list may optionally have a type signature. A qtycon or qtycls in an export list may optionally have an annotation saying whether it is a type, newtype, data, or class. Instances cannot be mentioned in export lists, and this does not change. export - qvar | qtycon [ (..) | ( cname_1, ... , cname_n ) ] (n=0) | qtycls [ (..) | ( var_1, ... , var_n ) ] (n=0) | module modid becomes export - qvar [ :: type ] | [type]qtycon | [newtype] qtycon [ (..) | ( cname_1, ... , cname_n ) (n=0) | [data]qtycon [ (..) | ( cname_1, ... , cname_n ) (n=0) | [class] qtycls [ (..) | ( var_1, ... , var_n ) (n=0) | module modid As far as import entity lists are concerned, we permit an optional annotation for type synonyms, newtypes, datatypes, and classes: import - var | tycon [ (..) | ( cname_1, ... , cname_n ) ] (n=0) | tycls [ (..) | ( var_1, ... , var_n ) ] (n=0) becomes import - var | [type]tycon | [newtype] tycon [ (..) | ( cname_1, ... , cname_n ) ] (n=0) | [data]tycon [ (..) | ( cname_1, ... , cname_n ) ] (n=0) | [class] tycls [ (..) | ( var_1, ... , var_n ) ] (n=0) Anyone see any difficulties? No, but one question: If the type signature is given in the export lists, is it then necessary (or even allowed) later on? I would vote for _not_ having it twice in the file. Cheers, Georg pgpCsWo4zYkq0.pgp Description: PGP signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
On Tuesday 21 February 2006 11:40, Malcolm Wallace wrote: Jared Updike [EMAIL PROTECTED] wrote: I am not sure if this has been mentioned before, but something I would really find useful is the ability to tell Haskell to export everything in a function except for some named functions. No one has responded so ... I believe some people (perhaps on another list) have been advocating the addition of Java-style public/private modifiers on function definitions, to indicate whether they are exported or not. (A truly horrible idea in my opinion!) Why is it horrible? It avoids redundancy in the code-file which is a good thing in general. module Module hiding ( list, of, things, not, to, export ) where I quite like this for its minimal syntactic overhead, and backward compatibility. There is a slight worry that it would be too easy to overlook the hiding keyword when reading a module, leading to confusion. I dislike this idea because the export list is a sort of signature of the module, which is also often used for structuring the haddock documentation. In case of hiding() version you explicitly state the unimportant parts. Apart from that you might change the hidden functions much more often than the public interface. Proper signatures would be a nice solution I guess. Just my 2p! Regards, Georg There is also the issue that we might adopt the proposal to allow (and perhaps eventually, to require) type signatures on export lists. If so, then it would be kind of ridiculous to have interface signatures only for the things you are /not/ exporting! Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime pgpaklCJrwz0e.pgp Description: PGP signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Module System
Hello, I have some proposals for changes of the hierarchical module system as it is at the moment. Goals: - easy refactoring at Module/Package level - easier import/export of trees of modules (useful for any larger library) - relative imports/exports - deep import or export lists Notation: I use X -- Y to mean X is an example how it is now and Y is my proposed version. 1) Instead of writing the full name of the module in the head line it should be allowed to just use its last part e.g. module System.Posix -- module Posix The hierarchical name can be derived from the place in the filesystem. Pros: - allow much easier refactoring at package level. - reduce redundancy between file location and file content Cons: - loose location information in file itself 2) relative imports/exports: imports/exports of submodules can be specified as a relative path: module System.Posix ( module System.Posix.Env ) where import System.Posix.Env -- module Posix ( module .Env ) where import .Env or whatever syntax you prefere. Pros: - Again, easier refactoring at package level Cons: - the . might be overseen (I expect long syntax discussions :-) ) 3) Import subtrees: import (qualified) System.Posix.* as P would to the same as import (qualified) System.Posix.Directory as P.Directory import (qualified) System.Posix.Env as P.Env import (qualified) System.Posix.DynamicLinker as P.DynamicLinker import (qualified) System.Posix.DynamicLinker.Module as P.DynamicLinker.Module Pros: - Much less imports - easy use of large libraries like Graphics.UI.Gtk Cons: - More modules are imported than necessary 4) Export subtrees: This proposal seems to do the same thing as 3) but on the side of the library not on the calling side. - module System ( module P.* ) where import qualified Posix.* as P -- module Test where import System -- Posix.Env is in scope now The details about the qualification must be sorted out carefully, but I see no serious problem there at the moment. Pros: - Easy writing of meta-modules - avoids name clashing within submodules (e.g. Data.Map, Data.Set,... which have all insert, lookup,...) Cons: - importing side does not see, that there is a whole tree imported. Comments? Cheers, Georg ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: MPTCs and functional dependencies
Am Freitag, 3. Februar 2006 00:06 schrieb John Meacham: On Thu, Feb 02, 2006 at 03:09:35PM +, Henrik Nilsson wrote: Now, I'm not saying that FDs are that important, only that it seems to me they are. I'd be happy to be convinced of the opposite. But from the above, it at least seems that John M. too actually says that FDs are important? Oh, I don't think anyone is disagreeing that they are important. they are just quite underspecified at the moment, and it looks like they will be replaced at some point anyway. It would be great if we can figure out some well specified subset that works for most uses that is ready to put into haskell prime. John From the users point of view, the implementation in GHC works quite well and a lot people use it. It would be a pitty if they are not included in the new standard. What is the problem of specifiing what is implemented. If they are replaced in the future we will have haskell'' anyway :-). Cheers, Georg -- Georg Martius, Tel: (+49 34297) 89434 --- http://www.flexman.homeip.net -- pgpapSKrhJlxf.pgp Description: PGP signature ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
