RE: base package -- goals
| In short, less of an either/or, more of a both/and.
|
| from reading between the lines I get the impression that you’d prefer
| (A) to happen first, in order to do (B) more easily. If (A) was
| successful, we even have to worry less about bad decisions while doing
| (B), as it would be relatively easy to fix these.
Yes, that's right. (A) sounds like a low-cost way of meeting some goals. (B)
is a higher-cost way of meeting some further goals.
Your follow-on remarks (appended below) about which implicit Prelude you get if
you (say) import only `base-pure` are well-taken, but they apply equally to
(B). Worth adding a section to the Wiki page to discuss this?
My gut feel: for the minority who do not want to depend on enough base-X
packages to get the Haskell-98 Prelude, use NoImplicitPrelude (since indeed you
don't depend on enough to get the H98 Prelude) and import what you want
explicitly.
Most people won't care and will continue to depend on enough to get Prelude.
Simon
| So if we do (A), we still have the problem that Ian pointed out: Why
| should anyone use these shim packages, when they can continue to use
| base?
|
| This is especially true when the shim packages are less simple to use,
| due to the handling of Prelude. I see some options (assuming, just for
| demonstration, we have to shim packages base-pure and base-io):
|
| 1. Prelude stays in base, packages wanting to use the shim packages
| exclusively have to use {-# LANGUAGE NoImplicitPrelude #-}
| everywhere and import stuff explicitly. base-pure would probably
| provide its subset of the Prelude in Prelude.Pure, to be
| imported explicitly.
| 2. Prelude goes to a separate shim package, base-prelude. Extra
| dependency required, packages that want to only depend on
| base-pure have no Prelude to use, same problem as in 1.
| 3. Every shim package has a Prelude module. Good for those who
| depend on base-pure, but those who require both base-pure and
| base-io have no an ambiguous import.
| 4. Separate packages base-io-prelude and base-pure-prelude
| providing Prelude’s containing stuff of base-* (+ dependencies).
| Packages can pull in precisely the Prelude they want, but yet
| more packages.
|
| None of these look particularly appealing. Here some ideas to make it
| more convenient for the programmer that require changes to GHC and how
| it treats packages:
|
| I. It automatically imports _all_ visible Prelude modules. So
| base-pure provides the pure Prelude and base-io adds the IO
| functions.
| II. Same, but a bit more explicit: We extend the package
| configuration by a prelude-modules field. Every module listed
| in that field of every visible package is treated as a Prelude
| and automatically imported (unless {-# LANGUAGE
| NoImplicitPreldue #-} is active.)
|III. Ambiguous module imports do not cause an error if, among the
| modules, there is one that is a superset of all others, i.e.
| reexports all other modules.
|
| I personally find I. quite elegant and appealing, as it is clearly the
| behavior expected by library authors if they have their code build-
| depend on their selection of shim packages, and requires no extra
| prelude packages. One might see it as a disadvantages that now arbitrary
| packages can add to the “virtual prelude”, although I don’t think it
| would be abused without good reason, and who knows what clever things
| people will do with that feature.
|
| Greetings,
| Joachim
|
|
| --
| Joachim nomeata Breitner
| Debian Developer
| nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
| JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
Hi, Am Mittwoch, den 13.03.2013, 14:04 + schrieb Simon Peyton-Jones: Your follow-on remarks (appended below) about which implicit Prelude you get if you (say) import only `base-pure` are well-taken, but they apply equally to (B). Worth adding a section to the Wiki page to discuss this? Sure, done, including stated opinions so far: http://hackage.haskell.org/trac/ghc/wiki/SplitBase#HandlingPrelude I also noticed an advantage of (P2) (No Prelude in any of the shim packages, but in a separate base-prelude package): It allows programmers to mix conveniently the shim packages with packages that provide a non-standard prelude (classy-prelude comes to my mind) without any use of NoImplicitPrelude. (Just stating that for completeness, my preference is still option (P4)+(I1), i.e. multiple partial Prelude modules which all automatically imported.) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package -- goals
On Wed, Mar 13, 2013 at 7:04 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Most people won't care and will continue to depend on enough to get Prelude. Let me just put this out here so keep it in the back of our heads: most people don't care about this whole thing (splitting base) so lets make sure there's still a base package to import that gives people what they have before. :) Other than that I'm quite excited about the prospects of splitting up base a bit. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Foreign.StablePtr: nullPtr double-free questions.
Excerpts from Remi Turk's message of Wed Mar 13 13:09:18 -0700 2013: Thanks for your quick reply. Could you elaborate on what a bit of overhead means? As a bit of context, I'm working on a small library for working with (im)mutable extendable tuples/records based on Storable and ForeignPtr, and I'm using StablePtr's as back-references to Haskell-land. Would you expect StablePtr's to have serious performance implications in such a scenario compared to, say, an IORef? Yes, they will. Every stable pointer that is active has to be stuffed into a giant array, and the entire array must be traversed during every GC. See also: http://hackage.haskell.org/trac/ghc/ticket/7670 Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Annotating an AST with type checking / source line number info
Hi there, I am not hugely familiar with compilers or the particulars of GHC, but am interested in creating a few programs which manipulate Haskell source code in particular ways. Two things I would like to be able to do are: - Swap every occurrence of a particular type for a different / dummy value of that type. - Find the line / column number of every place a value of a particular type is used From compiling Haskell programs, it seems clear that GHC performs type checking, and when I get a compile error it is able extract line and column information about where I had the error, so it appears as if GHC is annotating the source with this information as it compiles. I am struggling to find a lot in the way of learning materials for GHC, but from trawling through the API documentation (I am using GHC version 7.4.2), it seems like I can generate an abstract syntax tree via the method: parseModule :: GhcMonadhttp://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:GhcMonadm = ModSummaryhttp://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:ModSummary- m ParsedModulehttp://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t:ParsedModule My question is this: what combination of functions do I have to use to get not only an AST for my source, but an AST annotated with typing information and line / column number annotations for values within it? Also, as I am a bit of a newbie to this whole GHC API thing, any pointers to resources to learn more about it would be enormously appreciated. Thanks, Craig ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Annotating an AST with type checking / source line number info
Hi Craig -- you might look at: http://goto.ucsd.edu/~rjhala/llvm-haskell/doc/html/liquidtypes/Language-Haskell-Liquid-GhcInterface.html#v:getGhcInfo http://goto.ucsd.edu/~rjhala/llvm-haskell/doc/html/liquidtypes/src/Language-Haskell-Liquid-GhcInterface.html#getGhcModGuts1 for an example of how how to turn a `FilePath` into a GHC `[CoreBind]`. http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/CoreSyn.html#t:CoreBind The latter (i.e. `CoreBind` and related `Expr` and friends) are GHC's core representation of programs AFTER some amount of simplification. (This may be too late for your purposes, i.e. you may want something prior to simplification, but look at this chain mod_guts - coreModule `fmap` (desugarModule = typecheckModule = parseModule modSummary) to get a sense of the different steps... Hope this helps! Ranjit. On Mar 13, 2013, at 1:32 PM, Craig Innes wrote: Hi there, I am not hugely familiar with compilers or the particulars of GHC, but am interested in creating a few programs which manipulate Haskell source code in particular ways. Two things I would like to be able to do are: - Swap every occurrence of a particular type for a different / dummy value of that type. - Find the line / column number of every place a value of a particular type is used From compiling Haskell programs, it seems clear that GHC performs type checking, and when I get a compile error it is able extract line and column information about where I had the error, so it appears as if GHC is annotating the source with this information as it compiles. I am struggling to find a lot in the way of learning materials for GHC, but from trawling through the API documentation (I am using GHC version 7.4.2), it seems like I can generate an abstract syntax tree via the method: parseModule :: GhcMonad m = ModSummary - m ParsedModule My question is this: what combination of functions do I have to use to get not only an AST for my source, but an AST annotated with typing information and line / column number annotations for values within it? Also, as I am a bit of a newbie to this whole GHC API thing, any pointers to resources to learn more about it would be enormously appreciated. Thanks, Craig ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
