October 2007 - Haskell-Cafe

Hugs, dotnet, C#...
by Peter Verswyvelen 11 Oct '07

11 Oct '07

In the (Win)Hugs documentation, I found "Only the ccall, stdcall and *dotnet *calling conventions are supported. All others are flagged as errors." However, I fail to find any more information on how to invoke dotnet methods. This might be really handy for me, as I'm very familiar with the dotnet framework. For example, yesterday I rewrote and extended a program that I wanted to develop in Haskell in just 3 hours using dotnet, while I spend weeks trying do this in Haskell. Of course, I'm a Haskell newbie and a dotnet expert, so this is not a fair comparison. However, I got a strange feeling, which I want to share with you :) First of all, it was a *horrible* experience to program C# again; I needed to type at least 3 times the amount of code, much of which was boilerplate code, and the code is not elegant. Haskell really changed my point of view on this; before I knew Haskell, I found C# (I'm talking C# 3.0 here) a really neat and nice language. On the other hand, the great Visual Studio IDE and Resharper addin made it at least 3 times faster to type, navigate, refactor, and debug the code... Somehow, I get things done really really really fast in C#, albeit in an "ugly" way. Once again, I just wish Haskell had such an IDE... And yes, I know of the existance of Visual Haskell, EclipseFP, Haskell Mode for Emacs (which I'm using), VIM, YI, but still, these do not compare with the experience I have when using Visual Studio/Resharper (or Eclipse or IntelliJ/IDEA for Java). But that might just be me of course... A slightly frustrated Peter ;-) BTW: I don't want to bring up the IDE discussion again, no really ;-)

4 6

symbol type?
by Michael Vanier 11 Oct '07

11 Oct '07

Is there an implementation of a symbol type in Haskell i.e. a string which has a constant-time comparison operation? Mike

8 11

Re: [Haskell] Abstract syntax representation
by Neil Mitchell 11 Oct '07

11 Oct '07

Hi In future questions like this are usually best directed to haskell-cafe, with haskell being left for annoucements. The standard "full haskell" representation is in Template Haskell (http://haskell.org/ghc/docs/latest/html/libraries/template-haskell/Language…) If you want to work on a reduced language then I recommend Yhc.Core (http://www-users.cs.york.ac.uk/~ndm/yhc/ - there is a link to the Yhc.Core paper on that page). Thanks Neil

1 0

ANNOUNCE: metaplug
by mad.one＠gmail.com 10 Oct '07

10 Oct '07

Hi, Recently I just decided to finish up and publish my library, metaplug: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/metaplug What is it? It's basically a very tiny GHC API wrapper for programs that want eval and plugin style functionality packaged in a basic library. The need for it spawned out of my GHC API investigations, and looking at it as an easy way to get pluggable apps across GHC releases (hs-plugins is somewhat fragile as it can break basically inbetween any release,) and with the oh-so-close ghc 6.8 release, I needed something for things like my IRC bot (which does hot-code swapping) that wanted plugin style facilities without the hassle of using the API explicitly or having dependencies on soon to break packages like hs-plugins. Right now, there is no haddock documentation (I'll add it and upload a new version when I have time) but it's simple enough to figure out how to use from the source code. Here's a quickie review: Metaplug: top level module, you only need import this Metaplug.Eval: exports one function, eval, which, well, does what it sounds like Metaplug.Initialize: exports two functions, initSession and initSession' which initialize a metaplug session. initSession' is for the case where you want to provide your own very customized DynFlags to GHC.newSession Metaplug.Loader: provides two functions, loadFiles and compileCall which load files into a session and compiles a dynamic to a function you can call. Metaplug.Types: simply provides the SessionMode and MetaSession types Metaplug.Packages: provides a very simple interface to query the package database for info, please note this has NOT been tested with Cabal 1.2.0 There're some example applications in the tests/ directory which show off how to use most of this stuff in a very simple manner. Check the README. There is one limitation to this, however. compileCall expects to compile a dynamic via GHC.dynCompileExpr; what this means is your resource must be monomorphic (for Typeable to work.) As of right now, the easiest way I can see to get around this is to simply define a datatype like such: data Plugin { rsrc :: ... -- your type here } deriving Typeable And then have the symbol you want to compile could be for example, plugin = Plugin { rsrc = dynmain } The application in tests/dynst/ provides a good example of this. If anybody knows a way around this or an easier way to approach it, I appreciate all feedback (unsafeCoerce# is an option but there's not a version of compileCall to support this as of right now. I might add it if it seems needed.) Any feedback appreciated. Thanks, Austin

1 0

help!!!! install HaskellDirect
by Sulema Rocha Betancur 09 Oct '07

09 Oct '07

Hello :) Someone knows like installing HDirect 1,2 in Windows XP with cygwin? , and that version of GHC is the one that uses???.Thank you for its collaboration!!!!!!!! Sule ;) _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx

1 0

help!!!! install HakellDirect
by Sulema Rocha Betancur 09 Oct '07

09 Oct '07

Hello :) Someone knows like installing HDirect 1,2 in Windows XP with cygwin? , and that version of GHC is the one that uses???.Thank you for its collaboration!!!!!!!! Sule ;) _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

1 0

Manual constructor specialization
by Johan Tibell 09 Oct '07

09 Oct '07

I have a rope data type with the invariant that one of its data constructors can never appear as a leaf. module Data.Rope where import Data.Word (Word8) data Rope = Empty | Leaf | Node !Rope !Rope index :: Rope -> Int -> Word8 index Empty _ = error "empty" index Leaf _ = error "leaf" index (Node l r) n = index' l n where index' Leaf _ = error "leaf" index' (Node l r) n = index' l n I removed some of the actual details (Leafs have a ByteString member and Nodes have a length and a depth field). The point is that Empty can only appear at the top by construction (i.e. it's not possible to construct a rope that breaks this invariant using the exported API). If I understand compilation of case statements correctly they will compile into some if like construct that checks the constructor tag. This means that I would like that once we have established that the constructor is not Empty we could use a specialized function to traverse the tree without checking for Empty on each iteration. The above doesn't achieve this as GHC inserts an automatic error branch for Empty in index'. Perhaps one solution is to reorder the cases and remove index'? -- Johan

6 6

Re: [Haskell-cafe] ANNOUNCE: binary 0.4: high performance, pure binary parsing and serialisation
by Don Stewart 09 Oct '07

09 Oct '07

ketil: > Don Stewart <dons(a)galois.com> writes: > > > The main thing is porting to ghc 6.8 -- which means the new (*faster*) > > lazy bytestring representation, and the smp parallel quickcheck driver > > for the testsuite (it'll use N cores, watch the jobs migrate around). > > Binary 0.4 seems to require bytestring 0.9, the library formerly known > as fps. I just want to mention it, as most network resources (as > found by Google) only have discoverd fps 0.7, which is not going to > work. > > (Oh, and yes, it's at darcs.haskell.org/bytestring/ ) > > It'd be nice - since I know you're at it anyway :-) - if hackage/cabal > would have some support for backwards compatibility. I know GHC 6.8 > is the thing to get, but some of us still install what comes with our > distribution, so I hope 6.6.1 still will be supported. > Normally this is farily easy to do, with cabal configurations. (See bytestring's .cabal file for example). However, the binary internals changed in such a way that it wasn't worth preserving backwards buildability. Instead, you should use binary 0.3 with ghc 6.6 libs A released version of bytestring 0.9 will be on hackage shortly. -- Don

2 2

Haskell FFI and finalizers
by Maxime Henrion 09 Oct '07

09 Oct '07

Hello all, I have recently developed a small set of bindings for a C library, and encountered a problem that I think could be interesting to others. My problem was that the C function I was writing bindings to expects to be passed a FILE *. So, I had basically two possibles routes to take: 1) Mimic the C API and have the haskell function take a Handle. Unfortunately, I can see no way to go from a Handle to a Ptr CFile, at least no portable way, so I discarded this option. 2) Deviate from the C API slightly and have the haskell function take a FilePath instead of a Handle. This is the option I chose, and this is where things get interesting. In order to pass a Ptr CFile (FILE *) to the C function, I had to call fopen() myself, using a usual FFI binding: foreign import ccall unsafe "fopen" fopen :: CString -> CString -> IO (Ptr CFile) That's the easy part. Now my problem was that I had to find a way to automatically close this FILE * when it isn't used anymore, in order not to leak FILE structures (and thus fds, etc). A finalizer is typically what I need, but unfortunately, a finalizer has a very strict shape: type FinalizerPtr a = FunPtr (Ptr a -> IO ()) That is, a finalizer can only be a pointer to a foreign function, and the foreign function itself needs a quite specific shape. And then I discovered Foreign.Concurrent, which allows one to associate a plain Haskell IO action to a pointer. The 'Foreign.Concurrent' name is a bit misleading to me; it seems this module is named so because it needs concurrency itself, rather than providing stuff for concurrency. So, in the end, I've got this code: import Foreign import Foreign.C import qualified Foreign.Concurrent as FC ... data PlayerStruct type Player = ForeignPtr PlayerStruct ... foreign import ccall unsafe "dd_newPlayer_file" dd_newPlayer_file :: Ptr CFile -> Ptr ImageStruct -> IO (Ptr PlayerStruct) foreign import ccall unsafe "&dd_destroyPlayer" destroyPlayerFinal :: FunPtr (Ptr PlayerStruct -> IO ()) foreign import ccall unsafe "fopen" fopen :: CString -> CString -> IO (Ptr CFile) foreign import ccall unsafe "fclose" fclose :: Ptr CFile -> IO CInt ... mkFinalizedPlayer :: Ptr PlayerStruct -> IO Player mkFinalizedPlayer = newForeignPtr destroyPlayerFinal newPlayerFile :: FilePath -> Image -> IO Player newPlayerFile path image = do withCString path $ \cpath -> do withCString "rb" $ \cmode -> do file <- throwErrnoIfNull "fopen: " (fopen cpath cmode) withForeignPtr image $ \ptr -> do player <- dd_newPlayer_file file ptr >>= mkFinalizedPlayer FC.addForeignPtrFinalizer player (fclose file >> return ()) return player So I'm adding the "usual" finalizer, and with the help of Foreign.Concurrent, I can add a second free-form one (fclose file >> return ()), in order to close the file I opened at an appropriate time. I'm looking forward hearing about other people's opinions, and wether this is a correct solution to the initial problem or not. I think there is another way to solve this, which is to provide the finalizer still in haskell code, but export the haskell code using FFI, so that I can use it as a plain, normal finalizer. I'm still unsure about this. Cheers, Maxime

6 10

Some lambda identities
by Yitzchak Gale 09 Oct '07

09 Oct '07

While playing with @pl on #haskell, I noticed some weird and surprising lambda identities. For example: let {c = (.); c4 = c c c c} Then we have: c c4 == c c4 c c c c Proof: Repeatedly apply the identity: (*) x (y z) == c x y z More stuff: c c2 == c4, c c3 == c7, but c cn does not appear to be reducible for n>3. c7 c3 == c3 c7 c c c You get a lot more interesting stuff when you throw flip into the mix. The identity (*) is actually a semi-associativity condition that makes the entire lambda calculus into a semi-monoid. Apparently with very interesting structure. Anyone know more about these things? Thanks, Yitz

1 2