- ghc-devs - Haskell.org

Using stringize and string concatenation in ghc preprocessing
by Harendra Kumar 22 Aug '16

22 Aug '16

Hi, To reduce boilerplate code in an FFI implementation file I am trying to use the stringizing and string concatenation features of the C preprocessor. Since ghc passes '-traditional' to the preprocessor which disables these features I thought I can pass my own flags to the preprocessor like this: {-# OPTIONS_GHC -optP -E -optP -undef #-} But "-optP" seems to only append to the flags that GHC already passes and gcc has no "-no-traditional" option to undo the effect of the "-traditional" that GHC has already passed. I think "-optP" should override the flags passed by ghc rather than appending to them. Is there a reason not to do that? Is there any other better way to achieve this? What is the standard way of doing this if any? -harendra

3 4

GHC-related project for undergraduate thesis
by Eugene Akentyev 20 Aug '16

20 Aug '16

(forwarded from haskell-cafe) Hello, I am an undergraduate student and would like to do something useful for GHC as undergraduate thesis. This list https://ghc.haskell.org/trac/ghc/wiki/ProjectSuggestions is outdated (last modified 6 years ago) and some projects are already done (?). Do you have any ideas/projects? Thanks.

2 1

Re: ghc command line arguments parsing
by Harendra Kumar 19 Aug '16

19 Aug '16

On 18 August 2016 at 20:51, Sven Panne <svenpanne(a)gmail.com> wrote: > 2016-08-17 16:37 GMT+02:00 Harendra Kumar <harendra.kumar(a)gmail.com>: > >> ghc accepts a flag and its argument as a single quoted or escaped >> argument as well. For example all of the following are equivalent: >> >> ghc -package foo >> ghc "-package foo" >> ghc -package\ foo >> >> Is this by design or accidental? >> > > I would call this a bug, probably some missing quoting somewhere: Most > commands I know don't do splitting on the arguments for themselves. Just > try e.g. > > gcc "-v -v" > Initially I too thought the same but then I did some more testing and it turned out that the way ghc does not really parse it exactly in the same way as independent unquoted arguments. It only parses a flag which takes an argument. For example: ghc "-package foo" -- parses foo as an argument to the -package flag ghc "-package foo -v" -- is not the same as "-package foo" and "-v" arguments passed independently, it is "foo -v" as the argument to "-package" So it essentially allows packing a flag and its argument together. Which provides a nice way to pass flags and their values as a single unit. This may be accidental to begin with but I liked this just because it makes passing opaque flags combined with arguments from a wrapper program like runghc much more convenient. I cannot think of any downside of this behavior unless someone points out otherwise. > >> This has a nice side effect to make passing ghc arguments via rughc >> simple. For example runghc "-package foo" or runghc -package\ foo will pass >> "-package foo" to ghc. The alternative and documented way to achieve the >> same effect is runghc -package --ghc-arg=foo which is not that convenient. >> >> My question is - can we rely on this way of parsing? If it is not by >> design, does it make sense to legalize and therefore document this? >> > > And my question is: Can we fix this bug? :-D If this is not considered a > bug, we should be very explicit about this deviation from standard behavior > in the documentation, including the reasons for it. > As I explained above, I would prefer to keep this bug :-) and document it especially for runghc as a better alternative to --ghc-arg=foo . So instead of saying: runghc -package --ghc-arg=text -package --ghc-arg=turtle hello.hs We can just say: runghc "-package text" "-package turtle" hello.hs -harendra

2 4

Landing Backpack in HEAD
by Edward Z. Yang 19 Aug '16

19 Aug '16

Hello friends, I'm hoping to land Backpack (the patch is two years in the making now!) for GHC 8.2, even though 8.2 is intended to be a stabilization and performance release. In this email, I will make the case that the Backpack patch is relatively self-contained and will not affect non-Backpack users, and explain how you might be affected by the patch. The most recent patchset can be found at https://github.com/ezyang/ghc/tree/ghc-backpack ; look for "The Backpack patch" in the commit log, since I plan on squashing these commits before committing. OK, here is what is in the patchset that affects non-Backpack users: - The primary, overarching change is that there is now a distinction between "semantic" and "identity" modules. This solves a problem with hsig files: suppose you have A.hsig which defines data T in package p. The resulting A.hi is most accurately identified as p[A=<A>]:A; however, the Name for T should be <A>.T, not p[A=<A>]:A.T. The former is an identity module (it *identifies* interfaces), whereas the latter is a semantic module (it is what is used in names). Without Backpack, these two identities are always the same. There are a number of places in the existing codepaths where we have to distinguish between the two concepts (sometimes you want semantic, sometimes you want identity); we DEFAULT to the identity module but I fix a few cases where semantic modules were desired instead. - UnitId is generalized to also record how a component is instantiated (a mapping from module names to modules.) Without Backpack this is blank and equivalent to the existing UnitId. - Packages has been refactored to also handle Backpack `-unit-id` flags, since we have to do some extra work to determine what inherited signatures merge where. - The patch REVERTS all of the old support we had for hsig files; -sig-of is no more. spinda had mentioned that Liquid Haskell used this in some cases, and I'm looking at supporting *just* their particular use-case. - A new driver mode --backpack, which process test.bkp files. This mode is used PURELY for testing, and end users are not supposed to use it. These all live in their own modules (BkpSyn, DriverBkp) except for some modest, convenient extensions to the lexer and parser to parse multiple modules at once. The patch also comes with rewritten typechecking support for hsig files, and instantiating indefinite packages on the fly, but these are all standalone pieces of functionality which are not tied to any existing compiler infrastructure. Thanks, Edward

3 2

Request for feedback: deriving strategies syntax
by Ryan Scott 18 Aug '16

18 Aug '16

I'm pursuing a fix to Trac #10598 [1], an issue in which GHC users do not have fine-grained control over which strategy to use when deriving an instance, especially when multiple extensions like -XGeneralizedNewtypeDeriving and -XDeriveAnyClass are enabled simultaneously. I have a working patch up at [2] which would fix the issue, but there's still a lingering question of what the right syntax is to use here. I want to make sure I get this right, so I'm requesting input from the community. To condense the conversation in [1], there are three means by which you can derive an instance in GHC today: 1. -XGeneralizedNewtypeDeriving 2. -XDeriveAnyClass 3. GHC's builtin algorithms (which are used for deriving Eq, Show, Functor, Generic, Data, etc.) The problem is that it's sometimes hard to know which of the three will kick in when you say `deriving C`. To resolve this ambiguity, I want to introduce the -XDerivingStrategies extension, where a user can explicitly request which of the above ways to derive an instance. Here are some of the previously proposed syntaxes for this feature, with their perceived pros and cons: ----- Pragmas * Examples: - newtype T a = T a deriving ({-# BUILTIN #-} Eq, {-# GND #-} Ord, {-# DAC #-} Read, Show) - deriving {-# BUILTIN #-} instance Functor T * Pros: - Backwards compatible - Requires no changes to Template Haskell * Cons: - Unlike other pragmas, these ones can affect the semantics of a program ----- Type synonyms * Examples: - newtype T a = T a deriving (Builtin Eq, GND Ord, DAC Read, Show) - deriving instance Builtin (Functor T) * Pros: - Requires no Template Haskell or parser changes, just some magic in the typechecker - Backwards compatible (back to GHC 7.6) * Cons: - Some developers objected to the idea of imbuing type synonyms with magical properties ----- Multiple deriving clauses, plus new keywords * Examples: - newtype T a = T a deriving Show deriving builtin instance (Eq, Foldable) deriving newtype instance Ord deriving anyclass instance Read - deriving builtin instance Functor T * Pros: - Doesn't suffer from the same semantic issues as the other suggestions - (Arguably) the most straightforward-looking syntax * Cons: - Requires breaking changes to Template Haskell - Changes the parser and syntax significantly Several GHC devs objected to the first two of the above suggestions in [1], so I chose to implement the "Multiple deriving clauses, plus new keywords" option in [2]. However, I'd appreciate further discussion on the above options, which one you prefer, and if you have other suggestions for syntax to use. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/10598 [2] https://phabricator.haskell.org/D2280

15 29

Suggesting RankNTypes for ill-formed types
by Karolina Drobnik 18 Aug '16

18 Aug '16

Hello everyone, I am working on my first ticket (#11669, linked below) and I have some doubts after a little bit of hacking. There was a hint that an error message should be changed from the one suggesting RankNTypes to ExplicitForall. In my opinion it would be quite confusing for the user, especially where the type is ill-formed. A plain parse error should be shown here. It is clear that it should be done in such a way after turning on one of the extensions, but what about the situation where proposed fix (suggesting RankNTypes/ExplicitForall) won't work? We should be able to distinguish ill-formed type from the correct one, even before the extension activation. To be honest - I don't know how to do it. Additionally, I am not sure if we can assume that an user wants to use arbitrary rank (which implies ExplicitForall) or just a forall keyword. I am for the second one, but it is just my assumption. And the last minor thing - a type formed in this way also rises an error suggesting using RankNTypes (as we know that wouldn't solve the problem): f :: a. -> Int f = undefined Maybe we could treat it as a typo (simple parse error) and propose an extension activation only when forall was parsed earlier? That could be tricky. I'd appreciate some thoughts on this issue because I felt a bit lost after digging around the parser. Best regards, Karolina --------------------------------------------------------- #11669 - https://ghc.haskell.org/trac/ghc/ticket/11669

4 3

Broken Build due to T1969
by Matthew Pickering 17 Aug '16

17 Aug '16

Hi all, https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 broke the build by re-enabling the test T1969 The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437 Omer: Is it best to revert this patch and mark the test broken again? Matt

2 5

Back from move
by Ben Gamari 17 Aug '16

17 Aug '16

Hello everyone! If I have seemed quiet over the last few weeks it is because I was in the middle of a trans-Atlantic move to the United States. Needless to say, I am now somewhat settled again and will be working through my mail backlog over the next day or so. If you have sent something that you'd like a response from me on and I don't reply within the next day don't hesitate to ping me. Cheers, - Ben

1 0

ghc command line arguments parsing
by Harendra Kumar 17 Aug '16

17 Aug '16

Hi, ghc accepts a flag and its argument as a single quoted or escaped argument as well. For example all of the following are equivalent: ghc -package foo ghc "-package foo" ghc -package\ foo Is this by design or accidental? This has a nice side effect to make passing ghc arguments via rughc simple. For example runghc "-package foo" or runghc -package\ foo will pass "-package foo" to ghc. The alternative and documented way to achieve the same effect is runghc -package --ghc-arg=foo which is not that convenient. My question is - can we rely on this way of parsing? If it is not by design, does it make sense to legalize and therefore document this? -harendra

1 0

Question about initializing the run-time system
by Iavor Diatchki 17 Aug '16

17 Aug '16

Hello, GHC's user guide says that the run-time system cannot re-initialize itself, after it was shut-down (i.e., you can't call `hs_init` after calling `hs_exit`). Could anyone shed some light on why that is? -Iavor

2 1