- Haskell - Haskell.org

HBase Haddocumentation Available
by Ashley Yakeley 17 Jan '04

17 Jan '04

I now have some haddock for HBase available to browse. There's only one module missing, Org.Org.Semantic.HBase.Category.Constant, due to a kind declaration. Thanks to Simon M. for creating an excellent documentation tool. <http://hbase.sourceforge.net/haddock/> -- Ashley Yakeley, Seattle WA

1 0

OpenBSD/sparc Haskell support
by dons＠cse.unsw.edu.au 16 Jan '04

16 Jan '04

Hello OpenBSD Haskellers, GHC is now distributed for the sparc architecture in the OpenBSD ports tree. This means that happy, haddock, alex, hmake and other Haskell tools already in the tree are now being built for sparc/openbsd too. Just update to the current ports tree to use this stuff. Cheers, Don N.B. this is GHC 6.0.1, port tree builds for sparc, for 6.2 are coming soon

1 0

RE: Haddock and fixity declarations
by Simon Marlow 15 Jan '04

15 Jan '04

> could Haddock be made to document also fixity declarations? Yes, it's on the ToDo list. Cheers, Simon

1 0

GHC source bitten by the ghost of DOS
by Graham Klyne 15 Jan '04

15 Jan '04

I've just been bitten by the ghost of DOS when trying to unpack the source kit for GHC on a Windows (XP) system. It appears that the filename AUX is reserved (still crazy after all these years?). Unfortunately, the GHC source kit contains a file aux.dtd in .\ghc-6.2\src\libraries\HaXml\bugs So, when trying to copy this to my working system, I get strange errors that this file cannot be created. It's not a big deal for me -- I just unpacked the tar file on my Linux server machine, renamed the offending file, and the copy then works fine. But for Windows users without a Linux box to fall back on, this might be problematic. Maybe it's worth using another filename? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

overlapping instances and modules
by Iavor S. Diatchki 14 Jan '04

14 Jan '04

hello, i am a bit stuck on the following problem, which seems to be GHC related. consider the following two modules: > {-# OPTIONS -fglasgow-exts -fallow-overlapping-instances #-} > module Test where > > data T m a = T (m a) > > class C m where get :: m a > > instance C (T m) > instance C m => C (t m) > > obs :: T [] Int > obs = get > module Test1 where > > import Test > > obs' :: T [] Int > obs' = get i can load the first one (Test) without problems, but when i load the second one (Test1) a get the error: Test1.hs:6: No instance for (C []) arising from use of `get' at Test1.hs:6 In the definition of `obs'': obs' = get this seems to indicate that the second instance is being used, but i cannot figure out why. am i doing something silly here? -iavor ps: i am not on the GHC users list so please cc me if you replay there -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================

3 2

Haddock and fixity declarations
by Wolfgang Jeltsch 14 Jan '04

14 Jan '04

Hello, could Haddock be made to document also fixity declarations? Wolfgang

1 0

[Parsec] Extracting line and column numbers
by Stefan Holdermans 14 Jan '04

14 Jan '04

Hi, I'm using the Parsec library to parse strings for a small experimental language. I'd like to decorate each node in the abstract syntax tree with a pair (Int, Int) that represents the line and column number in the strings. Unfortunately, the SourcePos class in the Parsec library is abstract and I cannot extract the line and column numbers from a SourcePos value. What are my options? With kind regards, Stefan Holdermans

5 4

data label overloading
by Serge D. Mechveliani 14 Jan '04

14 Jan '04

Dear Haskellers, It is desirable to have shorter names for the data labels. Making a module out of a labeled data declaration does not look convenient. Providing the corresponding class operation is not always convenient. Maybe, future Haskell language could apprehend some special construct, like, say, in the following example data Foo1 = Foo1 {size :: Int ...} ... data Foo2 = Foo2 {size :: Int ...} ... f x y z = let size = Foo1..size in (size x) + (size y) + (Foo2..size z) ? "Foo.." is added when more than one type with the given label is visible in the scope. Copy, please, the answer to mechvel(a)botik.ru With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

GHC, functional dependency, rank-2 type
by oleg＠pobox.com 13 Jan '04

13 Jan '04

There appears to be a problem with GHC's handling of multi-parameter constraints with functional dependencies in the context of rank-2 types. The problem is not present in Hugs. Let us first consider a simple example: > module Test where > class Foo a > > class Bar a > > data Obj = Obj > > instance Bar Obj > > instance (Bar a) => Foo a > > foo:: (Foo a) => a -> String > foo _ = "works" > > runFoo:: (forall a. (Foo a) => a -> w) -> w > runFoo f = f Obj Here, the type of foo indicates > Test> :t foo > foo :: Foo a => a -> String that foo can be applied to the value of any type so long as it is in class Foo. The type of runFoo says that runFoo takes a function that can process the value of every type of class Foo. The function foo seems to be such a function. Therefore, "runFoo foo" should be well-typed. And it is, and it works, both in Hugs (version November 2002) and in GHC 6.0.1 (which is the current version for FreeBSD). However, if we make the classes Foo and Bar seemingly multi-parameter, the trouble begins: > class Foo a b | a->b > > class Bar a b | a->b > > data Obj = Obj > > instance Bar Obj Obj > > instance (Bar a b) => Foo a b > > foo:: (Foo a b) => a -> String > foo _ = "works" > > runFoo:: (forall a b. (Foo a b) => a -> w) -> w > runFoo f = f Obj In Hugs: > Test> :t foo > foo :: Foo a b => a -> String > Test> runFoo foo > "works" As before, the function foo promises to handle the value of any type a so long as "Foo a b" is satisfied (for any b -- although there can be only one such b, due to the functional dependency). The function runFoo takes any function that can handle the value of any type "a" subject to the "Foo a b" constraint. So, "runFoo foo" should be well-typed and should work. And it is, in Hugs. GHC 6.01 is a different matter, unfortunately. An attempt to load the above code in GHC succeeds, with flags: {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} Furthermore, the types of foo and runFoo seem to be in perfect match. > *Test> :t foo > foo :: forall a b. (Foo a b) => a -> String > *Test> :t runFoo > runFoo :: forall w. (forall a b. (Foo a b) => a -> w) -> w And yet, *Test> runFoo foo <interactive>:1: Could not deduce (Bar a b) from the context (Foo a b) arising from use of `foo' at <interactive>:1 Probable fix: Add (Bar a b) to the expected type of an expression In the first argument of `runFoo', namely `foo' In the definition of `it': it = runFoo foo Why all of the sudden does GHC need the constraint Bar a b? The function foo didn't ask for that... However, if we define foo and runFoo as follows: > foo:: (Foo a b) => a -> b -> String > foo _ _ = "works" > > runFoo:: (forall a b. (Foo a b) => a -> b -> w) -> w > runFoo f = f Obj Obj then both GHC and Hugs are happy: "runFoo foo" says that it works in both. What's more bizarre, even the following works: > runFoo:: (forall a b. (Foo a b) => a -> b -> w) -> w > runFoo f = f Obj undefined

2 2

ANNOUNCE: new FGL version (Jan 2004)
by Martin Erwig 13 Jan '04

13 Jan '04

FGL - A Functional Graph Library, Version: January 2004 ======================================================= I am happy to announce a new release of the Functional Graph Library for Haskell, a collection of graph algorithms and tools. New in this release: * bug fix for nearestNode (src/Data/Graph/Inductive/Query/GVD.hs) Update contributed by Aetion Technologies LLC (www.aetion.com) * Refactor into hierarchical namespace * Build changes: - build a standard haskell library (libHSfgl.a, HSfgl.o) - install as ghc package (fgl), uses Auto so no -package is needed * Automatic Node generation for labels: Data.Graph.Inductive.NodeMap * Graphviz output: Data.Graph.Inductive.Graphviz Download: http://eecs.oregonstate.edu/~erwig/fgl/haskell/ Please email comments, bug reports, etc. to erwig(a)cs.orst.edu -- Martin

1 0