News aggregator

Approaches to designing a Haskell API

Haskell on Reddit - Sun, 10/05/2014 - 4:47am

I've written a blog post about designing haskell APIs for external services.

I'm open for discussion and would like some feedback. I would also like to hear how you approach this problem and about any novel solutions.

submitted by edofic
[link] [2 comments]
Categories: Incoming News

How to Rewrite the Prelude

Haskell on Reddit - Sun, 10/05/2014 - 4:17am
Categories: Incoming News

Matthew Sackman: Programming in the real world

Planet Haskell - Sun, 10/05/2014 - 3:22am

One of the things that annoys me about Object Oriented Programming is how it's often suggested that it models the "real world". Frequently tutorials will start with creating an object modelling a chair, and through inheritance you'll be able to build up composable aspects of chairs: different numbers of legs, different colours, different designs. Sometimes they use tables rather than chairs. This is lovely, but it actually has everything to do with data modelling through inheritance, decomposition, abstraction and encapsulation, and almost nothing to do with Object Orientation: the key is that these chairs have no modifying methods on them. If they have any methods at all then they'll be for things like getting the number of legs or the colour, or volume or something - something that is basically fixed once the object is instantiated. At this point in such tutorials I'd probably claim this is not actually programming yet: all that's been achieved so far is that we've assigned some semantics to some numbers held in memory and we can write some numbers in memory. Programming is when we manipulate numbers: that involves reading and writing numbers.

The problem then is that Object Orientation immediately stops being about modelling the "real world" as soon as we can modify memory. If we think about how we actually would go about getting a chair made for us, it could go a bit like this:

  1. Go see your local carpenter,
  2. Have a discussion with them about the style and type of chair you'd like,
  3. They make the chair and give it to you in return for payment,
  4. You take the chair home,
  5. You decide you don't like the colour so you take it to your garage and repaint it yourself.

It should be clear that the inanimate object (the chair) is the odd one out here. Everything else is done by actors that have their own state, mainly act asynchronously, and can communicate with other actors through protocols - protocols that do not involve sharing mutable state (e.g. if I say something to you, that speech is immutable; you can't change what I've said (though you could choose to mishear me!)). At no point is any state of any actor actually exposed to another actor: I may share with you what I'm currently thinking, and you can try to influence me, but we don't exactly need a mutex around memory in my brain because YOU'RE NOT GETTING IN THERE!

If you tried modelling this sort of thing through Object Orientation without actors then you'd end up with your own thread doing all the work: it'd be you, it'd be the carpenter and it'd be the chair, maybe all at once. If your carpenter is in fact a growing business with a receptionist, a design team and a billing department your thread would be playing those roles too and would probably have to use locks to avoid unexpected interactions with other threads doing the same commissioning-receptioning-designing-constructing-delivery-repainting dance. And all the time, whilst you're doing the carpentry yourself, you'd could easily have your own thoughts, feelings, aspirations and regrets all on the same stack for your carpenter-alias to mess with.

Thus Object Orientation causes multiple personality disorder.

So in my view, the way Object Orientation gets introduced tends to be more like "useful tools for modelling data". But the OO approach to manipulating that data goes wrong as soon as you try to model the animated real world. Firstly it has nothing to say about separating out threads to self-contained actors (but try this in a language or on a platform without green-threads, or without the ability to preempt threads and you can quickly hit pain), and secondly even if you do have actors, OO encourages the sharing of mutable data rather than passing around either immutable data or copies of data. Yes, good programming discipline can result in sane designs and a successful result, but it's not a core aspect of the OOP mantra.

So, OOP has nothing good to say on manipulating data at all - it either says nothing or it encourages silly ideas like using locks. The data modelling bits are fine, but I think they're a broader concept beyond the confines of OOP. What else does OOP get you? An arbitrary restriction on the receiver of any method. That's about it. It's thanks to this restriction that writing combinators like cons on a list library in an OO language is really painful.

This week Erik Meijer wrote an article called The Curse of the Excluded Middle: "Mostly functional" programming does not work. After an introduction, we get onto The Problem, which (paraphrasing) is that languages that are mainly imperative but offer some features from pure functional languages are not as safe as pure functional languages.

The first three examples, from C# are certainly surprising to me (I barely know any C# at all though). The first two problems come from trying to compose side-effecting stuff with laziness. In the first case it's not clear that the problem is with the IO operation (printing things out) or actually with the laziness, but more the odd behaviour of the Where operator (presumably the implementation of Where doesn't know that a Cartesian product isn't necessary, but surely any normal monadic/list-comprehension implementation wouldn't have this problem?). The second case is certainly the terrifying composition of laziness with throwing exceptions and thus the exception having the potential to pop out anywhere where the lazy expression gets forced. However, if you know the Select operator is lazy, it's not really that surprising. It's arguably piss-poor language design that there's nothing there to help you, but C# doesn't have checked exceptions; apparently programmers don't like having to deal with errors so you reap what you sow. The third case is how C# has a nice using feature which binds a resource to a lexical scope. But if you construct a closure capturing the resource and then send it out of that lexical scope then using goes wrong (it will still discard the resource even though there's a reference to it within the closure which remains in-scope). This is certainly piss-poor language design: if the closure captures stuff from your lexical scope and you're not reference counting (or equivalent) your lexical scope then YOU'VE DONE IT WRONG. This is as bad as in C allocating stuff on your stack and then returning pointers to it.

Next he moves on somewhat tangentially to the point that if object creation is an observable action then you can't optimise it out. I'm not sure anyone outside a pure functional language specialist would ever want object creation to be optimised out, but the point is that if your constructor has side effects or can in any other way be observed then you can't have your language runtime do memoization of object creation. Doing side effects in object constructors has long been discouraged: I first read that back in the Effective Java book about a decade ago and I'm sure it wasn't exactly a ground-breaking piece of advice then.

So far then we have that side effects which are untracked have the potential to be bad: whether it's printing things out, or throwing exceptions, or discarding resources early, or preventing compiler optimisations. But next I feel the article goes a bit wrong. He first moves onto how channels in C⍵ can store state so they're not pure either, thus bad. And then goes onto how in Erlang you have the same problem as you're just modelling mutable state in actors:

Note how this Erlang actor basically encodes an object with dynamic method dispatch using the pattern-matching, message-sending, and recursion primitives of the language, which you may happily leverage to implement mutable references, sabotaging the fact that the Erlang language does not natively expose mutable state.

This is wrong: you cannot implement mutable references in Erlang. Data is immutable in Erlang so if you send some value out of an actor, you are sending that value. Not a reference to a value or variable. Even if you create a closure and send that out of the actor, the closure is capturing those values as they exist at that point in time. If you have received a value sent to you from an actor, you may use it to create other values, but doing so does not affect the "original", and similarly, the actor itself can continue to modify its own state, but it does not affect the values it sent to you. Yes, you can use Erlang actors to model objects. But an actor's own modifications of its state cannot be observed as side effects on values you've previously retrieved from that actor, and vice versa.

The reference you have to an actor is a process identifier (also immutable) which does not present any information itself about the state of the actor. Through that, you can send messages to an actor and test whether or not the actor is still alive, but that is all. And in any case, where has the sudden objection to mutable state come from? State is just a catamorphism on prior inputs. State is not the problem: unconstrained side effects are the problem. Certainly sharing mutable state is a problem (and you could argue that mutating shared state is a side effect and that it should be tracked statically), but Erlang does not allow for that.

He may have been better off going for an example of opening an file, sending the file handle to another process and then closing the file handle before it's been used (i.e. the same as the third C# example). Except:

  1. All file operations can return an error anyway so handling errors in such code is completely normal;
  2. In Erlang a file handle is normally an actor itself, so what you're doing is passing around a process identifier. Sending messages to a dead process (once the file is closed) is a normal activity and you can detect if the process has died in normal ways;
  3. If you bypass such normal file handling for performance reasons and open the file in "raw" mode then Erlang has a light form of object capabilities in which only the process that opened the file is allowed to use the file handle, so again the use of the file handle would error predictably;
  4. The language doesn't have the same C# feature for discarding resources once you return out of a lexical scope. Consequently closing a file is an explicit operation and given the asynchronous concurrent mindset one develops when working in Erlang, it's very likely you'll realise how odd it is to be closing a file handle whilst there's some closure out there which may not have been run yet.

Beyond this, he introduces the Haskell type system and explains that it captures side effects statically. As a result, by bowing to the demands of the type checker, it offers you a proof that if such effects occur, your program will handle them: exceptions will not go uncaught, IO operations are only permitted where the semantics lead to expected outcomes, resources are not used after they're discarded and the compiler can use all these proofs to do all manner of optimisations to your program.

These proofs can certainly be very valuable (though they are no substitute for disciplined, high quality design and careful implementation). Obviously, they don't capture everything though. Particularly relevant for concurrent and distributed programs, they don't capture sufficient side effects to allow for a proof of the absence of deadlocks. Haskell standard libraries contain channels and semaphores which can easily be used to sporadically end up with a deadlock between processes. A deadlock is definitely a side effect: the effect is the program probably stops working. The cause is an insufficient use of locks to control the scheduler (be it scheduling of OS threads or language runtime scheduling of green threads).

More broadly, the proof a type checker offers is that the specification you've provided (type signatures) is not violated by its inferences about your code. Until the type checker allows "and makes progress" as part of a specification, Haskell itself is no safer than any other language that claims to be "mostly functional".

Categories: Offsite Blogs

Neil Mitchell: How to Rewrite the Prelude

Planet Haskell - Sun, 10/05/2014 - 1:05am

Summary: Rewriting the Prelude should be done in a separate package and take a few years to complete, hopefully building a consensus and improving the result.

My recent suggestion that the Prelude shouldn't be rewritten to incorporate Foldable/Traversable generated a lot of feedback. It's clear some people strongly agree, and some strongly disagree. So instead of continuing the argument, in this post I'm going to describe how I think the people who want to change the Prelude should go about it.

There were a lot of comments that we should optimise Haskell for practitioners, not beginners - in particular that there should be Prelude (for advanced users) and Prelude.Simple (for beginners). My personal opinion is that if we have two Prelude's, why not make the beginner one the default one? Switching to the non-default one probably takes one line of moderately advanced syntax (currently import Prelude(); import Prelude.Advanced). For a beginner, writing a simple one line program, that more than doubles the complexity. For a moderate user, that's almost certainly outweighed by lines of LANGUAGE pragmas. (I'm also not sure that I want the "Advanced" Prelude, but that's not relevant to this post.)

Step 1: Write the new Prelude in a package

The first step to proposing a new Prelude should be to write Prelude.Advanced in a separate package on Hackage. Let's assume we have a package base-advanced with a module Prelude.Advanced. The Prelude is not trivial, and translating high-level design goals (e.g. move Foldable into the Prelude) requires some design choices to translate into concrete code.

Step 2: Gain users and feedback

Rather than roll out the Prelude to everyone at once, slowly try and persuade people that your Prelude is superior to the existing one. In doing so, advanced users can start trying out the Prelude, and describing their experiences with it. Does it require Foldable to gain a size method? Does it show up a GHC error message that could be better? Do we need some new type of defaulting? Does profiling give poor results without some manually inserted cost centre? Is a direct list isomorphism a better type class to start from (as F# does with IEnumerable)? Given the number of enthusiastic supporters, this step should be easy.

Step 3: Incorporate feedback

The feedback from step 2 needs incorporating into the package, and potentially into GHC itself. I expect that will result in a significant number of revisions, and perhaps significant departures from the original design. Note that the classy-prelude package is following the steps above, and has had 38 revisions on Hackage so far.

Step 4: Gain acceptance

Before going any further, some critical mass of people need to agree the new way is preferable. There may turn out to be competing proposals, and hopefully as a community we can find consensus and identify the best ideas (as we are currently doing with IO streaming libraries).

Step 5: Move to base

Once we have agreement on what the new Prelude should look like, it should probably be moved into base. At this point, based on all the experience we've got, we can decide whether it becomes Prelude or Prelude.Advanced. At the same time as moving into base, we should decide on the simpler story, but what that decision looks like, will depend on what the proposed Prelude looks like.

The current approach

There are a number of areas that current approach worry me. The change was made directly in the base Prelude, based on some agreement of high-level design decisions, and has already resulted in unexpected additions to the Foldable class. The Prelude will first be exposed to lots of users once GHC 7.10 ships, by which point iterating on feedback will be slow and difficult. The plan for the "beginner" version is to encourage beginners to use the haskell2010 package, which I don't think has been thought out (as someone who tried to use the haskell98 package for a short while, the exception change meant you couldn't use haskell98 and base in the same package, which is basically fatal).

The Haskell community changed Applicative to be a superclass of Monad. That change was simple and thoroughly thought out over a period of years. Warnings were added to GHC, packages were analysed, people experimented with what it would mean, and once decided the change took a number of GHC releases to fully roll out. I consider this change to have been done the right way. In contrast, the complete rewrite of the Prelude is happening far more quickly, and I would argue too quickly. By taking a bit more time hopefully we can come up with something even better.

Categories: Offsite Blogs

NFM 2015 - 3rd call for papers

General haskell list - Sat, 10/04/2014 - 7:17pm
CALL FOR PAPERS The 7th NASA Formal Methods Symposium 27 – 29 April 2015 Pasadena, California, USA Paper Submission: 10 Nov 2014 THEME The widespread use and increasing complexity of mission- and safety-critical systems require advanced techniques that address their specification, verification, validation, and certification. The NASA Formal Methods Symposium is a forum for theoreticians and practitioners from academia, industry, and government, with the goals of identifying challenges and providing solutions to achieving assurance in mission- and safety-critical systems. Within NASA such systems include for example autonomous robots, separation assurance algorithms for aircraft, Next Generation Air Transportation (NextGen), and autonomous rendezvous and docking for spacecraft. Moreover, emerging paradigms such as property-based design, code generation, and safety cases are bringing with them new challenges and opportunities. The focus of the symposium will b
Categories: Incoming News

HSLogger and Ghci

Haskell on Reddit - Sat, 10/04/2014 - 4:57pm

Is there a good solution to using hslogger and ghci? If I kill the program in ghci it never releases the handle to the log file so I have to stop and restart ghci. Is there a better way to do this?

submitted by DiegoNola
[link] [4 comments]
Categories: Incoming News

Several default implementations for instance methods

haskell-cafe - Sat, 10/04/2014 - 4:44pm
Consider the following class for an overloaded pretty printer. For atomic data (numeric types, String etc.) one would implement prettyShow, for complex data either pretty or prettyPrec. > import Text.PrettyPrint > > class Pretty a where > pretty :: a -> Doc > prettyShow :: a -> String > prettyPrec :: Int -> a -> Doc Implementing one of these methods should be enough, giving default implementations for the other two. It is easy to get prettyShow and prettyPrec from pretty. > prettyShow = render . pretty > prettyPrec = const . pretty However, to define pretty from one of the others, I need two default implementations. > pretty = text . prettyShow > pretty = prettyPrec 0 Is there a way to get this to work? Workarounds (not entirely satisfactory): Technically, one could define a cycle of default implementations. Alternative 1: > pretty = prettyPrec 0 > prettyShow = render . pretty > prettyPrec _ = text . prettyShow Problem: Here, if pretty is defined,
Categories: Offsite Discussion

Call for Contributions - Haskell Communities and Activities Report, November 2014 edition

haskell-cafe - Sat, 10/04/2014 - 2:32pm
Dear all, We would like to collect contributions for the 27th edition of the ============================================================ Haskell Communities & Activities Report Submission deadline: 1 Nov 2014 (please send your contributions to hcar at, in plain text or LaTeX format) ============================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell us, so that we can contact the project leaders and ask them to submit an entry. * Feel free to pass on th
Categories: Offsite Discussion

Lecture notes and assignments - Sat, 10/04/2014 - 1:15pm
Categories: Offsite Blogs

Can this arbitrary-size tuple type be written in Idris?

Haskell on Reddit - Sat, 10/04/2014 - 11:43am

Could a type constructor taking a vector of types and returning a tuple type be written in Idris, or Agda? The goal would be to have a type where

() : Tuple [] tup = (True, Wednesday, North) : Tuple [Bool, Day, Direction] (Nothing :: tup) : Tuple [Maybe a, Bool, Day, Direction]

The type might be implemented as:

data Tuple (Vect n Type) where Unit : Tuple [] (::) : (x : t) -> (xs : Tuple ts) -> Tuple (t :: ts)

The purpose of this type would not be to have some kind of pseudo-dynamic lists, it just seems like a much cleaner and more orderly way of organizing a language's tuple types. Is is valid? What other approaches might work better, if any are even possible?

submitted by MuricanWillzyx
[link] [11 comments]
Categories: Incoming News

makeFields without lenses

haskell-cafe - Sat, 10/04/2014 - 10:57am
Good morning to everyone. I really love what makeFields from Control.Lens.TH does: generating a typeclasse HasXXX for each field _typeXXX and instances of the class for each type that has a record field with the same name. However, it generates lenses, which at this time I don’t use in my little project. I'll learn to use them well sooner or later, I promise! In the meantime, is there some module out there than provides a template haskell function that do the same thing but generating simple accessor functions instead of lenses? Or can I configure the parameters of makeFieldsWith to generate simple functions instead of lenses? Another related question: if I use makeFields in more than one module, and different records have fields with the same name, the generated typeclasses will have the same name but will be different, because declared twice in different modules, am I right? Is there a way to use a unique typeclass in the whole project for every generated field of the same name? Thank you very muc
Categories: Offsite Discussion

Proper way to structure data models

Haskell on Reddit - Sat, 10/04/2014 - 10:52am

So I'm quite comfortable with haskell, but one aspect in design that I haven't found a proper solution for is structuring data models for my various layers.

In Java, I've found that using a separate pojo for each layer to be the cleanest approach because most of the tools use reflection for configuration (e.g. I have an internal model used by my services and a model with Jackson annotations that represents the structure for my rest api). Then I use something like model mapper to go between the various models. I don't particularly like this approach, but it works well with Java.

In scala, I've been using one internal model (case class) for everything (the db entities (using slick) and the internal services). Then at the rest api layer I define my formatters which are implicit json serializers that take tuples of my internal models (e.g. A message along with the user that posted it: (Message, User)) and produce the correct json structrue for the specific endpoint using play-json; no extra classes/pojos needed. I like this because I only have one model for my data throughout my app, and the portion concerned with how the data is exposed externally is handled directly by the layer that exposes it. This is similar to the Java approach, just without the unneeded pojos and reflection magic.

Now, for haskell, my question is how does one structure their models for the varying layers without exposing implementation details outside their layer. For example, persistent wants to generate the models, the protobuf library wants records with special field types, and I don't want either of these details exposed elsewhere in my application. To handle this I've considered creating data models for each specific layer and providing Convertible instances to and from the core internal structure; is this advisable?

EDIT While writing my response to eegre, I realized that I feel like what I really want to do is emulate the "service abstraction" that I'm using in Scala/Java, and because I want to be able to swap out each component, I don't want to be dependent on any one component for the structure of my data. But I've had somewhat of an epiphany! I'll structure my application with my models at the core (Message, Comment, User, etc), then if I have a layer/component that needs to manage it's own data structure, I'll just convert to their models within the layer (their interface depends on my models, but their implementation may use their own). And now for the realization: I can create the service interfaces as records containing the implementations for each operation:

data MessageService m = MessageService { fetchById :: ID -> m Message, deleteById :: ID -> m () etc... }

Then I can provide implementations

dbMessageService = MessageService dbFetchById dbDeleteById ....

and pass those around to my external layers.

submitted by kcuf
[link] [11 comments]
Categories: Incoming News