August 2008 - Haskell-Cafe

problem with cabal for syb-with-class
by Andrew U. Frank 27 Aug '08

27 Aug '08

i tried to install wxGeneric and need syb-with-class. i got the package from hackage. configure runs fine, but when i build i get: Data/Generics/SYB/WithClass/Instances.hs:11:7: Could not find module `Data.Array': it is a member of package array-0.1.0.0, which is hidden but array-0.1.0.0 is installed, as shown later. what can be wrong? why is an installed package complained about as hidden? thanks for help! andrew frank@bernH:~/haskellSources/packages/syb-with-class-0.3$ ghc-pkg describe array name: array version: 0.1.0.0 license: BSD3 copyright: maintainer: libraries(a)haskell.org stability: homepage: package-url: description: This package defines the classes @IArray@ of immutable arrays and @MArray@ of arrays mutable within appropriate monads, as well as some instances of these classes. category: author: exposed: True exposed-modules: Data.Array Data.Array.Base Data.Array.Diff Data.Array.IArray Data.Array.IO Data.Array.MArray Data.Array.ST Data.Array.Storable Data.Array.Unboxed hidden-modules: Data.Array.IO.Internals import-dirs: /usr/lib/ghc-6.8.2/lib/array-0.1.0.0 library-dirs: /usr/lib/ghc-6.8.2/lib/array-0.1.0.0 hs-libraries: HSarray-0.1.0.0 extra-libraries: extra-ghci-libraries: include-dirs: includes: depends: base-3.0.1.0 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: /usr/share/doc/ghc6-doc/libraries/array/array.haddock haddock-html: /usr/share/doc/ghc6-doc/libraries/array f

5 10

Associative Commutative Unification
by John D. Ramsdell 27 Aug '08

27 Aug '08

I'd like to write an obviously correct implementation of a unifier, a program that when given two terms, finds a substitution that makes the two terms equal. The phrase "obviously correct" is meant to imply that the clarity of the code trumps efficiency. As near as I can tell, high performance unifiers are full of side-effects, and achieving the same performance without side-effects in Haskell is difficult or impossible. In contrast, it is easy to write obviously correct Hasklell implementations of unifiers for freely generated term algebras. One can use Lawrence Paulson's code in ML for the Working Programmer as a template or follow Martelli and Montanari's simple set of rules. My problem is one of my operators is multiplication, which is associative and commutative. These two properties make unification much more difficult. Mark Stickel described a complete unification algorithm for this problem, but the task of translating his description into an obviously correct Haskell program appears to be difficult. For example, the algorithm requires the generation of the basis of solutions to linear homogeneous diophantine equations. I haven't located an algorithm for this part yet. If you have experience implemented equational unification in Haskell, please share it. John

6 9

Problem building the plugins package
by Emmanuel 27 Aug '08

27 Aug '08

Hello I am having troubles building the plugins package : manu:~/Desktop/tmp manu$ cabal install plugins Resolving dependencies... cabal: cannot configure plugins-1.2. It requires ghc >=6.8 There is no available version of ghc that satisfies >=6.8 I am on a Mac PPC (OS X 10.4) with ghc-6.8.2 and Cabal-1.4.0.1 so the error message is puzzling... Can anyone help ? I'd like to install Lambdabot and plugins is one of the dependencies... Thanks Manu

1 0

timer_create revisited
by Brandon S. Allbery KF8NH 27 Aug '08

27 Aug '08

I'm trying to build GHC 6.8.2 (6.8.3 once I get all this nailed down...) from an old bootstrap ghc on SuSE 9.3-64 (yes, I know) because the 6.6.1 and newer binary tarballs for amd64 Linux doesn't work with the "timer_create" issue. The problem is, having built a shiny new 6.8.2 both stage1 and stage2, the result works but compiled programs have the "timer_create" problem. (??) At this point I'm stymied. Suggestions, other than "upgrade" (not currently possible due to commercial software support and timing issues)? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

1 0

ANNOUNCE: Wired 0.1.1
by Emil Axelsson 27 Aug '08

27 Aug '08

Hello, This is to announce the first release of the hardware description library Wired. Wired can be seen as an extension to Lava that targets (not exclusively) semi-custom VLSI design. A particular aim of Wired is to give the designer more control over the routing wires' effects on performance. The only working backends in this version are simulation and verification (through Lava), and generation of postscript layouts. Soon, there will also be static timing analysis and DEF file generation. The DEF format is accepted by most tools for physical design. Wired is available from Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Wired or using Darcs: darcs get http://www.cs.chalmers.se/~emax/darcs/Wired/ There is also a homepage at: http://www.cs.chalmers.se/~emax/wired/index.html Comments, questions, patches are welcome. Cheers, / Emil

1 0

Re: [Haskell] Another First course in Haskell
by Johannes Waldmann 27 Aug '08

27 Aug '08

Piyush P Kurur wrote: ( http://article.gmane.org/gmane.comp.lang.haskell.general/16390 ) > I am planing a haskell based functional programming course. > It is supposed to be a first course and I intend to show how > real world applications can be built quite easily in haskell. > Any feed back is really welcome. Is it a first course in programming, or in functional programming? Either way, I recommend focus on "data" and then "class/instance", i.e. have the students use algebraic data types right from the beginning (*). Another idea for teaching is to introduce the language by having the students use standard libraries (e.g. Data.Map), also right from the start. So they are forced to read type signatures etc. (**) (*) that's the main problem I see with Hutton's book http://www.cs.nott.ac.uk/~gmh/book.html : it has "Declaring types and classes" as chapter 10 (of 13 total). I think that's way off - and it leaves readers (students) with the impression that declarative programming basically deals with (functions on) lists. This may have been true in the 70s/80s (LISP, Prolog), but it certainly shouldn't be true today. Recall the proverb "Get your data structures correct first, and the rest of the program will write itself." (David Jones, cited in John Bentley: More Programming Pearls) I think this is independent of language and paradigm. (**) again, Hutton's book does not contain a single "import" declaration in the programming examples (did not check fully, but got this impression while browsing). Yes , Data.* is not Standard Haskell(98) and that's probably why he avoided it but the result diametrically contradicts everyday programming experience where the typical application program (in any language) is just some glue between library functions that do 90 percent of the actual work. Sure, a student programmer must be able to write a stand-alone bubble/quick/mergesort but it is equally (if not more) important that he knows how to (1) find and (2) call a sorting routine in any given programming environment. (So, have your students use http://www.haskell.org/hoogle/ ) Best regards, J.W.

4 6

apparent minor bug in "Getting started" tutorial at "Haskell Hacking: a journal of Haskell programming"
by Benjamin L.Russell 27 Aug '08

27 Aug '08

This is just a minor documentation bug report, but I tried following the instructions in the "Getting started" tutorial at "Haskell Hacking: a journal of Haskell programming" (http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/16#programming-haskell-intro) for GHCi 6.8.3 on Windows XP Professional (Service Pack 2), as follows: >You can compile this code to a native binary using GHC, by writing in a source file: > > main = putStrLn "G'day, world!" > >and then compiling the source to native code. Assuming your file is A.hs: > > $ ghc A.hs > >This produces a new executable, ./a.out (a.out.exe on windows), which you can run like any other program on your system: > > $ ./a.out > G'day, world! However, this produced the following files, instead: A.hi A.o main.exe main.exe.manifest There was no a.out file, and running A.o popped up a Windows dialog box asking me to specify which application to run the program with. So, I ran $ ghc --help and found the following documentation: >To compile and link a complete Haskell program, run the compiler like >so: > > ghc --make Main > >where the module Main is in a file named Main.hs (or Main.lhs) in the >current directory. The other modules in the program will be located >and compiled automatically, and the linked program will be placed in >the file `a.out' (or `Main.exe' on Windows). > >[...] > >Given the above, here are some TYPICAL invocations of ghc: > > # compile a Haskell module to a .o file, optimising: > % ghc -c -O Foo.hs Running $ main.exe produced the desired result: >G'day, world! Would it be possible to update the documentation to reflect the need to enter $ main.exe after compilation instead of $ a.out ? Thank you. -- Benjamin L. Russell

2 2

Re: [Haskell-cafe] Re: [Haskell] Top Level <-
by Adrian Hey 27 Aug '08

27 Aug '08

Lennart Augustssom wrote: > Since at some point you have to interface with the hardware you are > forced to obey whatever convention is used for interrupts etc. At that > point you may very well have to use global variables. But you can > quickly abstract away from that in stay in the safe land without globals. BTW, did you notice that the non-hosted driver API example I put on the wiki page doesn't use "globals" either :-) The two device handles are at the top level (are "globals" as you would say), but the driver code takes these as an argument so doesn't care if they're top level or not. If I don't have the device handles at the top level or some means to get them from the top level then I have no alternative but to export createDeviceHandle either directly to the "user level" API (really bad!) or to some other bit of higher level system code that can be trusted not to create 2 or more handles for the same device (and no handles for non-existant devices). Let's assume it's that latter. In the simple case where it is known at compile time that there are exactly 2 devices in the system at known base addresses, can you explain how the higher level bit of the system guarantees that user level application code will only ever have access to 2 different device handles in total (one for each device), no matter what? How does it solve this problem in the more complex complex case where hardware must be probed somehow to discover how many devices there are and where they are? All without using any global variables please. Also, assuming you succeed, please explain what advantages or extra safety your solution provides over a solution which does use global variables. The obvious solution seems to be to have this code present this function to the user level API.. getAvailableDeviceHandles :: IO [DeviceHandle] Which shouldn't be hard to implement in either case, except for the fact IO state "getters" can't be implemented at all without top level mutable state or runOnce primitives or something like that (AFAICS). newAvailableDeviceHandles perhaps? I guess that could come in handy if the user code decides it doesn't like the old ones for some reason :-) Regards -- Adrian Hey

1 0

best runProcess solution to work with windows and linux
by Andrew U. Frank 27 Aug '08

27 Aug '08

i use System.POSIX.IO to run a process and access the handles (after due transformation) to get the values back. this solution is unfortunately not portable and works only on unix (or cygwin) but not for plain windows. there seems to be a somewhat comparable package in system.win32.process. is there a solution independent of OS? what is the best approach to use to run a process and read the result back which works in both unix and windows? any suggestion highly appreciated! andrew

2 1

Re: [Haskell] Top Level <-
by Adrian Hey 27 Aug '08

27 Aug '08

(Moving to Haskell cafe) Edward Kmett wrote: > On Sun, Aug 24, 2008 at 7:12 PM, Ashley Yakeley <ashley(a)semantic.org> wrote: > >> Is there any interest in implementing a top level "<-" to run monadic code? >> > > This is actually implemented in jhc. See the 'top level actions' section of > http://repetae.net/computer/jhc/manual.html Gosh! I was always quite impressed by Johns determination to write a Haskell compiler and by his self discipline in resisting the temptation to fix everything that was wrong with Haskell and keep to standards :-) I implemented my own ACIO monad a while ago (which is of course quite useless without top level <- bindings) and it turned out that there was quite a lot that could go in here. The only problem seemed to be that some things that seemed perfectly reasonable to create via ACIO had *IO* finalisers associated with them, which didn't feel right to me. But if you think about how finalisers get run I'm inclined to think we should insist that they are ACIO too. Regards -- Adrian Hey

4 13