Re: RFC: migrating to git

count for much, but a switch to git would be one more small thing that would discourage me from contributing in the future. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely ef

Re: Moving External Core library to Hackage

On 11/8/09, Ian Lynagh wrote: > > Hi Tim, > > > On Sun, Sep 27, 2009 at 04:15:24PM -0700, Tim Chevalier wrote: > > > > I've uploaded the External Core library (currently living under > > utils/ext-core in the GHC build tree) to Hackage, as mentione

Moving External Core library to Hackage

stant future -- perhaps just leaving a pointer to the Hackage page under utils/ext-core. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt "an intelligent person fights for lost causes,realizing that others are merely effects" -

patch applied (ghc): Under utils/ext-core, update README to mention that ext-core is now on Hackage

Sun Sep 27 16:08:45 PDT 2009 Tim Chevalier * Under utils/ext-core, update README to mention that ext-core is now on Hackage Ignore-this: 8d8d2cad45c07931f0ed1ccfed002d66 M ./utils/ext-core/README +9 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20090927230845-d61e2

patch applied (ghc): External Core: re-add code I removed mistakenly in last commit

Wed Jan 14 16:26:12 PST 2009 Tim Chevalier * External Core: re-add code I removed mistakenly in last commit M ./utils/ext-core/Language/Core/Check.hs -1 +16 M ./utils/ext-core/Language/Core/Prep.hs -2 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20090115002612-d61e2

patch applied (ghc): External Core lib: lots of cleanup

Wed Jan 14 14:44:28 PST 2009 Tim Chevalier * External Core lib: lots of cleanup - Factor out code for applying newtypes from Check into CoreUtils - Use this code in Prep, which allowed for some simplification - Change Merge and ElimDeadCode to not flatten top-level binds - Add a

patch applied (ghc): External Core: print out more precise dependency info

Wed Jan 14 14:17:34 PST 2009 Tim Chevalier * External Core: print out more precise dependency info Print out the same recursive/non-recursive binding groups that existed in internal Core in an External Core file, rather than dumping everything into one big recursive group. M

patch applied (ghc): ext-core: change .cabal file so we can build with either GHC 6.8 or 6.10

Mon Jan 5 11:27:57 PST 2009 Tim Chevalier * ext-core: change .cabal file so we can build with either GHC 6.8 or 6.10 M ./utils/ext-core/Setup.lhs -6 +10 M ./utils/ext-core/extcore.cabal -6 +15 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20090105192757-d61e2

patch applied (ghc): ext-core: fix some Prep bugs

Mon Jan 5 11:27:34 PST 2009 Tim Chevalier * ext-core: fix some Prep bugs M ./utils/ext-core/Language/Core/Prep.hs -59 +97 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20090105192734-d61e2-283afcadf2efbf1de77cebe3246c95e0009fbdb5.gz

patch applied (ghc): ext-core: use shorter names when combining modules

Mon Jan 5 11:26:45 PST 2009 Tim Chevalier * ext-core: use shorter names when combining modules M ./utils/ext-core/Language/Core/CoreUtils.hs +11 M ./utils/ext-core/Language/Core/Merge.hs -4 +12 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20090105192645-d61e2

patch applied (ghc): ext-core: twiddle primitive things

Mon Jan 5 11:24:34 PST 2009 Tim Chevalier * ext-core: twiddle primitive things M ./utils/ext-core/Language/Core/Core.hs -1 +4 M ./utils/ext-core/Language/Core/Prims.hs -1 +4 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20090105192434-d61e2

darcs vs. git?

Hello all, I haven't been paying much attention lately; is it possible yet to push patches to the GHC repo via git? I'm guessing not, but wasn't able to find a definitive answer on the wiki. If not, is there any timetable for when that will be possible? Thanks, Tim -- Tim C

Re: Building with GhcBootLibs=Yes doesn't work

something like "These libraries are necessary if you're bootstrapping GHC; otherwise, try make stage=1". Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If you don't understand the causes, it is impossible to come up with

Re: Building with GhcBootLibs=Yes doesn't work

Oops, ignore that last post. On second glance, the problem seems to be with my changes to GHC config files and not with GhcBootLibs=YES. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If you don't understand the causes, it is impossible to come

Building with GhcBootLibs=Yes doesn't work

AFAIK, and if it depends on the other libs, shouldn't GhcBootLibs=Yes make sure to build them? Or am I doing something wrong? (Do I have to make clean before doing this? I hope not.) Thanks, Tim [*] for some fairly ill-specified value of "minimal" -- Tim Chevalier * http://c

patch applied (ghc): ext-core library: Parser fixes; make it build with the HEAD

Thu Sep 18 02:03:49 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Parser fixes; make it build with the HEAD In the ext-core parser I guess I never tested: * existential type variable bindings in case alts * empty data declarations That'll learn me!

Re: Strange permissions when installing HEAD

On Sun, Sep 14, 2008 at 1:49 PM, Ian Lynagh <[EMAIL PROTECTED]> wrote: > On Sat, Sep 13, 2008 at 02:46:14PM +0100, Ian Lynagh wrote: >> On Fri, Sep 12, 2008 at 11:07:18PM -0700, Tim Chevalier wrote: >> > >> > -rwx-- 1 root root 134 2008-09-12 22:28 ghc-

patch applied (ghc): Slightly more helpful panic message in DynFlags

Mon Sep 15 01:06:50 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Slightly more helpful panic message in DynFlags M ./compiler/main/DynFlags.hs -1 +1 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080915080650-d61e2-6d2ce67e92e9f09b4f98fead9f5f2e11e989d

patch applied (ghc): Comments only: ".core" => ".hcr"

Sun Sep 14 13:36:45 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Comments only: ".core" => ".hcr" M ./compiler/main/DynFlags.hs -1 +1 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080914203645-d61e2-021ae7b8aed8a7

Strange permissions when installing HEAD

c, and installPackage!) It also seems like it didn't work this way in the past. Was this a deliberate change? (I fixed the permissions in my directory, of course, but it was confusing at first.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in dou

patch applied (ghc): ext-core library: Add dead code eliminator for Core

Thu Sep 11 21:41:47 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Add dead code eliminator for Core Added code for dead code elimination to the ext-core library. This can be used in concert with Language.Core.Merge to produce a single self-contained module w

patch applied (ghc): ext-core library: expose some more modules

Thu Sep 11 20:45:15 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: expose some more modules M ./utils/ext-core/extcore.cabal -2 +2 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080912034515-d61e2-c2b05cf6329ffacc42b450403dab1e87dec37

patch applied (ghc): ext-core library: Change syntax for primitive coercions

Thu Sep 11 20:33:47 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Change syntax for primitive coercions Changed the ext-core syntax to include primitive coercions (left, right, sym, trans, etc.) as syntax rather than referring them to their names as in GHC. (I

patch applied (ghc): ext-core library: Export a lot more things from Prims

Thu Sep 11 20:22:19 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Export a lot more things from Prims See comments for details. M ./utils/ext-core/Language/Core/Overrides.hs -2 +5 M ./utils/ext-core/Language/Core/Prims.hs -13 +78 View patch online

patch applied (ghc): ext-core library: Extend Core preprocessor

Thu Sep 11 20:14:52 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Extend Core preprocessor See comments for details. M ./utils/ext-core/Language/Core/Prep.hs -5 +70 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080912031452

patch applied (ghc): ext-core library: Export a bunch more stuff from the parser

Thu Sep 11 19:56:15 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Export a bunch more stuff from the parser M ./utils/ext-core/Language/Core/ParsecParser.hs -1 +3 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080912025615

patch applied (ghc): ext-core library: Fix performance bug

Thu Sep 11 19:53:14 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Fix performance bug isUtupleTy was implemented inefficiently (and is called a lot by the typechecker). Replaced with uglier but faster code. M ./utils/ext-core/Language/Core/Core.hs -2 +11 View

patch applied (ghc): ext-core library: Remove some cruft

Thu Sep 11 19:38:42 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Remove some cruft M ./utils/ext-core/Language/Core/Merge.hs -4 +2 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080912023842-d61e2-1d67e5e5e2e0c998f6df553c02ed9756b7d19

Re: Git problem

I've pushed in a while. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): ext-core library: Add code for merging multiple Core modules into a single module

Thu Sep 11 19:15:35 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * ext-core library: Add code for merging multiple Core modules into a single module I added a new module, Merge, to the ext-core library that combines a list of ext-core modules into a new, uniquely renamed module.

Splitting off ext-core library?

se I don't want to make sure I have a GHC tree that I can actually push patches from every time I want to check something in under utils/ext-core.) Any objections? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough:

darcs.haskell.org still has poor bandwidth

't do better than PSU, I assume something is wrong :-) I had similar problems doing a darcs pull a little bit earlier (so I decided to start over with a more recent tarball). Just letting you know in case the problem turns out to be more persistent... Cheers, Tim -- Tim Chevalier * http://

Re: External Core output path

On Tue, Sep 9, 2008 at 10:14 AM, Tim Chevalier <[EMAIL PROTECTED]> wrote: > Well, one solution, which is not simple but not as complicated as it > could be, is (just for ExtCore) to inline only names that appear in > the original source module's export list, under the ration

Re: External Core output path

ich isn't perfect either, but seems good enough for now.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

Re: External Core output path

> would give different answers. So a flag is probably the right thing. > Yes, I think that's right. I also think writing it up carefully so users know what to expect will be half the battle (if I ever get around to doing this, anyway). Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~

Re: External Core output path

On 9/8/08, Tim Chevalier <[EMAIL PROTECTED]> wrote: > > Maybe I didn't state my point clearly, or maybe it was so obvious as > to be easily missed. An External Core file should be like a Haskell > source file at least in the sense that it doesn't depend on any > s

Re: External Core output path

to recompile the rest. But I would expect libraries to behave differently. You were talking before about the possibility of only doing inlining within the same package -- or at least of having a flag that causes that behavior -- which I think would be solve the problem completely. I hope this mak

Re: patch applied (ghc): Update the users guide to point at the in-tree core.ps.gz

; describe the right version of core. > Yay thanks! Is there a reason to keep it as a ps.gz? It could just as easily be made a PDF, Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt Just enough: Obama/Biden '08. ___

Re: External Core output path

'll experiment with it at some point. But from your other comments, it sounds like you're confirming my suspicion that making GHC generate External Core files that it can read back in again entails either paying an optimization cost in terms of the generated Core files, or cross-cutting ch

External Core output path

ve; thus if you merge a source module with all the libraries it depends on, you now have a new renamed Bool type that is incompatible with the Bool type that the primops depend on. I can think of solutions for this, all of them ugly. Any thoughts? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~

Re: Updating External Core docs for 6.10

but nonetheless, I like beer, so I'll try to put something more practical together (perhaps on the wiki.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If you try to solve a hard problem, the question is not whether you will use a powerful

Re: Updating External Core docs for 6.10

and Haddock does > do, and be pointed to from the manual by a relative path. Rather than > pointing to a single stale version. > Yes, I agree. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt

Re: Updating External Core docs for 6.10

ted. I don't have access to do that myself, as far as I know. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Programming is like sex: one mistake and you have to support for a lifetime." -- anonymous

Updating External Core docs for 6.10

hanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Thus spake the Master Programmer: When you have learned to snatch the error code from the trap frame, it will be time for you to leave."--J. Geoffrey ___ Cvs-g

Re: Unboxed singleton tuples

t to bar $! (f m) ? (Or are the singleton tuples a way to avoid using seq and its friends?) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I wish people weren't so set on being themselves, when that means being a bastard." -- Robertson D

Unboxed singleton tuples

in deSugar/DsCCall.lhs. But I still don't understand -- what's the difference between (# foo #) and foo? Just curious. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Love is an exploding cigar which we willingly smoke

patch applied (ghc): Fixed performance bug in ext-core preprocessor

Fri Aug 8 17:20:51 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Fixed performance bug in ext-core preprocessor The Core preprocessor was rebuilding the type and data constructor environments every time it called the typechecker, which was horribly inefficient. Fixed. M ./uti

patch applied (ghc): Add dummy LICENSE file to make Cabal go through

Fri May 16 19:53:51 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Add dummy LICENSE file to make Cabal go through Add a LICENSE file that just points to the GHC license. A ./utils/ext-core/LICENSE View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080517025351

patch applied (ghc): don't rebuild PrimEnv if genprimopcode and/or primops.txt don't exist

Thu May 15 16:04:05 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * don't rebuild PrimEnv if genprimopcode and/or primops.txt don't exist This helps if, for example, you want to build the Core tools on a machine that doesn't have a GHC build tree, and have a pre-existi

patch applied (ghc): Cabalize ext-core tools

Wed May 14 16:53:41 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Cabalize ext-core tools I cabalized the ext-core tools, so now they can be built as a library. The driver program has to be built separately. Also updated genprimopcode to reflect the new module hierarchy f

patch applied (ghc): External Core tools: add note to README about where to find documentation

Sun May 4 17:46:03 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * External Core tools: add note to README about where to find documentation M ./utils/ext-core/README +6 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080505004603

patch applied (ghc): Some External Core doc fixes

Sun May 4 17:39:55 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Some External Core doc fixes M ./docs/ext-core/core.tex -53 +44 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080505003955-d61e2-8e3706772c68662e110f8533512bae14606a7

patch applied (ghc): External Core tools: track new syntax for newtypes

Sun May 4 17:10:50 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * External Core tools: track new syntax for newtypes Update External Core tools to reflect new syntax for newtypes. (Notice that the typechecker is 90 lines shorter!) Also: improve dependency-finding, miscell

patch applied (ghc): Improve External Core newtype syntax

Sun May 4 16:02:33 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve External Core newtype syntax I realized that recursive newtypes no longer have to be distinguished in the External Core AST, because explicit coercions allow the typechecker to typecheck newtypes withou

patch applied (ghc): Improve syntax for primitive coercions in External Core

Sat May 3 19:43:04 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve syntax for primitive coercions in External Core Add new syntax in External Core for primitive coercions (trans, sym, etc.) rather than wiring their names into the ext-core parser. M ./compiler/c

patch applied (ghc): Fix External Core interpreter

Sat May 3 16:10:44 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Fix External Core interpreter The External Core interpreter works (in a limited sense). For details, see the README. This means we now have a marginally functioning set of External Core tools. The other ex

Re: trouble getting repo up to date

I ran into the same problem trying to push a patch recently. At http://bugs.darcs.net/issue753 Eric Kow suggested that the bug might be fixed in version 2 of darcs, but I haven't tried it yet. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "

Re: Another question about subkinds in Core

nvention, "o" stands for an open ty var (grep for openAlphaTyVar in the code...) But it's all quite obscure. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "No one in the world ever gets what they want and that is beautiful / Every

External Core available in HEAD

Trac if you're sure). Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "What doesn't kill you will make you stronger / I'm not dead yet so I must be stronger" -- Nerissa Nields ___

patch applied (ghc): Improve External Core syntax for newtypes

Mon Apr 21 21:52:44 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve External Core syntax for newtypes I was confused by the newtype eta-contraction trick before. Newtype declarations are much less redundant now. M ./compiler/coreSyn/ExternalCore.lhs -4 +1 M ./co

patch applied (ghc): Update External Core docs

Mon Apr 21 21:43:42 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Update External Core docs Update documentation to reflect GHC HEAD. M ./docs/ext-core/Makefile -10 +8 A ./docs/ext-core/core.bib M ./docs/ext-core/core.tex -410 +263 View patch online: http://darcs.haske

patch applied (ghc): External Core typechecker - improve handling of coercions

Mon Apr 21 18:56:22 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * External Core typechecker - improve handling of coercions Reorganized coercion-related code in the typechecker (this was brought about by typechecking the Core versions of the optimized GHC libraries.) A few miscell

patch applied (ghc): Naming changes in External Core

Mon Apr 21 18:27:34 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Naming changes in External Core Two changes: - Top-level bindings in a given module are now printed as a single %rec group. I found that in External Core generated from optimized code, nonrec bindings weren&#

Another question about subkinds in Core

a type argument with kind *, then that would be expressed by writing its body as (Prim.touch# t), not by giving it a type signature that doesn't match the body type. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "You can't learn ev

Re: Dodgy newtype axioms

nks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Well-behaved women rarely make history." --Laurel Thatcher Ulrich ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

patch applied (ghc): Improve External Core syntax

Tue Apr 15 17:03:47 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve External Core syntax Got rid of the silly '^' characters before qualified names (plus: reverts to the original syntax; minus: makes the parser a little hairier.) Also, added warning in the

Re: Dodgy newtype axioms

On 4/14/08, Tim Chevalier <[EMAIL PROTECTED]> wrote: > But I'm not so sure that it's sound in general. What if you had a coercion > like: > :CoT (t:::*) (forall a . a -> t :=: a -> T) > where T :: *? > Then if you wrote (:CoT (u::?)), that would mean &g

Re: Dodgy newtype axioms

eral. What if you had a coercion like: :CoT (t:::*) (forall a . a -> t :=: a -> T) where T :: *? Then if you wrote (:CoT (u::?)), that would mean forall a . a -> ? :=: a -> T Do you see what I'm getting at now? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in err

patch applied (ghc): Revive External Core typechecker

Sun Apr 13 19:46:48 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Revive External Core typechecker The typechecker works again! Yay! Details upon request. M ./utils/ext-core/Check.hs -84 +304 M ./utils/ext-core/Core.hs -9 +55 M ./utils/ext-core/Driver.hs -62 +134

patch applied (ghc): Eta-expand newtype coercions in External Core

Sun Apr 13 20:16:54 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Eta-expand newtype coercions in External Core Typechecking External Core is easier if we eta-expand axioms in newtype declarations. For a fuller explanation, see: http://www.haskell.org/pipermail/cvs-ghc/2008-April/

patch applied (ghc): Extra info in genprimopcode --make-ext-core-source

Sun Apr 13 19:54:07 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Extra info in genprimopcode --make-ext-core-source The ext-core typechecker needs to know what types are valid for various kinds of literals, so I changed genprimopcode to dump out that information as well with

Re: Dodgy newtype axioms

On 4/13/08, Tim Chevalier <[EMAIL PROTECTED]> wrote: > For other reasons, I decided it was better to re-eta-expand newtype > declarations before printing out External Core, and this fixed the > problem I described below. But I'd still be curious whether you agree >

Re: Dodgy newtype axioms

ed as: eta-contracting a type fails to preserve kinds). Cheers, Tim On 4/11/08, Tim Chevalier <[EMAIL PROTECTED]> wrote: > Hi, Simon- > > I'm currently trying to generate External Core for all the GHC > libraries and typecheck them using the stand-alone ext-core > typ

Dodgy newtype axioms

ldn't be any problem if GHC didn't do the eta-contraction thing for newtypes... but I don't know how easy it would be to eta-expand again before printing out External Core. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Modesty...is both ali

patch applied (ghc): Update .darcs-boring with utils/ext-core stuff

Fri Apr 11 11:57:34 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Update .darcs-boring with utils/ext-core stuff M ./.darcs-boring +2 View patch online: http://darcs.haskell.org/ghc/_darcs/patches/20080411185734-d61e2-945e096858cc1b72e0ca02552a5bf8fdb2397

patch applied (ghc): Extend genprimopcode to print primop types for ext-core

Thu Apr 10 11:58:10 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Extend genprimopcode to print primop types for ext-core I added a new flag, --make-ext-core-source, to genprimopcode. It prints out the type information for primops that the External Core typechecker needs. This re

patch applied (ghc): Another round of External Core fixes

Wed Apr 9 21:37:27 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Another round of External Core fixes With this patch, GHC should now be printing External Core in a format that a stand-alone program can parse and typecheck. Major bug fixes: - The printer now handles qua

Name shadowing in types in Core

; instead, I'm inclined to just change the documentation to say that name shadowing is allowed in types but not in terms. Before I do that, though, I thought I would ask: Is type variable name shadowing supposed to be allowed in internal Core? Or does this reflect a bug in GHC? Cheers, Tim -- Tim Chev

patch applied (testsuite): Accept output for bug1677, mod178

Sun Apr 6 14:15:54 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Accept output for bug1677, mod178 Changed error messages as per: Sun Apr 6 12:38:21 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve error message for non-matching file name M ./tests

patch applied (testsuite): Accept output for read029

Sun Apr 6 14:13:39 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Accept output for read029 Changed error message as per: Sun Apr 6 13:23:33 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve error message for malformed LANGUAGE pragma M ./tests/ghc-re

patch applied (ghc): Improve error message for malformed LANGUAGE pragma

Sun Apr 6 13:23:33 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve error message for malformed LANGUAGE pragma I made the error (which previously said "cannot parse LANGUAGE pragma") slightly more helpful by reminding the user that pragmas should be comma-s

patch applied (ghc): Improve error message for non-matching file name

Sun Apr 6 12:38:21 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve error message for non-matching file name I changed the "File name does not match module name" error message so that it prints out both the declared module name and the expected module name (bef

patch applied (ghc): Revive External Core parser

Sat Mar 29 15:39:48 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Revive External Core parser Huzzah, the External Core parser will now parse External Core generated by the HEAD. Most notably, I rewrote the parser in Parsec, but the old Happy version remains in the repo

patch applied (ghc): Fix big character literal printing in External Core

Sat Mar 29 15:11:09 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Fix big character literal printing in External Core Characters bigger than '\xff' should be represented as int literals in External Core. (This was originally fixed five years ago and broken again four

patch applied (ghc): External Core: don't print superfluous parens in case types

Sat Mar 29 12:46:29 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * External Core: don't print superfluous parens in case types The External Core printer was parenthesizing the scrutinee type in case expressions. Since this type is required to be atomic, the parens aren't n

patch applied (ghc): External Core: print function types correctly, improve newtype pretty-printing

Fri Mar 28 15:26:30 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * External Core: print function types correctly, improve newtype pretty-printing - In a previous patch I broke the printing of fully-applied arrow types (e.g., "a -> b" was "(ghczmprim:GHCziP

patch applied (ghc): Print out rational literals correctly in External Core

Fri Mar 28 14:19:19 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Print out rational literals correctly in External Core The External Core printer was printing out rational literals of the form: 2.0e-2 when the External Core grammar doesn't allow this. (This bug has appa

patch applied (ghc): Change syntax for qualified names in External Core

Thu Mar 27 11:54:36 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Change syntax for qualified names in External Core Two changes that make the ext-core code uglier but the parser easier: - Prefix qualified names with "^" so that we can more easily distinguish

patch applied (ghc): Change syntax for newtypes in External Core

Tue Mar 25 10:02:18 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Change syntax for newtypes in External Core The way that newtype declarations were printed in External Core files was incomplete, since there was no declaration for the coercion introduced by a newtype. For e

Re: HEAD broken?

On 3/25/08, Ian Lynagh <[EMAIL PROTECTED]> wrote: > On Tue, Mar 25, 2008 at 08:56:31PM +, Ian Lynagh wrote: > > On Tue, Mar 25, 2008 at 11:02:27AM -0700, Tim Chevalier wrote: > > > > > > GHC/Word.hs:668:17: Not in scope: data constructor `S#' >

GHC hacking without tears?

nts of code often; plus, this has more or less the same problem with merging) Do other people have any thoughts/experiences related to this? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I'm a nonbeliever, but I believe in your smile." -- La

Re: HEAD broken?

t see what you're trying to suggest I should do, but I see in a subsequent email from Ian that he is pushing a patch to fix this, so I assume that once that patch is pushed and I pull it, I'll be OK. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in

Re: HEAD broken?

On 3/25/08, Don Stewart <[EMAIL PROTECTED]> wrote: > The integer package is needed to build base now. Are you saying that I need to do something other than running darcs-all get and darcs-all pull (as well as sh boot, configure, make)? If so, what? Thanks, Tim -- Tim Chevali

HEAD broken?

t in scope: data constructor `J#' GHC/Word.hs:710:38: Not in scope: data constructor `S#' GHC/Word.hs:711:80: Not in scope: data constructor `J#' The most recently nightly build report gives the same output, so I guess it's not just me. Just a heads-up... Cheers, Tim -- Tim

patch applied (ghc): Fix primMname in External Core printer

Sun Mar 23 18:43:11 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Fix primMname in External Core printer My earlier changes broke printing of function types in .hcr files. In other words: the z-encoding must die. M ./compiler/coreSyn/ExternalCore.lhs

patch applied (ghc): Fix primMname in External Core printer

Sun Mar 23 17:52:46 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Fix primMname in External Core printer My earlier changes broke printing of function types in .hcr files. In other words: the z-encoding must die. M! ./compiler/coreSyn/ExternalCore.lhs

patch applied (ghc): Handle hierarchical module names in External Core tools

Wed Mar 19 18:44:49 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Handle hierarchical module names in External Core tools I updated the parser to handle hierarchical module names (with package names) the way GHC is currently printing them out in External Core. Beware kludgy us

patch applied (ghc): Improve hierarchical module name handling in MkExternalCore

Wed Mar 19 12:04:29 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Improve hierarchical module name handling in MkExternalCore It's easier for the External Core parser if MkExternalCore prints module names like: base:GHCziBase rather than like: base:GHC.Base (w

patch applied (ghc): Fixed remaining warning in coreSyn/MkExternalCore

Wed Mar 19 11:25:21 PDT 2008 Tim Chevalier <[EMAIL PROTECTED]> * Fixed remaining warning in coreSyn/MkExternalCore There was a (suppressed) warning about an incomplete pattern match in make_alt. This was because the DEFAULT alt never has variable bindings. I thought it would be bet

Re: patch applied (ghc): First cut at reviving the External Core tools

er for many years, and I'm doing what I can to produce something useful at this point. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If you're going to do it, overdo it / that's how you know you're alive" -- Ani Di

  1   2   >