News aggregator

Haskell in Leipzig 2016: Final Call for Papers

haskell-cafe - Thu, 06/23/2016 - 5:00pm
                             Haskell in Leipzig                             September 14-15, 2016                             HTKW Leipzig, Germany                          http://hal2016.haskell.org/ This is the third and last call for submissions for the Haskell in Leipzig workshop. In case you were hesitating whether you want to submit something, the answer is „Yes!“. I’m looking forward to receiving your contribution on July 1st (next Friday). == About HaL == The workshop series “Haskell in Leipzig”, now in its 11th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts and Haskell beginners to listen to talks, take part in tutorials, and join in interesting conversations. Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to function
Categories: Offsite Discussion

wren gayle romano: Self-improvement goals, overcoming perfectionism, and dissertating

Planet Haskell - Thu, 06/23/2016 - 2:43pm

This year's self-improvement goal was to get back into blogging regularly. Part of that goal was just to get back into writing regularly; the other part was specifically to publish more regularly.

I've done fairly well on the first half, actually. I'd hoped to do better, but then all year I've had to deal with spoon-draining circumstances, so I've probably done about as well as I can without sacrificing my health. One of my other self-improvement goals has been to take my health seriously, to listen to my body rather than pushing it beyond its limits. I'm on-track for improving at both of these, I just need to stop beating myself up over it.

For the second half, the publishing bit, that I've done poorly. I'd like to blame the spoon vortex here too, but really I think the biggest problem is my perfectionism. Perfectionism greatly amplifies the problem of lacking spoons: both the editing itself, as well as the emotional fallout of missing the mark or of having taken the entire day to hit it, both of these cost spoons. The real aim behind my goal to publish regularly wasn't to have more words to my name, but rather to “get out there” more, to be more productive in-and-of-itself rather than to have more products. So I've started thinking: the real target for this self-improvement goal should not be publishing regularly, but rather should be (working to) overcome perfectionism.

If perfectionism is a problem of fear, then the thing I must address is that fear. So how to do it? One of the suggestions in that article is to let yourself fail. Not to lower your unreasonable standards (the party-line for what to do), but rather to allow yourself to not meet those standards. One of my standards is to be thought provoking, and hence to focus overmuch on essays. To try and break free from this, I'm thinking to start posting summaries of my daily dissertation progress. A nanowrimo sort of thing, though without the focus on word-count per se. I've read a few articles suggesting one should start their day by summarizing the previous day's progress, but I've never tried it. So here goes nothing :)



comments
Categories: Offsite Blogs

PEPM 2017 Call for Papers

haskell-cafe - Thu, 06/23/2016 - 9:16am
CALL FOR PAPERS Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM 2017) http://conf.researchr.org/home/PEPM-2017 Paris, France, January 16th - 17th, 2017 (co-located with POPL 2017) PEPM is the premier forum for discussion of semantics-based program manipulation. The first ACM SIGPLAN PEPM symposium took place in 1991, and meetings have been held in affiliation with POPL every year since 2006. PEPM 2017 will be based on a broad interpretation of semantics-based program manipulation, reflecting the expanded scope of PEPM in recent years beyond the traditionally covered areas of partial evaluation and specialization. Specifically, PEPM 2017 will include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-d
Categories: Offsite Discussion

Disciple/DDC: Type 'Int' does not match type 'Int'

Planet Haskell - Thu, 06/23/2016 - 6:48am
I joke to myself that the last project I complete before I retire will be a book entitled "Anti-patterns in compiler engineering", which will be a complete summary of my career as a computer scientist.

I spent a couple of days last week undoing one particular anti-pattern which was causing bogus error messages like: "Type 'Int' does not match type 'Int'". In DDC the root cause these messages was invariably this data type:
data Bound n
= UIx Int -- An anonymous, deBruijn variable.
| UName n -- A named variable or constructor.
| UPrim n (Type n) -- A primitive value (or type) with its type (or kind).
A value of type Bound n represents the bound occurrence of a variable or constructor, where n is the underlying type used for names. In practice n is often Text or String. The data type has three constructors, UIx for occurrences of anonymous variables, UName for named variables and constructors, and UPrim for names of primitives. We use Bound type for both terms and types.

The intent was that when type checking an expression, to determine the type (or kind) of a Bound thing in UIx or UName form, we would look it up in the type environment. However, as the types (and kinds) of primitives are fixed by the language definition, we would have their types attached directly to the UPrim constructor and save ourselves the cost of environment lookup. For example, we would represent the user defined type constructor 'List' as (UName "List"), but the primitive type constructor 'Int' as (UPrim "Int" kStar), where 'kStar' refers to the kind of data types.

The pain begins the first time you accidentally represent a primitive type constructor in the wrong form. Suppose you're parsing type constructor names from a source file, and happen to represent Int as (UName "Int") instead of (UPrim "Int" kData). Both versions are pretty printed as just "Int", so dumping the parsed AST does not reveal the problem. However, internally in the compiler the types of primitive operators like add and mul are all specified using the (UPrim "Int" kData) form, and you can't pass a value of type (UName "Int") to a function expecting a (UPrim "Int" kData). The the uninformative error message produced by the compiler simply "Type 'Int' does not match type 'Int'", disaster.

The first time this happens it takes an hour to find the problem, but when found you think "oh well, that was a trivial mistake, I can just fix this instance". You move on to other things, but next week it happens again, and you spend another hour -- then a month later it happens again and it takes two hours to find. In isolation each bug is fixable, but after a couple of years this reoccurring problem becomes a noticeable drain on your productivity. When new people join the project they invariably hit the same problem, and get discouraged because the error message on the command line doesn't give any hints about what might be wrong, or how to fix it.

A better way to handle names is to parameterise the data types that represent your abstract syntax tree with separate types for each different sort of name: for the bound and binding occurrences of variables, for bound and binding occurrences of constructors, and for primitives. If the implementation is in Haskell we can use type families to produce the type of each name based on a common index type, like so:
type family BindVar l
type family BoundVar l
type family BindCon l
type family BoundCon l
type family Prim l

data Exp l
= XVar (BoundVar l)
| XCon (BoundCon l)
| XPrim (Prim l)
| XLam (BindVar l) (Exp l)
DDC now uses this approach for the representation of the source AST. To represent all names by a single flat text value we define a tag type to represent this variation, then give instances for each of the type families:
data Flat = Flat

type instance BindVar Flat = Text
type instance BoundVar Flat = Text
type instance BindCon Flat = Text
type instance BoundCon Flat = Text
type instance Prim Flat = Text

type ExpFlat = Exp Flat
On the other hand, if we want a form that allows deBruijn indices for variables, and uses separate types for constructors and primitives we can use:
data Separate = Separate

data Bind = BAnon | BName Text
data Bound = UIx Int | UName Text
data ConName = ConName Text
data PrimName = PrimName Text

type instance BindVar Separate = Bind
type instance BoundVar Separate = Bound
type instance BindCon Separate = ConName
type instance BoundCon Separate = ConName
type instance Prim Separate = PrimName

type ExpSeparate = Exp Separate
It's also useful to convert between the above two representations. We might use ExpSeparate internally during program transformation, but use ExpFlat as an intermediate representation when pretty printing. To interface with legacy code we can also instantiate BoundVar with our old Bound type, so the new generic representation is strictly better than the old non-generic one using a hard-wired Bound.

Compiler engineering is full of traps of representation. Decisions taken about how to represent the core data structures permeate the entire project, and once made are very time consuming to change. Good approaches are also difficult to learn. Suppose we inspect the implementation of another compiler and the developers have set up their core data structures in some particular way. Is it set up like that because it's a good way to do so?, or is it set up like that because it's a bad way of doing so, but now it's too difficult to change? For the particular case of variable binding, using type like Bound above is a bad way of doing it. Using the generic representation is strictly better. Let this be a warning to future generations.
Categories: Offsite Blogs

[oleg.grenrus< at >iki.fi: Re: Easy type-level math]

haskell-cafe - Wed, 06/22/2016 - 7:28pm
Forwarding Oleg's message to the list. ----- Forwarded message from Oleg Grenrus <oleg.grenrus< at >iki.fi> ----- Date: Tue, 21 Jun 2016 05:27:13 +0300 From: Oleg Grenrus <oleg.grenrus< at >iki.fi> To: Lana Black <lanablack< at >amok.cc> Subject: Re: [Haskell-cafe] Easy type-level math X-Mailer: iPhone Mail (13F69) ghc-typelits-natnormalise can dismiss equality constraints, like `n + m ~ m + n`. OP needs to conjure KnownNat dictionary though, and that plugin cannot do. You can do it unsafely and manually with `reifyNat` from `reflections`: http://hackage.haskell.org/package/reflection-2.1.2/docs/Data-Reflection.html - Oleg ----- End forwarded message ----- _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
Categories: Offsite Discussion

User-friendly access to SmallArray# and SmallMutableArray#

libraries list - Wed, 06/22/2016 - 6:01pm
The only user-friendly wrappers I can find for SmallArray# and SmallMutableArray# are in Data.Discrimination.Internal.SmallArray in the discrimination package. What are the chances that we could get something like that in the array package, or possibly some other GHC boot package? I can't use discrimination in containers! David _______________________________________________ Libraries mailing list Libraries< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Categories: Offsite Discussion

How bad would it be for containers to depend on transformers?

libraries list - Wed, 06/22/2016 - 5:58pm
Currently, containers does not depend on transformers, so it has to duplicate its functionality or just do without. Since transformers is also a GHC boot package, I believe it should be feasible to make containers depend on it. To what extent would that reduce parallelizability of GHC builds or otherwise make people mad? David _______________________________________________ Libraries mailing list Libraries< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Categories: Offsite Discussion

Type-class predicates head-normal forms

haskell-cafe - Wed, 06/22/2016 - 6:31am
Hello, I got a question about what the form of types in Haskell are allowed. Specifically, what are the requirements of the context of a type? The paper Typing Haskell in Haskell required the type to be in the form P => t, where P to be in head-normal form or in other words shouldn't be something like Num Bool. Now what about multi-parameter classes? The paper Type classes: an exploration of the design space listed several potential choices but didn't say exactly what. The Haskell 2010 report covered single-parameter type classes only. Given the following definition. class Collects ce e | ce -> e where empty :: ce insert :: e -> ce -> ce insert2 c = insert True (insert False c) The function insert2 has the following type insert2 :: Collects ce Bool => ce -> ce This shows that the definition of head-normal forms for multi-parameter class differs from that for single-parameter classes. Is there any definite specification about the context of Haskell types? Thank you, Sheng _______
Categories: Offsite Discussion

Mark Jason Dominus: The Greek clock

Planet Haskell - Tue, 06/21/2016 - 9:39pm
In former times, the day was divided into twenty-four hours, but they were not of equal length. During the day, an hour was one-twelfth of the time from sunrise to sunset; during the night, it was one-twelfth of the time from sunset to sunrise. So the daytime hours were all equal, and the nighttime hours were all equal, but the daytime hours were not equal to the nighttime hours, except on the equinoxes, or at the equator. In the summer, the day hours were longer and the night hours shorter, and in the winter, vice versa.

Some years ago I suggested, as part of the Perl Quiz of the Week, that people write a greektime program that printed out the time according to a clock that divided the hours in this way. You can, of course, spend a lot of time and effort downloading and installing CPAN astronomical modules to calculate the time of sunrise and sunset, and reading manuals and doing a whole lot of stuff. But if you are content with approximate times, you can use some delightful shortcuts.

First, let's establish what the problem is. We're going to take the conventional time labels ("12:35" and so forth) and adjust them so that half of them take up the time from sunrise to sunset and the other half go from sunset to sunrise. Some will be stretched, and some squeezed. 01:00 in this new system will no longer mean "3600 seconds after midnight", but rather "exactly 7/12 of the way between sunset and sunrise".

To do this, we'll introduce a new daily calendar with the following labels:

Midnight Sunrise Noon Sunset Midnight 00:00 06:00 12:00 18:00 24:00

We'll assume that noon (when the sun is directly overhead) occurs at 12:00 and that midnight occurs at 00:00. (Or 24:00, which is the same thing.) This is pretty close to the truth anyway, although it is screwed up by such oddities as time zones and the like.

On the equinoxes, the sun rises around 06:00 and sets around 18:00, again ignoring time zones and the like. (If you live at the edge of a time zone, especially a large one like U.S. Central Time, local civil noon does not occur at solar noon, so these calculations require adjustments.) On the equinoxes the normal calendar corresponds to the Greek one, because the day and the night are each exactly twelve standard hours long. (The day from 06:00 to 18:00, and the night from 18:00 to 06:00 the following day.) In the winter, the sun rises later and sets earlier; in the summer it rises earlier and sets later. So let's take 06:00 to be the label for the time of sunrise in the Greek clock all year round; 18:00 is similarly the time of sunset in the Greek clock all year round.

With these conventions, it turns out that it's rather easy to calculate the approximate time of sunrise for any day of the year. You need two magic numbers, A and d. The number d is the number of days that have elapsed since the vernal equinox, which is around 19 March (or 19 September, if you live in the southern hemisphere.) The number A is a bit trickier, and I will return to it shortly.

Once you have the two numbers, you just plug into the formula:

The tricky part is the magic number A; it depends on your latitude. At the equator, it is 0. And you can probably calculate it directly from the latitude, if you happen to know your latitude. I do know my latitude (Philadelphia is conveniently located at almost exactly 40° N) but I failed observational astronomy classes twice, so I don't know how to do the necessary calculation.

(Actually it occurs to me now that , should work, where L is the absolute latitude. For the equator (), this gives 0, as it should, and for Philadelphia it gives , which is just about right.)

However, there's another trick you can use even if you don't know your latitude. If you know the time of sunset on the summer solstice, you can calculate A quite easily:

Does that really help? If it were October, it might not. But the summer solstice is today. So all you have to do is to look out the window in the evening and notice when the sun seems to be going down. Then plug the time into the formula. (Or you can remember what happened yesterday, or wait until tomorrow; the time of sunset hardly changes at all this time of year, by only a few seconds per day. Or you could look at the front page of a daily newspaper, which will also tell you the time of sunset.)

The sun went down here around 20:30 today, but that is really 19:30 because of daylight saving time, so we get A = 19:30 - 18:00 = 90 minutes, which happily agrees with the 84.22 we got earlier by a different method. Then the time of sunrise in Philadelphia d days after the vernal equinox is $$\text{Sunrise} = \text{06:00} - 90\text{ min}\cdot \sin {2\pi d\over 365.2422}$$ Today is June 21, which is (counts on fingers) about 31+30+31 = 92 days after the vernal equinox which was around March 21. So notice that the formula above involves because 92 is just about one-fourth of 365.2422—that is, today is just about a quarter of a year after the vernal equinox. So the formula says that sunrise ought to be about 04:30, or, because of daylight saving time, that's 05:30 local civil time. This time of year the night is only 9 standard hours long, so the Greek nighttime hour is standard hours long, or 45 minutes. Right now it's 22:43 daylight time, which is 133 standard minutes past sundown, or just about 3 Greek nighttime hours. So the Greek time is close to 9 PM. In another 2:15 standard hours another 3 Greek hours will have elapsed and it will be Greek midnight; this coincides with standard midnight, which is 01:00 local civil time because of daylight saving.

Here's code for greektime that you can run where you to find out the current Greek time. I hereby place this program in the public domain.

#!/usr/bin/perl # # Calculate local time in fictitious Greek clock # http://blog.plover.com/calendar/Greek-clock.html # Author: Mark Jason Dominus (mjd@plover.com) # This program is in the public domain. # my $PI = atan2(0, -1); use Getopt::Std; my %opt; getopts('l:s:', \%opt) or usage(); my $A; if ($opt{l} =~ /\d/) { $A = 360 * 60 * (1-cos(radians($opt{l}))); } elsif ($opt{s} =~ /:/) { my ($hr, $mn) = split /:/, $opt{s}; $A = (($hr - 18) * 60 + $mn) * 60; } else { usage(); } my $time = time; my $days_since_equinox = ($time - 1047950185)/86400; my $dst = (localtime($time))[9]; my $days_per_year = 365.2422; my $sunrise_adj = $A * sin($days_since_equinox / $days_per_year * 2 * $PI ); my $length_of_daytime = 12 * 3600 + 2 * $sunrise_adj; my $length_of_nighttime = 12 * 3600 - 2 * $sunrise_adj; my $time_of_sunrise = 6 * 3600 - $sunrise_adj; my $time_of_sunset = 18 * 3600 + $sunrise_adj; my ($gh, $gm) = time_to_greek($time); my ($h, $m) = (localtime($time))[2,1]; printf "Standard: %2d:%02d\n", $h, $m; printf " Greek: %2d:%02d\n", $gh, $gm; sub time_to_greek { my ($epoch_time) = shift; my $time_of_day; { my ($h, $m, $s, $dst) = (localtime($epoch_time))[2,1,0,8]; $time_of_day = ($h-$dst) * 3600 + $m * 60 + $s; } my ($greek, $hour, $min); if ($time_of_day < $time_of_sunrise) { # change early morning into night $time_of_day += 24 * 3600; } if ($time_of_day < $time_of_sunset) { # day my $diff = $time_of_day - $time_of_sunrise; $greek = 6 + ($diff / $length_of_daytime) * 12; } else { # night my $diff = $time_of_day - $time_of_sunset; $greek = 18 + ($diff / $length_of_nighttime) * 12; } $hour = int($greek); $min = int(60 * ($greek - $hour)); ($hour, $min); } sub radians { my ($deg) = @_; return $deg * 2 * $PI / 360; } sub usage { print STDERR "Usage: greektime [ -l latitude ] [ -s summer_solstice_sunset ] One of latitude or sunset time must be given. Latitude should be in degrees north of the equator. (Negative for southern hemisphere) Sunset time should be given in the form '19:37' in local STANDARD time. (Southern hemisphere should use the WINTER solstice.) "; exit 2; } This article has been in the works since January of 2007, but I missed the deadline on 18 consecutive solstices. The 19th time is the charm!

Categories: Offsite Blogs

14th ACM MobiWac 2016, MALTA

General haskell list - Tue, 06/21/2016 - 8:22pm
** We apologize if you receive multiple copies of this message ** ================================================================== The 14th ACM International Symposium on Mobility Management and Wireless Access (MobiWac 2016) November 13 - 17, 2016 - Malta http://mobiwac-symposium.org/ ================================================================== The MOBIWAC series of event is intended to provide an international forum for the discussion and presentation of original ideas, recent results and achievements by researchers, students, and systems developers on issues and challenges related to mobility management and wireless access protocols. To keep up with the technological developments, we also open up new areas such as mobile cloud computing starting from this year. Authors are encouraged to submit both theoretical and practical results of significance on all aspects of wir
Categories: Incoming News

Programming in Haskell - 2nd Edition

haskell-cafe - Tue, 06/21/2016 - 3:05pm
Dear all, I'm delighted to announce that the 2nd edition of Programming in Haskell will be published in August 2016! The new edition has been extensively updated and expanded to include recent and more advanced features of Haskell, new examples and exercises, selected solutions, and freely downloadable lecture slides and example code. Further details, including how to preorder and obtain inspection copies, are provided below. Best wishes, Graham ================================================================= *** BOOK ANNOUNCEMENT *** Programming in Haskell - 2nd Edition Graham Hutton, University of Nottingham Cambridge University Press, August 2016 320 pages, 120 exercises, ISBN 9781316626221 http://tinyurl.com/PIH-2e ================================================================= DESCRIPTION: Haskell is a purely functional language that allows programmers to rapidly develop clear, concise, and correct software. The language has grown in popularity in recent years, both in teaching and in
Categories: Offsite Discussion

Programming in Haskell - 2nd Edition

General haskell list - Tue, 06/21/2016 - 3:04pm
Dear all, I'm delighted to announce that the 2nd edition of Programming in Haskell will be published in August 2016! The new edition has been extensively updated and expanded to include recent and more advanced features of Haskell, new examples and exercises, selected solutions, and freely downloadable lecture slides and example code. Further details, including how to preorder and obtain inspection copies, are provided below. Best wishes, Graham ================================================================= *** BOOK ANNOUNCEMENT *** Programming in Haskell - 2nd Edition Graham Hutton, University of Nottingham Cambridge University Press, August 2016 320 pages, 120 exercises, ISBN 9781316626221 http://tinyurl.com/PIH-2e ================================================================= DESCRIPTION: Haskell is a purely functional language that allows programmers to rapidly develop clear, concise, and correct software. The language has grown in popularity in recent years, both in teaching and in
Categories: Incoming News

Haskell Developer Position at Scrive

General haskell list - Tue, 06/21/2016 - 12:53pm
Hi, Cross-posting from StackOverflow [1] and Reddit [2]. We have a job opportunity at Scrive [3]. The company is based in Stockholm, Sweden, but the business is global and working in the Stockholm office is optional as most of the development team is working remotely already. We are looking for someone in GMT±3 to be reachable during CET/CEST office hours. Feel free to ask me questions. Applications on StackOverflow please (best apply by July 24th). Thanks. [1] https://stackoverflow.com/jobs/118855/haskell-backend-developer-scrive [2] https://www.reddit.com/r/haskell/comments/4p3s00/haskell_developer_position_at_scrive/ [3] https://stackoverflow.com/jobs/companies/scrive PS. Hope mailing the list is appropriate, I subscribe on my private account and have seen postings before. Cheers!
Categories: Incoming News

WFLP 2016 - Final Call for Papers

General haskell list - Tue, 06/21/2016 - 11:49am
Register an abstract within the next 48 hours, and a full paper, work-in-progress report or system description 7 days later! *********************************************************** 24th International Workshop on Functional and (Constraint) Logic Programming (WFLP 2016) https://wflp2016.github.io/ September 13-14, part of the Leipzig Week of Declarative Programming (L-DEC 2016) Formal proceedings will be published by EPTCS (http://www.eptcs.org/). Both full technical papers and less formal work-in-progress report submissions are welcome, as are system descriptions. More details below and on the web page. *********************************************************** Deadlines: * abstract submission: June 22, 2016 (extended) * paper submission: June 29, 2016 (extended) * notification: July 15, 2016 * camera-ready (workshop) version due: August 10, 2016 Submissions can be directly accepted for publication in the formal EPTCS proceedings, or accepted for presentation at the workshop and invited to ano
Categories: Incoming News

Brent Yorgey: Any clues about this Newton iteration formula with Jacobian matrix?

Planet Haskell - Tue, 06/21/2016 - 10:35am

A while ago I wrote about using Boltzmann sampling to generate random instances of algebraic data types, and mentioned that I have some code I inherited for doing the core computations. There is one part of the code that I still don’t understand, having to do with a variant of Newton’s method for finding a fixed point of a mutually recursive system of equations. It seems to work, but I don’t like using code I don’t understand—for example, I’d like to be sure I understand the conditions under which it does work, to be sure I am not misusing it. I’m posting this in the hopes that someone reading this may have an idea.

Let be a vector function, defined elementwise in terms of functions :

where is a vector in . We want to find the fixed point such that .

The algorithm (you can see the code here) now works as follows. First, define as the Jacobian matrix of partial derivatives of the , that is,

Now let and let be the identity matrix. Then for each define

and also

Somehow, magically (under appropriate conditions on , I presume), the sequence of converge to the fixed point . But I don’t understand where this is coming from, especially the equation for . Most generalizations of Newton’s method that I can find seem to involve multiplying by the inverse of the Jacobian matrix. So what’s going on here? Any ideas/pointers to the literature/etc?


Categories: Offsite Blogs

[Caml-list] Call for contribution, PLRR 2016 (Parametricity, Logical Relations & Realizability), EXTENDED DEADLINE

General haskell list - Tue, 06/21/2016 - 9:45am
LAST CALL FOR CONTRIBUTIONS EXTENDED DEADLINE Workshop PLRR 2016 Parametricity, Logical Relations & Realizability September 2, Marseille, France http://lama.univ-savoie.fr/plrr2016 Satellite workshop - CSL 2016 http://csl16.lif.univ-mrs.fr/ BACKGROUND The workshop PLRR 2016 aims at presenting recent work on parametricity, logical relations and realizability, and encourage interaction between those communities. The areas of interest include, but are not limited to: * Kleene's intuitionistic realizability, * Krivine's classical realizability, * other extensions of the Curry-Howard correspondence, * links between forcing and the Curry-Howard correspondence, * parametricity, * logical relations, * categorical models, * applications to programming languages. INVITED SPEAKERS Neil Ghani (University of Strathclyde) Nick Benton (Microsoft Research, Cam
Categories: Incoming News

Haskell eXchange 2016 - call for contributions

General haskell list - Tue, 06/21/2016 - 9:32am
Hi everyone. The 5th edition of the Haskell eXchange is going to take place on October 6 and 7 in London, and we are still looking for contributions on all aspects of Haskell (and related programming languages). It does not matter whether you are going to present your own project or want to explain someone else's work. Talks can be about expert topics, but we also particularly invite talks aimed at beginners. You can offer short talks, normal talks or hands-on tutorials. The topic can range from purely theoretical research to practical experience reports, or even be something that we would never have thought about ... Please check https://skillsmatter.com/conferences/7276-haskell-exchange-2016 for more detailed information as well as the submission page. The deadline is soon: 30 June 2016. Registration is also open. Cheers, Andres _______________________________________________ Haskell mailing list Haskell< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Categories: Incoming News

Functional Jobs: Haskell Software Engineer at Wrinkl, Inc. (Full-time)

Planet Haskell - Tue, 06/21/2016 - 8:54am

Based in New York City, Wrinkl, Inc. is a next generation SaaS communication platform. Wrinkl is a well-funded startup company with an innovative approach that has received interest from Fortune 500 companies and industry thought leaders. The company’s co-founders each have 30+ years of experience as successful entrepreneurs and in private equity and M&A. Wrinkl has assembled a group of sophisticated investors, advisors and potential beta partners who are committed to success.

Currently, Wrinkl is working with Obsidian Systems, a leading Haskell software consulting company that uses a combination of cutting-edge and tried-and-true technologies to build custom software solutions, which range from seed-stage startups to multinational corporations. Wrinkl’s technology stack is based on Haskell, Reflex and Reflex-DOM, GHCJS, NixOS, PostgresSQL and AWS. Wrinkl is looking to hire experienced and capable Haskell developers to initially work with Obsidian Systems and to be the core on which our in-house technology development team is built.

Wrinkl is building a world-class team that enjoys an intellectually challenging and high-energy environment. We want developers who are fully invested, enthusiastic and take great pride in their work. Wrinkl also fully appreciates the need to live a balanced life and values productive output over face time.

While we are located in New York City, and we will be hiring people locally, remote work is also available. If you are highly proficient with front-end and/or back-end architecture and have a passion for innovation, we would love to tell you more about our exciting opportunity.

Wrinkl provides its developers a competitive compensation package, including cash, equity and health care coverage.

Positions:

Haskell Developers with experience working on Haskell web and mobile applications. You’ll be working with a team of developers on all levels of our full-stack functional application. Our developers work in quick iterations to build complete features (from database to frontend) with a focus on quality, maintainability, and performance.

Chief Technology Officer with a successful history in managing a development team, specifically for mobile and web apps. The CTO will collaborate closely with the founders to co-create the product and technology strategy, staffing model and delivery plans to realize the full potential of the business. This responsibility includes the planning, development, and implementation of Wrinkl’s application architecture, technology stack and product experience on various platforms including desktop, mobile and native applications (iOS and Android).

Get information on how to apply for this position.

Categories: Offsite Blogs

Help with triple stack monad

haskell-cafe - Tue, 06/21/2016 - 7:12am
Hi, I was expanding on my earlier learning, to try a triple monad stack: {-# LANGUAGE GeneralizedNewtypeDeriving #-} <...snip...> import System.Random import Control.Monad.Random import Control.Monad.State.Lazy import Control.Monad.Reader newtype ReaderStateRandom r s g a = RSR { rSR :: ReaderT r (StateT s (Rand g)) a } deriving (Monad, MonadReader r, MonadState s) However, it seems that I must implement MonadRandom myself, as there is no instance for this sort of arrangement already. Probably this is trivial, but I'm having trouble wrapping my mind around how to do it. Would anybody perhaps assist me in implementing one function, to help guide me in the correct direction? instance MonadRandom (ReaderStateRandom r s g) where getRandom = ...?
Categories: Offsite Discussion

Philip Wadler: Brexit is a fake revolt – working-class culture is being hijacked to help the elite

Planet Haskell - Tue, 06/21/2016 - 5:36am

What dismays me most about the EU debate is that what people say it is about and what it is really about are quite different. Paul Mason in the Guardian analyses the problem clearly.
To people getting ready for the mother of all revolts on Thursday, I want to point out the crucial difference between a real revolt and a fake one. The elite does not usually lead the real ones. In a real revolt, the rich and powerful usually head for the hills, terrified. Nor are the Sun and the Daily Mail usually to be found egging on a real insurrection. ...

I want to have one last go at convincing you that leaving now, under these conditions, would be a disaster. First, let’s recognise the problem. For people in the working classes, wages are at rock bottom. Their employers treat them like dirt. Their high streets are lined with empty shops. Their grownup kids cannot afford to buy a home. Class sizes at school are too high. NHS waiting times are too long. ...

But a Brexit led by Ukip and the Tory right will not make any of these things better: it will make them worse. Take a look at the people leading the Brexit movement. Nigel Farage, Neil Hamilton, Boris Johnson, Michael Gove. They have fought all their lives for one objective: to give more power to employers and less to workers. Many leading Brexiters are on record as wanting to privatise the NHS. They revelled in the destruction of the working-class communities and cultures capable of staging real revolt. Sir James Dyson moved his factory to Malaysia, so much did he love the British workforce. They talk about defying the “elite”. But they are the elite.
Categories: Offsite Blogs