RE: Request for feedback: deriving strategies syntax

[Simon Peyton Jones via ghc-devs]

Ryan

I've been on holiday, and there's been a lot of traffic on this 
deriving-strategy thread.

Would you like to send an email summarising the state of play. Eg
* Current specification is here: ...
* Patch is here: ...  (complete?)
* Unresolved issues?  Ready to review?

Thanks

Simon

| -Original Message-
| From: Ryan Scott [mailto:ryan.gl.sc...@gmail.com]
| Sent: 02 August 2016 23:59
| To: Simon Peyton Jones 
| Cc: Richard Eisenberg ; Andres Loeh ; GHC developers 
| Subject: Re: Request for feedback: deriving strategies syntax
| 
| Thanks for the feedback, everyone! I've typed up the developments so
| far in the DerivingStrategies Haskell wiki page [1].
| 
| Here's what seems to be the consensus:
| 
| * The syntax in which actual keywords are used to designate deriving
| strategies was the clear favorite.
| * In particular, a slight edge goes to the form in which multiple
| deriving clauses can be placed after a datatype, and each `deriving`
| clause has its own (optional) strategy keyword, as opposed to putting
| the keyword directly in front of the derived type.
| * The `builtin` keyword was poorly received. There isn't a obvious
| candidate to replace it, and several of us like the word `bespoke`, so
| it looks like `bespoke` will be the replacement. (If someone ends up
| complaining about it, we've got several other choices.)
| 
| 
| Any other questions or comments?
| 
| Ryan S.
| -
| [1]
| https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrate
| gies
| 
| On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones
|  wrote:
| > I'm not following all the details here, and I do not feel strongly
| about syntax; but I do hope that you'll update the wiki page to reflect
| the discussion.
| >
| > Thanks
| >
| > Simon
| >
| > -Original Message-
| > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ryan
| Scott
| > Sent: 18 July 2016 15:00
| > To: Richard Eisenberg 
| > Cc: Andres Loeh ; GHC developers 
| > Subject: Re: Request for feedback: deriving strategies syntax
| >
| > Andres,
| >
| >> The objects probably shouldn't be type synonyms, but they could be
| >> special datatypes or type families, perhaps.
| >
| > I considered that - we already have some special datatypes, type
| families, and type classes currently. However, neither datatypes nor
| type families are allowed to appear as the outermost type in an instance
| declaration (unless we bake in a very prominent exception to this rule),
| and if we imbued type classes with this magic, one might think that
| "deriving (GND Eq)" means we're deriving an instance for the magical GND
| class, not Eq. So those approaches don't sound satisfying to me on a
| cursory examination.
| >
| > Richard,
| >
| >> The one idea I can suggest in this space (somewhat tongue-in-cheek,
| >> but feel free to take it seriously) is `bespoke`
| >
| > It might be a tongue-in-cheek suggestion, but I _really_ like it. It
| captures the intended semantics better than any other previous
| suggestion, I think. And we're already going to be appropriating a new
| keyword with "anyclass", so why not take "bespoke" as well? :)
| >
| > Please stop me if I've slipped into madness here.
| >
| >> I thought about verbosity here, and it's not clear which one is more
| verbose. For example, I frequently define a new newtype and then wish to
| use GND to derive a whole host of instances. In this case (is it
| common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter
| than putting newtype on each class name.
| >
| > That's a good point. Another thing to consider is that I suspect in
| 90% of the time, users are only going to be reaching for -
| XDerivingStrategies in the scenario when they enable both -
| XGeneralizedNewtypeDeriving and -XDeriveAnyClass. That will happen when
| they want to derive instances for newtypes, and as you said, you
| typically derive several instances at a time when defining newtypes.
| > Therefore, it seems less noisy to factor out the deriving strategy
| names so that readers can tell at a glance which batch of instances are
| newtype-derived and which are anyclass-derived, instead of having to
| read a keyword before every single type.
| >
| > Plus, on a superficial level, I like keeping the deriving strategy
| name outside of the parentheses. I think it makes clear that these
| keywords aren't modifying the type we're deriving, only the means by
| which we're deriving it. Of course, you may feel differently than I do,
| so please speak up if you disagree!
| >
| >
| > Ryan S.
| > ___
| > ghc-devs mailing list
| > ghc-devs@haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.has
| kell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cea562a7e9e494f07c
| ede08d3af13cbc7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rKTWOkEZsKU
| dDOTnk7WL2BNx1lf36uelef4JDg0pX44%3d
___

Re: Request for feedback: deriving strategies syntax

[Ryan Scott]

Hi Simon,

> * Current specification is here: ...

It's in a Haskell wiki page: [1]. This summarizes the current proposed
syntax for -XDerivingStrategies, how GHC will choose a strategy in the
absence of an explicit strategy, and also goes over some alternative
syntaxes that have been proposed previously for the sake of archiving.

> * Patch is here: ...  (complete?)

It's on Phabricator: [2].

> * Unresolved issues?  Ready to review?

It's ready for review. It's incorporated all of the changes discussed
on this e-mail thread, including renaming the "builtin" strategy to
"bespoke", and including a link to the DerivingStrategies wiki in a
Note.

You left some inline comments on an earlier draft—I responded to some
of them with questions [3], since I wasn't clear what you were asking.

Ryan S.
-
[1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies
[2] https://phabricator.haskell.org/D2280
[3] https://phabricator.haskell.org/D2280#inline-20129

On Thu, Aug 11, 2016 at 6:36 AM, Simon Peyton Jones
 wrote:
> Ryan
>
> I've been on holiday, and there's been a lot of traffic on this 
> deriving-strategy thread.
>
> Would you like to send an email summarising the state of play. Eg
> * Current specification is here: ...
> * Patch is here: ...  (complete?)
> * Unresolved issues?  Ready to review?
>
> Thanks
>
> Simon
>
> | -Original Message-
> | From: Ryan Scott [mailto:ryan.gl.sc...@gmail.com]
> | Sent: 02 August 2016 23:59
> | To: Simon Peyton Jones 
> | Cc: Richard Eisenberg ; Andres Loeh  | loeh.de>; GHC developers 
> | Subject: Re: Request for feedback: deriving strategies syntax
> |
> | Thanks for the feedback, everyone! I've typed up the developments so
> | far in the DerivingStrategies Haskell wiki page [1].
> |
> | Here's what seems to be the consensus:
> |
> | * The syntax in which actual keywords are used to designate deriving
> | strategies was the clear favorite.
> | * In particular, a slight edge goes to the form in which multiple
> | deriving clauses can be placed after a datatype, and each `deriving`
> | clause has its own (optional) strategy keyword, as opposed to putting
> | the keyword directly in front of the derived type.
> | * The `builtin` keyword was poorly received. There isn't a obvious
> | candidate to replace it, and several of us like the word `bespoke`, so
> | it looks like `bespoke` will be the replacement. (If someone ends up
> | complaining about it, we've got several other choices.)
> |
> |
> | Any other questions or comments?
> |
> | Ryan S.
> | -
> | [1]
> | https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrate
> | gies
> |
> | On Mon, Jul 18, 2016 at 5:54 PM, Simon Peyton Jones
> |  wrote:
> | > I'm not following all the details here, and I do not feel strongly
> | about syntax; but I do hope that you'll update the wiki page to reflect
> | the discussion.
> | >
> | > Thanks
> | >
> | > Simon
> | >
> | > -Original Message-
> | > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ryan
> | Scott
> | > Sent: 18 July 2016 15:00
> | > To: Richard Eisenberg 
> | > Cc: Andres Loeh ; GHC developers  | d...@haskell.org>
> | > Subject: Re: Request for feedback: deriving strategies syntax
> | >
> | > Andres,
> | >
> | >> The objects probably shouldn't be type synonyms, but they could be
> | >> special datatypes or type families, perhaps.
> | >
> | > I considered that - we already have some special datatypes, type
> | families, and type classes currently. However, neither datatypes nor
> | type families are allowed to appear as the outermost type in an instance
> | declaration (unless we bake in a very prominent exception to this rule),
> | and if we imbued type classes with this magic, one might think that
> | "deriving (GND Eq)" means we're deriving an instance for the magical GND
> | class, not Eq. So those approaches don't sound satisfying to me on a
> | cursory examination.
> | >
> | > Richard,
> | >
> | >> The one idea I can suggest in this space (somewhat tongue-in-cheek,
> | >> but feel free to take it seriously) is `bespoke`
> | >
> | > It might be a tongue-in-cheek suggestion, but I _really_ like it. It
> | captures the intended semantics better than any other previous
> | suggestion, I think. And we're already going to be appropriating a new
> | keyword with "anyclass", so why not take "bespoke" as well? :)
> | >
> | > Please stop me if I've slipped into madness here.
> | >
> | >> I thought about verbosity here, and it's not clear which one is more
> | verbose. For example, I frequently define a new newtype and then wish to
> | use GND to derive a whole host of instances. In this case (is it
> | common?), `deriving (X, Y) deriving newtype (A,B,C,D,E,F)` is shorter
> | than putting newtype on each class name.
> | >
> | > That's a good point. Another thing to consider is that I suspect in
> | 90% of the time, users are only going to be reaching for -
> | XDerivingStrategies in the scenario when they e

Noticing how the Rust team is improving compiler errors

[Christopher Allen]

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html

I'd particularly note that their compiler errors were dramatically
better to begin with, now they're doing this. Thought the list would
be interested in this.

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

Suggesting RankNTypes for ill-formed types

[Karolina Drobnik]

Hello everyone,

I am working on my first ticket (#11669, linked below)
and I have some doubts after a little bit of hacking.

There was a hint that an error message should be
changed from the one suggesting RankNTypes to ExplicitForall.
In my opinion it would be quite confusing for the user, especially where
the type is ill-formed. A plain parse error should be shown here.

It is clear that it should be done in such a way after turning on one
of the extensions, but what about the situation where proposed
fix (suggesting RankNTypes/ExplicitForall) won't work?
We should be able to distinguish ill-formed type from the correct one,
even before the extension activation. To be honest - I don't know how to do
it.

Additionally, I am not sure if we can assume that an user wants
to use arbitrary rank (which implies ExplicitForall) or just a forall
keyword.
I am for the second one, but it is just my assumption.

And the last minor thing - a type formed in this way also rises an error
suggesting using RankNTypes (as we know that wouldn't solve the problem):

f :: a. -> Int
f = undefined

Maybe we could treat it as a typo (simple parse error) and propose
an extension activation only when forall was parsed earlier?
That could be tricky.

I'd appreciate some thoughts on this issue because I felt a bit lost
after digging around the parser.

Best regards,

Karolina
-
#11669 - https://ghc.haskell.org/trac/ghc/ticket/11669
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Suggesting RankNTypes for ill-formed types

[Oleg Grenrus]

FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,
yet my code doesn’t always has the scoped type variable used.
So even GHC could parse further and propose it to me, there isn’t anything from 
to do it :(

I don’t know if many use /just/ `ExplicitForAll`...

- Oleg

> On 11 Aug 2016, at 20:30, Karolina Drobnik  wrote:
> 
> Hello everyone,
> 
> I am working on my first ticket (#11669, linked below)
> and I have some doubts after a little bit of hacking.
> 
> There was a hint that an error message should be
> changed from the one suggesting RankNTypes to ExplicitForall.
> In my opinion it would be quite confusing for the user, especially where
> the type is ill-formed. A plain parse error should be shown here.
> 
> It is clear that it should be done in such a way after turning on one
> of the extensions, but what about the situation where proposed
> fix (suggesting RankNTypes/ExplicitForall) won't work?
> We should be able to distinguish ill-formed type from the correct one,
> even before the extension activation. To be honest - I don't know how to do 
> it.
> 
> Additionally, I am not sure if we can assume that an user wants
> to use arbitrary rank (which implies ExplicitForall) or just a forall keyword.
> I am for the second one, but it is just my assumption.
> 
> And the last minor thing - a type formed in this way also rises an error
> suggesting using RankNTypes (as we know that wouldn't solve the problem):
> 
> f :: a. -> Int
> f = undefined
> 
> Maybe we could treat it as a typo (simple parse error) and propose
> an extension activation only when forall was parsed earlier?
> That could be tricky.
> 
> I'd appreciate some thoughts on this issue because I felt a bit lost
> after digging around the parser.
> 
> Best regards,
> 
> Karolina
> -
> #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Landing Backpack in HEAD

[Edward Z. Yang]

Hello friends,

I'm hoping to land Backpack (the patch is two years in the making now!)
for GHC 8.2, even though 8.2 is intended to be a stabilization and
performance release.  In this email, I will make the case that the
Backpack patch is relatively self-contained and will not affect
non-Backpack users, and explain how you might be affected by the
patch.  The most recent patchset can be found at 
https://github.com/ezyang/ghc/tree/ghc-backpack ; look for "The Backpack patch" 
in the commit log, since I plan
on squashing these commits before committing.

OK, here is what is in the patchset that affects non-Backpack users:

- The primary, overarching change is that there is now
  a distinction between "semantic" and "identity" modules.
  This solves a problem with hsig files:  suppose
  you have A.hsig which defines data T in package p.
  The resulting A.hi is most accurately identified
  as p[A=]:A; however, the Name for T should be .T,
  not p[A=]:A.T.  The former is an identity module
  (it *identifies* interfaces), whereas the latter is a semantic
  module (it is what is used in names).  Without Backpack,
  these two identities are always the same.  There are a number
  of places in the existing codepaths where we have to
  distinguish between the two concepts (sometimes you
  want semantic, sometimes you want identity); we DEFAULT
  to the identity module but I fix a few cases where
  semantic modules were desired instead.

- UnitId is generalized to also record how a component
  is instantiated (a mapping from module names to modules.)
  Without Backpack this is blank and equivalent to the
  existing UnitId.

- Packages has been refactored to also handle Backpack `-unit-id`
  flags, since we have to do some extra work to determine
  what inherited signatures merge where.

- The patch REVERTS all of the old support we had for hsig
  files; -sig-of is no more.  spinda had mentioned that
  Liquid Haskell used this in some cases, and I'm looking
  at supporting *just* their particular use-case.

- A new driver mode --backpack, which process test.bkp files.
  This mode is used PURELY for testing, and end users
  are not supposed to use it.  These all live in their own
  modules (BkpSyn, DriverBkp) except for some modest,
  convenient extensions to the lexer and parser to parse
  multiple modules at once.

The patch also comes with rewritten typechecking support for hsig
files, and instantiating indefinite packages on the fly, but these
are all standalone pieces of functionality which are not tied
to any existing compiler infrastructure.

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Landing Backpack in HEAD

[Howard B. Golden via ghc-devs]

Hi,

I created a stub Backpack entry in the Haskell wiki using the abstract of the 
paper.

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

Re: enumFromThenTo for Doubles

[Edward Kmett]

Good catch. Adding and subtracting over and over relying on massive
cancellation over and over is a recipe for floating point disaster!

That said, so is adding small things to a large thing over and over, you'll
accumulate the rounding error from the addition of small numbers to the
large base.

An even better fix would be then to track the base and the current
accumulated total delta from the base and do a final addition at the end.
Then you only ever add like sized step sizes together before adding them to
the base. This would stage the additions such that you get another matissa
sized window of possible accumulation.

Something like:

enumFromThen n m = go (n - m) n 0 where
  go !d !b !a = db `seq` db : go d b (a + d) where
db = d + b

which probably beats Kahan in practice, Kahan-Babuška-Neumaier should be
more stable still, and there are other techniques that go further into
accuracy at the cost of significant performance.

But we don't need a general number summation algorithm. All the numbers
except the base are the same, we have a final hammer available to us: just
do multiplication of the delta by the number of steps and add it to the
base.

That should be the most numerically stable thing possible, given that we
are forced to do at least the first massive cancellation between the from
and then steps by the API we have to meet, but I don't have benchmarks to
say which technique wins in practice.

-Edward

On Tue, Aug 9, 2016 at 11:22 PM, Andrew Farmer  wrote:

> Noticed this today:
>
> ghci> let xs = [0.0,0.1 .. 86400.0] in maximum xs
> 86400.005062
>
> enumFromThenTo is implemented by numericEnumFromThenTo:
>
> https://github.com/ghc/ghc/blob/a90085bd45239fffd65c01c24752a9
> bbcef346f1/libraries/base/GHC/Real.hs#L227
>
> Which probably accumulates error in numericEnumFromThen with the (m+m-n):
>
> numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m
> (m+m-n))
>
> Why not define numericEnumFromThen as:
>
> numericEnumFromThen n m = let d = m - n in d `seq` go d n
> where go delta x = x `seq` (x : go delta (x + delta))
>
> (or with BangPatterns)
>
> numericEnumFromThen n m = go (m - n) n
> where go !delta !x = x : go delta (x + delta)
>
> Seems like we'd save a lot of subtractions by using the worker function.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs