GHC Proposals session at Haskell Symposium at ICFP
Dear friends of GHC, this year’s Haskell Symposium will host a special “GHC Proposals session” where current, future and past GHC Proposals can be presented and discussed: https://icfp22.sigplan.org/home/haskellsymp-2022#GHC-Proposals-Session I invite all GHC Proposal authors (or otherwise interested party) who are in Ljubljana to present your ideas and plans; just e-mail me if you want a slot. I also invite everyone else – users, developers, educators – to join the session for the discussions of these proposals. Your chance to get your voice heard, and not just your writing on GitHub! Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Types differ, but they look the same
Hi, Am Freitag, dem 08.04.2022 um 16:58 +0200 schrieb Joachim Breitner: > what might make eqType go False that is _not_ visible in the pretty- > printed view? I have a hunch: `(%,%) a b` differs from `(,) a b`, but both are pretty-printed as (a, b)`… I’ll shout if that wasn’t it. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Types differ, but they look the same
Hi, sorry for not providing a mwe, but while I dig deeper, maybe someone has a “this is typically a problem with X” idea… This is in the context of a Core plugin (Conal’s Compiling to Categories), and I observe an oddity: I have two 'Types' that _should_ be equal, that ppr’int equal, but where eqType says False. The type looks like this: (SymRAD1 windowFunctor_a3e0Q kernelFunctor_a3e0R channelsFunctor_a3e0S numType_a3e0T, SymRAD2 paddedWindowFunctor_a3e0P windowFunctor_a3e0Q kernelFunctor_a3e0R channelsFunctor_a3e0S numType_a3e0T) what might make eqType go False that is _not_ visible in the pretty- printed view? Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Call for lightning talks and participation -- Haskell Implementors' Workshop
Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop Sunday, 23 September, 2018 https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 The Haskell Implementors Workshop is only one week away! Time to look at our great program at https://icfp18.sigplan.org/track/hiw-2018-papers#program and plan your day! Lightning Talks --- Like in the previous years, we will have slots for lightning talks. And because they were so successful last year, we will have more! *Topics* Anything related to Haskell implementations, fun uses of Haskell etc. goes. Feel free to tell us about ongoing work, to entertain, to rant, to stir a debate! (If you ever have been to a security or crypto conference, you might have attended their “rump session”. While there will not be alcohol involved at HIW, I hope that we can still match their creativity and insightful fun.) *Rules* * There are 3 sets of 3 lightning talks. * Sign-up is on day of the event, in person, on paper. No prior registration possible. * Lightning talks are 8 mins or less. If you know that your lightning talk takes less time, please say so, and maybe we can put four lightning talks into the slot. * Lightning talks do not count as peer-reviewed publications and are not published in the conference proceedings. Program Committee - * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (DFINITY / University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact --- * Joachim Breitner -- Joachim Breitner former post-doctoral researcher http://cis.upenn.edu/~joachim signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Final Call for Talks -- Haskell Implementors' Workshop
Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 Important dates --- Proposal Deadline: Friday, 20 July, 2018 Notification: Friday, 3 August, 2018 Workshop: Sunday, 23 September, 2018 Keynote speaker --- This year, the Haskell Implementors’ Workshop is proud to present Rahul Muttineni as the keynote speaker. Rahul brough the joys of Haskell to the realm of Java by creating the Eta programming language. Title: Let's Go Mainstream with Eta! Eta is a fork of GHC that focuses on three core principles: user experience, performance, and safety. We'll discuss how we used these principles to guide the re-implementation of the GHC runtime and code generator on the JVM. Moreover, will also cover the inner workings of the FFI and the typechecker support we added for subtyping to make it smooth to interact with Java libraries. Finally, we'll round out with a look at where Eta is headed and how Eta and GHC can collaborate in the future. About the Haskell Implementors’ Workshop The 10th Haskell Implementors’ Workshop is to be held alongside ICFP 2018 this year in St. Louis. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience - It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2018. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks - We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw18.hotcrp.com/ until July 20th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee - * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact --- * Joachim Breitner -- Joachim Breitner Post-Doctoral researcher http://cis.upenn.edu/~joachim signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
2nd Call for Talks -- Haskell Implementors' Workshop
Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 Important dates --- Proposal Deadline: Friday, 20 July, 2018 Notification: Friday, 3 August, 2018 Workshop: Sunday, 23 September, 2018 Keynote speaker --- This year, the Haskell Implementors’ Workshop is proud to present Rahul Muttineni as the keynote speaker. Rahul brough the joys of Haskell to the realm of Java by creating the Eta programming language. Title: Let's Go Mainstream with Eta! Eta is a fork of GHC that focuses on three core principles: user experience, performance, and safety. We'll discuss how we used these principles to guide the re-implementation of the GHC runtime and code generator on the JVM. Moreover, will also cover the inner workings of the FFI and the typechecker support we added for subtyping to make it smooth to interact with Java libraries. Finally, we'll round out with a look at where Eta is headed and how Eta and GHC can collaborate in the future. About the Haskell Implementors’ Workshop The 10th Haskell Implementors’ Workshop is to be held alongside ICFP 2018 this year in St. Louis. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience - It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2018. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks - We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw18.hotcrp.com/ until July 20th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee - * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact --- * Joachim Breitner -- Joachim Breitner Post-Doctoral researcher http://cis.upenn.edu/~joachim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Open up the issues tracker on ghc-proposals
Hi, Am Mittwoch, den 02.05.2018, 09:53 + schrieb Anthony Clayden: > Speaking as a non-developer of ghc, often there's a bright idea with no very > clear notion how best it fits into Haskell, or could be implemented > effectively/efficiently: > > * maybe it's something seen in another language; > * maybe the proposer finds themself writing the same boilerplate > repeatedly, and wonders if that's a common idiom the language could > capture; > * sometimes it starts as more of a 'how do I do this?' question; then > you get told you can't; then other people chip in with 'yes I'd like > to do that too'. > * sometimes it's more of a niggle: this really annoys me/is > awkward/is confusing every time I bump into it/even though I can work > round it. hmm, some of that sounds like it would be better suited for haskell- cafe, StackOverflow, Reddit or your personal twitter feed, at least until the idea has matured a little bit more. I am worried about the signal-to-noise ratio for those poor committee members who have not given up on following the GitHub notifications for the ghc-proposals repository. We can try, but I reserve the right to abondon the experiment if we end up with a few unproductive long discussions around some obviously whacky idea, and a larger number of vague abandoned “wouldn’t it be nice” issues. Most vague ideas get better when the proposer is nudged to sit down and write it up properly! (And some get dropped in the process, which is also good :-)). Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How to highlighting subexpressions in dumped core?
Hi, Am Mittwoch, den 07.03.2018, 12:14 + schrieb Simon Peyton Jones via Glasgow-haskell-users: > I'm not keen on adding more Tick complexity -- it's a bit out of hand > already, and all transformations must "do the right thing". > > AnnExpr adds an annotation at every node. You could, I guess use > that to annotate -- but then you'd need a pretty printer for it so > you'd end up with duplication. > > Worth looking at #8809 and related tickets these are all for CoreExpr, right? I guess I can just copy the pretty-printer code for my maybe a bit peculiar needs, it’s not too big. (Although highlights in CoreLint output would be useful for all of use.) Thanks for your input, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
How to highlighting subexpressions in dumped core?
Hi, one of my plugins dumps core output to the user, and this core output contains “interesting subexpressions”. I would like to highlight them (for example, with `bold :: SDoc -> SDoc`). As far as I can see, I have these options: * I copy all, or most of PprCore, and extend ppr_expr to look for the subexpressions that I care about. Obviously not nice, because of a code copy. * I extend GHC to support that. One way would be to add a new constructor to `data Tickish id = … | Highlight` so that I can wrap the interesting subexpressions in `Tick Highlight e`. That’s a bit better, and could even be useful in GHC (e.g. a linter error could highlight the lint error location), but it’d mean waiting for new compiler versions until I can make use of that, and it is still limited to subexpressions – highlighting a binder would require yet another support. * Could we extend SDoc with an operation highlightIn :: SDoc -> SDoc -> SDoc or highlightIn :: Doc -> Doc -> Doc where `highlightIn doc1 doc2` is like doc2, but any subdocument that is “ismorphic to doc1” (for whatever that means) gets highlighted? Are there other options that I might not see right now? Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Why is EvTerm limited?
Hi, I had some funky idea where a type checker plugin would have to synthesize code for a custom-solved instances on the fly. But it seems that does not work because EvTerm is less expressive than Core (especially, no lambdas): https://downloads.haskell.org/~ghc/8.2.2/docs/html/libraries/ghc-8.2.2/TcEvidence.html#t:EvTerm What would break if we had | EvExpr CoreExpr as an additional constructor there? Cheers, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Maybe String -> CoreExpr in a GHC plugin
Hi, Am Dienstag, den 16.01.2018, 11:08 -0500 schrieb Joachim Breitner: > in a GHC plugin, I want to synthesize simple data structures, and > insert them into the code. What is the most idiomatic way of writing a > function, say, > > foo :: Maybe String -> CoreExpr > > or > > foo :: Maybe String -> CoreM CoreExpr > > so that the resulting CoreExpr describes the input. Abstractly > speaking, I could imagine creating the Core AST by hand (but I’d have > to figure out how to resolve the names of the constructors), or somehow > invoking the renamer, type-checker and desugarer from within CoreM. I ended up writing this: dcExpr :: TH.Name -> CoreM CoreExpr dcExpr thn = do Just name <- thNameToGhcName thn dc <- lookupDataCon name pure $ Var (dataConWrapId dc) resultToExpr :: Result -> CoreM CoreExpr resultToExpr (Success s) = App <$> dcExpr 'Success <*> mkStringExpr s resultToExpr (Failure s) = App <$> dcExpr 'Failure <*> mkStringExpr s which seems to work fine. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Maybe String -> CoreExpr in a GHC plugin
Hi, in a GHC plugin, I want to synthesize simple data structures, and insert them into the code. What is the most idiomatic way of writing a function, say, foo :: Maybe String -> CoreExpr or foo :: Maybe String -> CoreM CoreExpr so that the resulting CoreExpr describes the input. Abstractly speaking, I could imagine creating the Core AST by hand (but I’d have to figure out how to resolve the names of the constructors), or somehow invoking the renamer, type-checker and desugarer from within CoreM. Surely someone else has solved this problem before. How did you do it? Thanks, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Rewrite rules involving LHS lambda?
Hi, Am Samstag, den 02.12.2017, 12:59 -0800 schrieb Conal Elliott: > Thanks for the reply, Ed. > > > I'd assume that `x` didn't occur in either `u` or `v` > > This is exactly the issue I'm wondering about. Since rewrite rules > admit lambdas and only first-order matching, I'm wondering whether > they're interpreted as you did (and I'd tend to), namely that `x` > doesn't occur freely in `u`or `v`, in which case lambdas don't seem > useful in rules (and yet were implemented for some reason) even with these restrictions, they are still useful for rules like map (\x -> x) = id > With a wee bit of higher-order matching, one might make `u` and `v` > functions and instead write: > > > foo (\ x -> fmap (u x) (v x)) = bar u v > > In that case I'd expect `u` and `v` to be synthesized rather than > literally matched. For instance, `foo (\ (a,b) -> fmap (+ a) > [b,b,b])` would match with `u = \ (a,b) -> (+ a)` and `v = \ (a,b) -> > [b,b,b]`. That would be nice and interesting, but we don’t do that now, unfortunately. And of course higher-order pattern matching is quite a can of worms. I implemented it in http://incredible.pm/ but that was a much simpler setting than a complex typed language like Core. Implementing some form of higher-order pattern matching might actually be doable, but would it be reliable? When does it become undecidable? Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Annotations with names
Hi,
I’d like to use Annotations to transport some meta-information from the
Haskell source to GHC Plugins (as they are meant to be, right?).
But I am struggling expressing annotations that relate different
symbols. Here are some hypthetical examples what I want to express:
foo :: String -> String
foo = …
bar :: [(String,String), (String, String)]
{-# ANN bar (TestCasesFor 'foo) #-}
rec :: Natural -> (a -> a) -> a -> a
{-# ANN rec (RecurserFor 'Natural) $-}
This code actually works (with TemplateHaskell). It will put a TH.Name
into the annotations, but when I am in Core, I need a core Name.
Is there a good way of transporting such references in Annotations so
that the desugarer (or the renamer) will do the necessary name changes
for me?
And slightly related: Do Annotations keep bindings alive? (It seems so,
but then it should be documented in
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#source-annotations
Thanks,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de
https://www.joachim-breitner.de/
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How does GHC's testsuite work?
Hi Sebastien, I’m looking forward to your report, surely there will be some interesting inspirations for us. Am Montag, den 30.10.2017, 11:25 -0400 schrieb Edward Z. Yang: > Actually, it's the reverse of what you said: like OCaml, GHC essentially > has ~no unit tests; it's entirely Haskell programs which we compile > (and sometimes run; a lot of tests are for the typechecker only so > we don't bother running those.) The .T file is just a way of letting > the Python driver know what tests exist. let me add that these tests rarely check the actual output of the compiler (i.e. the program, or even the simplified code). Often it is enough to check * whether the compile succeeds or fails as expected, or maybe * what messages the compiler prints. In a few cases we do dump the complete intermediate code (-ddump- simpl), but then the test case specifies a “normalization function” that checks the output for a certain property, e.g. by grepping for certain patterns. The only real unit tests that I know of are these: http://git.haskell.org/ghc.git/tree/HEAD:/testsuite/tests/callarity/unittest These are effectively programs using “GHC-the-library” Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: GHC rewrite rule type-checking failure
Hi,
I think creating your rules as built-in rules is a good way to go.
You could reduce the complexity somewhat by generating all n*m rules as
“normal” rules in the plugin when you see the instancs. This way, the
plugin does not have to do anything when you want the rule to actually
file (…and maybe the plugin does not have to be loaded at all). But I
am not sure if it is worth the effort. And the built-in rules are more
efficient, as you say.
Greetings,
Joachim
Am Dienstag, den 03.10.2017, 09:01 -0700 schrieb Conal Elliott:
> Thanks for the suggestion, Joachim.
>
> Since I'm writing a core-to-core plugin anyway, it wasn't so hard for
> me to implement all of these n*m rules (for n operations and m
> instances) at once via a "built-in" rewrite rule that explicitly
> manipulates Core expressions. Doing so is probably also considerably
> more efficient than matching against many rewrite rules (whether
> generated manually or automatically), at least the way rewrite rule
> matching is currently implemented. As you & I discussed at ICFP, I'm
> looking for ways to reduce the complexity of the plugin to make it
> easier to maintain and extend, and I thought that dictionary
> synthesis from rewrite rules might be one.
>
> Regards,
> -- Conal
>
> On Tue, Oct 3, 2017 at 8:49 AM, Joachim Breitner <m...@joachim-breitner.de>
> wrote:
> > Hi,
> >
> > Now that I think about it: You can probably even generate these rules
> > in a core2core pass that looks for instances of C, and then adds the
> > rules to the mod_guts. That would solve the problem neatly, I’d say.
> >
> > Greetings,
> > Joachim
> >
> >
> > Am Dienstag, den 03.10.2017, 08:45 -0700 schrieb Conal Elliott:
> > > Hi Joachim. Thanks very much for the suggestions and the `-ddump-
> > > rules` view. I wouldn't want to make people write `morph` rules for
> > > all combinations of operations (like `(.)`) and categories, but
> > > perhaps as you suggest those rules can be generated automatically.
> > >
> > > Regards, - Conal
> > >
> > > On Tue, Oct 3, 2017 at 7:52 AM, Joachim Breitner
> > > <m...@joachim-breitner.de> wrote:
> > > > Hi,
> > > >
> > > >
> > > > Am Montag, den 02.10.2017, 17:03 -0700 schrieb Conal Elliott:
> > > > > My questions:
> > > > >
> > > > > * Is it feasible for GHC to combine the constraints needed LHS and
> > > > > RHS to form an applicability condition?
> > > > > * Is there any way I can make the needed constraints explicit in my
> > > > > rewrite rules?
> > > > > * Are there any other work-arounds that would enable writing such
> > > > > RHS-constrained rules?
> > > >
> > > > if you are fine writing one RULE per _instance_ of C, the following
> > > > works:
> > > >
> > > >
> > > > {-# LANGUAGE ExplicitForAll, TypeApplications #-}
> > > > {-# OPTIONS_GHC -Wall #-}
> > > > module RuleFail where
> > > > class C k where comp' :: k b c -> k a b -> k a c
> > > >
> > > > instance C (->) where comp' = (.)
> > > > instance C (,) where comp' (_,a) (c,_) = (c,a)
> > > >
> > > > -- Late-inlining version to enable rewriting.
> > > > comp :: C k => k b c -> k a b -> k a c
> > > > comp = comp'
> > > > {-# INLINE [0] comp #-}
> > > >
> > > > morph :: forall k a b. (a -> b) -> k a b
> > > > morph _ = error "morph: undefined"
> > > > {-# NOINLINE morph #-}
> > > >
> > > > {-# RULES "morph/(.)/->" forall f g. morph @(->) (g `comp` f) =
> > > > morph g `comp` morph f #-}
> > > > {-# RULES "morph/(.)/(,)" forall f g. morph @(,) (g `comp` f) =
> > > > morph g `comp` morph f #-}
> > > >
> > > >
> > > > Let’s look at the rules:
> > > >
> > > > $ ghc -O -c -ddump-rules RuleFail.hs
> > > >
> > > > Tidy Core rules
> > > > "morph/(.)/(,)" [ALWAYS]
> > > > forall (@ b)
> > > >(@ b1)
> > > >(@ a)
> > > >($dC :: C (->))
> > > >(f :: a -> b)
> > > >(g :: b -> b1).
> > > >
Re: GHC rewrite rule type-checking failure
Hi,
Now that I think about it: You can probably even generate these rules
in a core2core pass that looks for instances of C, and then adds the
rules to the mod_guts. That would solve the problem neatly, I’d say.
Greetings,
Joachim
Am Dienstag, den 03.10.2017, 08:45 -0700 schrieb Conal Elliott:
> Hi Joachim. Thanks very much for the suggestions and the `-ddump-
> rules` view. I wouldn't want to make people write `morph` rules for
> all combinations of operations (like `(.)`) and categories, but
> perhaps as you suggest those rules can be generated automatically.
>
> Regards, - Conal
>
> On Tue, Oct 3, 2017 at 7:52 AM, Joachim Breitner <m...@joachim-breitner.de>
> wrote:
> > Hi,
> >
> >
> > Am Montag, den 02.10.2017, 17:03 -0700 schrieb Conal Elliott:
> > > My questions:
> > >
> > > * Is it feasible for GHC to combine the constraints needed LHS and RHS
> > > to form an applicability condition?
> > > * Is there any way I can make the needed constraints explicit in my
> > > rewrite rules?
> > > * Are there any other work-arounds that would enable writing such
> > > RHS-constrained rules?
> >
> > if you are fine writing one RULE per _instance_ of C, the following
> > works:
> >
> >
> > {-# LANGUAGE ExplicitForAll, TypeApplications #-}
> > {-# OPTIONS_GHC -Wall #-}
> > module RuleFail where
> > class C k where comp' :: k b c -> k a b -> k a c
> >
> > instance C (->) where comp' = (.)
> > instance C (,) where comp' (_,a) (c,_) = (c,a)
> >
> > -- Late-inlining version to enable rewriting.
> > comp :: C k => k b c -> k a b -> k a c
> > comp = comp'
> > {-# INLINE [0] comp #-}
> >
> > morph :: forall k a b. (a -> b) -> k a b
> > morph _ = error "morph: undefined"
> > {-# NOINLINE morph #-}
> >
> > {-# RULES "morph/(.)/->" forall f g. morph @(->) (g `comp` f) = morph
> > g `comp` morph f #-}
> > {-# RULES "morph/(.)/(,)" forall f g. morph @(,) (g `comp` f) =
> > morph g `comp` morph f #-}
> >
> >
> > Let’s look at the rules:
> >
> > $ ghc -O -c -ddump-rules RuleFail.hs
> >
> > Tidy Core rules
> > "morph/(.)/(,)" [ALWAYS]
> > forall (@ b)
> >(@ b1)
> >(@ a)
> >($dC :: C (->))
> >(f :: a -> b)
> >(g :: b -> b1).
> > morph @ (,) @ a @ b1 (comp @ (->) @ b @ b1 @ a $dC g f)
> > = comp
> > @ (,)
> > @ b
> > @ b1
> > @ a
> > $fC(,)
> > (morph @ (,) @ b @ b1 g)
> > (morph @ (,) @ a @ b f)
> > "morph/(.)/->" [ALWAYS]
> > forall (@ b)
> >(@ b1)
> >(@ a)
> >($dC :: C (->))
> >(f :: a -> b)
> >(g :: b -> b1).
> > morph @ (->) @ a @ b1 (comp @ (->) @ b @ b1 @ a $dC g f)
> > = comp
> > @ (->)
> > @ b
> > @ b1
> > @ a
> > $dC
> > (morph @ (->) @ b @ b1 g)
> > (morph @ (->) @ a @ b f)
> >
> > As you can see, by specializing the rule to a specific k, GHC can
> > include the concrete instance dictionary (here, $fC(,)) _in the rule_
> > so it does not have to appear on the LHS. This is pretty much how
> > specialization works.
> >
> > Is that a viable work-around for you? It involves boilerplate code, but
> > nothing that cannot be explained in the documentation. (Or maybe TH can
> > create such rules?)
> >
> >
> > If this idiom turns out to be useful, I wonder if there is a case for
> > -rules specified in type classes that get instantiated upon every
> > instance, e.g.
> >
> > class C k where
> > comp' :: k b c -> k a b -> k a c
> > {-# RULES "morph/(.)/(,)" forall f g. morph @k (g `comp` f) = morph
> > g `comp` morph f #-}
> >
> >
> > Greetings,
> > Joachim
> > --
> > Joachim Breitner
> > m...@joachim-breitner.de
> > http://www.joachim-breitner.de/
>
>
--
Joachim Breitner
m...@joachim-breitner.de
http://www.joachim-breitner.de/
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: GHC rewrite rule type-checking failure
Hi,
Am Montag, den 02.10.2017, 17:03 -0700 schrieb Conal Elliott:
> My questions:
>
> * Is it feasible for GHC to combine the constraints needed LHS and RHS to
> form an applicability condition?
> * Is there any way I can make the needed constraints explicit in my rewrite
> rules?
> * Are there any other work-arounds that would enable writing such
> RHS-constrained rules?
if you are fine writing one RULE per _instance_ of C, the following
works:
{-# LANGUAGE ExplicitForAll, TypeApplications #-}
{-# OPTIONS_GHC -Wall #-}
module RuleFail where
class C k where comp' :: k b c -> k a b -> k a c
instance C (->) where comp' = (.)
instance C (,) where comp' (_,a) (c,_) = (c,a)
-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}
morph :: forall k a b. (a -> b) -> k a b
morph _ = error "morph: undefined"
{-# NOINLINE morph #-}
{-# RULES "morph/(.)/->" forall f g. morph @(->) (g `comp` f) = morph g
`comp` morph f #-}
{-# RULES "morph/(.)/(,)" forall f g. morph @(,) (g `comp` f) =
morph g `comp` morph f #-}
Let’s look at the rules:
$ ghc -O -c -ddump-rules RuleFail.hs
Tidy Core rules
"morph/(.)/(,)" [ALWAYS]
forall (@ b)
(@ b1)
(@ a)
($dC :: C (->))
(f :: a -> b)
(g :: b -> b1).
morph @ (,) @ a @ b1 (comp @ (->) @ b @ b1 @ a $dC g f)
= comp
@ (,)
@ b
@ b1
@ a
$fC(,)
(morph @ (,) @ b @ b1 g)
(morph @ (,) @ a @ b f)
"morph/(.)/->" [ALWAYS]
forall (@ b)
(@ b1)
(@ a)
($dC :: C (->))
(f :: a -> b)
(g :: b -> b1).
morph @ (->) @ a @ b1 (comp @ (->) @ b @ b1 @ a $dC g f)
= comp
@ (->)
@ b
@ b1
@ a
$dC
(morph @ (->) @ b @ b1 g)
(morph @ (->) @ a @ b f)
As you can see, by specializing the rule to a specific k, GHC can
include the concrete instance dictionary (here, $fC(,)) _in the rule_
so it does not have to appear on the LHS. This is pretty much how
specialization works.
Is that a viable work-around for you? It involves boilerplate code, but
nothing that cannot be explained in the documentation. (Or maybe TH can
create such rules?)
If this idiom turns out to be useful, I wonder if there is a case for
-rules specified in type classes that get instantiated upon every
instance, e.g.
class C k where
comp' :: k b c -> k a b -> k a c
{-# RULES "morph/(.)/(,)" forall f g. morph @k (g `comp` f) = morph g
`comp` morph f #-}
Greetings,
Joachim
--
Joachim Breitner
m...@joachim-breitner.de
http://www.joachim-breitner.de/
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: GHC rewrite rule type-checking failure
Hi Conal,
The difference is that the LHS of the first rule is mentions the `C k`
constraint (probably unintentionally):
*RuleFail> :t morph comp
morph comp :: C k => k1 (k b c) (k a b -> k a c)
but the LHS of the second rule side does not:
*RuleFail> :t morph addC
morph addC :: Num b => k (b, b) b
A work-around is to add the constraint to `morph`:
morph :: D k b => (a -> b) -> k a b
morph = error "morph: undefined"
but I fear that this work-around is not acceptable to you.
Joachim
Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
> -- Demonstrate a type checking failure with rewrite rules
>
> module RuleFail where
>
> class C k where comp' :: k b c -> k a b -> k a c
>
> instance C (->) where comp' = (.)
>
> -- Late-inlining version to enable rewriting.
> comp :: C k => k b c -> k a b -> k a c
> comp = comp'
> {-# INLINE [0] comp #-}
>
> morph :: (a -> b) -> k a b
> morph = error "morph: undefined"
>
> {-# RULES "morph/(.)" morph comp = comp #-} -- Fine
> class D k a where addC' :: k (a,a) a
>
> instance Num a => D (->) a where addC' = uncurry (+)
>
> -- Late-inlining version to enable rewriting.
> addC :: D k a => k (a,a) a
> addC = addC'
> {-# INLINE [0] addC #-}
>
> {-# RULES "morph/addC" morph addC = addC #-} -- Fail
>
> -- • Could not deduce (D k b) arising from a use of ‘addC’
> -- from the context: D (->) b
>
> -- Why does GHC infer the (C k) constraint for the first rule but not (D k b)
> -- for the second rule?
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
--
Joachim Breitner
m...@joachim-breitner.de
http://www.joachim-breitner.de/
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: How to get a heap visualization
Hi, author of ghc-heap-view here. Am Mittwoch, den 30.08.2017, 18:34 +0300 schrieb Yitzchak Gale: > Getting ghc-vis to compile looks hopeless, for a number of reasons. > The dependencies on gtk and cairo are huge. Is that really a problem? > It hasn't been updated > on Hackage for a year and a half. It requires base < 4.9. GitHub is already ahead. I guess this just needs to be uploaded? https://github.com/def-/ghc-vis/blob/master/ghc-vis.cabal > I need to run > the visualizer either on a headless Ubuntu 16.04 server, or locally on > Windows. Ok, that is more tricky. > The heap scraper backend for ghc-vis, ghc-heap-view, looks usable, > and better supported than vacuum. But is there a quick and simple > visualizer for its output, without ghc-vis? Well, the :printHeap command that comes with it does “visualize” things as something resembling Haskell syntax: let x1 = "A Value" x16 = True : False : x16 in (x1,x1,x16) I don’t know of anything more graphical besides ghc-vis, but you could roll your own, if you want to; you can use ghc-heap-view to get a graph using http://hackage.haskell.org/package/ghc-heap-view-0.5.9/docs/GHC-HeapView.html#v:buildHeapGraph and then visualize that as you like. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Folding over short static lists
Hi, a common pattern is x `elem` [a,b,c] or x `elem` "/!#" instead of x == a || x == b || x == c or x == '/' || x == '!' || x == '#'. This used to be also what hlint suggested, although that hint was removed https://github.com/ndmitchell/hlint/issues/31. Upon closer inspection it seems that the compiler is not optimizing the former to the latter (more efficient, as allocation-free) form, which mildly surprised me. I guess the problem is described in this note in GHC/Base.hs: -- The foldr/cons rule looks nice, but it can give disastrously -- bloated code when commpiling -- array (a,b) [(1,2), (2,2), (3,2), ...very long list... ] -- i.e. when there are very very long literal lists -- So I've disabled it for now. We could have special cases -- for short lists, I suppose. -- "foldr/cons" forall k z x xs. foldr k z (x:xs) = k x (foldr k z xs) Now I am quite demanding of my compiler, and in particular I expect it to make a more informed choice here. Is there a good way of making an informed choice here? Up to what length of the list is it a good idea to do this? And can we implement it? Maybe simply with a few static rules for list lengths up to a certain, short length? (Maybe I should try that on a branch and see what perf.haskell.org has to say about it.) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Accessing the "original" names via GHC API
Hi Ranjit, Am Dienstag, den 24.01.2017, 16:09 -0800 schrieb Ranjit Jhala: > My goal is to write a function > > tyconString :: TyCon -> String > > (perhaps with extra parameters) such that given the > `TyCon` corresponding to `Set`, I get back the "original" > name `S.Set`, or even `Data.Set.Set`. > > Everything I've tried, which is fiddling with different variants of > `PprStyle`, end up giving me `Data.Set.Base.Set` > > Does anyone have a suggestion for how to proceed? in a way, `Data.Set.Base.Set` is the “original”, proper name for Set, everything else is just a local view on the name. So, are you maybe looking for a way to get the “most natural way” to print a name in a certain module context? This functionality must exist somewhere, as ghci is printing out errors this way. But it certainly would require an additional argument to tyconString, to specify in which module to print the name. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Rewrite rules
Hi, Am Freitag, den 13.01.2017, 20:27 +1100 schrieb Erik de Castro Lopo: > Michael Snoyman wrote: > > > Could be I'm misunderstanding, but are you looking for -ddump-rule- > > firings? > > Wasn't aware of that, but my question was a little more general. > > If I write a library that includes rewrite rules, how can I ensure > that they fire in client code that someone else writes? What > guarantees (however loose) are there? very little. The best one can do right now is to know enough about Core and the inliner to predict when things are going to be inlined and when not, what else can go wrong (wrappers maybe?), add the necessary controls (`NOINLINE [0]` etc.), and then hope for the best. And track down any instances of failed rewriting that you learn about. You might also be able to set up your code so that it fails (at runtime, with error) if the desired rules did not fire. This would be nicer if we had https://ghc.haskell.org/trac/ghc/ticket/9180. You can also ask for review if it is public code. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Narrower (per-method) GND
Hi, just responding to this one aspect: Am Sonntag, den 08.01.2017, 21:16 -0500 schrieb David Feuer: > but using defaults for > the others would give poor implementations. To cover this case, I > think it would be nice to add per-method GND-deriving syntax. This > could look something like > > instance C T where > deriving f > g = Assuming newtype T = MkT S You can achieve this using instance C T where f = coerce (f @F) g = (which is precisely what GND does), so I don’t think any new syntax is needed here. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
Hi, Am Montag, den 11.07.2016, 08:31 +0200 schrieb Sven Panne: > Because at first glance, this is visually only a tiny fraction away > from > > (if c then f else g) it d them a elsa b > > which would be parsed in a totally different way. (Personally, I > think that if/then/else is useless in Haskell and just a concession > for readers from other programming languages. Having a plain old "if" > function would have done the job in a more consistent way.) Of course > syntax highlighting improves readability here, but code should be > easily digestible in black and white, too. Visual clues matter... I believe we can and should expect programmers to know the keywords (there are not many of them) and should _not_ compromise other goals for “makes similar sense even if a keyword is mistake or mistyped as a symbol name”. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
Hi, Am Freitag, den 08.07.2016, 13:09 +0200 schrieb Sven Panne: > I don't think so: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo#Bl > ockasaLHS explicit states that > > do f &&& g > x > > parses as > > (f &&& g) x Correct > , so > > foobar > do f &&& g > x > > parses as > > foobar ((f &&& g) x) Where is the outer set of parenthesis coming from? This is all not related to the ArgumentDo notation. Note that (f &&& g) x parses as (f &&& g) x and still foobar (f &&& g) x parses as foobar (f &&& g) x just as foobar (f &&& g) x does. (NB: I consider foobar arg1 arg2 bad style and prefer foobar arg1 arg2 but the former is allowed now and will be allowed later as well.) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
Hi, Am Freitag, den 08.07.2016, 11:32 +0200 schrieb Sven Panne: > 2016-07-08 9:09 GMT+02:00 Joachim Breitner <m...@joachim-breitner.de>: > > Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne: > > > foobar > > > do f &&& g > > > x > > [...] Only with the proposed addition, it becomes an argument to foobar. > > [...] > > Huh? Nope! The Wiki page explicitly says that > > do f &&& g > x > > means > > (f &&& g) x > > Why should this be different here? Simply writing "foobar" above that > construct won't trigger any special layout rules, I hope... I believe this follows from the existing layout rules. Currenlty, foobar (do f &&& g) x calls foobar with two arguments, while (do f &&& g) x calls (f &&& g) with one argument. The ArgumentDo proposal does not change that, only that the parenthesis become redundant. Greetings, Joachim -- -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
Hi, Am Freitag, den 08.07.2016, 08:35 +0200 schrieb Sven Panne: > foobar > do f &&& g > x > > Should the x now be an argument of foobar (as it is currently) or the > "do"? If it is not an argument of the "do", suddenly things get very > context-dependent. Computers are good at handling context-dependent > things, humans are quite bad at it. What do you mean by “as it is currently”. Currently, this is a syntax error! (“parse error on input ‘do’”). Only with the proposed addition, it becomes an argument to foobar. And it is not hard to reason about this: "x" is lined up with the "do", so it is a sibling, not a child, in the AST. Hence, both are arguments to foobar. This is another good instance of how the (by me) beloved feature of “parenthesless arguments”, which so far is only available for the last argument of a function (using the “$” idiom), would now be possible for every argument of a function. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
Hi,
Am Donnerstag, den 07.07.2016, 13:15 -0400 schrieb Carter Schonwald:
> agreed -1,
> ambiguity is bad for humans, not just parsers.
>
> perhaps most damningly,
> > f do{ x } do { y }
>
> is just reallly really weird/confusing to me,
It is weird to me, but in no way confusing under the simple new rules,
and I am actually looking forward to using that, and also to reading
code with that.
In fact, everything I wanted to pass two arguments in do-notation to a
function I felt at a loss. The prospect of itemizing multiple large
arguments to a function by writing
someFunctionWithManyArguments
do firstArgument
do second Argument which may span
several lines
do third Argument
is actually making me happy! It feels like going from XML to YAML...
Greetings,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • https://www.joachim-breitner.de/
XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
Debian Developer: nome...@debian.org
signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Allow extra commas in module declarations or lists?
Hi, Am Samstag, den 11.06.2016, 12:12 -0700 schrieb Michael Burge: > What do you think? For the module header, this is already possible. For the term language, it unfortunately clashes with things like TupleSections. I believe this has been discussed a few times in the past, e.g. https://mail.haskell.org/pipermail/haskell-prime/2013-May/003833.html Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Reconsidering -Wall and -Wcompat
[Deliberately restricting my reply to one mailing list. Cross-posting is usually not required.] Hi, Am Sonntag, den 14.02.2016, 19:51 +0100 schrieb Sven Panne: > As stated on the Wiki, stuff in -Wcompat will often be non- > actionable, you omitted the important “if backwards compatibility is desired;”. The sometimes complicated hoops that you will have to jump through to gain 3-release-backward-compatibility are not something I expect every developer to follow, and for most others, “adjust early to API changes” will more likely be the sensible thing to do. Those might want to leave -Wcompat in their builds. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
Hi, Am Mittwoch, den 09.12.2015, 06:51 -0700 schrieb Jeremy: > "fix" is hyperlinked to itself, and it doesn't say what the fix is > for. that is intended. fix is inherent self-referential, and furthermore polymorphic. Greetings, Joachim PS: SCNR -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: type error formatting
Hi, Am Samstag, den 24.10.2015, 13:14 -0700 schrieb Evan Laforge: > WRT the "bound at" bits in "relevant bindings", I have no strong > opinion. What about omitting them if they are in the same file as > the main error? Or maybe they always are? I'm not totally clear how > it chooses which bindings are relevant. take one step at a time, and fix the issue you are having within #11014. Once that is through and merged, then (or in parallel to) trying to trim down the bound-at messages can be attempted. Am Samstag, den 24.10.2015, 22:30 +0200 schrieb MigMit: > At the very least, "bound at" should help IDEs (Emacs in particular) > show exactly the right places. an IDE that offers such a deep integration will hopefully not parse data meant for human consumption. We have had this discussion before (in the context of avoiding or merging multiple instances of the same error message, such as “foo not in scope”), and I continue to argue that the error messages printed by default should be tailored for the human reader. IDEs should ideally make use of something based on the GHC API. If that is not possible, then I’d advocate a flag, say "-fverbose-error- messages" or similar that includes all detail that might be relevant for an IDE, and maybe even in a nicer-to-parse format. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: type error formatting
Hi, Am Sonntag, den 25.10.2015, 21:30 +0100 schrieb MigMit: > Doesn't seem worth it to me. Current format is quite parseable, and > not really bad for human eyes either. I know that you meant this as a litote, but let me ignore that I know that for a moment to reply, that “not really bad” is definitely not good enough for me, and I want the compiler to print messages that are meant for my consumption to be in the _best_ possible format. Or at least try that. Obviously, there is no “best” for every human. But things get easier if we do not have to overly worry about computers as well. It goes the other way as well. IDEs would tremendously benefit if the error location would not just be a position but a whole span. But clearly (I hope) we do not want to include this information in the output that we read. BTW, does Emacs really parse _this_ bit of information? Most GHC integrations that I have seen match on the first line to indicate the file and position of the overall error, and take the error verbatim. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: type error formatting
Hi, Am Samstag, den 24.10.2015, 10:08 +0100 schrieb Malcolm Wallace: > On 24 Oct 2015, at 09:17, Joachim Breitner wrote: > > > For example in > > > > > Relevant bindings include > > > syllables :: [(a1, Syllable)] > > > (bound at Derive/Call/India/Pakhawaj.hs:141:16) > > > best_match :: [(a1, Syllable)] > > > -> Maybe (Int, ([(a1, Syllable)], [(a1, > > > Sequence Bol)])) > > > (bound at Derive/Call/India/Pakhawaj.hs:141:5) > > > > Also, unless the programmer is doing weird things with shadowing, > > is > > the "bound at" information really valuable? I’d say no: Usually, > > the > > programmer knows his bindings, and even if not, she will not have > > any > > problems finding the right binding. > > As someone who spends a lot of time maintaining code that I did not > write, I have to say that it is not enough that the "programmer knows > his bindings". She might, but I do not. This kind of helpful > signposting of exactly what file + linenumber + character position to > look at, is really useful for someone who is not familiar with the > code. sure, there is a trade off. But the file can by default to be assumed to be the file of the error. And are you really going to note the line number and go to that line, instead of just issuing /syllables? When error messages reach the vertical size of a terminal window, the benefit of adding such details diminishes. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: type error formatting
Hi, thanks for starting this discussion, and I agree with your suggestion. Maybe we can brainstorm some more fine refinements. Given that our error message are on the rather verbose side, maybe there is detail that can be omitted. For example in > Relevant bindings include > syllables :: [(a1, Syllable)] > (bound at Derive/Call/India/Pakhawaj.hs:141:16) > best_match :: [(a1, Syllable)] > -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) > (bound at Derive/Call/India/Pakhawaj.hs:141:5) do we really need to know what file these come from? I guess, in all but very obscure cases (or really all) they are from the same file. So why not omit the filename? Also, unless the programmer is doing weird things with shadowing, is the "bound at" information really valuable? I’d say no: Usually, the programmer knows his bindings, and even if not, she will not have any problems finding the right binding. So I suggest to drop the "bound at" line unless the binding is from a different file. > This would make this section much easier to parse and grasp visually. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Increased memory usage with GHC 7.10.1
Hi, Am Dienstag, den 14.04.2015, 21:54 +0200 schrieb Michal Terepeta: On Mon, Apr 13, 2015 at 10:34 PM, Christiaan Baaij christiaan.ba...@gmail.com wrote: Actually, I meant only with -fno-specialise. Done. Helps quite a bit but CallArity is still a pretty expensive. I’m on that, and I think I have a quite neat fix for it. I’ll report on that in the trac ticket: https://ghc.haskell.org/trac/ghc/ticket/10293#comment:4 Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Discovery of source dependencies without --make
Dear Lars,
Am Dienstag, den 25.11.2014, 10:36 +0100 schrieb Lars Hupel:
The invocation is similar to this:
ghc -c -outputdir $OUT -XTrustworthy Library.hs
ghc -c -outputdir $OUT -i$OUT -XSafe $SUBMISSION
ghc -c -outputdir $OUT -i$OUT Test_Suite.hs
ghc-outputdir $OUT -i$OUT -o $OUT/runner
the only reason you do these in individual steps is that you need to
pass different flags, or are there other reasons?
Have you tried putting the pragma {-# LANGUAGE Safe #-} as the first
line into the submission file? I’m not sure how safe that actually is,
but at least
{-# LANGUAGE Safe #-}
{-# LANGUAGE Trustworthy #-}
module Foo where
import Unsafe.Coerce
is rejected by 7.6.3. This way, it could work with a single invocation
of --make.
Greetings,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
Debian Developer: nome...@debian.org
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: Hiding import behaviour
Hi, Am Samstag, den 18.10.2014, 11:02 -0700 schrieb htebalaka: I guess my central point is I don't see how anyone can benefit from the current behaviour. For instance, a simple real world example: import Prelude import Data.Text.Lazy.IO (putStrLn) I find this quite convincing. If I bother to explicitly write out „take putStrLn from Data.Text.Lazy.IO“, why should the compiler assume that I might have meant some putStrLn from somewhere else. Of course, order should not matter (I don’t think anyone suggested it should, I think Austin simply mis-read that). Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org 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
ghc, tls, gmp
Hi, in Debian, we have the (well-known) problem of linking against libraries using libgmp, in this case haskell-curl, which links against libcurl, which links against gnutls, which uses libgmp since the latest release: https://lists.debian.org/debian-haskell/2014/07/msg0.html Are there any viable solutions to this problem that I might not be aware of? Are there any solutions to be expected in the near future? (My best idea so far is to use libcurl linked against openssl, but this causes licensing issues.) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F 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
Asserting that list fusing kicked in
Hi, for those of you who don’t follow Planet Haskell and haven’t seen my blog post¹ on it: I have created a (very) small library list-fusion-probe with an identity function fuseThis :: [a] - [a] that will complain loudly (at run-time, for the time being) if the argument is not fused away. Using it might give you more confidence in that your code really fuses as well as you think it does. Greetings from TFP (where the invited talk by Geoffrey Mainland inspired me to write that), Joachim ¹ http://www.joachim-breitner.de/blog/archives/649-Does-list-fusion-work.html -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org 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: Buildbots
Hi, Am Dienstag, den 01.04.2014, 10:25 + schrieb Simon Peyton Jones: Joachim Breitner has set up Travis-CI. (I don't know exactly what that is, but it sounds useful.) Travis is a free cloud service that runs arbitrary tests (in our case, a stripped version of validate) upon pushes to git repositories on github. I set it up to validate our master, so we get a nice history of successes and failures on https://travis-ci.org/nomeata/ghc-complete/builds and I get mails when things fail; that is when I send hopefully polite enough mails to ghc-dev, asking people to fix their commits. (Unless I broke it myself; then I silently fix it and hide.) It is a makeshift solution until we get our own infrastructure working. An early question would be: to continue to use a DIY system (Builder), or to move to some other better-supported (but perhaps less malleable) system. I don't even know what the options are. Sigh, test infrastructure are like content management systems: There are plenty out there to choose from, all can do lots of things one does not need, but none can do all, so one starts writing something selfmade, which eventually evolves in yet another of these beasts, just with fewer users. I’d recommend a move to existing, proven tools. Unfortunately, I cannot give advice as to what tool to move to. But if all these¹ projects are happy with buildbot, it might not be the worst choice. ¹ http://trac.buildbot.net/wiki/SuccessStories Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: PROPOSAL: Literate haskell and module file names
Hi, Am Sonntag, den 16.03.2014, 13:56 +0100 schrieb Merijn Verstraaten: Cons: GHC would have to either maintain a possibly long of variants to look for ([.hs, .lhs, .rst.lhs, .md.lhs, .svg.lhs, .docx.lhs]), or look for Foo.*.lhs. I’d find the latter acceptable, but it should be noted. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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
RC2 build failure on Debian: armhf
Hi, armhf still fails like in RC1: https://buildd.debian.org/status/fetch.php?pkg=ghcarch=armhfver=7.8.20140228-1stamp=1394723755 [..] 0% ( 0 / 5) in 'WwLib' 0% ( 0 / 2) in 'DmdAnal' 0% ( 0 / 2) in 'WorkWrap' compiler/typecheck/TcSplice.lhs-boot:29:1: TcSplice.tcTopSpliceExpr is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:37:1: TcSplice.runMetaE is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:38:1: TcSplice.runMetaP is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:39:1: TcSplice.runMetaT is exported by the hs-boot file, but not exported by the module compiler/typecheck/TcSplice.lhs-boot:40:1: TcSplice.runMetaD is exported by the hs-boot file, but not exported by the module 67% ( 2 / 3) in 'CmmPipeline' 0% ( 0 / 3) in 'StgCmmHpc' 0% ( 0 / 13) in 'PrelInfo' 0% ( 0 / 4) in 'StgCmmCon' 0% ( 0 / 2) in 'StgCmmExpr' 0% ( 0 / 6) in 'StgCmmBind' 0% ( 0 / 2) in 'CmmParse' 0% ( 0 / 2) in 'StgCmm' 5% ( 9 /175) in 'TcRnMonad' make[2]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 Any ideas? Anyone feeling responsible? Thanks, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: RC2 build failures on Debian: sparc
Hi, I only found https://ghc.haskell.org/trac/ghc/ticket/4872, so I created a new one at https://ghc.haskell.org/trac/ghc/ticket/8877 Thanks for having a look. Greetings, Joachim Am Mittwoch, den 12.03.2014, 08:36 + schrieb Simon Marlow: These look suspicious: /tmp/ghc29241_0/ghc29241_2.hc: In function 'stg_ap_pppv_ret': /tmp/ghc29241_0/ghc29241_2.hc:2868:30: warning: function called through a non-compatible type [enabled by default] /tmp/ghc29241_0/ghc29241_2.hc:2868:30: note: if this code is reached, the program will abort If this is a general problem with unregisterised via-C compilation then we can probably fix it. Could you open a ticket (or point me to the existing ticket if there is one)? Cheers, Simon On 05/03/2014 21:54, Joachim Breitner wrote: Hi, sparc fails differently than in RC1, and very plainly with a segmentation fault in dll-split (which happens to be the first program to be run that is compiled with stage1): https://buildd.debian.org/status/fetch.php?pkg=ghcarch=sparcver=7.8.20140228-1stamp=1393975264 Any ideas? Anyone feeling responsible? It would be shame to loose a lot of architectures in 7.8 compared to 7.6, but I’m not a porter and don’t know much about these part of the compiler, so I have to rely on your support in fixing these problems, preferably before 7.8.1. Greetings, Joachim ___ 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 -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de 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
RC2 build failure on Debian: armel
Hi, armel still fails like in RC1: https://buildd.debian.org/status/fetch.php?pkg=ghcarch=armelver=7.8.20140228-1stamp=1394495564 inplace/bin/ghc-stage2 -o utils/haddock/dist/build/tmp/haddock ... /«PKGBUILDDIR»/compiler/stage2/build/libHSghc-7.8.0.20140228.a(genSym.o): In function `genSym': genSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock' genSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock' Any ideas? Anyone feeling responsible? Thanks, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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
RC2 build failures on Debian: sparc
Hi, sparc fails differently than in RC1, and very plainly with a segmentation fault in dll-split (which happens to be the first program to be run that is compiled with stage1): https://buildd.debian.org/status/fetch.php?pkg=ghcarch=sparcver=7.8.20140228-1stamp=1393975264 Any ideas? Anyone feeling responsible? It would be shame to loose a lot of architectures in 7.8 compared to 7.6, but I’m not a porter and don’t know much about these part of the compiler, so I have to rely on your support in fixing these problems, preferably before 7.8.1. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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
RC2 build failures on Debian: mips
Hi, building RC2 right now, and the failures have changed. Reporting as the come in: Am Donnerstag, den 06.02.2014, 13:36 + schrieb Joachim Breitner: mips (https://buildd.debian.org/status/fetch.php?pkg=ghcarch=mipsver=7.8.20140130-1stamp=1391631539) mipsel (https://buildd.debian.org/status/fetch.php?pkg=ghcarch=mipselver=7.8.20140130-1stamp=1391660280) In file included from rts/sm/Evac.c:21:0: rts/sm/GCTDecl.h:139:2: error: #error Cannot find a way to declare the thread-local gc variable! #error Cannot find a way to declare the thread-local gc variable! ^ make[2]: *** [rts/dist/build/.depend-v-p-dyn-l-debug-thr-thr_debug-thr_l-thr_p-debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn-thr_debug_p.c_asm] Error 1 make[2]: *** Waiting for unfinished jobs echo compiler_stage2_depfile_haskell_EXISTS = YES compiler/stage2/build/.depend-v-p-dyn.haskell.tmp for dir in compiler/stage2/build/./ compiler/stage2/build/CodeGen/ compiler/stage2/build/CodeGen/Platform/ compiler/stage2/build/Hoopl/ compiler/stage2/build/Llvm/ compiler/stage2/build/LlvmCodeGen/ compiler/stage2/build/PPC/ compiler/stage2/build/RegAlloc/ compiler/stage2/build/RegAlloc/Graph/ compiler/stage2/build/RegAlloc/Linear/ compiler/stage2/build/RegAlloc/Linear/PPC/ compiler/stage2/build/RegAlloc/Linear/SPARC/ compiler/stage2/build/RegAlloc/Linear/X86/ compiler/stage2/build/RegAlloc/Linear/X86_64/ compiler/stage2/build/SPARC/ compiler/stage2/build/SPARC/CodeGen/ compiler/stage2/build/Vectorise/ compiler/stage2/build/Vectorise/Builtins/ compiler/stage2/build/Vectorise/Generic/ compiler/stage2/build/Vectorise/Monad/ compiler/stage2/build/Vectorise/Type/ compiler/stage2/build/Vectorise/Utils/ compiler/stage2/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' compiler/stage2/build/.depend-v-p-dyn.haskell.tmp compiler/stage2/build/.depend-v-p-dyn.haskell.tmp2 sed '/hs$/ p ; /hs$/ s/o /hi /g ; /hs$/ s/:/ : %hi: %o / ; /hs$/ s/^/$(eval $(call hi-rule,/ ; /hs$/ s/$/))/ ; /hs-boot$/ p ; /hs-boot$/ s/o-boot /hi-boot /g ; /hs-boot$/ s/:/ : %hi-boot: %o-boot /; /hs-boot$/ s/^/$(eval $(call hi-rule,/ ; /hs-boot$/ s/$/))/' compiler/stage2/build/.depend-v-p-dyn.haskell.tmp2 compiler/stage2/build/.depend-v-p-dyn.haskell make[1]: *** [all] Error 2 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Is now: https://buildd.debian.org/status/fetch.php?pkg=ghcarch=mipselver=7.8.20140228-1stamp=1393940600 rm -f rts/dist/build/libHSrts.a echo rts/dist/build/Adjustor.o rts/dist/build/Arena.o rts/dist/build/Capability.o rts/dist/build/CheckUnload.o rts/dist/build/ClosureFlags.o rts/dist/build/Disassembler.o rts/dist/build/FileLock.o rts/dist/build/Globals.o rts/dist/build/Hash.o rts/dist/build/Hpc.o rts/dist/build/HsFFI.o rts/dist/build/Inlines.o rts/dist/build/Interpreter.o rts/dist/build/LdvProfile.o rts/dist/build/Linker.o rts/dist/build/Messages.o rts/dist/build/OldARMAtomic.o rts/dist/build/Papi.o rts/dist/build/Printer.o rts/dist/build/ProfHeap.o rts/dist/build/Profiling.o rts/dist/build/Proftimer.o rts/dist/build/RaiseAsync.o rts/dist/build/RetainerProfile.o rts/dist/build/RetainerSet.o rts/dist/build/RtsAPI.o rts/dist/build/RtsDllMain.o rts/dist/build/RtsFlags.o rts/dist/build/RtsMain.o rts/dist/build/RtsMessages.o rts/dist/build/RtsStartup.o rts/dist/build/RtsUtils.o rts/dist/build/STM.o rts/dist/build/Schedule.o rts/dist/build/Sparks.o rts/dist/build/Stable.o rts/dist/build/Stats.o rts/dist/build/StgCRun.o rts/dist/build/StgPrimFloat.o rts/dist/build/Task.o rts/dist/build/ThreadLabels.o rts/dist/build/ThreadPaused.o rts/dist/build/Threads.o rts/dist/build/Ticky.o rts/dist/build/Timer.o rts/dist/build/Trace.o rts/dist/build/WSDeque.o rts/dist/build/Weak.o rts/dist/build/hooks/FlagDefaults.o rts/dist/build/hooks/MallocFail.o rts/dist/build/hooks/OnExit.o rts/dist/build/hooks/OutOfHeap.o rts/dist/build/hooks/StackOverflow.o rts/dist/build/sm/BlockAlloc.o rts/dist/build/sm/Compact.o rts/dist/build/sm/Evac.o rts/dist/build/sm/GC.o rts/dist/build/sm/GCAux.o rts/dist/build/sm/GCUtils.o rts/dist/build/sm/MBlock.o rts/dist/build/sm/MarkWeak.o rts/dist/build/sm/Sanity.o rts/dist/build/sm/Scav.o rts/dist/build/sm/Storage.o rts/dist/build/sm/Sweep.o rts/dist/build/eventlog/EventLog.o rts/dist/build/posix/GetEnv.o rts/dist/build/posix/GetTime.o rts/dist/build/posix/Itimer.o rts/dist/build/posix/OSMem.o rts/dist/build/posix/OSThreads.o rts/dist/build/posix/Select.o rts/dist/build/posix/Signals.o rts/dist/build/posix/TTY.o rts/dist/build/Apply.o rts/dist/build/Exception.o rts/dist/build/HeapStackCheck.o rts/dist/build/PrimOps.o rts/dist/build/StgMiscClosures.o rts
Re: ghc-7.8.1 and stm
Hi, Am Mittwoch, den 19.02.2014, 11:13 +0100 schrieb Herbert Valerio Riedel: On 2014-02-18 at 23:22:13 +0100, Joachim Breitner wrote: Am Dienstag, den 18.02.2014, 14:12 -0800 schrieb David Fox: It seems to me that the stm library that is supposed to be built into ghc-7.8.1 is missing. The deb provides and conflicts with libghc-stm-dev , but does not provide libghc-stm-dev-2.4.2.1-abcde. this seems to be the result of a possible inadvertent change in the GHC source tarball creation: stm had been a extra lib already in 7.6 and before, but was not part of the tarball. Herbert or Austin, is the sdist code not doing the right thing here? Afaics, 'stm' is only used as an extra lib by testsuite (and only for one test-case) and nofib; therefore I don't think the GHC source tarball is supposed to contain 'stm'... precisely. So someone needs to remove it. Created https://ghc.haskell.org/trac/ghc/ticket/8801 so that it is not forgotten. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de 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: ghc-7.8.1 and stm
Hi David, Am Dienstag, den 18.02.2014, 14:12 -0800 schrieb David Fox: It seems to me that the stm library that is supposed to be built into ghc-7.8.1 is missing. The deb provides and conflicts with libghc-stm-dev , but does not provide libghc-stm-dev-2.4.2.1-abcde. this seems to be the result of a possible inadvertent change in the GHC source tarball creation: stm had been a extra lib already in 7.6 and before, but was not part of the tarball. Herbert or Austin, is the sdist code not doing the right thing here? 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: 7.8.1, template haskell, and dynamic libraries
Hi, Am Sonntag, den 09.02.2014, 14:37 -0600 schrieb Austin Seipp: There is one caveat, if I remember correctly: if a package uses TemplateHaskell, it must declare it as such in the Cabal file. This is because Cabal does not parse the source to detect if TemplateHaskell is needed in the dependency graph of the compiled modules. Only GHC can do this reliably. If you don't specify TemplateHaskell as an extension, Cabal might not do the right thing. This is noted in the release notes: Note that Cabal will correctly handle -dynamic-too for you automatically, especially when -XTemplateHaskell is needed - but you *must* tell Cabal you are using the TemplateHaskell extension. we need -dynamic-too also for everything that a user ever might want to load in GHCi, right? So doesn’t that already imply that Cabal should and will build libHS*so files always anyways? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: RC1 build failures on Debian
Hi, Am Freitag, den 07.02.2014, 09:36 +0100 schrieb Karel Gardas: IMHO this should already be fixed in HEAD with patch by Peter Trommler: 298a25bdfd02bb591fde2dd0590bd7af81a91b94 which fixes #8722: https://ghc.haskell.org/trac/ghc/ticket/8722 thanks for spotting. I’ll wait for RC2 and report back. By now, also sparc has tried building GHC, and it also fails: https://buildd.debian.org/status/fetch.php?pkg=ghcarch=sparcver=7.8.20140130-1stamp=1391733028 /tmp/ghc18306_0/ghc18306_2.hc:928:1: error: 'MainCapability' undeclared (first use in this function) /tmp/ghc18306_0/ghc18306_2.hc: In function 'ghczm7zi8zi20140130_ExtsCompat46_geCharzh_entry': /tmp/ghc18306_0/ghc18306_2.hc:948:1: error: 'MainCapability' undeclared (first use in this function) /tmp/ghc18306_0/ghc18306_2.hc: In function 'ghczm7zi8zi20140130_ExtsCompat46_gtCharzh_entry': /tmp/ghc18306_0/ghc18306_2.hc:968:1: error: 'MainCapability' undeclared (first use in this function) make[2]: *** [compiler/stage2/build/ExtsCompat46.o] Error 1 Any ideas? Things have quite deteriorated on non-mainstream-architectures. Maybe I should, for the next release cycle, do a maybe weekly upload of GHC head to Debian experimental, so that these problems are found closer to their cause. Or hope for the builders network resurrection. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de 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
RC1 build failures on Debian
Hi, with RC1 in experimental, the Debian auto-builders have now picked up building 7.8, and it is failing on armel, hurd-i386, mips and mipsel: armel (https://buildd.debian.org/status/fetch.php?pkg=ghcarch=armelver=7.8.20140130-1stamp=1391666879) inplace/bin/ghc-stage2 -o utils/haddock/dist/build/tmp/haddock -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -optc-mlong-calls -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen-optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.4.0 -package deepseq-1.3.0.2 -package directory-1.2.0.2 -package filepath-1.3.0.2 -package ghc-7.8.20140130 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build utils/haddock/dist/build/Main.o utils/haddock/dist/build/Documentation/Haddock.o utils/haddock/dist/build/Data/Attoparsec.o utils/haddock/dist/build/Data/Attoparsec/ByteString.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.o utils/haddock/dist/build/Data/Attoparsec/Combinator.o utils/haddock/dist/build/Data/Attoparsec/Number.o utils/haddock/dist/build/Data/Attoparsec/ByteString/FastSet.o utils/haddock/dist/build/Data/Attoparsec/ByteString/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal.o utils/haddock/dist/build/Data/Attoparsec/Internal/Types.o utils/haddock/dist/build/Haddock.o utils/haddock/dist/build/Haddock/Interface.o utils/haddock/dist/build/Haddock/Interface/Rename.o utils/haddock/dist/build/Haddock/Interface/Create.o utils/haddock/dist/build/Haddock/Interface/AttachInstances.o utils/haddock/dist/build/Haddock/Interface/LexParseRn.o utils/haddock/dist/build/Haddock/Interface/ParseModuleHeader.o utils/haddock/dist/build/Haddock/Parser.o utils/haddock/dist/build/Haddock/Parser/Util.o utils/haddock/dist/build/Haddock/Utf8.o utils/haddock/dist/build/Haddock/Utils.o utils/haddock/dist/build/Haddock/Backends/Xhtml.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Decl.o utils/haddock/dist/build/Haddock/Backends/Xhtml/DocMarkup.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Layout.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Names.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Themes.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Types.o utils/haddock/dist/build/Haddock/Backends/Xhtml/Utils.o utils/haddock/dist/build/Haddock/Backends/LaTeX.o utils/haddock/dist/build/Haddock/Backends/HaddockDB.o utils/haddock/dist/build/Haddock/Backends/Hoogle.o utils/haddock/dist/build/Haddock/ModuleTree.o utils/haddock/dist/build/Haddock/Types.o utils/haddock/dist/build/Haddock/Doc.o utils/haddock/dist/build/Haddock/Version.o utils/haddock/dist/build/Haddock/InterfaceFile.o utils/haddock/dist/build/Haddock/Options.o utils/haddock/dist/build/Haddock/GhcUtils.o utils/haddock/dist/build/Haddock/Convert.o utils/haddock/dist/build/Paths_haddock.o /«PKGBUILDDIR»/compiler/stage2/build/libHSghc-7.8.20140130.a(genSym.o): In function `genSym': genSym.c:(.text+0x84): undefined reference to `arm_atomic_spin_lock' genSym.c:(.text+0x88): undefined reference to `arm_atomic_spin_unlock' collect2: error: ld returned 1 exit status make[2]: *** [utils/haddock/dist/build/tmp/haddock] Error 1 make[1]: *** [all] Error 2 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [build-stamp] Error 2 hurd (https://buildd.debian.org/status/fetch.php?pkg=ghcarch=hurd-i386ver=7.8.20140130-1stamp=1391625204) inplace/bin/ghc-stage1 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DDYNAMIC -optc-DRtsWay=\rts_dyn\ -fPIC -dynamic -H32m -O -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2-c rts/hooks/StackOverflow.c -o rts/dist/build/hooks/StackOverflow.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.8.20140130 for i386-unknown-gnu): howToAccessLabel: PIC not defined for this
Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
Hi, Am Mittwoch, den 05.02.2014, 15:53 +0100 schrieb Karel Gardas: Tried, on my ubuntu 12.04.02, but it fails miserably. Modern GHC requires alex 3.1 and cabal alex fails with (due to QuickCheck template haskell dependency): $ cabal install alex have you tried --disable-tests? Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nome...@joachim-breitner.de 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: test build of current ghc-7.8
Hi, Am Dienstag, den 04.02.2014, 09:52 +0900 schrieb Jens Petersen: Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen: Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21 devel, which I think should also install to Fedora 20. I’m surprised that it worked for you. Did not you not hit http://ghc.haskell.org/trac/ghc/ticket/8725? Does that also affect 7.8? I see the report is for a 7.9 snapshot. yes, 7.9 and 7.8 are not so different yet. But I think I’ll resolve this by making the Debian directory structure a bit more standard; much easier than hacking the build system. I’ll make sure it works and then close the bug. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: test build of current ghc-7.8
Hi,
Am Dienstag, den 04.02.2014, 09:03 + schrieb Joachim Breitner:
Am Dienstag, den 04.02.2014, 09:52 +0900 schrieb Jens Petersen:
Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen:
Hi, I did a test build [1] of the current ghc-7.8 branch for
Fedora 21
devel, which I think should also install to Fedora 20.
I’m surprised that it worked for you. Did not you not hit
http://ghc.haskell.org/trac/ghc/ticket/8725?
Does that also affect 7.8? I see the report is for a 7.9 snapshot.
yes, 7.9 and 7.8 are not so different yet. But I think I’ll resolve this
by making the Debian directory structure a bit more standard; much
easier than hacking the build system.
different issue: It seems that hpc is build dynamically, but installed
to the binpath (/usr/bin) instead of ghclibdir (/usr/lib/ghc/bin), so
the linking against the haskell library via rpath does not work. I had
to apply
$ cat patches/hpc-wrapper
Index: ghc-7.9.20140130/utils/hpc/ghc.mk
===
--- ghc-7.9.20140130.orig/utils/hpc/ghc.mk 2014-01-31 17:28:32.0
+
+++ ghc-7.9.20140130/utils/hpc/ghc.mk 2014-02-04 23:15:53.0 +
@@ -15,4 +15,7 @@
utils/hpc_dist-install_INSTALL = YES
utils/hpc_dist-install_INSTALL_INPLACE = YES
utils/hpc_dist-install_PROGNAME= hpc
+utils/hpc_dist-install_SHELL_WRAPPER = YES
+utils/hpc_dist-install_INSTALL_SHELL_WRAPPER_NAME = hpc
+
$(eval $(call build-prog,utils/hpc,dist-install,1))
Index: ghc-7.9.20140130/utils/hpc/hpc.wrapper
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ ghc-7.9.20140130/utils/hpc/hpc.wrapper 2014-02-04 23:17:49.0
+
@@ -0,0 +1,2 @@
+#!/bin/sh
+exec $executablename ${1+$@}
Jens, how does that work in the Fedora package?
Greetings,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C
Debian Developer: nome...@debian.org
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: test build of current ghc-7.8
Dear Jens, Am Montag, den 03.02.2014, 19:49 +0900 schrieb Jens Petersen: Hi, I did a test build [1] of the current ghc-7.8 branch for Fedora 21 devel, which I think should also install to Fedora 20. I’m surprised that it worked for you. Did not you not hit http://ghc.haskell.org/trac/ghc/ticket/8725? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Enabling TypeHoles by default
Hi, heh, I wanted to throw in the same argument: If its just more elaborate error messages, why do we need a flag for it? So count that as +1 from me. Greetings, Joachim Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp: I'm actually more in favor of Richard's proposal of just removing the flag to be honest, now that he mentioned it. And it's not like it's much more code. In any case, as Duncan informed me we'll have a Cabal release anyway, so I'll work on sorting this out and enabling it. On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts dun...@well-typed.com wrote: On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote: I can make another cabal release if needed, if someone submits a pull request with the right fix (i.e. add TypedHoles with TypeHoles as a synonym.) Thanks Johan, or I'm happy to do it. Duncan On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp aus...@well-typed.com wrote: At the very least, Type(d)Holes would never appear explicitly since it would be enabled by default. But it might be turned off (but I don't know who would do that for the most part.) Cabal at least might still need an update. In any case, Herbert basically summed it up: the time window is kind of close, and we would need to re-release/redeploy a few things most likely. I really think it mostly depends on the Cabal team and what their priorities are. I've CC'd Duncan and Johan for their opinions. On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel h...@gnu.org wrote: Hi, On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote: On 14.01.2014 17:07, Austin Seipp wrote: We probably won't change the name right now however. It's already been put into Cabal (as a recognized extension,) so the name has propagated a slight bit. We can however give it a new name and deprecate the old -XTypeHoles in the future. Or, we could change it, but I'm afraid it's probably a bit too late in the cycle for other devs to change. Removing a name later on is more time-consuming, with or without deprecation. People get used to the wrong name and stop caring, but I can already picture the type holes are really typed holes discussions on IRC. I'm strongly in favour of introducing the new name (and the deprecation for the synonym) as early as possible. This change should not be very extensive anyway, so why not slip it in? Well, as Austin hinted at, this would also require a Cabal-1.18.x release in time for the final 7.8, and a recompile of Hackage to pick it up so that people can start using the new 'TypedHoles' token in their .cabal files... so there's a bit of coordination required to make this happen in a timely manner... Or put differently, somebody has to care enough to invest some time and pull this through :-) Cheers, hvr -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: default roles
Hi, Am Mittwoch, den 09.10.2013, 23:18 -0400 schrieb Richard Eisenberg: On Oct 9, 2013, at 6:24 PM, Joachim Breitner m...@joachim-breitner.de wrote: So the conclusion is indeed: Let type class constraints have a nominal role, and all is fine. But, then it would seem that any class with a superclass wouldn't be compatible with GND. Do you see that detail as a consequence of this design? I think this approach might work, but I'm not yet convinced. given that we coerce the fields individually already, and are not going to change that, I don’t think there is a problem with superclasses. Even more so: The instance datatype of the subclass will have a field that contains the instance _datatype_ of the superclass, not a field with a type class constraint (because as soon as we talk about dictionaries, we are in Core, where the instance _type functions_ have already been resolved), which would be representational. It probably is confusing that (IIRC) the same TyCon is used for both uses of classes: At the Haskell level, as a function on types; at the core level, as a regular datatype. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: default roles
Hi, Am Mittwoch, den 09.10.2013, 15:21 -0400 schrieb Richard Eisenberg: Wait! I have an idea! The way I've been describing GND all along has been an abbreviation. GHC does not coerce a dictionary from, say, Ord Int to Ord Age. Instead, GHC mints a fresh dictionary for Ord Age where all the methods are implemented as coerced versions of the methods for Ord Int. (I'm not sure why it's implemented this way, which is why I've elided this detail in just about every conversation on the topic.) With this in mind, I have a proposal: 1) All parameters of all classes have nominal role. 2) Classes also store one extra bit per parameter, saying whether all uses of that parameter are representational. Essentially, this bit says whether that parameter is suitable for GND. (Currently, we could just store for the last parameter, but we can imagine extensions to the GND mechanism for other parameters.) Because GND is implemented using coercions on each piece instead of wholesale, the nominal roles on classes won't get in the way of proper use of GND. An experiment (see below for details) also confirms that even superclasses work well with this idea -- the superclasses aren't coerced. what do you need the extra bit for? During GHD, can’t you just create the new dictionary (using method = coerce original_method) and then see if it typechecks, i.e. if the method types can be coerced. (If not, the error messages might need massaging, though.) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: default roles
Hi, not sure if this is not old news to you all, but I think that for this discussion, it helps to consider these two aspects of a class instance separately: (1) An instance is a record of functions (2) An instance is a function of sorts¹ from types to (1) and clearly, type parameters of (1) can be representational, but the function in (2) should have its parameters nominal. Therefore it is fine to coerce the dictionary of a function (and would we want to implement GND this ways, that would be fine), but not a type involving a constraint. Inside GHC, as far as I can tell, (2) exists in the form of the instance metadata, and disappears after desugaring, while (1) is the actual dictionary that exists in core as a regular data type. So the conclusion is indeed: Let type class constraints have a nominal role, and all is fine. Greetings, Joachim ¹ well, a kind of function. But not that type of kind, but the other type. Sort of, at least. -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Liberalising IncoherentInstances
Good morning, Am Samstag, den 27.07.2013, 20:16 + schrieb Simon Peyton-Jones: So the change I propose to make IncoherentInstances to pick arbitrarily among instances that match. More precisely, when trying to find an instance matching a target constraint (C tys), a) Find all instances matching (C tys); these are the candidates b) Eliminate any candidate X for which another candidate Y is strictly more specific (ie Y is a substitution instance of X), if either X or Y was complied with -XOverlappingInstances c) Check that any non-candidate instances that *unify* with (C tys) were compiled with -XIncoherentInstances d) If only one candidate remains, pick it. Otherwise if all remaining candidates were compiled with -XInccoherentInstances, pick an arbitrary candidate All of this is precisely as now, except for the Otherwise part of (d). One could imagine different flags for the test in (c) and (d) but I really don't think it's worth it. I believe it would be more consistent to change the otherwise part of (d) to “Otherwise, if all but at most one remaining candidates were compiled with -XInccoherentInstances, pick the one that does not have the flag, or any other”. The rationale is that it goes much better with (c): Consider a typical example for (c): class C a b where foo :: (a,b) instance C [a] b instance [incoherent] [Int] b instance [incoherent] C a Int now foo :: ([a],b]) works (only one instance matches, the others unify, but are incoherent. So I can write (foo :: ([a],b])) :: ([Int], Int]). But I cannot write foo :: ([Int], Int]) as now all three instances from above match. The second is ruled out in step (b), but the third is not, so we are in case (d) and by the original logic, things fail here. If we allow one non-incoherent instance (and, for consistency with (b), pick that), it would work. I’ll prepare the patch in that variant, but of course I’ll change it if it turns out I am wrong here. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Liberalising IncoherentInstances
Hi, Am Montag, den 19.08.2013, 08:27 + schrieb Simon Peyton-Jones: Yes that makes sense to me. Please do document the reasoning of this thread (and the example you give) in a Note [Incoherent instances] somewhere though! done, patches ready for review and merge at https://github.com/nomeata/ghc/compare/liberalisingIncoherent and https://github.com/nomeata/ghc-testsuite/compare/liberalisingIncoherent (should I post patches only in trac, or only here on the list, or both?) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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
Marking type constructor arguments as nominal (e.g. Set)
Hi, now that roles are in HEAD, I could play around a bit with it. They were introduced to solve the unsoundness of newtype deriving, but there is also the problem of abstraction: If I define a set type based on an ord instance, e.g. data Set a = Set a -- RHS here just for demonstration the I don’t want my users to replace a Set Int by a Set (Down Int), even though the latter is a newtype of the former. This can be prevented by forcing the role of a to be Nominal (and not Representational, as it is by default). What I just noticed is that one does not even have to introduce new syntax for it, one can just use: type family NominalArg x type instance (NominalArg x) = x data Set' a = Set' (NominalArg a) and get different roles; here the excerpt from --show-iface (is there an easier way to see role annotations): 5b7b2f7c3883ef0d9fc7934ac56c4805 data Set a@R [..] 8e15d783d58c18b8205191ed3fd87e27 data Set' a@N The type family does not get into the way, e.g. conv (Set a) = Set' a works as usual. (I now also notice that the parser actually supports role annotations... but still a nice, backward-compatible trick here). Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Marking type constructor arguments as nominal (e.g. Set)
Hi, not sure – where would injectivity be needed? Greetings, Joachim Am Sonntag, den 18.08.2013, 15:00 -0500 schrieb Nicolas Frisby: Is the non-injectivity not an issue here because the type family application gets immediately simplified? On Sun, Aug 18, 2013 at 12:45 PM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, now that roles are in HEAD, I could play around a bit with it. They were introduced to solve the unsoundness of newtype deriving, but there is also the problem of abstraction: If I define a set type based on an ord instance, e.g. data Set a = Set a -- RHS here just for demonstration the I don’t want my users to replace a Set Int by a Set (Down Int), even though the latter is a newtype of the former. This can be prevented by forcing the role of a to be Nominal (and not Representational, as it is by default). What I just noticed is that one does not even have to introduce new syntax for it, one can just use: type family NominalArg x type instance (NominalArg x) = x data Set' a = Set' (NominalArg a) and get different roles; here the excerpt from --show-iface (is there an easier way to see role annotations): 5b7b2f7c3883ef0d9fc7934ac56c4805 data Set a@R [..] 8e15d783d58c18b8205191ed3fd87e27 data Set' a@N The type family does not get into the way, e.g. conv (Set a) = Set' a works as usual. (I now also notice that the parser actually supports role annotations... but still a nice, backward-compatible trick here). Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org ___ 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 -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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
Private classes
Hi, for some reason I was under the impression that if I don’t export the methods of a class, then no user of my module can create instances. But I was wrong and in fact they can; the methods will just all be bound to error Is there really no way to create a class so that no-one else can create any instances? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Private classes
Hi, Am Samstag, den 17.08.2013, 20:34 +0200 schrieb Bas van Dijk: I used the following in the past: module M (PublicClass(..)) where class HiddenClass a class HiddenClass a = PublicClass a where ... ... Now users of M can't declare instances of PublicClass because they don't have its superclass HiddenClass in scope. nice idea! Unfortunately not quite what I need; I still want the user to be able to use standalone deriving instances for the class. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Liberalising IncoherentInstances
Hi, Am Montag, den 29.07.2013, 16:19 +0100 schrieb John Lato: +1 to the original proposal and Edward's suggestion of emitting a warning. I've occasionally wanted this behavior from IncoherentInstances as well. +1 for the proposal, -1 for the warning: It is a feature, not a bug, at least there where I need it (newtype casting), and then having warnings would be confusing. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Exposing newtype coercions to Haskell
Hi, small update: I generalized the code at https://github.com/nomeata/nt-coerce/blob/9349dd3/GHC/NT/Plugin.hs a bit, it is now able to handle to create NT-values for unwarpping arbitrary newtypes and for lifting across type constructors. It does so unconditionally, i.e. does _not_ yet check whether the constructors are in scope and whether the user is allowed to cast the types occurring in the data constructors. So what works is this: NT values for newtypes without or with type arguments, and possibly recursive: newtype Age = Age Int deriving Show ageNT :: NT Age Int ageNT = deriveThisNT -- temporary syntax for deriving listNT ... newtype MyList a = MyList [a] deriving Show myListNT :: NT (MyList a) [a] myListNT = deriveThisNT newtype R a = R [R a] deriving Show rNT :: NT (R a) [R a] rNT = deriveThisNT NT values for type constructors, replacinge all or some of the type parameters: listNT :: NT a b - NT [a] [b] listNT = deriveThisNT myListNT' :: NT a b - NT (MyList a) (MyList b) myListNT' = deriveThisNT data F a b c = F a b c deriving Show fNT :: NT a a' - NT (F a b c) (F a' b c) fNT = deriveThisNT What does not work is creating a NT value between a newtype and its representation if type arguments change on the way, e.g. bar :: NT (MyList Age) [Int] but the user can construct that himself: bar = myListNT' ageNT `trans` myListNT The next step would be to add the safeguards about the visibility of constructors and about the types of data constructor parameters. Especially the latter is still not clear to me: For example with data Foo a = Foo (Bar a) is it really sufficient to check whether a barNT:: NT a b - NT (Bar a) (Bar b) exists? After all, I would not need barNT in the generated implementation of fooNT, so the user could “provide” this value via undefined and nobody would notice. I get the feeling that already the typing rule for TyConAppCo should expect coercions between the actual types in the data constructors rather than just between the type constructor parameters, so that the implementation barNT would actually have to use fooNT. Maybe that would simplify the two-equalities-approach. But that is just an uneducated gut feeling. BTW: Is this still on-topic on glasgow-haskell-users or should I move to ghc-dev? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Exposing newtype coercions to Haskell
Hi, Am Dienstag, den 02.07.2013, 16:28 + schrieb Simon Peyton-Jones: | I also noticed a problem with my logic for creating the NT-lifting | function. Suppose | data C a = MkC (Foo a) | Just having the constructors of C in scope is not sufficient | to safely provide | NT a b - NT (C a) (C b) | as the parameters of the constructor might wrap a in another type | constructor, eg | data Foo a = Foo (Set a) | | then we certainly don’t want the user to be able to write | deriving fooNT :: NT a b - NT (Foo a) (Foo b) Dually, suppose Foo was an *abstract* type, where we can't see the constructors of Foo. But the programmer as exported fooNT :: NT a b - NT (Foo a) (Foo b). Then we *do* want to be able to derive cNT :: NT a b - NT (C a) (C b) Instead maybe we say deriving cNT :: NT a b - NT (C a) (C b) using( fooNT ) listing the imported witnesses that we use. Or maybe we say simply deriving cNT :: NT a b - NT (C a) (C b) and magically use any NT-typed things that are in scope. Is this really the compiler’s job here? After all, the programmer would be able to write deriving cNT' :: NT (Foo a) (Foo b) - NT (C a) (C b) cNT :: NT a b - NT (C a) (C b) cNT = cNT' . fooNT and expose just cNT to his users, so no expressiveness is lost by not providing automatic support here. This clearly deserves treatment on the wiki page. Added. The criterion could you write it by hand? remains a good one. Agreed. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Exposing newtype coercions to Haskell
Hi, Am Dienstag, den 02.07.2013, 12:56 -0500 schrieb Nicolas Frisby: For my light experimentation, I have recovered these two values from the ModGuts that all plugins receive. Hopefully someone will shout out if there's pitfalls to avoid. * The mg_rdr_env field is of type GlobalRdrEnv. strange, why did I miss that? But I can’t get it to work, even looking up an element that I took from the GRE itself returns []: let e' = head (head (occEnvElts env)) putMsgS $ showSDoc dflags (ppr e') putMsgS $ showSDoc dflags (ppr (lookupGRE_RdrName (nameRdrName (gre_name e')) env)) prints: GHC.NT.Type.NT imported from `GHC.NT.Type' at GHC/NT.hs:5:1-18 (and originally defined at GHC/NT/Type.hs:6:6-7) [] Also, trying to construct a RdrName that I can look up fails: let rdrName = mkRdrQual (mkModuleName GHC.NT.Type) (mkTcOcc NT) putMsgS $ showSDoc dflags (ppr (lookupGRE_RdrName rdrName env)) prints also just []. What am I doing wrong? Thanks, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Exposing newtype coercions to Haskell
Hi again, Am Mittwoch, den 03.07.2013, 10:01 +0200 schrieb Joachim Breitner: Am Dienstag, den 02.07.2013, 16:28 + schrieb Simon Peyton-Jones: | I also noticed a problem with my logic for creating the NT-lifting | function. Suppose | data C a = MkC (Foo a) | Just having the constructors of C in scope is not sufficient | to safely provide | NT a b - NT (C a) (C b) | as the parameters of the constructor might wrap a in another type | constructor, eg | data Foo a = Foo (Set a) | | then we certainly don’t want the user to be able to write | deriving fooNT :: NT a b - NT (Foo a) (Foo b) Dually, suppose Foo was an *abstract* type, where we can't see the constructors of Foo. But the programmer as exported fooNT :: NT a b - NT (Foo a) (Foo b). Then we *do* want to be able to derive cNT :: NT a b - NT (C a) (C b) Instead maybe we say deriving cNT :: NT a b - NT (C a) (C b) using( fooNT ) listing the imported witnesses that we use. Or maybe we say simply deriving cNT :: NT a b - NT (C a) (C b) and magically use any NT-typed things that are in scope. Is this really the compiler’s job here? After all, the programmer would be able to write deriving cNT' :: NT (Foo a) (Foo b) - NT (C a) (C b) cNT :: NT a b - NT (C a) (C b) cNT = cNT' . fooNT and expose just cNT to his users, so no expressiveness is lost by not providing automatic support here. Hmm, I notice that this is not fully thought through. A problem is that on the one hand, the operations we have on newtypes (which allow us to lift coercions between the _type_ constructor parameters) suggest that we want cNT :: NT a b - NT (C a) (C b) while the “do it by hand” intuition suggests that cNT :: NT (Foo a) (Foo b) - NT (C a) (C b) should be provided. But I only now notice that this function will not be easily implemented. I guess in this case it could be using NthCo to get a ~ b from Foo a ~ Foo b, but this is probably shaky. This tension between the type constructor oriented coercions and data constructor oriented policy needs a bit more thought. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: Exposing newtype coercions to Haskell
Hi, Am Dienstag, den 02.07.2013, 14:11 + schrieb Simon Peyton-Jones: I'm not sure that a plugin is the way to go here, though it's a good start. as I said, it is just to host the prototype that allows for quick experimentation and allows people to test it without having to compile GHC. · I’m not sure how you expect to deal with essential NT arguments: newtype T a = MkT a a tNT :: NT a b - NT (T a) (T b) tNT n = createNT ??? I planned to use tNT = error magic message to GHC.NT.Plugin that is then replaced by GHC.NT.Plugin (and if for some reason it is missed by it it stays type safe) To your questions: · To do these kind of things, CoreM will need more reader stuff. In particular: o The global TypeEnv o The GlobalRdrEnv Ok, I guess this means that I’ll need to leave the easy land of Plugin experimentation very soon... I also noticed a problem with my logic for creating the NT-lifting function: Just having the constructors of C in scope is not sufficient to safely provide NT a b - NT (C a) (C b) as the parameters of the constructor might wrap a in another type constructor, i.e. data Foo a = Foo (Set a) then we certainly don’t want the user to be able to write deriving fooNT :: NT a b - NT (Foo a) (Foo b) as he can easily get the unwanted (Set a) - (Set b) coercion for arbitrary a b from that. So in this example, the compiler should at most accept deriving fooNT :: NT (Set a) (Set b) - NT (Foo a) (Foo b) but it feels a bit weird that the „internals“ of Foo are relevant here. Following this line of thought it means that for data Proxy a = Proxy we would allow deriving proxyNT :: NT (Proxy a) (Proxy b) without a NT a b parameter, as long as the Proxy data constructor is in scope. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de 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
Exposing newtype coercions to Haskell
Hi, this is related to http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers#Proposal3. I tried to hack up a little prototype of this, and this “works” now: import GHC.NT newtype Age = Age Int deriving Show ageNT :: NT Age Int ageNT = createNT newtype MyList a = MyList [a] deriving Show myListNT :: NT (MyList a) [a] myListNT = createNT main = do let n = 1 :: Int let a = coerce (sym ageNT) 1 let l1 = [a] let l2 = coerce (listNT ageNT) l1 let l3 = coerce (sym myListNT) l2 print a print l2 print l3 will print Age 1 [1] MyList [1] and no unsafeCoerce and no map is used in the production of this output. The GHC.NT module provides: data NT a b coerce :: NT a b - a - b refl :: NT a a sym:: NT a b - NT b a trans :: NT a b - NT b c - NT a c createNT :: NT a b listNT :: NT a b - NT [a] [b] where createNT takes the place of the deriving foo :: NT a b syntax: At compile time, it is checked if its first type argument is a newtype of the second, and the corresponding coercion is inserted, otherwise an error is (well, will be) printed. The idea is that these coercions will be guaranteed to be free (or almost free; I am not sure if the coercion witness (NT a b) will actually be optimized away). The prototype can be found at https://github.com/nomeata/nt-coerce and is implemented as a GHC plugin compatible with GHC 7.6.3 (I chose this route as it means not having to compile GHC). You can check if it works for you via $ ghc -dcore-lint -package ghc --make test.hs ./test The code itself is, well, at most prototype code quality and contains quite a number of hacks and other warts, mostly due to my inexperience with GHC hacking, and I could make use of some advice. Some more concrete questions: * How do I look up a module (here GHC.NT.Type) and a name therein (NT) in CoreM? I tried to go via getOrigNameCache, but passing the ModuleName name to lookupModuleEnv yielded Nothing, although it seems to me to be precisely the same name that I find in moduleEnvKeys. If I take the ModuleName from that list, it works. Similar problems with the OccEnv. Please see https://github.com/nomeata/nt-coerce/blob/edef9f4d4889dde651bb086e76c576f84e8f8aec/GHC/NT/Plugin.hs#L99 for what I tried (and how I worked around it). This work-around also prevents building the package with cabal right now. * I did not find generic Core traversal functions like traverse :: (Monad m) = (Expr a - m (Maybe (Expr a))) - Expr a - m (Expr a) which I defined in https://github.com/nomeata/nt-coerce/blob/edef9f4d4889dde651bb086e76c576f84e8f8aec/GHC/NT/Plugin.hs#L231. Are such traversals re-implemented everywhere or did I just not search well enough? * On the core level, once I have a TyCon, I also have all DataCons available. Is there already code present that checks if the currently compiled module really should see the data constructors, i.e. if they are exported? I see code in normaliseFfiType, but that seems to be integrated in the type checker, and it seems I need a GlobalRdrEnv; can I get such a thing in a Core2Core pass? Thanks, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org 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: ANNOUNCE: GHC version 7.6.3
Hi, Am Sonntag, den 21.04.2013, 14:23 +0100 schrieb Ian Lynagh: = The (Interactive) Glasgow Haskell Compiler -- version 7.6.3 = The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.3. the Debian Haskell Team is pleased to announce that GHC 7.6.3 is available to Debian users in Debian experimental; library rebuilds are in progress. 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: Why is GHC so much worse than JHC when computing the Ackermann function?
Hi, Am Samstag, den 20.04.2013, 13:03 -0700 schrieb Edward Z. Yang: I don't seem to get the leak on latest GHC head. Running the program in GC debug mode in 7.6.2 is quite telling; the program is allocating *a lot* of megablocks. We probably fixed it though? it’s confirmed that it is fixed in HEAD. But it’d be really interesting to know what the bug was and how it was fixed. Could someone who has a setup for running bisect at his fingertips find out? 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
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
Hi,
Am Montag, den 11.03.2013, 23:45 + schrieb Simon Peyton-Jones:
| I don’t feel in the position to actually make a call here, or even to cast
a vote with
| confidence, but I’m happy to continue summarizing the discussion until a
| consensus is found. If there is more discussion, that is.
I've updated the page http://hackage.haskell.org/trac/ghc/wiki/SplitBase a
bit.
thanks.
It seems to me that there are two kinds of goals
A Better for external clients (stable APRs, few version bumps)
B Better for internal implementation (eg using containers or
bytestring in base)
On the Wiki page, (G1) and (G2) are to do with group (A). And this
seems best handled by defining client-facing shim packages that export
just what you want.
However (G4) and later seem to be concerned with (B), and they clearly
do require re-structuring the code.
It seems entirely possible to me that BOTH will be needed. That is,
the structure to achieve (B) will not be precisely what is wanted for
(A). So it seems to be me that both approaches are valid and we might
want to do both. We can do them in either order, or simultaneously.
(Mind you, doing (A) first would make (B) less disruptive for our
users.)
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.
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
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
Hi, Am Dienstag, den 12.03.2013, 14:35 + schrieb Ian Lynagh: I think we should avoid getting bogged down in one small detail at this stage. If we make the bulk of the changes now then we still have a few months to polish the result before it gets effectively frozen by being released. I’m not sure it is just a small detail: The handling of Prelude will influence how practical it is to use the shim package, and how practical it is to use just some of the shim packages. If you don't like the idea of putting it in its own package, then I think either the file-io package (as that's the worst thing it contains) or the pure package (as that's the package most likely to be depended on anyway) would make most sense. Both have issues: Putting it in file-io will cause everyone to depend on file-io, subverting „To allow packages to be explict about what they need (G2)“. Putting it in pure will make pure not pure any more, as the Prelude would still have to contain writeFile etc. But you are right that this discussing this should not prevent us from deciding between A, B and both, and then actually doing it. 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
Hi, Am Dienstag, den 26.02.2013, 10:08 + schrieb Simon Peyton-Jones: I think it would be vv helpful to have all these goals articulated on the wiki page. http://hackage.haskell.org/trac/ghc/wiki/SplitBase well, all the goals are there (or are they not sufficiently well explained)? I also tried to compare the two approaches – the re-exporting API-specifying packages and the actual split of base – by listing their advantages (I skipped the disadvantages, these would just be the negation of the other advantages list...) at http://hackage.haskell.org/trac/ghc/wiki/SplitBase#Approaches I don’t feel in the position to actually make a call here, or even to cast a vote with confidence, but I’m happy to continue summarizing the discussion until a consensus is found. If there is more discussion, that is. 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
Hi, Am Montag, den 25.02.2013, 11:25 -0800 schrieb Johan Tibell: 1. I'd like to have text Handles use the Text type and binary Handles use the ByteString type. Right now we have this somewhat awkward setup where the I/O APIs are spread out and bundled with pure types. Splitting base would let us fix this and write a better I/O layer. 2. The I/O manager currently has a copy of IntMap inside its implementation because base cannot use containers. Splitting base would let us get rid of this code duplication. added to http://hackage.haskell.org/trac/ghc/wiki/SplitBase It would be interesting to see if Text and Bytestring (without the file IO parts) can be compiled using the base-foreign package extracted here https://github.com/nomeata/packages-base/tree/base-split/base-foreign. Looking at the imports, it seems possible. Then a base-io-system package can indeed depend on text and bytestring, and provide the appropriately typed file IO functions there. The containers package looks like a good example for a package that sits on base-pure: No IO, no FFI. So with the split suggested in my branch, having the ghc-io-system depend on containers seems possible. I'm less interested in having super fine-grained dependencies in my libraries. More packages usually means more busy-work managing dependencies. Taken to its extreme you could imagine having base-maybe, base-bool, and whatnot. I don't think this is an improvement. Splitting base into perhaps 3-5 packages (e.g. GHC.*, IO, pure types) should let us get a bunch of benefits without too many downsides. This is basically the goal added by SPJ: Split base into as FEW packages as possible, consistent with meeting the other goals. 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
Hi, Am Samstag, den 23.02.2013, 10:27 + schrieb Simon Peyton-Jones: I’d like to be very clear about goals, though. I have not been following this thread closely enough, but is there a Wiki page that explains what the goals of the base-package break-up is? I added a Goals section to http://hackage.haskell.org/trac/ghc/wiki/SplitBase and besides I believe that the driving goal is: · to allow changes to internals without forcing a version-bump on ‘base’, on which every package depends added these two goals, which I find worthwhile to pursue: To allow packages to be explictly about what they need A library that does not use the IO monad could communicate that just by not depending on some base-io package. Similar with the Foreign Function Interface or unsafe operations. To allow alternative implementations/targets A Haskell-to-Javascript compiler will not support File IO, or maybe not even IO at all. It would be desirable such an implementation has a chance to at least provide a complete and API compatible base-pure package, and that one can hence reasonably assume that packages and libraries depending only on base-pure will indeed work without modification. This might be subsumed by fulfilling the previous goal. Just by looking at the goals, the variant with a big base package that uses all kinds of “uglyness” (FFI for pure stuff, cyclic dependencies between API-wise unrelated stuff, lots of GHC internals used) and re-exporting packages that have a more specific and possibly more stable API sounds like it can provide the mentioned goals. Iain commented this idea earlier this thread¹ with three points: * No-one would use the new packages unless they come with GHC; e.g. not a perfect analogy, but compare the number of rev-deps according to http://packdeps.haskellers.com/reverse of the various *prelude* packages vs base: 4831 base 6 basic-prelude 8 classy-prelude 4 classy-prelude-conduit 2 custom-prelude 1 general-prelude 1 modular-prelude 17 numeric-prelude 2 prelude-extras Hopefully the problem here (often-changing base) is big enough and the alternative (more purpose-oriented and more stable) packages are attractive enough to make people use the new set. * If it comes with GHC, it would mean us permanently maintaining the two levels True. I’m not convinced that it will be too much a burden, at least if the reexporting packages do that on the module level. * base would still be an opaque blob, with too many modules and cyclic imports, which makes development tricky Does it really make development tricky? I’d rather expect it to make development easier, because you _can_ mix, say, IO and Foreign stuff easily and even use some of that in lower levels. If it were less tricky to separate it, then my experiment at https://github.com/nomeata/packages-base/tree/base-split would have been less work... In any case there is still the problem: What and where is the Prelude... but maybe let’s postpone this. Greetings, Joachim ¹ http://www.haskell.org/pipermail/glasgow-haskell-users/2013-February/023774.html -- 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
Hi, another status report about my base-splitting experiment: The list of packages has grown to * base-pure: Basic stuff without `IO`, `Foreign` or floating point arithmetic. * base-st: The `ST` monad, uses base-pure. * base-array: Arrays, uses base-st. * base-float: Floating point types, uses base-array internally. * base-io: The `IO` monad, uses base-st. * base-concurrent: Currently just `MVar`, uses base-io. * base-foreign: Everything related to `Foreign`, uses base-io and base-float (for the `Storable` instances for `Double` and `Float`). Of the (exactly!) 200 modules in base, 83 have not yet been sorted into these or other packages: Control/Concurrent.hs Control/Concurrent/Chan.hs Control/Concurrent/QSem.hs Control/Concurrent/QSemN.hs Control/Concurrent/SampleVar.hs Control/Exception.hs Control/Exception/Base.hs Control/Monad/Instances.hs Data/Data.hs Data/Dynamic.hs Data/Fixed.hs Data/HashTable.hs Data/Unique.hs Data/Version.hs Debug/Trace.hs GHC/Conc.lhs GHC/Conc/IO.hs GHC/Conc/Signal.hs GHC/Conc/Sync.lhs GHC/Conc/Windows.hs GHC/ConsoleHandler.hs GHC/Constants.hs GHC/Desugar.hs GHC/Environment.hs GHC/Event.hs GHC/Event/Array.hs GHC/Event/Clock.hsc GHC/Event/Control.hs GHC/Event/EPoll.hsc GHC/Event/IntMap.hs GHC/Event/Internal.hs GHC/Event/KQueue.hsc GHC/Event/Manager.hs GHC/Event/PSQ.hs GHC/Event/Poll.hsc GHC/Event/Thread.hs GHC/Event/Unique.hs GHC/Exts.hs GHC/GHCi.hs GHC/Generics.hs GHC/Handle.hs GHC/IO.hs-boot GHC/IO/Device.hs GHC/IO/Exception.hs GHC/IO/Exception.hs-boot GHC/IO/FD.hs GHC/IO/Handle.hs GHC/IO/Handle.hs-boot GHC/IO/Handle/FD.hs GHC/IO/Handle/FD.hs-boot GHC/IO/Handle/Internals.hs GHC/IO/Handle/Text.hs GHC/IO/Handle/Types.hs GHC/IO/IOMode.hs GHC/IOArray.hs GHC/IOBase.hs GHC/IP.hs GHC/PArr.hs GHC/Pack.lhs GHC/Stack.hsc GHC/Stats.hsc GHC/TopHandler.lhs GHC/TypeLits.hs GHC/Windows.hs NHC/PosixTypes.hsc NHC/SizedTypes.hs Numeric.hs Prelude.hs System/CPUTime.hsc System/Console/GetOpt.hs System/Environment.hs System/Environment/ExecutablePath.hsc System/Exit.hs System/IO.hs System/IO/Error.hs System/Info.hs System/Mem.hs System/Mem/StableName.hs System/Mem/Weak.hs System/Posix/Types.hs System/Timeout.hs Text/Printf.hs Inspired by a similar graph by Herbert Valerio Riedel, I tried to visualize the current state and came up with this: https://github.com/nomeata/packages-base/blob/base-split/graph.pdf?raw=true It is not completely accurate due to Prelude not included in -ddump-minimal-imports (but that shouldn’t matter as most interesting functions of the Prelude are in base-pure). The script to generate the dot file from *.imports is included in the branch at https://github.com/nomeata/packages-base/tree/base-split Next I’d need to see how entangled the system-close stuff is (File IO, concurrency, GHC.Event.*). Of course with too much splitting one runs in the Bane of the Orphaned Instances – neither should base-foreign require base-float nor the other way around, but Storable Double needs to be define somewhere... And the same question will arise if Data.Date should go to a package of its own. Also, I notice that there is an issue with “internal” modules (mostly GHC.something) that should not be part of some stable API, but needed to implement packages further down. Should they just not be considered part of the “public” (and PVP-relevant) API? Or should there be two packages, e.g. base-pure-internal and base-pure, where the latter re-exports those modules that are meant for public consumption? So, what is the general opinion? Is this a way worth pursuing? Or are we fine with the huge base and I can do different things again ;-)? 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
Hi, Am Freitag, den 22.02.2013, 11:38 -0800 schrieb Johan Tibell: In addition, I don't think we want to say that e.g. pure data structures can't depend on the FFI. While their current implementation might not use the FFI, what if we want to use it in the future. We'd have to reshuffle the packages again. right, there is a tension between having just independent APIs and having also independent implementations. My main goal is to allow packages to specify their imports more precisely, to require less changes as not-so-common stuff in base evolves and to make it easier for alternative compiler/targets to implement parts of base; this would just require providing better grouped APIs. But if we want that while retaining the freedom to have an entangled implementation, we are back at the large base + specific re-exporting packages approach, which wasn’t particularly well received here. Greetings, Joachim PS: Even with the currently explored split stuff in base-pure can use the FFI; it could just not use the modules from the Foreign.* structure. This may or may not be a problem. It was for the GHC.Fingeprint implementation, as it was marshalling arrays. -- 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
Hi, Am Donnerstag, den 21.02.2013, 09:42 + schrieb Simon Marlow: The trick is indeed neat, but only if it is possible to make IOFail completely invisible. If it isn't possible to make it completely invisible, then I would prefer IOFail to be a first-class exception type without the special trick to coerce it to IOException, and accept the API breakage. I don't think it's a good idea to have special magic in the exception hierarchy - other people would start doing it too, then we'd have a mess. great – for the purposes of splitting base I don’t care which one is taken, as long as I know that there is some way. I have now changed my setup so that I can modify the files without removing others or moving them to different branches or symlinking. This way, a simple git diff ghc-7.6 base-split lists all changes. I also created a script to check whether every module is in exactly one of the new packages. See https://github.com/nomeata/packages-base/blob/base-split/README.md for a description of the setup and an explanation of the changes applied. Contributions welcome! 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
Hi, Am Freitag, den 15.02.2013, 23:00 +0100 schrieb Joachim Breitner: Am Freitag, den 15.02.2013, 14:50 + schrieb Simon Marlow: On 15/02/13 12:22, Joachim Breitner wrote: more progress: On top of base-pure, I created base-io involving GHC/IO and everything required to build it (which pulled in ST, some of Foreign and unfortunately some stuff related to Handles and Devices, because it is mentioned in IOException). This is the list of modules: You have a random collection of modules here :) I think you want to have the IO *monad* (GHC.IO) live in a lower layer, separate from the IO *library* (GHC.IO.Device and so on). Every Haskell implementation will need the IO monad, but they might want to replace the IO library with something else. Things like GHC.IORef, GHC.MVar can all live in a low-down layer because they're just wrappers over the primops. Right, that is my aim, and I started with GHC.IO. But unfortunately, the IO monad calls failIO, which is an IOError which has a field of type ioe_handle :: Maybe Handle (and one of type CInt) which pulls in all the rest there, and so far I did not have a good idea how to untangle that. What would break if fail would not raise an IOError, but a separate exception type, e.g. IOFailError? Probably too much, as users expect to catch the exception raised by fail with an exception handler that matches IOError. I’m still stuck at the problem of separating the definition of IO and Monad IO from all file related stuff, which is prevented by the Maybe Handle field in the IOError data type. Given that IOError is abstract to the „regular“ user (i.e. not to base-io-file), I guess we can afford to be a little bit hacky here. Two ideas come to my mind: 1. Instead of declaring the field as Maybe Handle, we define a pseudo-handle datatype data NotYetAHandle = NotYetAHandle and use Maybe NotYetAHandle in IOError, with the documented convention that only code in base-io-file (and code further down the tree) may use this field, and only after unsafeCoerce’ing it to a Maybe Handle. This way, the base-io package does not have to include the definition, but the IOError data type still has place for it. If the NotYetAHandle constructor is not exported, and base-io-file defines functions NotYetAHandle - Handle and Handle - NotYetAHandle via unsafeCoerce, then the unsafeness is very local and nobody can break the code without also using unsafeCoerce. 2. A little safer (and with a little more overhead) wold be to include Data.Dynamic in base and change the field to a Maybe Dynamic. Same procedure as above, only that a violation of the convention might be caught without crashes. Is having a package that provides io without providing file-related definition worth this kludge? Greetings, Joachimh -- 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
Hi,
Am Mittwoch, den 20.02.2013, 14:57 +0100 schrieb Joachim Breitner:
I’m still stuck at the problem of separating the definition of IO and
Monad IO from all file related stuff, which is prevented by the Maybe
Handle field in the IOError data type.
re-reading „An Extensible Dynamically-Typed Hierarchy of Exceptions“
helped me to come up with this somewhat neat solution:
The Monad IO instance uses an exception different from IOError:
$ git show HEAD | filterdiff -i \*.cabal -i \*Fail\* -i \*/GHC/IO.hs
--- a/GHC/IO.hs
+++ b/GHC/IO.hs
@@ -46,8 +46,7 @@ import GHC.ST
import GHC.Exception
import GHC.Show
import Data.Maybe
-
-import {-# SOURCE #-} GHC.IO.Exception ( userError )
+import GHC.IO.Fail
-- ---
-- The IO Monad
@@ -79,7 +78,7 @@ liftIO :: IO a - State# RealWorld - STret RealWorld a
liftIO (IO m) = \s - case m s of (# s', r #) - STret s' r
failIO :: String - IO a
-failIO s = IO (raiseIO# (toException (userError s)))
+failIO s = IO (raiseIO# (toException (IOFail s)))
-- ---
-- Coercions between IO and ST
--- /dev/null
+++ b/GHC/IO/Fail.hs
@@ -0,0 +1,20 @@
+{-# LANGUAGE NoImplicitPrelude #-}
+module GHC.IO.Fail where
+
+import GHC.Base
+import GHC.Exception
+import Data.Typeable
+import GHC.Show
+
+
+-- | This exception is thrown by the 'fail' method of the 'Monad' 'IO'
instance.
+--
+-- The Exception instance of IOException will also catch this, converting the
+-- IOFail to a UserError, for compatibility and consistency with the Haskell
+-- report
+data IOFail = IOFail String
+
+instance Typeable IOFail -- deriving does not work without package
+instance Show IOFail -- name changes to GHC
+instance Exception IOFail
+
After this change,
exposed-modules:
GHC.IO.Fail,
GHC.IO,
GHC.IORef,
GHC.ST,
GHC.STRef
is possible (and of course ST can be moved away as well).
So far so good, but this breaks user code. So the solution is to make
sure that to everyone who tries to catch an IOException (which will
likely be part of some base-io-file), an IOFail will look like a IOError
of type UserError:
$ git show HEAD|filterdiff -i \*Exception.hs
--- a/GHC/IO/Exception.hs
+++ b/GHC/IO/Exception.hs
@@ -45,9 +45,10 @@ import GHC.Show
import GHC.Exception
import Data.Maybe
import GHC.IO.Handle.Types
+import GHC.IO.Fail
import Foreign.C.Types
-import Data.Typeable ( Typeable )
+import Data.Typeable ( Typeable, cast )
--
-- Exception datatypes and operations
@@ -222,7 +223,11 @@ data IOException
}
instance Typeable IOException
-instance Exception IOException
+instance Exception IOException where
+toException = SomeException
+fromException e = case cast e of
+Just (IOFail s) - Just (userError s)
+Nothing - cast e
instance Eq IOException where
(IOError h1 e1 loc1 str1 en1 fn1) == (IOError h2 e2 loc2 str2 en2 fn2) =
Neat, isn’t it?
Now I can proceed separating some of the Foreign stuff from the IO
stuff.
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 (Was: GHC 7.8 release?)
Hi, Am Donnerstag, den 14.02.2013, 21:41 -0500 schrieb brandon s allbery kf8nh: On Thursday, February 14, 2013 at 8:14 PM, Johan Tibell wrote: On Thu, Feb 14, 2013 at 2:53 PM, Joachim Breitner m...@joachim-breitner.de wrote: I don't think having FFI far down the stack is a problem. There are lots of pure data types we'd like in the pure data layer (e.g. bytestring) that uses FFI. As long as the I/O layer itself (System.IO, the I/O manager, etc) doesn't get pulled in there's no real problem in depending on the FFI. I think it would be nice, also to other Haskell implementations that might have not have FFI, to separate the really basic stuff from pure-but-impurely-implemented stuff. At least as long as it does not caues trouble. GHC.Fingerprint does not need to be crippled when it is going to use a pure hashing; I quickly added some simple fingerpriting found via Wikipedia that was easier than MD5. https://github.com/nomeata/packages-base/commit/b7f80066a03fd296950e0cafa2278d43a86f82fc The choice is of course not final, maybe something with more bits is desirable. Doesn't the FFI pull in some part of the I/O layer, though? In particular threaded programs are going to end up using forkOS? Another good reason to try to have a pure ground library. Based on base-pure, the next step would be to check if FFI can be provided without IO (but I doubt that is difficult), so there would be an base-io package on top of base-pure, and then bytestring can depend on that base-io and base-pure, while users of bytestring of course don’t have to depend on base-io (as long as they are not using the IO-related functions of bytestring). Questions: * Does anyone have a tool to compare package APIs? It would be interesting to diff base’s API with the combined APIs of the package we are creating right now. * Currently, base-pure exports lots of modules that should not be part of its “pure” API (all the GHC.* packages). But I assume they need to be exported for the benefit of packages like base-io built on top. Should we provide another package that re-exports those that are for public consumption and is likely to have a more stable API? Again I feel the need for packages re-exporting modules without incurring a conflict. * What to do with Prelude. Should it be in base-io (which is potentially the lowest package containing everything needed) or rather in a package of its own? Or should it live in a package of its own? Or can we use the haskell2010 package for that somehow? * Should base-io provide just the IO monad and all, say, file-related stuff in a separate package or is this going too far? 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 (Was: GHC 7.8 release?)
Hi, more progress: On top of base-pure, I created base-io involving GHC/IO and everything required to build it (which pulled in ST, some of Foreign and unfortunately some stuff related to Handles and Devices, because it is mentioned in IOException). This is the list of modules: Foreign.C.Types, Foreign.ForeignPtr, Foreign.ForeignPtr.Imp, Foreign.ForeignPtr.Safe, Foreign.ForeignPtr.Unsafe, Foreign.Ptr, Foreign.Storable, GHC.ForeignPtr, GHC.IO.BufferedIO, GHC.IO.Buffer, GHC.IO.Device, GHC.IO.Encoding.Types, GHC.IO.Exception, GHC.IO.Handle.Types, GHC.IO, GHC.IORef, GHC.MVar, GHC.Ptr, GHC.Stable, GHC.ST, GHC.Storable, GHC.STRef It is on a different branch on my github repo: https://github.com/nomeata/packages-base/tree/base-io GHC would complain that the CInt type is not valid in a ffi call (probably due to the different package name), so I replaced foreign declarations by regular ones defined using “undefined” – after all I’m just trying to discover how things can be split at all and just work towards building stuff. ST can probably be pulled below this package, after all it is quite pure. Either a package of its own, or in base-pure. 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 (Was: GHC 7.8 release?)
Hi, Am Freitag, den 15.02.2013, 14:50 + schrieb Simon Marlow: On 15/02/13 12:22, Joachim Breitner wrote: Hi, more progress: On top of base-pure, I created base-io involving GHC/IO and everything required to build it (which pulled in ST, some of Foreign and unfortunately some stuff related to Handles and Devices, because it is mentioned in IOException). This is the list of modules: You have a random collection of modules here :) I think you want to have the IO *monad* (GHC.IO) live in a lower layer, separate from the IO *library* (GHC.IO.Device and so on). Every Haskell implementation will need the IO monad, but they might want to replace the IO library with something else. Things like GHC.IORef, GHC.MVar can all live in a low-down layer because they're just wrappers over the primops. Right, that is my aim, and I started with GHC.IO. But unfortunately, the IO monad calls failIO, which is an IOError which has a field of type ioe_handle :: Maybe Handle (and one of type CInt) which pulls in all the rest there, and so far I did not have a good idea how to untangle that. What would break if fail would not raise an IOError, but a separate exception type, e.g. IOFailError? Probably too much, as users expect to catch the exception raised by fail with an exception handler that matches IOError. 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 (Was: GHC 7.8 release?)
Hi, Am Donnerstag, den 14.02.2013, 02:21 + schrieb Ian Lynagh: On Wed, Feb 13, 2013 at 07:32:06PM +0100, Joachim Breitner wrote: I have started a wikipage with the list of all modules from base, for a first round of shuffling, grouping and brainstorming: http://hackage.haskell.org/trac/ghc/wiki/SplitBase Great, thanks for taking the lead on this! lets see how far that leads goes... Yesterday, I experimented a bit with base’s code, first beginning with as few modules as possible and adding what’s required; then starting with the whole thing and trying to remove e.g. IO. But clearly it is not easy: 1. Int requires throw DivideByZero; Monad requires error. That pulls in Exceptions. 2. Exceptions require Typeable. 3. Typeable is implemented with GHC.Fingerprint. 4. GHC.Fingerprint is implemented with Foreign and IO. 5. Foreign clearly needs Int and the like. so it is not clear how to pull out a pure base without IO and Foreign. Are there any good tricks how to break these interdependencies? Maybe it is possible to have a pure base without the Monad class and without some of the operations on Int that throw exceptions, but that wold hardly be useable. There are other issues, some avoidable (such as the hard-coded base:Num constraint on literals); I collected a list on http://hackage.haskell.org/trac/ghc/wiki/SplitBase Maybe the proper is to reverse the whole approach: Leave base as it is, and then build re-exporting smaller packages (e.g. a base-pure) on top of it. The advantage is: * No need to rewrite the tightly intertwined base. * Libraries still have the option to have tighter dependencies. * Base can evolve with lots of breaking changes, as long as they do not affect the API by the smaller packages. * Development of this collection can happen outside the GHC tree. * Alternative implementations for (some of) these packages can be created, if the reason why they could not be moved out of base is one of implementation, not of API How does that sound? 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 (Was: GHC 7.8 release?)
Hi, I made a little progress after crippling GHC.Fingerprint: The package at https://github.com/nomeata/packages-base/tree/base-pure (Branch base-pure) builds and contains just these modules: ./Control/Applicative.hs ./Control/Arrow.hs ./Control/Category.hs ./Control/Monad/Fix.hs ./Control/Monad.hs ./Data/Bits.hs ./Data/Bool.hs ./Data/Either.hs ./Data/Eq.hs ./Data/Foldable.hs ./Data/Function.hs ./Data/Functor.hs ./Data/Int.hs ./Data/List.hs ./Data/Maybe.hs ./Data/Monoid.hs ./Data/Ord.hs ./Data/Ratio.hs ./Data/Traversable.hs ./Data/Tuple.hs ./Data/Typeable.hs ./Data/Typeable.hs-boot ./Data/Typeable/Internal.hs ./Data/Typeable/Internal.hs-boot ./dist/build/autogen/Paths_base_pure.hs ./GHC/Base.lhs ./GHC/Char.hs ./GHC/Enum.lhs ./GHC/Err.lhs ./GHC/Err.lhs-boot ./GHC/Exception.lhs ./GHC/Fingerprint.hs ./GHC/Fingerprint/Type.hs ./GHC/Int.hs ./GHC/List.lhs ./GHC/Num.lhs ./GHC/Real.lhs ./GHC/Show.lhs ./GHC/Word.hs ./Prelude.hs (contains just $!) ./Unsafe/Coerce.hs The crippling can be seen here: https://github.com/nomeata/packages-base/blob/base-pure/GHC/Fingerprint.hs So if there were a magic way of getting a working GHC.Fingerprint module without pulling in Foreign, this would be a good start for a base free of any trace of * Foreign * IO * Floating point arithmetic * Read * ST * Array Alternative, a magic way of providing the functions error and divZeroError without having to define Exceptions would do well. I guess it is not possible to define the data ErrorCall without the Exception class and somehow call the primop raise# in a way that the error can be caught, as catch will expect something of type SomeException that has the Exception dictionary bundled. Any idea how to achieve that, without having resort to ghc-bottom as suggested by Ian (which would be ok, but not as nice as genuine small packages to start with)? 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 (Was: GHC 7.8 release?)
Hi, Am Donnerstag, den 14.02.2013, 13:19 -0800 schrieb Johan Tibell: That's great. I'm curious I was under the impression that it was hard to split out a pure subset as functions might call 'error' (e.g. due to incomplete pattern matches) and that would pull in the whole I/O subsystem. How did you avoid that? as mentioned before: By crippling GHC.Fingerprint. error foo just calls raise (ErrorCall foo), which calls raise# (SomeException (ErrorCall foo). The problem is that the definition of SomeException pulls in the Exception type class, which pulls in Typeable, which pulls in GHC.Fingerprint, which uses FFI and IO code to to fingerprinting... Looking at the code it seems that the FFI is only required for MD5. Maybe a pure implementation there is worth it, if it is not performance-critical code. Or, another work-around, would be primops for these commands that can be used without the FFI types and IO. I have also removed GHC.Unicode and functions like lines that require the FFI calls there. These seem to be the largest open issues. 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 (was: GHC 7.8 release?)
Hi, Am Mittwoch, den 13.02.2013, 11:34 +0200 schrieb Roman Cheplyaka: It would be great to have a portable base, without any GHC-specific stuff in it. After all, modules like Control.Monad or Data.Foldable are pure Haskell2010. while you are considering to split base, please also consider separating IO out. We can expect compiling Haskell to, say JavaScript or other targets that are not processes in the usual sense. For these IO might not make sense. Having something below base that provides the pure stuff (common data structures etc.) would enable libraries to easily say: „My algorithm can be used in normal programs as well as in programs that are compiled to JS“ by not depending on base, but on, say, pure-base. 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
base package (Was: GHC 7.8 release?)
Hi, Am Mittwoch, den 13.02.2013, 13:58 + schrieb Ian Lynagh: If we go this route, then we would probably want to end up without a package called 'base', and then to make a new package called 'base' that just re-exports modules from all the new packages. can you transparently re-export a module from another package? I.e. if base depends on io, IO provides System.IO, is there a way for base to tell ghc to pretend that System.IO is in base, but that there is no conflict if io happens to be un-hidden as well. It seems that something like this would be required to move modules from base to something below it without breaking existing code. Also, if it works that smooth, this would not have to be one big reorganization, but could be done piece by piece. The disadvantage is that, at some point between the first release and the release that removes base, each package will have to have its dependencies updated. Why remove base? If it is just a list of dependencies and list of modules to be re-exported, then keeping it (but advocate that it should not be used) should not be too much a burden. (This is assuming that the reorganizing should not change existing module names. If your plan was to give the modules new names, this problem does not exist, but I’d rather prefer the less intrusive approach.) 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 (Was: GHC 7.8 release?)
Hi, I have started a wikipage with the list of all modules from base, for a first round of shuffling, grouping and brainstorming: http://hackage.haskell.org/trac/ghc/wiki/SplitBase Am Mittwoch, den 13.02.2013, 18:09 + schrieb Ian Lynagh: On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote: Am Mittwoch, den 13.02.2013, 13:58 + schrieb Ian Lynagh: If we go this route, then we would probably want to end up without a package called 'base', and then to make a new package called 'base' that just re-exports modules from all the new packages. can you transparently re-export a module from another package? I.e. if base depends on io, IO provides System.IO, is there a way for base to tell ghc to pretend that System.IO is in base, but that there is no conflict if io happens to be un-hidden as well. No. But there are currently no packages that depend on both base and io, and anyone adding a dependency on io would remove the base dependency at the same time. hmm, that reminds me of how haskell98 was handled, and it was slightly annoying when haskell98 and base eventually were made to conflict, and we had to patch some unmaintained packages. Ok, in this case io would be introduced with the intention of being used exclusive from base. So as long as we make sure that the set of modules exported by base is always the union of all modules provided by package that have any module in common with base this would be fine. (Why this condition? Imagine io adding IO.GreatModule without base also providing the module. Then a program that still uses base cannot use IO.GreatModule without fixing the dependencies _now_ (or using package imports everywhere). It would be nice if library authors allowed to do the change whenever convenient.) Also, if it works that smooth, this would not have to be one big reorganization, but could be done piece by piece. It's tricky to do it piece by piece. It's hard to remove individual sensible pieces in the first place, and it means that you can't subsequently move modules between packages later without breaking code depending on the new packages. Agreed. The disadvantage is that, at some point between the first release and the release that removes base, each package will have to have its dependencies updated. Why remove base? If it is just a list of dependencies and list of modules to be re-exported, then keeping it (but advocate that it should not be used) should not be too much a burden. * Any package using it doesn't benefit from the reduced version bumps, so we do actually want packages to move away from it We want them to do so. We should not force them (most surely will...) * Even though base (probably) wouldn't require a lot of work at any one time, it would require a little work every now and again, and that adds up to a lot of work Hopefully it is just updating the set of modules to be exported, sounds like it could be automated, given a list of packages. * Any time a module is added to one of the new packages, either we'd have to spend time adding it to base too, or packages continuing to use base wouldn't (easily) be able to use that new module. Hence we should add them; shouldn’t be too much work. After every larger change to base I am forced to touch old, hardly maintained code that I do not know, to get the packages working in Debian again. Hence my plea for staying compatible as long as feasible. 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: GHC 7.8 release?
Hi, one remedy to the problem could be better infrastructure: * More automated test-building of packages on hackage (including test suites) with various GHC releases, and better display of the results. This way, library authors would not have to manually build their library to see if they work with the latest compiler. * Automatic test building of packages with explicit relaxation of the dependencies, to suggest dependency relaxation that would work without code changes (from my work at Debian, in most cases only meta-data changes are required to support newer versions of dependencies, including core libs). * A more liberal attitude to changing other peoples packages’s metadata to fix the dependencies – either to exclude broken combinations or to expand the range. Preferably online, similar to the edit button in github, and checked by the above CI infrastructure. This way, it would be easier for libraries to support newer GHC releases without having to give up supporting older releases. But I know that development of Hackage is not something that seems to be happening a lot right now, and as I don’t help, I’m not complaining. So consider this a side notice and carry on discussing :-) 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: GHC 7.8 release?
Hi, Am Montag, den 11.02.2013, 22:31 + schrieb Simon Peyton-Jones: No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. wording does indeed help a lot. I remember that 7.2 was dubbed a technology review with the effect that, at least Debian, never included it in the main repository. It was packaged and provided in experimental, for easy access to those who want to play with it, but not with additional library packages. From what I can remember, there was no push towards supporting 7.2 properly, and I believe this would have been different if 7.2 was just “the next regular GHC release”. 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: ANNOUNCE: GHC 7.6.2 Release Candidate 1
Hi, Am Dienstag, den 22.01.2013, 21:39 -0800 schrieb David Terei: ghc/hschooks.c:36:0: error: conflicting types for ‘StackOverflowHook’ oh, is GHC about to have a feature where, upon a compiler error, it will ask the user „would you like me to ask on stack overflow about this for you?“? Very cool! Are we going to see a GoogleHock, HayooHock, HaskellCafeHook and ComplainOnTwitterHook as well? Greetings, Joachim (SCNR) -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ 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
RULES map (\x - x) = id
Hi,
I am experimenting with rewrite rules, but found that they do not fire
as often as I wanted them. Here is a small example:
module MapId where
myMap f [] = []
myMap f (x:xs) = f x : myMap f xs
{-# RULES map id myMap id = id #-}
{-# RULES map id2 myMap (\x - x) = id #-}
mapId = myMap id
mapIdApp x = myMap id x
mapLamId = myMap (\x - x)
mapLamIdApp x = myMap (\x - x) x
This works as expected, i.e. the latter four functions become some kind
of identity. But I am a bit surprised that I do need two rules to catch
all cases, as I thought that the simplifier „looks through“ definitions
like id. But when I remove the map id rule, the functions mapId
and mapIdApp are not optimized.
So I wonder: Why is rule map id2 not enough here?
Thanks,
Joachim
--
Joachim nomeata Breitner
m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C
xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/
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
