Re: Suggestion for module system (to get rid of many uses of unsafePerformIO)
Stephen Dolan wrote: At the moment, we have the situation of modules using unsafePerformIO newIORef, which influences program behaviour without being referenced by main. Not really. Even with things as they currently are, if we have at the top level.. resultOfSomething = unsafePerformIO doSomething .. laziness will ensure that nothing will happen unless the value resultOfSomething is demanded (by main ultimately). Of course, this does not imply the above hack is at all safe. Regards -- Adrian Hey ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Suggestion for module system (to get rid of many uses of unsafePerformIO)
Stephen Dolan wrote: unsafePerformIO is possibly the most ugly feature of Haskell, yet is necessary to do many things which should be possible without it, such as reading configuration from a file at startup or creating global IORefs There is a considerable debate about global mutable state even in imperative languages. As to reading data from a configuration file -- which should be immutable for the rest of the computation -- one solution has been proposed back in 2002: Pure File Reading (was: Dealing with configuration data) http://www.haskell.org/pipermail/haskell/2002-September/010519.html The problem essentially is of separate compilation and dynamic linking -- both of which are far simpler now than it was in 2002, with GHC API and hs-plugins. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion for module system (to get rid of many uses of unsafePerformIO)
Stephen Dolan wrote: Would this be useful, useless, or just downright silly? The silence is deafening :-) I think what you're describing seems to be so completely different from Haskell as it is now that that people either don't understand it, or they do understand it and do think it's downright silly, but are just too polite to say that. Maybe you should try writing it up in a more comprehensible form on a Haskell wiki page. I would say that I get worried when people talk about module initialisation and/or (potentially) side effecting imports. I'm not sure if this is a problem with what you're proposing, but I think it's important that we don't get into a situation where the mere presence or absence of some definition in a module can influence program behaviour, even if it isn't referenced by main somehow. Regards -- Adrian Hey ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion for module system (to get rid of many uses of unsafePerformIO)
I think what you're describing seems to be so completely different from Haskell as it is now that that people either don't understand it, or they do understand it and do think it's downright silly, but are just too polite to say that. Maybe you should try writing it up in a more comprehensible form on a Haskell wiki page. Yeah, that certainly wasn't my most readable piece of writing. I would say that I get worried when people talk about module initialisation and/or (potentially) side effecting imports. I'm not sure if this is a problem with what you're proposing, but I think it's important that we don't get into a situation where the mere presence or absence of some definition in a module can influence program behaviour, even if it isn't referenced by main somehow. No, the point of what I was proposing was that, when a module requires side-effecting initialisation, it would have to be imported inside a do block like any other side-effecting piece of code. At the moment, we have the situation of modules using unsafePerformIO newIORef, which influences program behaviour without being referenced by main. If the import statement was inside a do block, it would be clear when the side-effects are taking place. Regards, Stephen Dolan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Suggestion for module system (to get rid of many uses of unsafePerformIO)
unsafePerformIO is possibly the most ugly feature of Haskell, yet is necessary to do many things which should be possible without it, such as reading configuration from a file at startup or creating global IORefs, e.g module Main where import Data.IORef a = unsafePerformIO $ newIORef 42 fac n = product [1..n] main = do val - readIORef a putStrLn $ show (fac val) This can be avoided by putting everything in the monad in main, i.e. module Main where import Data.IORef main = do a - unsafePerformIO $ newIORef 42 let fac n = product [1..n] let mainFunc = do val - readIORef a putStrLn $ show (fac val) mainFunc However, this approach does not work for modules which need to do their own initialisation with the current module system. I propose that it be legal to write things like this: MyModule.hs: fac n = product [1..n] do ref - newIORef 42 module MyModule (ref, fac) and then, in a different file, write this: module Main where main = do import qualified MyModule as M -- implies evaluating newIORef val - readIORef M.ref putStrLn $ show (M.fac val) The statement module name [(exported symbols)] would, informally, give a value of type Module. This would not be a first-class type, so it can't be passed around or bound to a variable. So, do ref - newIORef 42 module MyModule (ref, fac) writeIORef ref 43 would be illegal, since if you expand the do-notation, it is trying to pass around an object of type IO Module. So, in the previous example, Main :: Module and MyModule :: IO Module. The only valid operation you can perform on a module is to import it, so while import Main would be valid anywhere, import MyModule would only be valid in the IO monad, and would cause the line ref - newIORef 42 to be run when the IO action was executed. Following lexical scoping rules, its symbols would only be accessible in the do-block it was imported into, so the IORef ref could never escape from the IO monad. This would also mean that if main were run twice, each run would see a different IORef for ref, since the call to newIORef has, in effect, been included into main. If the module were imported in two different places, both places would see different values for ref, since the evaluation of newIORef has been done twice. Would this be useful, useless, or just downright silly? Thanks, Stephen Dolan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.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[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: Module System
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. Currently, as far as I can see, we can only do this with Main, and even then there are weirdnesses in ghc because Main.hi gets generated. -- David Roundy http://www.darcs.net ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Module System
David Roundby wrote: 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. And I'd like to second that! But not a Haskell' issue (I hope). Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Module System
Simon Marlow wrote: there's a lack of modularity in the current design, such that renaming the root of a module hierarchy requires editing every single source file in the hierarchy. The only good reason for this is the separation between language and implementation. I don't see how this is related to implementation. Surely all the language spec has to say is that the implementation has some unspecified way of finding the code for a module given only its canonical name, along with (if desired) a way of expanding a glob to a list of canonical names. Then the module namespace reform boils down to rules for converting partial names into canonical names. I can't see how any useful functionality in the module system could depend on a particular way of organizing code on disk. -- Ben ___ 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: Module System
Hi all, Georg Martius wrote: I have some proposals for changes of the hierarchical module system as it is at the moment. [...] The hierarchical name can be derived from the place in the filesystem. This is not a comment about the above proposal in itself, which arguably has its merits, but rather a meta comment. I get very anxious whenever I see the file system being mentioned in the context of a *language* specification (as opposed to, say, a specification of standard language libraries for interfacing with file systems). Some reasons: * File systems have all kinds of quirks one would rather not deal with in a language spec. * File systems can differ radically between different operating systems. In fact, even within an OS, as OS's these days tend to support many file systems simultaneously. * A valid module names in a language is not necessarily the same as a valid file name. (Yes, bijective mappings could be defined, but they would only be valid for a specific set of file systems.) * Even if we assume that the notion of a hierachical module name space always can be mapped to a corresponding file hierarchy in a simple way, why should that assumption be made in a language specification? In my opinion it is the task of the programming environment to locate the source files and interfaces that make up a semantically meaningful unit, and that semantics should be completely independent of where the different pieces happen to be stored. 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. So, please, to the extent possible, let's keep the file system out of the Haskell' definition! All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Module System
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. me too. which is why I made jhc search for System.IO.Unsafe in System/IO/Unsafe.hs System/IO.Unsafe.hs System.IO.Unsafe.hs in that order. It would be nice if other implementations did this too, but it is not the sort of thing that belongs in a language spec. So, please, to the extent possible, let's keep the file system out of the Haskell' definition! I very much agree. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: module system/namespaces: separate with/use, allow local use
On Mon, Jan 30, 2006 at 10:13:36AM +0100, Johannes Waldmann wrote: I am not sure what a local fixity declaration would mean for an operator that is defined in some outer scope. It would mean a whole new class of obfusciation ability for haskell programmers :) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: module system/namespaces: separate with/use, allow local use
Simon Marlow [EMAIL PROTECTED] writes: On 30 January 2006 09:03, Simon Peyton-Jones wrote: With the module system, we should make a distinction between declaring (1) that we want to use a module (2) how to bring the module's names into scope Perhaps 'import' should be allowed anywhere among definitions. Indeed. Requiring the import clauses to be at the top, and the fixity declarations, makes them easy to find -- but we don't require that for type signatures or class declarations etc. It'd be more consistent to allow imports and fixity declarations anywhere. This'd be a backward compatible change, but it's an utterly un-forced one. It's not something that people complain about much. I vaguely remember suggesting this for Haskell 98 or Haskell 1.4 (can't remember which) but nobody saw the need for it back then. (snip pros cons summary) Can one of you add a ticket / wiki page with this summary? I'd like to track things like this in case they come up again. Johannes, if you have any more specific proposals you'd like to make, please do so on the mailing list, then add a ticket once some consensus emerges. peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
