- Haskell-Cafe - Haskell.org

haskell and fuse
by David Roundy 30 Aug '05

30 Aug '05

Hi all, I worked for a bit while I was on vacation on a haskell interface to libfuse, which I thought some of you might find interesting. It is VERY much a halted-work-in-progress, as I didn't get very far, and don't have time to continue work on it. You can get what there is with darcs get http://abridgegame.org/repos/fuse_example or browse at http://abridgegame.org/cgi-bin/darcs.cgi/fuse_example It's basically an attempt at combining a nice DarcsIO-style filesystem interface on the haskell side (called FuseIO) with an interface to libfuse (which is a library for creating filesystems from user space on linux). The main file is (quite confusingly) called hello.hs, and you can see that it basically just imports one function from FuseIO and one from Fuse. It tries to do the equivalent of `mount --bind dir1 dir2`, execpt that there's no support for writing to files, or in general modifying the mounted filesystem. I had been thinking (although I now have no time for this) about the possibility of implementing a caching distributed network filesystem which had git as its backend. Of course, I'd start with just a local filesystem with git as the backend, which would be a bit stupid, although it'd have the (very minor) advantage that identical files would be effectively hard-linked as far as space use goes. The FuseIO module itself might be rather interesting for other projects (e.g. darcs), or even (one could imagine) as an alternative to the haskell standard IO libraries for filesystem access, since it'd allow you to write a function that is guaranteed by the typesystem to do nothing but read from a filesystem, and it'd also allow writing polymorphic filesystem access/modification code that could be applied outside the IO monad (e.g. to Slurpies). It would also allow one to use treat network objects (e.g. http or ftp) as filesystems. The Fuse side of things uses hsffig to generate an interface to libfuse, and then translates the libfuse interface into FuseIO commands, so implementing a new sort of filesystem (e.g. sshfs) would require modifying neither FuseIO nor Fuse, but instead just implementing a new FS and plugging it in. But the Fuse interface is very limited, as is the FuseIO interface (which doesn't support, for example, file permissions), so to make a real useful filesystem would require considerable extension of both modules. -- David Roundy http://www.darcs.net

2 1

Hugs - evaluation statistics
by Dusan Kolar 29 Aug '05

29 Aug '05

Hello, Even if I know number of reductions should not be used to anything important I'm quite confused with values I get. Is garbage collection somehow affecting the number of reductions? I have always thought not, but... ;-) Thx, Dusan

3 4

generics question, logical variables
by Frederik Eaton 29 Aug '05

29 Aug '05

Hi all, I'm trying to write something like a generic fmap, or a generic natural transformation. The application is this. I have a typed logical variable library which produces arbitrary terms with values of type "Var a", which are references to a value of type "Maybe a", and I want to write a "solve" function which replaces these values with instantiated versions of type "Id a" where newtype Id a = Id a . Furthermore I want this to be reflected in the type of the generic term: solve :: Pred (t Var) -> [t Id] so if I have a type like data Entry k = Entry (k String) (k Int) then I can write some constraint equation with values of type "Entry Var", and get back values of type "Entry Id" - in other words, objects where the unknowns are statically guaranteed to have been filled in. I looked at the generics library. I may be mistaken, but it seems that it doesn't have what I need to do this. The problem isn't the mapping, it's creating a new type which is parameterized by another type. The only options for creating new types are variations on fromConstr :: Data a => Constr -> a but what is needed is something like fromConstr1 :: Data1 a => Constr1 -> a b With something like that it should be possible to define: gmapT1 :: (forall b . Data1 b => b l -> b m) -> a l -> a m Does this make sense? Here I would be treating all instances of Data as possibly degenerate instances of Data1 (which just might not depend on the type variable). If it seems like a good idea, I would be interested in helping out with the implementation. Frederik -- http://ofb.net/~frederik/

1 0

Data.Graph or Data.Graph.Inductive?
by Kimberley Burchett 29 Aug '05

29 Aug '05

Is there a general agreement as to whether one should prefer Data.Graph or Data.Graph.Inductive? I've read both of the papers, and while I find the Inductive view very compelling, it seems like Erwig was more concerned with elegance than performance, while King&Launchbury seem to value performance more highly. Any guidance as to which package people actually use would be appreciated. Kim

1 0

Weak hashtable memoization code?
by David Roundy 28 Aug '05

28 Aug '05

Hi all, Does anyone have a nice bit of example code to implement memoization using weak pointers and hash tables? It would be nice to have a pre-packaged module that I could just use, which has already been tested. The contents of Data.WeakPtr seem a bit lower-level than I'd rather work with. -- David Roundy http://www.darcs.net

2 1

Comtrol.Monad.when
by Juan Carlos Arevalo Baeza 28 Aug '05

28 Aug '05

Any reason why "Control.Monad.when :: Monad <Control.Monad.html#t%3AMonad> m => Bool <Data.Bool.html#t%3ABool> -> m () -> m ()" doesn't have type "Monad <Control.Monad.html#t%3AMonad> m => Bool <Data.Bool.html#t%3ABool> -> m a -> m ()" instead? Just seems a bit of a waste to have the restriction without need. I find myself needing to add the extra spurious "return ()" at the end more often than not. I made an alternate "when_" for my own use, but... JCAB

1 0

RE: [Haskell-cafe] How to use STArray?
by Bayley, Alistair 27 Aug '05

27 Aug '05

> From: Udo Stenzel [mailto:u.stenzel@web.de] > > You messed the argument order to readArray up. Yes, that won't help :-) > Even with that repaired, > you'll need a type signature somewhere to help ghc resolve the > overloading of newArray and readArray, which is surprisingly > tricky due > to the "s" that must not escape. This works: > > compute :: Int -> Int > compute n = runST ( do > arr <- newArray (-1, 1) n :: ST s (STArray s Int Int) > readArray arr 1 > ) Thanks. This is what I needed. The thing that worked best for me was to wrap newArray (and newArrayList) with functions that I could give signatures to. I was hoping to keep the program as signature-free as possible, to avoid committing heavily to particular implementations. e.g. makeArray :: Int -> Int -> a -> ST s (STArray s Int a) makeArray lower upper val = newArray (-lower, upper) val makeListArray :: Int -> Int -> [a] -> ST s (STArray s Int a) makeListArray len lst = newListArray (1, len) lst Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 2

RE: [Haskell-cafe] How to use STArray?
by Bayley, Alistair 26 Aug '05

26 Aug '05

> From: Ketil Malde [mailto:ketil+haskell@ii.uib.no] > > Greg Buchholz <haskell(a)sleepingsquirrel.org> writes: > > > Diff arrays have an immutable interface, but rely on > internal updates in > > place to provide fast functional update operator //. > > While a cool concept, ISTR that somebody benchmarked these some time > ago, and found the performance to be fairly poor in practice. Has > that changed lately, or am I just misremembering? DiffArray certainly improved the execution time of my program (the execution time was dominated by array updates, so no surprise there). I should have said that I'm also concerned with space usage; I'd like to allocate the arrays at the beginning and expect that to be all of the memory required, so that's another reason to be interested in mutable arrays. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

RE: [Haskell-cafe] How lazy can "peek" be?
by Bayley, Alistair 26 Aug '05

26 Aug '05

> From: Juan Carlos Arevalo Baeza > > If I don't want to pay for that cost, then I have > to convert the code as in: > > func p = > b <- peekByteOff p 4 > case b of > B1 -> doSomething > B2 -> do { a <- peekByteOff p 0; doSomethingElse a } > B3 -> do { a <- peekByteOff p 0; doAnotherThing a } > > Repetition, repetition, repetition. This does get tedious. Would this work? > func p = do > let get_a = peekByteOff p 0 > b <- peekByteOff p 4 > case b of > B1 -> doSomething > B2 -> do a <- get_a; doSomethingElse a > B3 -> do a <- get_a; doAnotherThing a Or, with marginally less duplication: > B2 -> get_a >>= doSomethingElse > B3 -> get_a >>= doAnotherThing Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

How lazy can "peek" be?
by Juan Carlos Arevalo Baeza 25 Aug '05

25 Aug '05

Hi! One of the nice things of laziness is that it allows us to express things concisely. For instance: func a b = let ta = transmogrify a in case b of B1 -> doSomething B2 -> doSomethingElse ta B3 -> doAnotherThing ta It is clear why having this let-expression is a good thing. We can "transmogrify a" only once, and then use the "transmogrified a" only when (if) needed. In this case, one branch of the case expression doesn't need it, in which case we've effectively paid nothing for it, no matter how complex and time/resource-consuming "transmogrify" is. So far, so good. Now, I need to interoperate with external code using FFI. I have a function that gets called from outside, and gets its parameters as a pointer to a structure, so: func p = do a <- peekByteOff p 0 b <- peekByteOff p 4 case b of B1 -> doSomething B2 -> doSomethingElse a B3 -> doAnotherThing a Now I see myself with a little dilemma. This code looks a lot like the first version, where instead of "transmogrifying", we just read the value from the structure through the use of the pointer. Reading the value from memory can't be very time consuming, but it has to cost something. If I don't want to pay for that cost, then I have to convert the code as in: func p = b <- peekByteOff p 4 case b of B1 -> doSomething B2 -> do { a <- peekByteOff p 0; doSomethingElse a } B3 -> do { a <- peekByteOff p 0; doAnotherThing a } Repetition, repetition, repetition. This does get tedious. Especially when the case expression has many branches, and there are many variables in the structure that might or might not be needed. So you see my dilemma. It's _very_ tempting to do something like: func p = do let a = unsafePerformIO $ peekByteOff p 0 b <- peekByteOff p 4 case b of B1 -> doSomething B2 -> doSomethingElse a B3 -> doAnotherThing a I mean... the contents of "p" are never going to be modified, so this "feels" right on some level. But we're effectively breaking the pureness of the language. I mean... this function could be called twice with the same _pointer_ but different data stores in the structure, which can (and maybe will) cause problems depending on how evaluation proceeds. Is there a way to handle this nicely? I recently read about the Clean language. It seems like it allows (and relies) in an extension to the type system, that allows the program to specify uniqueness of values, so that two pointers values might be represented using the same bits, but they'd still be considered distinct values. But no such thing in Haskell. Maybe a good thing... trying to understand the whole explanation of uniqueness in Clean made my head spin. But still... Is it known what GHC, for instance, will do to this code when optimizing? Might it just do the right thing? Probably the C optimizer would take care of it. It feels to me that's my only hope. But it'd be great if the "haskell" part of the compiler could take care of it natively. This is something that I've been thinking about. I mean... the IO monad does seem to impose too much sometimes. Any IO action always is assumed to modify the "external world" (affect the execution of the actions that come after it), whether it does or not: do peekByteOff p 0 -- totally useless, but it needs to be performed anyway before "returning" return () do a <- peekByteOff p 0 b <- peekByteOff p 4 -- could be done before "a" Somehow, it feels like it'd be a good thing to be able to limit the scope of IO actions. Going too far would complicate it enormously: do a <- readFile "file" b <- peekByteOff p 4 -- could be done in any order, really, but how would you express it... maybe "domains of influence", like "filesystem" and "memory"... not very clear. do a <- peekByteOff p1 0 pokeByteOff p2 0 1234 -- could be done in any order, as long as p1 and p2 don't alias each other (yuck!) So I wouldn't want to go that far... yet :). A global thing might be an improvement. I'm aware it wouldn't be a monad anymore, but could it be something else? I hope this is all pointless :-). JCAB

1 0