News aggregator

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 http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 1 Nov 2014 (please send your contributions to hcar at haskell.org, 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

del.icio.us/haskell - 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

Domain settings

Lambda the Ultimate - Sat, 10/04/2014 - 5:24am

I am about to make some changes to the name server definitions. Since changes take time to propagate, you may have trouble reaching the site for awhile. If this happens, try using the .com domain instead of the preferred .org domain.

Categories: Offsite Discussion

apfelmus: GUI - Release of the threepenny-gui library, version 0.5.0.0

Planet Haskell - Sat, 10/04/2014 - 2:59am

I am pleased to announce release of threepenny-gui version 0.5, a cheap and simple library to satisfy your immediate GUI needs in Haskell.

Want to write a small GUI thing but forgot to sacrifice to the giant rubber duck in the sky before trying to install wxHaskell or Gtk2Hs? Then this library is for you! Threepenny is easy to install because it uses the web browser as a display.

The library also has functional reactive programming (FRP) built-in, which makes it a lot easier to write GUI application without getting caught in spaghetti code. For an introduction to FRP, see for example my slides from a tutorial I gave in 2012 (the API is slightly different in Reactive.Threepenny) and the preliminary widget design guide.

Version 0.5 is essentially a maintenance release, allowing for newer versions of the libraries that it depends on. It also incorporates various contributions by other people, including a small Canvas API by Ken Friis Larsen and Carsten König, and a complete set of SVG elements and attributes by Steve Bigham. Many thanks also to Yuval Langer and JP Moresmau.

However, while it’s great that the library begins to grow in breadth, incorporating larger and larger parts of the DOM API, I also feel that the current backend code is unable to cope with this growth. In the next version, I intend to overhaul the server code and put the JavaScript FFI on a more solid footing.

To see Threepenny in action, have a look at the following applications:

Daniel Austin’s FNIStash
Editor for Torchlight 2 inventories.
Daniel Mlot’s Stunts Cartography Track Viewer
Map viewer for the Stunts racing game.

Get the library here:

Note that the API is still in flux and is likely to change radically in the future. You’ll have to convert frequently or develop against a fixed version.

Categories: Offsite Blogs

Blog | jelv.is¬es

del.icio.us/haskell - Fri, 10/03/2014 - 8:53pm
Categories: Offsite Blogs

Blog | jelv.is¬es

del.icio.us/haskell - Fri, 10/03/2014 - 8:53pm
Categories: Offsite Blogs

www.joachim-breitner.de

del.icio.us/haskell - Fri, 10/03/2014 - 8:00pm
Categories: Offsite Blogs