[Haskell] Nominations close Jan 11th for the Haskell Foundation Board

[Simon Peyton Jones via Haskell]

Friends
Happy new year!
The closing date for self-nominations for membership of the Board of the 
Haskell Foundation<https://haskell.foundation/> is in just under a week:
Monday January 11th 2021

The Haskell Foundation is a new non-profit organisation that seeks to 
articulate the benefits of functional programming to a broader audience, to 
erase barriers to entry, and to support Haskell as a solidly reliable basis for 
mission-critical applications.

The Board provides the strategic leadership for the Foundation, including its 
goals, governance, finances, and staff.  Membership of the Board is a key 
leadership role, not an honorary appointment.

The Call for Nominations<https://haskell.foundation/board-nominations/> gives 
more details.  Please do consider nominating yourself, or encouraging a 
suitable (but perhaps modest) colleague to do so.  The HF needs a strong Board, 
and that means strong nominations.

Thanks!  Please do forward this message on social media or elsewhere.

Simon Peyton Jones



___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] Guidelines for respectful communication

[Simon Peyton Jones via Haskell]

Friends
As many of you will know, I have been concerned for several years about the 
standards of discourse in the Haskell community.  I think things have improved 
since the period that drove me to write my Respect 
email, 
but it's far from secure.
We discussed this at a meeting of the GHC Steering 
Committee at ICFP in September, 
and many of us have had related discussions since.  Arising out of that 
conversation, the GHC Steering Committee has decided to adopt these
  Guidelines for respectful 
communication

We are not trying to impose these guidelines on members of the Haskell 
community generally. Rather, we are adopting them for ourselves, as a signal 
that we seek high standards of discourse in the Haskell community, and are 
willing to publicly hold ourselves to that standard, in the hope that others 
may choose to follow suit.
We are calling them "guidelines for respectful communication" rather than a 
"code of conduct", because we want to encourage good communication, rather than 
focus on bad behaviour.  Richard Stallman's recent 
post about the new GNU Kind Communication 
Guidelines expresses the 
same idea.
Meanwhile, the Stack community is taking a similar 
approach.
Our guidelines are not set in stone; you can comment 
here.
   Perhaps they can evolve so that other Haskell committees (or even 
individuals) feel able to adopt them.
The Haskell community is such a rich collection of intelligent, passionate, and 
committed people. Thank you -- I love you all!
Simon



<>___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] Summit on Advances in Programming Languages 2019

[Simon Peyton Jones via Haskell]

Haskellers
The Summit oN Advances in Programming 
Languages (SNAPL) is a biennial venue for 
discussions about programming languages. SNAPL focuses on experience-based 
insight, innovation, and visionary ideas spanning from foundations to 
applications of programming languages. SNAPL welcome perspectives from both 
industry and academia.
Ras Bodik and Shriram Krishnamurthi are looking for community input in where 
and when to hold SNAPL 2019, and how long it should be.
Here is their survey.  Do consider 
making your views known to them.
Simon


<>___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] Postdoc and internship opportunities at Microsoft Research Cambridge

[Simon Peyton Jones via Haskell]

Microsoft Research Cambridge seeks

  *   Up to two post docs
  *   At least one intern
to do research in the general area of spreadsheet technology and usability.
We work in deep collaboration with the Excel team in Microsoft Office on 
Project<https://www.microsoft.com/en-us/garage/wall-of-fame/new-data-types-in-excel/>
 
Yellow<https://www.linkedin.com/feed/update/urn:li:activity:6427691426989121536/>,
 bringing new data types and other features to Excel.
Please see https://aka.ms/CalcIntel for details.
Applications deadline for the postdoc position is 1st of December 2018.
Informal enquiries to Andy Gordon a...@microsoft.com or Simon Peyton Jones 
simo...@microsoft.com

___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Treatment of unknown pragmas

[Simon Peyton Jones via Haskell]

I rather agree.

We don't even need a convention do we?  /Any/ comment in {- -} is ignored
by GHC /except/ {-# ... #-}.  So tool users are free to pick whatever
convention they like to identify the stuff for their tool.

Simon

| -Original Message-
| From: ghc-devs  On Behalf Of Ben Gamari
| Sent: 16 October 2018 18:51
| To: GHC developers ; haskell@haskell.org
| Subject: Treatment of unknown pragmas
| Hi everyone,
| 
| Recently Neil Mitchell opened a pull request [1] proposing a single-line
| change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the
| lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the
| lexer for every tool that wants a pragma seems quite unsustainable.
| 
| On the other hand, a reasonable counter-argument could be made on the
| basis of the Haskell Report, which specifically says that
| implementations should ignore unrecognized pragmas. If GHC did this
| (instead of warning, as it now does) then this wouldn't be a problem.
| 
| Of course, silently ignoring mis-typed pragmas sounds terrible from a
| usability perspective. For this reason I proposed that the following
| happen:
| 
|  * The `{-# ... #-}` syntax be reserved in particular for compilers (it
|largely already is; the Report defines it as "compiler pragma"
|syntax). The next Report should also allow implementations to warn in
|the case of unrecognized pragmas.
| 
|  * We introduce a "tool pragma" convention (perhaps even standardized in
|the next Report). For this we can follow the model of Liquid Haskell:
|`{-@ $TOOL_NAME ... @-}`.
| 
| Does this sound sensible?
| 
| Cheers,
| 
| - Ben
| 
| 
| [1] https://github.com/ghc/ghc/pull/204
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] The Haskell Report: who maintains it?

[Simon Peyton Jones via Haskell]

Friends

Does anyone know who, if anyone, feels responsible for committing updates to 
the Haskell 2010 Report?

Who even has commit rights?

There’s Frank’s pull request below, and I have another important typo to fix.

Thanks

Simon

From: Frank Steffahn [mailto:notificati...@github.com]
Sent: 11 March 2018 17:03
To: haskell/haskell-report 
Cc: Subscribed 
Subject: [haskell/haskell-report] Fix a typo in: Semantics of Case Expressions, 
Part 3 (s) (#4)


Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / 
mistake. I’m not 100% sure if this is the right branch (or even in general the 
right place) to note this, but I hope it will get fixed ;-)

This seems like it is an artifact of copy-and-pasting from “Semantics of Case 
Expressions, Part 1 (c)” without properly adapting the thing, especially in 
commit 
bc94554.


You can view, comment on, or merge this pull request online at:

  
https://github.com/haskell/haskell-report/pull/4

Commit Summary

  *   Fix a typo in: Semantics of Case Expressions, Part 3 (s)

File Changes

  *   M 
report/exps.verb
 (1)

Patch Links:

  *   
https://github.com/haskell/haskell-report/pull/4.patch
  *   
https://github.com/haskell/haskell-report/pull/4.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on 
GitHub,
 or mute the 
thread.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] SLURP: a single unified registry for Haskell packages

[Simon Peyton Jones via Haskell]

Friends

Hackage has been extraordinarily successful as a single repository through 
which to share Haskell packages. It has supported the emergence of variety of 
tools to locate Haskell packages, build them and install them (cabal-install, 
Stack, Nix, ...). But in recent years there has been increasing friction over,

  *   Hackage's policies, especially concerning version bounds;
  *   Hackage's guarantees, especially around durability of package content and 
metadata;
  *   Hackage's features, especially the visual presentation and package 
documentation.

If we do not resolve this friction, it seems likely that the Haskell library 
ecosystem will soon "fork", with two separate repositories, one optimised for 
Cabal and one for Stack. This would be extremely counter-productive for Haskell 
users.

Thus motivated, over the last few months we have talked a lot to colleagues, 
including ones in the Hackage and Stack communities. We have emerged with 
SLURP, a proposal that could go a long way towards supporting the upsides of a 
diverse ecosystem, without the sad downsides of forking into mutually-exclusive 
sub-communities.

Here is the SLURP 
proposal<https://github.com/simonmar/ecosystem-proposals/blob/slurp/proposals/-slurp.rst>.
 We invite the Haskell community to debate it.

SLURP is meant to enable both Hackage and Stackage (and perhaps more services 
in the future) to in the future make choices autonomously without hurting other 
package services. But it will only work if the implementors of both Hackage and 
Stackage are willing to participate. We respect their autonomy in this matter, 
but we urge them to give this proposal serious consideration in the best 
interests of the community and Haskell's success. We have carefully designed 
SLURP to be as minimal and non-invasive as possible, so that it can be adopted 
without much trouble. Of course, we are open to debate about the specific 
details.

We do have an offer from someone willing to implement SLURP.

We also strongly urge members of the community to express clear views about the 
importance --- or otherwise --- of adopting something like SLURP. You are, 
after all, the community that GHC, Hackage, Stackage, Cabal, etc are designed 
to serve, so your views about what best meets your needs are critically 
important.

Mathieu Boespflug (@mboes<https://github.com/boes>)
Manuel Chakravarty (@mchakravarty<https://github.com/mchakravarty>)
Simon Marlow (@simonmar<https://github.com/simonmar>)
Simon Peyton Jones (@simonpj<https://github.com/simonpj>)
Alan Zimmerman (@alanz<https://github.com/alanz>)

___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] A small milestone

[Simon Peyton Jones via Haskell]

Hmm.  Maybe 1987 was thirty years ago, not forty.  Clearly old age saps one’s 
mental arithmetic.  Best to read the 
paper<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fpublication%2Fa-history-of-haskell-being-lazy-with-class%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4d7a883633f4bc5be7308d55e975753%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518926451639509&sdata=PIKf6Tp95N2w%2F%2BwnQwyLNkuoIP5p%2F%2FofI%2B7eAccJnJM%3D&reserved=0>
 😊.
Simon
From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Simon 
Peyton Jones via Haskell-Cafe
Sent: 18 January 2018 17:14
To: haskell@haskell.org; Haskell Cafe 
Subject: [Haskell-cafe] A small milestone

Cherished friends
Today is my sixtieth birthday.
It is just over forty thirty years since Phil and I called in at Yale on my way 
to FPCA, and floated the idea of Haskell with Paul 
Hudak<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fresearch%2Fpublication%2Fa-history-of-haskell-being-lazy-with-class%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4d7a883633f4bc5be7308d55e975753%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518926451639509&sdata=PIKf6Tp95N2w%2F%2BwnQwyLNkuoIP5p%2F%2FofI%2B7eAccJnJM%3D&reserved=0>.
  (It wasn’t called Haskell then, of course.)   Rather a lot of water has 
flowed under the bridge since then.  GHC’s bug tracker is up to 14,683 tickets; 
 I have read every one of them.
But the best thing is Haskell’s rich community of smart, motivated, passionate, 
and friendly colleagues.  There was a time when I knew every Haskell programmer 
on the planet, but we are far, far beyond that point.  Now it’s beyond me even 
to keep up with the huge wave of elegant and creative ideas, tools, libraries, 
and blog posts that you generate.   (Kudos to Taylor – and doubtless other 
colleagues -- for the Haskell Weekly 
News<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhaskellweekly.news%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4d7a883633f4bc5be7308d55e975753%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636518926451639509&sdata=dIrK%2FTAR35aPdiqWiiLWx3VxEpnZxONI%2FX%2Bbdz0dXA0%3D&reserved=0>,
 which I love.)   But despite its size, it’s a community that is still 
characterised by a love of elegance, and a desire to distil the essence of an 
idea and encapsulate it in an abstraction, all tempered with respect and 
tolerance. We don’t always live up to these ideals, but by and large we do.
Thank you all.  Onward and upward!
Simon
PS: as birthday recreation I’m working on 
https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] A small milestone

[Simon Peyton Jones via Haskell]

Cherished friends
Today is my sixtieth birthday.
It is just over forty years since Phil and I called in at Yale on my way to 
FPCA, and floated the idea of Haskell with Paul 
Hudak.
  (It wasn't called Haskell then, of course.)   Rather a lot of water has 
flowed under the bridge since then.  GHC's bug tracker is up to 14,683 tickets; 
 I have read every one of them.
But the best thing is Haskell's rich community of smart, motivated, passionate, 
and friendly colleagues.  There was a time when I knew every Haskell programmer 
on the planet, but we are far, far beyond that point.  Now it's beyond me even 
to keep up with the huge wave of elegant and creative ideas, tools, libraries, 
and blog posts that you generate.   (Kudos to Taylor - and doubtless other 
colleagues -- for the Haskell Weekly News, which I 
love.)   But despite its size, it's a community that is still characterised by 
a love of elegance, and a desire to distil the essence of an idea and 
encapsulate it in an abstraction, all tempered with respect and tolerance. We 
don't always live up to these ideals, but by and large we do.
Thank you all.  Onward and upward!
Simon
PS: as birthday recreation I'm working on 
https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] Respect

[Simon Peyton Jones via Haskell]

Friends

One of the most precious attributes of the Haskell community over the last 
twenty-five years has been its supportive, friendly, and respectful dialogue. 
People have often drawn attention to this, and I have always felt good about 
it.  (A great example is this hilarious exchange [1], which I came across in 
the wonderful but sadly-in-abeyance Haskell Weekly News).  As I write this post 
I am travelling back from ICFP where the same high standards of discourse 
prevail.  People certainly ask searching questions, but they do so as critical 
friends, not hostile adversaries. 

There's no denying that our shared dialogue as a community has taken a 
nose-dive in the last few months.  If this change of tone becomes established 
as a norm, I believe it will corrode our common life, perhaps permanently, and 
harm our shared purpose. I would be heartbroken if that happened. 

Underlying these exchanges there are strong differences of opinion.  Some are 
technical judgements; others are to do with an assessment of what will be most 
helpful to new users.  These are matters about which reasonable, thoughtful 
people can differ.  But in a community in which I believe that everyone is 
passionately motivated to do the Right Thing, I am certain that we can debate 
those differences in a more constructive way. 

In writing this post, I am not seeking to discourage open debate, or 
expressions of concern.  It's worth separating two things

  1. Publicly debating an issue where judgements differ
  2. Using offensive or adversarial language in that debate

It's fine to respectfully disagree with someone's judgement (i.e. 1).  It's 
/not/ fine to imply that they have hidden (and bad) motives, or declare them 
incompetent or deliberately obtuse (i.e. 2).  This has no place in our public 
conversations.   The trickier the issue, the more careful we should be to 
express ourselves in a way that is respectful, and is visibly grounded in the 
assumption that the other person is acting in good faith.

I not attributing blame.  There is no idle malice here, nor thoughtless 
trolling.  It's no good each of us pointing the finger elsewhere: our shared 
conversation is our shared responsibility. 

Nor am I trying to paper over the cracks, and pretend everything will be ok if 
we are just polite to each other.  There are significant underlying technical 
disagreements, bruised feelings, frustration, and some anger.   So there is 
work to do together, and I'm in active conversation some of with the main 
protagonists, working on some concrete steps forward. More on that anon, I hope.

Meanwhile, I am asking -- begging actually -- that we work on these issues 
using language that is respectful of others, that celebrates the work of both 
volunteers and companies, and that assumes that our dialogue partners are 
acting from the best of intentions.

Simon

[1] https://gist.github.com/quchen/5280339

___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Haskell-cafe] ANN: Creation of Haskell-Community list for Haskell.org Community Infrastructure Discussions

[Simon Peyton Jones]

|  But this leaves open people wondering what those discussions are. And
|  it also leaves open where the *designated place* to discuss
|  haskell.org community infrastructure is. The haskell-infrastructure
|  [2] list is very quiet and really about technical considerations.
|  Meanwhile, -cafe, reddit and so forth are about anything and
|  everything. So we created another list, which will be a place where we
|  seek to have our discussions related to plans for haskell.org
|  committee work, and where we invite everyone to join us.

I think this is terrific, thanks Gershom.  Just to be clear, as I understand 
it, the intent is to broaden participation in the work of the haskell.org 
committee (which is our only single point of confluence covering the entire 
Haskell community) by making its discussions by-default open to everyone to 
join in.  Specifically:

* Anyone can write to the haskell-community list.

* Haskell.org committee members commit to reading the haskell-community
  list and writing to it.  That is, it's not a side-show.  The way to
  bring something to the attention of the committee (and the wider 
  community) is to write to the list.

* Discussion among haskell.org committee members takes place, by default,
  on the new, public, haskell-community mailing list.  (There is still a
  private list for members, but it is used only when there is a particular
  reason for not conducting a conversation in public; for example when
  debating nominations for new members of the committee.)

Perhaps it'd be worth adding a sub-section on 
https://wiki.haskell.org/Haskell.org_committee just to make these points?

Simon

|  -Original Message-
|  From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf
|  Of Gershom B
|  Sent: 08 September 2015 22:59
|  To: haskell-cafe; haskell@haskell.org; haskell-
|  infrastruct...@community.galois.com; haskell-commun...@haskell.org
|  Subject: [Haskell-cafe] ANN: Creation of Haskell-Community list for
|  Haskell.org Community Infrastructure Discussions
|  
|  Dear all,
|  
|  The haskell.org committee [1] had a productive week during ICFP, and
|  at some point we'll try to write up some of the small things underway
|  and future plans -- many things are quite tentative at the moment.
|  
|  However, one thing that became clear to us (well, thanks to the useful
|  prodding of SPJ) is that we have historically participated in
|  discussions in other venues (-cafe, reddit, etc) and then had our own
|  internal discussions (few, seldom, and largely organizational to be
|  honest) on the low-traffic committee [at] haskell.org mail alias.
|  
|  But this leaves open people wondering what those discussions are. And
|  it also leaves open where the *designated place* to discuss
|  haskell.org community infrastructure is. The haskell-infrastructure
|  [2] list is very quiet and really about technical considerations.
|  Meanwhile, -cafe, reddit and soforth are about anything and
|  everything. So we created another list, which will be a place where we
|  seek to have our discussions related to plans for haskell.org
|  committee work, and where we invite everyone to join us.
|  
|  This new list is the haskell-community list:
|  https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community
|  
|  The committee alias will still work, and is still the way to just
|  write directly to the members of the committee -- no list to join. But
|  if you wish to have a discussion about how we have things set up on
|  haskell community infrastructure, services provided, and that we might
|  wish to add, and how you can help (or even just what your thoughts are
|  on how things might be done), now there is a good place for that.
|  
|  Hope to continue conversations with many of you there, Gershom (for
|  the haskell.org committee)
|  
|  [1] https://wiki.haskell.org/Haskell.org_committee
|  [2] http://community.galois.com/mailman/listinfo/haskell-
|  infrastructure
|  ___
|  Haskell-Cafe mailing list
|  haskell-c...@haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] GHC 7.10 will use Plan FTP

[Simon Peyton Jones]

Colleagues
You will remember (see this 
email<https://mail.haskell.org/pipermail/libraries/2015-February/024925.html>) 
that the Haskell community has been engaged in a debate about proposed changes 
to the Haskell Prelude, the Plan-List or Plan-FTP 
debate<https://ghc.haskell.org/trac/ghc/wiki/Prelude710>.   We decided to hold 
an open survey to get feedback from the community.  Simon Marlow and Simon PJ 
were asked to make a decision in the light of that feedback.  The survey closed 
on 21 Feb, so it's time to decide.
Bottom line: we recommend Plan FTP.
There are strong arguments in both directions.  For the record, our own 
personal instincts were both in the conservative, Plan List direction.  But the 
survey gave some pretty compelling feedback, and was far more unequivocal than 
we expected.
Some details

*   Over 800 people participated in the survey. That's a lot for an 11-day 
window. Many wrote several paragraphs of supporting information.  Thank you for 
participating so actively!

*   Overall, 82% of respondents were in favour of FTP, a 4:1 majority.  
Simon and I found this level of unanimity quite surprising - and it made our 
task much easier.  We clearly under-estimated the Haskell community's appetite 
for absorbing change when they approve of the direction of travel.

*   Herbert helped us by doing a rough categorisation into 
hobbyist/non-hobbyist responses.

o   The first interesting fact is that there were a lot of non-hobbyist 
responses: in fact a majority (58%) of the responses were from non-hobbyists.  
So increasingly people are using Haskell for real work.

o   The support for Plan FTP among hobbyists was overwhelming (over 87%).  But 
it was still very strong indeed among non-hobbyists (over 79%).

Caveat: time was short, so the hobby/non-hobby categorisation is extremely 
approximate.  But since the results are so unambiguous, even the crude results 
are helpful.

*   We tried filtering out responses that were blank in the name field and 
both text boxes.  The 82% majority did not budge.
What happens now

*   GHC 7.10 will embody Plan FTP.

*   The Core Libraries committee, freshly energised and informed by this 
episode, is drafting new guidelines to clarify what it does, and how it works; 
and to help avoid a repetition of the recent drama.

*   The responses.  In the survey we said "We won't publish either textual 
responses or personally-identifying information without your consent. The full 
responses will be made available only to a limited few."   However, the 
English-language comments are a remarkable snapshot of the Haskell community, 
and it would be a shame to discard them without deeper study.  We propose to 
make them available to the Core Libraries Committee, to inform their future 
choices.

If anyone else wants to digest the comments into a summary report, we think 
that would be a service to the community, and (in our view, provided they are a 
reputable person etc) would fall under the "available to a limited few" rubric. 
 If that appeals to you, write to us.

If you object even to such limited sharing, write to us too.
This wasn't an entirely easy process, especially because it happened so late in 
the release cycle.  But although many people felt quite strongly about List vs 
FTP, the whole debate has involved light rather than heat; people have 
concentrated on the technical issues, rather than yelling.  Overall, it's been 
very encouraging to see the resilience, transparency, and constructive tone of 
the community.  We really appreciate that - thank you.
Simon Marlow and Simon Peyton Jones

___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] Rank-N types with (.) composition

[Simon Peyton Jones]

($) has its own *typing rule*; it does not have a special type.  It's very ad 
hoc, but ($) is used so much to decrease parens that (e1 $ e2) is almost 
special syntax!

At the moment the *only* robust way to pass a polymorphic function to a 
polymorphic function (here, you are passing Wrap to (.)) is to wrap it in a 
newtype, much as Wrap does.

I have made several forays into the impredicative swamp, and barely made it 
back to the shore alive.  I think that, at least in the context of Haskell, the 
trick is to be less ambitious, something like QML.

Since this comes up regularly, I've started a wiki page to explain the issues:
  https://ghc.haskell.org/trac/ghc/wiki/ImpredicativePolymorphism

Please do improve it.

Simon



|  -Original Message-
|  From: Haskell [mailto:haskell-boun...@haskell.org] On Behalf Of Tyson
|  Whitehead
|  Sent: 10 February 2015 23:20
|  To: Dan Doel
|  Cc: haskell@haskell.org
|  Subject: Re: [Haskell] Rank-N types with (.) composition
|  
|  On February 10, 2015 16:28:56 Dan Doel wrote:
|  > Impredicativity, with regard to type theories, generally refers to
|  > types being able to quantify over the collection of types that they
|  > are then a part of. So, the judgment:
|  >
|  > (forall (a :: *). a -> a) :: *
|  >
|  > is impredicative, because we have a type in * that quantifies over
|  all
|  > types in *, which includes itself. Impredicativity in general refers
|  > to this sort of (mildly) self-referential definition.
|  
|  Thanks Dan and David,
|  
|  That was informative.  Also very interesting that ($) is a special
|  case.  I tried this
|  
|   newtype Wrap = Wrap { extract :: forall f. Functor f => f Int }
|  
|   trip'' :: Wrap -> Wrap
|   trip'' a = Wrap $ extract a
|  
|  and the compiler was happy.  Wrapping ($) as ($') gave an error as you
|  implied it would
|  
|   trip''' :: Wrap -> Wrap
|   trip''' a = Wrap $' extract a
|   where ($') = ($)
|  
|  With regard to my earlier comment about translating the (.) version
|  
|   trip' :: Wrap -> Wrap
|   trip' = Wrap . extract
|  
|  to core, I can see it's actually okay.  A most you may need is a
|  lambda to float the implicit parameters backwards
|  
|   trip' :: Wrap -> Wrap
|   trip' = Wrap . (\a f fDict -> extract f fDict a)
|  
|  as GHC seems to always float them as far leftward as possible
|  
|   extract :: Functor f => Wrap -> f Int
|  
|  I take it there are no user supplied types a person can give to
|  overcome the predicative assumption?
|  
|  Out of curiosity, how would you write the special internal type that
|  ($) has that separates it from ($') above?
|  
|  Thanks!  -Tyson
|  ___
|  Haskell mailing list
|  Haskell@haskell.org
|  http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] [Haskell-cafe] GHC 7.10 Prelude: we need your opinion

[Simon Peyton Jones]

|  What were the objections? Especially the principle ones?

Please read the info pages, which set out the arguments quite carefully.

Also, I spammed several email lists to ensure broad coverage, but it'd be best 
to debate on the librar...@haskell.org, rather than reply-to-all; that's what 
it's for.  (Which I failed to send the announcement to!  I'll fix that.)

Simon

|  -Original Message-
|  From: Miguel Mitrofanov [mailto:miguelim...@yandex.ru]
|  Sent: 10 February 2015 15:59
|  To: Simon Peyton Jones; haskell@haskell.org; Haskell Cafe (haskell-
|  c...@haskell.org); GHC users; ghc-d...@haskell.org
|  Subject: Re: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion
|  
|  What were the objections? Especially the principle ones?
|  
|  10.02.2015, 18:51, "Simon Peyton Jones" :
|  > Haskell Friends
|  >
|  > This email asks for your help in deciding how to proceed with some
|  Prelude changes in GHC 7.10.  Please read on, but all the info is also
|  at the survey link, here: http://goo.gl/forms/XP1W2JdfpX.   Deadline
|  is 21 Feb.
|  >
|  > The ​Core Libraries Committee (CLC) is responsible for developing the
|  core libraries that ship with GHC. This is an important but
|  painstaking task, and we owe the CLC a big vote of thanks for taking
|  it on.
|  >
|  > For over a year the CLC has been working on integrating the Foldable
|  and Traversable classes (shipped in base in GHC 7.8) into the core
|  libraries, and into the Prelude in particular. Detailed planning for
|  GHC 7.10 started in the autumn of 2014, and the CLC went ahead with
|  this integration.
|  >
|  > Then we had a failure of communication.  As these changes affect the
|  Prelude, which is in scope for all users of Haskell, these changes
|  should be held to a higher bar than the regular libraries@ review
|  process.  However, the Foldable/Traversable changes were not
|  particularly well signposted. Many people have only recently woken up
|  to them, and some have objected (both in principle and detail).
|  >
|  > This is an extremely unfortunate situation. On the one hand we are
|  at RC2 for GHC 7.10, so library authors have invested effort in
|  updating their libraries to the new Prelude. On the other, altering
|  the Prelude is in effect altering the language, something we take
|  pretty seriously. We should have had this debate back in 2014, but
|  here we are, and it is unproductive to argue about whose fault it is.
|  We all share responsibility.
|  >
|  > We need to decide what to do now. A small group of us met by Skype
|  and we've decided to do this:
|  >
|  > · Push back GHC 7.10's release by at least a month, to late
|  March.  This delay also gives us breathing space to address an
|  unrelated show-stopping bug, Trac #9858.
|  >
|  > · Invite input from the Haskell community on which of two
|  approaches to adopt (this survey).  The main questions revolve around
|  impact on the Haskell ecosystem (commercial applications, teaching,
|  libraries, etc etc), so we want to ask your opinion rather than guess
|  it.
|  >
|  > · Ask Simon Marlow and Simon Peyton Jones to decide which
|  approach to follow for GHC 7.10.
|  >
|  > Wiki pages have been created summarizing these two primary
|  alternatives, including many more points and counter-points and
|  technical details:
|  >
|  > · Overall summary:
|  https://ghc.haskell.org/trac/ghc/wiki/Prelude710
|  >
|  > · Details of Plan List:
|  https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List
|  >
|  > · Details of Plan FTP:
|  https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP
|  >
|  > This survey invites your input on which plan we should follow. Would
|  you please
|  >
|  > · Read the details of the alternative plans on the three
|  wiki pages above
|  >
|  > · Add your response to the survey
|  >
|  > Please do read the background.  Well-informed responses will
|  help.  Thank you!
|  >
|  > DEADLINE: 21 February 2015
|  >
|  > Simon PJ
|  >
|  > ,
|  >
|  > ___
|  > Haskell-Cafe mailing list
|  > haskell-c...@haskell.org
|  > http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] GHC 7.10 Prelude: we need your opinion

[Simon Peyton Jones]

Haskell Friends
This email asks for your help in deciding how to proceed with some Prelude 
changes in GHC 7.10.  Please read on, but all the info is also at the survey 
link, here: http://goo.gl/forms/XP1W2JdfpX.   Deadline is 21 Feb.

The ​Core Libraries Committee (CLC) is responsible for developing the core 
libraries that ship with GHC. This is an important but painstaking task, and we 
owe the CLC a big vote of thanks for taking it on.

For over a year the CLC has been working on integrating the Foldable and 
Traversable classes (shipped in base in GHC 7.8) into the core libraries, and 
into the Prelude in particular. Detailed planning for GHC 7.10 started in the 
autumn of 2014, and the CLC went ahead with this integration.

Then we had a failure of communication.  As these changes affect the Prelude, 
which is in scope for all users of Haskell, these changes should be held to a 
higher bar than the regular libraries@ review process.  However, the 
Foldable/Traversable changes were not particularly well signposted. Many people 
have only recently woken up to them, and some have objected (both in principle 
and detail).

This is an extremely unfortunate situation. On the one hand we are at RC2 for 
GHC 7.10, so library authors have invested effort in updating their libraries 
to the new Prelude. On the other, altering the Prelude is in effect altering 
the language, something we take pretty seriously. We should have had this 
debate back in 2014, but here we are, and it is unproductive to argue about 
whose fault it is. We all share responsibility.

We need to decide what to do now. A small group of us met by Skype and we've 
decided to do this:

· Push back GHC 7.10's release by at least a month, to late March.  
This delay also gives us breathing space to address an unrelated show-stopping 
bug, Trac #9858.

· Invite input from the Haskell community on which of two approaches to 
adopt (this survey<http://goo.gl/forms/XP1W2JdfpX>).  The main questions 
revolve around impact on the Haskell ecosystem (commercial applications, 
teaching, libraries, etc etc), so we want to ask your opinion rather than guess 
it.

· Ask Simon Marlow and Simon Peyton Jones to decide which approach to 
follow for GHC 7.10.

Wiki pages have been created summarizing these two primary alternatives, 
including many more points and counter-points and technical details:

· Overall summary: 
https://ghc.haskell.org/trac/ghc/wiki/Prelude710<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FPrelude710&sa=D&sntz=1&usg=AFQjCNE1p5w-YCXC7ixebvwObayuV7Ut4w>

· Details of Plan List: 
https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FPrelude710%2FList&sa=D&sntz=1&usg=AFQjCNHaufeSwtIsvZwdVXwP9F9G45zLSA>

· Details of Plan FTP: 
https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP<https://www.google.com/url?q=https%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fwiki%2FPrelude710%2FFTP&sa=D&sntz=1&usg=AFQjCNHbhNyIwAbcOd3JfikIhD6S7rc-vw>

This survey invites your input on which plan we should follow. Would you please

· Read the details of the alternative plans on the three wiki pages 
above

· Add your response to the survey<http://goo.gl/forms/XP1W2JdfpX>

Please do read the background.  Well-informed responses will help.  Thank you!

DEADLINE: 21 February 2015
Simon PJ
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Haskell Weekly News: Issue 316

[Simon Peyton Jones]

After doing more than 150 of these, I have come to the conclusion that

it is time for me to take a permanent break from HWN. I realize that

"we could do better", and have something a bit more edited than a

collection of links, and some quotes. I wish I had more time to devote

to such endeavour, but my time is currently being taken up by trying to

help my 1 year old explore her little world.


We owe Daniel a huge debt of thanks.  HWN is a huge service to the community. I 
have read many interesting blog posts that I would have never otherwise found.  
Thank you!

We really need a successor!  Please, please.

Simon

From: Haskell [mailto:haskell-boun...@haskell.org] On Behalf Of Daniel Santa 
Cruz
Sent: 05 February 2015 04:22
To: haskell@haskell.org; haskell-c...@haskell.org
Subject: [Haskell] Haskell Weekly News: Issue 316

Welcome to issue 316 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers
from January 18 to 31, 2015

After doing more than 150 of these, I have come to the conclusion that
it is time for me to take a permanent break from HWN. I realize that
"we could do better", and have something a bit more edited than a
collection of links, and some quotes. I wish I had more time to devote
to such endeavor, but my time is currently being taken up by trying to
help my 1 year old explore her little world.

If you'd like to be the one to continue the long tradition of HWN, drop
me a line.

Thanks for following along for the last 3 years!

Quotes of the Week

   * johnw: "Sir, what weapon did the assailant use against you?" "All I
 know is that it was done in IO, officer."

   * monochrom: $ can't buy you love, but it can buy you function
 application

   * hiptobecubic: benzrf, well sure. I'm not suggesting that lens has
 actually left any operators available for anything

Top Reddit Stories

   * I think I've nailed it! I've solved the records problem!
 Domain: nikita-volkov.github.io, Score: 
348, Comments: 193
 Original: [1] http://goo.gl/PhJo6K
 On Reddit: [2] http://goo.gl/vWPeOj

   * Use Haskell for shell scripting
 Domain: haskellforall.com, Score: 121, Comments: 
62
 Original: [3] http://goo.gl/Fx4HeT
 On Reddit: [4] http://goo.gl/2g83KR

   * Major Prelude changes proposed
 Domain: haskell.org, Score: 119, Comments: 252
 Original: [5] http://goo.gl/wtFWt3
 On Reddit: [6] http://goo.gl/kaegj2

   * Slides from Don Stewart's Google tech talk
 Domain: code.haskell.org, Score: 104, Comments: 75
 Original: [7] http://goo.gl/ejfoFp
 On Reddit: [8] http://goo.gl/9cK9dB

   * Haskell Design Patterns: .Extended Modules
 Domain: jaspervdj.be, Score: 86, Comments: 29
 Original: [9] http://goo.gl/TvwGCF
 On Reddit: [10] http://goo.gl/wkNx38

   * IO Monad Considered Harmful
 Domain: blog.jle.im, Score: 86, Comments: 157
 Original: [11] http://goo.gl/z9Elq7
 On Reddit: [12] http://goo.gl/uehgF9

   * We are making great efforts to spread Haskell around our local
 programming groups. Today, I finally saw a Haskell post, so I'm
 glad it is kinda working. Kinda.
 Domain: i.imgur.com, Score: 86, Comments: 41
 Original: [13] http://goo.gl/0SsbT7
 On Reddit: [14] http://goo.gl/gyBJ1o

   * My Haskell tooling wishlist by Chris Done
 Domain: chrisdone.com, Score: 77, Comments: 27
 Original: [15] http://goo.gl/VIRJgM
 On Reddit: [16] http://goo.gl/ChmItY

   * Categories for Programmers: Functors
 Domain: bartoszmilewski.com, Score: 70, 
Comments: 14
 Original: [17] http://goo.gl/6M64jC
 On Reddit: [18] http://goo.gl/tW6ubH

   * I wrote another monad tutorial. Sorry.
 Domain: kevinmahoney.co.uk, Score: 63, 
Comments: 22
 Original: [19] http://goo.gl/zEQIgS
 On Reddit: [20] http://goo.gl/XXeZN3

   * Introducing SJS, a type inferer and checker for JavaScript
 (written in Haskell)
 Domain: noamlewis.wordpress.com, Score: 
61, Comments: 33
 Original: [21] http://goo.gl/oQRSNo
 On Reddit: [22] http://goo.gl/1LfY1u

   * Solving the expression problem with Object Algebras and
 Tagless Interpreters
 Domain: 
oleksandrmanzyuk.wordpress.com, Score: 
59, Comments: 30
 Original: [23] http://goo.gl/daJWGy
 On Reddit: [24] http://goo.gl/fKy9zV

Top StackOverflow Questions

   * Why do we need monads?
 votes: 142, answers: 5
 Read on SO: [25] http://goo.gl/Ioviv9

   * Why compiling this Haskell program with -fllvm produces a different result?
 votes: 19, answers: 0
 Read on SO: [26] http://goo.gl/twid2N

   * What is the difference between traits in Rust and typeclas

Re: [Haskell] [Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (27th ed., November 2014)

[Simon Peyton Jones]

Friends

With each issue of the Haskell Communities and Activities Report I am freshly 
awed by the range and creativity of the things you are all doing with Haskell. 
From web frameworks to bioinformatics, from automatic differentiation to GUIs 
and games.  Amazing stuff.

I think we owe the editors, Mihai Maruseac and Alejandro Serrano Mena, a huge 
debt for putting it together.  Thank you!

Simon

|  -Original Message-
|  From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf
|  Of Mihai Maruseac
|  Sent: 17 November 2014 02:03
|  To: Haskell; haskell; Haskell Beginners; Lista principala
|  Subject: [Haskell-cafe] [Haskell] ANNOUNCE: Haskell Communities and
|  Activities Report (27th ed., November 2014)
|  
|  On behalf of all the contributors, we are pleased to announce that the
|  
| Haskell Communities and Activities Report
|  (27th edition, November 2014)
|  
|  is now available, in PDF and HTML formats:
|  
|http://haskell.org/communities/11-2014/report.pdf
|http://haskell.org/communities/11-2014/html/report.html
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] HPC and the Square Kilometre Array

[Simon Peyton-Jones]

Here's an interesting-looking job.  The Cambridge radio astronomy group are 
looking for a research associate to work on software for the Square Kilometre 
Array.  The advert is here
http://www.jobs.cam.ac.uk/job/2189/
Although it doesn't mention Haskell. Bojan says ""Somebody with background in 
C, MPI (or other HPC models) and Haskell would be ideal".
Simon

Microsoft Research Limited (company number 03369488) is registered in England 
and Wales
Registered office is at 21 Station Road, Cambridge, CB1 2FB

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] An APL library for Haskell

[Simon Peyton-Jones]

PS: Oddly I sent this message in March 2012. I don't know why it has taken over 
year for it to be delivered!

Simon

From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Simon 
Peyton-Jones
Sent: 08 March 2012 13:45
To: haskell@haskell.org; Haskell Cafe
Cc: Lennart Augustsson; John Scholes; nic...@chalmers.se; Nate Foster; Andy 
Gill; Mary Sheeran; Fritz Henglein
Subject: [Haskell-cafe] An APL library for Haskell

Friends

Many of you will know the array language 
APL<http://en.wikipedia.org/wiki/APL_%28programming_language%29>.   It focuses 
on arrays and in particular has a rich, carefully-thought-out array algebra.

An obvious idea is: what would a Haskell library that embodies APL's array 
algebra look like?  In conversation with John Scholes and some of his 
colleagues in the APL community a group of us developed some ideas for a 
possible API, which you can find on the Haskell wiki here: 
http://www.haskell.org/haskellwiki/APL

However, we have all gone our separate ways, and I think it's entirely possible 
that that the idea will go no further.  So this message is to ask:

*   Is anyone interested in an APL-style array library in Haskell?

*   If so, would you like to lead the process of developing the API?

I think there are quite a few people who would be willing to contribute, 
including some core gurus from the APL community: John Scholes,  Arthur 
Whitney, and Roger Hui.

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Lambda Style

[Simon Peyton-Jones]

Dear Haskellers

Happy New Year!

Did you see our friend Ranjit Jhala's (of liquid type fame) Lambda Style video? 
 Haskell hits the pop scene.
  http://www.youtube.com/watch?v=Ci48kqp11F8

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] The end of an era, and the dawn of a new one

[Simon Peyton-Jones]

Friends

You'll have seen Simon Marlow's recent announcement (included below):

| Today I'm announcing that I'm leaving Microsoft Research.

Simon Marlow and I have worked together on GHC for nearly two decades.
During much of that time we have shared a cup of coffee every morning
(one cup each, since you ask), to discuss what's going on in
GHC-land.  We had frequent detailed and illuminating debates
about design alternatives. Simon is the absolute master of GHC's
code generation, runtime system, garbage collector, support for
parallel execution, and much else besides.  His sheer programming
skill in rooting out obscure and hard-to-reproduce runtime system
bugs has always amazed me.  He is more than just a great hacker,
of course.  He is a leader in our community, has a strong
publication record, chaired the Haskell Prime committee for a
year, and is sought after for tutorials about parallel
programming.

I owe Simon a great debt, as I think we all do, for the care and
skill he has lavished on GHC.  He's not going to disappear
entirely, but he will be spending much less time on GHC than in
the past.  That is a change, but it's a change that was always
going to happen sometime, and while change is sometimes
uncomfortable, it can also open up new possibilities.

GHC is over 20, and like my own children (who are actually all a bit
younger than GHC), that's not a bad time to start to head out into the
world.  Over time, more and more people have started to help with the
task of developing and maintaining GHC.  We'll have to do more of
that.  These days GHC has a very large "surface area" (running on
different platforms, dynamic linking, debugger, profiler, GHCi,
libraries and Cabal, etc etc), and has grown far beyond what any
single person or research group can manage.  

Lest you should wonder, I myself will certainly continue to work on
GHC.  But my job is to be a *researcher*, and I am not well equipped --
in temperament or expertise -- to deal with the myriad complexities of
deployment, upgrade policy, portability, and the like.  Well Typed
(mostly in the guise of Ian Lynagh) will continue to handle some of
these issues, but again there is too much for one person to do.

So we need your help.  Seriously.  Rather than just thinking "GHC
HQ will sort it out", I would welcome you saying "Shall I take
responsibility for X?".  Johan, Bryan, and others offering to be
GHC Performance Tsars is a great recent example.  But don't wait
to be asked: just make an offer if you see a gap or an open
ticket --- and I think there will be plenty of those.
Particularly valuable are offers to take responsibility for a
particular area (eg the LLVM code generator, or the FFI).  I'm
hoping that this sea change will prove to be quite empowering,
with GHC becoming more and more a community project, more
resilient with fewer single points of failure. 

I am going to miss that cup of coffee though.  Thank you Simon!
Facebook is lucky to have you.  

Onward and upward.

Simon (PJ)


| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of Simon Marlow
| Sent: 22 November 2012 11:27
| To: haskell; glasgow-haskell-us...@haskell.org
| Subject: Leaving Microsoft
| 
| Today I'm announcing that I'm leaving Microsoft Research.
| 
| My plan is to take a break to finish the book on Parallel and Concurrent
| Haskell for O'Reilly, before taking up a position at Facebook in the UK
| in March 2013.
| 
| This is undoubtedly a big change, both for me and for the Haskell
| community.  I'll be stepping back from full-time GHC development and
| research and heading into industry, hopefully to use Haskell.  It's an
| incredibly exciting opportunity for me, and one that I hope will
| ultimately be a good thing for Haskell too.
| 
| What does this mean for GHC? Obviously I'll have much less time to work
| on GHC, but I do hope to find time to fix a few bugs and keep things
| working smoothly. Simon Peyton Jones will still be leading the project,
| and we'll still have support from Ian Lynagh, and of course the
| community of regular contributors. Things are in a reasonably stable
| state - there haven't been any major architectural changes in the RTS
| lately, and while we have just completed the switchover to the new code
| generator, I've been working over the past few weeks to squeeze out all
| the bugs I can find, and I'll continue to do that over the coming months
| up to the 7.8.1 release.
| 
| In due course I hope that GHC can attract more of you talented hackers
| to climb the learning curve and start working on the internals, in
| particular the runtime and code generators, and I'll do my best to help
| that happen.
| 
| Cheers,
|   Simon


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Status of Haskell'?

[Simon Peyton-Jones]

I'd argue that it's not. Haskell hasn't had a release in years, and I think 
it's time to put a little pressure on the community.

The question is: who is "the community"?

It's fairly clear that the Haskell Prime process itself is languishing. The 
last message about the development process that I can find is this one from 
Malcolm 
Wallace,
 in January 2011.

But please don't blame Malcolm or the 
committee.  
Developing new, well-specified changes to Haskell will only happen if there is 
a vigorous eco-system of folk who are prepared to devote the love and time to 
do it.  There are plenty of people (myself among them) who would be delighted 
if there was a series of well-specified updates to the Haskell standard; but it 
is harder to assemble a group that is willing to move that process forward.

Why not?  I don't think it's laziness or selfishness; just look at how helpful 
people are on the mailing list.  Rather, I am guessing that it's a subconscious 
assessment of cost/benefit.  The cost is certainly significant, and (unlike a 
quick email response on Haskell Cafe) takes place over months.

The benefit, for an individual, is harder to articulate.   GHC defines a 
de-facto standard, simply by existing, and for many practical purposes that is 
good enough.  However, GHC is (quite consciously) exploring stuff that may or 
may not ultimately turn out to be a good idea: it's a laboratory, not an 
every-detail-thought-out product.  [Though of course we try hard to be good 
enough for production use.]  So there is real merit in having a group, not too 
closely coupled to GHC, that picks off the best ideas and embodies them in a 
language standard.   But if for any one individual, GHC is "good enough", then 
the benefits of a language standard may seem distant and diffuse.

I don't have a solution to this particular conundrum.  As many of you will 
remember, the Haskell Prime 
process was itself 
developed in response to a sense that making a "big iteration" of the language 
was so large a task that no one felt able to even begin it.  Hence the 
deliberately more incremental nature of Haskell Prime; but even this 
lighter-weight process is rather stuck.

I'm sure that any solution will involve (as it did in earlier stages) motivated 
individuals who are willing to take up leadership roles in developing Haskell's 
language definition.  I'm copying this to the main Haskell list, in the hope of 
attracting volunteers!

Simon

From: haskell-prime-boun...@haskell.org 
[mailto:haskell-prime-boun...@haskell.org] On Behalf Of Nate Soares
Sent: 27 November 2012 22:44
To: Ben Millwood
Cc: haskell-pr...@haskell.org Prime
Subject: Re: Status of Haskell'?

> it might be wise to see what GHC decides to do on that front, first,

I'd argue that it's not. Haskell hasn't had a release in years, and I think 
it's time to put a little pressure on the community.

On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood 
mailto:hask...@benmachine.co.uk>> wrote:
On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh 
mailto:ig...@earth.li>> wrote:
> [...] adding DeriveDataTypeable
> hopefully wouldn't be too controversial [...]

This is a little tricky since the Data class itself makes (essential,
I think) use of Rank2Types. Typeable ought to be fine, but it might be
wise to see what GHC decides to do on that front, first, e.g. whether
it's going to autoderive all instances or forbid user instances or
anything else similarly bold.

___
Haskell-prime mailing list
haskell-pr...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Haskell stars in experimental film

[Simon Peyton-Jones]

Friends

You may enjoy this weird 2-minute video:
  http://www.youtube.com/watch?v=WtfvoiqLZrs&feature=youtu.be

It stars our cat (who is called Haskell at my children's insistence) in an 
"experimental concrete music video", created by a Cambridge undergrad music 
student.  Enjoy!  (What is concrete music, btw?)

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ESOP Call For Papers

[Simon Peyton-Jones]

Call for Papers

   ESOP 2013: The European Symposium on Programming

  http://www.ccs.neu.edu/esop2013/

   Affiliated with ETAPS'13
  Rome, Italy, 16-24 March 2013

DESCRIPTION AND TOPICS
  ESOP is an annual conference devoted to fundamental issues in the
  specification, design, analysis, and implementation of programming
  languages and systems. ESOP seeks contributions on all aspects of
  programming language research including, but not limited to, the
  following areas:

  * Programming paradigms and styles: functional programming,
object-oriented programming, aspect-oriented programming, logic
programming, constraint programming, extensible programming
languages, domain-specific languages, synchronous and real-time
programming languages;

  * Methods and tools to write and specify programs and languages:
programming techniques, logical foundations, denotational
semantics, operational semantics, meta programming, module systems,
language-based security;

  * Methods and tools for reasoning about programs: type systems,
abstract interpretation, program verification, testing;

  * Methods and tools for implementation: program transformations,
rewriting systems, partial evaluation, experimental evaluations,
virtual machines, intermediate languages, run-time environments;

  * Concurrency and distribution: process algebras, concurrency theory,
parallel programming, service-oriented computing, distributed and
mobile languages.

  Contributions bridging the gap between theory and practice are particularly 
welcome. 

IMPORTANT DATES
   7 October  2012: Submission deadline for abstracts 
  14 October  2012: Submission deadline for full papers 
  28 November 2012: Beginning of author response period
  14 December 2012: Notification of decision 
   8 January  2013: Camera-ready versions due
  16-24 March 2013: Presentations in Rome, Italy

INFORMATION
  For additional information, point your browser at 
http://www.ccs.neu.edu/esop2013/ 



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Higher types in contexts

[Simon Peyton-Jones]

Yes, it's hard: it's impredicative polymorphism.  Dimitrios and Tim and I have 
a plan for a modest but reliable form of impredicative polymorphism, which we 
hope to have ready for the Haskell Symposium deadline.  It is relatively 
simple, like QML, but a bit clumsy.  That's the tradeoff.

Simon

|  -Original Message-
|  From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org] On
|  Behalf Of Barney Hilken
|  Sent: 05 March 2012 12:22
|  To: haskell@haskell.org
|  Subject: [Haskell] Higher types in contexts
|  
|  Is there any deep reason why I can't write a polymorphic type in a context? 
I think
|  the record update problem can be (sort of) solved if you could write:
|  
|  class Has r Rev (forall a. [a] -> [a]) => HRClass r where
|   setHRClass :: (forall a.[a] -> [a]) -> r -> r
|  
|  but polymorphic types are not allowed in contexts. Is this one of the 
problems SPJ
|  considers "Hard" or is it a feasible extension?
|  
|  Barney.
|  
|  
|  ___
|  Haskell mailing list
|  Haskell@haskell.org
|  http://www.haskell.org/mailman/listinfo/haskell



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Faculty Fellowships

[Simon Peyton-Jones]

Friends

Microsoft Research is inviting nominations for its Faculty Fellowship program, 
starting on September 30, 2011. This program recognizes and supports 
exceptional early-career faculty engaged in innovative computing research. The 
objective is to stimulate and support the research of promising individuals who 
have the potential to make a profound impact on the state-of-the-art in their 
research disciplines and to become future thought leaders.  The award is 
substantial -- typically enough to fund a faculty salary for a couple of years.


Applications by 31 October. Further information is available at 
http://research.microsoft.com/en-us/collaboration/awards/msrff.aspx, questions 
regarding eligibility etc. can be directed to 
fls...@microsoft.com.


Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Proposal to incorporate Haskell.org

[Simon Peyton-Jones]

Dear haskell.org committee

Great stuff.  Thanks for getting this together.

Things I wondered about are:
- who will run the haskell.org entity?
- how are they chosen?  do they have fixed terms? 
- how are they accountable to the Haskell Community
  (eg an a brief annual report would be good; 
 since money is involved, accounts perhaps)

None of these look like being problems to me, but I think we should have a page 
that sets out these matters -- a kind of constitution for haskell.org, if you 
like -- as part of the process.

Simon

| -Original Message-
| From: libraries-boun...@haskell.org [mailto:libraries-boun...@haskell.org] On 
Behalf
| Of Don Stewart
| Sent: 10 May 2011 23:45
| To: haskell@haskell.org; Haskell Libraries; GHC Users Mailing List; 
haskell-cafe;
| commit...@haskell.org
| Subject: Proposal to incorporate Haskell.org
| 
| Hello everyone.
| 
| The haskell.org committee[1], in the interest of the long-term stability
| of the open source Haskell community infrastructure, has decided to
| incorporate haskell.org as a legal entity. This email outlines our
| recommendation, and seeks input from the community on this decision.
| 
| The committee's proposal is that haskell.org incorporate as an entity
| under the Software Freedom Conservancy umbrella organization (the same group
| that Darcs joined recently):
| 
| http://sfconservancy.org/
| 
| If we proceed with this move, haskell.org will be a legal entity, and
| registered as a non-profit, allowing us to more directly accept
| (US tax-deductible) donations, and to invest in assets that benefit the
| Haskell open source community.
| 
| We welcome your feedback on the proposal attached below.
| 
| -- Don Stewart (on behalf of the Haskell.org committee)
| 
| 
| 
| 
| 
| = A proposal for the incorporation of Haskell.org =
| 
| In recent years, haskell.org has started to receive assets, e.g. money from
| Google Summer Of Code, donations for Hackathons, and a Sparc machine for use 
in
| GHC development. We have also started spending this money: in particular, on
| hosting haskell.org itself. There is also interest in running fundraising
| drives for specific things such as Hackathon sponsorship and hosting fees.
| 
| However, haskell.org doesn't currently exist as a legal entity, meaning that
| these assets have had to be held on our behalf by other entities, such as
| Galois and various universities. This leads to tricky situations, with no-one
| being sure who should decide how the haskell.org assets can be used.
| 
| To solve these problems, we propose that haskell.org applies to become a 
member
| project of the Software Freedom Conservancy (SFC)
| . The SFC is a non-profit 
organization
| that provides free financial and administrative services to open source
| projects. Additionally, it has 501(c)(3) status, meaning donations from the US
| are tax-deductible. The SFC would hold haskell.org's money and other assets,
| and would be able to accept donations on behalf of haskell.org.
| 
| The haskell.org committee, as described here [2], will make decisions on
| spending assets and other decisions related to governing the non-profit.
| 
| 
| Before proceeding, we are inviting input from the community in the form
| of specific objections or queries regarding the plan.
| 
| We've tried to answer some of the most likely questions:
| 
| Q: Does this mean that my Haskell project must now be covered by a
|  copyleft licence such as GPL?
| A: No, but Haskell projects using haskell.org resource should use an
| Open Source licence
|  .
| 
| Q: Will it still be possible to use community.h.o to host
|  non-open-source material, such as academic papers?
| A: An overall minority of such content, as is the current situation, is
| not a problem.
| 
| Q: Will it still be possible to have job ads on the haskell.org mailing
| lists and website?
| A: Yes.
| 
| Q: Will this affect our ability to host the Haskell Symposium
|   and Industrial Haskell
| Group  webpages within haskell.org?
| A: No.
| 
| Q: What will be the relationship between haskell.org and other
| organizations such as the Haskell Symposium and Industrial Haskell
| Group?
| A: Those organisations will continue to exist as separate entities.
| 
| Q: If an umbrella non-profit organisation "The Haskell Foundation" was
| created, would haskell.org be able to join it?
| A: Yes. It's likely that in such a scenario, the Haskell Foundation
| would become the owner of the haskell.org domain name, with the cost
| divided between the members. The entity that is part of the SFC would
| be renamed "community.haskell.org" in order to avoid confusion.
| 
| [1]: http://www.ha

[Haskell] FW: For Haskell List: The F# Team are Hiring

[Simon Peyton-Jones]

Dear Haskell'ers

The F# team in Seattle/Redmond have an opening for a Senior Program 
Manager.
 A demonstrated love for applied Haskell/OCaml/F# programming would be highly 
regarded background experience :)

We also have positions open for software development engineers specializing in 
compilers and tools (see 
https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=3&jid=34078&jlang=EN)

Kind regards & best wishes,

Don Syme

The F# Team are Hiring!!!

  *   Do you have a love for modern, industry-leading programming technologies?
  *   Can you help us take the F# language to the next level?
  *   Do you have the vision to combine functional programming  with 
technologies for data, cloud, web, finance and technical computing?
  *   Do you have a passion for delivering great visual tools and a simple, 
clear end-to-end experience for F# programmers?
  *   And do you want to work on a talented agile team that releases compiler 
sources on codeplex.com and has originated major innovations for C# and Visual 
Basic?

If so, we have a great opportunity for you!

The Visual Studio Pro team is looking for an experienced Program Manager to 
drive the F# area. Partnering with your engineering team in Redmond and 
Microsoft Research in Cambridge, you will define the F# developer experience 
for Visual Studio and out of band releases such as the F# PowerPack. As a 
strong customer advocate, you will drive changes into the F# language, 
libraries and tools. You will develop and update community programs that drive 
increased awareness and adoption of F#. Being responsible for delivering 
integrated solutions, you have experience in building strong cross-group 
partnerships, ensuring alignment of schedules and business goals, and the 
natural skill of getting things done.

Specific responsibilities include:

  *   Travelling to major conferences, user group meetings, and enterprises to 
get people excited about solving problems using F#
  *   Defining the strategy for marketing F# to the developer community
  *   Owning our content strategy and community engagement programs
  *   Driving multiple concurrent projects for the F# team including Visual 
Studio and out of band releases
  *   Working closely with groups within Microsoft such as Technical Computing, 
.NET Framework, SQL and Azure to deliver great experiences for F# developers
  *   Contributing to the design of all aspects of F# from language & libraries 
to the tools that integrate with Visual Studio

Basic Qualifications:

  *   3-5 years experience in Program Management or related experience, 
including a proven track record of delivering on challenging projects
  *   A BS or equivalent degree in Computer Science, Electrical Engineering, or 
a related field.
  *   Passionate for language and user experience design
  *   Knowledge of Visual Studio, .NET & functional programming languages, and 
the ability to dig deep into technical challenges
  *   Strong sense of teamwork, personal integrity, responsibility and 
accountability
  *   Excellent verbal and written communication skills
  *   Strong customer advocate, self-starter and problem solver
  *   Strong knowledge of F# or language design on managed platforms is 
preferred

If you'd would like more details, please either contact me 
(ds...@microsoft.com), or Sean Laberee 
(sea...@microsoft.com) directly. To apply 
immediately, please fill in the online 
forms
 and drop us a note that you're applying.

https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=1&jid=33994&jlang=EN

don

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] CFP: Workshop on Intermediate Representations: deadline Jan 21

[Simon Peyton-Jones]

Friends

Happy new year!  I'm on the PC for Workshop on Intermediate Representations; do 
consider submitting a paper.

Simon

WIR 2011: Workshop on Intermediate Representations 2011
http://researchr.org/conference/wir-2011

The intermediate representation is the core of any program transformation tool. 
Its design has a significant impact on the simplicity, efficiency, and 
effectiveness of program transformations. The developments in concurrent 
programming, integrated development environments, and domain-specific languages 
pose new requirements on intermediate representations. This workshop provides a 
forum to discuss current trends and experiences in the design, implementation, 
and application of intermediate representations.

Co-located with CGO 2011

Conference Dates
Submissions:

January 21, 2011

Notification:

February 25, 2011

Event:

April 2, 2011-April 2, 2011


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] letter?

[Simon Peyton-Jones]

Did someone forget to renew www.haskell.org?  Who does this?   

Also plain http://haskell.org/ used to work, but doesn't any more.

I'm sure lots of people have noticed this, but it'd be good if someone posted a 
summary of what's being done about it. 

Simon

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Memory management job

[Simon Peyton-Jones]

Dear Haskellers and Camlers



I'm posting this job ad on behalf of Richard Brooksby at Ravenbrook.   They do 
cool stuff, and I thought some of you might be interested.

Simon





Ravenbrook is seeking a developer to work with us on the Memory Pool System 
(MPS), a mature, open source, high reliability, high performance memory 
management system with a unique and innovative architecture.  You can read an 
overview here 
.
  The MPS is a highly engineered "Swiss watch" of a system with an extremely 
low bug rate.



We're looking for someone who can support our commercial clients with 
customisations, but also develop the MPS for new opportunities.  It could be a 
half-time position (or subcontract), paying about £35k pro rata.  This could 
grow if you are successful in developing new commercial opportunities for the 
MPS.  We have several other options for work structure and payment that we can 
discuss with you.  There can be a great deal of flexibility and a higher rate 
of pay depending on what kind of risk/reward tradeoff you need.  Ask!



This is an excellent opportunity for someone interested in memory management 
and garbage collection research.  We are keen to promote research, and the 
flexible nature of this work would allow time for it.  It's also an excellent 
opportunity for someone interested in developing commercial applications for 
memory management and garbage collection.



There would also be an opportunity to get involved with our other consulting 
work, or even video game development.



Essential requirements:



* you will mostly need to work at our office in Cambridge, UK



* you will need to start early in 2011



* highly professional attitude to quality, reliability, and commercial 
relationships



* able to self-start, plan, and manage yourself



* excellent verbal and written technical communication skills



* excellent knowledge of ISO/IEC 9899:1990 and ISO/IEC 9899:1999.  (Oh OK then, 
I mean C.)



* good understanding of operating systems and memory management



* understanding of processor architectures and assembly language



Also very useful:



* some compiler and language run-time development experience



* good understanding of threads, concurrency, and race/hazard issues



* some low level systems and embedded systems experience



* low-level Unix (including Mac) and Windows programming



* some experience in soft real-time systems



* keen interest in programming languages, compilers, provability



Address in sig.  Do get in touch.



PLEASE NOTE: Generic CVs and resumes as Word document attachments will be 
trashed.  Explain why you might be good for us, in plain text or on the phone.  
Thanks!



---

Richard Brooksby mailto:r...@ravenbrook.com>>

Director

Ravenbrook Limited  PO Box 205, Cambridge CB2 1AN, 
United Kingdom

Voice: +44 777 9996245  Fax: +44 1223 750036





___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] International Workshop on Intermediate Representations (WIR 2011)

[Simon Peyton-Jones]

Dear functional friends

Here's the Call for Papers for a new Workshop on Intermediate Representations.  

I expect it to get a lot of papers about the JVM and program dependence graphs, 
but the Chair explicitly wants papers about intermediate representations for 
functional programs, both typed and untyped.  So, do me a favour :-) and submit 
your paper, lest I get landed with a mountain of SSA papers to review.   (Yes, 
SSA is just CPS in disguise. But the disguise is heavy.)

The deadline is rather short: Jan 21.  Happy Christmas!

Simon

==
Call for Papers

International Workshop on Intermediate Representations (WIR 2011)

Co-located with CGO 2011, April 2/3 2011 in Chamonix, France

http://researchr.org/conference/wir-2011

Description
===

The intermediate representation is the core of any program transformation tool. 
Its design has a significant impact on the simplicity, efficiency, and 
effectiveness of program transformations. The developments in concurrent 
programming, integrated development environments, and domain-specific languages 
pose new requirements on intermediate representations. This workshop provides a 
forum to discuss current trends and experiences in the design, implementation, 
and application of intermediate representations.  

Topics of Interest
==

The list of topics includes, but is not limited to:

   * intermediate representations for
 o parallelism and concurrency
 o instrumentation
 o JIT compilation
 o compiler verification
 o domain-specific languages
 o refactoring
 o integrated development environments
   * functional intermediate representations for imperative programs
   * translation to, and code generation from an IR
   * modeling low-level machine details in IRs
   * impact of IR on the precision of static analyzers
   * representing static analysis results in an IR
   * origin tracking

Submission
==

We solicit submission of original papers on topics relevant to intermediate
representations. Papers should be formatted in SIGPLAN Proceedings
Format, 9 point
font, and be at most 8 pages in length.

   * http://www.acm.org/sigs/sigplan/authorInformation.htm

Selected papers will be published in the ACM digital library (to be confirmed).

Papers should be submitted electronically with easychair:

   * http://www.easychair.org/conferences/?conf=wir2011

Important Dates
===

   * Submission: January 21, 2011
   * Notification: February 25, 2011
   * Camera-ready: March 18, 2011
   * Workshop: April 2/3, 2011

Organizers
==

   * Florent Bouchez
   * Sebastian Hack
   * Eelco Visser

Program Committee
=

* Florent Bouchez (chair)
* Martin Bravenboer
* Albert Cohen
* François de Ferrière
* Robert Fuhrer
* Sebastian Hack (chair)
* Andrew Kennedy
* Sorin Lerner
* Nathaniel Nystrom
    * Simon Peyton Jones
* Tijs van der Storm
* Eelco Visser (chair)

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Specification and prover for Haskell

[Simon Peyton-Jones]

Would someone like to make a Haskell Wiki page to summarise the responses to 
this thread?

Simon

| -Original Message-
| From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org] On 
Behalf Of
| Till Mossakowski
| Sent: 26 October 2010 11:38
| To: haskell@haskell.org >> "haskell@haskell.org"
| Subject: Re: [Haskell] Specification and prover for Haskell
| 
| The Heterogeneous Tool Set supports HasCASL for specification
| of Haskell programs, and uses Isabelle for proving
| http://www.dfki.de/sks/hets
| 
| Moreover, the Programatica project has an expressive logic
| called P-logic, and tools supporting it:
| http://programatica.cs.pdx.edu/
| 
| Best, Till
| 
| Am 25.10.2010 10:09, schrieb Romain Demeyer:
| > Hello,
| >
| > I'm working on static verification in Haskell, and I search for existing
| > works on specification of Haskell programs (such as pre/post conditions,
| > for example) or any other functional language. It would be great if
| > there exists a prover based on this kind of specifications. I already
| > found the ESC/Haskell. Do you know some other works which could be
| > interesting?
| >
| > Thanks,
| >
| > rde.
| >
| >
| >
| > ___
| > Haskell mailing list
| > Haskell@haskell.org
| > http://www.haskell.org/mailman/listinfo/haskell
| 
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Haskell Weekly News: Issue 155 - October 20, 2010 (Originally posted to Haskell-Cafe)

[Simon Peyton-Jones]

| Malcolm Wallace noticed that I had not posted the HWN to this list,
| and requested that I do so.
| I realize that many of you are also following -Cafe, and I do
| apologize if this is a bit spamish due
| to that.  Hopefully some of you will find this useful.

Personally I welcome the Haskell Weekly News, and would love it to be posted to 
the Haskell list regularly.  It's not spam.  The bandwidth of Haskell-Cafe is 
too high for me, and HWN serves as a useful summary.

I suspect most people will agree, so perhaps (to avoid more spam) those who 
agree can sit tight, while anyone who definitely *doesn't* want to see HWN in 
their mailbox can sing out.  If there is significant disagreement we can 
discuss.  Until then, send it along, Daniel.  Thank you for doing it.

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Proposal: Form a haskell.org committee

[Simon Peyton-Jones]

Ian et al

| To fix this problem, we propose that we create a "haskell.org
| committee", which is responsible for answering these sorts of questions,
| although for some questions they may choose to poll the community at
| large if they think appropriate.

I think that's an excellent idea.  I think there should be a web page 
describing what the committee does, who is in it, how to contact it, etc.  I'm 
sure you intended that.  An annual statement of what money came in and went out 
would be good practice.

Well the committee also be responsible for the haskell.org web site? 

| We suggest that the committee be composed of 5 representatives from the
| community, with committee members standing down after at most 3 years.
| Each year the committee will appoint one of their members to be the chair.

It's usually helpful to establish a rotation so that everyone knows who is 
going to stand down when, and to arrange that there isn't a sudden glut one 
year.  Document the stand-down dates on the committee web page.  In my 
experience, everyone forgets!

Five might be a little small.

It might be good to allow for a person to be re-elected for a second term if 
they are willing.  It's a good principle to have rotation, but a pity to lose 
willing and experienced talent.  But six years is enough.

| As membership of "the Haskell community" is not well-defined, and voting
| would potentially be open to abuse if anyone were able to vote, we
| propose that the committee should choose their replacements from open
| nominations.

I agree with the problem, and I think your proposed solution may do for now, 
but it's obviously not a robust solution.  I trust you five, but in three years 
time you may all have stood down!

A possible solution would be to have an "electoral college" of people entitled 
to vote. It should be easy to become a member of the college: any track record 
of contributions to the Haskell community, including constructive contributions 
to Haskell Cafe, would be enough.  Then the college can elect the committee.

It's debatable whether this is worth the bother at this point.  Maybe it would 
be enough to document on the committee page that we don't regard the nomination 
process as robust, and if any concern arises we will consider something more 
substantial.

Simon

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] FW: [TYPES/announce] CUFP 2010 Call for Participation

[Simon Peyton-Jones]

Dear Haskellers

CUFP should be a lot of fun this year.  Do consider going.

Simon

   Commercial Users of Functional Programming Workshop
   (CUFP) 2010

 Call for Participation

  Sponsored by SIGPLAN

Co-located with ICFP 2010

_

   1 - 2 October 2010
   Baltimore (MD), USA

http://cufp.org/conference/schedule/2010


  Reservation will be available through
 ICFP's website: http://www.icfpconference.org/icfp2010

_


Functional programming languages have been a hot topic of academic
research for over 35 years, and have seen an ever larger practical
impact in settings ranging from tech startups to financial firms to
biomedical research labs. At the same time, a vigorous community of

practically-minding functional programmers has come into existence.

CUFP is designed to serve this community. The annual CUFP workshop is
a place where people can see how others are using functional
programming to solve real world problems; where practitioners meet and

collaborate; where language designers and users can share ideas about
the future of their favorite language; and where one can learn
practical techniques and approaches for putting functional programming
to work.

 
CUFP 2010 will feature three hour Functional Programming tutorials
given by language experts on the first day and Experience and
Technical Talks on day two. Attendees may attend either or both days.


Talks Program, October 2nd 2010

Luke Hoban (Microsoft)
   Keynote: F#: Embracing Functional Programming in
   "Visual Studio 2010" 

Sally A Browning (Galois Inc)
   Cryptol, a DSL for Cryptographic Algorithms 


Marius Eriksen (Twitter)
   Scaling Scala at Twitter  

Michael Fogus (Science Applications International Corporation)
   Naïveté vs. Experience - or, How We Thought We Could Use Scala and
   Clojure, and How We Actually Did It 


Neal Glew & Leaf Petersen (Intel)
   Functional Language Compiler Experiences at Intel

Warren Harris (Metaweb)
   Functional Programming at Freebase

Warren A. Hunt, Jr. (U. of Texas)
   Eating One’s Own Dog Food


Rusty Klophaus (Basho Technologies)
   Riak Core: Building Distributed Applications Without Shared State

Howard Mansell (Credit Suisse)
   Eden: An F#/WPF frameworok for building GUI tools

Erik Meijer (Microsoft)

   Reactive Extensions (Rx): Curing Your Asynchronous Programming
   Blues

Tutorial Program, October 1st 2010

Morning:  
   Clojure (Aaron Bedra) 
   Building robust servers with Erlang (Martin Logan)

   High Performance Haskell (Johan Tibell)
Afternoon:
   F# 2.0 - A day at the beach (Rick Minerich)
   Implementing web sites with Scala and Lift (David Pollak)
   Camlp4 and Template Haskell (Nicolas Pouillard, Jake Donham) 


There will be no published proceedings, as the meeting is intended to
be more a discussion forum than a technical interchange. For more
information, for more information, including presentation abstracts
and the most recent schedule information, visit


http://cufp.org

See you there!
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Programming language opening at Oxford

[Simon Peyton-Jones]

Oxford is advertising a tenure-track faculty position in programming languages:

http://www.comlab.ox.ac.uk/news/231-full.html

This is the same type of position as, say, Oege de Moor holds, so I can 
guarantee it's a nice job!

Simon


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Another Haskell job opportunity

[Simon Peyton-Jones]

-Original Message-
From: donotre...@cufp.org [mailto:donotre...@cufp.org] 
Sent: 16 July 2010 17:18
To: Simon Peyton-Jones
Subject: CUFP.org Job Posting Notification

Greetings CUFP Editor,

A new Job entitles 'WANTED Haskell Developer - Investment Banking - Openings  
in London, NY and Asia' has been submitted by Carrington Fox  
(http://cufp.org/user/121).  It will remain unavailable to general users  
until it is reviewed and published by one of our editorial volunteers.

You can administer this job by logging in and reviewing the post at the  
following URL:
http://cufp.org/node/263


-CUFP.org

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Modular type inference

[Simon Peyton-Jones]

Friends

Many of you will know that I've been muttering about re-engineering GHC's type 
inference engine for some time now.  Dimitrios, Tom, Martin and I have just 
completed an epic paper describing the Glorious New Framework that forms the 
substance of the above mutterings:
http://haskell.org/haskellwiki/Simonpj/Talk:OutsideIn

We'd love comments and feedback. Dimitrios and I plan to roll up our sleeves 
and implement it in June.

Simon

Modular type inference with local assumptions: OutsideIn(X)

Abstract. Advanced type system features, such as GADTs, type classes, and type 
families have have proven to be invaluable language extensions for ensuring 
data invariants and program correctness among others. Unfortunately, they pose 
a tough problem for type inference, because they introduce local type 
assumptions.

In this article we present a novel constraint-based type inference approach for 
local type assumptions. Our system, called OutsideIn(X), is parameterised over 
the particular underlying constraint domain X, in the same way as HM(X). This 
stratification allows us to use a common metatheory and inference algorithm.

Going beyond the general framework, we also give a particular constraint solver 
for X = type classes + GADTs + type families, a non-trivial challenge in its 
own right.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] FP jobs

[Simon Peyton-Jones]

Friends

Did you know that CUFP has a jobs board

http://cufp.org/jobs

There's a Haskell vacancy advertised recently (along with lots of F#)!

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Signature error because the order

[Simon Peyton-Jones]

In Haskell, the context of all functions in a mutually recursive group must be 
identical.
http://haskell.org/onlinereport/decls.html#generalization

Simon

From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org] On 
Behalf Of Luis Cabellos
Sent: 14 January 2010 11:26
To: haskell@haskell.org
Subject: [Haskell] Signature error because the order

Hi,

  I found than this piece of code causes an error in GHC ( 
http://haskell.pastebin.com/m5e3f4a4c ):

data Tree a = Leaf a | Node (Tree a) (Tree a)

--prettyShow :: (Show a, Num a) => Tree a -> String  -- WORKS
prettyShow :: (Num a, Show a) => Tree a -> String  -- FAILS
prettyShow (Leaf a) = show a
prettyShow (Node a b) = (simple a) ++ (simple b)

simple :: (Show a, Num a) => Tree a -> String
simple (Leaf x) = prettyShow (Leaf x)
simple x = "(" ++ prettyShow x ++ ")"

With the error:
test.lhs:14:0:
Couldn't match expected type `Show a'
   against inferred type `Num a1'
When matching the contexts of the signatures for
  prettyShow :: forall a. (Num a, Show a) => Tree a -> String
  simple :: forall a. (Show a, Num a) => Tree a -> String
The signature contexts in a mutually recursive group should all be identical
When generalising the type(s) for prettyShow, simple
Failed, modules loaded: none.


But if I change the order of Show and Num in the signature of prettyShow it 
works.

It's a GHC problem? it's normal than signature is order-dependent?

I use GHC  6.10.3

Thanks, Luis Cabellos

--

LC, ("There is no Dana, only Zuul." - Cazafantasmas [1984])
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] ANNOUNCE: Haskell Communities and Activities Report (17th ed., November 2009)

[Simon Peyton-Jones]

Brilliant.  Thank you Janis!

| 
| On behalf of the many, many contributors, I am pleased to announce
| that the
| 
|  Haskell Communities and Activities Report
|(17th edition, November 2009)
| 
|   http://www.haskell.org/communities/
| 
| is now available from the Haskell Communities home page in PDF and
| HTML formats.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] memory management

[Simon Peyton-Jones]

| In the early to mid '90s we built various heap-profiling tools to
| examine the characteristics of heap data in lazy functional programs.
| You can find papers describing this work by Googling "heap profiling".
| You may be particularly interested in the investigation of "heap lag"
| and "heap drag" -- see for example the ICFP'96 paper.  Others have
| worked on similar tools since, but I'm not sure how extensive heap
| profiling facilities are in ghc, the most widely used implementation of
| Haskell.

GHC has pretty good heap profiling, including lag/drag/void.  I hope they are 
still working smoothly, although I don't think they have received much love 
recently.

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] memory management

[Simon Peyton-Jones]

Also region inference is likely to be much less effective in a lazy language, 
because (I think that) data escapes the lifetime of its allocating procedure 
much more often.  I don't know of any work that has even tried it.

Simon

| -Original Message-
| From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org] On
| Behalf Of Simon Marlow
| Sent: 04 August 2009 14:50
| To: Sam Martin
| Cc: Colin Runciman; Haskell@haskell.org
| Subject: Re: [Haskell] memory management
| 
| On 04/08/2009 13:33, Sam Martin wrote:
| >> Sounds like region inference to me.
| >> (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference)
| >
| > Thanks, yes, that's exactly what I had in mind.
| >
| > Is anything like this is done in GHC?
| 
| Not at the moment, no.
| 
| Bear in mind that with generational GC, allocating memory that quickly
| becomes garbage is quite cheap.
| 
| Cheers,
|   Simon
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Fun with type functions

[Simon Peyton-Jones]

Friends

Ken, Oleg, and I have finished Version 2 of our paper "Fun with Type 
Functions", which gives a programmer's tour of what type functions are and how 
they are useful.

http://haskell.org/haskellwiki/Simonpj/Talk:FunWithTypeFuns

If you have a moment to look at, and wanted to help us improve it, the above 
link goes to a wiki page where you can comment on the paper or discuss it.  We 
still have time to improve it.

Thanks

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] ANNOUNCE: Haskell Communities and Activities Report (16th ed., May 2009)

[Simon Peyton-Jones]

| On behalf of the many, many contributors, I am pleased to announce
| that the
|  Haskell Communities and Activities Report
|(16th edition, May 2009)
| is now available from the Haskell Communities home page in PDF and
| HTML formats.

Congratulations Janis!  Thank you from all of us for editing the HCAR.

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Fun with type functions

[Simon Peyton-Jones]

Friends

Ken, Oleg, and I have been working on a tutorial paper about type families (aka 
associated data types, or type functions). It's in draft at the moment, and 
we'd really appreciate feedback that would help us improve it.

Here it is: http://haskell.org/haskellwiki/Simonpj/Talk:FunWithTypeFuns

Thank you!

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Marketing Haskell

[Simon Peyton-Jones]

Dear Haskell enthusiasts,

Now that the logo issue finally has been settled, it is time to select
the proper Haskell mascot.  As you are no doubt aware, Microsoft's
involvement in Haskell means that we have moved from avoiding success
at all cost to actively marketing the language, and any language
striving for success is entirely dependent on a cute and distinctive
mascot.  Where would Perl be today without its camel?

Since the recent logo discussion has demonstrated once and for all the
futility of attempting a democratic process in the Haskell community -
to be quite honest, the elected logo looks like an error message from an IBM
mainframe - I have decided to decide on a mascot myself.

So I hereby declare the official Haskell mascot to be the koala, in
the form of the image attached below.  Please ensure that this image
accompanies any material published on the web or on paper.

Simon

<>___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Take a break: write an essay for Onward! Essays

[Simon Peyton-Jones]

Friends

Writing papers is fun, we mostly only get to write one *kind* of paper.  Here 
is an opportunity to write something in a totally different style:

Submit an essay to Onward! Essays
Deadline: 20 April 2009
http://onward-conference.org/calls/foressays

An Onward! essay is a thoughtful reflection upon software-related technology. 
Its goal is to help the reader to share a new insight, engage with an argument, 
or wrestle with a dilemma.

A successful essay is a clear and compelling piece of writing that explores a 
topic important to the software community. The subject area should be 
interpreted broadly, including the relationship of software to human 
endeavours, or its philosophical, sociological, psychological, historical, or 
anthropological underpinnings. An essay can be an exploration of its topic, its 
impact, or the circumstances of its creation; it can present a personal view of 
what is, explore a terrain, or lead the reader in an act of discovery; it can 
be a philosophical digression or a deep analysis. It can describe a personal 
journey, perhaps that by which the author reached an understanding of such a 
topic.

I'm the program chair, and I'd love to get submissions from the POPL/ICFP/types 
community.  Reflections on programming languages, types, testing, verification, 
software engineering, compilers, society, ... you name it.  Anything to do with 
software.  NB: Onward! is co-located with OOPSLA, but they are otherwise 
unrelated.  OO is fine, but not required.

Don't forget: 20th April.

Simon


PS: To get your imagination going, here are a couple of (strongly-contrasting) 
past essays:
  * Dan Grossman "The transactional memory / garbage collection analogy"
http://www.cs.washington.edu/homes/djg/papers/analogy_oopsla07.pdf
  * Dick Gabriel "Designed as designer"
http://dreamsongs.org/DesignedAsDesigner.html

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Wait for *either* MVar to be set

[Simon Peyton-Jones]

| However, preemptive multitasking operating systems offer support for waiting 
for multiple
| "MVars", until *either* one of them returns (or timeouts).

The standard way to do this is to spawn a thread for each MVar you are waiting 
for; the thread blocks on the MVar and, when it unblocks it fills a third MVar 
with the outcome.  The original thread waits on this single MVar.  See Section 
5 of http://research.microsoft.com/users/simonpj/papers/concurrent-haskell.ps.gz

Alternatively STM supports such multiple waiting directly
http://research.microsoft.com/%7Esimonpj/papers/stm/index.htm#composble

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter
| Verswyvelen
| Sent: 26 November 2008 18:05
| To: haskell@haskell.org
| Subject: [Haskell] Wait for *either* MVar to be set
|
| Maybe this is not the correct mailing list to ask this question, but as a 
similar question was
| asked seemingly unanswered by Duncan Coutts in 2002
| (http://markmail.org/message/kftpnulks7mbz2ij), and as this most likely has 
to do with the GHC
| runtime, I might have more luck to get an answer here... Sorry for the spam 
if this is
| inappropriate; please say so and I will resubscribe to the Haskell Cafe 
mailing list, not
| polluting this main list anymore...
|
| So here's my question.
|
| GHC provides MVar for nice lightweight concurrency synchronization.
|
| However, preemptive multitasking operating systems offer support for waiting 
for multiple
| "MVars", until *either* one of them returns (or timeouts).
|
| I see no way of achieving this with GHC's MVar, unless using Conal Elliott's 
unamb package on
| Hackage that emulates this by spawning and killing two threads (which might 
be an expensive
| operation, I'm not sure)
|
| Am I wrong in this? If so, is this something that might be considered as a 
future enhancement
| in the GHC libraries and runtime?
|
| Thanks very much,
| Peter Verswyvelen
| CTO - Anygma
|
|
|
|
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] GHC 6.10 and OpenGL

[Simon Peyton-Jones]

| It's sad to see the OpenGL binding being dropped from GHC binary
| installers starting from 6.10. Though this issue has been brought up
| and discussed before, I'm sure a lot of people who based their work on
| OpenGL would share the same sympathy.

The plan (which we have perhaps not articulated as clearly as we should) is 
this:

- We are trying to make the GHC release contain as few libraries as possible
- Instead, you get the "batteries" for GHC (ie the libraries) from the Haskell 
Platform
http://www.haskell.org/haskellwiki/Haskell_Platform

This lets GHC HQ get out of the library business, and makes it easier to 
upgrade libraries independently from GHC.  But it does mean that GHC without 
the batteries is a feeble thing.  You really want to wait until the HP comes 
out.

The HP will be released in source form, to be installed by cabal-install, of 
course. But I believe that the intention is that there should be a Windows 
installer for it too.

Things I am less clear about
 - When will the first HP release compatible with GHC 6.10 appear?
 - How do users get cabal-install in the first place?  Is there
a windows installer for it?
 - Where can one find an up-to-date list of what packages are in HP?
 - Is there anyone who is actually planning to do the work of making
a windows installer for the HP?  The HP home page lists only
Duncan and Don.

I think it'd be good if it was easy to answer these questions from the HP home 
page.

Simon

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] IORef sharing

[Simon Peyton-Jones]

This would be an excellent thread for the Haskell Cafe mailing list, [EMAIL 
PROTECTED]

However, it's becoming over-long for the main list

http://haskell.org/haskellwiki/Mailing_lists#Mailing_lists_in_detail

Thanks!

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Brandon S. Allbery KF8NH
| Sent: 28 October 2008 00:38
| To: Rodney D Price
| Cc: haskell@haskell.org
| Subject: Re: [Haskell] IORef sharing
|
| On 2008 Oct 27, at 20:25, Rodney D Price wrote:
| > Okay... However, when I use IO in a Haskell program,
| > the response is usually pretty snappy.  It's not as
| > if the Haskell runtime is hanging around, waiting for
| > some time in the future when it might be appropriate
| > to do IO.  It happens right now.  Yet the literature
| > gives the impression that the IO monad in particular
| > is a clever trick to preserve referential transparency
| > by gathering up all the IO actions, but not necessarily
| > actually *performing* them.  Then the Haskell runtime
| > holds its nose and *performs* them when necessary.0
|
| The *conceptual* model for the IO monad is that "main" returns a big
| IO action which is then evaluated by the Haskell runtime.
|
| As a practical matter, this usually behaves the same as if <- actually
| did evaluation.  (It doesn't.  It binds monadic expressions together,
| and is a convenient way to use the (>>=) operator.)  The one
| difference is its interaction with Haskell equations (a = b); since
| those are more or less macro definitions, assigning e.g. an expression
| of type IO String to such a "macro" will cause the expression to be
| substituted wherever the "macro" is used.
|
| IO is a very atypical monad, by the way.  Someone pointed you earlier
| to the "IO Inside" page, which describes the internal tricks that make
| IO work.  I prefer to think of IO actions as partially applied
| functions, with the missing argument being a "RealWorld" that is
| hidden inside the IO monad.  (think:  IO a = State RealWorld a.  This
| isn't quite correct because the state also has IORefs inside it.)
|
| --
| brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
| system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
| electrical and computer engineering, carnegie mellon universityKF8NH
|
|
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Probably a trivial thing for people knowing Haskell

[Simon Peyton-Jones]

Folks,

I wonder if this worthwhile thread could move from haskell@haskell.org to 
[EMAIL PROTECTED]

The main Haskell list, haskell@haskell.org, is a low-bandwidth list for 
discussion starters and announcements.  The Haskell Cafe, by contrast, is a 
high-bandwidth list for detailed discussion.

We don't want to force subscribers to the main Haskell list to unsubscribe.

Thanks

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Friedrich
| Sent: 21 October 2008 08:18
| To: haskell@haskell.org
| Subject: Re: [Haskell] Probably a trivial thing for people knowing Haskell
|
| Udo Stenzel <[EMAIL PROTECTED]> writes:
|
| >> Friedrich wrote:
| >> >Ok to  be more concrete is the laziness "hidden" here?
| >> >
| >> >check_line line sum count =
| >> >let match = matchRegex regexp line
| >> >in case match of
| >> >   Just strs -> (sum + read (head strs) :: Integer, count +
| 1)
| >> >   Nothing -> (sum, count)
| >
| > Yes, part of it.  To see why, put yourself into the role of an evaluator
| > for your program.  An application of check_line will not be evaluated
| > until necessary, and it becomes necessary only if the result is bound to
| > a pattern (and that binding is needed for some reason).  At that point,
| > enough has to be evaluated to determine whether the result is actually a
| > pair or bottom.
| >
| > So what will you do?  The body of check_line is a case expression, so
| > you need to sufficiently evaluate its scrutinee.  You evaluate enough of
| > matchRegex to see whether the result is Nothing or Just.  Let's say it's
| > Just.  So you descent into the Just branch, and you see the result is a
| > pair (and not bottom).  The elements of the pair have not been
| > evaluated, there was no need to.  Also, the arguments to check_line have
| > not been evaluated, except for line.
| >
| > You need to force the evaluation of the elements of the result pair
| > whenever the pair itself is demanded, for example:
| >
| >> >check_line line sum count =
| >> >let match = matchRegex regexp line
| >> >in case match of
| >> >   Just strs -> ((,) $! (sum + read (head strs) :: Integer))
| $! count + 1
| >> >   Nothing -> ((,) $! sum) $! count)
| >
| > (The associativity of ($!) is inconvenient here.  I want
| > left-associative ($!).  Actually, a strict pair type would be even more
| > convenient here.)
| >
| > On recent GHC with bang-patterns, this short-cut works, too.  It's not
| > quite equivalent, because it will create unevaluated thunks, though they
| > won't pile up:
| >
| >> >check_line line !sum !count =
| >> >let match = matchRegex regexp line
| >> >in case match of
| >> >   Just strs -> (sum + read (head strs) :: Integer, count +
| 1)
| >> >   Nothing -> (sum, count)
|
| Ok, I followed the suggestions. Now I have the following code:
|
| module Main where
| import System
| import System.IO
| import System.Directory
| import System.IO.Error
| import Text.Regex
| import Control.Monad
|
| regexp = mkRegex ("([0-9]+) Windows ex")
|
| main = do
|files <- show_dir "[0-9].*"
|(sum,count) <- run_on_all_files (0,0) files
|let dd = (fromIntegral (sum::Integer))/ (fromIntegral (count::Int))
|in
| putStr("Download = " ++ show sum ++ " in " ++ show count ++ "
| days are " ++ show dd ++ " downloads/day\n")
|
|
|
|
| run_on_all_files (a,b) [] = return (a,b)
| run_on_all_files (a,b) (x:xs) = do (s,c) <- run_on(a,b) x
|run_on_all_files (s,c) xs
|
|
| run_on (a,b) file_name = do
| handle <- openFile file_name ReadMode
| (sum,count) <- for_each_line (a,b) handle
| hClose handle
| return ((sum,count))
|
| for_each_line (sum, count) handle = do
|l <- try (hGetLine handle)
|case l of
|   Left err
|   | isEOFError err -> return(sum,count)
|   | otherwise -> ioError err
|   Right line  -> do
|  let (nsum, ncount) =
| count_downloads line (sum, count)
|  for_each_line (nsum,ncount)
| handle
|
|
|
| count_downloads line (!sum, !count) =
| let match = matchRegex regexp line
| in case match of
|Just strs -> (sum + read (head strs) :: Integer, count + 1)
|Nothing -> (sum, count)
|
|
|
| show_dir regmatch = do
| files <- getDirectoryContents "."
| let reg = mkRegex regmatch in
|   return(filter (\file_name -> let fm =
| matchRegex reg file_name
|   in case fm of
|   Just strs -> True
|   Nothing -> False) files)
|

[Haskell] Functional programming job opening

[Simon Peyton-Jones]

Folks

Looking for a job in functional programming.  Here's one (at Microsoft):

http://members.microsoft.com/careers/search/details.aspx?JobID=E29D3886-A152-4D95-873D-8890EFB683AD&start=1&interval=10&SortCol=DatePosted

"We are seeking an experienced software development engineer who has mastered 
C/C++ and/or C# development and is now learning or is already an expert using 
F# (or Haskell). Our platform's logic engine is written in F# and we expect 
F#'s use to extend into many other areas of the platform. ... A strong interest 
in functional programming is necessary and as is comfort with theory-based 
software system designs."

Simon

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] FW: shootout on quad-core

[Simon Peyton-Jones]

Friends: an opportunity spotted by Ulf.

Simon

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf Wiger
Sent: 12 August 2008 16:33
Subject: shootout on quad-core

The famous language shootout now has a quad-core architecture:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all

So far, the maintainers have mainly focused on trying to get the build
environment to work, and no real agreement exists on how to
potentially expand the benchmark suite with multicore problems,
or perhaps how to handle alternative entries on existing benchmarks.

I think they welcome suggestions. I imagine that several different
categories exist:

- problems that naturally lend themselves to message-passing concurrency
- obviously data parallel algorithms
- problems that could be parallelized using a smart compiler


BR,
Ulf W

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] A problem with overlapping instances and super-classes

[Simon Peyton-Jones]

Yes indeed, this is one of those "well-known" (ie not at all well known, but 
folk lore) problems with overlapping instances, at least in programs where 
different instances can be in scope at different times.

It's discussed (not very clearly) in 
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap
 (..."GHC is conservative about committing to an overlapping instance"...)

I don't think you need a superclass. Suppose you put your function 'f' in 
module A

f :: Name a => a -> String
f x = name [x]

Then, f will commit to the Name [a] instance, because it uniquely matches.

But if, in module B you say

(name ['x'], f 'x')

you'll get two different answers, even though the former is just an unfolding 
of the latter.

If GHC can "see" both instance decls at the moment you declare f, it'll 
complain.  But while it can see only one, it doesn't.  It's the same with your 
instance decl 'instance Name a => C [a]'


This isn't great, but it's not really different than is the case for 
non-overlapping instances.  Suppose module B1 declares 'instance C T', and uses 
that instance; and module B2 declares a *different* 'instance C T', and uses 
that instance; and Main imports B1 and B2, but does not use either instance 
directly.  Then GHC will compile the program without complaint, although it is 
incoherent.


The only way I know to fix this would be to keep a history of all instance-decl 
matches performed during compilation, and check that they are still unique 
matches even when all instance decls in the program are taken into account. Or, 
to put it another (less modular) way: first find all instance decls, and only 
then compile the program.  But this destroys modular compilation.

Simon




| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iavor Diatchki
| Sent: 07 June 2008 23:12
| To: Haskell users
| Subject: [Haskell] A problem with overlapping instances and super-classes
|
| Hello,
| (you should be able to copy and paste the code in this email into two
| modules called A and B to try it out)
|
| > {-# LANGUAGE OverlappingInstances #-}
| > module A where
|
| This module, together with module 'B', illustrates a problem in some
| implementations of overlapping instances and their interaction with
| super-classes.  I tried GHC 6.8.2 and Hugs (September 2006).
| The problem is one of coherency---we can get a method to behave differently,
| when instantiated at the same type in the same module.  We need two modules to
| illustrate the problem because both Hugs and GHC perform some checking
| to avoid this problem.  Unfortunately, it seems that we can circumvent
| the checking by moving instances to a different module.
|
| Consider the class 'Name'. We are going to show how 'name' behaves
| differently when
| instantiated at the same type.
|
| > class Name a where name :: a -> String
| > instance Name Char where name _ = "Char"
| > instance Name a => Name [a] where name x = "[" ++ name (head x) ++ "]"
|
| We also define a super-class of 'Name' called 'C'.
| The methods of 'C' are not important---we use a single method that can
| be used to generate 'C' constraints.
|
| > class Name a => C a where c :: a -> ()
| > instance Name a => C [a] where c _ = ()
|
| The instance of 'C' is interesting: we have to check that the
| super-class constraint holds, so we need to prove (Name a => Name [a]).
| In the given context there is exactly one way to do this, namely, by
| using the corresponding instance for 'Name'.  Note, however, that
| in other modules there may be more specific instances for 'Names [a]'
| that could have been used.  This leads to a problem, as we show in module B.
|
|
| > {-# LANGUAGE OverlappingInstances, FlexibleInstances #-}
| > module B where
| > import A
|
| We add another instance for 'Name'---it overwrites the generic behavior
| on lists, with a specific instance for lists of characters:
|
| > instance Name [Char] where name _ = "String"
|
| Here is an example function that uses both 'c' and 'name' at the same
| type ('[a]', for some 'a').  This results in two constraints: (Name [a], C 
[a]).
| Implementations "simplify" this to just (C [a]) by using the fact that
| 'C [a]' is a super-class of 'Name [a]'.  Unfortunately this commits to using
| the "generic" instance for 'Name' on lists (the one in module 'A').
|
| > f x = name [x]
| >  where _ = c [x]
|
| Here is an example illustrating the problem:  the two components of the
| pair use 'name' at the same instance, '[Char]', but the first ends up
| using the generic instance, while the second uses the specific instance.
|
| > test = (f 'x', name ['x'])
|
| GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
| Loading package base ... linking ... done.
| [1 of 2] Compiling A( A.lhs, interpreted )
| [2 of 2] Compiling B( B.lhs, interpreted )
| Ok, modules loaded: A, B.
| *B> test
| ("[Char]","

[Haskell] A chance to share your experience

[Simon Peyton-Jones]

Friends

I know for a fact that many of you are using Haskell successfully for real 
applications.  Yet none of you have sent me an offer of a presentation at the 
Commercial Users of Functional Programming workshop, which happens in late 
Sept.  I'm the program co-chair, and I confidently expecting several Haskell 
offers... but not one so far.  I am sad.  I am very sad.

Make me happy!  I'm sure you are very busy making your business work.  But 
think what fun it'd be to share your experience with others, meet other people 
with similar experiences, recruit bright students to your company...

Happily, there is still time.  The deadline for offers is 2nd June.  All we 
need by then is a short summary of what you think you might say.  You don't 
have to write a paper (not now, not ever). Your presentation does not have to 
be highly technical. On the contrary, the emphasis is on the process issues 
that surround functional programming: convincing management, changes to 
software development, testing, benefits, costs, successes, concerns.

I'm going to the Lake District for a week's holiday next week (it's half term 
in the UK).  Please send me a lovely full mailbox to come back to.  The CFP is 
below, and at http://cufp.galois.com/.

best wishes

Simon



  Commercial Users of Functional Programming Workshop (CUFP) 2008
26 September 2008, Victoria, British Columbia

== CALL FOR PRESENTATIONS ==

 Presentation proposals due 2 June 2008

 http://cufp.functionalprogramming.com
   Functional Programming As a Means, Not an End

  Sponsored by SIGPLAN
Co-located with ICFP 2008 
_

   Functional languages have been under academic development for over 25
   years, and remain fertile ground for programming language research.
   Recently, however, developers in industrial, governmental, and open
   source projects have begun to use functional programming successfully
   in practical applications. In these settings, functional programming
   has often provided dramatic leverage, including whole new ways of
   thinking about the original problem.

   The goal of the CUFP workshop is to act as a voice for these users of
   functional programming. The workshop supports the increasing viability
   of functional programming in the commercial, governmental, and
   open-source space by providing a forum for professionals to share
   their experiences and ideas, whether those ideas are related to
   business, management, or engineering. The workshop is also designed to
   enable the formation and reinforcement of relationships that further
   the commercial use of functional programming.

Speaking at CUFP

   If you use functional programming as a means, rather than as an end,
   we invite you to offer to give a talk at the workshop. Alternatively,
   if you know someone who would give a good talk, please nominate them!

   Talks are typically 30-45 minutes long, but can be shorter. They aim
   to inform participants about how functional programming played out in
   real-world applications, focusing especially on the re-usable lessons
   learned, or insights gained. Your talk does not need to be highly
   technical; for this audience, reflections on the commercial,
   management, or software engineering aspects are, if anything, more
   important. You do not need to submit a paper!

   If you are interested in offering a talk, or nominating someone to do
   so, send an e-mail to jim (dot) d (dot) grundy (at) intel (dot) com or
   simonpj (at) microsoft (dot) com by 2 June 2008 with a short
   description of what you'd like to talk about or what you think your
   nominee should give a talk about. Such descriptions should be about
   one page long.

Program Plans

   CUFP 2008 will last a full day and feature an invited presentation
   from Michael Hopcroft, the product unit manager for the forthcoming
   release of Microsoft Visual Studio F#. Additionally, the program
   will include a mix of presentations and discussion sessions. Topics
   will range over a wide area, including:
 * Case studies of successful and unsuccessful uses of functional
   programming;
 * Business opportunities and risks from using functional languages;
 * Enablers for functional language use in a commercial setting;
 * Barriers to the adoption of functional languages, and
 * Mitigation strategies for overcoming limitations of functional
   programming.

   There will be no published proceedings, as the meeting is intended to
   be more a discussion forum than a technical interchange.

Program Committee

 * Lennart Augustsson 
 * Matthias Blume 
 * Adam Granicz 
 * Jim Grundy (co-chair) 
 * John Lalonde 
 * Andy Martin 
 * Yaron Min

RE: [Haskell] Change of Editor HCAR (Haskell Communities and Activities Report)

[Simon Peyton-Jones]

Well done Janis!

And a massive thank you to you, Andres.  You are a hero.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andres Loeh
| Sent: 08 April 2008 14:27
| To: haskell@haskell.org
| Subject: [Haskell] Change of Editor HCAR (Haskell Communities and Activities 
Report)
|
| Dear Haskellers.
|
| The Haskell Communities and Activities Report (HCAR) for short is a
| collection of status reports and news items from projects, groups,
| companies, and individuals that appears twice per year.
|
| As of now, the latest issue is from December 2007 and available from
| http://haskell.org/communities. I have been the editor of the report for
| the last six editions, and have recently been looking for a successor.
| It is my pleasure to announce that
|
|   Janis Voigtlaender, Technical University of Dresden
|
| has declared himself willing to perform this task,
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] FW: [TYPES/announce] DEFUN08: Call for Talks & Tutorials (co-located w/ ICFP08)

[Simon Peyton-Jones]

Folks,

ICFP is growing a Functional Programming Developer Conference!  It'll sit 
back-to-back with ICFP, with the Commercial Users of Functional Programming 
workshop as part of it.

As well as CUFP, though, there'll be tutorials and presentations about
libraries
tools
programming techniques

The call below invites you to offer such a talk or tutorial.   More details 
below.  You don't have to write a paper -- you just have to have a cool and 
*useful* library or tool that you'd like to show to others.

Step up!  Deadline for offers is 27 June, so you have time.  But don't leave it 
too long.

Simon


 Call for Talks and Tutorials
 ACM SIGPLAN 2008 Developer Tracks on Functional Programming
http://www.deinprogramm.de/defun-2008/
 Victoria, BC, Canada, 25, 27 September, 2008
   The workshop will be held in conjunction with ICFP 2008.
   http://www.icfpconference.org/icfp2008/

Important dates

Proposal Deadline: June 27, 2008, 0:00 UTC
Notification:  July 14, 2008

DEFUN 2008 invites functional programmers who know how to solve
problems with functional prorgamming to give talks and lead tutorials
at the The ICFP Developer Tracks.

We want to know about your favorite programming techniques, powerful
libraries, and engineering approaches you've used that the world
should know about and apply to other projects. We want to know how to
be productive using functional programming, write better code, and
avoid common pitfals.

We invite proposals for presentations in the following categories:

How-to talks: 45-minute "how-to" talks that provide specific
  information on how to solve specific problems using functional
  programming. These talks focus on concrete examples, but provide
  useful information for developers working on different projects or in
  different contexts.

  Examples:
  - "How I made Haskell an extension language for SAP R/3."
  - "How I replaced /sbin/init by a Scheme program."
  - "How I hooked up my home appliances to an Erlang control system."
  - "How I got an SML program to drive my BMW."

General language tutorials
  Half-day general language tutorials for specific functional
  languages, given by recognized experts for the respective languages.

Technology tutorials Half-day tutorials on techniques, technologies,
  or solving specific problems in functional programming

  such as:
  - how to make the best use of specific FP programming techniques
  - how to inject FP into a development team used to more conventional
technologies
  - how to connect FP to existing libraries / frameworks / platforms
  - how to deliver high-performance systems with FP
  - how to deliver high-reliability systems with FP

Remember that your audience will include computing professionals who
are not academics and who may not already be experts on functional
programming.

Presenters of tutorials will receive free registration to ICFP 2008.

Submission guidelines

Submit a proposal of 150 words or less for either a 45-minute talk
with a short Q&A session at the end, or a 300-word-or-less proposal
for a 3-hour tutorial, where you present your material, but also give
participants a chance to practice it on their own laptops.

Some advice:
- Give it a simple and straightforward title or name; avoid fancy
  titles or puns that would make it harder for attendees to figure out
  what you'll be talking about.
- Clearly identify the level of the talk: What knowledge should people
  have when they come to the presentation or tutorial?
- Explain why people will want to attend:
  is the language or library useful for a wide range of attendees? Is
  the pitfall you're identifying common enough that a wide range of
  attendees is likely to encounter it?
- Explain what benefits attendees are expected to take home to their
  own projects.
- For a tutorial, explain how you want to structure the time, and what
  you expect to have attendees to do on their laptops. List what
  software you'll expect attendees to have installed prior to coming.

Submit your proposal in plain text electronically to
defun-2008-submission-AT-deinprogramm.de by the beginning of Friday,
June 27, Universal Coordinated Time.

Organizers
Kathleen Fisher AT&T Labs
Simon Peyton Jones  Microsoft Research
Mike Sperber (co-chair) DeinProgramm
Don Stewart (co-chair)  Galois
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Commercial Users of Functional Programming Workshop

[Simon Peyton-Jones]

  Commercial Users of Functional Programming Workshop (CUFP) 2008
26 September 2008, Victoria, British Columbia

== CALL FOR PRESENTATIONS ==

 Presentation proposals due 2 June 2008

 http://cufp.functionalprogramming.com
   Functional Programming As a Means, Not an End

  Sponsored by SIGPLAN
Co-located with ICFP 2008 
_

   Functional languages have been under academic development for over 25
   years, and remain fertile ground for programming language research.
   Recently, however, developers in industrial, governmental, and open
   source projects have begun to use functional programming successfully
   in practical applications. In these settings, functional programming
   has often provided dramatic leverage, including whole new ways of
   thinking about the original problem.

   The goal of the CUFP workshop is to act as a voice for these users of
   functional programming. The workshop supports the increasing viability
   of functional programming in the commercial, governmental, and
   open-source space by providing a forum for professionals to share
   their experiences and ideas, whether those ideas are related to
   business, management, or engineering. The workshop is also designed to
   enable the formation and reinforcement of relationships that further
   the commercial use of functional programming.

Speaking at CUFP

   If you use functional programming as a means, rather than as an end,
   we invite you to offer to give a talk at the workshop. Alternatively,
   if you know someone who would give a good talk, please nominate them!

   Talks are typically 30-45 minutes long, but can be shorter. They aim
   to inform participants about how functional programming played out in
   real-world applications, focusing especially on the re-usable lessons
   learned, or insights gained. Your talk does not need to be highly
   technical; for this audience, reflections on the commercial,
   management, or software engineering aspects are, if anything, more
   important. You do not need to submit a paper!

   If you are interested in offering a talk, or nominating someone to do
   so, send an e-mail to jim (dot) d (dot) grundy (at) intel (dot) com or
   simonpj (at) microsoft (dot) com by 2 June 2008 with a short
   description of what you'd like to talk about or what you think your
   nominee should give a talk about. Such descriptions should be about
   one page long.

Program Plans

   CUFP 2008 will last a full day and feature an invited presentation
   from Michael Hopcroft, the product unit manager for the forthcoming
   release of Microsoft Visual Studio F#. Additionally, the program
   will include a mix of presentations and discussion sessions. Topics
   will range over a wide area, including:
 * Case studies of successful and unsuccessful uses of functional
   programming;
 * Business opportunities and risks from using functional languages;
 * Enablers for functional language use in a commercial setting;
 * Barriers to the adoption of functional languages, and
 * Mitigation strategies for overcoming limitations of functional
   programming.

   There will be no published proceedings, as the meeting is intended to
   be more a discussion forum than a technical interchange.

Program Committee

 * Lennart Augustsson 
 * Matthias Blume 
 * Adam Granicz 
 * Jim Grundy (co-chair) 
 * John Lalonde 
 * Andy Martin 
 * Yaron Minsky 
     * Simon Peyton Jones (co-chair) 
 * Ulf Wiger 

   This will be the fifth CUFP, for more information - including reports
   from attendees of previous events - see the workshop web site:
   http://cufp.functionalprogramming.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"CUFP" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/cufp?hl=en
-~--~~~~--~~--~--~---

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Extensible records: Static duck typing

[Simon Peyton-Jones]

So to clarify that statement. Honestly the number one problem I have with the 
current records system is that labels share the same namespace. This makes 
interfacing with any C library using structs quite painful. This is why I say 
that I don't really care which gets implemented. The current system is 
*painful* IMO, so anything which improves on it would be welcome (even if just 
puts the record accessors in a per-record namespace, where with syntactic sugar 
to avoid having to qualify it).

You do know about: 
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields
don't you?

S
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Extensible records: Static duck typing

[Simon Peyton-Jones]

This sort of disagreement means that nothing gets done. After my
experience with the wiki page, I don't believe anything will get done
until one of the core ghc developers makes some arbitrary decisions
and implements whatever they want to, which will then eventually
become part of the standard by default.


This is the sort of situation where a "benign dictator" is needed. I have no 
strong feelings about which of all of these (all very good) proposals get 
implemented, but I do have a strong opinion that the lack of "proper" records 
is hurting Haskell quite a bit.

Any of them will do, just get it in there! I'm assuming that Simon {PJ,M} et 
al. won't make an obviously terrible choice, and GHC seems to be the de facto 
standard anyway, so if they just implemented something in GHC that would be 
good enough for me, and a shoe-in for a future standard.

Since you are taking my name in vain, I had better respond!  I wish I felt as 
confident of my good taste as you do. My last attempt to implement records 
(with Umut Acar, more or less the design in the "proposal for records" paper) 
involved rather significant changes to the type checker, and I was reluctant to 
commit to them without stronger evidence that it was a good design.

I'm not so despondent about the Wiki page. It's already a good start.  Don't 
give up too soon!

You say that "lack of proper records is hurting Haskell".   I think it'd help 
to give much more structure to that statement.  "proper records" means 
different things to different people.   After all Haskell already has somethng 
you can call "records" but they obviously aren't "proper" for you.

So it might be interesting to do several things.

1.  List the interested parties.  The Wiki page doesn't say who's interested in 
this so it's hard to judge whether the "hurting" is a widely held opinion or 
not.

2. List the possible features that "records" might mean.  For example:

* Anonymous records as a type.  So {x::Int, y::Bool} is a type.  (In 
Haskell as it stands, records are always associated with a named data type.

* Polymorphic field access.  r.x accesses a field in any record with 
field x, not just one record type.

* Polymorphic extension

* Record concatenation

* Are labels first-class?

* etc
Give examples of why each is useful.   Simply writing down these features in a 
clear way would be a useful exercise.  Probably some are "must have" for some 
people, but others might be optional.

3.  Cross-tabulate, for each of the current proposals, say which features they 
have.

4. Reflect on how invasive each proposal would be, given the existence of type 
functions.


Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Why functional programming matters

[Simon Peyton-Jones]

Friends

Over the next few months I'm giving two or three talks to groups of *non* 
functional programmers about why functional programming is interesting and 
important.  If you like, it's the same general goal as John Hughes's famous 
paper "Why functional programming matters".

Audience: some are technical managers, some are professional programmers; but 
my base assumption is that none already know anything much about functional 
programming.

Now, I can easily rant on about the glories of functional programming, but I'm 
a biased witness -- I've been doing this stuff too long.  So this message is 
ask your help, especially if you are someone who has a somewhat-recent 
recollection of realising "wow, this fp stuff is so cool/useful/powerful/etc".

I'm going to say some general things, of course, about purity and effects, 
modularity, types, testing, reasoning, parallelism and so on. But I hate 
general waffle, so I want to give concrete evidence, and that is what I 
particularly want your help with.  I'm thinking of two sorts of "evidence":


1. Small examples of actual code. The goal here is (a) to convey a visceral 
idea of what functional programming *is*, rather than just assume the audience 
knows (they don't), and (b) to convey an idea of why it might be good.  One of 
my favourite examples is quicksort, for reasons explained here: 
http://haskell.org/haskellwiki/Introduction#What.27s_good_about_functional_programming.3F

But I'm sure that you each have a personal favourite or two. Would you like to 
send them to me, along with a paragraph or two about why you found it 
compelling?  For this purpose, a dozen lines of code or so is probably a 
maximum.


2. War stories from real life.  eg "In company X in 2004 they rewrote their 
application in Haskell/Caml with result Y".  Again, for my purpose I can't tell 
very long stories; but your message can give a bit more detail than one might 
actually give in a presentation.  The more concrete and specific, the better.  
E.g. what, exactly, about using a functional language made it a win for you?


If you just reply to me, with evidence of either kind, I'll glue it together 
(regardless of whether I find I can use it in my talks), and put the result on 
a Wiki page somewhere.  In both cases pointers to blog entries are fine.

Quite a lot of this is FP-ish rather than Haskell-ish, but I'm consulting the 
Haskell mailing lists first because I think you'll give me plenty to go on; and 
because at least one of the talks *is* Haskell-specific.  However, feel free to 
reply in F# or Caml if that's easier for you.

Thanks!

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Ancient, but still having fun

[Simon Peyton-Jones]

Friends,

It's Friday 18 January 2008, which makes it my 50th birthday.  I spent part of 
the day happily polishing Geoff Mainland's patch that adds quasi-quoting to 
GHC, and committing it to the GHC HEAD.

I'm happy to say that this is increasingly the story: more and more people are 
getting involved with making GHC into a better compiler.  Better still, many 
more people are involved in making Haskell a successful and 
increasingly-influential language.  I'm boggled by the sheer number of 
libraries that are announced these days in each issue of the Haskell Weekly 
(sic) News.  And for the first time I'm getting invitations out of the blue to 
speak about Haskell at mainstream professional-developer conferences.  Suddenly 
Haskell is cool.

Ancient or not, I'm still having a terrific time in this community.  When I 
first became addicted to functional programming, as a result of Arthur Norman's 
4-lecture course, and David Turner's SK-combinator papers, I never dreamt of 
what a wild and fascinating ride it would turn out to be.

Thank you all!

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Should the following program be accepted by ghc?

[Simon Peyton-Jones]

| I have been playing with ghc6.8.1 and type families and the following
| program is accepted without any type-checking error:

Martin's comments are spot on.

FWIW, in the HEAD -- as Stefan says, type families are not *supposed* to work 
in 6.8.1 -- your program gives

TF.hs:9:7:
Couldn't match expected type `a' against inferred type `b'
  `a' is a rigid type variable bound by
  the type signature for `c' at TF.hs:8:7
  `b' is a rigid type variable bound by
  the type signature for `c' at TF.hs:8:15
  Expected type: a :=: b
  Inferred type: b :=: b
In the expression: Eq
In the definition of `c': c Eq = Eq

That's fair enough.  If you change K to be a 'data family', then decomposition 
works, and the program compiles.

Bugs in type families against the HEAD are, as Don says, highly welcome.

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] 2nd ANNOUNCE: HCAR 12/2007

[Simon Peyton-Jones]

Thank you Andres!  As always it's amazing how much is going on in Haskell land, 
and running the Haskell Communities and Activities Report is a real service to 
our community.  You are a star.

Everyone else: I see that Andres would like to hand on the HCAR editor-ship to 
someone else.  Get in touch with him -- don't be shy!  This would be a great 
way for you to contribute.

Simon

| -Original Message-
| From: Andres Loeh
| Sent: 08 January 2008 22:49
| To: haskell@haskell.org
| Subject: [Haskell] 2nd ANNOUNCE: HCAR 12/2007
|
| Hi everyone.
|
| [For everyone who missed the first announcement because they were
| already in the holidays ...]
|
| The December 2007 edition of the Haskell Communities and Activities
| Report is out and available for download from
|
|   http://haskell.org/communities
|
| Cheers,
|   Andres

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] garbage collection of Concurrent Haskell threads?

[Simon Peyton-Jones]

The GC discards an MVar when there are only blocked readers on it.   But there 
can be any number of blocked readers.  So long as the read remains in the 
future, however, the GC doesn't recover it, because it has no way to know that 
the thread will only read it and not write it.

Your idea of splitting the MVar into two halves, a read end and a write end, 
might well improve this situation somewhat.

But, like finalisers, it's dangerous to rely on reachability arguments for 
anything that's really important.  Boehm's article on finalisers explains why.  
My guess is that the same remarks would apply to MVars.

Simon

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott
Sent: 24 December 2007 18:49
To: Simon Peyton-Jones
Cc: haskell@haskell.org
Subject: Re: [Haskell] garbage collection of Concurrent Haskell threads?

Thanks, Simon.  If I understand the mechanism you're describing, it discards 
readers of an empty MVar when there are no other references to the MVar 
*because* the MVar can never get written.  And if there are other readers but 
no writers, then I'm guessing GC wouldn't know that, and none of the readers 
get discarded.  Is that so?

I think Baker & Hewitt's trick was analogous to discarding writers of an 
already full MVar when there are readers (readMVar) but no takers (takeMVar).  
(Though not quite, since readMVar is implemented via takeMVar & putMVar.)  I 
guess that effectively means IVars instead of MVars.

In either direction (blocked reader or blocked writer), the interface of MVars 
(or IVars) would seem to prevent an accurate analysis, since GC wouldn't know 
whether a Var reference was for reading or writing.  Right?  A simple solution 
might be to hide the Var itself and instead expose reader and writer halves.  
If there's an analysis problem at all, does that solution make sense?

Cheers,  - Conal
On Dec 24, 2007 1:02 AM, Simon Peyton-Jones <[EMAIL PROTECTED]<mailto:[EMAIL 
PROTECTED]>> wrote:

GHC already garbage-collects threads that are blocked on an MVar that is 
otherwise inaccessible (and hence cannot be updated).  More precisely, GHC 
sends the thread an asynchronous exception (ThreadBlocked or something), so 
that it has a chance to clean up.



So perhaps the GC you want is already implemented?

Simon



From: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> [mailto:[EMAIL 
PROTECTED]<mailto:[EMAIL PROTECTED]>] On Behalf Of Conal Elliott
Sent: 24 December 2007 00:15
To: haskell@haskell.org<mailto:haskell@haskell.org>
Subject: [Haskell] garbage collection of Concurrent Haskell threads?



The classic paper "The Incremental Garbage Collection of Processes" 
(http://citeseer.ist.psu.edu/baker77incremental.html) describes "futures" and 
how particularly garbage collecting them when their pending result is no longer 
referenced.  I've been playing with an implementation of futures in Concurrent 
Haskell ( http://haskell.org/haskellwiki/Reactive), using MVars, and I'm 
stumped about how to GC non-winning threads in a race between futures 
("parallel or").  I'm having winner kill loser, which seems to work fine, 
though is potentially dangerous w.r.t locked resources.  Still, the elegance of 
a GC-based solution appeals to me.  Has anyone explored process GC ideas for 
Concurrent Haskell (or STM)?

Futures are implemented using Concurrent Haskell's MVars.  I first tried using 
STM and TVars, simply using orElse to implement mappend for futures.  However, 
I didn't see how to avoid nesting "atomically", which yielded a run-time error. 
 If anyone has ideas about using STM & TVars for futures, I'd love to hear.

Thanks,  - Conal


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] garbage collection of Concurrent Haskell threads?

[Simon Peyton-Jones]

GHC already garbage-collects threads that are blocked on an MVar that is 
otherwise inaccessible (and hence cannot be updated).  More precisely, GHC 
sends the thread an asynchronous exception (ThreadBlocked or something), so 
that it has a chance to clean up.

So perhaps the GC you want is already implemented?

Simon

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott
Sent: 24 December 2007 00:15
To: haskell@haskell.org
Subject: [Haskell] garbage collection of Concurrent Haskell threads?

The classic paper "The Incremental Garbage Collection of Processes" 
(http://citeseer.ist.psu.edu/baker77incremental.html) describes "futures" and 
how particularly garbage collecting them when their pending result is no longer 
referenced.  I've been playing with an implementation of futures in Concurrent 
Haskell ( http://haskell.org/haskellwiki/Reactive), using MVars, and I'm 
stumped about how to GC non-winning threads in a race between futures 
("parallel or").  I'm having winner kill loser, which seems to work fine, 
though is potentially dangerous w.r.t locked resources.  Still, the elegance of 
a GC-based solution appeals to me.  Has anyone explored process GC ideas for 
Concurrent Haskell (or STM)?

Futures are implemented using Concurrent Haskell's MVars.  I first tried using 
STM and TVars, simply using orElse to implement mappend for futures.  However, 
I didn't see how to avoid nesting "atomically", which yielded a run-time error. 
 If anyone has ideas about using STM & TVars for futures, I'd love to hear.

Thanks,  - Conal


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Nested guards?

[Simon Peyton-Jones]

| Note that Clean also supports nested guards. See section 3.3 of the
| Clean language report:
|
| http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf

Interesting, I didn't know that.

But (a) Clean guards don't bind, and pattern guards that bind was where this 
thread started.   And (b) the Clean manual says: "To ensure that at least one 
of the alternatives of a nested guard will be successful, a nested guarded 
alternative must always have a 'default case' as last alternative".  That's a 
pity.  The main point about guards is that failure means "go on to the next 
equation", a semantics that they could have chosen I guess.

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Nested guards?

[Simon Peyton-Jones]

Indeed this makes sense.  See Section 3 of
http://research.microsoft.com/~simonpj/Papers/pat.htm

It's really the syntactic/notational problem that has put me off every doing 
something like this.  I just couldn't come up with a compelling syntax.  (The 
syntax GHC uses has the great merit that it's identical to that for list 
comprehensions.)

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iavor Diatchki
| Sent: 04 December 2007 19:42
| To: Haskell users
| Subject: [Haskell] Nested guards?
|
| Hi,
| Lately I have been using pattern guards more than usual and I find
| that occasionally I need to nest them (i.e., I have alternatives with
| a common prefix).  This seems to happen when I need to do some
| preliminary checking, followed by some decision making.  Here is an
| example:
|
| server text
|| Just xs <- parse text
|,   | "field1" `elem` xs   = ... do one thing ...
|| "field2" `elem` xs   = ... do something else ...
|
| server  _ = ... invalid request ...
|
| As far as I can see this should be a fairly simple change to the
| pattern bindings extension.   Would anyone else find this a useful
| feature, and if so what syntax should we use?
|
| -Iavor
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] IVars

[Simon Peyton-Jones]

But since the read may block, it matters *when* you perform it.  For example if 
you print "Hello" and then read the IVar, you'll block after printing; but if 
you read the IVar and then print, the print won't come out.  If the operation 
was pure (no IO) then you'd have a lot less control over when it happened.

Simon

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lennart 
Augustsson
Sent: 04 December 2007 08:19
To: Conal Elliott
Cc: haskell@haskell.org
Subject: Re: [Haskell] IVars

Good question.  That must be a matter of taste, because as you say the read 
will always produce the same result.  But it sill is a bit of a strange 
operation.

  -- Lennart
On Dec 4, 2007 6:25 AM, Conal Elliott < [EMAIL PROTECTED]> wrote:
Oh.  Simple enough.  Thanks.

Another question:  why the IO in readIVar :: IVar a -> IO a, instead of just 
readIVar :: IVar a -> a?  After all, won't readIVar iv yield the same result 
(eventually) every time it's called?

On Dec 3, 2007 12:29 AM, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
You can make them from MVars.
On Dec 2, 2007 8:03 PM, Conal Elliott <[EMAIL PROTECTED]> wrote:
what became of (assign-once) IVars?  afaict, they were in concurrent haskell 
and now aren't.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Bang patterns and declaration order

[Simon Peyton-Jones]

Right.  Still, it's a point worth noting. I've added a short section to
http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
which in turn is referred to from the GHC manual.

Simon

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lennart 
Augustsson
Sent: 18 November 2007 22:47
To: Derek Elkins
Cc: Haskell users
Subject: Re: [Haskell] Bang patterns and declaration order

I totally agree with Derek.  Which exception you get can vary with compiler 
version, compiler flags, time of day, phase of the moon, ...
It will be one in a set of exceptions, but you don't know which one.

  -- Lennart
On Nov 18, 2007 8:34 PM, Derek Elkins <[EMAIL PROTECTED]> wrote:
On Sun, 2007-11-18 at 12:11 -0800, Iavor Diatchki wrote:
> Hello,
>
> I was playing around with "bang patterns" and I noticed that
> when combined with asynchronous exceptions they can lead to
> programs where the order of the declarations in a binding
> group is important!  Here is an example:
>
> > import Control.Exception
> > import Prelude hiding (catch)
> >
> > main = putStrLn =<< eval_order
> >
> > test = "no exception"
> >   where !_ = error "top down"
> > !_ = error "bottom up"
> >
> > eval_order = evaluate test `catch` \e ->
> >case e of
> >  ErrorCall txt -> return txt
> >  _ -> throw e
>
> Of course, this is a contrived exampled but, as far as I know,
> this was not possible in Haskell before (if anyone has an example
> to the contrary please send it to the list).
>
> By the way, with GHC 6.8.1 the above program prints "bottom up".
> This means that when there are multiple "banged" bindings they
> are evaluated starting with the last one in the text.  I imagine
> than in most programs this is not particularly important, but
> it seems to me that it would be a bit nicer if we were to adjust
> the translation so that bindings were evaluated top to bottom
> (e.g., like in ML).
The whole point of the "imprecise exceptions" paper was that any
exception may be returned when multiple ones could be.  There is no
reason why the bindings should be evaluated top-down.  If you are
relying on the order the bindings are evaluated you are doing something
very, very wrong.  Should we also specify what exception should be
thrown for  error "left-right" + error "right-left" ?

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] [Fwd: undecidable & overlapping instances: a bug?]

[Simon Peyton-Jones]

Good point Mark!  And yes, the bug is still open Iavor.

The trouble is that
a) the coverage condition ensures that everything is well behaved
b) but it's too restrictive for some uses of FDs, notably the MTL library
c) there are many possibilities for more generous conditions, but
the useful ones all seem complicated

Concerning the last point I've dumped the current brand leader for (c) into 
http://hackage.haskell.org/trac/ghc/ticket/1241#comment:15.

Better ideas for (c) would be welcome.

Simon

| -Original Message-
| From: Iavor Diatchki [mailto:[EMAIL PROTECTED]
| Sent: 17 October 2007 19:19
| To: Mark P Jones
| Cc: Simon Peyton-Jones; Haskell users; Tom Schrijvers; Martin Sulzmann
| Subject: Re: [Haskell] [Fwd: undecidable & overlapping instances: a bug?]
|
| Hi,
| Mark is quite right, and there is a bug report that documents the problem:
| http://hackage.haskell.org/trac/ghc/ticket/1241
| The trac ticket is targeting GHC 6.8 but the ticket is still open.  I
| have not had a chance to try out any of the 6.8 release candidates
| yet, so I am not sure if there have been changes in this area.
| -Iavor
|
| On 10/17/07, Mark P Jones <[EMAIL PROTECTED]> wrote:
| > Simon Peyton-Jones wrote:
| > > | I am quite intrigued at the behaviour examplified in the attached
| module.
| > > | It's true I am a newbie and probably don't quite get the whole
| consequence
| > > | spectrum of -fallow-undecidable-instances, but why providing that dummy
| > > | instance (commented out) get the thing to compile?
| > >
| > > Sorry I must have missed this.  It's a nice example of the trickiness of
| > > functional dependencies.  Here's what is happening.  First a very cut-
| down
| > > version of your example:
| > >
| > > class Concrete a b | a -> b where
| > > bar :: a -> String
| > >
| > > instance (Show a) => Concrete a b
| > >
| > > wib :: Concrete a b => a -> String
| > > wib x = bar x
| > >
| > > Now consider type inference for 'wib'. ...
| >
| > Hold on a second!  There's a more serious problem here, before we
| > get to 'wib'.  The definition of class Concrete asserts that there
| > is a dependency from a to b.  In other words, it promises that, for
| > any a, there must be at most one b such that Concrete a b holds.
| > But then the following instance declaration says that Concrete a b
| > can be instantiated for *any* a and b, the only proviso being that a
| > is an instance of Show.  In particular, there is no functional
| > relationship between the parameters.  As such, these two
| > declarations are in direct conflict with one another!  To quote the
| > error message that Hugs produces, the "Instance is more general than
| > a dependency allows".
| >
| > I thought this must be a typo in your email, but then I discovered
| > that the ghci (6.6.1) installed on my machine accepts this code, at
| > least once the Concrete Bool Bool instance was added.  If the
| > instance declarations are not consistent with the functional
| > dependency, then improvement is unsound, and all bets are off!
| >
| > Further experiments suggest that this behavior occurs only when
| > the-fallow-undecidable-instances flag is specified.  But the reason you
| > need to check for consistency between instance declarations and
| > dependencies is to ensure soundness, not decidability.
| >
| > I don't know if this was the problem in the original example, but
| > perhaps we should debug this cut down version first :-)
| >
| > All the best,
| > Mark
| >
| > ___
| > Haskell mailing list
| > Haskell@haskell.org
| > http://www.haskell.org/mailman/listinfo/haskell
| >
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] [Fwd: undecidable & overlapping instances: a bug?]

[Simon Peyton-Jones]

| I am quite intrigued at the behaviour examplified in the attached module.
| It's true I am a newbie and probably don't quite get the whole consequence
| spectrum of -fallow-undecidable-instances, but why providing that dummy
| instance (commented out) get the thing to compile?

Sorry I must have missed this.  It's a nice example of the trickiness of 
functional dependencies.  Here's what is happening.  First a very cut-down 
version of your example:

class Concrete a b | a -> b where
bar :: a -> String

instance (Show a) => Concrete a b

wib :: Concrete a b => a -> String
wib x = bar x

Now consider type inference for 'wib'.  GHC figures out that the call of 'bar' 
gives rise to the constraint (Concrete p q), where x has type 'p'.  Ah, but x 
must have type 'a', so the constraint is (Concrete a q).

Now GHC tries to satisfy (Concrete a q) from (Concrete a b). If it applied 
improvement right away it'd succeed, but sadly it first looks at instances 
declarations.  Success: we can get (Concrete a q) from (Show a).  So it uses 
the instance decl and now we can't get (Show a) from (Concrete a b).


OK, so you found that adding
instance Concrete Bool Bool
fixed the problem. That's weird isn't it?  The reason is this. When GHC looks 
at the instance decls, it now sees *two* instance decls matching (Concrete a 
q), and so it declines for now to use either of them (since it's not clear 
which would be the right one).  Once it has finished with instance decls it 
tries improvement.  And, yes, it now sees that q=b, so all is well.


You might say that GHC should use improvement more vigorously, and perhaps 
you'd be right.  And indeed the upcoming GHC 6.8 does exactly that.

But it's a great example of the delicacy of type inference in the presence of 
equalities. I'm going to add it to GHC's test suite!

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Module system question

[Simon Peyton-Jones]

The H98 report is pretty clear about there being a single name space for type 
constructors and classes.  Yes, in certain circumstances it's unambiguous.  In 
Hugs, can you write
module M where
  class C a
  data C = MkC
  f :: C a =>  C -> C
which is also unambiguous.

I'm inclined to stick to the H98 story.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iavor Diatchki
| Sent: 15 October 2007 20:35
| To: haskell@haskell.org
| Subject: [Haskell] Module system question
|
| Hello,
|
| I have a question concerning Haskell's module system.
| Consider the following example which defines three modules A,B, and C:
|
| > module A where { data X = X }
| > module B where { class X a }
| > module C where { import A; import B; data Y = Y X }
|
| The question is: "Is there an ambiguity error in module C?".  It seems
| that the answer depends on how we interpret "ambiguous".  In the
| context of module C, the name X may refer to either the class defined
| in module B, or the datatype defined in module A.  Therefore, we could
| consider X to be ambiguous, and indeed, this is what happens in GHC
| 6.6.  On the other hand, the name X is used in a context where we are
| expecting a type constructor and not a class name, and therefore the
| name X could be unambiguously taken to refer to the datatype X, which
| is what seems to happen in Hugs.
|
| I like the Hugs behavior because it accepts more programs.  OTOH,
| GHC's behavior may be a bit simpler to explain and implement(?).   Any
| thoughts?
|
| -Iavor
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Fingerprints and hashing

[Simon Peyton-Jones]

Interesting! The associativity property is the kind of thing I was after.  
Except that I don't really care if FP(as ++ bs) = FP(as) `plusFP` FP(bs).  I 
only care that the latter is robust in the sense of having low probabilty of 
collision.  So the Rabin scheme does more than I really need (which is probably 
fine).

On page 1 he draws a distinction between fingerprinting and hashing, which 
relates to my last wish.  Does one need a different technique for the two, or 
is it enough to reduce the number of bits in the Rabin scheme, and thereby get 
a hashing scheme?

Strangely the paper gives no comparison with other fingerprinting schemes.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lauri Alanko
| Sent: 11 October 2007 11:27
| To: haskell
| Subject: Re: [Haskell] Fingerprints and hashing
|
| If compositionality is important, at least Rabin's fingerprints are
| worth considering: http://citeseer.ist.psu.edu/broder93some.html
|
| They have the neat property that the fingerprint of a concatenation of
| strings can be cheaply computed from the fingerprints of the
| constituents. I think this effectively means that the plusFP operation
| can be made associative, which might offer optimization opportunities.
|
| I remember implementing it some seven years ago when prototyping for a
| C implementation. The code is lost, though. I can give it a shot
| again, if this is considered a reasonable algorithm.
|
|
| Lauri
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Fingerprints and hashing

[Simon Peyton-Jones]

Dear Haskellers

Here's a challenge.

We are all familiar with the idea of an MD5 checksum, which provides a reliable 
"fingerprint" for a file, usually 128 bits or so.  If the file changes, the 
fingerprint is (almost) certain to do so too.  There are lots of techniques: 
CRC, shar?, MD5, etc.

For various applications (including identifying common sub-expressions, and 
version tracking in GHC), I'd like a Haskell library that supports simple 
fingerprint operations.

Below I give an informal specification of such a library.  I can think of any 
number of implementations, but I'd like one that is (a) robust and (b) 
efficient.  By "robust" I meant that with, say, a 128-bit fingerprint the 
chance of accidental collision is truly low; a non-robust implementation uses 
the 128-bit space in a non-uniform way [trivial example: gets stuck on zero].

Any takers?  I bet some of you have this already, in some form.

Simon



The module signature would be something like this:

  data Fingerprint
  instance Eq Fingerprint
  instance Ord Fingerprint

  initialPrint :: Fingerprint

  class Fingerprintable t where
fingerPrint :: t -> Fingerprint -> FingerPrint

  instance Fingerprintable Char
  instance Fingerprintable Int
  instance Fingerprintable Word32
  -- etc

The fingerPrint operation here is expressed in the traditional way: an 
accumulator (say 128 bits) into which one stuffs successive values (e.g. a byte 
stream).

However, very important, I also want a more compositional form:

  instance Fingerprintable Fingerprint

so that I can do something like

  fp :: Expr -> Fingerprint
  fp (App e1 e2) = fp e1 `fingerPrint` fp e2

Yes, I could thread the accumulator, thus:

  fp' :: Expr -> Fingerprint -> Fingerprint
  fp' (App e1 e2) p = fp' e1 (fp' e2 p)

but I can't *always* do that; or even if I can, I may already *have* a 
fingerprint for e1 in my hand, and it's painful to re-traverse e1.  Think of 
hash-consing.

An obvious implementation of "instance Fingerprintable Fingerprint" is to 
divide one fingerprint into words, and feed it into the other via the Word32 
instance.  But it's not clear to me whether or not that is robust.


(Incidentally, one could define the class thus:
  class Fingerprintable t where
fingerPrint :: t -> FingerPrint
plus
  plusFP :: Fingerprint -> Fingerprint -> Fingerprint
But I think it'd be less efficient if that was the only way, because of all 
those now-compulsory plusFP operations.)


I'd like one other thing: to be able to trade cost for accuracy.  I'd like a 
128-bit fingerprint with essentially zero chance of having two distinct values 
that map to the same fingerprint; and a one-word fingerprint that was a lot 
more efficient, but where collisions would be entirely possible (again 
hash-consing is an example).



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Haskell Applications - reg

[Simon Peyton-Jones]

Stefan's last point is the key one. GHC compiles into code that doesn't use 
call/return instructions.  Instead, it pushes explicit return addresses, and 
returns by doing an indirect jump.  I bet this isn't what your tool expects.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Stefan O'Rear
| Sent: 04 October 2007 01:15
| To: Ganesh Narayan
| Cc: haskell@haskell.org
| Subject: Re: [Haskell] Haskell Applications - reg
|
| On Thu, Oct 04, 2007 at 05:32:31AM +0530, Ganesh Narayan wrote:
| > [1] Am presently constructing the call graphs from disassembled application
| > binaries; resultant graph includes ghc runtime library calls.
|
| Not necessary a good idea - Haskell's purity gives the compilers great
| license to reorder and rearrange code, and the laziness causes the
| dynamic call graph to differ wildly from the static call graph even
| without without optimizations.  GHC's use of a private stack with very
| weird return conventions probably isn't helping either!
|
| Stefan
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Job programming in F#

[Simon Peyton-Jones]

Want to be paid to write functional programs?  My colleagues here at Cambridge 
are looking for you.  See below.

Simon

A position has arisen within our Applied Games Team in Cambridge for a Software 
Development Engineer (SDE).  The role of the SDE will be to design, implement 
and maintain solutions based on new technology in the very competitive web 
search and advertising arena. In this position you will be working closely with 
researchers to analyze very large data sets, and with product teams to have the 
research applied. Please see job description attached for full details.

Any machine learning or functional programming experience (particularly F#) is 
highly desirable, however not essential as training will be provided for the 
right candidate.

Background: We are establishing a virtual team for applied research between 
adCenter's Research & Mining group and Microsoft Research Cambridge's Applied 
Games group. The mission of the team is to conduct applied research into 
problems relevant for Microsoft's online advertisement business and to transfer 
resulting technology to adCenter.

1. Design, implement and maintain solutions.
2. Assist researchers to analyze data and provide rapid prototypes for new 
technology.
3. Transferring technology to product teams.

Knowledge, Skills and Experience
1) Essential Experience
* Three years SQL Server Programming experience.
* Three years .Net Programming experience.

2) Technical / Functional Skills
* Knowledge of SQL programming.
* Knowledge of C# and .Net programming.
* Experience with Agile methods

3) Personal Attributes / Interpersonal Skills
* Good communication skills ideally with some client facing experience.
* Self-motivated.
* Willingness to travel.
* Interest in cutting edge research

Special Requirements/Additional Information

Must be willing to live and work in the UK; but also be prepared to travel 
frequently to the US. Any machine learning or functional programming experience 
particularly F# is highly desirable but not essential as training will be 
provided for the right candidate.

To apply please send your current curriculum vitae (CV) to our Human Resources 
Department by email: [EMAIL PROTECTED]


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Swapping parameters and type classes

[Simon Peyton-Jones]

This thread is certainly interesting, but it would be better on [EMAIL 
PROTECTED]  The Haskell@haskell.org list is intended as a low-bandwidth list 
for announcements and the like.  Thanks!

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of Bas van Dijk
| Sent: 17 September 2007 20:17
| To: Mads Lindstrøm
| Cc: haskell@haskell.org
| Subject: Re: [Haskell] Swapping parameters and type classes
|
| On 9/17/07, Mads Lindstrøm <[EMAIL PROTECTED]> wrote:
| > Hi Bas
| >
| > Thank you for the answer.
| >
| > I tried to "fill in some blanks" in the example you gave. And mostly
| got
| > a lot of context reduction stack overflows :(
| >
| > Here is my example (a little closer to what I actually need):
| >
| > data Foo a b = Foo { first :: a, second :: b }
| >
| > class Bar (x :: * -> *) where
| > foo :: x a -> a
| >
| > instance Bar (Foo a) where
| > foo x = second x
| >
| > type family BarB a b :: * -> *
| > type instance BarB a b = Foo b
| >
| > instance Bar (BarB a b) where
| > foo x = second x -- this unexpectedly works!
| > --  foo x = first x  -- This unexpectedly gives context reduction
| stack overflow
| >
| > What surprises me is that I still need to look at `second`, even
| though
| > I use BarB. I thought I was swapping the parameters. Whats more
| changing
| > the line:
| >
| > type instance BarB a b = Foo b
| >
| > to
| >
| > type instance BarB a b = Foo a  -- the last letter changed
| >
| > has no effect.
| >
| >
| > Greetings,
| >
| > Mads Lindstrøm
| >
| > P.s. Why can we not just have the option of being explicit about
| which type parameters are applied? Something like:
| >
| > "instance Bar (apply a. Foo a b)" which would apply a and be
| identical to "instance Bar (Foo a)"
| > "instance Bar (apply b. Foo a b)" which would apply b and be what I
| am trying to achieve.
| >
| > It would seem a lot more natural to me. But maybe there are other
| reasons why type families are a better solution?
| >
| > I do not know if I use the right terminology when saying "apply".
| Please correct if there is more correct terms.
| >
| >
| > Bas van Dijk:
| > > On 9/16/07, Mads Lindstrøm <[EMAIL PROTECTED]> wrote:
| > > > But what if I want to "apply" the 'b' ? How do I do that ?
| > >
| > > The following uses type families (functions) and compiles under GHC
| HEAD:
| > >
| > > {-# OPTIONS_GHC -XTypeFamilies -XEmptyDataDecls -
| XTypeSynonymInstances #-}
| > >
| > > data Foo a b
| > >
| > > class Bar (x :: * -> *)
| > >
| > > instance Bar (Foo a)
| > >
| > > type family BarB a b :: * -> *
| > > type instance BarB a b = Foo b
| > >
| > > instance Bar (BarB a b)
| > >
| > >
| > > regards,
| > >
| > > Bas van Dijk
| >
| >
|
| Mads, my sollution was not correct.
|
| This is why:
|
| instance Bar (BarB a b)
|
| is equal to:
|
| instance Bar (Foo b)
|
| which is just equal to:
|
| instance Bar (Foo a)
|
| The 'b' in  'instance Bar (Foo b)' has nothing to do with the 'b' in
| 'Foo a b'. In fact the 'b' in 'BarB a b' is equal to the 'a' in 'Foo a
| b'.
|
| Sorry that I bothered you with this but like I said, it was late and I
| already consumed some wine. Not a good combination when programming
| ;-)
|
| Bas.
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Re: Numeric programming on toy problems in Haskell

[Simon Peyton-Jones]

Interesting though this thread is, it belongs on Haskell-café, or ghc-users, 
not the main Haskell announcement list.  Can I suggest that replies are 
directed to one of those places?

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of Isaac Dupree
| Sent: 12 September 2007 15:37
| To: haskell@haskell.org
| Subject: [Haskell] Re: Numeric programming on toy problems in Haskell
|
| Philip K.F. Hölzenspies wrote:
| > The GHC extensions are used, however,
| > because of laziness; i.e. automatic derivation of Enum, Num,
| > Fractional, Real and RealFrac. Without the GHC extensions, only Eq
| and
| > Ord can be derived automatically. If I'm wrong about this, please let
| > me know, because I would prefer a compiler independent solution as
| > well.
|
| Thank you for reminding me.  You can preferably use {-# LANGUAGE
| GeneralizedNewtypeDeriving #-} instead of {-# OPTIONS -fglasgow-exts
| #-}, to just enable the needed extension, although only GHC implements
| it currently  Or, you can explicitly write out each instance in the
| very straightforward way, which is portable (though a bit annoying and
| inefficient).  Or, I think there are tools that can automatically write
| such instances for you?
|
|
| > [...]
| >  At that time I could either have my own simplifier and
| > approximator, or I could link to other tools (maple, gnu something?).
| >
| > The idea was stalled, because I only use this for toy problems ;) If
| > someone feels inspired, feel free to take this module and rework. I'm
| > also open for suggestions on how to do this myself in case I ever
| > un-stall this ;)
|
| That is *a lot* more complicated. Beware of non-termination. I don't
| think every equality, every exactness, is observable (not sure whether
| a
| Num type like that offers the full power of the real numbers - if it
| does, then you have a turing-complete problem.)
|
| Whereas, the present inexactness means that the numerator and
| denominator don't tend to get so big that the computations are really
| slow.  (If MPFR could be used in Haskell, one could choose the desired
| precision rather than using whatever Double gives, I suppose)
|
| Making the type be "data" with fields Rational as well as whether it's
| exact, could be done (though I'm not entirely satisfied with, nor
| interested in, the "exact" concept, so it's just an idea).  Then you
| would not be able to use generalized newtype deriving, so you wouldn't
| ^_^
|
| Isaac
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] new SOE package and the annoucement of GLFW

[Simon Peyton-Jones]

Great!  Put it on the Hackage site?
http://hackage.haskell.org/packages/hackage.html

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul L
| Sent: 29 August 2007 20:50
| To: haskell
| Subject: [Haskell] new SOE package and the annoucement of GLFW
|
| Hi all,
|
| After much struggle to bring the SOE source to be compatible with the
| latest GHC, I'm pleased to announce that it's available at
|
|   http://www.haskell.org/soe
|
| It's has been tested on Windows (both XP and Vista), Linux and Mac OS
| X under GHC 6.6.1. The code now requires a Haskell package GLFW, an
| interface to the GLFW OpenGL Framework (http://glfw.sourceforge.net),
| which is an alternative to GLUT for OpenGL based programs.
|
| Most SOE code examples are not affected by this change except that
| they now make use of the included SOE.hs instead of the previous
| SOEGraphics module. The SOE.hs now handles all window and drawing
| activities through GLFW and OpenGL. The music part of SOE code has
| also been brought up to date.
|
| Please help to report bugs or suggestions if you have any. Help is
| also needed to make the GLFW Haskell package fully compatible with
| cross-platform Cabal installation steps.
|
| Regards,
| Paul Liu
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Commercial users of functional programming 2007: programe is published, registration open

[Simon Peyton-Jones]

Friends,

The program for the 2007 Commercial Users of Functional Programming workshop is 
now published.

http://cufp.galois.com/

The workshop is co-located with ICFP, and will be held in Freiburg, Germany, on 
4 October 2007.  We had a terrific response to our call for talks, and there 
are twelve (!) speakers describing commercial applications,  variously written 
in
Caml
Erlang
F#
Haskell
ML
Scheme

The talks are informal, and there are no proceedings.  We'll just have fun 
learning about functional programming used to solve real problems.  Do come!

Kathleen Fisher
Simon Peyton Jones
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Quantified class constraints (& back-chaining)

[Simon Peyton-Jones]

See also the paper that Ralf and I wrote about "Derivable type classes" (on my 
pubs page) which uses quantified constraints.

Quantified constraints would be another perfectly sensible extension.  GHC does 
not support them at the moment though.  I'm really not too sure how much work 
it'd be to add them; quite significant I suspect.

Simon

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott
Sent: 02 August 2007 01:29
To: haskell@haskell.org
Subject: [Haskell] Quantified class constraints (& back-chaining)

I'm developing a type constructor class and want the constraint forall a. 
Monoid (m a) (where m :: * -> * ), which is neither legal Haskell, nor 
supported by GHC.

As a work-around, I used the first encoding suggested in "Simulating Quantified 
Class Constraints" (Valery Trifonov, Haskell Workshop '03).  Add a type class

class Monoid_f m where
  mempty_f  :: forall a. m a
  mappend_f :: forall a. m a -> m a -> m a

and an instance *schema*

-- instance Monoid_f f where { mempty_f = mempty ; mappend_f = mappend }

to instantiate manually wherever necessary. For instance,

instance Monoid_f [] where { mempty_f = mempty ; mappend_f = mappend }


The paper's second approach is to replace the schema and multiple 
instantiations with a single instance.

instance Monoid_f f => Monoid (f a) where
  { mempty = mempty_f ; mappend = mappend_f }

As the paper points out,
Unfortunately, due to the type variable f in the head of the instance type, 
this declaration is not in Haskell 98; however, at least two implementations 
support extensions allowing such declarations.

Sadly, this solution runs into the problem of instance selection based only on 
head-matching, not back-chaining into constraints.  For instance, I'd like also 
to use the following "conflicting" declaration.

instance (Applicative f, Monoid a) => Monoid (f a) where
  mempty  = pure mempty
  mappend = liftA2 mappend

What's the state of thinking & doing with regard to universally quantified 
class constraints?

Note that hereditary Harrop formulas do include universally quantified goals.  
Less ambitiously, I think GHC's type-checker already deals with 
universally-quantified variables, so perhaps quantified constraints are not a 
great reach (just guessing).

  Cheers,  - Conal
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] type class instance selection & search

[Simon Peyton-Jones]

Conal

It certainly makes sense to do backward chaining, but I don't know any Haskell 
implementation that's tried it.  It'd be more complicated in the presence of 
functional dependencies, since we must "undo" any unifications done as a result 
of discarded searches, much like the "trail" in a Prolog implementation.

To be honest I can't see myself trying this anytime soon.  Because of the 
unification part, it'd be a significant structural change.  And one would need 
to dig into the theory to make sure that the algorithm was both sound and 
complete (finds all solutions).

Simon

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott
Sent: 31 July 2007 20:09
To: haskell@haskell.org
Subject: [Haskell] type class instance selection & search

I keep running into situations in which I want more powerful search in 
selecting type class instances.  One example I raised in June, in which all of 
the following instances are useful.

> instance (Functor g, Functor f) => Functor (O g f) where
>   fmap h (O gf) = O (fmap (fmap h) gf)

> instance (Cofunctor g, Cofunctor f) => Functor (O g f) where
>   fmap h (O gf) = O (cofmap (cofmap h) gf)

> instance (Functor g, Cofunctor f) => Cofunctor (O g f) where
>   cofmap h (O gf) = O (fmap (cofmap h) gf)

> instance (Cofunctor g, Functor f) => Cofunctor (O g f) where
>   cofmap h (O gf) = O (cofmap (fmap h) gf)

My understanding is that this sort of instance collection doesn't work together 
because instance selection is based only on the matching the head of an 
instance declaration (part after the "=>").  I'm wondering why not use the 
preconditions as well, via a Prolog-like, backward-chaining search for much 
more flexible instance selection?  Going further, has anyone investigated using 
Prolog as a model for instance selection?  Better yet, how about LambdaProlog ( 
http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog), which generalizes 
from Horn clauses to (higher-order) hereditary Harrop formulas, including 
(restricted but powerful) universals, implication, and existentials?  Once 
search is in there, ambiguity can arise, but perhaps the compiler could signal 
an error in that case ( i.e., if the ambiguity is not eliminated by further 
search pruning).

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] 3-yr post for language person

[Simon Peyton-Jones]

Tim Griffin is advertising a 3-year research associate position at the 
Cambridge Computer Lab, working on a project that seeks to design and implement 
a meta-language for the specification and implementation of correct Internet 
routing protocols.

He says "A PL person would be perfect".

Details here: 
http://www.admin.cam.ac.uk/offices/personnel/jobs/vacancies.cgi?job=2114

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] ANNOUNCE: Haskell Communities & Activities Report (12th ed., May 2007)

[Simon Peyton-Jones]

| On behalf of the many, many contributors, I am pleased to announce
| that the
|
|   Haskell Communities and Activities Report
|(12th edition, May 2007)
|
|  http://www.haskell.org/communities/
|
| is now available from the Haskell Communities home page in several
| PDF and HTML formats.

And on behalf of the many, many contributors I'd like to thank the one and only 
Andres for his work in putting the HCAR together.  It *is* a lot of work, but 
the HCAR is terrific glue for the Haskell community.  It's always a blast 
reading about the interesting things everyone else is up to.

Thanks, Andres!

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Commercial Users of Functional Programming: call for speakers

[Simon Peyton-Jones]

Folks,

This is just to remind you about the closing date for offers of talks at the

2007 Commercial Users of Functional Programming workshop
http://cufp.galois.com/

The closing date is 1st June, in a couple of weeks.  The workshop itself is on 
Oct 4, colocated with ICFP at Freiburg, Germany.

CUFP is a workshop for people who use functional programming (in some guise), 
because it's the best way to get the job done, rather than because it's a cool 
research topic.

It's a very informal workshop.  No papers, no proceedings -- just stand up and 
tell us how it is for you.  But you have to tell us in advance so we can plan 
the day.  Please get in touch with me or Kathleen Fisher (details at the URL 
above).

You can also nominate someone else.  That's even easier.  (But ask them first.)

And plan to come, too!

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Re: Newbie: what are the advantages of Haskell?

[Simon Peyton-Jones]

This is an interesting thread but can I urge posters to reply to

[EMAIL PROTECTED]

The Haskell-cafe mailing list is designed for precisely the kind of discussion 
in the current thread.  But Haskell@haskell.org is a low-bandwidth mailing list 
for announcements and the like.

Thanks

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Taillefer, Troy
| (EXP)
| Sent: 27 April 2007 22:32
| To: haskell@haskell.org
| Subject: [Haskell] Re: Newbie: what are the advantages of Haskell?
|
|
| Mike,
|
| It has affected my Java/C/C++ programming a lot.
|
| 1. I am much more careful how I combine ( inherit, compose, aggregate )
| code because of potential side affects
|
| 2. It has helped to find certain types of bugs in Java code more easily
| that come up because of subtle effects introduced by combining code
| together
|
| 3. It has helped me to write code that is more composable
|
| 4. Haskell has increased my awareness of how important type safety is So
| I use Java Generics more now to enforce more type safety  when I can
| (sometimes I am stuck deploying to java 1.4) (I also use C++ templates
| to do the same thing for C++) But these are often feel like hacks
|
| Haskell's type system is a thing of pure beauty haven't seen anything
| quite like it in any other PL (ML and OCAML are as close as I have seen
| but still fall short) and Generics and Templates really can't compare
|
| You really want the compiler to help you out as much it can. Have it
| tell you when you are doing something that you shouldn't be doing.
|
| By the way Mike thanks you just totally cheered me up I guess I just
| needed to sit back and think about what I have learned and how valuable
| it is to me.
|
| Troy
|
|
|
|
|
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of mike clemow
| Sent: Friday, April 27, 2007 4:16 PM
| To: haskell@haskell.org
| Subject: Re: [Haskell] Re: Newbie: what are the advantages of Haskell?
|
| Troy,
|
| As a Java chimp embarking on the Haskell journey myself, I'd be
| interested in hearing about specific ways that learning Haskell has
| changed the way you program Java.  How do you employ the "very
| interesting concepts" that you have learned through your study of
| Haskell in your Java programming?  Do you employ them at all?  _Can_
| they be employed in Java?  Has it made you a better Java programmer?
|
| Cheers,
| Mike
|
| On 4/27/07, Taillefer, Troy (EXP) <[EMAIL PROTECTED]> wrote:
| > >Admittedly, this is phrased in an inflammatory manner, however, the
| > original sentiment >>is actually pointing out an advantage of Java
| > over Haskell. Here is the original >>>.paragraph in context:
| >
| > This not the first inflammatory comment he has made
| >
| > >>But, Sebastian is right.
| > Sebastian will be right when I see Chimpanzees coding in Java :)
| >
| > >> The leap is worth it.
| > I am not so sure it was for me.
| > I guess It depends on what you are looking for I have spent the last
| > year learning Haskell and I have learned some very interesting
| concepts.
| > I can't help but wish that Haskell turned out to be a more practical
| > language for me to code something useful in every time I looked for
| > Haskell libraries I was a disappointed.
| > I can't help feeling that last year might have been better spent
| > learning Erlang (which is this years language for me to learn).
| >
| > I really enjoy Functional programming (at least until I try to do
| > something serious then frustration sets in). I can't produce software
| > in a timely and cost effective fashion without a large body of high
| > quality, documented and maintained libraries.
| >
| > I get the feeling that Haskell is for researchers to explore ideas
| > about programming in but no one is interested in doing The grind work
| > of cranking out useful basic libraries.
| > I guess you need borrow some of those Java Chimps :).
| >
| > Am I the only person on the list that feels this way ?
| >
| > I guess I am feeling a bit bitter of spending so much time on Haskell
| > and having so little to show for it.
| >
| > Troy
| >
| >
| > -Original Message-
| > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| > On Behalf Of Al Falloon
| > Sent: Friday, April 27, 2007 12:19 PM
| > To: haskell@haskell.org
| > Cc: haskell@haskell.org
| > Subject: [Haskell] Re: Newbie: what are the advantages of Haskell?
| >
| > Taillefer, Troy (EXP) wrote:
| > > Java sense (i.e. "cut out any feature that can't be understood in
| > > five
| >
| > > minutes by a chimp")
| > >
| > > Got to love comments like this they are constructive, objective,
| > > mature and accurate.
| > >
| > > Glad we have your expert opinion to give us the gospel.
| > >
| > > Can I get an amen? How about a Hallelujah ?
| >
| > Admittedly, this is phrased in an inflammatory manner, however, the
| > original sentiment is actually pointing out an advantage of Java over
| > Haskell. He

[Haskell] Commercial Users of Functional Programming: call for speaker nominations

[Simon Peyton-Jones]

Commercial Users of Functional Programming (CUFP) 2007
Oct 4 2007, Freiburg, Germany

=== Call for speaker nominations and talk proposals ===

Functional languages have been under academic development for
over 25 years, and remain fertile ground for programming language
research. Recently, however, developers in industrial,
government, and open source projects have begun to use functional
languages very successfully in practical applications. In these
settings, functional programming has often provided dramatic
leverage, including whole new ways of thinking about the original
problem.

The goal of the CUFP workshop is to act as a voice for these
users of functional languages. The workshop supports the
increasing viability of functional programming in the commercial,
governmental, and open-source space by providing a forum for FP
professionals to share their experiences and ideas, whether those
ideas are related to business, management, or engineering. The
workshop is also designed to enable the formation and
reinforcement of relationships that further the commercial use of
functional languages.


 Speaking at CUFP

If you use functional programming as a means, rather than as an
end, this message is an invitation for you to offer to give a
talk at the workshop. Alternatively, you may know someone else
who would give a good talk: please nominate them.

Talks are typically about 30-45 minutes long, but can be shorter.
They aim to inform participants about how functional programming
played out in real-world applications, focusing especially on the
re-usable lessons learned, or insights gained.

Your talk does not need to be highly technical; for this
audience, reflections on the commercial, management, or software
engineering aspects are, if anything, more important. You do not
need to submit a paper!

If you are interested in offering a talk, or nominating someone
to do so, send an e-mail to kfisher at research.att.com or
simonpj at microsoft.com by June 1, 2007 with a short description
of what you'd like to talk about or what you think your nominee
should give a talk about. Such descriptions should be roughly a
page in length.



___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] FW: A history of Haskell

[Simon Peyton-Jones]

[Sorry to spam you, but I got the URL wrong.  Darn!]

Many of you will know that Paul Hudak, John Hughes, Phil Wadler and I have been 
working on a paper called

A History of Haskell: being lazy with class

which will appear at this year's ACM SIGPLAN History of Programming Languages 
Conference (HOPL-III) San Diego, California, June 9-10, 2007.

It's finally done!  You can get a copy here:

http://research.microsoft.com/~simonpj/papers/history-of-haskell/index.htm

We warmly thank all those of you who helped us get it done; I hope we 
remembered you all in the acknowledgements!  (If not, let us know.)

It's in copy-editing now, so if you spot typos, please drop us a line.

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] A history of Haskell

[Simon Peyton-Jones]

Many of you will know that Paul Hudak, John Hughes, Phil Wadler and I have been 
working on a paper called

A History of Haskell: being lazy with class

which will appear at this year's ACM SIGPLAN History of Programming Languages 
Conference (HOPL-III) San Diego, California, June 9-10, 2007.

It's finally done!  You can get a copy here:
http://camwwwdev/~simonpj/papers/history-of-haskell/index.htm

We warmly thank all those of you who helped us get it done; I hope we 
remembered you all in the acknowledgements!  (If not, let us know.)

It's in copy-editing now, so if you spot typos, please drop us a line.

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] [Fwd: Re: Computer Language Shootout]

[Simon Peyton-Jones]

http://www.mail-archive.com/haskell@haskell.org/msg18863.html

(It was Simon Marlow actually, but we are joined at the hip so it hardly 
matters)

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joel Reymont
| Sent: 25 January 2007 09:01
| To: Simon Marlow
| Cc: haskell@haskell.org
| Subject: Re: [Haskell] [Fwd: Re: Computer Language Shootout]
|
| Where are SPJs disclosed comments from Brent Fulgham?
|
| On Jan 25, 2007, at 8:55 AM, Simon Marlow wrote:
|
| > Forwarding on behalf of Andrzej Jaworski <[EMAIL PROTECTED]>:
| >
| >  Original Message 
| > From: Andrzej Jaworski <[EMAIL PROTECTED]>
| >
| > Dear fellows,
| >
| > It is ironic that just after SPJ disclosed Comments from Brent
| > Fulgham on
| > Haskell and the shootout the situation has radically changed for
| > the worse.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Views in Haskell

[Simon Peyton-Jones]

I don't mind whether discussion is on Haskell-prime or on Haskell-cafe (I read 
both).  But I don't think it should be on the main Haskell mailing list, which 
is advertised as relatively low-bandwidth.   It's an excellent place to start 
discussions but if we carried them all though there, a bunch of people would 
unsubscribe.  I think anyway.  (That's why we started Haskell-cafe in the first 
place.)

Simon

| -Original Message-
| From: Iavor Diatchki [mailto:[EMAIL PROTECTED]
| Sent: 24 January 2007 17:50
| To: Simon Peyton-Jones
| Cc: Duncan Coutts; Malcolm Wallace; haskell@haskell.org
| Subject: Re: [Haskell] Views in Haskell
|
| Hello,
| Is this really a good idea?  This seems a lot more relevant to the
| Haskell mailing list then haskell-prime (at least to me)---it is a
| language extension that is not implemented, there are a number of
| different ways to implement it, and we have no significant experience
| using it.  As such, it seems that it is not relevant to haskell-prime,
| at least in my understanding of the goals of Haskell'.  On the other
| hand, the proposal would probably benefit from the input of the wider
| audience of the Haskell mailing list, after all, this is an extension
| to Haskell.  Despite the fact that haskell-prime is an open mailing
| list, there are a number of people who are not subscribed to it
| because they are not interested in the standardization effort.
| -Iavor
|
| On 1/24/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
| > Let me urge everyone, once more, to conduct this interesting discussion on 
the haskell-prime
| mailing list. It's quite open --- anyone can subscribe --- and we'll avoid 
spamming the main Haskell
| list.
| >
| > I'll send responses there.
| >
| > Simon
| >
| > | -Original Message-
| > | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Duncan
| Coutts
| > | Sent: 24 January 2007 15:25
| > | To: Malcolm Wallace
| > | Cc: haskell@haskell.org
| > | Subject: Re: [Haskell] Views in Haskell
| > |
| > | On Wed, 2007-01-24 at 14:58 +, Malcolm Wallace wrote:
| > |
| > | > To add to the bikeshed discussion of syntax, did you consider and reject
| > | > the obvious use of '<-' rather than '->', which would more closely match
| > | > the pattern guard syntax?
| > |
| > | > Using the '<-' arrow does not seem to obscure
| > | > this feature too much:
| > | >   parsePacket ((n, (val,bs) <- bits n) <- bits 3) = ...
| > | > vs
| > | >   parsePacket (bits 3 -> (n, (bits n -> val bs))) = ...
| > |
| > | The main drawback to this is that we don't get the left to right binders
| > | and uses. That is we use 'n' as a variable binder when we extract the 3
| > | bits and then use that later to decide how many bits to extract. With
| > | the '<-' form the flow is all back and forth rather than left to right.
| >
| >
| > ...etc...
| >
| > ___
| > Haskell mailing list
| > Haskell@haskell.org
| > http://www.haskell.org/mailman/listinfo/haskell
| >
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: [Haskell] Views in Haskell

[Simon Peyton-Jones]

Let me urge everyone, once more, to conduct this interesting discussion on the 
haskell-prime mailing list. It's quite open --- anyone can subscribe --- and 
we'll avoid spamming the main Haskell list.

I'll send responses there.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Duncan Coutts
| Sent: 24 January 2007 15:25
| To: Malcolm Wallace
| Cc: haskell@haskell.org
| Subject: Re: [Haskell] Views in Haskell
|
| On Wed, 2007-01-24 at 14:58 +, Malcolm Wallace wrote:
|
| > To add to the bikeshed discussion of syntax, did you consider and reject
| > the obvious use of '<-' rather than '->', which would more closely match
| > the pattern guard syntax?
|
| > Using the '<-' arrow does not seem to obscure
| > this feature too much:
| >   parsePacket ((n, (val,bs) <- bits n) <- bits 3) = ...
| > vs
| >   parsePacket (bits 3 -> (n, (bits n -> val bs))) = ...
|
| The main drawback to this is that we don't get the left to right binders
| and uses. That is we use 'n' as a variable binder when we extract the 3
| bits and then use that later to decide how many bits to extract. With
| the '<-' form the flow is all back and forth rather than left to right.


...etc...

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Views in Haskell

[Simon Peyton-Jones]

Dear Haskellers

Provoked by a discussion with Don Syme, and after some helpful conversations at 
POPL, I have finally written up a proposal for adding "view patterns" to 
Haskell.  We've wanted views for a long time, but they have never made it, into 
GHC at any rate.  This proposal is a very lightweight (and hence, I hope, 
cost-effective) proposal for a view-like mechanism.

http://hackage.haskell.org/trac/haskell-prime/wiki/ViewPatterns

I'm thinking of implementing it in GHC, so I'd be interested in feedback of the 
form
- how desirable is it to have a feature of this general form?
- can this particular proposal be improved?

I've made it into a Wiki page on the Haskell Prime site.  It's probably 
premature to treat it as a serious contender for Haskell Prime (unless there is 
wild enthusiasm), because it hasn't been tried in practice yet, but that seems 
like the right forum to discuss it.

Discussion would best be directed via the open Haskell-Prime mailing list 
[EMAIL PROTECTED]
http://haskell.org/mailman/listinfo/haskell-prime

Thanks

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Beautiful concurrency: Santa Claus v2

[Simon Peyton-Jones]

Friends

I had lots of useful feedback about my paper "Beautiful concurrency"; thank 
you.  I've revised it quite heavily, and have just put up a revised draft, 
Version 2.

If you want to take a look, either for the first time, or to see what I've done 
in response to your suggestions, look here: 
http://haskell.org/haskellwiki/Talk:SantaClausProblemV2

The code is online there too.

If you give your real name somewhere in your text (or email it to me), I'll add 
you to the acknowledgements at the end of the chapter.  I'm missing some from 
the previous Talk page; notably, I'd like to acknowledge Steven807, Tibbe, 
Fanf, Garious, Rycee, Brecknell, Mvanier, Gaal, Fernando, Gknauth, 
EngineerScotty, BoAdler.  If you'd like a mention, let me know who you are.

Thanks again for your input.  I must do this with all my papers!

Simon

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Beautiful concurrency with a Christmas flaour

[Simon Peyton-Jones]

Dear Haskellers

I've been writing a modest chapter for a book edited by Greg Wilson called 
"Beautiful code".  In the end I decided to write about concurrency and 
transactional memory.  If you'd like to have a look at my first draft, go here
   http://haskell.org/haskellwiki/Talk:SantaClausProblem

I would welcome constructive suggestions for improvement. The book is aimed at 
a general audience of programmers, not Haskell geeks, so I have tried to 
explain everything necessary as I go along.  So if you are not a Haskell 
expert, your input would be particularly valuable to me.

Happy Christmas

Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] RE: package mounting

[Simon Peyton-Jones]

| > http://hackage.haskell.org/trac/ghc/wiki/PackageMounting
|   
| It looks nice, but don't you think the -package-base flag ought to
| take both the package name *and* the mountpoint?
| 
| Otherwise, this looks like what I've wanted all along, if only I knew
it ;-).

I think most of you know that GHC 6.6 made (IHMO) a significant step
forward, by allowing a program to contain multiple modules with the same
name, if they are from different packages.  That means that package
authors can choose module names freely, rather than worry about
accidentally colliding with other packages.  (We'd regard it as
unacceptable if the local variables of a function could not have the
same name as the local variables of another procedure!)

That still leaves an open question, not resolved by GHC 6.6: what to do
if you want to import module M from two different packages into the same
module?  (A related question is when you have to decide what your module
is called.)  This can be tackled in at least three different ways, one
being Frederik's proposal.  Simon and I are not wedded to any particular
one, and we'd welcome a consensus on what to do.

The state of play is summarised here
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
which includes a link to the package-mounting proposal.

If you care about this stuff, do debate it -- and please record points
that survive a bit of discussion on the Wiki pages.  None of this is
very hard to implement; the difficulty is settling on a good design.  

Simon

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Lexically scoped type variables

[Simon Peyton-Jones]

This message is about scoped type variables.  I'm sending it to the Haskell 
mailing list, because I think that the question of scoped type variables is of 
general interest to Haskellers, but I suggest that you all send *replies* to 
Haskell Café, where this thread originated.

Simon

The thread was provoked by Nicholas's message about scoped type variables
http://www.haskell.org/pipermail/haskell-cafe/2006-October/018947.html

I've thought a lot about this scoped-type-variable issue, and failed to come up 
with a truly satisfactory solution.  As several of you have noticed, GHC 6.6 
changes design wrt GHC 6.4.   Perhaps it'd help if I explained what the problem 
is, and then some of you may be able to figure out a better solution.

For reference
GHC 6.6: 
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#scoped-type-variables
GHC 6.4: 
http://www.haskell.org/ghc/docs/6.4.2/html/users_guide/type-extensions.html#scoped-type-variables

| I'd like to not have to introduce the forall, because with that comes
| introducing the entire context of the type. Thus I have to maintain
| any changes to the context, which I would prefer to leave to inference
| for modularity's sake.
| 
| In 6.4 I was able to fix this without having to introduce the forall;
| I could introduce scoped type-variables in patterns to get the job
| done.

Well, there is something to be said for the forall approach [plan (B)] -- it is 
fully explicit, and you can see exactly what the program means. One way forward 
would be to allow you to abbreviate the context of the type signature (since 
that is often the awkward bit) to "...", and approach you mention as "partial 
type signatures".

The only other reasonable alternative that I know of is plan (A), the one taken 
by earlier versions of GHC, and OCaml.  As Oleg puts it:

| Which of the two occurrences of the type variable |'a| a binding one? Who
| cares... It just works: within the same expression, the same type
| variable stands for the same type.

(I think it does matter which the binding occurrence is, because Oleg's comment 
begs the question "when are two type variables in the same expression?".  In 
earlier versions of GHC, it was precisely specified which was the binding 
occurrence.  However, that's a detail.)  A big difference between the two 
approaches is that with (B) a type variable stands for a *type variable*, 
whereas in (A) it stands for a *type*.  


So why did we switch from (A) to (B)?  Because of type inference for GADTs.  If 
you read our paper "unification based type inference for GADTs" (on my home 
page) you'll see that 

a programmer-written type signatures always describes a rigid type

("rigid" means completely known from birth -- no nonsense about unification 
etc.)   It's very important for GADTs to know when a type is rigid (see the 
paper).

That invariant in turn motivates the rigidity of type variables, and hence plan 
(B). 


Now, one could combine (A) and (B).  It'd be possible to have rigid type 
variables (bound by foralls) standing for type variables, and wobbly ones 
(bound by patterns) standing for types.  That would do what you want, but it'd 
be yet more complicated, and I hesitate before making GHC's type system more 
complicated.

Other alternatives would be: do something about partial type signatures; or 
make GADT type inference more sophisticated (and thereby perhaps less 
predicatable).


So there you have it.  For myself I'm not yet convinced that plan (B) is so 
bad.  Maybe we should do something about partial type signatures, which might 
be useful regardless of scoped type variables.   But I'd welcome better 
designs.  It's an annoying issue because it *must* be solved (not having scoped 
type variables is unacceptable); but no solution seems satisfying.  However, 
Haskell Prime must incorporate scoped type variables in some form!
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell