News aggregator

Workshop on Type Inference and Automated Proving

General haskell list - Wed, 04/15/2015 - 10:28pm
********************************************************************* WORKSHOP ON TYPE INFERENCE AND AUTOMATED PROVING Tuesday the 12th of May, 12PM to 6PM School Of Computing, University of Dundee http://staff.computing.dundee.ac.uk/frantisekfarka/tiap/ ********************************************************************* Refreshments will be available from 12:00, with talks beginning at 12:45. For the detailed programme please see the above website. Talks: Tom Schrijvers (Katholieke Universiteit Leuven) GADTs Meet Their Match: Pattern-matching Warnings that Account for GADTs, Guards, and Laziness Bob Atkey (University of Strathclyde) An Algebraic Approach to Typechecking and Elaboration Edwin Brady (University of St Andrews) Implementing a Dependently Typed Programming Language Peng Fu (University if Dundee) Nontermination Analysis for Evidence Construction in Type Class Inference Adam Gundry (Well-Typed LLP
Categories: Incoming News

bed & breakfast library update?

libraries list - Wed, 04/15/2015 - 7:52pm
I've asked a couple of times over the last eight moths for an update of this library that would compile on 7.8 to be published, and gotten no response. If you're not able or interested in maintaining this library any longer, please let the community know so that someone else can take over those duties. If you can't or don't respond, I'll have to assume you're no longer able to, and see about getting another maintainer. Thank you, Mike _______________________________________________ Libraries mailing list Libraries< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Categories: Offsite Discussion

Leuven Haskell User Group meeting on April 21

General haskell list - Wed, 04/15/2015 - 7:38pm
You are kindly invited to the special edition of the Leuven Haskell User Group with guest presentation by Amplidata. For details see: https://groups.google.com/d/msg/leuven-haskell/VNcTKtFPGL0/gQhPWtxTbg4J
Categories: Incoming News

Haskell on Windows instructions - is MinGHC versionupdate needed?

General haskell list - Wed, 04/15/2015 - 5:50pm
Hi, Currently, the Haskell website's Windows download page (https://www.haskell.org/downloads/windows) offers two alternatives, MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC-7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want to update the link, you only need to change the URL from 7.8.3 to 7.8.4. Howard
Categories: Incoming News

Joachim Breitner: Talk and Article on Monads for Reverse Engineering

Planet Haskell - Wed, 04/15/2015 - 5:32pm

In a recent project of mine, a tool to analyze and create files for the Ravensburger Tiptoi pen, I used two interesting Monads with good results:

  • A parser monad that, while parsing, remembers what part of the file were used for what and provides, for example, an annotated hex dump.
  • A binary writer monad that allows you to reference and write out offsets to positions in the file that are only determined “later” in the monad, using MonadFix.

As that’s quite neat, I write a blog post for the German blog funktionale-programmierung.de about it, and also held a talk at the Karlsruhe functional programmers group. If you know some German, enjoy; if not, wait until I have a reason to hold the talk in English. (As a matter of fact, I did hold the talk in English, but only spontaneously, so the text is in German only so far.)

Categories: Offsite Blogs

Syntax for has type and has kind

Haskell on Reddit - Wed, 04/15/2015 - 4:18pm

This is probably not the right place to ask, but I didn't think it belongs on SO. Currently, :: is used to express has type in type signatures, as well as has kind in extensions like KindSignatures, PolyKinds, ConstraintKinds, DataKinds etc…

Would it be more clear/concise if we use :k for has kind, and use :t as an alternative of :: to denote has type? In GHCi, :t is already short for :type and :k for :kind, so I think this would make a nice correspondence between the language syntax and the interpreter.

Granted, I'm pretty new to all these advanced language extensions, but from time to time when I see :: pops up in code where I do not expect it to, I have to pause and think, is :: here for type, or for kind?

Any thoughts?

submitted by lurking-about
[link] [6 comments]
Categories: Incoming News

Noam Lewis: Identity Crisis

Planet Haskell - Wed, 04/15/2015 - 4:10pm

Compared to other tools adding static types to JavaScript, Infernu’s main strengths are full type inference and strong type safety. Here are a few examples.

Identity Function

Here is the simplest possible function:

function id(x) { return x; } TypeScript

TypeScript‘s compiler tsc can generate a .d.ts from that:

declare function id(x: any): any;

That’s no good! We can pass any type we want to our function, but the return type is not tied to the argument type – it is treated as anything, basically untyped. So we can do this:

var n = 'hi'; n = id(5);

And TypeScript will output the following .d.ts:

declare var n: string;

That seems wrong: n is assigned a number via id(5). But wait – there is a way to turn off inference of any types (with --noImplicitAny). If we try that on our identity function, we get:

id.ts(1,13): error TS7006: Parameter 'x' implicitly has an 'any' type. Explicit Generics

Oops. Ok, but TypeScript has generics! Let’s try that: the TypeScript handbook gives exactly the example we need – we just write the type out explicitly, like so:

function identity<T>(arg: T): T { return arg; }

Great! We got what we needed, but without type inference.

Flow

Facebook’s Flow has a type system that’s (slightly?) different from TypeScript’s, and apparently works differently. Let’s try it. We can use the flow suggest command to get suggested typing (I’m using version 0.7). Here’s what we get for a single file containing only the identity function above: nothing. It doesn’t suggest any type. Ok, let’s try using our id in a way that makes no sense, to induce an error (after all, type checkers are used to find errors). Here’s bad_id.js:

/* @flow */ function id(x) { return x;} var n = 'hi'; n = id(5); var z = n; // added so we can see what flow says the type of n is here.

(Note: The /* @flow */ header is used to tell flow that it should look at this file.)
Run flow suggest bad_id.js and you get a diff-style output. I’ve ‘applied’ it to make it easier to read – here’s what flow suggests:

function id(x: number) : number{ return x;} var n: string | number = 'hi'; n = id(5); var z: number = n;

Interesting! We managed to get something without reverting to explicit type annotations. But we didn’t get an error!

First, id was inferred to take and return number, apparently because that’s the only way we’ve used it. It would be interesting to see what happens when we use id several times with different types – we’ll try that soon.

Second, n was given a union type string | number, because it takes on both types during its lifetime. It may be a matter of taste, but I would rather not have the type checker deduce implicit union types in this case (n = 'hi'; n = 5;) – instead I would expect that to be an error.

The unique (and impressive) part is that flow is able to tell that z is only ever going to have number values, and so it’s safe to assign it that type. That’s probably a result of the flow analysis they do.

Now let’s try calling id several times, with different types:

/* @flow */ function id(x) { return x;} id(5); id('hi');

Flow suggests:

function id(x: string | number) : string | number{ return x;}

Uh oh – does this means the argument and result types are no longer tied to each other? If I pass in a number, will the compiler check that I use the result only as a number (and not as a string)? Let’s try using it, doing var n = id(5), flow suggests:

var n: string | number = id(5);

Despite n only ever being assigned a number, it now has type string | number. So apparently, union types propagate implicitly, infecting everything on the way.

Explicit Generics

Fortunately, flow too has generics, and again straight out of the manual we find:

/* @flow */ function foo(x: X): X { return x; }

Great! We got what we needed, but without type inference.

Infernu

Let’s get down to business. Infernu says:

// id : a.(b -> b) function id(x) { return x; }

Cool! Without any help from us, Infernu figured out the most generic type. Take a type b, return the same type b. The magic of polymo…Wait, what’s that a. thing?

Well, JavaScript has this nice keyword called this which is dynamically scoped, meaning that this is bound to different things depending on how your function is invoked and not on how it’s defined. For example:

var obj = { hat: { type: 'top' }, getHatType: function() { return this.hat.type; } }; obj.getHatType(); // ok. var f = obj.getHatType; f(); // oops! TypeError: Cannot read property 'type' of undefined

Nasty stuff. Every JavaScript programmer should know this.

Fortunately, Infernu is here to save you. It infers not only what arguments and return types a function has, but also what this must be for the function call to work, and verifies that you use it correctly.

Infernu type signatures for functions have the following format (subject to change without notice, bla bla bla):

this.(arguments -> result)

So for our var f = obj.getHatType example, Infernu says:

// f : {hat: {type: d, ..f}, ..e}.(() -> d) var f = obj.getHatType;

Decomposing that type signature, we read that this is expected to be an object containing at least a property called ‘hat’ which is an object with at least a property called ‘type’ of some type d. The function takes no arguments (hence the empty ()) and returns the same type d that was taken from the hat.type property of this. (The ellipsis stuff ..f and ..e is due to row-type polymorphism, which will be elaborated upon in a future blog post.)

Back to our identity function, we examine the signature again: a.(b -> b) – the type of this is given an unconstrained type parameter a – so Infernu is telling us explicitly that this is allowed to be anything for our identity function. Yippy!

Summary

We saw that both TypeScript and Flow (and Google Closure too, which I haven’t shown) support generics that can express the identity function properly. They also offer weak forms of type inference that sometimes yields weakly-typed results. Infernu, on the other hand, will infer generic types automatically, and prefers to fail over giving weak typings.

There are many known discussions about subtyping (inheritance)-based type systems, represented here by TypeScript and Flow, vs. parametric polymorphism (being Infernu in this case). There are known pros and cons to both sides: but one important result is that type inference is just easier when there is no subtyping involved.

Infernu is designed to take advantage of that.


Tagged: Infernu, Javascript
Categories: Offsite Blogs

Tom Schrijvers: Invitation for the 4th meeting of the Leuven Haskell User Group on April 21

Planet Haskell - Wed, 04/15/2015 - 12:42pm
You are kindly invited to the upcoming meeting of the Leuven Haskell User Group. We have a special guest presentation by Amplidata, which is the first Belgian company to seriously use Haskell.

See here for details.
Categories: Offsite Blogs

Execution order in IO

haskell-cafe - Wed, 04/15/2015 - 10:07am
Good morning all, I think I've got the hang of the way state is carried and fancy operators work in monads but still have a major sticky issue. With lazy evaluation where is it written that if you write things with no dependencies with a "do" things will be done in order ? Or isn't it ? Is it a feature of the language we're supposed to accept ? Is it something in the implementation of IO ? Is the do keyword more than just a syntactic sugar for a string of binds and lambdas ? Jon
Categories: Offsite Discussion

cabal-helper-wrapper: Installing a private copy of Cabal (What?)

Haskell on Reddit - Wed, 04/15/2015 - 7:41am

I was trying to answer a question on stackoverflow to help someone install ghc-mod. Now as of this post ghc-mod does not compile with GHC-7.10 and cabal-1.22 sandboxes break ghc-mod. So I detailed how to (not very cleanly) downgrade cabal-1.22 to cabal-1.20.0.3. If there is a nicer way to do this I would love to know.

However, soon after writing my post Daniel Gröber posted a working fork of ghc-mod that compiles and works with GHC-7.10! So I put this at the top of my answer after trying it myself with great success. Unfortunately, the person asking the question on stack exchange is getting an error I have never seen before.

Why would cabal install a private version of cabal? For the full error please see the post on stackoverflow.

I apologize for asking this here, but I wasn't sure where else to ask.

submitted by Aoi32
[link] [5 comments]
Categories: Incoming News

Coding katas/dojos and functional programmingintroduction

haskell-cafe - Wed, 04/15/2015 - 7:34am
Hello, Some days ago I have participated to a coding dojo* which aimed to be an introduction to functional programming. I have also facilitate 3 of events like this and do several talks on this subject. But I'm kinda disappointed because each time there is a common pattern: 1. Unveil the problem which will be treated 2. Let the attendees solve it 3. Show the FP-ish solution (generally a bunch of map/fold) I think it's frustrating for the attendees (because they don't try to solve it) and gives a false illusion of knowledge. I don't consider myself as a "FP guru" or anything but for me FP is a matter of types and expressions, so when someone illustrate FP via map/fold, it's kind of irritating. Ironically, the best workshop I have done was on functional generalization (you begin by two hard coded functions, sum and product, and you extract Foldable and Monoid), but again, it's not satisfying. We can do better, we should do better. Have you got any feedback/subjet ideas/examples on how to introduce "real" FP t
Categories: Offsite Discussion

Failing to set up emacs for Haskell coding

Haskell on Reddit - Wed, 04/15/2015 - 7:30am

Hello everyone,

I'm semi-new to Haskell development (I finished LYAH, now doing CIS194) and always used Sublime Text + Terminal to write and run code. I wanna switch over to emacs (I doubted between Vim and emacs, choice went to emacs. If Vim is easier, please recommend me Vim) but I keep failing to setting it up for Haskell.

I followed Tim Dysinger's tutorial and this tutorial (which was recommended by Bitemyapp's Github tutorial, which I follow).

Both of them don't result in what I think is correct. The first one should result in a colored window, but doesn't, so I doubt the rest works. The second one doesn't run M-x haskell-stylish-...

Can anyone point me to an easy to follow tutorial for setting up a text editor for Haskell development (that actually works)

Note: I works on OSX

submitted by MusicalWatermelon
[link] [22 comments]
Categories: Incoming News

Should a module exporting TH-code also export the types/constructors/functions etc needed by the generated code?

Haskell on Reddit - Wed, 04/15/2015 - 5:42am

Basically what the title says.

If I don't re-export, the person using the library will have to manually import these names, and there's no really nice way of showing this in the documentation, as you can't tell from the types of the TH-functions what the generated code will USE.

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

cabal install glade

haskell-cafe - Wed, 04/15/2015 - 4:33am
Hello, I am trying to install the Glade package from hackage, and I keep getting exit failure... Hope someone can help me solve it! What I did: $ mkdir ~/haskell/project $ cd ~/haskell/project $ cabal sandbox init $ cabal update $ cabal install alex $ cabal install happy $ cabal install gtk2hs-buildtools $ cabal install gtk #successful until here $ cabal install glade The last statement gave me the following error: $ [1 of 2] Compiling SetupWrapper ( /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/SetupWrapper.hs, /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/dist/dist-sandbox-acbd4b7/setup/SetupWrapper.o ) $ $ /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/SetupWrapper.hs:91:17: $ Ambiguous occurrence ‘die’ $ It could refer to either ‘Distribution.Simple.Utils.die’, $ imported from ‘Distribution.Simple.Utils’ at /tmp/cairo-0.12.5.3-5133/cairo-0.12.5.3/SetupWrapper.hs:8:1-32 $ or ‘System.Exit.die’, $ imported from
Categories: Offsite Discussion

Floating and Data.Fixed

libraries list - Wed, 04/15/2015 - 1:43am
Hello libraries list, (Warning: this whole message may be a waste of time, you may wish to skip it.) I'd like to inquire about the possibility of a Floating instance for Data.Fixed. (Unfortunately, not knowing of the existence of this list or the appropriate procedure, I created a trac ticket to ask about this, because that was the only forum I knew of. It's https://ghc.haskell.org/trac/ghc/ticket/10297. Sorry.) The original idea was along these lines: lift :: (HasResolution a) => (Double -> Double) -> Fixed a -> Fixed a lift f = realToFrac . f . realToFrac instance (HasResolution a) => Floating (Fixed a) where pi = realToFrac pi sin = lift sin -- etc, similar lift2 function for (**), logBase This allows the use of transcendental functions on Fixed values. Conceptually, transcendental functions on fixed point values aren't problematic, and are actually pretty widely used in certain gaming/simulation/signal processing applications. I've since learned that this may not be a good idea. A commenter
Categories: Offsite Discussion