- Haskell-prime - Haskell.org

type signatures in export lists
by Isaac Dupree 18 Jun '07

18 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 They're not implemented, but they won't be until we decide exactly what they mean - it's not simple. (at least the syntax is obvious: http://hackage.haskell.org/trac/haskell-prime/wiki/PermitSignaturesInExports ) One big question: can their presence have any effect? * on the module doing the exporting (conflict with the presence of in-module type-signature for the same thing; type restriction in-module; monomorphism-restriction-lifting or defaulting-removal of the named thing) * on modules importing this one (can a module re-export something, giving it a more restrictive type-signature?) Case study 1: module Foo1 (Foo(..), foo :: Foo) where data Foo = CFoo foo :: Foo foo = CFoo If we interpret it as an in-module type signature, it will be a problem because there already is one for foo. (unless we should relax the rules for uniqueness of type signatures anyway?) Case study 2: module Foo2 (foo :: Foo) where data Foo = CFoo foo :: Foo foo = CFoo The type doesn't need to be exported. (which is more likely if it's just a type synonym than a new type.) So what scope are the names in the export-list-type-signature drawn from? It would be odd if a type signature couldn't be given because some names weren't exported; but it would be odd if a module-user looking at the interface saw some types that weren't defined anywhere visible. This suggests that wildcards in type signatures could be helpful for this: module Foo3 (foo :: Int -> Foo -> Bool) versus module Foo4 (foo :: Int -> _ -> Bool) Open for discussion. Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdmneHgcxvIWYTTURAlTpAJ425ZL8WPzkAeIxRbgGSOQFCKtrnwCeIG0P aawB6GDwSfiRNM20MErBj8E= =KCKj -----END PGP SIGNATURE-----

2 2

What separates lines in Haskell code?
by Isaac Dupree 17 Jun '07

17 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In the report, under the layout rule (section 9.3), "The characters newline, return, linefeed, and formfeed, all start a new line." (Which four characters are those? from http://en.wikipedia.org/wiki/Linefeed , I'm guessing "LF: Line Feed, U+000A", "CR: Carriage Return, U+000D", "FF: Form Feed, U+000C", and what's the fourth one? Newline usually refers to '\n', which is LF, but linefeed has a direct name correspondence to that also!) The literate haskell section 9.4 just talks about lines without being specific about how they're specified. My proposed sample implementation uses Prelude.lines ... Prelude.lines presumes that lines are separated only by '\n'. (Of course, for Prelude.unlines to be an inverse operation (which it's not anyway) there has to be only one character that makes a line-separation) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcT5vHgcxvIWYTTURAowrAJ4rz3/Sc763l8TEharcnWcma5BkBgCfRhAF XbfCIG8tnym1gZFRZf4KuRo= =it7M -----END PGP SIGNATURE-----

2 2

"qvars"? pragma syntax generally?
by Isaac Dupree 16 Jun '07

16 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For INLINE and NOINLINE the report uses "qvars" http://haskell.org/onlinereport/pragmas.html which is not defined in http://haskell.org/onlinereport/syntax-iso.html (although its meaning is obvious since var, qvar and vars are all defined). Is it permissible for compilers to die on pragma syntax they don't personally like? For example GHC chokes on {-# INLINE Ma-in.ma-in #-} at top level, but it would be worse with non-standardized pragmas. (the compiler giving a warning that it understands a pragma of that name, but not the syntax given, would be best.) "the pragma should be ignored if an implementation is not prepared to handle it." WHAT IS pragma syntax?? The report doesn't say how whitespace is handled. syntax-iso doesn't mention pragmas; in its opinion everything from {-# hi-} to {-#{-##-}#-} to {-# INLINE main #-} is a perfectly good comment. [1] But the report recommends some specific syntaxes. To all appearances, it is expected that they follow (guessing from other Haskell syntax) the form pragma -> {-# pragmaid (some pragma-specific syntax that is consistent with the whole thing being ncomment) #-} pragmaid -> (large|_) {large|_|'} Still... whitespace? GHC understands as a pragma {-# LINE 3 "foo.hs" #-} but not {-# {- nested comment -} LINE 3 "foo.hs" #-} ; I don't even know about inside or next to the (some pragma-specific syntax). Is the inside of pragmas supposed to be lexed somewhat the same way as the rest of the Haskell file, or "it can vary" because pragmas can be anything they want... hopefully the convention of beginning pragmas with a name cannot vary. [1] (hmm, maybe pragmas should be used to indicate haddock comments - too late now, and probably too verbose too) Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGdCuyHgcxvIWYTTURAnljAJ9NLJKW+CTroJ0Vg43bgGWZ3DXJHwCgp+Z3 SAX/cK5PSV7B4TBfwg664xM= =81g6 -----END PGP SIGNATURE-----

1 0

inits is too strict
by apfelmus 14 Jun '07

14 Jun '07

Hello, inits [] = [[]] inits (x:xs) = [[]] ++ map (x:) (inits xs) as specified in Data.List has a "semantic bug", namely it's too strict: inits (1:_|_) = []:_|_ as opposed to the expected inits (1:_|_) = []:[1]:_|_ A correct version would be inits xs = []:case xs of [] -> [] (x:xs) -> map (x:) (inits xs) The Haskell report specifies how inits has to behave, so this is a problem in the report, not in a concrete implementation. Where can I report a bug report for the report? ;) Regards, apfelmus

3 3

Literate Haskell specification
by Isaac Dupree 29 May '07

29 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 24 May '07

24 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 21 May '07

21 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