- Haskell-Cafe - Haskell.org

Error building Edison 1.2.0.1
by Lyle Kopnicky 19 Oct '06

19 Oct '06

Hi folks, I tried to build edison-1.2.0.1-sources with the command 'make system' but got: *** Exception: Line 10: Unknown field 'hs-source-dirs' I am using GHC 6.4.1. Any idea how to fix this? Thanks, Lyle

3 13

A better syntax for qualified operators?
by Brian Hulley 19 Oct '06

19 Oct '06

Hi - Consider the scenario when you want to find a function that returns the i'th element of an array but all you know is that there is a module called Data.Array.IArray that will probably have such a function in it. So you start typing in your program: let ith = Data.Array.IArray. at this point, you'd hope the editor you're using would somehow display a list of avaliable values exported from Data.Array.IArray including the indexing function, so you could select it, thus I would *like* to be able to use the syntax: let ith = Data.Array.IArray.(!) because it's not the user's fault that the person who wrote Data.Array.IArray decided to use a symbol instead of an identifier for this function - the user of Data.Array.IArray in this case just wants to see normal identifiers to use with prefix application so the use of (!) at this point effectively gets rid of the unwanted operatorness associated with the function. However the current syntax of Haskell would not allow this. Instead you have to write: let ith = (Data.Array.IArray.!) The problem is that the user of Data.Array.IArray has to know already in advance, before typing the 'D' of "Data", that the indexing function has been named with a symbol instead of an identifier, but this knowledge is only available later, when the user has typed the '.' after "IArray", so the current syntax would be frustrating for the user because the user then has to go all the way back and insert an opening paren before the 'D'. Also, consider the appearance of: let ith = (Data.Array.IArray.!) arr i b = Data.Array.IArray.bounds arr vs let ith = Data.Array.IArray.(!) arr i b = Data.Array.IArray.bounds arr I'm not sure if I've managed to explain this problem clearly enough, but my proposal is that we might consider changing the lexical syntax of Haskell as follows: varId ::= id varOp ::= symbol varIdOp ::= ` varId varOpId ::= ( varOp ) varOpIdOp ::= ` varOpId qvarId ::= {conId .}+ varId -- { }+ denotes 1 or more times qvarIdOp ::= ` qvarId qvarOp ::= {conId .}+ varOp qvarOpId ::= {conId .}+ varOpId qvarOpIdOp ::= `qvarOpId In other words, to turn an operator symbol into an id, the parentheses would be put immediately around the symbol (with no spaces since this is lexical syntax), and to turn an id into an operator the backquote is put in front of the entire (qualified) id. (Also the trailing backquote in the existing syntax is redundant) The above syntax would have 3 advantages: 1) It allows the client of a module to write code without having to worry if the author of the module used symbols or identifiers to name functions - everything exported from the module can be made to appear as if it was named by an identifier (ie OpId) 2) Moving the parentheses to the lexical syntax makes syntax highlighting easier (because there are no comments to worry about inside the OpId) and also makes parsing simpler because all the mess associated with Ops versus Ids is handled by the lexer 3) It allows an editor to make a distinction between (+) -- an operator turned into an identifier - varOpId ( + ) -- an expression with 2 gaps in it which should be marked as incomplete (+ ) -- a section with 1 gap Some examples of the proposed syntax are: let ith = Data.Array.IArray.(!) arr i foo = k `Math.(+) 6 -- default precendence bar = k Math.+ 6 -- using precedence of + in module Math When you try to write an editor for Haskell (or some subset of it), you quickly discover these areas of Haskell syntax like the above which need to be changed to get an optimum interactive editing experience. I think it *is* possible to adjust the Haskell grammar so that it is LL(1) and the only reason it is not already LL(1) seems to be that the grammar has been designed with compilers (which only need to deal with complete modules) in mind rather than programmers interactively editing in mind. (The other change needed for LL(1) is to give contexts a marker before they appear eg: foo :: {MonadIO m} a -> m a ) By LL(1) I'm really meaning that the grammar for interactive editing needs to be adjusted so that it is possible to maintain the invariant that as code is entered from left to right constructs and identifiers can be highlighted according to their grammatical role and highlighting (modulo incompleteness) must remain unchanged regardless of whatever is typed afterwards to the right otherwise it can become more of a liability than a help, hence my hope that some future revision of Haskell grammar might consider taking the above points into account. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

9 14

Thanks !! (was: Newbie and working with IO Int and Int)
by Víctor A. Rodríguez 19 Oct '06

19 Oct '06

I want to thanks you all for your helps regarding this issue. You've been very helpful and comprehensive. Salute !! -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

1 0

Re: [Haskell] Lexically scoped type variables
by Bulat Ziganshin 19 Oct '06

19 Oct '06

Hello Simon, Wednesday, October 18, 2006, 12:09:40 PM, you wrote: > Other alternatives would be: do something about partial type > signatures; or make GADT type inference more sophisticated (and > thereby perhaps less predicatable). just one more problem is that this issue is too complicated. i'm not sure that i correctly understands details, but for me the situation seems like this: in 6.4 it was no distinction between declarations and usages of type variables - first use declared it, while in 6.6 we have exactly defined places to declare type variable. the problem is that sometimes we want to declare variable for one type but the place where it may be declared - function signature - requires to write full type so, if my understanding is correct, may be it's possible to use special syntax for explicit _declaration_ of type variable at any place where it can be used? i mean the following: f (x :: forall a. a) = undefined::a here, we use 'forall' to explicitly declare new type variable. so it is equivalent to the following: f :: forall a. a -> ... f x = undefined::a where '...' used to make partial type signature -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

beginner's problem about lists
by falseep＠gmail.com 19 Oct '06

19 Oct '06

Hi all, I'm trying to implement a function that returns the shorter one of two given lists, something like shorter :: [a] -> [a] -> [a] such that shorter [1..10] [1..5] returns [1..5], and it's okay for shorter [1..5] [2..6] to return either. Simple, right? However, it becomes difficult when dealing with infinite lists, for example, shorter [1..5] (shorter [2..] [3..]) Could this evaluate to [1..5]? I haven't found a proper implementation. Again it's ok for shorter [2..] [3..] to return whatever that can solve the above problem correctly. An infinite list could work, I guess, but I don't know how. Thanks for any help.

17 26

optimization help
by jeff p 18 Oct '06

18 Oct '06

Hello, I have been trying to do some CSV-style processing. My code works fine for small input (up to 10MB), but performs poorly for moderate to large input (it can't seem to finish 100MB of input with 700MB heap space). I have gone through several optimization passes with profiler help, and now I am hoping someone else can point out some other approaches to improving the code's performance (both space and time). The code breaks a large file into smaller files all of whose entries have the same date. thanks, Jeff ------------------------ module Main where import Debug.Trace import Control.Monad import Data.List import qualified Data.ByteString.Lazy.Char8 as B import qualified Data.Map as M import System.Environment (getArgs) dataDir = "dataH/" myRead file = do v <- B.readFile file let (cols' : rows) = map (B.split ',') $ B.lines v let cols = foldl' (\mp (k,v) -> M.insert k v mp) M.empty (zip cols' [0 ..]) return (cols, rows) getColId cols col = M.lookup col cols getCol cols col row = do i <- getColId cols col return $! row!!i dates file nRows = do (cols, rows) <- myRead file let addDate mp row | mp `seq` row `seq` False = undefined | otherwise = do date <- getCol cols (B.pack "\"Date\"") row let old = M.findWithDefault [] date mp return $ M.insert date (row:old) mp res <- foldM addDate M.empty $ take nRows rows mapM_ writeDate $ M.toList res where fmt = B.unpack . B.map (\x -> if x == '-' then '_' else x) . B.takeWhile (/= ' ') writeDate (date,rows) = B.writeFile (dataDir++fmt date) (B.unlines $ map (B.join (B.pack ",")) rows) main = do args <- getArgs case args of ["dates",file,nRows] -> dates file (read nRows)

4 16

Re: Lexically scoped type variables
by apfelmus＠quantentunnel.de 18 Oct '06

18 Oct '06

I think the problem comes from the fact that let (x :: a) = rhs in expr has two interpretations: either the programmer mainly specifies a judgment (\Gamma |- rhs :: a) (f.i. as a guide for type inference) or he just introduces a new variable and sees let as a sugar for (\(x :: a) -> expr) rhs with the viewpoint that the program is a huge expression and all top-level declarations are just (somewhat superflous) lambdas which lead to a final goal. In both cases, one would assume that the main variable binder is our good old lambda. Thus, the (::) in (\(x::a) -> ..) behaves like a constructor and the type variable on the right hand side is just a pattern: f (x :: [a]) = ... is not any different from f (Cons x [a]) = ... When f is applied to an argument, it's the type checker that performs "pattern matching". Of course, one needs nonlinear "type patterns": (f :: a -> b) $ (x :: a) = f x So the type variables in lambdas behaves like normal variables and things like g :: Int -> Int g (x :: a) = x + 1 :: a are entirely fine. All in all, type variables in lambdas are real variables. The first interpretation of let amounts to the Haskell98 intuition: the code x :: a -> a x = rhs means a judgment that x has type (forall . a -> a). This also means that this does not bring any new type variables in scope, only lambdas are capable of introducing new variables. GHC 6.6 rules are not compatible with that. They somehow admit variable bindings by judgments only to discover that this doesn't work for existential types. But note that we have (x :: ...) and (x=...) as separate statements, and we may well keep the second interpretation: f :: Int -> Int (f :: a -> a) = \x -> (x+1 :: a) The intuition is that stand-alone statements (x :: ...) are exactly what they look like: judgments for the type system. The only odd thing about them is that they are stand-alone and do not add to the "main program expression". IMHO, the most natural thing would be that type judgments appear on the rhs of a let or a lambda and that type variable bindings appear on the lhs of a let or a lambda. In the definition of f above, (f :: Int -> Int) and (x+1 :: a) are judgments and (f :: a -> a) is a variable binding. Any confusion between judgment and binding is just like a confusion between constructor application and pattern. Regards, apfelmus

1 0

Re: [Haskell-cafe] Newbie and working with IO Int and Int
by Víctor A. Rodríguez 18 Oct '06

18 Oct '06

> What's wrong with doing it this way? > > -- ** UNTESTED CODE ** > > verifyAdd :: Int -> Int -> Int -> Bool > verifyAdd a b sum | a + b == sum = True > otherwise = False > > testAddMundane :: Int -> Int -> Bool > testAddMundane a b = verifyAdd a b (a + b) > > -- all the IO-dependent stuff is below this line -- > > testAddRandom :: IO Bool > testAddRandom = do a <- randomIO > b <- randomIO > return verifyAdd a b (a + b) > I discovered something worst yet :-P Using the next code and calling verifyAdd or testAddMundane it says : Program error: verifyAdd: ERROR Instead calling testAddRandom only says : :: IO Bool (55 reductions, 92 cells) ---- CODE STARTS HERE, AND IS TESTED ----- import Random verifyAdd :: Int -> Int -> Int -> Bool verifyAdd a b sum = error "verifyAdd: ERROR" testAddMundane :: Int -> Int -> Bool testAddMundane a b = verifyAdd a b (a + b) -- all the IO-dependent stuff is below this line -- testAddRandom :: IO Bool testAddRandom = do a <- randomIO b <- randomIO return ( verifyAdd a b (a+b) ) -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

4 4

Re: 6.4 -> 6.6, scoped type variables
by oleg＠pobox.com 18 Oct '06

18 Oct '06

I too miss the old way of handling local type variables. Previously, local type annotations worked a lot like an additional constraint, with type variables denoting some type. The same type variable denoted the same type. Here's how it works in OCaml, for example: # let pair x y = (x,y);; val pair : 'a -> 'b -> 'a * 'b = <fun> # let pair1 (x:'a) (y:'a) = (x,y);; val pair1 : 'a -> 'a -> 'a * 'a = <fun> # let pair2 x y = ((x:'a),(y:'a));; val pair2 : 'a -> 'a -> 'a * 'a = <fun> # let pair3 x (y:int) = ((x:'a),(y:'a));; val pair3 : int -> int -> int * int = <fun> # let pair4 x (y:int) = ((x:'a list),(y:'a));; val pair4 : int list -> int -> int list * int = <fun> # let pair5 (x:'a list) (y:int) = (x,(y:'a));; val pair5 : int list -> int -> int list * int = <fun> Which of the two occurrences of the type variable |'a| a binding one? Who cares... It just works: within the same expression, the same type variable stands for the same type. > I'm looking for some tips and references regarding prescribing > poly-/mono-morphism. I know of three ways to do it: > 1) rely on the monomorphism-restriction -- kind of scary in that its > not explicitly obvious > 2) introducing scoped-type variables of interest -- explicit and modular > 3) introducing all type variables with a forall -- explicit but not modular It seems that with GCH 6.6, we are forced to go back to the fourth method -- the one that was available back in Haskell98. Use useless expressions to hint the typechecker. > bop :: forall x y z m c v . > ( SubType x v, SubType y v, SubType z v > , SubType (Fun m c v) v > , Monad m, Comonad c > ) => (x -> y -> z) -> Fun m c v > bop op = Fun fn > where fn = wrap fn' > where fn' v0 = (inj . Fun) (wrap fn'') > where fn'' v1 = inj (lazyPrj v0 `op` lazyPrj v1) > wrap :: (v -> v) -> (c v -> m v) > wrap = (return .) . (. counit) > If I leave the types to inference (i.e. drop the forall and the type > ascription for |wrap|), then I end up with this type > > bop :: ( SubType x v2, SubType y v1, SubType z v1 > , SubType (Fun m c v1) v2 > , Monad m, Comonad c > ) => (x -> y -> z) -> Fun m c v2 > Note the multiple |v|s; they wreak havoc in the rest of my code. It seems that you wish that, for example, v0 and v1 be of the same type. We have to be direct then and write where fn'' v1 = inj (lazyPrj v0 `op` lazyPrj (v1 `asTypeOf` v0) or where fn'' v1 = inj (lazyPrj v0 `op` lazyPrj v1) where useless = if True then v0 else v1 or where fn'' v1 | const True [v0,v1] = inj (lazyPrj v0 `op` lazyPrj v1) or something similar...

1 0

Type level functions (type of decreasing list)
by Greg Buchholz 18 Oct '06

18 Oct '06

I'm wondering about creating a data structure that has the type of decreasing numbers. If I want an increasing list, it is easy... > {-# OPTIONS -fglasgow-exts #-} > > data Succ a = S a deriving Show > data Zero = Z deriving Show > > data Seq' a = Cons' a (Seq' (Succ a)) | Nil' deriving Show ...which can be used like... > > zero = Z > one = S zero > two = S one > three = S two > > increasing = Cons' zero (Cons' one (Cons' two (Cons' three Nil'))) ...on the other hand, if I want the decreasing list, I can try... > > class Pre a b | a -> b > instance Pre (Succ a) a > instance Pre Zero Zero > > data (Pre a b) => Seq a = Cons a (Seq b) | Nil > > decreasing = Cons three (Cons two (Cons one Nil)) ...but that complains about "Not in scope: type variable `b'". Of course that makes perfect sense, but I'd like to know if there is a Haskell idiom that I'm missing in order to get this to work. Thanks, Greg Buchholz

3 3