March 2010 - Haskell-Cafe

PseudoTerminals and Handles (again)
by Mathijs Kwik 10 Mar '10

10 Mar '10

Hi All, A few days ago, I got started with the code found on this blogpost: http://www.serpentine.com/blog/2008/09/30/unix-hacking-in-haskell-better-ps… On my system, I found that using pseudoterminals as handles did not work. Reading output and writing input works fine, it's just that finding "the end of the stream" seems to break. This means that I can read all output up to the last character outputted by the other process, but the string doesn't end there. Instead it's throwing: fdReadBuf: hardware fault (Input/output error) Using normal pipes (no pty), this does work as expected. My guess is that I should somehow setup the fd or the pty a little more before starting the child process. Set them to nonblock/block, read/write mode, setTerminalAttribute, stuff like that. And maybe it matters when to change settings (before forking / after forking / in the child), or to change the master or the child... I don't know very much about this stuff but since the rest seems to work fine it just seems to be a problem with how the child announces it's finished writing to the fd. Is there anyone who got this to work somehow? Or is there a way to somehow trick hGetContents and friends to just treat the "hardware fault" as EOF? Thanks Mathijs PS: I'm using ghc 6.12.1 on x86_64 (ubuntu) by the way

1 0

Re: [Haskell-cafe] Re: more thoughts on "Finally tagless"
by Bruno Oliveira 10 Mar '10

10 Mar '10

Hi Oleg, (cc'ed the haskell-cafe as it may be of interest to other readers) On Tue, 9 Mar 2010 oleg(a)okmij.org wrote: > > Hi, Bruno! > > Of course I know the EMGM paper and approach -- we discuss it > at great length in the paper we are both editing, don't we? What I had > in mind about tagless final is different from EMGM, without the mediation > by an isomorphism. The isomorphism has no role in extensibility there: it is completely orthogonal to this issue. The isomorphism is used for the generic programming part. If we apply the tecnique directly to the expression problem this is what we get: http://www.haskell.org/pipermail/haskell-cafe/2008-July/045028.html > Whether it is more direct or not is in the eye of > the beholder. > > I guess you probably won't be at the Spring School. No I am not going to be there, unfortunatelly :(. > So, I'm > sending you the code that might hopefully clarify what I meant. The > original code was written in Haskell; I am sending you the OCaml > translation. Somehow I thought you might like it better (and also tell > if it translatable to Scala). I must say that my OCaml is not as good as my Haskell or Scala :). However, if I understand the code correctly I don't see where the difference to the code in the link above is. Regarding whether it is translatable to Scala. The answer for your question is answered here: Modular Visitor Components: A Practical Solution to the Expression Families Problem Bruno C. d. S. Oliveira In Sophia Drossopoulou, editor, LNCS 5653, Proceedings of the 23rd European Conference on Object Oriented Programming (ECOOP). June 2009. Link: http://ropas.snu.ac.kr/%7Ebruno/papers/ModularVisitor.pdf > > I was a little bit surprised that you ended up in Korea. That > was quite a big jump and quite a lot of hassle moving, I imagine. On > the other hand, it makes a lot of sense: governments on that side of > the world seem to have real money, and they are intent in investing > them in science, including basic science. How is your Korean? It is worse than my OCaml :). Bruno > Cheers, > Oleg > > (* Tagless Final using dictionary passing *) > > (* Compare with Haskell's ExpSYM *) > class type ['repr] expSYM = object > method lit : int -> 'repr > method neg : 'repr -> 'repr > method add : 'repr -> 'repr -> 'repr > end;; > > (* Constructor functions *) > let lit n = fun ro -> ro#lit n;; > let neg e = fun ro -> ro#neg (e ro);; > let add e1 e2 = fun ro -> ro#add (e1 ro) (e2 ro);; > > (* Unit is for the sake of value restriction *) > (* The term is exactly the same as that in Intro2.hs *) > let tf1 () = add (lit 8) (neg (add (lit 1) (lit 2)));; > > (* We can write interepreters of expSYM *) > (* and evaluate exp in several ways. The code for the interpreters > is quite like the one we have seen already > *) > class eval = object > method lit n = (n:int) > method neg e = - e > method add e1 e2 = e1 + e2 > end;; > > let eval = new eval;; > > let 5 = tf1 () eval;; > > class view = object > method lit n = string_of_int n > method neg e = "(-" ^ e ^ ")" > method add e1 e2 = "(" ^ e1 ^ " + " ^ e2 ^ ")" > end;; > > let view = new view;; > > let "(8 + (-(1 + 2)))" = tf1 () view;; > > (* We can extend our expression adding a new expression form *) > class type ['repr] mulSYM = object > method mul : 'repr -> 'repr -> 'repr > end;; > > let mul e1 e2 = fun ro -> ro#mul (e1 ro) (e2 ro);; > > > (* Extended sample expressions *) > (* Again, the code is the same as before, modulo the occasional () *) > (* Value restriction is indeed annoying ... *) > let tfm1 () = add (lit 7) (neg (mul (lit 1) (lit 2)));; > > let tfm2 () = mul (lit 7) (tf1 ());; > > class evalM = object > inherit eval > method mul e1 e2 = e1 * e2 > end;; > > let evalM = new evalM;; > > class viewM = object > inherit view > method mul e1 e2 = "(" ^ e1 ^ " * " ^ e2 ^ ")" > end;; > > let viewM = new viewM;; > > (* can use the extended evaluator to evaluate old expressions *) > let 5 = tf1 () evalM;; > > (* Of course we can't use the old evaluator to evaluate extended > expressions > let 5 = tfm1 () eval;; > Error: This expression has type eval but an expression was expected of type > < add : 'a -> 'b -> 'c; lit : int -> 'a; mul : 'a -> 'a -> 'd; > neg : 'd -> 'b; .. > > The first object type has no method mul > *) > > let 5 = tfm1 () evalM;; > > let 35 = tfm2 () evalM;; > > let "(7 + (-(1 * 2)))" = tfm1 () viewM;; > > let "(7 * (8 + (-(1 + 2))))" = tfm2 () viewM;; > > (* The expressions are first-class: we can put them into the same list *) > > let tl1 () = [lit 1; tf1 ()];; > > (* and add the extended objects afterwards *) > > let tl2 () = tfm1 () :: tfm2 () :: tl1 ();; > > let [5; 35; 1; 5] = List.map (fun x -> x evalM) (tl2 ());; > > let ["(7 + (-(1 * 2)))"; "(7 * (8 + (-(1 + 2))))"; "1"; "(8 + (-(1 + 2)))"] > = List.map (fun x -> x viewM) (tl2 ());; > > Printf.printf "\nAll done\n";; >

1 0

search Data.Tree.Zipper
by Jian Fan 09 Mar '10

09 Mar '10

Hi, There doesn't seem to be a function to search the tree so I come up with following function: searchTree :: (a -> Bool) -> TreeLoc a -> Maybe (TreeLoc a) searchTree pred rootLoc = if pred (getLabel rootLoc) then Just rootLoc else case firstChild rootLoc of Just loc -> case searchTree pred loc of Just loc -> Just loc Nothing -> case right loc of Just rLoc -> searchTree pred rLoc Nothing -> Nothing Nothing -> Nothing Which feels quite ugly. Any suggestions? Thanks. Jian

4 7

Re: [Haskell-cafe] A few ideas about FRP and arbitrary access in time
by Patai Gergely 09 Mar '10

09 Mar '10

> ...Are hereby presented at: > http://www.ee.bgu.ac.il/~noamle/_downloads/gaccum.pdf > > Comments are more than welcome. > (P.S Thanks to a whole bunch of people at #haskell for educating me about > this, but most notably Conal Elliott) Well, my impression is that trying to unite events and behaviours in this manner is not the solution we're looking for. If you follow the WWRD principle, you have to forget about events as fundamental building blocks, because the concept of event is an abstraction over continuous phenomena. Reality has a trivial solution: throw extreme parallelism at the problem, set an extremely high sampling rate and shamelessly 'recalculate' unchanging parts of the system all the time (which is exactly why you don't want to use Yampa or Elerea for GUI programming: they are pull-based, so they'll keep the CPU churning even in the absence of events; note also that both solve the problem of unlimited access to the past). In this framework, events can only be introduced as high-level abstractions that require much more computational power than what would seem necessary. It is a bit like using a large and complex neural network to perform basic arithmetic. Also, if you think about the applicative, monad etc. type class morphisms, you'll see that what makes sense for behaviours is completely useless for events. For instance, the applicative instance for behaviours (time functions) gives us a neat point-wise function application. However, if you define events as functions that are undefined almost everywhere, point-wise application of two events is only defined at the times where both events yield a value simultaneously. Same for monads: they capture the act of sampling for behaviours, but they can't do much for temporal values that are mostly undefined if interpreted as the reader monad. This suggests that events and behaviours have a different nature. Either only behaviours have a meaningful monad instance, or their meaningful monad instances are different. The unified system you're describing very much reminds me of Lucid Synchrone, if we think of behaviours as signals synchronised to the base clock, while events as signals with a slower clock. It might be interesting to think about how clock calculus interacts with the type class instances. However, that still doesn't say anything about the fact that the set of operations meaningful for behaviours and events are different, with only some overlap. Gergely -- http://www.fastmail.fm - Does exactly what it says on the tin

10 12

Type variables
by Giuseppe Maggiore 09 Mar '10

09 Mar '10

Hi everyone, this is my first post: I am a ph.d. student from Italy who is learning the wonderful world of Haskell :) I have encountered a problem and I cannot find a way to get past it (or even to begin to understand it). I wish to define a simple type class that defines how to convert a type function into its argument (like going from a dumb constructor like data T a = T a into a itself): class Convert rec where convert :: rec a -> a now when I try to use the conversion operator class (CNum n, HasField n (a -> (b,rec a)) l, Convert rec) => HasMethod n l a b rec where (..!) :: l -> n -> (a -> (b,a)) instance (CNum n, HasField n (a -> (b,rec a)) l, Convert rec) => HasMethod n l a b rec where l ..! n = let m = l .! n in (\x -> let (y,v) = m x in (y,convert v)) in what looks to me as a straightforward use, the compiler complains that : *References> :load Main.hs [1 of 5] Compiling Records ( Records.hs, interpreted ) [2 of 5] Compiling References ( References.hs, interpreted ) [3 of 5] Compiling Methods ( Methods.hs, interpreted ) Methods.hs:25:14: Could not deduce (HasField n (a -> (b, rec a)) l) from the context (HasMethod n l a b rec1, CNum n, HasField n (a -> (b, rec1 a)) l, Convert rec1) arising from a use of `.!' at Methods.hs:25:14-19 Possible fix: add (HasField n (a -> (b, rec a)) l) to the context of the instance declaration or add an instance declaration for (HasField n (a -> (b, rec a)) l) In the expression: l .! n In the definition of `m': m = l .! n In the expression: let m = l .! n in (\ x -> let (y, v) = ... in (y, convert v)) Failed, modules loaded: References, Records. *References> I apologize for what might look like a huge dumping of code, but I have no idea what might have caused this to further refine the code or to write a more focused example...

2 2

Re: [Haskell-cafe] Re: more thoughts on "Finally tagless"
by Bruno Oliveira 09 Mar '10

09 Mar '10

Hi Oleg, On 9 Mar 2010, at 17:52, oleg(a)okmij.org wrote: > > Stephen Tetley wrote: >> The finally tagless style is an implementation of the TypeCase >> pattern >> (Bruno C. d. S. Oliveira and Jeremy Gibbons): >> >> http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/typecase.pdf > > The finally tagless style is slightly more general. > > The TypeCase paper emphasizes that TypeCase is a pattern to define a > _closed_ type-indexed function -- the indexed family is fixed but the > collection of functions is extensible. This is in contrast to type > classes, where the collection of functions is fixed (by the class > declaration) but the indexed family is extensible (more type class > instances can be defined at any time). > > The tagless final approach permits the definition of an extensible > family of open type-indexed functions. For example, we can define a > `data type' of expressions and extend it at any time with more > expression forms *and* more processing functions (e.g., a new way to > print or compile an expression). With the tagless final approach, we > have the extensibility in both dimensions. > It is true that "Typecase" is aimed at closed type-indexed functions, although in Section 4.2 I note, in passing, that you can achieve extensibility too for the *explicit* representations variation of the typecase pattern (which is the same that is used by tagless final): "The smart datatype solution in this section is fully closed to extension. That is, in order to add another case in the formatting list, such as a constructor Chr that handles characters, we would need to modify the GADT itself. On the other hand, the solution in the previous section using the explicit version of the design pattern allows some form of extensibility. Adding a new case for printf that handles characters corresponds to adding a new function, which could even be in a different module." Fortunately, there is a whole paper devoted to the issue of extensibility for an application of the typecase pattern using *explict* representations: Extensible and Modular Generics for the Masses Bruno C. d. S. Oliveira, Ralf Hinze and Andres Loeh In Henrik Nilsson, editor, Trends in Functional Programming (TFP). Link: http://ropas.snu.ac.kr/%7Ebruno/papers/ExtensibleGM.pdf And the relation to the expression problem is pointed out there. Perhaps you'd like to have a look at the paper if you haven't seen it already. Bruno

1 0

Re: more thoughts on "Finally tagless"
by oleg＠okmij.org 09 Mar '10

09 Mar '10

Stephen Tetley wrote: > The finally tagless style is an implementation of the TypeCase pattern > (Bruno C. d. S. Oliveira and Jeremy Gibbons): > > http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/typecase.pdf The finally tagless style is slightly more general. The TypeCase paper emphasizes that TypeCase is a pattern to define a _closed_ type-indexed function -- the indexed family is fixed but the collection of functions is extensible. This is in contrast to type classes, where the collection of functions is fixed (by the class declaration) but the indexed family is extensible (more type class instances can be defined at any time). The tagless final approach permits the definition of an extensible family of open type-indexed functions. For example, we can define a `data type' of expressions and extend it at any time with more expression forms *and* more processing functions (e.g., a new way to print or compile an expression). With the tagless final approach, we have the extensibility in both dimensions. I'll be talking about this extensibility at some length in two weeks, at the Spring School on Generic and Indexed Programming.

1 0

Real-time garbage collection for Haskell
by Luke Palmer 09 Mar '10

09 Mar '10

I have seen some proposals around here for SoC projects and other things to try to improve the latency of GHC's garbage collector. I'm currently developing a game in Haskell, and even 100ms pauses are unacceptable for a real-time game. I'm calling out to people who have seen or made such proposals, because I would be willing to contribute funding and/or mentor a project that would contribute to this goal. Also any ideas for reducing this latency in other ways would be very appreciated. Thanks, Luke

23 49

file descriptors and handles
by Mathijs Kwik 08 Mar '10

08 Mar '10

Hi all, Today I had a look at chapter 20 of RWH. The extended example (stripped down HSH) in the end is great. I think I understand it, but I have some questions left: the master process closes the client-sided FD's. it uses fdToHandle for the other sides of the pipe to get a handle to stdIn and stdOut on the client process. it writes to the stdIn handle and closes it afterwards. - doesn't it need to close the fd as well? the stdOut handle gets used when reading the command output (using hGetContents) - doesn't the handle need to get closed? or will this happen automatically if hGetContents finds EOF ? - and also here, shouldn't the fd get closed? More general: what happens when closing a handle when there's still output left? Will reading further output throw an exception or just think it's EOF? And what happens when closing the underlying FD? will the handle "break"? or will it close automatically? Thanks for any help Mathijs

2 1

ptys and hGetContent problem
by Mathijs Kwik 08 Mar '10

08 Mar '10

Hi all, I found this blogpost from Bryan O'Sullivan http://www.serpentine.com/blog/2008/09/30/unix-hacking-in-haskell-better-ps… and I wanted to try it out. Before moving to an interactive command (which needs pty), I just did a small test for "ls -l /" to see if it worked. I got it to compile, but when running, it throws an exception when reaching the end of the output (in this case because I evaluate the length to force reading all). Main: /dev/ptmx: hGetContents: hardware fault (Input/output error) Please have a look at the hpaste to see what I did: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=23343 What's wrong? :) My guess is that hGetContents doesn't receive a nice EOF when the process exits (ls doesn't stay around waiting for input), but I have no idea on how to fix this. And further... If I do want to use an interactive program which needs input, how do I send ctrl-d or ctrl-c? tail -f needs ctrl-c (or I need to kill the process) Thanks for any help Mathijs PS: I know about libexpect, it's not useful for what I wanna do (multiple processes, having 'answers' from 1 be used to decide what to input the other, without ending the 'answer' process)

4 5