- Haskell-Cafe - Haskell.org

Cabal ^M bug
by Vyacheslav Akhmechet 18 Nov '06

18 Nov '06

Cabal appears to have an end-of-line bug. If the .cabal file is created on Windows and the project is installed on a Unix system, the resulting executable ends up having ^M at the end because Cabal doesn't properly handle Windows line termination. If the .cabal file is converted to Unix style, everything installs as expected. I tried to submit a ticket to Cabal via the wiki but couldn't authenticate (guest/haskell, as says on the web page, doesn't seem to work). Also HackageDB link seems to be down. I'm not sure who's maintaining the project, so I'm emaling here. Thanks, - Slava.

1 0

Type signatures in FFI exported functions
by Alfonso Acosta 18 Nov '06

18 Nov '06

Hi, The FFI doesn't allow using type signatures in exported functions. Imagine this simplified example class Foo a where action1 :: a -> IO() action2 :: a -> IO() exportable :: Foo a => StablePtr a -> IO() exportable ptr = do deref <- deRefStablePtr ptr action1 deref Currently the FFI doesn't allow to export exportable due to the type signature. But I don't really understand why isn't it feisable. In my code I solved the problem by quantifying existentially data CFoo = forall a.Foo a => CFoo a instance Foo CFoo where action1 (CFoo a) = action1 a action2 (CFoo a) = action2 a exportable' :: StablePtr CFoo -> IO() exportable' ptr = do deref <- deRefStablePtr ptr action1 a Another way to fix it would be, unlike standard Haskell98, allowing dictionaries to be packaged in data constructors data CFoo' a = Foo a => CFoo' a instance Foo (CFoo' a) where action1 (CFoo' x) = action1 x action2 (CFoo' x) = action2 x exportable'' :: StablePtr (CFoo' a) -> IO() exportable'' ptr = do deref <- deRefStablePtr ptr action1 deref As far as I know, the later option has only been recently made available for GADTs in GHC, does anyone know away of doing it with normal ADT? Does anyone know a better workaround? Thanks in advance, Alfonso Acosta

1 0

Debugging partial functions by the rules
by dons＠cse.unsw.edu.au 18 Nov '06

18 Nov '06

So all this talk of locating head [] and fromJust failures got me thinking: Couldn't we just use rewrite rules to rewrite *transparently* all uses of fromJust to safeFromJust, tagging the call site with a location? To work this requires a few things to go right: * a rewrite rule * assertions * and rewrite rules firing before assertions are expanded Let's try this. Consider the program: 1 import qualified Data.Map as M 2 import Data.Maybe 3 4 main = print f 5 6 f = let m = M.fromList 7 [(1,"1") 8 ,(2,"2") 9 ,(3,"3")] 10 s = M.lookup 4 m 11 in fromJust s When we run it we get the not so useful error: $ ./A A: Maybe.fromJust: Nothing Ok, so we have a few tricks for locating this, using LocH (http://www.cse.unsw.edu.au/~dons/loch.html) we can catch an assertion failure, but we have to insert the assertion by hand: 1 import Debug.Trace.Location 2 import qualified Data.Map as M 3 import Data.Maybe 4 5 main = do print f 6 7 f = let m = M.fromList 8 [(1,"1") 9 ,(2,"2") 10 ,(3,"3")] 11 s = M.lookup 4 m 12 in safeFromJust assert s 13 14 safeFromJust a = check a . fromJust Which correctly identifies the call site: $ ./A A: A.hs:12:20-25: Maybe.fromJust: Nothing Now, this approach is a little fragile. 'assert' is only respected by GHC if -O is *not* on, so if we happened to try this trick with -O, we'd get: $ ./A A: Debug.Trace.Location.failure So lesson one: you have to do the bug hunting with -Onot. Currently there's -fignore-asserts for turning off assertions, but no flag for turning them on with -O, Simon, could this be fixed? Could we get a -frespect-asserts that works even with -O ? Ok, assuming this assert trick is used, can we get the compiler to insert the asserts for us? If so, this would be a great advantage, you'd just be able to switch on a flag, or import a debugging module, and your fromJusts would be transparently rewritten. With rewrite rules we do just this! So, to our initial unsafe use of fromJust, we add a rewrite rule: -- -- rewrite fromJust to a located version, and hope that GHC expands -- 'assert' after the rule fires.. -- {-# RULES "located fromJust" fromJust = check assert . myFromJust #-} This just tells the compiler to replace every occurence of fromJust with a assertion-throwing fromJust, should it fail. We have to use myFromJust here, to avoid rule recursion. -- -- Inlined to avoid recursion in the rule: -- myFromJust :: Maybe a -> a myFromJust Nothing = error "Maybe.fromJust: Nothing" -- yuck myFromJust (Just x) = x Ok, so can we get ghc to rewrite fromJust to the safe fromJust magicaly? $ ghc --make -Onot A.hs -fglasgow-exts -ddump-simpl-stats [1 of 1] Compiling Main ( A.hs, A.o ) 1 RuleFired 1 located fromJust Linking A ... Yes, the rule fired! GHC *did* rewrite our fromJust to a more useful fromJust. Running it: $ ./A A: A.hs:19:36-41: Maybe.fromJust: Nothing Looks good! But that is deceiving: the assert was expanded before the rule fired, and refers to the rewrite rule source line (line 19), not the fromJust call site (line 12). Now if we could just have the 'assert' token inserted into the AST before it was expanded, we'd be home and dry. Could this be done with TH? Or could we arrange for asserts in rewrite rules not to be expanded till later? Note that this is still a useful technique, we can rewrite head/fromJust/... to some other possibly more useful message. And if we can constrain the rule to fire in only particular modules, we may be able to narrow down the bug, just by turning on a rule. For example, adding: {-# RULES "located fromJust" fromJust = safeFromJust #-} safeFromJust s = case s of Nothing -> "safeFromJust: failed with Nothing. Ouch" Just x -> x will produce: $ ./A "safeFromJust: failed with Nothing. Ouch" So rewrite rules can be used to transparently alter uses of partial functions like head and fromJust. So, further work: * have 'assert' respected when -O is on * think up a technique for splicing in 'assert' via rewrite rules (or TH ...) such that the src locations are expanded after the rewrite, and correctly reflect the location of the splice point. Any ideas? -- Don

6 10

Re: Debugging partial functions by the rules
by oleg＠pobox.com 18 Nov '06

18 Nov '06

Donald Bruce Stewart wrote: > So all this talk of locating head [] and fromJust failures got me > thinking: > > Couldn't we just use rewrite rules to rewrite *transparently* > all uses of fromJust to safeFromJust, tagging the call site > with a location? I'm sorry for shifting the topic: I'm wondering if, rather than trying to make an error message more informative, we ought to make sure that no error will ever arise? The fromJust and `head of empty list' errors are totally equivalent to the dereferencing of zero pointer in C++ or NullPointerException in Java. It pains me to see that exactly the same problem arises in Haskell -- keeping in mind that already in C++ and Java one may exterminate these errors given right encapsulations. Languages like Cyclone or Cw use the type system to eliminate such errors. Surely Haskell can do something about this? This topic has been discussed at length on this list. It seems that the discussion came to the conclusion that eliminating head of the empty list error is possible and quite easy in Haskell. http://www.haskell.org/pipermail/haskell-cafe/2006-September/017915.html http://www.haskell.org/pipermail/haskell-cafe/2006-September/017937.html As to fromJust: would the world come to an end if this function is just not available? Oftentimes when we get the value of the type |Maybe a|, the algorithm prescribes the actions for the case if this value is Nothing. Thus the function `maybe', the deconstructor, seems to be called for. And if we are dead sure that the |Maybe a| value is definitely |Just smth| and we need to extract this |smth|, we can always write maybe (assert False undefined) id value I like how this phrase stands out in the code, to remind me to double-check my certainty about the value (and perhaps, to re-factor the code). Similarly for empty lists: it is often algorithmically significant as it is the base case for our recursion/induction. Thus, we have to make the null check according to the algorithm anyway. The type system can carry the result of such a test, so we don't have to repeat it. The functions head and tail should operate on the newtype NonemptyList -- in which case they are total. Other list functions may remain as they are, because we can always `forget' the NonemptyList tag. The run-time overhead is zero, the notational overhead is not much: writing a few extra `fromNonemptyList'. Compare with writing `fromIntegral', especially in the FFI-related code. The Haskell type system can do far more complex things, for example, solve the pervasive SQL injections and cross-site scripting problems: http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-st… (This URL appeared on one of the recent Haskell Weekly News, btw). Surely we can do something about a far simpler problem of head [] and fromJust? We may have to adjust our coding styles a little. The adjustment doesn't appear extensive; besides, isn't the whole point of programming in Haskell is to think differently?

20 31

working with lists of couples
by Clara Zamolo 18 Nov '06

18 Nov '06

Hello, i'd like to write a function that given a list like [1,2,3,4...] returns a list of couple where the first element is the corresponding element of the string, and the second is the sum of the previous elements. An example: input: [1,2,3,4] output: [(1,0)(2,1)(3,3)(4,6)] The problem could seem trivial, and here's a first solution: buildCouples = snd . foldl op (0,[]) where op (v,xs) x = (v+x,xs++[(x,v)]) The problem is that this solution is quadratic, and I want a solution that take time n (2n is not good either). Any suggestion? Thanks, Clare.

4 4

Are associated types synonyms like type classes?
by Brian Smith 18 Nov '06

18 Nov '06

I read the easy parts of the "Associated Types with Class" and "Associated Type Synonyms" papers. An associated type synonym seems to kind of work similarly to a restricted form of class. In what way are the two following examples different? -- define a class with a type synonym, and a set of operations class A a where type B b foo :: a -> B b instance A Int where type B = Bool foo = (==0) -- define two classes, and an function that . class A a, B b where foo :: a -> b instance A Int, B Bool where foo = (==0) Also, has anybody written a paper on the differences between typeclasses + associated types and ML's module system + overloading? Thanks, Brian

4 5

Re[2]: [Haskell] I18N, external strings
by Bulat Ziganshin 18 Nov '06

18 Nov '06

Hello Axel, Friday, November 17, 2006, 11:27:00 AM, you wrote: > (l_ "Translate this") > is compiled into a C string constant, that GHC then turns lazily into a > list of characters, which l_ then turns into an array in C land to pass > to the gettext function, which, in turn, returns a new C string array > that has to be turned into a Haskell string again. So I'm glad Lennart > proposed to turn String into a class which would then make it possible > to pass a pointer to a contant C string to gettext. i'm not sure that you are right. GHC can perform compile-time computation of constant expressions. Don Bruce should know better, once he pointed out how a String constant can be turned into ByteString one at compile time -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

Updated School of Expression Sources?
by Justin Bailey 17 Nov '06

17 Nov '06

I downloaded the SOE sources from http://www.haskell.org/soe and found they were not compatible with the my version of WinHugs (Sep 2006). I have two questions: 1) Is an updated version of those sources available? 2) If not, would someone like to host mine? I updated all the source files so they at least load without error. Mostly it involved changing a few import statements. I also had to make some updates to the included Haskore files. Also, I found the some of the programs included crash Hugs without warning. For example, evaluating "test cball5" in the file "Fal.lhs" will crash Hugs after running for a few seconds, or if the mouse is moved over the window. Does anyone know why that may occur? Justin

3 2

Newbie; Can't Install Hat From Source
by Aditya Siram 17 Nov '06

17 Nov '06

Hi all, I have been trying to install Hat for the last couple of days but GHC does not recognize it as a package. I compiled 2.05 from source, but at the 'make install' step I see this error message: **Begin Output** ./configure --install Configuring for hat... [ 2.05 ] Starting with earlier config in targets/ix86-Linux/config.cache [ config: ix86-Linux/ by deech@ubuntu on 15 Nov 2006 ] (but cmdline options have precedence) -------- Looking for already-installed Haskell compilers: Looking for ghc... found 6.6 Looking for nhc98... (not found) Looking for hmake... found 3.13 You said you want to use ghc to build hat. Done. -------- Configuration report for hat. You are going to build hat with: ghc Executables need .exe suffix? no (detected) Testing for the glib library: no (using slower replacement) Installation directories are now created/checked. Install directory root is: /usr/local Hat interface files (.hx) go into: /usr/local/include/hat-2.05 (exists) Array.hx ...... Debug/Trace.hx Installing hat as a ghc package: Installing hat package for ghc under /usr/local/lib/hat-2.05/ix86-Linux/ghc-606 ghc-pkg: cannot find package hat <-----ERROR MESSAGE!!!!! Reading package info from stdin ... done. ghc-pkg: package hat-2.4 is already installed Scripts go into: /usr/local/bin (exists) hat-graph hat-trans hat-tools: hat-stack hat-check hat-observe hat-detect hat-delta hat-view hat-trail hat-anim hat-explore hat-cover black-hat hat-nonterm pretty-hat Executables go into: /usr/local/lib/hat-2.05/ix86-Linux (exists) config hat-anim hat-check hat-cover hat-delta hat-detect hat-explore hat-nonterm hat-observe hat-stack hat-trail hat-trans hat-view black-hat pretty-hat Man pages go into: /usr/local/man/man1 (exists) hat-anim.1 hat-delta.1 hat-detect.1 hat-observe.1 hat-stack.1 hat-trail.1 hat-trans.1 pretty-hat.1 Not (re-)installing html documents Saving current configuration in targets/ix86-Linux/config.cache Done. Please ensure /usr/local/bin is in your PATH variable. **End Of Output** The output of 'ghc-pkg list' is: /usr/local/lib/ghc-6.6/package.conf: Cabal-1.1.6, HUnit-1.1, QuickCheck-1.0, base-2.0, cgi-2006.9.6, fgl-5.2, (ghc-6.6), haskell-src-1.0, haskell98-1.0, html-1.0, mtl-1.0, network-2.0, parsec-2.0, readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.0, time-1.0, unix-1.0, xhtml-2006.9.13 /home/deech/.ghc/i386-linux-6.6/package.conf: (hat-2.4) <----ERROR!!! For some reason it thinks that hat-2.4 is installed. I tried to run a test program saved in HatTest.hs: import Prelude main = do { print "Hello"; } When I compile it with 'hmake -hat HatTest' I get the following error: hat-trans HatTest.hs Wrote Hat/HatTest.hs ghc-6.6 -c -package hat -o Hat/HatTest.o Hat/HatTest.hs Hat/HatTest.hs:3:0: Bad interface file: /usr/local/imports/hat-2.05/ghc-606/Hat/PreludeBasic.hi Something is amiss; requested module hat-2.4:Hat.PreludeBasic differs from name found in the interface file hat:Hat.PreludeBasic I'm not really sure how to proceed. Any help is appreciated. BTW I get the ghc-package: cannot find package hat when I 'apt-get install' it too. Thanks.. Deech _________________________________________________________________ View Athletes Collections with Live Search http://sportmaps.live.com/index.html?source=hmemailtaglinenov06&FORM=MGAC01

2 2

Generalizing zip
by Jason Dagit 17 Nov '06

17 Nov '06

In #haskell on freenode we had a discussion about isPrefixOf, which is probably implemented roughly as so: isPrefixOf [] _ = True isPrefixOf _ [] = False isPrefixOf (x:xs) (y:ys) = x == y && isPrefixOf xs ys Well, this is basically just a zip with a special base case. But you can't just write it with zipWith because zipWith stops when it exausts either list. How about we define zipWith'' like this: zipWith'' _ [] _ l _ = [l] zipWith'' _ _ [] _ r = [r] zipWith'' f (x:xs) (y:ys) l r = f x y : zipWith'' f xs ys l r Then we can write: isPrefixOf xs ys = and (zipWith'' (==) xs ys True False) A point free reduction might look like the following and probably isn't worth it: isPrefixOf = (and .) . flip flip False . flip flip True . zipWith'' (==) Are there lots of other places where this zipWith'' would come in handy? It seems like I've found lots of times when I needed to manually code the recursion because of the way zip behaves when it exhausts one of its parameter lists. Jason

3 3