News aggregator

Mixing own and derived instances with GenericDeriving Mechanism

haskell-cafe - Sat, 02/01/2014 - 2:11pm
Dear Pedro, Cafe, Thanks again for helping me out last December. I have been playing a bit more with deriving show and now ran into an interesting problem mixing my own instances with derived instances. Hope you can enlighten me there! > {-# LANGUAGE DeriveGeneric #-} > module Test where > import GHC.Generics > import Generics.Deriving.Show The Generic Deriving Mechanism adds the keyword 'default' to class definitions. With this keyword we can define a type-generic definition of that method when not given. For example, if we define our own MyData type, we can derive the GShow methods: > data MyData = MyData MyFancyType deriving Generic > instance GShow MyData We can also still give our own definition, for example if we want values of the MyFancyType to always be shown as the same string: > data MyFancyType = MyFancy1 | MyFancy2 deriving Generic > instance GShow MyFancyType where > gshow _ = "Fancy!" There is something strange here though: when we use gshow directly on a MyFancyType val
Categories: Offsite Discussion

(Question) DSLs and heterogeneous lists

Haskell on Reddit - Sat, 02/01/2014 - 9:57am

I have a game in which the user can create/write/read variables, using a small DSL. The type of the variables created can be whatever chooses the user, so I'm using existential types to store those variables in a heterogeneous list. This works fine, but the problem is that the "Typeable" class tag leaks into the DSL... The question is, how to get rid of it?

> This is literate Haskell > {-# LANGUAGE GADTs, ScopedTypeVariables #-} > module DSLClass where > import Control.Monad > import Control.Monad.State > import Data.Typeable

This is the (simplified) DSL. With it you can read a variable stored in the game state (creation/writing is not shown). How can we get rid of the "Typeable a" in the ReadFirstVar constructor?

> -- first type parameter is used to track effects > data Exp a where > ReadFirstVar :: (Typeable a) => Exp a <----- Ugly > Return :: a -> Exp a > Bind :: Exp a -> (a -> Exp b) -> Exp b

This is the definition of a variable. The type is unknow, so I use existantial types.

> data Var = forall a . (Typeable a) => Var { v :: a}

This game state. It holds the heterogenous list.

> data Game = Game { variables :: [Var]}

The evaluation of "Exp" can be:

> eval :: Exp a -> State Game a > eval ReadFirstVar = do > (Game ((Var v):vs)) <- get > case cast v of > Just val -> return val > Nothing -> error "no cast" > eval (Bind exp f) = do > a <- eval exp > eval (f a)

As you can see, I'm obliged to cast the variable type to match it with the expression's type. Is that the right place to do it?

Thanks!!

submitted by kaukau
[link] [10 comments]
Categories: Incoming News

Yesod Web Framework: PostgreSQL, UTCTime, and WITHOUT TIME ZONE

Planet Haskell - Sat, 02/01/2014 - 8:40am

I've just added a Wiki page describing the situation in PostgreSQL databases regarding the schema type used for UTCTime. This is a question that seems to come up every so often and, since I just wrote a user a rather lengthy explanation of the problem, decided it was time to set up a canonical location for the information. I've copied the full content of the Wiki page below for ease of viewing.

My question is: have I missed some use case with this explanation?

A question which comes up quite a bit is why persistent-postgresql stores UTCTime values in the database as TIMESTAMP WITHOUT TIME ZONE instead of WITH TIME ZONE. There are two datatypes in Haskell, and two in PostgreSQL, relevant to this discussion:

  • Haskell
    • UTCTime: An exact moment in time, in the UTC timezone.
    • ZonedTime: A UTCTime plus a timezone.
  • PostgreSQL
    • WITHOUT TIME ZONE: A time stamp, which could be in any time zone.
    • WITH TIME ZONE: An exact moment in time, with a given time zone.

It's clear from this that ZonedTime and WITH TIME ZONE line up perfectly. The problem is that there's a small mismatch between UTCTime and WITHOUT. The latter could imply any timezone, which is quite problematic. When Persistent uses this SQL type, it guarantees that all stored timestamps are in UTC time, and therefore does not run into any issues of mismatched timezones.

However, why not get the extra safety of being explicit about the timezone selection in the database? The problem comes down to what Persistent should do in the case of a value in a non-UTC timezone. There are essentially two options:

  1. Raise an exception about unexpected data. This is suboptimal, since we would like to avoid runtime errors like this whenever possible, and instead rely on the type system + SQL schema to keep things safe.
  2. Simply discard the timezone information. The problem here is that roundtripping will no longer work: reading a value, dropping the timezone, and writing back to the database would force a conversion to the UTC timezone, which may not be what a user wants.

So in your application, what should you do? Here's my recommendation:

  • If your database is only being accessed from Persistent, using UTCTime and WITHOUT TIME ZONE is perfectly safe, and is a simpler option.
    • Unless, of course, you actually want to store timezone information, in which case you should use ZonedTime!
  • If you're dealing with an existing database, or publishing data that other applications will need to see, always use ZonedTime. Inside your application, you can trivially converted to a UTCTime instead. But this will force you to be aware of any data loss you may be performing, and of any roundtripping issues you may be introducing to your database.
Categories: Offsite Blogs

davean/waldo · GitHub

del.icio.us/haskell - Sat, 02/01/2014 - 8:34am
Categories: Offsite Blogs

Trolling #haskell

del.icio.us/haskell - Sat, 02/01/2014 - 7:13am
Categories: Offsite Blogs

Manage effects in a DSL II

Haskell on Reddit - Sat, 02/01/2014 - 5:01am

I got some very interesting responses from my first post. I decided to put them together in a blog post: http://www.corentindupont.info/blog/posts/2014-01-30-DSL-Effect.html

submitted by kaukau
[link] [comment]
Categories: Incoming News

Alejandro Cabrera: OSCON 2014 Aspirations: The Case for Haskell

Planet Haskell - Fri, 01/31/2014 - 11:19pm
Update (Feb. 01, 2014, 00:18am EST): I uploaded by proposal to OSCON two days ago, then blogged about it. You can see the result here: OSCON 2014 Proposal

It's been an exciting year, and it's only just started.

Inspired by movements like Allowed to Apply and following all kinds of amazing people on Twitter, I'm going to submit an OSCON proposal this year.

I decided this about a day and a half ago, a bit close to the proposal submission deadline. I've had to move fast as a result.

Yesterday, I brainstormed on what I want to speak on. Haskell. Definitely Haskell. It's what I've poured a good portion of my free time in to over the past few months. Sadly, I've yet to even say hello on #haskell, but it's been great listening in to discussions on there!

So, more on that brainstorming -

The title: "The Case for Haskell"
The track: Emerging Languages
The goals:

1, Instill excitement in Haskell
2. Show where Haskell can help you (a list of 10)
3. Share 5 places where Haskell is changing the way we think

There's a lot of pieces left to fill in there still.

Today, I put together a short summary of talks that emphasized how language features helped people solve problems that were presented at OSCON 2013. I'm sharing this guide with you today in the hope that it helps you build a great submission to OSCON 2014.

You can find the guide here: OSCON 2013: What People Were Saying About Languages

Happy reading!


Categories: Offsite Blogs

Instances and Dictionaries

Haskell on Reddit - Fri, 01/31/2014 - 10:13pm
Categories: Incoming News

Dispatch a type-function on the existence (or not)of instances?

haskell-cafe - Fri, 01/31/2014 - 7:56pm
Dear all, I have been curious about the ability to detect the presence of a certain instance (ClassFoo TypeBar) in the type system. Specifically, is it possible to "dispatch" a type on the existence (or not) of such an instance. For example given two functions: withInstance :: (ClassFoo TypeBar) => TypeIfInstanceExists withoutInstance :: TypeIfInstanceDoesNotExists I would be able to consolidate them into something like this: withOrWithoutInstance :: (r ~ InstanceExists ClassFoo TypeBar, a ~ If r TypeIfInstanceExists TypeIfInstanceDoesNotExists) => a I guess what I need is: 1) A type-level "if". 2) The possibility of "converting" a constraint into a type-level bool. I am sure (1) is possible but have no idea about (2). Anyone? Best regards, Hans
Categories: Offsite Discussion

What game libraries should I use?

haskell-cafe - Fri, 01/31/2014 - 2:19pm
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I need: - -2D graphics (preferably with simple shapes available) - -menus (I can make menus myself with shapes though) - -simple audio - -fonts (better than Gloss at least) - -keyboard input - -networking (simple direct connections between two computers) I need to be able to express my game system as declaratively as possible[0]. If the library is based on SDL/OpenGL, that would be nice[1]. This is, however, not necessary. What game libraries are the most mature and adequate for this? The only library I have used previously with Haskell is Gloss. I am not experienced in FRP, though I have read about and somewhat groked the point. I am willing to learn an FRP library. [0] I am writing it as part of a thesis in which I will look at the modularity and expressiveness of purely functional programming compared to object-oriented programming. Writing code that is technically purely functional, but in practice looks like imperative code, is sub-optimal. [1] For
Categories: Offsite Discussion

Jon Kristensen: d-bus: A Pure* and Permissively Licensed D-Bus Implementation for Haskell

Planet Haskell - Fri, 01/31/2014 - 1:44pm

D-Bus is a free software framework for inter-process communication. It’s used by many components of the freedesktop.org implementations, including GNOME, KDE, and Xfce. Until today, there were (to our knowledge) no permissively licensed pure D-Bus implementation written for Haskell.

Philonous and myself are hereby presenting d-bus, a permissively licensed D-Bus client library written purely in Haskell*. The library has been written by Philonous, but we have shared the development costs between ourselves.

This initial release features all D-Bus data types, complete handling of D-Bus signatures (which describes the number and types of arguments required by methods and signals), as well as introspection. The library uses modern extensions to the Haskell type system (including GADTs, DataKinds and TypeFamilies) and the singletons library to embedd the D-Bus type system. This allows D-Bus signatures to be inferred.

The library will be used by the Pontarius project (together with Pontarius XMPP and our end-to-end security software in the works) to allow for integration with our upcoming GNOME software.

*) If you’re compiling on FreeBSD there is a small piece of C code for compatibility.

Update, 25 February, 2014: Vincent Hanquez has pointed out that he has actually developed a permissive D-Bus library, udbus. The point for us was the dependently typed interface, and had we known about udbus, we would have happily built our interface on top of it.

Categories: Offsite Blogs

TFP 2014 - 2nd call for papers

haskell-cafe - Fri, 01/31/2014 - 10:49am
--------------------------------- 2ND C A L L F O R P A P E R S --------------------------------- ======== TFP 2014 =========== 15th Symposium on Trends in Functional Programming May 26-28, 2014 Utrecht University Soesterberg, The Netherlands http://www.cs.uu.nl/wiki/TFP2014/WebHome *** Submission for TFP 2014 is now open: please direct your browser to *** http://www.cs.uu.nl/wiki/TFP2014/PaperSubmission The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below), described in draft papers submitted prior to the symposium. A formal post-symposium refereeing process then selects a subset of the articles presented at the symposium and s
Categories: Offsite Discussion

TFP 2014 - 2nd call for papers

General haskell list - Fri, 01/31/2014 - 10:49am
--------------------------------- 2ND C A L L F O R P A P E R S --------------------------------- ======== TFP 2014 =========== 15th Symposium on Trends in Functional Programming May 26-28, 2014 Utrecht University Soesterberg, The Netherlands http://www.cs.uu.nl/wiki/TFP2014/WebHome *** Submission for TFP 2014 is now open: please direct your browser to *** http://www.cs.uu.nl/wiki/TFP2014/PaperSubmission The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below), described in draft papers submitted prior to the symposium. A formal post-symposium refereeing process then selects a subset of the articles presented at the symposium and s
Categories: Incoming News