June 2006 - Haskell-Cafe

Separate a string into a list of strings
by Sara Kenedy 18 Apr '08

18 Apr '08

Hi all, I want to write a function to separate a string into a list of strings separated by commas. Example: separate :: String -> [String] separate "Haskell, Haskell, and Haskell" = ["Haskell", "Haskell", "and Haskell"] If anyone has some ideas, please share with me. Thanks. S.

14 35

Creating static libraries using GHC
by Tom Hawkins 16 Mar '07

16 Mar '07

I have a chunk of Haskell code I would like wrap up and distribute as a library. Is there a way to build a static library (*.a) that includes my code plus the Haskell runtime, which C programs can easily link against? Here is what I have tried so far... ghc --make -fffi MyLib # Builds MyLib.o and MyLib_stub.o. gcc -c -I/usr/local/lib/ghc-6.4.1/include MyLibWrapper.c ar -r libMyLib.a MyLib.o MyLib_stub.o MyLibWrapper.o This works fine when I use ghc to compile and link a C program... ghc main.c libMyLib.a But if I use gcc, it throws a lot of unresolved references. I have no problem compiling with ghc, but the folks using my library probably won't have it installed. I added -v to ghc to see how it calls gcc; it seems to link in different libraries based on what Haskell libraries are being used, and it undefines a bunch is symbol references. Are there any switches to have ghc return a single archive with everything included? Please excuse my ignorance of the linking process. Thanks for any help! -Tom

3 2

Computing lazy and strict list operations at the same time
by C Rodrigues 27 Sep '06

27 Sep '06

Here's a puzzle I haven't been able to solve. Is it possible to write the initlast function? There are functions "init" and "last" that take constant stack space and traverse the list at most once. You can think of traversing the list as deconstructing all the (:) [] constructors in list. init (x:xs) = init' x xs where init' x (y:ys) = x:init' y ys init' _ [] = [] last (x:xs) = last' x xs where last' _ (y:ys) = last' y ys last' x [] = x Now, is there a way to write initlast :: [a] -> ([a], a) that returns the result of init and the result of last, takes constant stack space, and traverses the list only once? Calling reverse traverses the list again. I couldn't think of a way to do it, but I couldn't figure out why it would be impossible.

10 14

Packages and modules
by Brian Hulley 10 Jul '06

10 Jul '06

Hi - At the moment there is a problem in that two packages P and Q could contain the same hierarchical module eg Data.Foo, and the only way for user code to ensure the "right" Data.Foo is used is to ensure that packages P and Q are searched in the right order. However suppose P and Q also contain another module with the same name, eg Data.Bar. And suppose a user module wants to use Data.Foo from P but Data.Bar from Q!!! I'm wondering: would it not be easier to just make it that the package name is prepended to the hierarchical module name, so the modules would instead be called by the names P.Data.Foo and Q.Data.Bar? As I see it, this would have at least these advantages: 1) A package author would only have to ensure that the name of the package (eg Edison, FPS, Base) is globally unique, and would then be free to name the modules in the package without having to worry about conflicts with other packages 2) Users of packages could specify exactly which modules they want to use, which would also make it easier to switch between different implementations of the same data type provided by different people etc 3) When you read the program text, you could immediately see which packages the modules came from, so you would know which packages you need to download if you don't currently have that module on your system. (At the moment, if I come across "import Data.Foldable" I've got no idea where to get it from.) It seems to me that the only reason this wasn't done in the first place was that originally there was just a flat module namespace, whereas with hierarchical modules it seems obvious to put the package name at the beginning (eg in Java the modules are called java.xyz, com.company.xyz etc to ensure there are no namespace conflicts) (On the Haskell' wiki there is http://hackage.haskell.org/trac/haskell-prime/wiki/SolveThePackageAbstracti… but this doesn't appear to consider the above solution.) 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

16 37

Re: Comments from Brent Fulgham on Haskell and the shootout
by Simon Marlow 05 Jul '06

05 Jul '06

John Meacham wrote: > On Tue, Jun 27, 2006 at 02:58:05PM +0100, Simon Marlow wrote: > >>>.. (and jhc already generates native C code, so it will have at least >>>one substantial advantage over GHC) ... >> >>Compiling via C is a dead end. We realised this about 5 years ago, and >>yet we still haven't managed to shake off the C backend from GHC, but I >>remain hopeful that one day we will. /me heads for the cafe... > > Out of curiosity, compiling via C as opposed to what? c--? Parrot? JVM? C-- ultimately, but in the meantime GHC's built in native-code generator. Our NCG is quite reasonable, and we plan to push it forward in various ways to improve the generated code. There's a wiki page with some ideas: http://hackage.haskell.org/trac/ghc/wiki/BackEndNotes Cheers, Simon

6 13

Re: [haskell] ANNOUNCE: HNOP 0.1
by mvanier 05 Jul '06

05 Jul '06

[Moving to haskell-cafe] OK, after going through this several times, here's what I've found: 1) The Debian linux build of haskell produces large executables. 2) The generic x86 binary distribution produces smallish executables (383765 bytes; still kind of large; stripped it's 191584 bytes). 3) I removed my entire source distribution, and recompiled from scratch with this build.mk file: SRC_HC_OPTS = -H64m -O2 GhcLibHcOpts = -O2 -fgenerics SplitObjs = YES I did an "autoreconf; configure; make; make install" and then recompiled hnop from scratch. I got large executables (2838528 bytes unstripped, 1540072 stripped). I'm at a loss here. Somehow, the SplitObjs option doesn't seem to be doing the job. Any suggestions would be appreciated. Mike Donald Bruce Stewart wrote: > Hmm. Did you build from scratch? Perhaps the libraries didn't get > rebuilt with split objs ? > > > mvanier: >> I've tried doing a manual build with SplitObjs set to YES, but without >> success; either the compiler was broken or it would still generate large >> executables. So as a sanity check, I installed the debian unstable build. >> But that one also gives me a huge executable: >> >> % ls -l >> total 2720 >> -rw-r--r-- 1 mvanier mvanier 818 Jun 29 20:48 LICENSE >> -rw-r--r-- 1 mvanier mvanier 308 Jun 30 04:59 Main.hi >> -rw-r--r-- 1 mvanier mvanier 80 Jun 29 20:48 Main.hs >> -rw-r--r-- 1 mvanier mvanier 1928 Jun 30 04:59 Main.o >> -rw-r--r-- 1 mvanier mvanier 43 Jun 29 20:48 Makefile >> -rwxr-xr-x 1 mvanier mvanier 2756151 Jun 30 04:59 hnop >> -rw-r--r-- 1 mvanier mvanier 807 Jun 29 23:56 hnop.tar.gz >> >> Am I the only person in the world with this problem? >> >> Also, for some inexplicable reason, debian puts ghci into /usr/X11R6/bin, >> though ghc is in the more sensible /usr/bin/ghc. >> >> TIA, >> >> Mike >> >> Donald Bruce Stewart wrote: >>> mvanier: >>>> Nope, just ghc-6.4.2 that I compiled myself on a Dell x86 laptop (Pentium >>>> M). I didn't use any strange configure options. Is there a special >>>> configure flag for split objects? If not, how is this determined? >>> Ah ha! You need to add -split-objs to the build.mk used by ghc to build >>> its libraries, as described here: >>> http://cvs.haskell.org/cgi-bin/cvsweb.cgi/~checkout~/fptools/ghc/HACKING?co… >>> >>> You want: >>> SplitObjs = YES >>> >>> in mk/build.mk >>> >>> It's not enabled by default, since it doesn't work on every platform. >>> The ghc that is distributed in the debian package system does have split >>> objs on, though. >>> >>> Cheers, >>> Don

3 4

System.FilePath, Request for comments
by Neil Mitchell 02 Jul '06

02 Jul '06

Hi, I have written a System.FilePath module in part based on the one in Yhc, and in part based on the one in Cabal (thanks to Lemmih). The aim is to try and get this module into the base package, as FilePath's are something many programs use, but its all too easy to hack up a little function that gets it right most of the time on most platforms, and there lies a source of bugs. This module is Posix (Linux) and Windows capable - just import System.FilePath and it will pick the right one. Of course, if you demand Windows paths on all OS's, then System.FilePath.Windows will give you that (same with Posix). Written in Haskell 98 + Heirarchical Modules. Haddock: http://www-users.cs.york.ac.uk/~ndm/projects/filepath/System-FilePath.html Darcs: darcs get http://www.cs.york.ac.uk/fp/darcs/filepath Source: http://www.cs.york.ac.uk/fp/darcs/filepath/System/FilePath.hs Homepage: http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php Tests: http://www.cs.york.ac.uk/fp/darcs/filepath/Tests.hs If you go to the haddock page there are a few little examples at the top of the file. If anyone could make any comments on the interface, the semantics of the operations (look at the Tests file if you don't want to go prodding the code), missing features etc. that would be very handy. The interface is not yet stable as a warning to those who choose to use it (although I hope its close - that depends on your comments!) Thanks Neil PS. Thanks to Marc Webber for code contributions, shapr for suggestions and a few others.

4 6

Re: ANNOUNCE: HNOP 0.1
by Simon Marlow 01 Jul '06

01 Jul '06

My congratulations to the development team; this is an important contribution to the community. You might want to use {-# OPTIONS_GHC #-} rather than {-# OPTIONS #-}, unless compatibility with older versions of GHC is a goal. Still, the pragma only turns on warnings, so it's harmless. Ashley Yakeley wrote: > One interesting line of development would be to spin off the core > functionality into a separate library, to provide no-op services to > other Haskell applications. I'm thinking something like this: > > noop :: IO () -- generalise to other Monads? Only IO makes sense really, since by definition every non-IO expression does nothing, so the only interesting way to do nothing is in the IO monad. I imagine this interface would be relatively stable. I'm not sure at this stage where in the module hierarchy we should place it, though. Cheers, Simon

5 4

Re: ANNOUNCE: HNOP 0.1
by Ashley Yakeley 01 Jul '06

01 Jul '06

> Now we just need the Godot version, in which nothing happens twice. You may have to wait for that. -- Ashley Yakeley Seattle WA

2 1

Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
by Robert Dockins 30 Jun '06

30 Jun '06

[moved to cafe] On Jun 30, 2006, at 4:01 AM, Ashley Yakeley wrote: > In article > <252C89C12FCAD84BA018CAD5268682FD0190C955(a)GBLONXMB02.corp.amvescap.net > >, > "Bayley, Alistair" <Alistair_Bayley(a)invescoperpetual.co.uk> wrote: > >> Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal >> Setup.hs? Would it be much trouble to add them? > > Bear in mind HNOP compiles just to an executable file, so it doesn't > really have a Haskell API. > > One interesting line of development would be to spin off the core > functionality into a separate library, to provide no-op services to > other Haskell applications. I'm sorry; I know this is a serious discussion (either that or everyone involved in this discussion has a more subtle sense of humor than I), but this sentence made me laugh out loud... :-) "no-op services"? That's just great! > I'm thinking something like this: > > noop :: IO () -- generalise to other Monads? > > This would actually not be too hard to write, given my existing work, > and then of course the executable would simply be a thin wrapper. > > -- > Ashley Yakeley > Seattle WA Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 1