- Haskell-Cafe - Haskell.org

Num instance for Lazy ByteStrings (was: NumLazyByteString Package License)
by Thomas DuBuisson 10 Mar '10

10 Mar '10

Tristan and other interested parties on the Cafe, Answering your question first, Tristan: I was going to use BSD3 (if it isn't already) for the NumLazyByteString. For the cafe too: A while ago I made a Num instance for LPS; it is currently on my code.haskell.org account. Notice this isn't on Hackage yet and the semantics will be different soon. Most notably I want to ensure divide and anything else implemented through 'asInteger' and 'asInteger2' results in a bytestring of length equal to the largest of the operands. If that isn't clear then let me be very explicit. NumLazyByteString intentionally allows overflow! If you want operations (mod 2^40) then you need only work with bytestrings of length 5 bytes and the operations will result in 5 byte ByteString. This is already true for basic operations (bit operations, +, -, *) but is not yet done for quot, rem, quotRem, divMod, mod, /, and other you can see leverage Integer instead of using custom code. Any desire for non-overflowing operations (basically, re-expressing Integer as LazyByteString) would have to be done as an newtype with a Num instance that grows the bytestring to the necessary level, preventing overflow prior to calling NumLazyByteString. Finally, I intend for numerous operations to be lazy. If you add two infinite bytestrings you should be able to get the result of that operation (modulo some finite value) using NumLazyByteString. This is obviously not true for those operations leveraging Integer. Any comments or requests on the future of this Library are welcome - I'll probably get around to finishing it and putting it on Hackage in a couple weeks. Cheers, Thomas On Sun, Mar 7, 2010 at 9:24 PM, Tristan Ravitch <travitch(a)cs.wisc.edu> wrote: > I found myself adding Bits and Num instances for ByteStrings when I > found your implementation (which is much better than mine was shaping > up to be). Do you have any particular license in mind for it? > > I used it in an implementation of the Delta Debugging algorithm > (http://www.st.cs.uni-saarland.de/dd/) which I was thinking I would > like to release, and wanted to make sure the licensing could work out > properly. > > Thanks, > -- > Tristan Ravitch > travitch(a)cs.wisc.edu > http://pages.cs.wisc.edu/~travitch > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkuUiiUACgkQJklRJNuIcWSxmACfVblD+gR/Fv57teNTArSfXhHg > NtsAnRqBvinNesMk3mxMxDERw5MBn9jZ > =Jm4O > -----END PGP SIGNATURE----- > >

5 5

Re: First time haskell - parse error!
by John Lato 10 Mar '10

10 Mar '10

> From: Ketil Malde <ketil(a)malde.org> > > "S. Doaitse Swierstra" <doaitse(a)cs.uu.nl> writes: > >>> then (s1 ++ s2 ++ s3 ++ s4) where >>> s1 = "Golds " >>> s2 = show (gold s g) >>> s3 = ", Silvers " >>> s4 = show (silver s g) > >> If you want to keep the definitions local to the expression you should write > > ..but I think it is better style to avoid this kind of one-off named > values. I much prefer: > > then "Golds "++show (gold s g)++... > > For some reason, this is a style isse that doesn't get much attention, > at least not in the non-functional language tradition, where temporary > variables are scattered all over. So instead of doing: > > let ns y = not (isSpace y) > f x = takeWhile ns x > in map f > > We can use anonymous functions in place of the uninformatively named > ones: > > map (\x -> takeWhile (\y -> not (isSpace y)) x) > > and use partial application toward point-free-ness: > > map (takeWhile (not . isSpace)) I agree, and also tend to this style. Although I sometimes use one-off named values to avoid line wraps. For the particular task of combining strings like this, how about using Text.Printf.printf? then printf "Golds %s, Silvers %s" (show (gold s g)) (show (silver s g)) It can be a little hard to understand the type at first, but IMHO it works as expected. Cheers, John

1 0

more thoughts on "Finally tagless"
by Günther Schmidt 10 Mar '10

10 Mar '10

Hi all, and Oleg et al in particular. Yeah, subject "Finally Tagless" again, sorry, I'm just not done with it yet. In Olegs haskell implementation he is using classes mainly to model the syntax and instances to use for evaluators / compilers to allow multiple interpretations. I wonder if it'd be possible to do the same without classes using data types instead? Something similar to what Luke Palmer has done here: http://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-… Günther

6 8

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