Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/ghc/nightly/HEAD-cam-02-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Sun Jun 17 19:30:00 BST 2007.
checki
Sun Jun 17 14:52:05 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Sort names before printing them in the debugger so output order is
consistent
M ./compiler/ghci/InteractiveUI.hs -13 +21
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskel
Sun Jun 17 14:50:40 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
* Update ghci debugger output order
M ./tests/ghc-regress/ghci.debugger/scripts/break017.stdout -1 +1
M ./tests/ghc-regress/ghci.debugger/scripts/break018.stdout -2 +2
___
Cvs-ghc ma
Hi
I guess I started this discussion by asking for a concrete thing,
rather than describing what I'm hoping to do. In reality, any solution
that accomplishes my end goal suits me perfectly - so perhaps I should
say what I'm hoping to do.
Currently Yhc has an external core format, Yhc.Core. Howev
On 6/17/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote:
On Sun, Jun 17, 2007 at 12:08:26PM -0700, Tim Chevalier wrote:
> There's nothing to stop us from just adding deriving(Show) and
> deriving(Read) to those existing data types, right? Of course, this
> requires adding instances for a number of da
On Sun, Jun 17, 2007 at 12:08:26PM -0700, Tim Chevalier wrote:
> On 6/16/07, Aaron Tomb <[EMAIL PROTECTED]> wrote:
> >We've been leaning away from having a specific data type for External
> >Core, and just using the existing data types in GHC (such as
> >IfaceExpr and CoreExpr). So it's unclear wha
On 6/16/07, Aaron Tomb <[EMAIL PROTECTED]> wrote:
We've been leaning away from having a specific data type for External
Core, and just using the existing data types in GHC (such as
IfaceExpr and CoreExpr). So it's unclear what data type we'd add
deriving(Show) to.
There's nothing to stop us fro
