August 2009 - Haskell-Cafe

Quickcheck for common typeclass laws
by Job Vranish 14 Aug '09

14 Aug '09

Is there a hackage package that contains quickcheck properties for the laws of common typeclasses? (Functor, Monad, Num, Ord, Eq, Applicative, etc...) so that one could quickly check (har har) that their new instances satisfy the appropriate laws? It would be very nice to have a isValidMonad (undefined :: MyNewMonadType) function. If one does not exist, I may just have to make one. - Job

3 2

Re: [Haskell-cafe] Improving event management in elerea
by Patai Gergely 14 Aug '09

14 Aug '09

> or > > event :: a -> Signal Bool -> (a -> a) -> SignalMonad (Signal a) > event v0 b f = accumIf v0 f =<< return b > > ? That's not a good idea, because it doesn't take time into consideration, so you'd jump a huge amount in every frame. What I had in mind is something like this: ifte :: Signal Bool -> Signal a -> Signal a -> Signal a ifte sc st sf = (\c t f -> if c then t else f) <$> sc <*> st <*> sf And then: playerX <- integral playerX0 ( ifte (lpress &&@ (playerX >@ pure (-fieldW))) (-1) 0 + ifte (rpress &&@ (playerX <@ pure (fieldW-playerW))) (1) 0 ) This won't be perfect, since the paddle can get a bit beyond the edge of the field. This can be prevented by using some kind of clamped integral, for instance, which you can again define in terms of transfer, just like the plain integral. Also, note that mixing bind and return is redundant, since "f =<< return b" is equivalent to "f b". Gergely -- http://www.fastmail.fm - Choose from over 50 domains or use your own

2 1

Cleaner networking API - network-fancy
by Taru Karttunen 14 Aug '09

14 Aug '09

Hello network-fancy offers a cleaner API to networking facilities in Haskell. It supports high-level operations on tcp, udp and unix sockets. I would like some feedback on the API http://hackage.haskell.org/packages/archive/network-fancy/0.1.4/doc/html/Ne… In particular: * Does the type of the server function in dgramServer make sense? or would (packet -> Address -> (packet -> IO ()) -> IO ()) be better? * Does the StringLike class make sense? * Any other suggestions? - Taru Karttunen

6 7

Re: [Haskell-cafe] Improving event management in elerea
by Patai Gergely 14 Aug '09

14 Aug '09

Hello Jean, If I got you right, you basically want to have a signal that changes its value by a predetermined transform function whenever there is an edge detected on a bool signal. In that case, it would be easier to define it in terms of transfer: accumIf :: a -> (a -> a) -> Signal Bool -> SignalMonad (Signal a) accumIf v0 f b = transfer v0 g b where g _dt c x0 = if c then f x0 else x0 event :: a -> Signal Bool -> (a -> a) -> SignalMonad (Signal a) event v0 b f = accumIf v0 f =<< edge b I even factored out the edge functionality. Of course you also have to pass playerX0 to this function as is, without the pure wrapping. Also, your flat function is practically equivalent to (return . pure), why did you define it using transfer? Another thing to note is that you might want to define playerX as an integral of a velocity derived from lpress and rpress, so you wouldn't need to press and release the buttons repeatedly, and the speed would be the same regardless of sampling rate, since integral takes the time step into account. > but I still can't answer my first one (couldn't this function > -or its improvement- be part of the library ?) Sure, anything is possible. Elerea is a new library, and it deliberately exposes only some low-level constructs. In particular transfer, which basically lets you fall back on pure state transformer functions. My idea was that as more and more code is written in it, we can extract recurring patterns and add them to the library. But at the moment it is not clear what the useful patterns are, and I'd rather not start guessing and littering the library with useless combinators in advance. For instance, the accumIf function is a conditional version of stateful, and it might be generally useful. Whether it's the best name, that's another question. Gergely -- http://www.fastmail.fm - The professional email service

2 1

containers and maps
by John Lato 14 Aug '09

14 Aug '09

Hello, The recent discussion regarding One Container Class To Rule Them All got me to thinking about container classes and map functions. ListLike (which is really a pretty nice package, and I would like to see more people use it) provides two map functions, a regular map with type > map :: (item -> item') -> full -> full' and also rigidMap: > rigidMap :: (item -> item) -> full -> full I think the utility of rigidMap is clear for anyone who's tried to solve the container class problem. Anyway, I had the idea of taking both maps out of ListLike entirely, and replace them with this: > class (ListLike full item, ListLike full' item') => Map full item full' item' where > map :: (item -> item') -> full -> full' Wouldn't this be better? I see the following benefits: -instances for polymorphic types like List are trivial -instances for monomorphic types (e.g. ByteString) can use the native map implementation. -Instances for types with class restrictions on the elements (e.g. UVector) can also be written. On the downside, the class context is much longer, but you'd only need to write the whole thing when you're actually using map, and then it'll include the ListLike instance automatically. Obviously this isn't so much one container class to rule them all as it is a set of classes that all work together, but as long as it's sensible that's fine with me. Thoughts? John Lato

3 6

Hack on the Delve core, with Delve and Haskell
by spoon 14 Aug '09

14 Aug '09

Delve is a new programming language intended to bring the benefits of static type checking and functional programming to object-oriented design and development. It is an impure, eager language (Yes I can hear the groans of woe and cries for sanity already!) Currently Delve supports: Higher-order functions/first class functions Anonymous functions Lexical closures First class continuations Tail-call optimization A meta-object model (classes are objects) S-Expression based syntax. Embedded Haskell expressions within Delve. What it doesn't have: Lots and lots! Basically what I have is an de-sugared, untyped core language. An analogy could be made with Haskell core files. I'm going to be working on the type system for next little while (I have a stack of paper and a pen right here!). Once that is implemented we'll see where to go. Please see the TUTORIAL file included in the source for a brief outlook on Delve's syntax, semantics and planned type system. However! If you're looking for a new project, and especially if you are an undergraduate, then I think Delve would be a good choice for these reasons: It's written in a hybrid of Haskell and itself. It's currently undergoing active development (by me and some pals). You're not going to be lonely! It's quite powerful already, without too many lines of code (it's now just about 5.5KLOC - it's no goliath! ) It's a programming language: name a compiler which isn't a cool piece of tech! Ok, maybe you can but still, it's a chance to work on something non-trivial and interesting. Quite honestly, I'm a bit of a fool - I am a math undergrad! So don't you feel foolish about getting involved if you're not a professorial chap! If you feel like it, get involved in the design, and push me the patches :) It does require lots of love though! It was all hacked out rather quickly :) Executables which Delve provides: edc -- The Elgin Delve Compiler The Elgin Delve Compiler currently supports two backends - the first to a bytecode format for execution on edvm, and the second is to a Haskell source code representation of Delve bytecode. This allows Haskell to be embedded within Delve, for the express purpose of extending and building edvm. edc is written in Haskell (GHC). edvm -- The Elgin Delve Virtual Machine The Elgin Delve Virtual Machine executes Delve bytecode files (.dcode format). Since part of the VM is actually driven by Delve bytecode, edvm can be considered a hybrid of Delve and Haskell (again GHC). Delve continues the grand tradition of naming compilers after Scottish Cities (no, Elgin does not have a university). Delve is released under the terms of the GNU GPLv3. For more information on Delve, check my blog at http://killersmurf.blogspot.com/ and the Delve repository at http://github.com/elginer/Delve/ -- John

2 2

Improving MPTC usability when fundeps aren't appropriate?
by Daniel Peebles 13 Aug '09

13 Aug '09

Hi all, I've been playing with multiparameter typeclasses recently and have written a few "uncallable methods" in the process. For example, in class Moo a b where moo :: a -> a the moo function is effectively impossible to call (no amount of type annotations can tell the compiler what you intended b to be there). Some might suggest adding an a -> b functional dependency, but in some cases that is not appropriate, as there are multiple possible instances. Another solution would be to artificially force moo to take a "dummy" b so that the compiler can figure out which instance you meant. That's what I've been doing in the mean time, but wouldn't it be simpler and less hackish to add a some form of "instance annotation", like a type annotation, that would make it possible to specify what instance you wanted when it's ambiguous? I'm not sure what syntax might be appropriate here, but it could also be seen as "opening" a particular instance, so something "open"-like might be good. I don't know whether this has already been discussed much, but I was unable to find anything that seemed relevant (beyond discussing relationships between parametrized modules and typeclasses) but I wanted to know if anyone had any opinion on adding such a feature to (a future revision of) Haskell? I know people are generally reluctant to add new syntax elements to a language, but considering the lack of such a feature and the impossibility of writing such a thing in the language itself, it seems like it'd be useful to add to the language itself. Thanks, Dan

4 4

Space for commentaries on hackage
by Maurício CA 13 Aug '09

13 Aug '09

It would be nice to have a place for anonimous comments below each page of a hackage package, maybe with a cabal option to enable/disable that for a particular package. Authors of packages with few users may want that as a way to get first impressions on their work they would otherwise not get. (At least, I am, so I thought maybe others probably would.) Best, Maurício

4 5

Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
by Gregory Michael Travis 13 Aug '09

13 Aug '09

"John A. De Goes" <john(a)n-brain.net> sed: > Hmmm, bad example. Assume memory instead. That said, reordering/ > parallelization of *certain combinations of* writes/reads to > independent files under whole program analysis is no less safe than > sequential writes/reads. It just "feels" less safe, but the one thing > that will screw both up is interference from outside programs. This reminds me of something I've heard of: the commutative monad. I might have seen the phrase in some presentation by Simon Peyton-Jones. I took it to mean some sort of monad that sequenced computations, but was also capable of reordering them according to rules specified by the implementer of the monad. Thus, you could re-order operations on separate files, because they can't possible interfere with each other. This strikes me as an important idea, something that would allow you to incrementally optimize while keeping safety. For example, let's say you implement a complex distributed system, using a single distributed state monad to manage global state. This would be very slow, since you would no doubt have to have a central node controlling the order of all side-effects. But this node could re-group and re-distributed the side-effects. This would be done by using the type system to carefully separate effects that couldn't interfere. I'm not expressing this as well as I'd like. From the programmer's perspective, though, it could have a nice property: you start with a slow, but trivial state monad. Then you add rules and clauses that indicate when two effects can have their order switched; all the while, the meaning of the program is unchanged. This is not unlike nodes distributed database that have to receive updates from other nodes and figure out how to apply all the updates in a coherent order, or throw an exception if it cannot.

1 0

Improving event management in elerea
by jean legrand 13 Aug '09

13 Aug '09

Hi Haskellers, I've written a new version of the breakout elerea-example where mouse is replaced by LEFT and RIGHT keys http://hpaste.org:80/fastcgi/hpaste.fcgi/view?id=8159 and I have two questions. 1) my event function (line 79) returns a new signal and takes 3 arguments : an initial signal and a Bool signal which triggers when to apply the transform function given as a third argument. The body of the event function uses two calls to the sampler function. Is it possible to write this body with a unique call to sampler ? 2) this event function is used to link a keypress with a transformation of the position of the player. It is thus called two times (lines 91 and 94), one for each one of the two keys LEFT and RIGHT. Thanks to the ability to compose a new Bool signal from other ones, it is possible to define a guard for the transform function during the calls to event (lines 92 and 95 : the incrementation (decrementation) is only doable when the player abscissa is less than 0.6 (more than -0.8)). Nevertheless, during the game, I noticed some discrepancy with this ideal description : try to go to an extreme side (several hits of the LEFT key for instance until the player hits the left side) then go back in the opposite direction before hitting the opposite side (three hits of the RIGHT key for instance) then the first key pressing corresponding to the opposite of the opposite direction (i.e the initial LEFT direction) has no effect. Do you understand why ? Thanks

1 1