Tue Jul 21 22:18:06 PDT 2009 simo...@microsoft.com
* Test pattern-match overlap checking for GADTs
Ignore-this: 355ff54d49f196f3b4e769ce486786f0
A ./tests/ghc-regress/deSugar/should_compile/GadtOverlap.hs
A ./tests/ghc-regress/deSugar/should_compile/GadtOverlap.stderr
M ./tests/gh
Sun Jul 19 23:01:55 PDT 2009 simo...@microsoft.com
* Test for Trac #3382
Ignore-this: b8a90bfdf4219235cf0adb51c0d36e36
A ./tests/ghc-regress/deSugar/should_run/T3382.hs
A ./tests/ghc-regress/deSugar/should_run/T3382.stdout
M ./tests/ghc-regress/deSugar/should_run/all.T +1
View pa
Tue Jul 21 22:09:33 PDT 2009 simo...@microsoft.com
* Take account of GADTs when reporting patterm-match overlap
Ignore-this: 7dcbdcb91021e83e6e6208a2e68c50c9
When matching against a GADT, some of the constructors may be impossible.
For example
data T a where
T1 :: T
Sun Jul 19 23:12:26 PDT 2009 simo...@microsoft.com
* Fix Trac #3382: desugaring of NPats
Ignore-this: 4dccdaf2b7d6428141dcf174cb455a20
Max spotted that the short-cut rules for desugaring NPats (where
we compare against a literal) were wrong now that we have overloaded
strings.
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/HEAD
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Tue Jul 21 18:00:01 BST 2009.
checking out
Build description = HEAD on x86_64-unknown-linux
(cam-04-unx.europe.corp.microsoft.com)
Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx
Nightly build started on cam-04-unx at Tue Jul 21 19:00:01 BST 2009.
**
On 21/07/2009 09:14, Simon Peyton-Jones wrote:
Yes, but a lot of the API remains somewhat accidental... so I don't want to tie
us in to full backward compat.
Whenever possible, let's retain a deprecated old type or function; but if it's
difficult or inconvenient, let's not.
Agreed.
Concern
Yes, but a lot of the API remains somewhat accidental... so I don't want to tie
us in to full backward compat.
Whenever possible, let's retain a deprecated old type or function; but if it's
difficult or inconvenient, let's not.
Concerning SrcLoc etc, we did indeed start with SrcLoc, and then
We're at the stage where the GHC API is beginning to settle down a bit,
so it might be a good idea to keep backwards compatibility where
possible. If we rename things, we can leave the old names in, but
DEPRECATED, for one release.
Cheers,
Simon
On 20/07/2009 19:51, Isaac Dupree wrot
