- ghc-devs - Haskell.org

RE: ExtraCommas
by Simon Peyton Jones 13 Oct '14

13 Oct '14

| What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where No. I'm proposing this. Insetad of data HsRecFields id = HsRecFields { rec_flds :: [HsRecField id arg], rec_dotdot :: Maybe Int have this: data HsRecFields id = HsRecFields { rec_flds :: HsCommaList (HsRecField id arg), rec_dotdot :: Maybe Int data HsCommaList a = Empty | ExtraComma (HsCommaList a) | Cons a (HsCommaList a) So that HsCommaList a is very like [a] but can express precisely where the extra commas appear. Now adapt the parser to produce a (HsCommaList (HsRecField RdrName (LHsExpr RdrName))), rather than a list of those things. The renamer then complains if it finds any ExtraComma constructors, unless the -XExtraCommas is specified. Does that help? Simon | -----Original Message----- | From: Alexander Berntsen [mailto:alexander@plaimi.net] | Sent: 23 September 2014 10:40 | To: Simon Peyton Jones | Subject: Re: ExtraCommas | | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA256 | | On 23/09/14 11:28, Simon Peyton Jones wrote: | > My advice was only: parse commas *always* as if they were part of | the | > language. (So the parser has no conditinoals.) Reject them later (in | > the renamer) if the language extension is not enabled. | I don't understand this. From my limited understanding commas are | lexed, and then I can, in the parser, pattern match on things. Here's | a very specific example, record field update/construction: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbinds1 { $1 } | | {- empty -} { ([], False) } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of (flds, dd) -> | ($1 : flds, dd) } | | fbind { ([$1], False) } | | '..' { ([], True) } | | What's happening here is that fbinds uses a helper fbinds1, to capture | both fbinds1 & emptys. So to add support for leading/trailing commas, | what I did is simply pattern match on them: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : ',' fbinds1 { $2 } | | fbinds1 { $1 } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of | (flds, dd) -> ($1 : flds, dd) | } | | fbind { ([$1], False) } | | '..' { ([], True) } | | {- empty -} { ([], False) } | | You can observe that I am now using fbinds to capture ',' fbinds1, and | have moved the empty match to fbinds1 itself. | | This is the general pattern I have used for all of my patches so far. | | | What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where | this is meant to happen. And it also sounds like your suggestion will | mean I need to handle the case where extra commas are *not* supposed | to be handwaved, like tuples. So please elaborate, if you can. | | > Happy to talk. I'm simonpj0 on skype. | Do you happen to use any non-proprietary tool or at least protocol? | - -- | Alexander | alexander(a)plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhP9sACgkQRtClrXBQc7U0+gD/TvT+9iVA6JqiopTfeYEc7NU2 | USD2bf+bKwhy9MNUjssA/3YUjA3PVYRpw1RFoRQF15zBFF6WDH5PQbS/8/5q7h+P | =saJc | -----END PGP SIGNATURE-----

3 2

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 13 Oct '14

13 Oct '14

Ok, will do. An integer can potentially have any number of leading zeros, and I will have to check what escaping exists in the others. On Mon, Oct 13, 2014 at 11:33 AM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.9 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: D297 | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > I suggest doing so only if the two can differ. In the case of `String` > there can be string gaps, thus > {{{ > foo :: String > foo = "blah blah\ > \more blah blah\ > \and more" > }}} > and I guess you want to have all that layout reproduced. Fine. But for > integers like `3234242329423`, I don't see how the displayed form could > differ. > > For `Words` perhaps there is binary/hex forms? > > Regardless, I'm not against this, but very keen that the reasons for > keeping the two are documented on a per-literal basis, as I have begun to > do above. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:29> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

GHC HEAD breakage by pthread_setname_np usage.
by Karel Gardas 13 Oct '14

13 Oct '14

Hello Simon, I'm sorry to disturb you, but your recent patch: commit 674c631ea111233daa929ef63500d75ba0db8858 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Fri Oct 10 14:26:19 2014 +0100 Name worker threads using pthread_setname_np This helps identify threads in gdb particularly in processes with a lot of threads. breaks build on FreeBSD and Solaris at least. The problem is that pthread_setname_np is GNU extension and so far I've seen it just in linux using glibc >=2.12, modern NetBSD and modern QNX. Builds on Solaris and FreeBSD result in unresolved symbol failure. Two examples showing this are here: http://haskell.inf.elte.hu/builders/smartos-x86-head/147/10.html http://haskell.inf.elte.hu/builders/freebsd-amd64-head/411/10.html The problem is that I cannot simply #ifdef usage of this since it's using `name' parameter of the createOSThread function and if I #ifdef this, then the compiler emits obvious warning: rts/posix/OSThreads.c: In function ‘createOSThread’: rts/posix/OSThreads.c:132:40: warning: unused parameter ‘name’ which is probably going to break validate build which builds with -Werror. Perhaps if pthread_setname_np is not available on the target platform we can define it ourself (as empty macro or inline function doing nothing?) and use that, but in this case we would probably need proper configure check for the presence of this function. As rts is your domain, I'm just writing this in a hope that you will either revert the patch for now or solve it in a way you like. Thanks! Karel

2 1

RE: Building ghc on Windows with msys2
by Tamar Christina 13 Oct '14

13 Oct '14

Hi Gintautas, This seems like a good idea to me. I was also wondering would it be a good idea to have configure also handle cabal/happy/alex in a similar way? It would be another step you don't manually have to do and would make it easier to insure that the right versions are installed. Regards, Tamar ------------------------------ From: Gintautas Miliauskas <gintautas(a)miliauskas.lt> Sent: ‎13/‎10/‎2014 00:06 To: kyra <kyrab(a)mail.ru> Cc: ghc-devs(a)haskell.org Subject: Re: Building ghc on Windows with msys2 > However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on > Windows than 4.8.3. 'Mingw-builds' project (which is now a part of > mingw-w64 project and is considered to be an "official" mingw-w64 gcc > distribution and is maintained by a man close to Msys2 project) has very > nice and complete build of 4.8.3 (64-bit build, for example, is here: > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting% > 20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/). > I am looking into migrating ghc to the newer gcc package linked above. There is also the associated question of what to do with ghc-tarballs. Here's an idea: how about downloading the mingw package directly from sourceforge at configure time with curl/wget? That should work pretty well. I see two potential issues: 1. URL stability. The sourceforge repo is not in our control and files in it could go away any time. The repo seems stable though, with some files from 2011. If we're concerned about this, copying the file to a domain under our control should not be a problem. I did not get any responses about who to contact about that though... 2. Download failing due to internet connectivity issues or missing proxy configuration. This could easily be addressed by printing a message with a URL and a filesystem location to put the file in the case that the download fails. If there are no objections, I'll proceed with whipping up a patch. -- Gintautas Miliauskas

1 0

Problems adding a custom section to a Windows binary
by Gintautas Miliauskas 13 Oct '14

13 Oct '14

This is slightly offtopic, but maybe some of the Windows folks know an answer to this question. I've been working on #9686 <https://ghc.haskell.org/trac/ghc/ticket/9686>, but have been blocked by Windows rejecting all my attempts to add a custom section to a binary withthe error "bash: ./c.exe: cannot execute binary file: Exec format error". I'm not sure if this is a gcc/binutils bug or not (the exact same commands with the same tools work fine on Linux binaries). I have filed http://sourceforge.net/p/mingw/bugs/2239 and https://sourceware.org/bugzilla/show_bug.cgi?id=17466 to see what the developers say, but have not gotten a response yet. Perhaps someone here knows what's going on? -- Gintautas Miliauskas

3 2

msys2 python2 for running tests
by Gintautas Miliauskas 12 Oct '14

12 Oct '14

Hi Herbert, I saw your comment on the Windows build page about msys2's python2. It used to be broken, a patch of mine recently went through to fix the problem. If you can verify that msys2's python2 works correctly for the entire test suite, feel free to update the instructions <https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows> accordingly. Also, it looks like you added a section for setting up sshd on msys2. I think it's great, but I don't think it should be on the main ghc build page, it's just a separate concern (and it's also interesting not just to people building ghc). Would you mind moving that text off to a separate wikipage and adding a link to it instead? -- Gintautas Miliauskas

1 0

Curious Windows GHCi linker behaviour .o vs. .dll
by Herbert Valerio Riedel 12 Oct '14

12 Oct '14

Hello *, I assume this is a well known issue to MSYS2/Windows developers, so I hope somebody may be able to provide more insight for me to better understand the underlying problem of https://github.com/haskell/time/issues/2 So the prototype for tzset() is simply void tzset(void); and it's defined in `msvcrt.dll` as far as I can tell; Consider the following trivial program: module Main where foreign import ccall unsafe "time.h tzset" c_tzset :: IO () main :: IO() main = c_tzset When compiled with GHC 7.8.3, the resulting executable works and has the following tzset-symbols: $ nm tz.o | grep tzset U tzset $ nm tz.exe | grep tzset 000000000050e408 I __imp_tzset 00000000004afc40 T tzset However, when loaded into GHCi, the RTS linker fails to find `tzset`: $ ghci tz.hs WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( tz.hs, interpreted ) ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: tzset ... However, when I prefix a `_` to the symbol-name in the FFI import, i.e. foreign import ccall unsafe "time.h tzset" c_tzset :: IO () Now, GHCi happily loads the module and is apparently able to resolve the `tzset` symbol: $ ghci tz.hs WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( tz.hs, interpreted ) Ok, modules loaded: Main. *Main> Moreover, compiling and running the program still works, and the additional underscore is visible in `nm` as well: $ nm tz.o | grep tzset U _tzset $ nm tz.exe | grep tzset 000000000050e558 I __imp__tzset 00000000004b8050 T _tzset What's going on here? Why does one need to add an artificial underscore to FFI imported symbols for GHCi to resolve symbols? Is this a bug? Cheers, hvr

3 6

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 10 Oct '14

10 Oct '14

Ok, then I think the middle ground is keyword-specific annotations, as proposed by Neil. What should happen is that the raw annotations are used by a tool layer such as ghc-exactprint or HaRe, and other more casual users will not have to worry about the internal detail. On Fri, Oct 10, 2014 at 9:13 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.9 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: D297 | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > I don't have data, but people are already complaining about the amount of > code generated by data type declarations #9669. Have you counted how many > data constructors there are in `HsSyn`? It's a LOT. > > It just feels like a sledgehammer to crack a nut. > > Simon > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:21> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Capturing commas in Api Annotations (D297)
by Alan & Kim Zimmerman 10 Oct '14

10 Oct '14

I am currently working annotations into the parser, provided them as a separate structure at the end of the parse, indexed to the original by SrcSpan and AST element type. The question I have is how to capture commas and semicolons in lists of items. There are at least three ways of doing this 1. Make sure each of the items is Located, and add the possible comma location to the annotation structure for it. This has the drawback that all instances of the AST item annotation have the possible comma location in them, and it does not cope with multiple separators where these are allowed. 2. Introduce a new hsSyn structure to explicitly capture comma-separated lists. This is the current approach I am taking, modelled on the OrdList implementation, but with an extra constructor to capture the separator location. Thus ``` data HsCommaList a = Empty | Cons a (HsCommaList a) | ExtraComma SrcSpan (HsCommaList a) -- ^ We need a SrcSpan for the annotation | Snoc (HsCommaList a) a | Two (HsCommaList a) -- Invariant: non-empty (HsCommaList a) -- Invariant: non-empty ``` 3. Change the lists to be of type `[Either SrcSpan a]` to explicitly capture the comma locations in the list. 4. A fourth way is to add a list of SrcSpan to the annotation for the parent structure of the list, simply tracking the comma positions. This will make working with the annotations complicated though. I am currently proceeding with option 2, but would appreciate some comment on whether this is the best approach to take. Option 2 will allow the AST to capture the extra commas in record constructors, as suggested by SPJ in the debate on that feature. Regards Alan

2 3

Again: Uniques in GHC
by p.k.f.holzenspies＠utwente.nl 10 Oct '14

10 Oct '14

Dear all, I *finally* had some time again to look at how to properly redo Uniques in GHC. A few things stood out to me: - The export-list of Unique has some comments stating that function X is only exported for module Y, yet is used elsewhere. This may be because these comments do not show up in haddock etc. leading some people to think they're up for general use. In my refactoring, I'm sticking the restriction in the function name, so it's no longer mkUniqueGrimily, but rather mkUniqueOnlyForUniqSupply (making the name even longer should discourage their use more). If at all possible, these should be removed altogether asap. - The implementation is based on FastInts, which, on most machines nowadays, is a 64-bit thing. The serialisation in BinIface is explicitly based on Word32s. Aside from the obvious potential (albeit with a low probability) for errors, this lead me to wonder about 32/64-bitness. Is there a reason for 64-bit versions of GHC to write Word32s, or is this a historic thing? Must the interface-files be bit-compatible between different versions (32/64-bits) of the compiler? Lastly, is the choice of whether "this" is a 32 or 64-bit version completely determined by WORD_SIZE_IN_BITS (MachDeps.h)? - There are a few libraries that are explicitly dependent on GHC, yet have their own versions of Unique. So far, I've seen this for Hoopl and Template Haskell. They have unboxed ints to do the job. I have not researched whether they manipulate them in any way, or just store things. If the former; I would like to call to reconsider this, because it seems like a poor separation of concerns toe me. If the latter, I think refactoring them to use Unique instead of Int# should be straightforward. ? The point of refactoring Unique is to no longer have low-level optimisations of manually unpacking (and repacking using the MkUnique constructor), which should serve as a lovely test of how far the optimisations have come. Furthermore, it seemed that the use of characters to encode the domain was somewhat awkward, but I refer anyone interested to earlier posts on this list. Thoughts? Comments? Suggestions? Objections? Regards, Philip

7 18