August 2016 - ghc-devs

Rewrapping with simple bidirectional pattern synonyms
by David Feuer 24 Aug '16

24 Aug '16

I'm trying to write a bidirectional pattern synonym which is morally simple, but as far as I can tell there's no way to write it as a simple bidirectional pattern synonym. What I want to say is pattern TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) (where TSnocList and Dual are both newtype constructors) But I don't see a way to do it without being explicitly bidirectional: pattern TSnoc xs x <- (tsViewR -> ViewR xs x) where TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs) tsViewR :: TSnocList c x y -> ViewR c (TSnocList c) x y tsViewR (TSnocList CL.TNil) = EmptyR tsViewR (TSnocList (CL.TCons (Dual x) xs)) = ViewR (TSnocList xs) x Would it be possible to make this simple thing simple?

3 3

Errors when building users guide
by Harendra Kumar 23 Aug '16

23 Aug '16

I see errors like this when using 'make html' in the topdir of the ghc repo: ---- /vol/hosts/cueball/workspace/github/ghc/docs/users_guide/flags.rst:15: SEVERE: Problems with "include" directive path: InputError: [Errno 2] No such file or directory: 'docs/users_guide/flags-verbosity.gen.rst'. ---- What am I doing wrong or not doing? -harendra

2 5

Style or bug in user manual?
by Harendra Kumar 22 Aug '16

22 Aug '16

I was working to fix some documentation and noticed that the user manual lists options like this: -package⟨pkg⟩ Notice that there is no space between the argument and the option. Should this be fixed? All options on this page seem to be similarly formatted which makes me wonder whether its by design? -harendra

2 2

SSH failing on Windows
by Simon Peyton Jones 22 Aug '16

22 Aug '16

I'm continuing the saga of setting up my lovely Surface Book. Succeeding, just, but see below. Now my problem is that 'git push' doesn't work. My 'pushurl' is pushurl = ssh://git@git.haskell.org/ghc.git which is correct I think. I have a .ssh directory set up, with a copy of all the files that used to work. But 'git push' says /c/code/HEAD$ git push Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. So presumably it's a ssh problem. Turned out (via ssh -v) that I was getting debug1: Skipping ssh-dss key /c/users/simonpj/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes I solved this by adding to .ssh/config the line PubkeyAcceptedKeyTypes +ssh-dss But I guess this is bad practice. How would I (a) generate RSA keys (b) push them to git.haskell.org (or wherever they need to go) Is there a wiki page describing this? The (b) part at least is GHC specific, as is the strange pushurl. Thanks Simon

3 4

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

22 Aug '16

Bardur, Since you don't like "bespoke", would you mind suggesting an alternative, or advocating for a previously mentioned idea? From [1], the ideas I've seen tossed around are: * builtin * standard (Elliot Cameron suggested it here [2]) * wiredin (Cater Schonwald suggested it here [3]) * magic (Andres Löh suggested it here [4]) * native * original * specialized (the above three are ad hoc suggestions I came up with in a hurry) Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategie… [2] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012448.html [3] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012450.html [4] https://mail.haskell.org/pipermail/ghc-devs/2016-July/012453.html

9 11

Moving ArgumentsDo forward
by Akio Takano 22 Aug '16

22 Aug '16

Hi, Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would love to see in GHC. It's a small syntactic extension that allows do, case, if and lambda blocks as function arguments, without parentheses. However, its differential revision [1] has been abandoned, citing a mixed response from the community. A message [2] on the ticket summarizes a thread in haskell-cafe on this topic. I, for one, think adding this extension is worthwhile, because a significant number of people support it. Also, given how some people seem to feel ambivalent about this change, I believe actually allowing people to try it makes it clearer whether it is a good idea. Thus I'm wondering: is there any chance that this gets merged? If so, I'm willing to work on whatever is remaining to get the change merged. Regards, Takano Akio [0]: https://ghc.haskell.org/trac/ghc/ticket/10843 [1]: https://phabricator.haskell.org/D1219 [2]: https://ghc.haskell.org/trac/ghc/ticket/10843#comment:12

7 11

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