- ghc-devs - Haskell.org

Is there a stable URL for the latest GHC library haddocks?
by Howard B. Golden 25 Aug '16

25 Aug '16

Hi, In https://wiki.haskell.org/Unboxed_type I noticed a broken link to the latest library Haddock for GHC-Exts: http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Exts.html This link doesn't work because the version of base is omitted, but that will change over time. It works (at the moment) as: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.9.0.0/GHC-Exts… Is there some stable URL that can be used in the wiki or other documentation to reference GHC library haddocks? Howard

1 0

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