RE: A question about run-time errors when class members are undefined

[Simon Peyton Jones via Haskell-prime]

Anthony

You may be interested in Carlos Camarao’s interesting work.  For a long time 
now he has advocated (in effect) making each function into its own type class, 
rather that grouping them into classes.   Perhaps that is in line with your 
thinking.
https://homepages.dcc.ufmg.br/~camarao/

Simon

From: Haskell-prime  On Behalf Of Anthony 
Clayden
Sent: 06 October 2018 04:19
To: Petr Pudlák 
Cc: haskell-prime@haskell.org
Subject: Re: A question about run-time errors when class members are undefined


On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák 
mailto:redir...@vodafone.co.nz>> wrote:

IIRC one of the arguments against having many separate classes is that a class 
is not a just set of methods, it's also the relations between them,

Hi Petr, I was talking about splitting out Haskell's current class hierarchy as 
a step towards doing away with classes altogether. If your language insists on 
methods being held in classes, that's just tedious bureacracy to invent class 
names.

The relations between classes (including between single-method classes) can be 
captured through superclass constraints. For example, in the Haskell 2010 report

class (Eq a, Show a) => Num a where ...

such as the important laws between `return` and `>>=`. And then for example a 
class with just `return` doesn't give any information what `return x` means or 
what should be its properties.

Then make Bind a superclass constraint on `return` (or vice versa, or both 
ways).

Just as the laws for Num's methods are defined in terms of equality

x + negate x == fromInteger 0  -- for example

Talking about laws is a red herring: you can't declare the laws/the compiler 
doesn't enforce them or rely on them in any way. Indeed the Lensaholics seem to 
take pleasure in building lenses that break the (van Laarhoven) laws.



That said, one of really painful points of Haskell is that refactoring a 
hierarchy of type-classes means breaking all the code that implements them. 
This was also one of the main reasons why reason making Applicative a 
superclass of Monad took so long. It'd be much nicer to design type-classes in 
such a way that an implementation doesn't have to really care about the exact 
hierarchy.

Yes that's what I was saying. Unfortunately for Haskell's Num class, I think 
it's just too hard. So a new language has an opportunity to avoid that. If OTOH 
Helium wants to slavishly follow Haskell, I'm wondering what is the point of 
Helium.

With Applicative, IIRC, refactoring had to wait until we got Constraint kinds 
and type families that could produce them. Would Helium want to put all that 
into a language aimed at beginners?


 For example, in Haskell we could have

class (Return m, Bind m) => Monad m where

without any methods specified. But instances of `Monad` should be only such 
types for which `return` and `>>=` satisfy the monad laws.

First: what does "satisfy the xxx laws" mean? The Haskell report and GHC's 
Prelude documentation state a bunch of laws; and it's a good discipline to 
write down laws if you're creating a class; but it's only documentation. 
Arguably IO, the most commonly used Monad, breaks the Monad laws in rather 
serious ways because it imposes sequence of execution; and it would be unfit 
for purpose if it were pure/lazy function application.

Then: what do you think a language could do to detect if some instance 
satisfies the laws? (Even supposing you could declare them.)


And this would distinguish them from types that have both `Return` and `Bind` 
instances, but don't satisfy the laws.

You could have distinct classes/distinct operators. Oh, but then `do` dotation 
would break.


Unfortunately I'm not sure if there is a good solution for achieving both these 
directions.

I don't think there's any solution for achieving "satisfy the xxx laws".


AntC


čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden 
mailto:anthony_clay...@clear.net.nz>> napsal:
> We are adding classes and instances to Helium.

> We wondered about the aspect that it is allowed to have a class instance

> of which not all fields have a piece of code/value associated with them, ...



I have a suggestion for that. But first let me understand where you're going 
with Helium. Are you aiming to slavishly reproduce Haskell's classes/instances, 
or is this a chance for a rethink?



Will you want to include associated types and associated datatypes in the 
classes? Note those are just syntactic sugar for top-level type families and 
data families. It does aid readability to put them within the class.



I would certainly rethink the current grouping of methods into classes. Number 
purists have long wanted to split class Num into Additive vs Multiplicative. 
(Additive would be a superclass of Multiplicative.) For the Naturals perhaps we 
want Presburger arithmetic then Additive just contains (+), with `negate` 
certainly in a different class, perhaps (-) subtract also in a dedicated class. 
Also there's people wanting Monads 

RE: Quo vadis?

[Simon Peyton Jones via Haskell-prime]

|  That sounds like we're stuck with the committee we have. In that case,
|  Simon, could you at least pull some strings to have the actual Haskell
|  Report placed in the same repository?

Sounds like a good plan.  If the haskell-prime committee agreed to do this, and 
it's only a matter of doing it, then you just need someone with commit rights 
to the relevant repository. I don't know who that is (it certainly isn't me), 
but if you make them a PR, and ping them by email, it would be easy for them to 
execute.

Simon


|  -Original Message-
|  From: Mario Blažević 
|  Sent: 08 October 2018 02:52
|  To: Simon Peyton Jones ; haskell-prime@haskell.org
|  Subject: Re: Quo vadis?
|  
|  On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:
|  > I think the difficulty has always been in finding enough people who
|  > are
|  >
|  > * Well-informed and well-qualified
|  > * Willing to spend the time to standardise language features
|  >
|  > GHC does not help the situation: it's a de-facto standard, which
|  reduces the incentives to spend time in standardisation.
|  >
|  > I don’t think we should blame anyone for not wanting to invest this
|  time -- no shame here.  It is a very significant commitment, as I know
|  from editing the Haskell 98 report and the incentives are weak.  Because
|  of that, I am not very optimistic about finding such a group -- we have
|  been abortively trying for several years.
|  
|  
|  That sounds like we're stuck with the committee we have. In that case,
|  Simon, could you at least pull some strings to have the actual Haskell
|  Report placed in the same repository? This is a basic precondition if we
|  expect individual efforts to accomplish anything. The minimal steps to
|  actually updating the Haskell Report are:
|  
|  1. write an RFC (we have some already),
|  2. have it provisionally accepted (not entirely clear how - would
|      "no negative votes in 4 weeks" count?), 3. add the modification to
|  the Haskell Report to the RFC, 4. receive the final approval, 5. merge
|  the RFC into the report.
|  
|  Steps #3 and #5 depend on having the report in the same repository with
|  the RFCs. This has been agreed over a year ago:
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  September%2F004319.htmldata=02%7C01%7Csimonpj%40microsoft.com%7C227f
|  843099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
|  C636745603204766102sdata=z3meiZAXQoKzsiOzPAjicdzLbL2vRp0NPgIsUFM2h%2
|  FY%3Dreserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  October%2Fthread.htmldata=02%7C01%7Csimonpj%40microsoft.com%7C227f84
|  3099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  36745603204766102sdata=ilw5EXJyblsVyqs3e7iczbTpG3TexjNY7nmSokMJFvM%3
|  Dreserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2017-
|  November%2Fthread.htmldata=02%7C01%7Csimonpj%40microsoft.com%7C227f8
|  43099c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
|  636745603204766102sdata=T5zS7b9Swyn%2FWPW8Yqt9XTOf38KSqYmMkgzglesjAR
|  Y%3Dreserved=0
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fpipermail%2Fhaskell-prime%2F2018-
|  March%2F004356.htmldata=02%7C01%7Csimonpj%40microsoft.com%7C227f8430
|  99c5489509da08d62cc0a25f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636
|  745603204766102sdata=bSimqVnSL0Yp18LhYMJ9LsqnPWT4QmT%2BKpyRwAISbdY%3
|  Dreserved=0
|  
|  
|  > If we want to change that, the first thing is to build a case that
|  greater standardisation is not just an "abstract good" that we all
|  subscribe to, but something whose lack is holding us back.
|  
|  Neither an abstract good nor a good abstraction are something Haskell has
|  ever shied away from. I don't know if you're actually asking for a list
|  of "concrete goods"? To start with, every GHC extension that's added to a
|  standard means:
|  
|  - one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension #-}
|  pragma,
|  - one less item to understand for beginners,
|  - one less item whose necessity must be justified to the team, and
|  - one less item of whose future stability the management needs to be
|  convinced.
|  
|  I could go on.

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

RE: Quo vadis?

[Simon Peyton Jones via Haskell-prime]

I think the difficulty has always been in finding enough people who are

* Well-informed and well-qualified
* Willing to spend the time to standardise language features

GHC does not help the situation: it's a de-facto standard, which reduces the 
incentives to spend time in standardisation.

I don’t think we should blame anyone for not wanting to invest this time -- no 
shame here.  It is a very significant commitment, as I know from editing the 
Haskell 98 report and the incentives are weak.  Because of that, I am not very 
optimistic about finding such a group -- we have been abortively trying for 
several years.

If we want to change that, the first thing is to build a case that greater 
standardisation is not just an "abstract good" that we all subscribe to, but 
something whose lack is holding us back.

Simon

|  -Original Message-
|  From: Haskell-prime  On Behalf Of
|  Mario Blaževic
|  Sent: 05 October 2018 17:47
|  To: haskell-prime@haskell.org
|  Subject: Re: Quo vadis?
|  
|  On 2018-10-05 09:10 AM, Henrik Nilsson wrote:
|  > Hi,
|  >
|  > On 10/05/2018 01:20 PM, Mario Blažević wrote:
|  >>  I hereby propose we formally disband the present Haskell 2020
|  >> committee. Our performance has been so dismal
|  >
|  > It has.
|  >
|  > And I should apologise in particular: I've just had far less time than
|  > I thought over the past year for a variety of reasons.
|  >
|  >> that I feel this is the
|  >> only course of action that gives Haskell 2020 any chance of fruition.
|  >> A new committee could then be formed with some more dedicated
|  membership.
|  >
|  > I'm less convinced about that, though. I believe those who signed up
|  > for H2020 actually are people who believe in the value of an updated
|  > standard and has core expertise to make it happen.
|  
|       Regarding the beliefs, if we really represent the most zealous group
|  of Haskell enthusiasts, I have to say the community is in deep trouble. I
|  have no evidence, but I can only hope you're wrong.
|  
|       As for the expertise, my impression is that *everybody* who self-
|  nominated for the committee got accepted. My own self-nomination e-mail
|  [1] explicitly said that
|  
|  
|  > The main reason I'm applying is because I'm afraid that the commitee
|  > might disband like the previous one. If there are enough members
|  > already, feel free to ignore my nomination.
|  
|  Yet I'm in. This was not a high bar to clear.
|  
|  
|  > I can't see how giving up and forming a new group would speed things
|  > up or even increase the chance of success.
|  
|       I was kinda hoping for a Simon ex machina, where a few universally-
|  accepted members of the community hand-pick a new committee.
|  Alternatively, we could come up with some stricter criteria for the next
|  committee before we disband but that assumes we can even get a quorum.
|  
|       Lest I'm suspected of some Machiavellian plot, let me be clear that
|  I refuse to be a part of the next committee, if my proposal should be
|  accepted. Honestly I feel that all members of the present committee with
|  any sense of shame should recuse themselves as well, but that's not up to
|  me.
|  
|  
|  > Instead, what about focusing on identifying a couple of things that
|  > absolutely would have to be in H2020 to make a new standard
|  > worthwhile, like multi-parameter type classes, possibly GADTs, then
|  > figure out what else is needed to support that (like what Anthony
|  > Clayden sketched), and with that as a basis, find out exactly what
|  > technical problems, if any, are hindering progress?
|  >
|  > If this could be neatly summarized, then we'd actually be in a
|  > position to make some progress.
|  
|       That is much the plan we agreed on over a year ago during ICFP 2018.
|  The activity since then is plain to see.
|  
|  
|  [1]
|  http://mail.haskell.org/pipermail/haskell-prime/2015-
|  September/003939.html
|  
|  ___
|  Haskell-prime mailing list
|  Haskell-prime@haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Haskell Report 2010: pattern bindings

[Simon Peyton Jones via Haskell-prime]

Thanks Jose.

The other issue I have in mind is that of pattern bindings.  Currently in the 
2010 Haskell Report

  *   The text on the monomorphism 
restriction<https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-880004.5>
 (4.5.5) refers to “simple pattern bindings”.
  *   It claims that a simple pattern binding “is a pattern binding in which 
the pattern consists of a single variable”
  *   You’d expect “simple pattern binding” to be defined in 3.17.1 
Patterns<https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-580003.17>.
  But it isn’t.
  *   Instead, 4.4.3.2 Pattern 
bindings<https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-84.4>
 explicitly contradicts 4.5.5 by saying “a simple pattern binding has form p=e”.
What a mess!
The simplest way out is probably:

  *   Define “simple pattern binding” to be of form x=e, in 3.17.1.
  *   Fix the first para of 4.4.3.2.
  *   Fix the cross-ref in 4.5.5 to refer to the definition of simple pattern.
Sadly, 4.4.3.2 still is not very well defined.  It’s supposed to say what 
pattern bindings mean, including top-level ones; but it does so by referring to 
3.12 which does not handle top-level bindings.  I’m not sure if this is worth 
fixing.

Simon

From: José Manuel Calderón Trilla <j...@jmct.cc>
Sent: 15 March 2018 23:17
To: Simon Peyton Jones <simo...@microsoft.com>; haskell-prime@haskell.org; 
ghc-d...@haskell.org
Subject: Re: [Haskell] The Haskell Report: who maintains it?

All of us on the Haskell Language Committee have the ability to commit on that 
repo.

I think typos are uncontroversial and I'll happily merge pull requests like 
that.

I think the pull-request you point out suffered from the bystander effect, 
unfortunately. I'll review and merge it now.

If you let me know the typo you'd like fixed I'll make sure that gets done as 
well.

Cheers,
José Manuel



On Thu, Mar 15, 2018, at 6:52 PM, Simon Peyton Jones via Haskell wrote:

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 <haskell-rep...@noreply.github.com>
Cc: Subscribed <subscri...@noreply.github.com>
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<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=1xk6eQn%2Fq4vKglbQSLHNOGYrNdxJBp074b2%2ByJbvCrQ%3D=0>

Commit Summary

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

File Changes

  *   M 
report/exps.verb<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4%2Ffiles%23diff-0=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=OYptlGmxyWflETFlpd4f8ln1AEYgT8EwiYX44dPafJI%3D=0>
 (1)

Patch Links:

  *   
https://github.com/haskell/haskell-report/pull/4.patch<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4.patch=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=gUICTD38nmiLSOheLW14zHM%2FTj2Uv59k7kxyxXKXgpU%3D=0>
  *   
https://github.com/haskell/haskell-report/pull/4.diff<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4.diff=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=NrCOwM0rJ8rH0p7d3tSG7YCsVziBJGli%2BKfx8SaFgDE%3D=0>

—
You are receiving this becau

The Haskell Report: who maintains it?

[Simon Peyton Jones via Haskell-prime]

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-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: Remove eq and show from num class

[Simon Peyton Jones via Haskell-prime]

Good summary Herbert.  It'd be great to have it as a page on haskell.org, 
rather than just in soon-lost email.

Simon

| -Original Message-
| From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On Behalf
| Of Herbert Valerio Riedel
| Sent: 08 September 2017 09:43
| To: Anthony Clayden 
| Cc: haskell-prime@haskell.org
| Subject: Re: Remove eq and show from num class
| 
| On 2017-09-08 at 09:19:54 +0200, Anthony Clayden wrote:
| 
| [...]
| 
| > If this is to the committee, shouldn't it be on the committee list?
| > (I mean ghc-steering-committee.)
| 
| > Or is there some other committee? I thought the Haskell-prime forum
| > and process was dead/replaced by the github proposals process?
| 
| I can see how the proliferation of committees & github repos may seem
| confusing to casual observers, so let me provide a quick overview which
| hopefully doesn't worsen the confusion... :-)
| 
| ## Haskell Core Library Committee
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.has
| kell.org%2FCore_Libraries_Committee=02%7C01%7Csimonpj%40microsoft.co
| m%7Ca13a8633ae3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7
| C1%7C0%7C636404570444220789=wQ%2B6bfpKtDPUmnxa54FWVDiq%2F3H7eVfnkGF
| kW4s82Ns%3D=0
| 
| Basically, the core library committee oversees decisions of what happens
| with core libraries such as `base` which includes the API defined by the
| Haskell library report. However, the Eq/Show=>Num superclass removal
| proposal (),
| however predates the core libraries committee's existence (the CLC was
| originally formed sometime around 2013 to design and manage big changes
| such as the implementation of the Functor/Applicative/Monad proposal --
| for which there was big community support but lack of leadership was
| preventing its implementation).
| 
| Moreover, the CLC together with the Hackage Trustees also maintains the
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fhaskell%2Fpvp=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633ae3c4
| 36a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63640457
| 0444220789=uI0uVdaGjBLmNrlUqdrPeO7g6%2B4isWj8w1Qi3CDHIIU%3D
| d=0 specification which is integral to the way Hackage and the Cabal
| solver interact.
| 
| ## Haskell Language Committee (aka Haskell Prime Committee)
| 
|  - https://mail.haskell.org/pipermail/haskell-prime/2016-
| April/004050.html
| 
| So this committee's incarnation has just been formed last year; it's a
| bit too early to declare it dead.
| 
| ## GHC Steering Committee
| 
|  - https://ghc.haskell.org/trac/ghc/wiki/SteeringCommittee
| 
| This is mostly about user-facing changes to GHC and was created shortly
| after the prime committee's formation was announced. It surely wasn't
| intended to replace the prime committee, but was rather formed as a
| reaction to complaints about GHC's governance, you can read up about its
| intent at
| 
|  - https://ghc.haskell.org/trac/ghc/blog/rethinking-proposals
| 
| Not all changes are even relevant to the Haskell Report (like e.g.
| warning flags); but Report-relevant changes may start their life-cycle as
| GHC extensions to get some empirical field-testing, and if desirable to
| later be promoted to Haskell Prime proposals subject to the Prime
| process.
| 
| ## Other Committees
| 
| For completeness, here's a few other Haskell-related committees and/or
| working-group like processes OTTOMH:
| 
| ### Haskell.org committee
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.has
| kell.org%2FHaskell.org_committee=02%7C01%7Csimonpj%40microsoft.com%7
| Ca13a8633ae3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%
| 7C0%7C636404570444220789=7yZv2psUaTehR%2FsiCtNY0n1AXzrGcHXrUKoDxeeV
| HyY%3D=0
| 
| ### The Haskell.org Website Working Group (HWWG)
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fndmitchell%2Fhwwg=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633a
| e3c436a9deb08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
| 04570444220789=cKoBAcJdILupv2mlkwvHuSCx1lwdwIimCi3%2BTujuSHo%3D
| erved=0
| 
| ### Haskell Ecosystem Proposals
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
| om%2Fhaskell%2Fecosystem-
| proposals=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633ae3c436a9deb08
| d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63640457044422078
| 9=XW3ojdp3kjN8wB%2FhOzeWSi6T2UKYaH2M9u8YaSWzeGQ%3D=0
| 
| ### Industrial Haskell Group
| 
|  -
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Findustry.
| haskell.org=02%7C01%7Csimonpj%40microsoft.com%7Ca13a8633ae3c436a9deb
| 08d4f695bee5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636404570444220
| 789=tmFLIQlxl%2Bs9HFSS2d6qLV3MKGjjToLDnskN99yGYKg%3D=0
| 
| ### Commercial Haskell Group
| 
|  -
| 

RE: Are there GHC extensions we'd like to incorporate wholesale?

[Simon Peyton Jones]

Just to be clear, MonoLocalBinds, as implemented, does not apply to local 
bindings that could equally well have been written at top level; that is, they 
do not mention any locally-bound variables (except other local bindings that 
could themselves be floated).

So you are at liberty to use where for stylistic reasons.

You may still dislike the cure, but the disease is pretty bad.  Do suggest 
alternative cures!

This is not to argue for or against MonoLocalBinds for Haskell Prime.

Simon

|  -Original Message-
|  From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On
|  Behalf Of wren romano
|  Sent: 08 May 2016 02:40
|  To: haskell-prime@haskell.org List 
|  Subject: Re: Are there GHC extensions we'd like to incorporate
|  wholesale?
|  
|  On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese
|   wrote:
|  > As an outsider, I would like to suggest thinking about
|  MonoLocalBinds.
|  > GHC has a rather convincing story (at least to me) that "(local) let
|  > should not be generalised" (since it becomes problematic in
|  > combination with several other language extensions) and the journal
|  > version of the OutsideIn(X) paper has empirical data that indicates
|  it
|  > is not a big problem to remove.  If there is a concern about
|  backwards
|  > compatibility, perhaps the committee could deprecate local let
|  > generalisation in Haskell2020 and remove it in a subsequent iteration
|  of the report?
|  
|  
|  FWIW, I'm against MonoLocalBinds. I understand the rational given in
|  the paper, but I disagree with it. In my experience the medicine is
|  worse than the disease.
|  
|  It used to be that where-clauses where a nice clean way of organizing
|  code, especially for things like the worker/wrapper transform; but with
|  MonoLocalBinds all the benefits of where-clauses are eliminated.
|  For every local binding I'm forced to provide a type signature —because
|  part of the whole *point* of factoring things out is that you're going
|  to use them repeatedly, which for GADTs virtually guarantees the uses
|  will be at different index types and therefore will require universal
|  quantification— and these requisite type signatures almost entirely
|  duplicate information provided by the signature for the primary/top-
|  level binding. Indeed, in almost every situation I end up needing to
|  manually provide type signatures which are identical to what let-
|  generalization would have inferred. This repetition is not merely
|  annoying, it actively harms legibility and maintainability of code.
|  
|  --
|  Live well,
|  ~wren
|  ___
|  Haskell-prime mailing list
|  Haskell-prime@haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fhaskell-
|  prime=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd15df870d2b4441
|  c57c808d376e19b35%7c72f988bf86f141af91ab2d7cd011db47%7c1=U2WAdUt4
|  qXclT7F7G93J1zVylYv3CvhqNuNHeem%2fvEg%3d
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: Are there GHC extensions we'd like to incorporate wholesale?

[Simon Peyton Jones]

|  For example, much as I love GADTs and would be all for them being added
|  in some future language report, I do not feel they should be added this
|  time around. (Though I emphatically and wholeheartedly support adding
|  GADTSyntax.) The primary reason being that while the semantics of the
|  data types themselves is easy enough to define, there's no really
|  sensible way of specifying how type inference should work for them. GHC
|  has gone back and forth with a bunch of different inference methods
|  over the years, and I don't think that's really stabilized yet;

Actually it has stabilised.  The OutsideIn journal paper 
(http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/index.htm)
 describes how it works, and has been absolutely stable for several years.  
(All the movement has been on other things: type families, kind polymorphism, 
etc.)

I agree that the specification isn't entirely satisfactory, because it's a bit 
operational.  But it's robust and stable.

I'm not arguing for or against GADTs in the next iteration of Haskell.  But I 
don't think that the ease or difficulty of specifying GADTs is going to change 
much, so waiting till next time may not help; useful as they are, a declarative 
specification for GADTs is tricky.


Simon

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

RE: Chairship / responsibility

[Simon Peyton Jones]

|  It was my understanding that Herbert would be the chair when I asked to
|  be on the committee, and the fact that this question was already answer
|  was a factor in my decision to try to help. Being the committee chair
|  is less a position of power, and more a position of responsibility. I
|  think we can be very happy to have someone who is willing to do the
|  job, and I absolutely trust hvr to be up to the task.

Andres says this well.  Being chair is a facilitating role, helping discussions 
make progress, and gently pressing them forward to a conclusion.  

I'm very grateful to Herbert for taking it on -- thank you!

Simon


|  -Original Message-
|  From: Haskell-prime [mailto:haskell-prime-boun...@haskell.org] On
|  Behalf Of Andres Löh
|  Sent: 30 April 2016 09:39
|  To: Herbert Valerio Riedel 
|  Cc: haskell-prime@haskell.org
|  Subject: Re: Chairship / responsibility
|  
|  Hi.
|  
|  It was my understanding that Herbert would be the chair when I asked to
|  be on the committee, and the fact that this question was already answer
|  was a factor in my decision to try to help. Being the committee chair
|  is less a position of power, and more a position of responsibility. I
|  think we can be very happy to have someone who is willing to do the
|  job, and I absolutely trust hvr to be up to the task.
|  
|  If needed, we can revisit the question over time when we have a better
|  idea how our usual workflow and processes look like, but I don't think
|  we need to or should have this discussion now.
|  
|  Cheers,
|Andres
|  
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: Breaking Changes and Long Term Support Haskell

[Simon Peyton Jones]

| > Are these three technical capabilities *all* that we would need?
| > Perhaps
| > we also need a way to tie the current language (-XHaskell98,
| > -XHaskell2010) to a particular implementation of the Prelude.
| >
| >
| > I don't have a concrete plan here. I'm not even sure one can be
| > achieved that works. I'd say that the burden of figuring out such a
| > thing falls on the party that can create a plan, pitch it to the
| > community and potentially implement it.

In fact there is more than one concrete plan: 
https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses

All are complex, only partially designed, entirely unimplemented (and the 
implementation will be non-trivial), and lacking an active champion.  The one I 
link to above is probably the leading contender, but it feels too complicated 
to me.

Simon

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

RE: Breaking Changes and Long Term Support Haskell

[Simon Peyton Jones]

While we are here, let me say

  A BIG THANK YOU TO THE CORE LIBRARIES COMMITTEE

Library design has a lot of detail, and a lot of competing priorities.  I am 
personally very grateful to the CLC for the work they put into this. Like many 
crucial tasks it's one that often seems to attract more complaints than thanks, 
but they are doing us all a huge service, and at significant cost in terms of 
their most precious and inelastic commodity: their personal time.

Remember, as Dan says, before the CLC we no process whatsoever for library 
evolution... various people made various patches, and there was no way of 
getting anything substantial done.  So we are far far further on than before.

Still not perfect, as my last post said. But still: THANK YOU.

Simon

| -Original Message-
| From: Dan Doel [mailto:dan.d...@gmail.com]
| Sent: 21 October 2015 22:23
| To: Geoffrey Mainland
| Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell-
| pr...@haskell.org List; Haskell Libraries
| Subject: Re: Breaking Changes and Long Term Support Haskell
| 
| Hello,
| 
| I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
| only for myself). As I recall, one of the reasons I got tapped for it
| was due to my having some historical knowledge about Haskell; not
| because I was there, but because I've gone back and looked at some old
| reports and whatnot (and sometimes think they're better than what we
| have now).
| 
| But, I was around (of course) when the core libraries committee
| started up, so perhaps I can play the role of historian for this as
| well.
| 
| The reason the committee exists is because a couple years ago, people
| brought up the ideas that were finally realized in the
| Applicative-Monad proposal and the Foldable-Traversable proposal. A
| lot of people weighed in saying they thought they were a good idea,
| and significantly fewer people weighed in saying they thought that it
| shouldn't happen for various reasons---roughly the same things that
| people are still bringing up about these proposals.
| 
| This wasn't the first time that happened, either. I think it was
| widely agreed among most users that Functor should be a superclass of
| Monad since I started learning Haskell around 10 years ago. And once
| Applicative was introduced, it was agreed that that should go in the
| middle of the two. But it appeared that it would never happen, despite
| a significant majority thinking it should, because no one wanted to do
| anything without pretty much unanimous consent.
| 
| So, one question that got raised is: why should this majority of
| people even use Haskell/GHC anymore? Why shouldn't they start using
| some other language that will let them change 15-year-old mistakes, or
| adapt to ideas that weren't even available at that time (but are still
| fairly old and established, all things considered). And the answer was
| that there should be some body empowered to decide to move forward
| with these ideas, even if there is some dissent. And frankly, it
| wasn't going to be the prime committee, because it hadn't shown any
| activity in something like 3 years at the time, and even when it was
| active, it didn't make anywhere near the sort of changes that were
| being discussed.
| 
| And the kicker to me is, many things that people are complaining about
| again (e.g. the FTP) were the very things that the committee was
| established to execute. I don't think we had a formal vote on that
| proposal, because we didn't need to. Our existence was in part to
| execute that proposal (and AMP). And then a year ago, when it was
| finally time to release the changes, there was another ruckus. And we
| still didn't have a CLC vote on the matter. What we did was conduct a
| community poll, and then SPJ reviewed the submissions. But I don't
| mean to pass the buck to him, because I'm pretty sure he was worried
| that we were crazy, and overstepping our bounds. Just, the results of
| the survey were sufficient for him to not overrule us.
| 
| So my point is this: there seems to be some sentiment that the core
| libraries committee is unsound, and making bad decisions. But the
| complaints are mostly not even about actual decisions we made (aside
| from maybe Lennart Augustsson's, where he is unhappy with details of
| the FTP that you can blame on us, but were designed to break the least
| code, instead of being the most elegant; if we had pleased him more,
| we would have pleased others less). They are about the reasons for
| founding the committee in the first place. You can blame us, if you
| like, because I think it's certain that we would have approved them if
| we had formally voted. We just didn't even need to do so.
| 
| Forgive me if I'm wrong, but suggestions that these decisions should
| have been deferred to a Haskell Prime committee mean, to me, that the
| hope is that they would have been rejected. That the Haskell Prime
| committee should have just vetoed

RE: Breaking Changes and Long Term Support Haskell

[Simon Peyton Jones]

| For the record, I am also not sure Proposal 3 is a good idea :)
| 
| However, I do think we could clarify what the respective
| responsibilities of the core libraries committee and Haskell Prime
| committees are.

My instinct is this:
  Haskell Prime: language
  Core Libraries Committee: libraries

That seems simple.  If we try to move the largest and most challenging library 
design tasks from CLC to HP, I fear that we will overload the latter and 
devalue the former.

| You are absolutely correct that moving the question to the Haskell Prime
| committee risks pushing the issue around. The idea behind the separation
| outlined above is to reduce the treadmill; the two bodies use different
| processes, with different time frames, to arrive at decisions. Some
| library decisions may deserve a longer deliberative process.

I do agree that some library changes are far-reaching, and need a more 
deliberative process.  I think the CLC is in the process of developing such a 
process.  Moreover, I trust them to be able to tell the difference between 
low-impact and high-impact changes.

That said, as HP moves towards a new language Report, it would be good if CLC 
similarly moved towards a new libraries Report, so that there was a single 
unified document, just as we have had to date.

Simon


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

RE: Breaking Changes and Long Term Support Haskell

[Simon Peyton Jones]

Friends

I think it's good for us to debate the question of how we should balance 
innovation against change; and how we should make those decisions in future.  
Geoff's message had some good ideas, especially this bit:

|  Proposal 2: After a suitable period of discussion on the libraries list, the
|  Core Libraries Committee will summarize the arguments for and against a
|  proposal and post it, along with a (justified) preliminary decision, to a
|  low-traffic, announce-only email list. After another suitable period of
|  discussion, they will issue a final decision. What is a suitable period of
|  time? Perhaps that depends on the properties of the proposal, such as
|  whether it breaks backwards compatibility.

Identifying major changes to the libraries, and having a better publicised, 
more RFC-like process for deliberating them, would be a good thing.  I believe 
that the Core Libraries committee is thinking actively about this.

|  Personally, I think AMP was the right thing to do, but I don't think FTP was
|  the right thing.

These make good examples to motivate future changes to our process.  But in the 
end FTP was subject to a pretty broad deliberative process, precisely along the 
lines that Geoff suggests above.  We had two clearly-articulated alternatives, 
a discrete call for opinions broadcast to every Haskell channel we could find, 
a decent interval for people to respond, and (as it turned out) a very clear 
preponderance of opinion in one direction.  In a big community, even a broad 
consultation may yield a result that some think is ill-advised.  That's part of 
the joyful burden of being a big community.

Let's look forward, not back.  I think we can do better in future than we have 
done in the past.  I don't think we can hope for unanimity, but I think we can 
reasonably seek 

 * transparency; 
 * clarity about what decisions are on the table; 
 * broad consultation about decisions that affect 
a broad constituency; and 
 * a decent opportunity to debate them without having 
to be involved in massive email threads.  Let's try do to that.

Simon

PS: For what it's worth I'm less keen on Geoff's other proposal:

|  Proposal 3: A decision regarding any proposal that significantly affects
|  backwards compatibility is within the purview of the Haskell Prime
|  Committee, not the Core Libraries Committee.

*Precisely* the same issues will arise whether it's CLC or HPC.  And the HPC is 
going to be jolly busy with language issues. Moving the question from one group 
to another risks avoiding the issue rather than addressing it.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

RE: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

[Simon Peyton Jones]

I think there are several different conversations going on at once in this 
thread.  I think it’s worth keeping them separate.


· Haskell Prime.  The intention there is to take a set of language 
features that are already in wide use in GHC (i.e. have demonstrably proved 
valuable), work out any dark corners, formalise them, and embody the result in 
a new Haskell Report.   That puts a useful stake in the ground, empowers 
alternative implementations of Haskell, gives confidence all round.

I think it’d be unusual for the Haskell Prime committee to specify a new 
feature of the language, one that had not been field tested.


· Libraries.  AMP, BBP, and Monad(return) are small but fundamental 
changes to the core libraries.  I think there was a consensus (not universal in 
the case of BBP) that the change was good.  Yet AMP and BBP (esp) were 
controversial.  The issues were mostly around how to make the transition; and, 
given that the transition is expensive, whether the cost/benefit tradeoff 
justifies the change.  The question of moving ‘return’ out of Monad is in this 
category.


The Core Libraries Committee was formed explicitly to handle this stuff. So my 
prior assumption was that the CLC would handle the Monad(return) question, not 
Haskell Prime.



Mark’s suggestion of a “stable” GHC 7.10 and a new GHC 8.0 is a reasonable one. 
But I for one would find it hard to promise to back-port every bug fix, 
especially as the two code bases diverge (which they will).



Here is another idea.  GHC knows very little about Monad.  It would take work, 
but it probably wouldn’t be impossible to make the same GHC work with two 
different ‘base’ libraries, each with a different definitions of the Monad 
class.  That would not solve the problem: you still could not use one library 
that used old Monad with another library that used new Monad.   But at least 
it’d decouple it from which version of GHC you were using.  I stress: it would 
take some work to make this go, and I’d prefer not to do this.

Returning to ‘return’, my instinct is that when these pervasive breaking 
library changes come up, we should batch them into larger clumps.  The 
“treadmill” complaint is real: small change A made me re-release my library; 
then small change B came along; and so on.  Perhaps if we saved them up this 
would be less of an issue, for two reasons.  First, the work happens once 
rather than many times.  Second, the benefits of the change is the sum of the 
benefits of the little component changes, and so is more attractive to library 
authors and library clients.

That line of thinking would suggest that the Core Libraries Committee might 
want to maintain a list of well-worked out agreed changes that are being “saved 
up” for execution at some later date.

Simon



From: Haskell-Cafe [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Mike 
Meyer
Sent: 07 October 2015 00:24
To: Mark Lentczner; Johan Tibell
Cc: Haskell Libraries; haskell cafe; haskell-prime@haskell.org List
Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement 
of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of 
`Monad`)

On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner 
> wrote:

On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel 
> wrote:
TLDR: To complete the AMP, turn `Monad(return)` method into a
  top-level binding aliasing `Applicative(pure)`.

Sure... if we had a language that no one uses and could keep reforming like 
putty until it is perfect. But we don't.

A modest proposal:

We can't keep tinkering with a language and it's libraries like this AND have a 
growing ecosystem that serves an ever widening base, including the range from 
newcomer to commercial deployment. SO - Why let's do all the language tinkering 
in GHC 8 there can be as many prereleases of that as needed until it is just 
right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing 
essential and dependable libraries, commercial work, projects on Haskell that 
we don't want to have to go back and #ifdefs to twice a year just to keep 
running, educators, people writing books. We can keep improving GHC 7 as 
needed, and focus on bugs, security issues, patches, cross compatibility, etc.

I'm just curious how much you think this would help, assuming that your 
solution would imply not upgrading to 8 until you're ready to. After all, you 
can already simply not upgrade now, and create (and distribute) fixes for bugs, 
security issues, cross-compatibility for 7 as you see fit.

While that's a popular thing to do in lots of systems (but if we don't it. for 
gnus sake let's not adopt the inane parity implies stability numbering 
convention), it leaves two major issues unaddressed.

#1, developer time. You need to get the people doing the work now to divide 
their efforts into the two branches.I don't know 

RE: Bang patterns

[Simon Peyton-Jones]

|   I have two proposals, I suppose:
|   - make bang patterns operate only on variables and wildcards
|   - make bang patterns in let altogether invalid
|  
|  Looking at this again made me realise that, as well as !_ and !varid
|  lexemes, we could also alter the decl production so that we get
|  decl - ...
|| pat rhs -- existing lazy binding production
|| '!' pat rhs -- new strict binding production
|  
|  That means that
|  let !(x, y) = e in ...
|  would still be valid, with the ! not actually being parsed as part of
|  the pattern, but would parse instead as a strict binding. 

Yes, I like this.  You could see the 
'!' pat rhs
production as cancelling the implied '~' that a let-binding usually gets (see 
the desugaring for lets in the report).

A bang really only makes sense
* At the top of a let, to cancel the implied '~'.  Like Johan I
   am very strongly in favour of using ! for this purpose.
* On a varid or '_', which otherwise match lazily
Hence Ian's proposal, which treats these two separately, makes sense.

For example, there's no point in the pattern (x, !(y,z)), because it behaves 
identically to (x, (y,z)).

We really do need to allow
f  !x  y !z = e
to mean f is strict in x and z.  There is an ambiguity here with a infix 
definition of (!), but it must be resolved in favour of the bang-pattern 
version.

I don't have a strong opinion about whether
f ! x y ! z = e
should mean the same; ie whether the space is significant.   I think it's 
probably more confusing if the space is significant (so its presence or absence 
makes a difference).

Simon



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

RE: 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 
Wallacehttp://www.haskell.org/pipermail/haskell-prime/2011-January/003335.html,
 in January 2011.

But please don't blame Malcolm or the 
committeehttp://hackage.haskell.org/trac/haskell-prime/wiki/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 
processhttp://hackage.haskell.org/trac/haskell-prime/wiki/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-prime@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 
hask...@benmachine.co.ukmailto:hask...@benmachine.co.uk wrote:
On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh 
ig...@earth.limailto: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-prime@haskell.orgmailto:Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

Yes, good point about idiom 1; I've added it.

S

| -Original Message-
| From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
| boun...@haskell.org] On Behalf Of AntC
| Sent: 10 June 2012 06:23
| To: haskell-prime@haskell.org
| Subject: Re: TypeFamilies vs. FunctionalDependencies  type-level
| recursion
| 
| Simon Peyton-Jones simonpj@... writes:
| 
| 
|  No I didn't intend to put more in the header, perhaps less.
|  I've added more clarification.
| 
|  Simon
| 
| Thanks Simon, I agree with keeping it terse; I agree with your yuk
| rating for `of'. At risk of bikeshedding over surafce syntax (for a
| feture that's still only a gleam in the eye) ...
| 
| I think we're going to see two idioms for overlapping instances:
| 
| Idiom 1: total instance (this would apply to all the HList examples). We
| only need one instance group for the whole; then it's the type family
| decl that seems superfluous. Perhaps we could allow:
| 
| type family Equal a b :: Bool where
| Equal a a = True
| Equal a b = False
| 
| type family HasMember a (b :: '[]) :: Bool where
| HasMember a '[] = False  -- (not
| overlapping)
| HasMember a ( a ': bs ) = True
| HasMember a ( b ': bs ) = HasMember a bs
| 
| Idiom 2: an instance group discriminated by the outermost type
| constructor, or by one of the arguments (this might apply for Monad
| Transformers). Then although the instance header is superfluous, it
| might be useful documentation:
| 
| module SomeLibrary where
| type family F a b :: ...
| 
| module MyModule where
| data MyType = ...
| type instance F MyType b where-- total function for a ~
| MyType
| F MyType Int = ...
| F MyType (Int, b) = ...
| F MyType b = ...
| 
| AntC
| 
| 
| 
| 
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime



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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

I have expanded the draft spec on
http://hackage.haskell.org/trac/ghc/wiki/NewAxioms
to answer some of the questions on AntC's discussion page.


From: haskell-prime-boun...@haskell.org 
[mailto:haskell-prime-boun...@haskell.org] On Behalf Of José Pedro Magalhães
Sent: 29 May 2012 11:14
To: AntC
Cc: haskell-prime@haskell.org
Subject: Re: TypeFamilies vs. FunctionalDependencies  type-level recursion

Hi,
On Tue, May 29, 2012 at 11:03 AM, AntC 
anthony_clay...@clear.net.nzmailto:anthony_clay...@clear.net.nz wrote:
Simon Peyton-Jones simonpj@...mailto:simonpj@... writes:


 See also http://hackage.haskell.org/trac/ghc/wiki/NewAxioms
 (as yet unimplemented)

 Simon

Thank you Simon (and Pedro).

Are you inviting comment/suggestions/requests for clarification at this stage?

Definitely! I think the design space should be explored in detail.

There is plenty of prior work/similar ideas to include in the references.

That document is not a paper draft; it's a draft of a design of a new GHC 
extension.

How's the best way to help? (Without unleashing a maelstrom.)

Perhaps having a wiki page where the problem of OverlappingInstances is 
discussed, and alternative solutions are proposed, so that at some point we can 
look at all of them and try to make an informed decision. I think it's good to 
have a wiki page to guide this sort of email discussion.


Cheers,
Pedro


AntC



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

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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

See also http://hackage.haskell.org/trac/ghc/wiki/NewAxioms
(as yet unimplemented)

Simon

| -Original Message-
| From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
| boun...@haskell.org] On Behalf Of AntC
| Sent: 24 May 2012 14:00
| To: haskell-prime@haskell.org
| Subject: Re: TypeFamilies vs. FunctionalDependencies  type-level
| recursion
| 
|  oleg@... writes:
| 
| 
| 
|  I don't think Overlapping Instances will be in Haskell' any time soon
|  since there are doubts about the soundness. Overlapping instances are
|  clearly unsound with type functions. Whether they are sound with
|  functional dependencies is not clear, but there are warning
|  signs:
| 
|  http://www.haskell.org/pipermail/haskell-cafe/2010-July/080043.html
| 
| I have now worked through that post in detail, thank you. And replied
| (on the cafe http://www.haskell.org/pipermail/haskell-cafe/2012-
| May/101417.html )
| 
| As SPJ says there, I don't expect there's any real difference in the
| fundeps approach compared to type families. And as a matter of taste, I
| find type families more easy to understand and reason about, and more
| *functional*.
| 
| But I don't see in SPJ's post any real doubts about soundness, just
| restrictions that would have to be imposed. He concludes I believe that
| if ..., then overlap of type families would be fine.
| 
| The only onerous restriction is that overlapping instances would have to
| be in a single module. And I don't think that is needed under my
| proposal to dis- overlap overlaps.
| 
| As a matter of interest, how would the TTypeable approach address those
| examples? Particularly the existentials (examples 3 and 4). How would it
| look inside the GADTs to discharge the constraints (or apply the type
| functions)?
| 
| I notice example 4 (and 1) 'exploits' separate compilation/imported
| overlapping instances to arrive at unsoundness. How does TTypeable
| handle imported instances?
| 
| AntC
| 
| 
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime



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

RE: String != [Char]

[Simon Peyton-Jones]

Don't forget that with -XOverloadedStrings we already have a IsString class.  
(That's not a Haskell Prime extension though.)

class IsString a where
fromString :: String - a

Simon

|  -Original Message-
|  From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
|  boun...@haskell.org] On Behalf Of Johan Tibell
|  Sent: 19 March 2012 15:54
|  To: Thomas Schilling
|  Cc: haskell-prime@haskell.org
|  Subject: Re: String != [Char]
|  
|  On Mon, Mar 19, 2012 at 8:45 AM, Thomas Schilling
|  nomin...@googlemail.com wrote:
|   Regarding the type class for converting to and from that type, there
|   is a perhaps more complicated question: The current fromString method
|   uses String as the source type which causes unnecessary overhead. This
|   is unfortunate since GHC's built-in mechanism actually uses
|   unpackCString[Utf8]# which constructs the inefficient String
|   representation from a compact memory representation.  I think it would
|   be best if the new fromString/fromText class allowed an efficient
|   mechanism like that.  unpackCString# has type Addr# - [Char] which is
|   obviously GHC-specific.
|  
|  I've been thinking about this question as well. How about
|  
|  class IsString s where
|  unpackCString :: Ptr Word8 - CSize - s
|  
|  It's morally equivalent of unpackCString#, but uses standard Haskell types.
|  
|  -- Johan
|  
|  ___
|  Haskell-prime mailing list
|  Haskell-prime@haskell.org
|  http://www.haskell.org/mailman/listinfo/haskell-prime



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

FW: 7.4.1-pre: Show Integral

[Simon Peyton-Jones]

I'm confused too.  I'd welcome clarification from the Haskell Prime folk.

S

-Original Message-
From: Serge D. Mechveliani [mailto:mech...@botik.ru] 
Sent: 23 December 2011 17:36
To: Simon Peyton-Jones
Subject: Re: 7.4.1-pre: Show  Integral

On Thu, Dec 22, 2011 at 08:14:54PM +, Simon Peyton-Jones wrote:
 |  2011/12/22 Edward Kmett ekm...@gmail.com:
 |   The change, however, was a deliberate _break_ with the standard that
 |   passed through the library review process a few months ago, and is now
 |   making its way out into the wild.
 |  
 |  Is it reasonable to enquire how many standard-compliant implementations
 |  of Haskell there are?
 
 Just to be clear, the change IS the standard.  GHC has to change to be 
 compliant. 
 At least that's how I understand it.


I am confused.
I am looking now at the on-line specification of  Haskell-2010, 
6.3 Standard Haskell Classes.
It shows that  Integral  includes  Show:  

   Eq Show 
 \   /
  Num 
  |
   Enum  Real 
  \   |
   Integral

This is also visible in the further standard class declarations in this chapter.

Hence, for  `x :: Integral a = a'  it is correct to write  (shows x ).
And  ghc-7.4.0.20111219  does not allow this.
So,  ghc-7.4.0.20111219  breaks the 2010 standard. Now, Edward Kmett writes that
this break is done deliberately.

Am I missing something?

I witness this for the first time: that GHC deliberately breaks the current 
Haskell standard.
Probably, many people (as myself) dislike this point of the standard.
Well, they can write a dummy Show implementation for their type T:
  showsPrec _ _ = showString (t :: T),

and wait for an improved standard, say, Haskell-II
-- ?

Regards,

--
Sergei
mech...@botik.ru






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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

Oleg

|  There seems no reason in principle to disallow
|  type instance F where
|F Int = Bool
|F a = [a]
| 
| 
| I would implement this as follows:
| 
|  type instance F x = F' (EQ (TYPEOF x) INT) x
|  type family F' trep x
|  type instance F' TRUE  x = Bool
|  type instance F' FALSE x = [x]

But you have just pushed the problem off to the definition of EQ.  And your 
definition of EQ requires a finite enumeration of all types, I think.  But * is 
open, so that's hard to do. What you want is
   type instance EQ where
   EQ a a = TRUE
   EQ _ _ = FALSE
and now we are back where we started.

Moreover, encoding the negative conditions that turn an arbitrary collection of 
equations with a top-to-bottom reading into a set of independent equations, is 
pretty tedious.

| First of all, can something be done about the behavior reported by
| David and discussed in the first part of the message
| 
|http://www.haskell.org/pipermail/haskell-prime/2011-July/003489.html

OK.  Can you give a small standalone test case to demonstrate the problem, and 
open a Track ticket for it?

| Second, what is the status of Nat kinds and other type-level data that
| Conor was/is working on? 

Julien is working hard on an implementation right now.  The Wiki page is here
http://hackage.haskell.org/trac/ghc/wiki/GhcKinds
Attached there are documents describing what we are up to.

| Would it be possible to add TYPEREP (type-level type representation)
| as a kind, similar to that of natural numbers and booleans?

Yes!  See 5.4 of the theory document. It's still very incoherent, but it's 
coming along.

Simon


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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

| GHC trac ticket on the feature, as you probably saw.  After a
| discussion with other people here at
| HacPhi, I've decided that what I'm going to attempt is to add
| type-level Maybes 

Hang on!  Julien Cretin (from INRIA) is doing an internship here at Cambridge 
with Dimitrios and me.  The primary goal is to support *typed* type-level 
programming; that is, to add a proper kind system to GHC.

Broadly our approach is like Conor's SHE system, with minor syntactic 
differences.  So type-level Maybes will appear automatically, as a special 
case, so it's probably a bit of a waste to implement them separately.  

There'll also be support for poly-kinded type-level functions, of course.

The stuff will be on a branch in the main ghc repo soon.

Julien: we should start a wiki page (see 
http://hackage.haskell.org/trac/ghc/wiki/Commentary, and look for the link to 
Type level naturals; one like that).  On the wiki you should 
 * add a link to the latest version of our (evolving) design document.
 * specify the branch in the repo that has the stuff
 * describe the status

Iavor's stuff is still highly relevant, because it involves a special-purpose 
constraint solver.  But Iavor's stuff is no integrated into HEAD, and we need 
to talk about how to do that, once you are back from holiday Iavor.

Simon

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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

| One thing you could do to help in this specific case would be to use a
| different M1 tag--e.g., M1 S ... for selectors and M1 NS ... for
| fields without selectors (or K1 NS).  I presume you've already
| considered this and/or it's too late to make such a change.  (Or to
| move the distinction up to the constructor with two different
| constructor tags, CR and CN for record and no-record.)

I don't think it's too late to make a change.  The stuff has only just gone in, 
so it's still very malleable.  There may be other considerations, but legacy 
code isn't one of them!

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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

| I'd like to summarize the relationship between functional dependencies
| and type functions, and propose a solution that should get rid of
| overlapping instances. The solution does not require messing with
| System-FC. In fact, it can be implemented today (although
| ungainly). A small bit of GHC support will be appreciated.

This sounds good.  I am keen to identify features that provide the 
expressiveness that you and David and others want.  However my brain is small.

Concerning 1. mutual dependencies I believe that equality superclasses 
provide the desired expressiveness.  The code may not look quite as nice, but 
equality superclasses (unlike fundeps) will play nicely with GADTs, type 
families, etc. Do you agree?

Concerning 2. combination with overlapping instances, you say The solution 
has been described already in the HList paper: provide something the typeOf at 
the type level. That is, assume a type function TypeOf :: * - TYPEREP.  

By the HList paper do you mean http://homepages.cwi.nl/~ralf/HList/?  I see 
no TYPEREP in that paper.  Do you think you might perhaps elaborate your 
proposed solution explicitly?  Perhaps saying explicitly:
  - This is the support we need from GHC
  - This is how you can then code examples X,Y,Z

I know that all of this is embedded variously in your past writings but I'm not 
very good at finding exactly the right bits and turning them into proposed 
features!

Incidentally Pedro's new deriving Generic stuff does derive a kind of 
type-level type representation for types, I think.  It's more or less as 
described in their paper.
http://www.dreixel.net/research/pdf/gdmh_nocolor.pdf

Thanks

Simon


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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

| By equality superclasses, do you just mean being able to say a ~ b
| in a class context? 

Yes.  Or (F a ~ b).

| Unless I'm missing something, that is not sufficient to do a lot of
| things I would like to do, as those things require both
| OverlappingInstances and FunctionalDependencies (as well as
| UndecidableInstances). 

Correct. Hence Oleg's second point 2. combination with overlapping instances.

Oleg claims to have a good story here.  I'd like to see how he uses it to solve 
your problem.

Simon

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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

| class C a b | a - b where
|   foo :: a - b
|   foo = error Yo dawg.
| 
| instance C a b where
| 
| The instance 'C a b' blatantly violates functional dependency and
| should not have been accepted. The fact that it was is a known bug in
| GHC. The bug keeps getting mentioned on Haskell mailing lists
| about every year. Alas, it is still not fixed. Here is one of the
| earlier messages about it:
| 
|   http://www.haskell.org/pipermail/haskell-cafe/2007-March/023916.html

Wait.  What about
instance C [a] [b]
?  Should that be accepted?  The Coverage Condition says no, and indeed it is 
rejected. But if you add -XUndecidableInstances it is accepted.  

It's just the same for 
instance C a b
It is rejected, with the same message, unless you add -XUndecidableInstances.

Do you think the two are different?  Do you argue for unconditional rejection 
of everything not satisfying the Coverage Condition, regardless of flags?

Simon

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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

There was an interesting thread on haskell-prime [1], about the relationship 
between functional dependencies and type families.  This message is my attempt 
to summarise the conclusions of that thread.  I'm copying other interested 
parties (eg Oleg, Dimitrios)
  [1] http://www.haskell.org/pipermail/haskell-prime/2011-May/003416.html

1. As things stand in GHC you can do some things with functional dependencies 
that you can't do with type families. The archetypical example is type 
equality.  We cannot write
type family Eq a b :: *
type instance Eq k k = True
type instance Eq j k = False
because the two instances overlap.  But you can with fundeps
class Eq a b c | a b - c
instance Eq k k True
instance Eq j k False
As Alexey mentioned, fundeps have other disadvantages, so it's reasonable to 
ask whether type families could extend to handle cases like this.

2.  In a hypothetical extension to type families, namely *closed* type 
families, you could support overlap:
closed type family Eq a b :: * where
  type instance Eq k k = True
  type instance Eq j k = False
The idea is that you give all the equations together; matching is 
top-to-bottom; and the type inference only picks an equation when all the 
earlier equations are guaranteed not to match.  So there is no danger of making 
different choices in different parts of the program (which is what gives rise 
to unsoundness).

3.  Closed type families are not implemented yet.  The only tricky point I see 
would be how to express in System FC the proof that earlier equations don't 
match.   Moreover, to support abstraction one might well want David's /~ 
predicate, so that you could say
f :: forall a b. (a /~ b) = ..blah..
This f can be applied to any types a,b provided they don't match.   I'm frankly 
unsure about all the consequences here.

4.  As Roman points out, type families certainly do support recursion; it's 
just they don't support overlap.

5.  David wants a wiki page fixed.  But which one? And how is it locked down?

6. There is a very old Trac wiki page about total type families here
http://hackage.haskell.org/trac/ghc/wiki/TypeFunctions/TotalFamilies
Written by Manuel, I think it needs updating.

That's my summary!

Simon

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

RE: TypeFamilies vs. FunctionalDependencies type-level recursion

[Simon Peyton-Jones]

|   
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies
|  
|  Currently under cons for FunctionalDependencies, it says:
|  
|   AssociatedTypes seem to be more promising.
|  
|  I proposed the following fix:
|  
|   AssociatedTypes seem to be more promising, but in their
|   current form are not as general as FunctionalDependencies
|   [link].

OK, that one.  I've made that change.

|  Is there a policy that only a proposal's owner can modify the wiki
|  page?  Or that you have to be a member of the Haskell' committee?  

I'm not sure.  Malcolm Wallace is chair at the moment; I'm ccing him.

Simon

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

RE: Proposal: Make gcd total

[Simon Peyton-Jones]

But see 
http://www.haskell.org/haskellwiki/Library_submissions/NewDraft
for a proposal for updating the core-libraries process.

Simon

| -Original Message-
| From: haskell-prime-boun...@haskell.org 
[mailto:haskell-prime-boun...@haskell.org] On
| Behalf Of Ian Lynagh
| Sent: 25 May 2011 23:48
| To: haskell-prime@haskell.org
| Subject: Re: Proposal: Make gcd total
| 
| On Wed, May 25, 2011 at 08:24:52PM +0200, Daniel Fischer wrote:
| 
|  If it's considered to be a small enough change so a libraries proposal
|  would be sufficient, all the better, but if not, I'd like to pursue the
|  haskell-prime process further.
| 
| My understanding is that for changes to libraries mentioned in the
| language report, we use the libraries@ process, not the H' process.
| 
| 
| Thanks
| Ian
| 
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime


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

RE: Add haskell-src as an official machine-readable component of the Haskell standard

[Simon Peyton-Jones]

See http://hackage.haskell.org/trac/ghc/ticket/4430 for what we are proposing 
for Template Haskell.

S


| -Original Message-
| From: haskell-prime-boun...@haskell.org 
[mailto:haskell-prime-boun...@haskell.org] On
| Behalf Of Lennart Augustsson
| Sent: 16 November 2010 19:52
| To: Ben Millwood
| Cc: haskell-prime@haskell.org
| Subject: Re: Add haskell-src as an official machine-readable component of the 
Haskell
| standard
| 
| Please explain.  Fixity information cannot be provided unless you find
| all the imported modules and process those, so I'm not sure how
| haskell-src-exts could do any better than it currently does.
| 
| 
|  (Examples of controversies possible in haskell-src: we have the Hs
|  prefix on constructors everywhere, we can't provide fixity information
|  (and the haskell-src-exts implementation of this is unsatisfactory in
|  several important ways), a lot of type class instances are absent
|  (even Ord!), the distribution of SrcLocs is a little awkward when
|  manipulating source abstractly, and some constructors allow impossible
|  values, e.g. HsLambda can contain zero patterns)
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime

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

RE: PROPOSAL: Include record puns in Haskell 2011

[Simon Peyton-Jones]

|  we implicitly get
|  f :: T - Int
|  which punning shadows with
|  f :: Int   
|  whereas I generally avoid shadowing completely.
| 
|  I agree with Ian.
| 
| I tend to agree.

I originally had field puns in GHC, and then took them out when Haskell 98 
removed them, after a discussion very like this one.  I put them back in 
because some people really wanted them.  

Actually GHC has three separate extensions to do with named fields:

field disambiguation (Section 7.3.14)
field puns (Section 7.3.15)
field wildcards (Section 7.3.16)

Look here 
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#disambiguate-fields


Opinions differ.  I'm rather with John: let the programmer choose, rather than 
enforcing a style in the language. For punning, the programmer can certainly 
choose on a case by case basis.  If you use Haskell 98's existing syntax, there 
is no change to the semantics if you switch on field puns:

data T = C { f :: Int }

foo (C {f = x}) = ...   -- No punning
bar (C {f}) = ...   -- Punning

It would help this discussion if someone created a ticket to explain the actual 
proposal, so that we are all discussing the same thing.

Simon

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

RE: Proposal: Hexadecimal floating point constants

[Simon Peyton-Jones]

|  Similarly, the greatest finite double value can be written as
|  0x1.fp+1023.
| 
|  These constants have the form
| 
|0x[HH][.H]p[+/-]DDD
| 
| If you don't want to wait on an (uncertain) inclusion into the Haskell
| standard, you can implement a small helper function to that effect
| yourself; essentially using  encodeFloat .

Or, alternatively, use quasiquoting

[hex| 1.fp+1023 |]

where 'hex' is a Haskell function that parses the string.

http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.html#th-quasiquotation

This has the advantage that you can use the constant in patterns too.

(In GHC 6.12 you have to say [$hex| 1.p+1023 |], with a $, but we're 
changing that for 6.14.  There's a thread on ghc-users about it.)

Simon

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

RE: Negation

[Simon Peyton-Jones]

| Of course unary minus should bind tighter than any infix operator.
| I remember suggesting this when the language was designed, but the
| Haskell committee was very set against it (mostly Joe Fasel I think).
| 
| I think it's too late to change that now, it could really introduce
| some subtle bugs with no parse or type errors.

I'm not sure it's too late to change.   That's what Haskell Prime is for.  The 
change would have a flag of course, and could emit a warning if the old and new 
would give different results.

I think I'll create a ticket at least.

| I imagine it would be something like deleting the production
| 
| lexp6-  - exp7
| 
| and adding the production
| 
| exp10-  - fexp

Yes, exactly

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

RE: bug in language definition (strictness)

[Simon Peyton-Jones]

| This suggests a natural implementation (and specification) for pseq,
| 
| pseq :: a - b - b
| pseq x y = x `seq` lazy y
| 
| where lazy :: a - a is a compiler provided function equivalent to 'id'
| except that it is considered lazy in its argument by the strictness
| analyzer.

Exactly so!  Here is the definition of `pseq` in GHC.Conc:

Conc.lhs:368:pseq :: a - b - b
Conc.lhs:369:pseq  x y = x `seq` lazy y


And 'lazy' is documented in the user manual:

http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC-Prim.html#v%3Alazy

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

RE: NoMonomorphismRestriction

[Simon Peyton-Jones]

| . Understanding how to respond to type inference and error messages is
| hard enough without having additional differences in innocent-looking
| code.  Do you think my hope is reasonable that not-generalizing could
| lead to better error messages? 

I don't think it's obvious one way or the other. We'll have to see.

| typechecker behaviors to think about.  I guess it's still possible to
| use explicit type-signatures to make let-bindings polymorphic,

Yes, just so

| in a way
| that is difficult or impossible for lambda or case? (I guess for lambda,
| it would require making the lambda into a rank-2 function, though I'm
| not sure how to do that syntactically.)

Easy:  \(x :: forall a. a-a) - blah

Simon

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

RE: StricterLabelledFieldSyntax

[Simon Peyton-Jones]

Personally I hate the fact that
f Z {x=3}
parses as 
f (Z {a=3})
because even though (as Iavor says) there is only one function application 
involved, it *looks* as if there are two.

Equally personally, I think that the presence or absence of white space is a 
powerful signal to programmers, and it's a shame to deny ourselves use of it.  
So I'd be quite happy with *requiring* there to be no space, thus Z{ x=3 }.  If 
that's tricky to lex, so be it.  (Though a token 
BRACE_WITH_NO_PRECEDING_WHITESPACE might do the job.)  But this would be a 
very non-backward-compatible change.

Simon

| -Original Message-
| From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-
| boun...@haskell.org] On Behalf Of Ian Lynagh
| Sent: 26 July 2009 21:53
| To: haskell-prime@haskell.org
| Subject: Re: StricterLabelledFieldSyntax
| 
| On Sun, Jul 26, 2009 at 10:16:28PM +0300, Iavor Diatchki wrote:
| 
|  On Sun, Jul 26, 2009 at 10:01 PM, Isaac
|  Dupreem...@isaac.cedarswampstudios.org wrote:
|   Iavor Diatchki wrote:
|  
|   I am strongly against this change.  The record notation works just
|   fine and has been doing so for a long time.  The notation is really
|   not that confusing and, given how records work in Haskell, makes
|   perfect sense (and the notation has nothing to do with the precedence
|   of application because there are no applications involved).  In short,
|   I am not sure what problem is addressed by this change, while a very
|   real problem (backwards incompatibility) would be introduced.
|   -Iavor
|  
|   a different approach to things that look funny, has been to implement a
|   warning message in GHC.  Would that be a good alternative?
| 
|  Not for me. I use the notation as is, and so my code would start
|  generating warnings without any valid reason, I think.  What would
|  such a warning warn against, anyway?
| 
| For context, I looked at the alsa package. All of the (roughly 10)
| would-be-rejected cases looked like one of the two examples below. I
| don't really have anything new to say: Some people think these are
| clear, others find them confusing. Hopefully we'll find a consensus and
| make a decision.
| 
| 
| throwAlsa :: String - Errno - IO a
| throwAlsa fun err = do d - strerror err
|throwDyn AlsaException
|  { exception_location = fun
|  , exception_description = d
|  , exception_code = err
|  }
| 
|   peek p  = do cl - #{peek snd_seq_addr_t, client} p
|po - #{peek snd_seq_addr_t, port} p
|return Addr { addr_client = cl, addr_port = po }
| 
| 
| Thanks
| Ian
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime

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

RE: [Haskell] Announcing the new Haskell Prime process, and Haskell 2010

[Simon Peyton-Jones]

| There are a couple sensible removals here.  Do we also want to get rid
| of the useless class contexts on data-declarations? (that look like
| data Ord a = Set a = Set ...)

Yes! Yes! Kill them.

(In GHC's source code these contexts are consistently called stupid_theta.)

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

RE: Proposal: Deprecate ExistentialQuantification

[Simon Peyton-Jones]

| That's why one should really be allowed to group constructor's in a
| type's definition:
| 
|data Colour :: * where
|  Red, Green, Blue :: Colour

Indeed.  GHC allows this now.  (HEAD only; will be in 6.12.)

Simon

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

RE: Proposal: ExplicitForall

[Simon Peyton-Jones]

| I would thus like to propose the following formalisation of the
| ExplicitForall extension:

What you suggest would be fine with me. Presumably ExplicitForall would be 
implied by RankNTypes and the other extensions?

There is a danger of having too *many* choices. 
(http://www.joelonsoftware.com/items/2006/11/21.html)  In particular, you might 
consider making ScopedTypeVariables synonymous with ExplicitForAll.  Once you 
have given up the keyword, it seems a shame not to allow lexically scoped type 
variables!  

On ExistentialQuantification, I personally think we should deprecate the entire 
construct, suggesting GADT-style syntax instead.

If you can form a consensus, go for it.

Simon

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

Newtype unwrapping in the FFI

[Simon Peyton-Jones]

[This email concerns an infelicity in the FFI spec. I'm directing it primarily 
to the Haskell Prime mailing list, but ccing the libraries list so that people 
there know about the thread. I suggest that replies go to Haskell Prime only.]

Consider this program (see http://hackage.haskell.org/trac/ghc/ticket/3008)

  module NT( N ) where
 newtype N = MkN Int

  module FFI where
 foreign import f :: N - IO ()

Is module FFI OK?  It would definitely be OK if N was defined in the module 
FFI: the FFI spec says that the compiler must automatically unwrap any newtype 
arguments.
http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2

But it's less clear when N is defined in another module *and* its 
representation isn't exported.  The author of NT might believe that because N's 
representation is hidden, she can change it to, say
data N = MkN Int
without affecting the rest of the world.  But she can't.  This is a nasty 
failure of abstraction.  It is, I believe the only way in which a client of a 
NT could be affected by N's representation, even though that representation is 
allegedly hidden.  (ToDo: check on generalised newtype deriving.) This seems 
Bad to me.

Indeed, the cause of the above bug report is that GHC's implementation assumes 
that the representation is fully hidden if the constructor is not exported, and 
does not expose the representation of N even to separately-compiled modules (at 
least when you are not using -O).

But the point here is not what GHC stumbles on but what is supposed to happen.

Maybe we should fix it.  Proposal:

  * Clarify the spec to say that a newtype can only be automatically
unwrapped if the newtype constructor (MkN in this case) is in scope

It happens that a large set of types from Foreign.C.Types, such as CInt and 
friends, are exported without their constructors, so adopting this new rule 
would require us to change Foreign.C.Types to expose the representation of CInt 
and friends.  (As it happens, nhc requires this already, so there's some 
#ifdeffery there already.)

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

RE: Newtype unwrapping in the FFI

[Simon Peyton-Jones]

|* Clarify the spec to say that a newtype can only be automatically
|  unwrapped if the newtype constructor (MkN in this case) is in
|  scope
|
| I agree up to here. For user-defined types, not exporting the
| constructor should be a guarantee of abstraction.
|
|  It happens that a large set of types from Foreign.C.Types, such as
|  CInt and friends, are exported without their constructors, so adopting
|  this new rule would require us to change Foreign.C.Types to expose the
|  representation of CInt and friends.  (As it happens, nhc requires this
|  already, so there's some #ifdeffery there already.)
|
| The thing about CInt though is that it is supposed to be abstract *and*
| an FFI type. I want to think of it as a primitive FFI type (though it is
| not a basic type as defined by the FFI). We don't want to know that on
| some system it is Int32 and on others it is Int64. We do not want access
| to the constructor here.

Trouble is, there are a zillion types in Foreign.C.Types, and another zillion 
in Foreign.Posix.Types. Do you want to list them all as blessed in the FFI 
addendum?

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

RE: Haskell' - class aliases

[Simon Peyton-Jones]

| The more I think about it, I think 'superclass' is just the wrong
| terminology for dealing with class aliases. Superclass implies a strict
| partial order on classes, which just isn't the case for class aliases,
| for instance
|
|  class alias Foo a = Foo a = Bar a where ...

Crumbs!  I have no idea what that means!  Did you really mean to repeat Foo?  
According to your expansion in type signatures
f :: (Foo a) = ...
expands to
f :: (Foo a, Bar a) = ...
which presumably expands again.  I'm totally lost here

Have a look at my last message, which gives a variant of your desugaring that 
IMHO greatly clarifies the meaning of (what I understand by) aliases.


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

RE: Haskell' - class aliases

[Simon Peyton-Jones]

|  Crumbs!  I have no idea what that means!  Did you really mean to repeat 
Foo?  According to your
| expansion in type signatures
|  f :: (Foo a) = ...
|  expands to
|  f :: (Foo a, Bar a) = ...
|  which presumably expands again.  I'm totally lost here
|
| Yes I did, because I wanted to make the differences between class alias
| contexts and superclasses very clear, the above context is valid, if
| vacuous. the expansion goes as follows .
| 1. Foo a -- reduce(Foo a,Bar a)
| -- Foo a expanded
...

Even more crumbs!  Is this fixpoint iteration (being careful to avoid infinite 
expansion) *really* essential to your proposal?  That would be a significant 
and unwelcome thing IMHO.

To be concrete, consider
f :: (Foo a) = ...

In GHC, f really takes an extra dictionary argument for the class Foo.  If 
aliases mean aliases in the sense of type synonyms (which I think you intend) 
you must expand Foo to find out whether f takes zero, one, or many dictionary 
arguments.  Furthermore, everyone must expand in precisely the same way, so 
that we agree on the order of these arguments.  That's reasonably simple if 
expand simply means normalise; but it's more complicated if there's a 
fixpoint algorithm involved.

So is this really crucial?

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

RE: The monomorphism restriction and monomorphic pattern bindings

[Simon Peyton-Jones]

| Ok.  So I counter-propose that we deal with pattern bindings like this:
|
|The static semantics of a pattern binding are given by the following
|translation.  A binding 'p = e' has the same meaning as the set of
|bindings
|
|  z = e
|  x1 = case z of { p - x1 }
|  ...
|  xn = case z of { p - xn }
|
|where z is fresh, and x1..xn are the variables of the pattern p.
|
| For bang patterns, I think it suffices to say that a bang at the top
| level of p is carried to the binding for z, and then separately define
| what banged variable bindings mean (i.e. add appropriate seqs).

Fair enough.  Although there will still be quite a bit of System F plumbing 
generated, I do agree that answers my questions about the static semantics of 
pattern bindings (*provided* we lift the MR).  And I agree that it gives a 
simple, consistent, and explicable story to the programmer.


The result may or may not do what you want though:
(f, g) = ( (+), (+) )
will generate

f :: (Num a, Num b) = a - a - a

which is ambiguous.  In general, pattern bindings for overloaded things are 
probably useless.  Perhaps worth pointing this out in the report.


Let's also make sure that the spec explicitly includes type signatures.  That 
is, the above transformation is carried out, and then the individual bindings 
for the xi are compared with their individual type signatures.


Simon

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

RE: instance export decls

[Simon Peyton-Jones]

Indeed! I think it'd be good to allow type signatures, including instance 
signatures, in export lists

module Foo(
data T (f :: * - *),
instance Functor f = Eq (T f),
g :: T f - T f
  )

The first step is to evolve a well-worked-out design. I think that'd be a very 
valuable thing for someone to do.  Indeed, I'd really like to see it in 
Haskell', but it doesn't meet the tried and tested criterion.

I'm a bit reluctant to invest effort in half-way-house solutions, though.

Simon


| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Serge D. Mechveliani
| Sent: 22 April 2008 13:33
| To: [EMAIL PROTECTED]
| Subject: instance export decls
|
| Dear GHC developers, people,
|
| Do you agree that there exists such a problem for a programmer as
| recalling exported instances?
| Have Haskell and/or GHC some constructs and tools to help the programmer
| to recall the exported instances for a module?
| Could GHC support the instance export messages for each module?
|
| In Haskell-98, the exported instances cannot be named explicitly in the
| export list.
| Right?
| But for easier understanding of a program, it is desirable to allow to
| name (in a short form) instances in the export list.
| For this reason, I add comments, and write the export like this:
|
|   module Poly
|   (WithHead(..), WithTail(..), -- classes
|Mon(..), Polynomial(..),
|lc, polMons
|-- , instances
|-- for Mon: WithHead, List;
|-- for Polynomial:  WithHead, Cast Polynomial Mon
|   )
| The comment of kind  -- , instances ...
| helps to recall which instances are exported, without inspecting all
| the (lengthy) module source.
|
| But when the programmer changes the source, one often forgets to
| add/remove the needed comments about instances.
| I often forget them (maybe, lazy to recall) when I move pieces of code
| between modules.
|
| So, I suggest the following feature for GHC.
|
| 1. To allow the export declarations of kind   instance {type}
|(maybe to suggest this for Haskell ?)
| 2. If the module under compilation has the word `instance' in its
|export list,
|then  ghc  finds the difference set  diff  for the exported instance
|kinds  eKinds  and the instance kinds  nKinds  named in the export
|list. If  not $ null diff,  it issues the message:
|Warning:  the exported instance kinds and the instance kinds named
|   in the export differ in the following items: 
|
| Seeing such a message, the user corrects the export list in the source
| according to  diff.
|
| For the export list and for their messages, it is probably better to
| use a short denotation: the instance kind rather than full instance
| declaration. In the instance kind, the part of (...) = is skipped.
|
| What people think of this suggestion?
|
| Thank you in advance for your notes and help,
|
| -
| Serge Mechveliani
| [EMAIL PROTECTED]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: Haskell' - class aliases

[Simon Peyton-Jones]

|  Fair enough.  But the strange syntax
| 
|  class alias Num a = Eq a = (Additive a, Multiplicative a)
| 
|  *does* seem so say that the (Eq a) behaves in a superclass way, and
|  (Additive a, Multiplicative a) behave in a class-alias way, as it
|  were.  That seems inconsistent with the design goal you describe
|  above.
|
| Wolfgang suggested the alternate syntax
|
| class alias Eq a = Num a = (Additive a, Multiplicative a) where 
|
| The correct reading being:
|
| if 'Eq a' then 'Num a' is an alias for (Additive a,Multiplicative a)
|
| I think I am coming around to his point of view, do you think this makes
| it clearer?

I am not arguing about syntax!

You say class aliases are orthogonal to superclasses, but then you allow this 
Eq a thing in the above alias, which is very like a superclass.  I think that 
if you allow the Eq a = part, you should also allow new methods to be 
declared in the alias (as I originally thought you did).  And if not, then you 
shouldn't allow superclasses.  It's precisely that you allow superclasses (Eq a 
=) that makes your feature non-orthogonal to ordinary superclasses.  Maybe you 
can't make them orthogonal, but it quite hard to explain this definition to me.

Incidentally, you say that your proposal is just syntactic sugar: if so, can 
you give the desugaring translation?

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

RE: The monomorphism restriction and monomorphic pattern bindings

[Simon Peyton-Jones]

| The report doesn't actually mention this translation although it is
| widely used to implement pattern bindings, and in some compilers (not
| GHC) the translation is done before type checking.
|
| What's interesting to me is that perhaps this gives us a way to
| understand what the static semantics of pattern bindings should be,
| absent MPB. e.g.

Yes, that's a fine point.  If this became the formal definition of the *static* 
semantics of pattern bindings, that would be a significant improvement, because 
it'd give us a precise way to answer the various questions I asked. (We might 
or might not like the answers, but at least we could answer them.)

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

RE: Haskell' - class aliases

[Simon Peyton-Jones]

John

OK here's a question about class alisas. You propose:

   class Foo a where
foo :: a - [a]
foo x = []
   class Bar a where
bar :: a - a
bar x = [x]

   class alias FooBar a = (Foo a, Bar a) where
foobar :: a - a
foobar x = x

foo x = bar x

I have a few minor questions about this that'd be worth clarifying on your main 
page
  (a) I assume you can add a method 'foobar' not declared
in either Foo or Bar.  Your very first example has this.
But it's contradicted later when you say that One can declare an 
instance
of Num either by giving separate instances for Eq, Additive, 
Multiplicative

  (b) And I assume that you don't need to repeat the type
signatures for 'foo' and 'bar'.

  (c) I think you intend that you can override the default methods
for foo and bar; and I have done so for method 'foo'.

Question: how does the above differ from this?

   class (Foo a, Bar a) = FooBarSC a where
foobar :: a - a

Here Foo, Bar are simply superclasses.  From the point of view of a type 
signature there *no* difference:

f :: (FooBarSC a) = ...

gives access to all the methods of Foo and Bar.  So what's the difference?

Answer (I believe): when you give an instance of FooBar
you give implementations for all methods of
Foo, Bar, and FooBar.

So the obvious question is: do we really need a new construct?  Why not just 
use FooBarSC?  Then we'd have to allow you to give implementations for 
superclass methods too:
instance FooBarSC Int where
  foobar = ...
  foo = ...
  bar = ...

I think I believe (like you) that this is a bad idea.  The main reason is that 
it's a totally unclear whether, given a FooBarSC Int instance declaration, 
should there be an instance for (Foo Int), always, never, or optionally?

However, I think you might want to articulate the reasons carefully, because we 
have two features that are really extremely close.

To put it another way, you could imagine re-expressing your proposal like this:

  class (Eq a)  (Additive a, Multiplicative a) = Num a

meaning this: when you give an instance for (FooBar T) you

 * MUST give implementations for the methods
of Addititive and Applicative

 * MUST NOT give implementations for methods of Eq;
rather the Eq T instance must be in scope.

This is, I believe, what you mean by
  class alias Num a = Eq a = (Additive a, Multiplicative a)

Now I'm not necessarily suggesting this as concrete syntax.  But my point is 
that you're really asking for small modification of the existing superclass 
mechanism, that divides the superclasses into two groups, the flat ones (like 
Additive and Multiplicative) and the nested ones (like Eq).  Is that right? 
If so, a syntax that is more suggestive of the current superclass declaration 
looks better to me.

This close relationship also suggests strongly that the answer to (a) above 
should be 'yes', since you can certainly add methods to a class with 
superclasses.


I won't say more until I'm sure I've understood your intent.

Simon



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

RE: The monomorphism restriction and monomorphic pattern bindings

[Simon Peyton-Jones]

| Iavor:
| the change is valid.  I do believe that you can probably work around
| the problem in many situations but the question in my mind is why
| should we have to work around stuff when we have a system that already
| works?  In other words, what problem do MBPs solve?
...
| Neil:
| Haskell has always had the attitude of doing what suits users, and
| making implementations work hard to handle the language features. In
| addition, this is a breaking change.


I have not made my case well!

1.  [Minor point] In general I agree with what Iavor and Neil say above, but it 
should not be an Iron Law.  If a small and easily-describable restriction in 
programming yields a significant simplification in implementation, that's a 
benefit that may be worth having.

2. More importantly, I am using System F *not* because it tells us about GHC's 
implementation, but because I have found that it's an excellent litmus test 
that tells when something smelly is going on.  The fact that one has to go 
through contortions to translate pattern bindings is a Bad Sign, I believe.

3. I'm more concerned about the programmer than the implementation.  Consider
(f,g) = (negate, show)
What type do you expect 'f' to have?  A straightforward answer might be
f :: (Num a, Show b) = a - a
If you don't want that, you need to explain a more complicated typing rule for 
pattern bindings.I'll ask the same about
(f,g) = (reverse, length)
A simple and consistent story is that all the pattern bound variables are 
generalised over all the class constraints and all the type variables of the 
RHS.  But I bet that is not what you want.

4.  Would it make a difference if you gave a type signature for f?  Can f,g 
have different sets of class constraints?  (H98 says 'no' for class 
constraints, but 'yes' for type variables, which is an obvious wart).

5.  I'm also concerned about the interaction with strictness.
let (f,g) = e in f (...f...g...)
Here 'f' is clearly used strictly, so the pair will certainly be evaluated.  
Does this mean the same?
case e of (f,g) - f (...f..g...)

6.  If we allow bang patterns, what does
!(f,g) = e
actually mean?


The implementation is not the driving force.  It's just the way I know that 
something is afoot.

What is the problem MPB tries to solve?  The problem of specifying the type 
system for pattern bindings. Try writing down the full typing rules for pattern 
bindings, including type signatures!  Higher-rank types too.

Simon

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

RE: Haskell' - class aliases

[Simon Peyton-Jones]

| I tried to see the discussion that led to class aliases being rejected
| as a proposal, but could not find links on the Wiki.  In fact, in Trac
| (#101) that proposal is still a 'maybe', but with no updates.  Is there
| a competing proposal that got accepted?
|
| [Without a mechanism like class aliases, breaking up Num into a
| hierarchy of proper mathematical concepts becomes too unwieldly to be
| realistic.  This is a real stumbling block for anyone trying to use the
| class system to encode fine-grained mathematical concepts.]

I think this is partly my fault for failing to implement the idea -- a full 
implementation is really a prerequisite for Haskell'.

One reason I've failed to do so is because I have not come under enough 
pressure!  If I thought there were dozens of people slavering at the chops for 
class aliases, that would put it more firmly on my radar.  Ben is right to say 
that it's much easier than the type-function stuff, which is decidedly tricky.  
 (Of course there nothing stopping someone else doing it, but GHC's typechecker 
is one of it's more richly-interconnected parts.)   Perhaps you have all just 
been very polite, and waiting in quiet but unrequited hope.

Is this the most up-to-date description of the proposal?
http://repetae.net/recent/out/classalias.html

I've just had another look, which threw up quite a few questions in my mind.   
I wonder what would be a good list to discuss it.  Maybe this one is not bad, 
because it has people interested in Haskell innovation, regardless of whether 
it's a live Haskell' candidate?

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

RE: Infix type and function definitions

[Simon Peyton-Jones]

| Just to clarify, issues of what names can be used for
| type constructors aside, are you proposing dropping
| infix syntax for defining functions, but retaining infix
| syntax for defining types (and type families etc.)?
|
| Or would the last example have to be written
|
| data (+) a b = Left a | Right b

I *am* proposing that varsyms become type *constructors* not type *variables*.

I can see arguments both ways for allowing definitions in infix form, and I 
don't have a strong position either way.

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

RE: Make it possible to evaluate monadic actions when assigning record fields

[Simon Peyton-Jones]

| In the end, I think that applicatively used monads are the wrong
| abstraction. For occasional use, liftM2 and `ap` often suffice. If the
| applicative style becomes prevalent, then Applicative Functors are
| likely to be the conceptually better choice. This is especially true
| for
| MonadReader. Arithmetic expressions are a case for liftM, too. And an
| instance (Monad m, Num a) = Num (m a)  allows to keep infix (+) and
| (*).
|
| Put differently, I don't see a compelling use-case for the proposed
| syntax extension. But I've seen many misused monads.

Can you be more explicit?  Monadic code is often over-linearised.  I want to 
generate fresh names, say, and suddenly I have to name sub-expressions.  Not 
all sub-expressions, just the effectful ones.  It'a a pain to define 
liftM_yes_no_yes which takes an effectful argument in first and third position, 
and a non-effectful one as the second arg:
liftM_yes_no_yes :: (a-b-c-m d)
- m a - b - m c - m d

What a pain.  So we have either

do { ...; va - a; vc - c; f va b vc; ... }

or
do { ...; liftM_yes_no_yes f a b c; ...}

or, with some syntactic sugar...

do { ...; f $(a) b $(c); ...}

The liftM solution is even more awkward if I want

f (g $(a)) b c
for example.

I'm thinking of this as a very superficial piece of syntactic sugar, aimed at 
avoiding the excessive linearization of monadic code.  Nothing deep.

Of course adding more syntactic sugar has a cost; but this one looks like 
having a good power to weight ratio.

Simon

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

RE: Make it possible to evaluate monadic actions when assigning record fields

[Simon Peyton-Jones]

Another alternative (which I got from Greg Morrisett) that I'm toying with is 
this.  It's tiresome to write

do { x - stuff1
   ; y - sutff2
   ; f x y }

In ML I'd write simply

f stuff1 stuff2

So Greg's idea (or at least my understanding thereof) is to write it like this:

do { f $(stuff1) $(stuff2) }

The idea is that a splice $e must be lexically enclosed by a 'do', with no 
intervening lambda.  It's desugared to the code above; that is, each splice it 
pulled out, in lexically left-right order, and given a name, which replaces the 
splice.

Of course it doesn't have to look like the above; the rule applies to any do:

do { v - this; foo $(h v); y - f $(t v v); ...etc }

The linearise the splices rule is quite general.

Don't burn any cycles on concrete syntax; I know the $ notation is used for 
Template Haskell; one would need to think of a good syntax.  But the idea is to 
make it more convenient to write programs that make effectful calls, and then 
use the result exactly once.

Anyway, this'd do what the original proposer wanted, but in a much more general 
way.

Just a thought -- I have not implemented this.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adde
| Sent: 10 July 2007 21:40
| To: [EMAIL PROTECTED]
| Cc: haskell-prime@haskell.org
| Subject: Re: Make it possible to evaluate monadic actions when assigning 
record fields
|
| On Tue, 2007-07-10 at 17:04 +, [EMAIL PROTECTED] wrote:
|  Isaac Dupree [EMAIL PROTECTED] wrote:
|   
|Adde wrote:
|  tmp - foo
|  return Bar {
|barFoo = tmp
|  }
|   
|There is a feature being worked on in GHC HEAD that would let you do
|   
|  do
|   tmp - foo
|   return Bar{..}
|   
|which captures fields from everything of the same name that's in scope.
|  I think this would also satisfy your desire.
|   
| 
|  I guess this means I could write:
| 
| 
|  data D = C {field1 :: Bool, field2 :: Char}
| 
|  f x = do
|field1 - foo1
|field2 - foo2
|field3 - foo3
|other stuff
|return C{..}
| 
| 
|  instead of
| 
| 
|  f x = do
|tmp1 - foo1
|tmp2 - foo2
|field3 - foo3
|other stuff
|return $ C { field1 = tmp1, field2 = tmp2 }
| 
| 
|  This has a dangerous feel to it ---
|  extending the definition of D to include a field field3
|  may have quite unintended consequences.
| 
| 
|  What I am missing most in the record arena
|  is a functional notation for record update, for example:
| 
|  {^ field1 }  =  \ f r - r {field1 = f (field1 r)}
|
| I agree, capturing variables without asking is just scary.
| While I'm pretty biased I still think my suggestion solves the problem
| in a cleaner, more consistent way.
|
| /Adde
|
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: Nested pattern binding translates to outermost binding?

[Simon Peyton-Jones]

In the section Changes to the Report of the Wiki page you refer to
http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
I attempted to give the semantics of bang-patterns by saying what changes would 
be needed in the Haskell Report.  If you think it's incomplete or ambiguous, 
then do yell.

(The wiki says that the changes are incomplete but I can't now think why!)

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan
| Weston
| Sent: 06 July 2007 20:08
| To: Haskell Prime
| Subject: Nested pattern binding translates to outermost binding?
|
|  From Haskell' ticket #76:
| http://hackage.haskell.org/trac/haskell-prime/wiki/BangPatterns
|
|   The main idea is to add a single new production to the syntax
|   of patterns
|pat ::= !pat
|
| Experiments (ghci -fbang-patterns -O2 -S, rename identifiers, then diff)
| shows that nested pattern bindings are equivalent to the outermost binding:
|
| !(!pat)  ==  !pat
| !(~pat)  ==  !pat
|
| ~(~pat)  ==  ~pat
| ~(!pat)  ==  ~pat
|
| but I do not see any wording to that effect either in the Haskell 98
| report, the GHC documentation, or the Haskell' wiki. Have I overlooked
| it, or does it follow from the existing language definition?
|
| Dan
|
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: type aliases and Id

[Simon Peyton-Jones]

| I don't think you need to produce 'a=Id (Tree Int)' since that
| reduces to 'a=Tree Int'.
| In general, you don't have to produce Id applied to anything, which
| gives me some hope that it's possible to add Id and still have
| decidable (and complete) type deduction.

Yes, that's true.  But I still don't know how to do inference.  Consider

f :: forall m a. m a - a - [a]
t :: Tree Int

and consider the call

f t t

Well, this is perfectly well typed thus (I'll add the type applications to make 
it totally clear):

f Id (Tree Int) t t

That is, instantiate  m=Id, a=Tree Int, and voila.  The trouble is, when 
unifying (m a) = (Tree Int), it's very unclear what to do.

Hmm. I suppose you might defer such unifications, instead gathering them as 
constraints, and solving them only when you quantify.  That's the standard way 
to deal with tricky unification problems.

It's certainly a nice challenge.

Simon

|
| Perhaps a good topic for a research paper?
|
| -- Lennart
|
| On Mar 20, 2007, at 12:00 , Simon Peyton-Jones wrote:
|
|  | Ganesh and I were discussing today what would happen if one adds Id
|  | as a primitive type constructor.  How much did you have to change
|  the
|  | type checker?  Presumably if you need to unify 'm a' with 'a' you
|  now
|  | have to set m=Id.  Do you know if you can run into higher order
|  | unification problems?  My gut feeling is that with just Id, you
|  | probably don't, but I would not bet on it.
|  |
|  | Having Id would be cool.  If we make an instance 'Monad Id' it's now
|  | possible to get rid of map and always use mapM instead.  Similarly
|  | with other monadic functions.
| 
|  I remember that I have, more than once, devoted an hour or two to
|  the question could one add Id as a distinguished type constructor
|  to Haskell.  Sadly, each time I concluded no.
| 
|  I'm prepared to be proved wrong.  But here's the difficulty.
|  Suppose we want to unify
|  (m a) with (Tree Int)
| 
|  At the moment there's no problem: m=Tree, a=Int.  But with Id
|  another solution is
|  m=Id, a=Tree Int
| 
|  And there are more
|  m=Id, a=Id (Tree Int)
| 
|  We don't know which one to use until we see all the *other* uses of
|  'm' and 'a'.
| 
|  I have no clue how to solve this problem.  Maybe someone else
|  does.  I agree that Id alone would be Jolly Useful, even without
|  full type-level lambdas.
| 
|  Simon

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

RE: type aliases and Id

[Simon Peyton-Jones]

| Ganesh and I were discussing today what would happen if one adds Id
| as a primitive type constructor.  How much did you have to change the
| type checker?  Presumably if you need to unify 'm a' with 'a' you now
| have to set m=Id.  Do you know if you can run into higher order
| unification problems?  My gut feeling is that with just Id, you
| probably don't, but I would not bet on it.
|
| Having Id would be cool.  If we make an instance 'Monad Id' it's now
| possible to get rid of map and always use mapM instead.  Similarly
| with other monadic functions.

I remember that I have, more than once, devoted an hour or two to the question 
could one add Id as a distinguished type constructor to Haskell.  Sadly, each 
time I concluded no.

I'm prepared to be proved wrong.  But here's the difficulty.  Suppose we want 
to unify
(m a) with (Tree Int)

At the moment there's no problem: m=Tree, a=Int.  But with Id another solution 
is
m=Id, a=Tree Int

And there are more
m=Id, a=Id (Tree Int)

We don't know which one to use until we see all the *other* uses of 'm' and 'a'.

I have no clue how to solve this problem.  Maybe someone else does.  I agree 
that Id alone would be Jolly Useful, even without full type-level lambdas.

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

RE: strict bits of datatypes

[Simon Peyton-Jones]

| This reminds me of something I discovered about using strict fields in
| AVL trees (with ghc). Using strict fields results in slower code than
| doing the `seq` desugaring by hand.

That is bad.  Can you send a test case that demonstrates this behaviour?

| If I have..
|
| data AVL e = E
| | N !(AVL e) e !(AVL e)
| .. etc
|
| then presumably this..
|
| case avl of N l e r - N (f l) e r
|
| desugars to something like ..
|
| case avl of N l e r - let l' = f l
| in l' `seq` r `seq` N l' e r
|
| but IMO it should desugar to..
|
| case avl of N l e r - let l' = f l
| in l' `seq` N l' e r

I agree.  If it doesn't please let me know!

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

RE: Polymorphic components, so far

[Simon Peyton-Jones]

|  | * Pattern matching on polymorphic fields.  This does not appear to be
|  | too controversial, although Atze  had some reservations about this
|  | design choice.
...
| So far, most replys seemed to agree that this is not a big
| restriction.  Could you give more details on how you think that should
| work?   If we follow the current rules for pattern simplification,
| then this feature might be a bit confusing.  Here is an example:
|
|  data T = C (forall a. [a-a])
| 
|  f (C (f:fs)) = ...
| 
|  f x = case x of
|  C y - case y of
|   f : fs - ...
|   _ - undefined
|
| Notice that in the translation, when we 'case' on the 'y' the list
| gets instantiated, so that 'f' is monomorphic.  There is nothing wrong
| with that but I think that the may be more confusing than useful.

Indeed; if you are going to match 'y' against a constructor, you must 
instantiate.  The translation is untyped so I don't think that's a problem.  
Indeed, you can regard the translation as specifying both the static and 
dynamic semantics.  That is
f (C (f:fs)) = ...
is well-typed iff
f x = case x of { C y - case y of { f:fs -... }}
is well-typed (as a Haskell source program).

Indeed, *not* allowing y to be polymorphic amounts to a special case of this 
rule that says f (C (f:fs)) is well-typed iff ... UNLESS one of the variables 
bound is polymorphic.  It seems simpler to be uniform, no?

The only difficulty in implementation is maintaining the translation into 
System F, but I know a tidy way to do that now.  And GHC is the only compiler 
that does that anyway.

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

RE: rank-2 vs. arbitrary rank types

[Simon Peyton-Jones]

| I don't think that the rank-N system is any more expressive then the
| rank-2 one.  The reason is that by placing a polymorphic value in a
| datatype we can decrese its rank.  In this way we can reduce a program

Hmm.  To be consistent, then, you'd have to argue for rank-2 data constructors 
only, since rank-2 functions can be simulated in the way you describe.

| This is good to know because it narrows our choices!  On the other
| hand, it is a bit unfortunate that we do not have a current
| implementation that implements the proposed rank-N extension.  I have
| been using GHC 6.4.2 as an example of the non-boxy version of the
| rank-N proposal, is this reasonable?

Yes, I think so.

| I am not convinced.  It seems to me that the higher rank polymorphism
| extension is still under active research---after only 1 major version
| of existsince, GHC has already changed the way it implements it, and
| MLF seems to have some interesting ideas too.

Well GHC changed *only* to reach for impredicativity, which is, as I say, a 
bridge too far for Haskell'.  Otherwise it was just fine.

MLF is also not relevant here, because its goal too is impredicativity, and it 
is a *much* more sophisticated type system with substantial implications for 
type inference.



I could say more, but let's see what others think.

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

RE: Polymorphic components, so far

[Simon Peyton-Jones]

Iavor

Does your proposal cover only higher-rank types for *data constructors*?  I 
don't think there is any problem with extending it to arbitrary functions, as 
our paper Practical type inference for higher rank types shows.  But the web 
page http://hackage.haskell.org/trac/haskell-prime/ticket/57 seems to cover 
only data constructors.

I hate the proposed restriction that a higher-rank function must be applied to 
all its polymorphic arguments. That's a hang-over from the earlier GHC rank-2 
design, and I don't think it's necessary.  Again, the paper gives the details.

| * Notation for polymorphic types with explicit quantifiers.  The main
| issue is if we should allow some corner case notational issues, such
| as empty quantifier lists, and quantified variables that are not
| mentioned in the type.
|   - option 1: disallow these cases because they are likely to be
| accidental mistakes.

I lean to this too.

| * Equality of schemes for labeled fields in different constructors.
| My suggestion did not seem to be too controversial.  Stephanie is
| leaning towards a more semantic comparison of  schemes.  Indeed, just
| using alpha equivalence might be a bit too weak in some cases.
| Another, still fairly syntactic option, would be to pick a fixed order
| for the variables in quantifiers (e.g., alphabetic) for the purposes
| of comparison.

GHC uses equality modulo alpha conversion, but not modulo reordering of type 
variables or contexts.  This is easy to explain to programmers, and of course 
it's easy for the programmer to ensure.  Why would you want the more expressive 
semantic equality in practice?  I think this a solution seeking a problem.   
Why complicate things?  (Same goes for the predicates in the context.  Let's 
insist they are the identical.)

| * Pattern matching on polymorphic fields.  This does not appear to be
| too controversial, although Atze  had some reservations about this
| design choice.

I removed this because I thought it was tricky to implement (given GHC's code 
structure).  But I needed something very similar for associated types, so now 
GHC's code structure makes it easy, and I'm planning to put it back in.

It's a small thing -- I have had one or two bug reports since removing it, but 
it's not a feature many will miss.  Still, it seems natural to allow it (e.g. 
disallowing it requires extra words in the language spec), which is why I think 
I'll add it.

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

RE: rank-2 vs. arbitrary rank types

[Simon Peyton-Jones]

| judgements (rather than boxes), no impredicativity, etc?  As I recall the
| treatment of application expressions there (infer type of the function,
| then check the argument) was considered a bit restrictive.  (It forbids
| runST $ foo, for example.)

That requires impredicativity, and that's the bit we don't understand very well 
yet.

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

RE: help from the community?

[Simon Peyton-Jones]

|  I can also imagine predicates that do not mention locally-quantified
|  variables - the assumption must be that they mention variables bound on
|  the LHS of the datatype decl instead?  e.g. the Show predicate here:
| 
|  data Foo a b = Foo a b
|   | Bar (forall c . (Show b, Relation b c) = (b,c))
| 
|  Hmm, maybe a simpler version of this example would illustrate what you
|  mean by the proposal (first of the three bullets) to allow an empty
|  quantifier list:
| 
|  data Foo a b = Foo a b
|   | Bar (forall . Show b = b)
| 
|  In which case, does this even count as a polymorphic component at all?
|  Is it not rather GADT-like instead?
| 
|  data Foo a b where
|Foo :: a - b - Foo a b
|Bar :: Show b = b - Foo a b
|
| I was thinking that we should allow those special cases because I
| could not see a reason to disallow them (rather then having a
| compelling example to use them).   You make a good point though, that
| some of them might indicate an error in the program.  So, I guess, the
| main decision is: do we want to make them illegal (i.e., require an
| error) or suggest that implementations report a warning?  I have no
| strong feelings either way, but I guess we need to pick something.

I think I know what we should do on this particular point.  I've even 
documented it here:
http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type-extensions.html#gadt-style

I would like to urge this design, or one close to it, for Haskell'.  Note that 
this is *not* the same as adopting GADTs.

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

RE: [Haskell] Views in Haskell

[Simon Peyton-Jones]

|  In my opinion, views are going to make more Haskell more complicated, and
|  from what I have seen so far, for little gain.
|
| We need some kind of pattern extension *now* for bytestring
| matching/views and bit parsing, though. Stuff that's used in large, real
| world Haskell programs :)

Would you care to elaborate?   After all, pattern guards get quite a lot of the 
way.

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

RE: [Haskell] Views in Haskell

[Simon Peyton-Jones]

| First, I'm not clear what Simon meant by first class abstractions
| in this comment
|
|  Several proposals suggest first class abstractions rather that
|  first-class patterns. Here are the ones I know of ...

Sorry to have been un-clear.  By a first class abstraction I mean a value of 
type
something - something
with a syntax something like
\ pattern - body

The abstraction includes both the pattern and the result.  In contrast, view 
patterns tackle only the syntax of patterns; the pattern of a first-class 
abstraction.  I'll update the wiki

A first-class *pattern*, on the other hand, really ought to be something like 
(a,b), where a and b are *binders*.  This is what Barry Jay means by a 
first-class pattern in his very interesting work (which I should reference from 
the wiki).  See The Patten Calculus 
http://www-staff.it.uts.edu.au/~cbj/Publications/chronological.html

Still, I think it's likely that I'm exaggerating, and that view patterns and 
first-class abstractions are tied up together somehow.  But I don't grok 
exactly how.

Simon

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

RE: [Haskell] Views in Haskell

[Simon Peyton-Jones]

| is that clearer?

yes, thanks.  I'm not quite sure whether it all means you think view patterns 
are good; or that they would be good with a tweak; or that something else would 
be better.

Do feel free to edit the wiki to articulate any design alternatives that you 
think deserve consideration.

Regardless of whether any of this gets implemented, I think the wiki page can 
usefully summarise a description of at least a local part of the design space.

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

Views in Haskell

[Simon Peyton-Jones]

There's been lots of interesting feedback about the views proposal -- thank you.

Many of the suggestions amount to plausible design alternatives.  If I do all 
the editing, I'll just become a bottleneck, and I'm more than usually 
snowed-under at the moment.  So I've moved the Wiki page to the GHC wiki, which 
is world-editable.  It's here
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns

The wiki isn't a good place for to-and-fro debate, but it is a good way to 
capture design alternatives.  If those with alternatives to propose would like 
to add them (in an even handed way needless to say) to the wiki page, that'd be 
good.  Feel free to re-structure the text if that'd make it clearer.

The big question is, as several people have observed, whether the (modest) gain 
is worth the (also modest) pain.  If the proposal has merit, it is its extreme 
simplicity.  There's no comparison with things like class aliases, which are a 
Much Bigger Deal on both those metrics.

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

RE: [Haskell] Views in Haskell

[Simon Peyton-Jones]

| 1 I am a bit concerned about the use of non-linear patterns in your examples.
| There are good arguments for non-linear patterns, and Haskellers have 
made good
| arguments against non-linear patterns. But you seem to suggest allowing 
non-linear
| patterns in some cases (related to view patterns), but not in others 
(general patterns).
| That is likely to be confusing.

I don't think view patterns are non-linear at all!  They are just as linear as 
Haskell's existing patterns.  Definitely no implicit use of equality, for 
example.

| 2 view patterns nicely separate expressions in patterns from pattern 
variables. But I
| didn't realize at first that view patterns can be used nested inside 
other patterns.
|
| Yet this variable binding during nested matching is the essential 
contribution, and
| the only reason why the extra syntactic sugar is justified. Perhaps this 
point could
| be repeated and emphasized in The proposal more formally, for people 
like me?-)

I've added a section called Nesting.   You can readily edit it (since I moved 
the page) to amplify if you think it would help.

| 3 what you call first class abstractions are not entirely orthogonal to view 
patterns.
| taking Tullsen's and my own proposal as examples:

I'm afraid I don't follow this.  I think they are entirely orthogonal.

| 4 whether to use view patterns inside ordinary patterns, or whether to build 
up
| patterns from abstract de-constructors (just as expressions are built from
| abstract constructors) may seem only a question of style. but if your aim 
is
| to encourage people to transition from exporting concrete data types to
| exporting abstract types only, the latter approach seems more consistent
| to me.

Again, I didn't follow

| 5 possible extension 1 smells of superfluous complexity. There is almost no 
gain
| compared to using tuples, but there's a lot to pay in added types and 
rules.

You may well be right.

| 6 possible extension 2 seems a non-starter if we want compositional abstract
| patterns, and I certainly do want them. Imagine the example in (4) with
| explicit Maybe.
|
| Being able to have compositional abstract patterns would be the make-or-break
| criterion for me. Without them, new syntactic sugar wouldn't be justified, 
with
| them, their precise form is a matter of convenience.

I think I must be missing what you mean by a compositional abstract pattern.


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

RE: [Haskell] Views in Haskell

[Simon Peyton-Jones]

[Redirecting to haskell-prime]

| In the related work, the Active Patterns proposal by Palao et at is missing:
|
| http://portal.acm.org/citation.cfm?id=232641coll=portaldl=ACM
|
| I thought this work should be included in the list because, I believe,
| they were the first to point out that computation should take place
| before matching, which was not the case in Wadler's and Burton's
| proposals?  They also proposed  types for patterns.

Good point. I've added them.  I think the Wadler/Burton stuff did allow for 
arbitrary computation; it's just that there was no way to do the value-input 
thing.  (Pattern synonyms, on the other hand, do not.)

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

RE: String literals

[Simon Peyton-Jones]

In my experience I've seen more requests for overloaded *Boolean* literals than 
strings.  In a Fran context, for example.

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Lennart Augustsson
| Sent: 11 November 2006 03:49
| To: Haskell Prime
| Subject: String literals
|
| I think it's time that string literals got overloaded just like
| numeric literals.  There are several reasons for this.  One reason is
| the new fast string libraries.  They are great, but string literals
| don't work; you need to pack them first.  Another reason is the
| increasing use of Haskell for DSELs.  In a DSEL you might want string
| literals to have a different type than the ordinary String.
|
| I have not implemented anything yet, but I would like to see
| something along the lines of the following:
|
| class IsString s where
|  fromString :: String - s
| instance IsString String where
|  fromString = id
|
| The instance declaration is not allowed in Haskell-98, but it can be
| rewritten as
| class IsChar c where  -- Make this class local to it's defining module
|  fromChar :: Char - c
| instance IsChar Char where
|  fromChar = id
| instance (IsChar c) = IsString [c] where
|  fromString = map fromChar
|
| And, like with numeric literals, any string literal will then have an
| implicit fromString insert to make the right conversion.
|
| My guess is that the defaulting mechanism needs to be extended to
| default to the String type as well, or we'll get some ambiguous
| expressions.
|
| Any thoughts?
|
| -- Lennart
|
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: Proposal for stand-alone deriving declarations?

[Simon Peyton-Jones]

The thread about stand-alone deriving is long-ish now, so I have summarised 
the issues here:
http://haskell.org/haskellwiki/GHC/StandAloneDeriving

Perhaps those who are interested can add their thoughts?  Bjorn is busy at the 
moment, but I think he'll get back to the implementation in a while, so now is 
a good time to refine the design.

I've tried to note all the issues that came up by email, but I might have 
missed.

I put it on the GHC wiki, because I'm not proposing it for Haskell'.  (Someone 
else is free to do so, of course.)

Simon

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| John Meacham
| Sent: 30 October 2006 05:17
| To: haskell-prime@haskell.org
| Subject: Re: Proposal for stand-alone deriving declarations?
| 
| On Fri, Oct 06, 2006 at 10:39:39AM -0500, Michael Shulman wrote:
|  On 10/6/06, John Hughes [EMAIL PROTECTED] wrote:
|  deriving (Eq Foo, Ord Foo)
|  
|  instead of
|  
|  deriving (Eq, Ord) for Foo
| 
|  So what does
| 
|  newtype Foo a = Foo a
|  newtype Bar b = Bar b
|  class C a b
|  deriving (C (Foo a) (Bar b))
| 
|  mean?  I could see it meaning any or all of the following:
| 
|  instance (C (Foo a) b) = (C (Foo a) (Bar b))
|  instance (C a (Bar b)) = (C (Foo a) (Bar b))
|  instance (C a b) = (C (Foo a) (Bar b))
| 
| 
| this is why we should make this explicit when deriving complex newtype
| instances, so we would write exactly the instance we want to derive:
| 
|  deriving (C (Foo a) b) = (C (Foo a) (Bar b))
|  deriving (C a (Bar b)) = (C (Foo a) (Bar b))
|  deriving (C a b) = (C (Foo a) (Bar b))
| 
| respectively.
| 
| John
| 
| --
| John Meacham - ⑆repetae.net⑆john⑈
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: Proposal for stand-alone deriving declarations?

[Simon Peyton-Jones]

Thanks for doing this.  

Is this the syntax we settled on?  I remember we discussed it at some length

S

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Bjorn Bringert
| Sent: 05 October 2006 09:05
| To: haskell-prime@haskell.org
| Subject: Proposal for stand-alone deriving declarations?
| 
| On http://hackage.haskell.org/trac/haskell-prime/wiki/
| DerivedInstances it says:
| 
| - There is no way to derive an instance of a class for a data type
| that is defined elsewhere (in another module).
| 
| Though there is no proposal to fix this. Would such a proposal be
| appropriate for Haskell'?
| 
| 
| If so, I propose to add a top-level declaration on the form:
| 
| 'deriving' qtycls 'for' qtycon
| 
| which produces the same instance as a deriving clause in the
| declaration of the datatype or newtype would.
| 
| 
| I have recently (thanks to the GHC Hackathon) implemented this in GHC.
| 
| /Björn
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: Proposal for stand-alone deriving declarations?

[Simon Peyton-Jones]

| What is not so nice is that you take a new keyword ('for'), which is
| quite likely to have been used as a variable name in existing code.
(Or
| does it work out to use one of the 'special' names here?)

The latter is what Bjorn has done.  That is, 'for' is only special in
this one context.  You can use it freely otherwise.  As I understand it
anyway.

| I think it would be useful to write the proposal in complete detail up
| on the Haskell' wiki.

Yes please.  Bjorn?  (It may just be a qn of transcribing the user
manual stuff you have written.)

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

RE: Class System current status

[Simon Peyton-Jones]

| So it looks like we're stuck at pretty much the same proposals for the
| class system.
...
| More generally, our discussion about the class system seems to be
| stalled. How should we to come to a decision?

I summarise my view of the state of play in the message below, which I
see I did not circulate to all of haskell-prime at the time.

My suggestion is this:

* Specify MPTCs in the main language

* Specify FDs in an Appendix (with some reasonably conservative
interpretation of FDs). 

* A Haskell' implementation should implement the Appendix, and
programmers can write programs against it.  But
we are advertising specifically that we aren't sure, one way
or the other, whether FDs will stay in the language for ever

I think it's probably too early even to have an Appendix describing ATs.
I'd be surprised if the experience of implementing and using them
doesn't have impact on their design.

The other alternative I can see is to delay the whole process until we
know more (a year or two), but I can see that is unattractive.

Simon


| -Original Message-
| From: Simon Peyton-Jones
| Sent: 04 May 2006 14:36
| To: [EMAIL PROTECTED]
| Cc: Martin Sulzmann; Stephanie Weirich; Ross Paterson; isaac jones;
Ravi Nanavati; Andres Loeh;
| John Launchbury; Simon Peyton-Jones
| Subject: RE: Class System current status
| 
| | I don't think I ever argued that we put ATs in Haskell'.  I am
arguing
| | that we should not put FDs in.
| 
| I think Haskell' MPTC situation is clarifying in my mind as follows
| 
| 1) We definitely want MPTCs
| 
| 2) MPTCs without either FDs or ATs or CHRs are not very useful.
| 
| 3) ATs are shaping up to be a better *programming* notation than FDs,
in the same way that FDs are
| better than CHRs.  This isn't an issue of expressiveness; it concerns
ease of inference and ease of
| programming.
| 
| 4) However, we have lots of experience of programming with, and
implementing FDs; but virtually
| none about ATs.  The situation might be very different in a year's
time, when we have an AT
| implementation, and some experience of use.
| 
| 
| I take (3) to be somewhat controversial.  We have little evidence to
go on, so far.  Nevertheless I'd be
| interested to know if (as of today) anyone would positively prefer a
language of FDs compared to one
| with ATs.
| 
| 
| All this makes me think that it will be hard to reach a satisfying
conclusion in a few months.  Perhaps
| this isn't the moment to force a conclusion.  An alternative might be
to punt the whole issue into a
| (longer-timescale) Blessed Appendix.  (I don't think that the rest of
the language depends much on
| this, although certain libraries do.)
| 
| Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org//mailman/listinfo/haskell-prime

Superclass inference (was: termination for FDs and ATs)

[Simon Peyton-Jones]

| Superclass implication is reversed when performing type inference.
| In the same way that instance reduction is reserved.
| 
| Here's the example again.
| 
|  class C a
|  class F a where
|type T a
|  instance F [a] where
|type T [a] = [[[a]]]
|  class C (T a) = D a
|  ^
| type function appears in superclass context
|  instance D [a] = C [[a]] -- satisfies Ross Paterson's Termination
Conditions
| 
| Consider
| 
|   D [a]
| --_superclassC (T [a]), D [a]
| --_type function C [[[a]]], D [a]
| --_instance  D [[a]], D [a]
| and so on
| 
| Of course, you'll argue that you apply some other inference methods.

Probably!  Let me explain what GHC does today, and see if that helps.
GHC tries to solve the following problem:

Input: a set of given constraints G
a set of wanted constraints W

Output: evidence that Y can be deduced from G+instance decls


During solving, GHC maintain two sets: the given set GG and the
wanted set WW. 

XX is maintained closed under superclasses; that is, when adding a
constraint (C t) to GG, I add all of C's superclasses.  GG is
initialised from G, closing under superclasses.

WW is initialised to W, but is *not* closed under superclasses.

Then we repeatedly pick a member of WW
a) if it's in GG, we are done
b) otherwise use an instance decl to simplify it, 
putting the new constraints back in WW
c) if neither applies, error.

In the pure inference case, the algorithm is slightly different:
Input: a set of wanted constraints W
Output: a minimal set of wanted constraints, G
  plus evidence for how to deduce W from G

GG starts empty.  The algorithm is the same as before, but in case (c)
we add the constraint to GG (plus its superclasses).  At the end,
extract G from GG; we want all the things that were not the
superclass-closure extras.


--

The point of explaining this is to say that in your example, (D [a]) is
part of Y, so GHC won't add D [a]'s superclasses in the first place, and
the problem you describe doesn't arise.  I don't know whether that is
luck, good judgement, or perhaps wrong.  

---

In the presence of ATs, I think that when adding a member to XX, or to
YY, we need to normalise the types wrt AT rewrites (a confluent
terminating process) first.  But that should do it.  (Of course, I have
proved nothing.)

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

RE: Concurrency, FFI status

[Simon Peyton-Jones]

Good summary.  I have made a few edits mainly to clarify what (I think)
is being said.

Under cooperative or preemptive concurrency I'd like someone two write
down as precisely as possible what it means to say the spec requires
cooperative concurrency or the spec requires preemptive concurrency.
That would set the context for the following choices

Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Simon Marlow
| Sent: 13 April 2006 14:42
| To: haskell-prime@haskell.org
| Subject: Concurrency, FFI status
| 
| I have now summarised the concurrency proposal status, here:
| 
| 
|
http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/Concurren
| cy
| 
| I have tried to summarise the various points that have arisen during
the
| discussion.  If anyone feels they have been mis-paraphrased, or I have
| forgotten something, please feel free to edit, or send me some text
for
| inclusion.  I don't want to include long gobs of text in here, though:
| just summarise the main points, and if necessary link to relevant
| mailing list posts.
| 
| Cheers,
|   Simon
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: FDs and confluence

[Simon Peyton-Jones]

| there are interesting problems in FDs, but it seems that the
confluence
| problems were merely problems of the old translation, not anything
| inherent in FDs! I really had hoped we had put that phantom to rest.

Claus

You're doing a lot of work here, which is great.  Why not write a paper?
Even for people (like me) who are relatively familiar with FDs, it's
hard to follow a long email thread.  For others, who might well be
interested, it's even harder.  The phantom is not resting yet!   (On the
other hand, email can be a good way of developing the ideas, which is
what you have been doing.)

A good way forward might be to write a paper building on our recent JFP
submission, and proposing whatever changes and improvements you have
developed.  That would make your work accessible to a much wider
audience.  

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

RE: deeqSeq proposal

[Simon Peyton-Jones]

| Any function that is not defineable in (pure) Haskell should be viewed
| with utmost suspicion.  The seq function is one of these.  At least
| seq has simple denotational semantics, which can't be said for
deepSeq.
| 
| I say, put deepSeq in a type class (which is what I've done when I
need
| it).

The whole *point* is that deepSeq is (dynamically) idempotent: deepSeq
(deepSeq x) = deepSeq x.  Its denotational behaviour is perfectly
definable in Haskell, but its operational behaviour is not.  That is
both attractive (because it means you feel less anxious about wasting
work with deepSeq) and repellent (because it constrains the
implementation, as John points out).

Whether it should be in a class is a rather separate discussion.  In a
way we already sold out when we allowed seq to escape from the
type-class world.  Perhaps deepSeq is worse (because it traverses data
structures) but not obviously. 

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

RE: deeqSeq proposal

[Simon Peyton-Jones]

| well, there is a difference there in that 'seq' is unimplementable in
| haskell, so the design comitee had freedom to implement it however
they
| wanted. 

class Eval a where
  seq :: a - b - b

instance Eval (a,b) where
   seq (_,_) b = b

instance Eval [a] where
   seq [] b = b
   seq (_:_) b = b

etc

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

RE: deeqSeq proposal

[Simon Peyton-Jones]

| Well, my worry was partly about the suggested version of deepSeq that
| would not diverge on circular structures (since circular structures
| are just one way to implement infinite data structures).

Dynamic idempotence is not the same as detecting circular structures.
Deepseqing a circular structure should definitely diverge, as it would
as if it was infinite.  Idempotence changes the operational behaviour,
but not the denotational behaviour.  So that part of the worry is ok.

But since the dynamic-idempotence operational behaviour is (as I
understand the proposal) the whole point, it's true that the
implementation would be constrained.  In the same kind of way that we
expect call-by-need rather than call-by-name.  

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

RE: limitations of newtype-derivings (fixed)

[Simon Peyton-Jones]

I like this idea.  Needs fleshing out though.

|  * you can only newtype derive the last argument to a MPTC.
|  * you cannot co-derive an instance for multiple newtype renamings.
| 
| it seems that both these can be solved when combined with the other
| proposed extension, allowing deriving clauses to be separate from data
| definitions.
| 
| basically, we would allow deriving anywhere.
| 
|  deriving (Show Foo)

I'm all for that.  A modest but useful gain. All we need is the syntax,
and that is something that Haskell Prime might usefully define.


|  newtype Id = Id Int
|  data Term = ...
|  newtype Subst = Subst (IM.IntMap Term)
| 
| ideally, we'd like an MapLike instance, but we'd have to tediously
write
| it ourselves. if we allow the supergeneralized newtype deriving, we
can do:
| 
|  deriving(MapLike Id Term Subst)

Now things aren't so clear.  You are assuming that we have an instance
instance MapLike Int a (IntMap a)

But suppose we also had an explicit instance decl for
instance MapLike Int Term Subst
which we might.  Which would the 'deriving' base its instance on? We
might also have an explicit instance 
instance MapLike Id a (IntMap a)
Now it's even less obvious which to use.

What if the newtype was buried more deeply.  Can we say
deriving( C (Foo Id) )
if we happen to have an instance for C (Foo Int) around already?  Here
the newtype isn't at the top level of the class argument.


GHC's newtype-deriving mechanism is very precise: it unwraps exactly one
layer of exactly one newtype.  It's attractive to go further, as you
describe, but it'd need to be tightly specified.  (And of course, that
increases the complexity of the overall language.)

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

RE: FDs and confluence

[Simon Peyton-Jones]

Interesting!  It'd be great if you've found a simpler more uniform rule.
(Which you seem to be getting rather good at.)Let's see if you can
convince Martin, first, and then articulate the proposed rules.  I'll
look fwd to that.

Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Ross Paterson
| Sent: 10 April 2006 09:53
| To: haskell-prime@haskell.org
| Subject: FDs and confluence
| 
| (see the FunctionalDependencies page for background omitted here)
| 
| One of the problems with the relaxed coverage condition implemented
| by GHC and Hugs is a loss of confluence.  Here is a slightly cut-down
| version of Ex. 18 from the FD-CHR paper:
| 
|   class B a b | a - b
|   class C a b c | a - b
| 
|   instance B a b = C [a] b Bool
| 
| Starting from a constraint set C [a] b Bool, C [a] c d, we have two
| possible reductions:
| 
| 1) C [a] b Bool, C [a] c d
|   = c = b, C [a] b Bool, C [a] b d   (use FD on C)
|   = c = b, B a b, C [a] b d  (reduce instance)
| 
| 2) C [a] b Bool, C [a] c d
|   = C a b, C [a] c d (reduce instance)
| 
| The proposed solution was to tighten the restrictions on instances to
| forbid those like the above one for C.  However there may be another
| way out.
| 
| The consistency condition implies that there cannot be another
| instance C [t1] t2 t3: a substitution unifying a and t1 need not
| unify b and t2.  Thus we could either
| 
| 1) consider the two constraint sets equivalent, since they describe
|the same set of ground instances, or
| 
| 2) enhance the instance improvement rule: in the above example, we
|must have d = Bool in both cases, so both reduce to
| 
|   c = b, d = Bool, B a b
| 
|More precisely, given a dependency X - Y and an instance C t, if
|tY is not covered by tX, then for any constraint C s with sX = S tX
|for some substitution S, we can unify s with S t.
| 
|We would need a restriction on instances to guarantee termination:
|each argument of the instance must either be covered by tX or be
|a single variable.  That is less restrictive (and simpler) than
|the previous proposal, however.
| 
| Underlying this is an imbalance between the two restrictions on
instances.
| In the original version, neither took any account of the context of
the
| instance declaration.  The implementations change this for the
coverage
| condition but not the consistency condition.  Indeed the original form
of
| the consistency condition is necessary for the instance improvement
rule.
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: deeqSeq proposal

[Simon Peyton-Jones]

|  let xs' () = 1 : 2 :  xs' ()
|  let xs2 = xs'
| 
|  let xs = 1 : 2 : xs
| 
|  So deepSeq xs2 == _|_, but deepSeq xs == xs

No, no.  deepSeq of either should be _|_.  

That's easy to achieve, even with the marking idea.  Simply do a
depth-first walk, but mark the node *after* traversing all its children,
not before. That way, if there's a cycle you'll diverge, as you should!
But you still get the effect that   
deepSeq (deepSeq x) = deepSeq x
(dynamically).

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

RE: New syntax

[Simon Peyton-Jones]

|  Template Haskell breaks expressions with $,
| 
| It's very bad that with TH enabled you cannot write sections of the
form ($ x)
| anymore which are sometimes very handy.

I'd prefer it if TH only sprang into action when you wrote
$x
or
$(f x)

That is, no space after the $.  If you put spaces, you should get the
H98 $.  

If anyone feels like fixing this, I think it'd be a good thing to do.

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

RE: MPTCs and functional dependencies

[Simon Peyton-Jones]

My current take, FWIW.

* MPTCs are very useful.  They came along very rapidly (well before
H98).  I think we must put them in H'

* But MPTCs are hamstrung without FDs or ATs

* FDs and ATs are of the same order of technical difficulty, as Martin
says

* ATs are (I believe) a bit weaker from the expressiveness point of view
(zip example), but are (I believe) nicer to program with.  

* BUT we have way more experience with actually programming with FDs.
ATs fail the well-established test by a mile.

* Largely due to Martin's work, we now have a much better handle on just
what restrictions on FDs make type inference tractable.  So I believe
there is a solid MPTC+FD story that we could embody in H'.

* Medium term, I think ATs may *at the programming-language level*
displace FDs, because they are nicer to program with.  But that's just
my opinion, and we don't have enough experience to know one way or the
other.


Tentative conclusion: H' should have MPTC + FDs, but not ATs.

Simon


| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Ross Paterson
| Sent: 02 February 2006 11:25
| To: haskell-prime@haskell.org
| Subject: MPTCs and functional dependencies
| 
| On Thu, Feb 02, 2006 at 11:38:07AM +0100, John Hughes wrote:
|  The problem with Haskell 98 is that it *lacks* features which
|  have become absolutely essential to Haskell programmers today. Those
|  features are what really *need* discussion and energy spent on them.
| 
|  [...]
| 
| Multi-parameter classes with functional dependencies
|- used everywhere... for example in monad transformers... so
|  *must* be included this time
|- omitted from Haskell 98 because the right design wasn't
clear
|- it's still unclear! Functional dependencies *in some form*
|  are essential, but associated types and datatypes look nicer
|  in many ways!
|- is it too late, in practice, to replace fundeps by something
|  else? How will we know? If we are to standardize on
associated
|  types instead, we need a major effort to *make sure* all
|  important applications of fundeps can be represented. How
will
|  we organize that?
| 
| I agree that MPTCs are much less useful (though not completely
useless)
| without something like FDs or associated types.  But the specification
| of FDs is far from clear: the system described in Mark's paper is
quite
| a bit weaker than what is implemented by GHC and (more shakily) by
Hugs.
| It seems that associated types aren't ready yet, but I don't think FDs
| are either, accustomed as people are to them.
| 
| I have another worry about MPTCs.  They require require relaxations on
| the form of instances (FlexibleInstances on the wiki), which in turn
| require relaxations on contexts and thus deferred context reduction
(see
| FlexibleContexts).  The result is that missing instances get reported
| later than they do now.  MPTCs are very useful and probably necessary,
| but there is a cost.
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: bringing discussions to a close

[Simon Peyton-Jones]

| As mentioned in my email from Tuesday March 21 [1], I'd like to bring
| most threads to a close very soon, and to document your discussions on
| the wiki.  The only topics that should remain open are concurrency and

Just before we do I'd like to mention one point that John Hughes and I
discussed:

Proposal: make all pattern bindings completely monomorphic
(regardless of type signatures)

At the moment you can say
let (f,g) = e in ...
and get *polymorphic* values f,g.  This causes a good deal of trouble in
the implementation (think of what the System F translation looks like),
and it's an odd thing to do.  Why odd?  Well here it's fine:
data T = C (forall a. a-a)
h x = let C f = e in ...
Constructor C has a polymorphic argument, so we can match e against (C
f) and get a polymorphic function.  But in the first example, (,) only
takes monomorphic arguments, so we have to generalise after selection.
To put it another way, even if the ... is definitely strict in f, we
cannot transform to
case e of (f,g) - ...

I've been meaning to give GHC a flag to give it this behaviour, so that
I can see if any Haskell programs break.  My bet is that this is a
feature that is tricky to implement, but which is virtually never used.
Removing it would simplify the language.

I have made a ticket for this
http://haskell.galois.com/trac/haskell-prime/ticket/103

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

RE: Infix expressions

[Simon Peyton-Jones]

| The second header line shows categories, whereas the links in the grey
| boxes are to articles. The idioms category collects together
articles
| that are about idioms.
| 
| We could have an idioms or programming techniques article as well,
| of course. It only needs to be written.

Interesting.  I thought there would be a rationale!

But my point is this: I didn't even know that there is a concept of a
category on the Haskell web site.  And I visit it regularly.  An
innocent visitor certainly won't.  Now I know that there is such a
concept, but I have no idea what it might mean, or how I might use it.

My suggestion: by all means have categories, whatever they are.  But can
we arrange the home page of Haskell.org so that a new and ignorant
visitor can simply look on the visible page (without prior knowledge)
and know where to go?   And can there be some information readily
accessible that explains what categories are, and how to use them and
add to them?

Sorry to be stupid about this.

Simon

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

RE: Infix expressions

[Simon Peyton-Jones]

If it is sufficiently non-obvious to require this thread, perhaps it'd
be worth adding the relevant guidance can be added to the idioms page
itself?

Incidentally, I looked on the Haskell home page for links to programming
idioms and advice, but came up empty.  The obvious place to look was
under Using Haskell, but I didn't find anything.  Was I being stupid?
Haskell.org is the obvious place to look for advice about programming in
Haskell.

S

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Donald Bruce Stewart
| Sent: 15 March 2006 23:49
| To: Malcolm Wallace
| Cc: haskell-prime@haskell.org
| Subject: Re: Infix expressions
| 
| Malcolm.Wallace:
|  [EMAIL PROTECTED] (Donald Bruce Stewart) writes:
| 
|   Yes, this is _exactly_ the kind of thing to add to the Idioms
|   page of the wiki, here:
|  http://www.haskell.org/haskellwiki/Category:Idioms
|   So if anyone knows of an interesting Haskell trick, and wants to
write
|   about it,  add a page!
| 
|  It is not entirely clear _how_ to add a page hanging off Idioms.
When
|  you click on Edit this page, the text edit box contains only a
single
|  word: [[Category:Haskell]], and no visible record of the existing
text.
|  Rather confusing, and there is no link to add a new page or
similar.
| 
| To add your page to a particular category, have [[Category:Idioms]]
(for
| example) appear at the bottom of the page -- it then appears
automagically.
| 
| You add a new page just by typing that page's url into your browser.
| You'll get a blank page suggesting that you create it (once you log
on).
| 
| -- Don
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: Infix expressions

[Simon Peyton-Jones]

|  Incidentally, I looked on the Haskell home page for links to
programming
|  idioms and advice, but came up empty.  The obvious place to look was
|  under Using Haskell, but I didn't find anything.  Was I being
stupid?
|  Haskell.org is the obvious place to look for advice about
programming in
|  Haskell.
| 
| There should be a link to Idioms above the grey boxes?

Oh yes so there is!  But what is the rationale for what goes in those
two header lines, and what goes in the grey box lists?  Why would
idioms be in the first place but not the second, and FAQ in the second
but not the first?  Perhaps we could have just the grey boxes?
(Incidentally idioms is too short to tell me follow me.  Something
like Programming techniques would be more suggestive.)

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

RE: Infix expressions

[Simon Peyton-Jones]

I often wish that cool tricks like this could be collected on the
Haskell web site.  Now that it's a wiki, anyone could do that.

Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| [EMAIL PROTECTED]
| Sent: 15 March 2006 04:34
| To: [EMAIL PROTECTED]; haskell-prime@haskell.org
| Subject: Infix expressions
| 
| 
| Doaitse Swierstra wrote:
|  In Haskell we write `f` in order to infixify the identifier f. In
ABC
|  the stuff between backquotes is not limited to an identifier, but
any
|  expression may occur there. This would allow one to write e.g.
| 
|xs `zipWith (+)` ys
| 
| Chung-chieh Shan and Dylan Thurston showed the Haskell98 solution for
| exactly the same example, in their article `Infix expressions',
| back in 2002:
|
http://www.haskell.org/pipermail/haskell-cafe/2002-July/003215.html
| 
| For ease of reference, here's their elegant solution:
| 
|  infixr 0 -:, :-
|  data Infix f y = f :- y
|  x -:f:- y = x `f` y
| 
|  main = print $ [1,2,3] -: zipWith (+) :- [4,5,6]
| 
| 
| For completeness, here's the `dual':
| 
|  infixr 5 -!
|  (-!) = flip ($)
|  infixr 5 !-
|  (!-) = ($)
| 
|  add2 x y = x + y
|  add3 x y z = x + y + z
|  add4 x y z u = x + y + z + u
| 
|  testa1 = 1 -! add2 !- 3 + 4
|  testa2 = 1 -! add3 1 !- 3 + 4
|  testa3 = 1 - 2 -! add4 1  5 !- 3 * 4
| 
| All code is Haskell98.
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: relaxed instance rules spec (was: the MPTC Dilemma (please solve))

[Simon Peyton-Jones]

Claus,

I urge you to read our paper Understanding functional dependencies via
Constraint Handling Rules, which you can find here
http://research.microsoft.com/%7Esimonpj/papers/fd%2Dchr/.

It will tell you more than you want to know about why relaxing
apparently-conservative rules is entirely non-trivial.   It's one of
those areas in which it is easy to suggest a plausible-sounding
alternative, but much harder to either prove or disprove whether the
alternative a sound one.

The paper describes rules we are reasonably sure of.   It would be great
to relax those rules.  But you do need to have a proof that the
relaxation preserves the properties we want.  Go right ahead!  The paper
provides a good framework for such work, I think.

Simon

| -Original Message-
| From: Claus Reinke [mailto:[EMAIL PROTECTED]
| Sent: 28 February 2006 19:54
| To: Simon Peyton-Jones; haskell-prime@haskell.org
| Subject: relaxed instance rules spec (was: the MPTC Dilemma (please
solve))
| 
| The specification is here:
|
http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extension
s.html#instance-decls
| 
| two questions/suggestions about this:
| 
| 1. there are other termination criteria one migh think of, though
| many will be out because they are not easy to specify. but here
| is an annoyingly simple example that doesn't fit the current rules
| even though it is clearly terminating (it's not even recursive):
| 
| class Fail all -- no instances!
| 
| class TypeNotEq a b
| instance Fail a = TypeNotEq a a
| instance TypeNotEq a b
| 
| class Test a b where test :: a - b - Bool
| instance TypeNotEq a b = Test a b where test _ _ = False
| instance Test a a where test _ _ = True
| 
| main = print $ (test True 'c', test True False)
| 
| never mind the overlap, the point here is that we redirect from
| Test a b to TypeNotEq a b, and ghc informs us that the
| Constraint is no smaller than the instance head.
| 
| it is true that the parameters don't get smaller (same number,
| same number of constructors, etc.), but they are passed to a
| smaller predicate (in terms of call-graph reachability: there
| are fewer predicates reachable from TypeNotEq than from
| Test - in particular, Test is not reachable from TypeNotEq).
| 
| this is a non-local criterion, but a fairly simple one. and it
seems
| very strange to invoke undecidable instances for this example
| (or is there anything undecidable about it?).
| 
| 2. the coverage condition only refers to the instance head. this
| excludes programs such as good old record selection (which
| should terminate because it recurses over finite types, and is
| confluent -in fact deterministic- because of best-fit overlap
| resolution):
| 
| -- | field selection
| infixl #?
| 
| class Select label val rec | label rec - val where
|   (#?) :: rec - label - val
| 
| instance Select label val ((label,val),r) where
|   ((_,val),_) #? label = val
| 
| instance Select label val r = Select label val (l,r) where
|   (_,r)   #? label = r #? label
| 
| now, it is true that in the second instance declaration, val is
| not covered in {label,(l,r)}. however, it is covered in the
recursive
| call, subject to the very same FD, if that recursive call complies
| with the (recursive) coverage criterion. in fact, for this
particular
| task, that is the only place where it could be covered.
| 
| would it be terribly difficult to take such indirect coverage (via
| the instance constraints) into account? there'd be no search
| involved (the usual argument against looking at the constraints),
| and it seems strange to exclude such straightforward consume
| a type recursions, doesn't it?
| 
| cheers,
| claus

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

RE: overlapping instances and constraints

[Simon Peyton-Jones]

Overlapping instances are undoubtedly useful, but they raise lots of
interesting questions.  Such as

- A program that type checks can have its meaning changed by adding an
instance declaration

- Similarly adding import M() can change the meaning of a program (by
changing which instances are visible

- Haskell would need to be a lot more specific about exactly where
context reduction takes place.  Consider
f xs x = xs == [x]
Do we infer the type (Eq a) = [a] - a - Bool?  Thereby committing to
a particular choice of instance?  Or do we (as GHC does) infer the type
(Eq [a]) = [a] - a - Bool, so that if f is applied at (say) type
Char, then an instance Eq [Char] instance would apply.  GHC is careful
to do the latter.

- When exactly is overlap permitted?  Is this ok?
instance C a Int
instance C Bool b
Previously GHC rejected this, on the grounds that it could be ambiguous
when you came across (C Bool Int).  But not GHC accepts it, on the
grounds that (C Bool Char) is quite unambiguous.  

[Actually this last point is relevant for MPTCs even if overlap isn't
allowed.]


Concerning using the instance context, yes, it's attractive, but it
involves *search* which the current mechanism does not.  Presumably you
have in mind that the type system should commit only when there is
only one remaining instance declaration that can fit.  You need to be
very careful not to prune off search branches prematurely, because in a
traditional HM type checker you don't know what all the type are
completely.  And you need to take functional dependencies into account
during the search (but not irrevocably).   I have not implemented this
in GHC.  I don't know anyone who has.   I don't even know anyone who has
specified it.


All good stuff to debate.  I'd be happy to see the traffic on MPTCs
reach half the level that syntax debates do!  In general, I think that
type-system proposals are much easier to evaluate when accompanied with
formal type rules.  It's not just a macho thing -- it really helps in
debugging the dark corners.


Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Claus Reinke
| Sent: 26 February 2006 16:28
| To: haskell-prime@haskell.org
| Subject: overlapping instances and constraints
| 
| 
| the point about overlapping instances is that they shouldn't,
| so we are looking for ways to resolve what looks like overlaps
| unambiguously, so that there are no overlapping instances left.
| 
| we don't want overlapping instances in the language definition,
| but we do want more expressive means of defining non-
| overlapping instances.
| 
| 1. resolving overlaps in favour of the most specific declaration
| does so, so why is that approach slated as adopt: probably no?
| 
| http://hackage.haskell.org/trac/haskell-prime/ticket/54
| 
| 2. FDs can help to make types in instance declarations more
| specific, thus avoiding some overlaps or at least helping the
| best-match to resolve overlaps. defaults resolve some of
| the simplest overlaps (which instance of Num did you mean?),
| but not others, because their overloading is not expressed in
| terms of classes (which empty list did you mean?).
| 
| 3. in this context, could someone please remind me what exactly
| is the reason that class constraints in instance declarations are
| ignored when deciding whether two instances overlap?
| 
| we have two worlds to consider, the unconstrained world of
| semi-decidable type class programming, and the restricted
| world which guarantees termination of type class inference.
| 
| in the first world, it seems there is no reason not to look at
| the constraints, because there are no termination guarantees
| anyway. and in the second world, it seems there is no reason
| not to look at the constraints, because we know that doing
| so will terminate nicely, thank you.
| 
| so why are some instance declarations still rejected as
| overlapping even if their constraints clearly say they don't?
| 
| cheers,
| claus
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: Export lists in modules

[Simon Peyton-Jones]

These days, hs-boot files are pretty close to source files, with masses
of stuff omitted.

However, you must process the import declarations of the hs-boot file to
figure out the name spaces involved.  In the original source file, you
can't process the import declarations because those modules have not
been compiled yet.  It's not clear which ones to omit.

Similarly in the body of the source file, there are lots of references
to things in imported modules, but those imported modules have not been
compiled yet.

You could imagine
a) compiling recursive groups all at once
b) somehow magically filtering the source file to omit anything
undefined, leaving only defined stuff. which ought to be enough to
tie the knot.

But GHC currently requires the programmer to perform (b) manually.

Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Ben Rudiak-Gould
| Sent: 23 February 2006 21:26
| To: haskell-prime@haskell.org
| Subject: Re: Export lists in modules
| 
| Malcolm Wallace wrote:
|  An explicit interface would be useful for many purposes besides
|  machine-checked documentation.  For instance, it could be used to
|  eliminate the hs-boot or hi-boot files used by some compilers when
|  dealing with recursive modules.
| 
| Why *does* ghc require hs-boot files? What can be gleaned from an
hs-boot
| file that couldn't be expressed in the corresponding hs file? For
example,
| why doesn't ghc simply require that at least one module in a recursive
group
| contain an explicit export list mentioning only explicitly typed
symbols?
| 
| -- Ben
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: the MPTC Dilemma (please solve)

[Simon Peyton-Jones]

I would not say that it's well-specified, no.   What we do know is this:
GHC may loop if you use -fallow-undecidable-instances -- but if it
terminates, the program is well typed and should not go wrong at
runtime.

S

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| Ashley Yakeley
| Sent: 21 February 2006 20:13
| To: haskell-prime@haskell.org
| Subject: Re: the MPTC Dilemma (please solve)
| 
| Simon Peyton-Jones wrote:
| 
|  Of course -fallow-undecidable-instances still lifts all
restrictions,
|  and then all bets are off.
| 
| Is the behaviour of GHC with -fallow-undecidable-instances (and
| -fcontext-stack) well-understood and specifiable? It is a very useful
| option, as you can join (meet?) classes like this:
| 
|class P a
|class Q a
| 
|class (P a,Q a) = PQ a
|instance (P a,Q a) = PQ a
| 
| --
| Ashley Yakeley
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: Array interface refactoring

[Simon Peyton-Jones]

|  Perhaps this e-mail could be read more generally as a
| request to consistencify/update the (Data) libraries
| in general 
...
| 
|  Is this possible for Haskell'?  Or is this too much
| of a break?  If it's possible, I'm happy to build a
| wiki page for discussion (I noticed that a short page
| has been started.)

Library design is certainly part of the Haskell' process, as I
understand it.  And the refactoring you describe sounds sensible and
desirable.  What it needs is someone willing to take up the cudgels and
do it.  Library design takes real work.

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

RE: the MPTC Dilemma (please solve)

[Simon Peyton-Jones]

With help from Martin Sulzmann and Ross Paterson, GHC (HEAD) now
implements a richer form of functional dependencies than Mark Jones's
version, but still decidable etc.  The rules for what must appear in the
context of an instance declaration are also relaxed.  

The specification is here:

http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions
.html#instance-decls

I think this is a step forward, and a serious candidate for Haskell'.  I
think that if you stick to these rules, everything is nailed down as
Martin so rightly says it should be.  And I am not sure we can go much
further.

Of course -fallow-undecidable-instances still lifts all restrictions,
and then all bets are off.

Many thanks to Ross and Martin.  You can try it out by downloading a GHC
snapshot (or by building from source).

Simon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
| isaac jones
| Sent: 11 February 2006 01:29
| To: haskell-prime@haskell.org
| Subject: the MPTC Dilemma (please solve)
| 
| I've created a wiki page and a ticket to record solutions to what I'm
| calling the Multi Parameter Type Class Dilemma.  It's summarized
| thusly:
| 
| MultiParamTypeClasses are very useful, but mostly in the context of
| FunctionalDependencies. They are particularly used in the monad
| transformer library found in fptools. The dilemma is that functional
| dependencies are very, very tricky (spj). AssociatedTypes are
| promising but unproven. Without a solution, Haskell' will be somewhat
| obsolete before it gets off the ground.
| 
| I've proposed a few solutions.  Please help to discover more solutions
| and/or put them on the ticket/wiki.
| 
| Wiki page:
| http://hackage.haskell.org/trac/haskell-prime/ticket/90
| 
| Ticket:
|
http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClasses
Dilemma
| 
| 
| peace,
| 
|   isaac
| 
| 
| 
| --
| isaac jones [EMAIL PROTECTED]
| 
| ___
| Haskell-prime mailing list
| Haskell-prime@haskell.org
| http://haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime

RE: Bang patterns, ~ patterns, and lazy let

[Simon Peyton-Jones]

I've updated the Wiki to add your strict proposal, but rather briefly.
If you want to add stuff, send it to me and I'll add it.

Meanwhile:

| And as a consequence, it is no longer possible to transform a pair of
| bindings into a binding of a pair. In Haskell 98,
| 
| p1 = e1
| p2 = e2
| 
| is always equivalent to
| 
| (~p1, ~p2) = (e1,e2)

In your strict proposal, I'm sure you hope that the above pair would be
equivalent to
(p1,p2) = (e1,e2)
which would be even nicer.

But sadly I don't think it is, because that'd change the strongly
connected component structure.  Somehow that smells wrong.

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

RE: Scoped type variables

[Simon Peyton-Jones]

| I think we should do the simplest thing that could possibly work,
| and then see if we really need more.  By work, I mean a compatible
| extension of H98 that makes it possible to add type signatures for
| local bindings (which isn't always possible in H98).  How about:
| 
|  * no implicit binding of type variables: to bind, use forall.
| 
|  * pattern type annotations allowed only at the top level of pattern
|bindings and lambda arguments (not on sub-patterns or arguments of
|function bindings).
| 
|  * no result type annotations (except on pattern bindings, where
they're
|equivalent to top-level pattern type annotations).
| 

I agree with the simplest thing plan.  But if HPrime is to include
existentials, we MUST have a way to name the type variables they bind,
otherwise we can't write signatures that involve them.  Stephanie and
Dimitrios and I are working on this scheme:

* Scoped type variables stand for type *variables*, not types.

* Type variables are brought into scope only by one of two ways:
   a) The forall'd variables of a declaration type signature
  f :: forall a b. type
f x y = e

   b) A pattern type signature may bring into scope a skolem bound
in the same pattern:
data T where
  MkT :: a - (a-Int) - T
f (MkT (x::a) f) = ...

The skolem bound by MkT can be bound *only* in the patterns that

are the arguments to MkT (i.e. pretty much right away).

The idea is that scoped type variables can be bound either at, or very
close to, the point at which they are actually abstracted.

This is a good topic to debate.  S+D+I will try to put forth a set of
rules shortly.

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

RE: Restricted data types

[Simon Peyton-Jones]

|  Have we considered Restricted Data Types?
| 
|  http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
| 
|
| Finally, I wrote my paper before fundeps came on the scene. Some of
the contortions I went through
| in my simulation of RDTs could be avoided with the help of fundeps.

A key point in the RDT paper, I think, was the ability to *abstract over
a type class*.  Now that is something one could consider adding to
Haskell, as the SYB3 paper argues. (See my home page.)

Suppose that one could abstract over a type class.  How would the RDT
paper change?  I'm not sure.

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

RE: Re[2]: Restricted Data Types

[Simon Peyton-Jones]

| data Eq a = Set a = Set (List a)
| 
| that is a sort of extension i will be glad to see. in my Streams
| library, it's a typical beast and i forced to move all these contexts
| to the instances/functions definitions:

Another reasonable alternative is

data Set a = Eq a = Set (List a)

Operationally, a dictionary for (Eq a) is stored in the Set constructor
along with the List a.  Haskell (and GHC) doesn't allow this at the
moment, but it would make perfect sense to do so, I think.  The type of
Set remains
Set :: forall a. Eq a = List a - Set a
The type of member would become
member :: a - Set a - Bool
(with no Eq constraint).

The typing rule for 'case' on a constructor with a context, like Set,
would be to make the Eq dictionary available in the right-hand side of
the case alternative:
case e of { Set xs - Eq a available in here...  }

I am not sure whether it would address all of the cases in John's paper,
but it'd address some of them.

It would be a significantly less radical step than Restricted Data Types
I think.  In particular, with GADTs imagine:
data T where
  C :: forall a b. (Eq a, Num b) = a - a - b - T b

All Haskell compilers that support existentials will capture the (Eq a)
dictionary, and make it available to the rhs of the case alternative.
It would be weird not to capture the (Num b) dictionary in the same way.


In short, a sensible design for GADTs will pretty much have to embrace
this.  GHC's implementation is trailing this a bit, I'm afraid, as GADT
users will know.  Making GADTs and type classes play nicely,
particularly with a typed intermediate language, is interesting.

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