May 2007 - Haskell-prime

Literate Haskell specification
by Isaac Dupree 30 May '07

30 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As I brought up earlier in Haskell-cafe http://thread.gmane.org/gmane.comp.lang.haskell.cafe/20026 , the Haskell98 specification for literate haskell (report section 9.4) could use some work, at least clarifications (existing haskell implementations differ in some ways) - see that thread for details. Since I haven't successfully gotten to writing a concrete revision of that section, I thought I'd at least bring the issue to the attention of specifically haskell-prime people, as it is an issue that "should definitely" be addressed in the Report. Hopefully there's someone around here who might tackle it :) Good luck, Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFppvHgcxvIWYTTURAgoqAKDKFXaVBVeSfodzlgEte5Loy42unACfXfbl qDlxnSUaNH5rg8r58KAkKl8= =UVvx -----END PGP SIGNATURE-----

1 1

Re: [Haskell-cafe] global variables
by Adrian Hey 25 May '07

25 May '07

[cc'ing HPrime] Isaac Dupree wrote: > The unsafePerformIO hack being used is not very satisfactory given how > many optimizations make it difficult to use safely in practice. This > hack is also used many places. I would be happier if that situation > were not true, and I suspect there's something like a consensus on > _that_. (maybe not as strong as "_needs_ a solution" in the short-to-mid > term future) Considering the value that the Haskell community normally places on sound semantics, reliance on such an appalling hack seems pretty bad to me. If a solution doesn't find it's way into H' then how many more years is it going to be with us? It's just embarrassing :-) Also, I don't know if the OP was a noob, but telling people (especially noobs) that if they can't figure out how to solve a problem without using a "global variable" then that must be down to inexperience and general cluelessness on their part just seems wrong to me. It simply isn't true. (Anyone who disagrees with this should feel free to submit the patches needed to fix up the base package :-) Regards -- Adrian Hey

7 14

Suggestion for module system (to get rid of many uses of unsafePerformIO)
by oleg＠pobox.com 24 May '07

24 May '07

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.

1 0

Suggestion for module system (to get rid of many uses of unsafePerformIO)
by Stephen Dolan 24 May '07

24 May '07

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

2 3

Re: Wanted: warning option for usages of unary minus
by Simon Marlow 22 May '07

22 May '07

John Meacham wrote: > On Wed, Apr 11, 2007 at 09:05:21AM +0100, Simon Marlow wrote: >> I definitely think that -1# should be parsed as a single lexeme. >> Presumably it was easier at the time to do it the way it is, I don't >> remember exactly. >> >> I'd support a warning for use of prefix negation, or alternatively you >> could implement the Haskell' proposal to remove prefix negation completely >> - treat the unary minus as part of a numeric literal in the lexer only. >> This would have to be optional for now, so that we can continue to support >> Haskell 98 of course. > > yes please! odd that I look forward to such a minor change in the big > scheme of things, but the current treatment of negation has annoyed me > more than any other misfeature I think. Really? I'm beginning to have second thoughts about the proposed change to negation for Haskell'. The main reason, and this isn't pointed out as well as it should be on the wiki, is that "x-1" will cease to be an infix application of (-), it will parse as x applied to the literal (-1). And this is different from "x - 1" (syntax in which whitespace matters should be avoided like the plague, IMO). I think this would be worse than the current situation. Cheers, Simon

7 13

Polymorphic strict fields
by Iavor Diatchki 03 May '07

03 May '07

Hello, At present, the Haskell report specifies the semantics of strict datatype fields (the ones marked with !) in terms of the strict application operator $! [Section 4.2.1, paragraph "Strictness flags"]. However, if we were to add polymorphic fields to Haskell, then we cannot use this definition anymore because the application operator (or ``seq`` for that matter) does not have the correct type---we would need many rank-2 versions, one for each possible type scheme. Notice, furthermore, that the behavior of such constructors may be a bit unexpected when combined with overloading. Consider, for example, the following declarations: > data T = T !(forall a. Eq a => a) > test = seq (T undefined) True In GHC 6.6 ``test`` evaluets to ``True`` because ``undefined`` is converted to a function that expects its implict evidence argument. Hugs does not support strictness annotations on polymorphic fields (I thought that this was a bug but, perhaps, it was a delibarate choice?) It seems that even without overloading, we may think of polymorphic values as being parameterized by their type arguments, so that they are always in head-normal form. All of this leads me to think that perhaps we should not allow strictness annotations on polymorphic fields. Would people find this too restrictive? If so, does anoyone have ideas about what should happen and how to specify the behavior? -Iavor

3 4