The source tarball is missing a few files for hptool:
hptool/src/HaddockMaster.hs
hptool/src/OS/Win.hs
hptool/src/Releases.hs
hptool/src/Releases2012.hs
hptool/src/Releases2013.hs
hptool/src/Templates.hs
hptool/src/Website.hs
I guess these are missing from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 24/07/14 01:29, Andrew Pennebaker wrote:
Like many programming language environments, GHC offers a handy
`-e` option for evaluating an expression, then returning to the
shell.
$ ghc -e '2 + 2'
4
One would expect the interpreter,
* Johan Tibell johan.tib...@gmail.com [2014-07-23 17:48:29+0200]
Hi!
I started a draft spec for the Strict language pragma we chatted about
during our call a while ago. I made the big mistake of writing it much
after the actual discussion, so I forgot most of the details.
For the record, Cabal is now up-to-date, we're using a different
patch which relaxes the version constraint on process so that 7.6
bootstraps.
Cheers,
Edward
Excerpts from Joachim Breitner's message of 2014-07-21 08:22:32 +0100:
Hi,
Am Sonntag, den 20.07.2014, 22:57 +0100 schrieb Edward
On Thu, Jul 24, 2014 at 11:10 AM, Roman Cheplyaka r...@ro-che.info wrote:
Will case with an irrefutable pattern force the scrutinee, too?
I.e. will
case x of { pat - y }
desugar to
case x of { pat - x `seq` y }
?
Yes. The user has to write ~x if he/she doesn't want that.
Will
Austin
I know that you have been working on
* https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git
*
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules
But what about the main Repositories page
*
Devs,
I'm trying to understand how the core2core pipeline works. Sadly, we don't have
a wiki page about
this so the only source of information are the papers and the source code.
Papers give pretty
much detail about each transformation in separate but none of the papers gives
a comprehensive
On Thu, Jul 24, 2014 at 5:09 AM, George Colpitts george.colpi...@gmail.com
wrote:
Installed on the Mac, looks good, ...
did cabal install -j3 of threadscope, criterion, hlint, ghc-mod,
quickcheck, smallcheck and smartcheck
That's all a good sign...
not sure if following is significant:
On Thu, Jul 24, 2014 at 5:30 AM, Brandon Allbery allber...@gmail.com
wrote:
E. Whoever is making the Mac bindist should take care to avoid any
MacPorts (or for that matter Homebrew) components slipping in to it; this
will cause problems down the road.
That would be makin' that bindist!
Hi,
Am Donnerstag, den 24.07.2014, 14:56 +0100 schrieb Edward Z.Yang:
We were wondering if there was any reason to prefer the former
situation over the latter.
One way to decide that is to ask “What is the more stable interface”?
I.e. under what circumstances will upgrading Cabal require
On Thu, Jul 24, 2014 at 1:25 AM, Sven Panne svenpa...@gmail.com wrote:
The source tarball is missing a few files for hptool:
I'll try to catch them the next round... or pull requests on github welcome!
On Thu, Jul 24, 2014 at 4:22 AM, Sven Panne svenpa...@gmail.com wrote:
...But I'm a bit
Hi,
On 24 July 2014 16:07, Joachim Breitner m...@joachim-breitner.de wrote:
So while Duncan’s Proposal has no such dependency, in Simon’s proposal
there is one. Will ghc-db’s interface be stable enough that the Cabal
developers will be happy to build against a very old version of it?
Cabal's
The way I am thinking of it is this. In Simon's proposal in
http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf
the ghc-db library is simply a Haskell library that gives a programmatic way to
interact with GHC's installed package database(s). GHC needs that. ghc-pkg
needs that. cabal
Right now, GHC has a very complex and hard to explain algorithm for
picking packages from the package database when you give it a pile of
-package/-package-id/-{hide,ignore,trust,distrust}-package flags.
Roughly, it currently does something like this.
1. Concatenate all of the package databases
Excerpts from Edward Z. Yang's message of 2014-07-24 15:57:05 +0100:
- It assumes *-hide-all-packages* at the beginning. This scheme
probably works less well without that: now we need some consistent
view of the database to start with.
Actually, thinking about this, this dovetails nicely
The background here is our (Edward + me) beliefs that
* The current situation is complicated, and completely un-documented
* Its functionality is not used. The dominant modes of use are
- Cabal: hide-all-packages and then say exactly which ones to expose
- Users: use -package (but not
GHC's data structures are often mutually recursive. e.g.
* The TyCon for Maybe contains the DataCon for Just
* The DataCon For just contains Just's type
* Just's type contains the TyCon for Maybe
So any attempt to recursively walk over all these structures, as you would
Sorry for the double email Simon, I hadn’t signed up for ghc-devs so my
response was rejected..
---
Thanks for getting back to me so quickly!
On July 24, 2014 at 0:33:44, Simon Peyton Jones (simo...@microsoft.com) wrote:
Eric
I'd like to help but I don't understand the question. What do
Dear Simon, et al,
These are very good points to make for people writing such traversals
and queries. I would be more than happy to write a page on the pitfalls
etc. on the wiki, but in my experience so far, exploring the innards of
GHC is tremendously helped by trying small things out and
While we are talking about fixing traversals, how about getting rid of the
phase specific panic initialisers for placeHolderType, placeHolderKind and
friends?
In order to safely traverse with SYB, the following needs to be inserted
into all the SYB schemes (see
| This is what I mean by “resolving” the types. For single-module programs
| this is trivial, we can do something like
|
| resolve x = do rn - hscParseIdentifier x
| hscTcRnLookupRdrName rn
|
| For multi-module programs it becomes trickier because we also have to
| resolve
| My plan is to gather up
| the answers on a wiki page.
Excellent -- please do that! My replies are below
Simon
| This mail basically asks just one question: what is the order of
| optimizations pefromed on Core?
It's entirely defined by
SimplCore.getCoreToDo :: DynFlags - [CoreToDo]
The
How would this work with ghci? If I'm understanding correctly, the
proposal means users could no longer do:
$ ghci SomeFile.hs
and have it work without manually specifying all -package flags. Did I
miss something?
I think it would work in conjuction with the package environments stuff,
Good question. I think package environments are the right answer here:
GHCi should come preloaded with some special global package environment.
Edward
Excerpts from John Lato's message of 2014-07-25 00:52:12 +0100:
How would this work with ghci? If I'm understanding correctly, the
proposal
I think I see where the confusion is now. In your example, hscTcRnLookupRdrName
should work perfectly. I’m thinking of a different scenario, where we are
trying to use the specification of a function that has been imported from
another module. Suppose we have
module List where
data List = Nil
25 matches
Mail list logo
