- ghc-devs - Haskell.org

Cleanup of RnExpr, RnEnv and RnSource
by Jan Stolarek 30 Jun '14

30 Jun '14

Dear all, RnExpr, RnEnv and RnSource (in compiler/renamer) declare locally: \begin{code} -- XXX thenM :: Monad a => a b -> (b -> a c) -> a c thenM = (>>=) thenM_ :: Monad a => a b -> a c -> a c thenM_ = (>>) \end{code} and then use these aliases instead of >>= and >>. These were introduced by Ian in 6c7b41cc2b24f533697a62bf1843507ae043fc97 in 2008 and later partially cleaned up by Simon in f0c99958649b8909612b1b9c9b48aad970dfce05 in 2009. Would there be objections if I cleand this up (ie. remove thenM and thenM_ and use >>= and >>)? Is anyone doing any substantial changes on any of these files and suspects that this could introduce merge conflicts for him? I'm at the moment changing some things in RnExpr, so doing this will only add little extra work for me and I'd like to take this oportunity to have cleaner code. Janek

2 1

cc & ld extra flags
by Mark Lentczner 29 Jun '14

29 Jun '14

I'd like to build GHC, and all the base libs, with an extra flag supplied to cc (well gcc) and ld commands: I thought I could just add this to mk/build.mk: SRC_CC_OPTS = -mmacos-version-min=10.7 SRC_LD_OPTS = -mmacos-version-min=10.7 But this seems very inconsistently applied. For example: This part of the build of the RTS gets it: "inplace/bin/ghc-stage1" -optc-m64 -optc-fno-stack-protector *-optc-mmacosx-version-min=10.7* -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-DBE_CONSERVATIVE -optc-DDTRACE -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Hash.c -o rts/dist/build/Hash.o But this part doesn't: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -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.1 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.8.2.20140623 -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 -c utils/haddock/src/Haddock/Utf8.hs -o utils/haddock/dist/build/Haddock/Utf8.dyn_o I think it might have to do with the dyn_o and thr_o targets? So - Is there a better way to ensure these flags are applied? I suppose I could wrap gcc (clang) and ld.... but that seems ham-handed. - Mark

2 2

Re: New GHC feature proposal: Pattern families
by Baldur Blöndal 29 Jun '14

29 Jun '14

Yes I reported #9226 :) I created a wiki page for pattern families (https://ghc.haskell.org/trac/ghc/wiki/PatternFamilies) with a whole host of examples, trying to keep them simple so do let me know it anything is unclear. In the area of pattern synonyms I agree with testing the waters a bit, personally I'd like to change the syntax since it doesn't really scale for using complicated view patterns (forcing you to define auxiliary functions) and looks a bit awkward when adding type annotations and explicitely bidirectional patterns. I'd say explicitely bidirectional patterns are the next step forward but it depends on the priorities: · End users: Explicitely bidirectional patterns (#8581) and associated pattern synonyms (#8583) are the biggest two, although the latter can be ‘faked’ with type classes: If #8581/#8583 are implemented and if (:)/[] weren't built-in syntax libraries like Data.Text could be used as a drop-in replacement for String, currently users must change every pattern match to a case statement (but I digress) · Library authors: Exhaustiveness checks (#8779) are important for getting abstract data types on par with normal data types. Since you mentioned VPA (ViewPatternsAlternative) I took the liberty of using several examples from the VPA wiki page and contrasting them with the example found there, most of the ones I did not mention (like “join lists”) can be implemented using PatternSynonyms, I feel some of the VPA examples are better motivating examples than what I presented before. Best regards, Baldur 2014-06-29 9:40 GMT+02:00, Baldur Blöndal <baldurpet(a)gmail.com>: > Yes I reported #9226 :) > > I created a wiki page for pattern families > (https://ghc.haskell.org/trac/ghc/wiki/PatternFamilies) with a whole > host of examples, trying to keep them simple so do let me know it > anything is unclear. > > In the area of pattern synonyms I agree with testing the waters a bit, > personally I'd like to change the syntax since it doesn't really scale > for using complicated view patterns (forcing you to define auxiliary > functions) and looks a bit awkward when adding type annotations and > explicitely bidirectional patterns. > > I'd say explicitely bidirectional patterns are the next step forward > but it depends on the priorities: > · End users: Explicitely bidirectional patterns (#8581) and associated > pattern synonyms (#8583) are the biggest two, although the latter can > be ‘faked’ with type classes: If #8581/#8583 are implemented and if > (:)/[] weren't built-in syntax libraries like Data.Text could be used > as a drop-in replacement for String, currently users must change every > pattern match to a case statement (but I digress) > · Library authors: Exhaustiveness checks (#8779) are important for > getting abstract data types on par with normal data types. > > Since you mentioned VPA (ViewPatternsAlternative) I took the liberty > of using several examples from the VPA wiki page and contrasting them > with the example found there, most of the ones I did not mention (like > “join lists”) can be implemented using PatternSynonyms, I feel some of > the VPA examples are better motivating examples than what I presented > before. > > Best regards, > Baldur > > 2014-06-23 17:30 GMT+02:00, Edward Kmett <ekmett(a)gmail.com>: >> The main thing Baldur had asked me about was if it makes sense to talk >> about patterns that are parameterized by expressions in places. >> >> I agree that the thought is very poorly fleshed out, but as a motivation, >> in some sense the previous form of view patterns already do this. >> >> Consider (->), which takes in an expression to apply on the left and a >> pattern for what to match against the result of it on the right. >> >> The question then becomes can we allow this for arbitrary patterns? >> >> There are a number of use cases for these. For example, >> >> A pattern to match a regular expression might look like >> >> Foo (x :~= "ab*") >> >> where you want "ab*" to be passed as a parameter to the code for the >> pattern synonym (:~=), not be something it is binding. >> >> This then speaks to needing some notion of mode for the different >> parameters. >> >> One of the reasons I'm under-excited about pattern synonyms is we already >> built all the machinery for working with prisms in lens to generalize >> them. >> =) >> >> In lens we have a combinator 'preview :: Prism' s a -> s -> Maybe a'. >> >> As a straw man proposal: >> >> It'd be nice to be able to do something like >> >> pattern (Match p a) <- (preview p -> Just a) >> >> and have it take the arguments that go to the left hand side of the -> as >> expressions, not patterns so that that can compile. >> >> Now, I'm somewhat dubious that it worth the pain to embellish the pattern >> language with something this complicated, but in some sense we already >> have >> a lot of the machinery to support it. e.g. IIRC we parse patterns first >> as >> expressions then convert them. >> >> -Edward >> >> >> On Mon, Jun 23, 2014 at 4:39 AM, Simon Peyton Jones >> <simonpj(a)microsoft.com> >> wrote: >> >>> Baldur >>> >>> (My name is Simon, not Peyton, incidentally. "Peyton Jones" is my last >>> name.) >>> >>> I'm glad you are enjoying pattern synonyms. Thanks for identifying >>> #9226, >>> which I guess is you. >>> >>> I honestly don't understand your pattern family proposal. Would you >>> like >>> to write a wiki page somewhere describing the >>> syntax >>> typing (static semantics) >>> desugaring (dynamic semantics) >>> as clearly and precisely as you can, independent of prisms, and using >>> the >>> simplest possible examples to illustrate. By all means say that prisms >>> are >>> a more advanced application, and give examples to show how. But in >>> general >>> to specify a language feature you need a lot more than a couple of >>> examples! >>> >>> Then you can ask GHC users what they think. >>> >>> I have to say that I'm cautious about adding further features to pattern >>> synonyms until we've gotten more user experience with what we have. (Do >>> you think the explicitly bidirectional stuff on the wiki page is >>> important? >>> To me that seems like the first thing a user might stumble over.) >>> >>> Incidentally, I'd really like to replace view patterns with >>> https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative, another >>> thing that is awaiting cycles. >>> >>> Copying ghc-devs for interest >>> >>> Thanks >>> >>> Simon >>> >>> >>> >>> | -----Original Message----- >>> | From: Baldur Blöndal [mailto:baldurpet@gmail.com] >>> | Sent: 18 June 2014 04:31 >>> | To: Simon Peyton Jones; gergo(a)erdi.hu >>> | Subject: New GHC feature proposal: Pattern families >>> | >>> | Hello Peyton and Gergo, >>> | >>> | I'm a master's student at Chalmers, a minor GHC contributor and have >>> | written about the pattern synonyms extension >>> | (https://www.fpcomplete.com/user/icelandj/Pattern%20synonyms) and >>> | included is a proposal for an extension I call “pattern families” >>> | allowing users to create patterns parameterized by an expression. I >>> feel >>> | like patterns don't get nearly as much attention as the type system >>> and >>> | this is my attempt to balance things out :) >>> | >>> | I discussed the proposal with Edward Kmett who suggested an example >>> with >>> | prisms and that I contact you two for comments. The syntax is still in >>> | flux. >>> | >>> | Some motivating examples for your consideration. >>> | >>> | PRISM PATTERNS >>> | >>> | Edward suggested a pattern to match a prism which would look like >>> this: >>> | <edwardk> an example where you want it is if you want to use a pattern >>> | synonym to match a prism <edwardk> foo (Match _Left a) = ... >>> | [...] >>> | <edwardk> the example of a single pattern that can match every prism >>> | would be a nice example >>> | >>> | which would be quite easy to implement: >>> | >>> | | pattern Match prism a ← ((^? prism) → Just a) >>> | | >>> | | bar :: Either c (Either a b) → a >>> | | bar (Match (_Right._Left) a) = a >>> | | bar _ = error "Not a Right (Left ...)" >>> | >>> | This can be used for any prism: >>> | | jsonBlob = "[{\"someObject\": {\"version\": [1,0,3]}}]" >>> | | >>> | | foo (Match (nth 0) (Match (key "someObject") (Match (key "version") >>> | (Match (nth 1) a)))) = a >>> | | ghci> foo jsonBlob >>> | | Number 0.0 >>> | >>> | and defining more specilized patterns we can make it terser: >>> | | pattern Get i a ← ((^? nth i) → Just a) pattern Key str a ← ((^? key >>> | | str) → Just a) >>> | | >>> | | baz (Get 0 (Key "someObject" (Key "version" (Get 1 a)))) = a baz (0 >>> | | `Get` "someObject" `Key` "version" `Key` 1 `Get` a) = a baz (a :→ >>> | | "someObject" :⇒ "version" :⇒ 1 :→ a) = a >>> | where >>> | | pattern i :→ a ← Get i a >>> | | pattern str :⇒ a ← Key str a >>> | >>> | So this is excellent for pattern matching on any sort of nested >>> | structure: records, JSON, XML, HTML, ASTs, … Since this also supports >>> | pattern matching on any value that satisfies a predicate. >>> | >>> | N+K PATTERNS >>> | Generalizing n+k patterns: We create a pattern family indexed by its >>> | first argument: >>> | >>> | | pattern (a :+) :: Num a ⇒ a → a >>> | | k :+ n ← (unSucc k → Just n) -- [1] unSucc defined >>> below >>> | >>> | where (a :+) indicates that 'k' is an index of the pattern family >>> | allowing it to be supplied to the view pattern. >>> | The pattern can be used as follows: >>> | | fact 0 = 1 >>> | | fact m@(1 :+ n) = m * fact n >>> | >>> | PATTERN MATCHING REGULAR EXPRESSIONS The pattern (:=~) is inspired >>> | by the operator (=~) from Text.Regex.Posix.Wrap (regex-posix), note >>> that >>> | its second argument is the index here: >>> | | pattern (:=~ String) :: RegexContext Regex a c ⇒ a → c >>> | | n :=~ pattern ← ((=~ pattern) → n) >>> | >>> | Used as: >>> | | vowels :: RegexContext Regex src tgt ⇒ src → tgt vowels (n :=~ >>> | | "[aeiou]") = n >>> | | >>> | | ghci> vowels "honorificabilitudinitatibus" ∷ Int >>> | | 13 >>> | >>> | where you can of course pattern match on the resulting value: >>> | >>> | | has5Vowels :: String → Int >>> | | has5Vowels (5 :=~ "[aeiou]") = True >>> | | has5Voewls _ = False >>> | >>> | TYPE INFERENCE >>> | Here is an example of a snippet inferring the type of an if >>> expression: >>> | >>> | | infer Γ (If cond t e) = >>> | | case (infer Γ cond, infer Γ t, infer Γ e) of >>> | | (Just TBool, Just τ₁, Just τ₂) >>> | | | τ₁ == τ₂ = Just t₁ >>> | >>> | Here is how it might look with pattern families: >>> | >>> | | infer Γ (If (Infer Γ TBool) (Infer Γ τ₁) (Infer Γ τ₂)) >>> | | | τ₁ == τ₂ = Just τ₁ >>> | >>> | (or even nicer if we use (:⇑) = Infer) >>> | | infer Γ (If (Γ :⇑ TBool) (Γ :⇑ τ₁) (Γ :⇑ τ₂)) … >>> | >>> | IMPLEMENTATION >>> | From what I can see this is a relatively straight-forward translation >>> | into view patterns where a variable bound by a view pattern is an >>> | “index” to the pattern family and unbound variables are regular >>> | patterns. In the examples above I use special syntax for the index >>> where >>> | the type is included but even without any annotation it can be >>> inferred >>> | from context. >>> | >>> | If the proposal is fine by you I offer to do the implementation work, >>> | all feedback welcome! >>> | >>> | Best regards, >>> | Baldur Blöndal >>> | >>> | APPENDIX >>> | | unSucc :: Int → Int → Maybe Int >>> | | unSucc k n >>> | | | n - k < 0 = Nothing >>> | | | otherwise = Just (n - k) >>> | | >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >

1 0

TypeLits question, how to build a Type Application with Symbol index
by Gabor Greif 28 Jun '14

28 Jun '14

Hello devs, I have {{{ data D (n :: Symbol) }}} in my module, and I want to obtain a type {{{ D "YAY!" }}} programmatically. Where can I find code that performs this (or something similar)? 1) I have to look up |D| in the current TyEnv (what if it is in a specific module?), 2) I have to build the type index (of kind Symbol), this involves FastString, looks non-trivial, 3) Apply 1) on 2), this is easy. Any hints welcome! Thanks and cheers, Gabor PS: some morsels I have so far: for 1) compiler/prelude/PrelNames.lhs:gHC_GENERICS = mkBaseModule (fsLit "GHC.Generics")

2 3

Cabal for GHC 7.8
by Manuel M T Chakravarty 28 Jun '14

28 Jun '14

I noticed that the Cabal package doesn’t have a branch for ghc-7.8: http://git.haskell.org/packages/Cabal.git Is that intended? Maybe as a result the instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources to check out a branch from the *GitHub mirror repos* doesn’t work either. It fails with == running git submodule update Cloning into 'libraries/Cabal'... fatal: remote error: ghc/packages/Cabal is not a valid repository name Email support(a)github.com for help Clone of 'git@github.com:ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed git failed: 256 at ./sync-all line 122. Manuel

3 3

Re: Make -fno-write-interface to all modes of GHC, not just -fno-code.
by Joachim Breitner 27 Jun '14

27 Jun '14

Hi, it seems that commit 05120ecd95b2ebf9b096a95304793cd78be9506e Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> Date: Fri Jun 27 13:48:19 2014 +0100 Make -fno-write-interface to all modes of GHC, not just -fno-code. Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> broke stuff: libraries/base/GHC/IO.hs-boot:6:1: Failed to load interface for â€˜GHC.Typesâ€™ There are files missing in the â€˜ghc-primâ€™ package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/base/dist-install/build/GHC/IO.o-boot] Error 1 make[1]: *** Waiting for unfinished jobs.... libraries/ghc-prim/GHC/Classes.hs:24:1: Failed to load interface for â€˜GHC.Magicâ€™ It is a member of the hidden package â€˜ghc-primâ€™. Use -v to see a list of the files searched for. libraries/ghc-prim/GHC/Classes.hs:26:1: Failed to load interface for â€˜GHC.Tupleâ€™ It is a member of the hidden package â€˜ghc-primâ€™. Use -v to see a list of the files searched for. libraries/ghc-prim/GHC/Classes.hs:27:1: Failed to load interface for â€˜GHC.Typesâ€™ It is a member of the hidden package â€˜ghc-primâ€™. Use -v to see a list of the files searched for. make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Classes.o] Error 1 (https://s3.amazonaws.com/archive.travis-ci.org/jobs/28588528/log.txt) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

RE: Haskell on windows 7 installation instructions
by Simon Peyton Jones 27 Jun '14

27 Jun '14

Very helpful Artella. Your page is about *using* Haskell or GHC on Windows. That is usefully distinct from how to *build* GHC on Windows; there is a separate page on the Trac wiki about that. I’ve added a clarifying sentence to your page, and added links from each to the other. I’m cc’ing a few others who have Windows knowledge. I would love it if you guys formed a GHC-on-Windows Task Force, who tried to make sure that the Windows experience was always good. At the moment we have lots of Windows users but very few who are willing to help make it work, the recipients of this email being honourable exceptions. Simon From: Artella Coding [mailto:artella.coding@googlemail.com] Sent: 25 June 2014 11:54 To: Simon Peyton Jones Subject: Haskell on windows 7 installation instructions Hi, I saw the installation instructions in http://www.gundersen.net/haskell-on-windows/ which cover installing in windows with msys (you suggested to the author that he put the instructions up on haskellwiki). However I wanted to install with the newer msys2 (which allows copying and pasting) and had quite a few problems initially (especially when trying to build hoogle). I have worked out all the issues, and have taken the liberty of writing the instructions at : http://www.haskell.org/haskellwiki/Windows which might require further editing. It took me a whole week to sort this out and thought it might be of help to others. I found that if you don't define the MSYSTEM environment variable (if you use the "msys2_shell.bat" instead of the "mingw32_shell.bat" or "mingw64_shell.bat" then this environment variable is not defined), then when you build hoogle you get some strange linker error messages https://github.com/haskell/cabal/issues/1950 . I didnt want to make the instructions too long, so omitted any explanation of why this environment variable is needed. Cheers

1 0

Pruning GADT case alternatives with uninhabitable coercion parameters
by Conal Elliott 26 Jun '14

26 Jun '14

I'm looking for tips on pruning away impossible branches in `case` expressions on GADTs, due to uninhabited coercion parameter types. Here's a simple example (rendered by HERMIT) from a type-specializion of the Foldable instance a GADT for perfect leaf trees in which the tree depth is part of the type: > case ds of wild (Sum Int) > L (~# :: S (S Z) ~N Z) a1 -> f a1 > B n1 (~# :: S (S Z) ~N S n1) uv -> ... Note the kind of the coercion parameter to the leaf constructor (`L`): `S (S Z) ~N Z`, i.e., 2 == 0. I think we can safely remove this branch as impossible. The reasoning gets subtler, however. After inlining and simplifying in the second (`B`) alternative, the following turns up: > case ds0 of wild0 (Sum Int) > L (~# :: n1 ~N Z) a1 -> f0 a1 > B n2 (~# :: n1 ~N S n2) uv0 -> ... Now I want to remove the first `L` alternative with `n1 ~ Z`, given that the kind `S (S Z) ~N S n1` is inhabited (since we're in the first `B` alternative), so that `n1 ~ S Z`. With more inlining, more such equalities pile up. Soon we get to an impossible `B` alternative, whose removal would then eliminate the rest of the recursive unfolding. My questions: * Does this sort of transformation already live in GHC somewhere, and if so, where? * Are there gotchas / sources of unsoundness in the transformation I'm suggesting? * Is anyone else already working on this sort of transformation? -- Conal

3 6

2nd call for contributions: Haskell Implementors' Workshop 2014
by Jost Berthold 26 Jun '14

26 Jun '14

Dear fellow Haskellers, We are 20 days away from the deadline for HIW 2014. If you have an exciting topic you would like to present, please propose a talk by submitting an abstract (through easychair, see below). Best regards Jost Berthold ==================================================================== Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2014 Gothenburg, Sweden, 06 September, 2014 Co-located with ICFP 2014 http://www.icfpconference.org/icfp2014/ Important dates --------------- Proposal Deadline: Monday, 14 July, 2014 (anywhere on earth) Notification: 21 July 2014 Workshop: Saturday, 6 September 2014 The 6th Haskell Implementors' Workshop is to be held alongside ICFP 2014 this year in Gothenburg. 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 a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Attendance figures clearly reflect the growth of the Haskell user community and a constant interest in implementation aspects. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2014. 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. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. 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 ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 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 should be made via EasyChair. The website is: https://www.easychair.org/conferences/?conf=hiw2014 If you don't have an account you can create one here: https://www.easychair.org/account/signup.cgi Because the submission is an abstract only, please click the "abstract only" button when you make your submission. There is no need to attach a separate file. We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. 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. Organisers ---------- * Jost Berthold (co-chair) (University of Copenhagen) * Kevin Hammond (University of St.Andrews) * Gabriele Keller (University of New South Wales) * Paul Liu (Intel Labs) * Rita Loogen (Philipps-Universitat Marburg) * Geoffrey Mainland (co-chair) (Drexel University, Philadelphia) * Carter Schonwald (WellPosed Ltd) Contact ------- * hiw2014(a)easychair.org * Jost Berthold <berthold at di.ku.dk> * Geoffrey Mainland <mainland at cs.drexel.edu>

1 0

Interesting whoCreated output (stack trace related)
by Ömer Sinan Ağacan 25 Jun '14

25 Jun '14

Hi all, I'm running this program: {-# LANGUAGE DeriveDataTypeable, ScopedTypeVariables #-} import GHC.Stack import Control.Exception.Base import Data.Typeable data MyException = MyException deriving (Show, Typeable) instance Exception MyException err1 :: IO Integer err1 = {-# SCC error1 #-} err2 >>= return err2 :: IO Integer err2 = {-# SCC error2 #-} throw MyException main = print =<< whoCreated =<< catch err1 =<< (\(_ :: MyException) -> return (42 :: Integer)) I'd expect `whoCreated` to return something like [Main.CAF, Main.main, Main.main.\] but instead this is the output: ["Main.CAF (<entire-module>)","Main.err2 (ioerr.hs:14:1-43)","Main.error2 (ioerr.hs:14:27-43)","Main.main (ioerr.hs:16:1-103)","Main.main.\\ (ioerr.hs:16:81-102)"] This output has two things that look somewhat weird to me. First, I'd expect cost-centre stack to be restored when exception is catched and then program would produce shorter stack trace like I mentioned above.(without err1 or err2 calls) Second, when no cost-centre restoring is done, I'd expect stack trace to include `Main.err1` and `Main.error1`. So can anyone explain my why stack trace contains err2 calls but not err1 calls? I think none of error1 and error2 should have been included in the stack trace or both of them should have been included. Thanks. --- Ömer Sinan Ağacan http://osa1.net

2 1