Making GHCi awesomer?
Good evening, So I’ve been working on Haskell user-facing tooling in general for some years. By that I mean the level of Emacs talking with Haskell tools. I wrote the interactive-haskell-mode (most functionality exists in this file https://github.com/haskell/haskell-mode/blob/master/haskell-process.el#L1 ). which launches a GHCi process in a pipe and tries very earnestly to handle input/output with the process reasonably. For Emacs fanciers: Written in Elisp, there’s a nice command queue that you put commands onto, they will all be run on a FIFO one-by-one order, and eventually you’ll get a result back. Initially it was just me using it, but with the help of Herbert Riedel it’s now a mode on equal footing with the venerable inferior-haskell-mode all ye Emacs users know and love. It’s part of haskell-mode and can be enabled by enabling the interactive-haskell-mode minor mode. For years I’ve been using GHCi as a base and it’s been very reliable for almost every project I’ve done (the only exceptions are things like SDL and OpenGL, which are well known to be difficult to load in GHCi, at least on Linux). I think we’ve built up a good set of functionality https://github.com/haskell/haskell-mode/wiki/Haskell-Interactive-Mode purely based on asking GHCi things and getting it to do things. I literally use GHCi for everything. For type-checking, type info, I even send “:!cabal build” to it. Everything goes through it. I love my GHCi. Now, I’m sort of at the end of the line of where I can take GHCi. Here are the problems as I see them today: 1. There is no programmatic means of communicating with the process. I can’t send a command and get a result cleanly, I have to regex match on the prompt, and that is only so reliable. At the moment we solve this by using \4 (aka ‘END OF TRANSMISSION’). Also messages (warnings, errors, etc.) need to be parsed which is also icky, especially in the REPL when e.g. a defaulted Integer warning will mix with the output. Don’t get me started on handling multi-line prompts! Hehe. 2. GHCi, as a REPL, does not distinguish between stdout, stderr and the result of your evaluation. This can be problematic for making a smooth REPL UI, your results can often (with threading) be interspersed in unkind ways. I cannot mitigate this with any kind of GHCi trickery. 3. It forgets information when you reload. (I know this is intentional.) 4. Not enough information is exposed to the user. (Is there ever? ;) 5. There is a time-to-market overhead of contributing to GHCi — if I want a cool feature, I can write it on a locally compiled version of GHC. But for the work projects I have, I’m restricted to given GHC versions, as are other people. They have to wait to get the good features. 6. This is just a personal point — I’ve like to talk to GHCi over a socket, so that I can run it on a remote machine. Those familiar with Common Lisp will be reminded of SLIME and Swank. Examples for point 4 are: - Type of sub-expressions. - Go to definition of thing at point (includes local scope). - Local-scope completion. - A hoogle-like query (as seen in Idris recently). - Documentation lookup. - Suggest imports for symbols. - Show core for the current module. - Show CMM for the current module, ASM, etc. SLIME can do this. - Expand the template-haskell at point. - The :i command is amazingly useful, but programmatic access would be even better.¹ - Case split anyone? - Etc. ¹I’ve integrated with it in Emacs so that I can C-c C-i any identifier and it’ll popup a buffer with the :i result and then within that buffer I can drill down further with C-c C-i again. It makes for very natural exploration of a type. You’ve seen some of these features in GHC Mod, in hdevtools, in the FP Haskell Center, maybe some are in Yi, possibly also in Leksah (?). So in light of point (5), I thought: I’ve used the GHC API before, it can do interactive evaluation, why not write a project like “ghc-server” which encodes all these above ideas as a “drop-in” replacement for GHCi? After all I could work on my own without anybody getting my way over architecture decisions, etc. And that’s what I did. It’s here https://github.com/chrisdone/ghc-server. Surprisingly, it kind of works. You run it in your directoy like you would do “cabal repl” and it sets up all the extensions and package dependencies and starts accepting connections. It will compile across three major GHC versions. Hurray! Rub our hands together and call it done, right? Sadly not, the trouble is twofold: 1. The first problem with this is that every three projects will segfault or panic when trying to load in a project that GHCi will load in happily. The reasons are mysterious to me and I’ve already lugged over the GHC API to get to this point, so that kind of thing happening means that I have to fall back to my old GHCi-based setup, and is
Re: Making GHCi awesomer?
I think there is currently a more general interest in this, and the ghc-mod guys are thinking on similar lines, see https://github.com/kazu-yamamoto/ghc-mod/issues/349 Alan On Sat, Oct 18, 2014 at 5:48 PM, Christopher Done chrisd...@gmail.com wrote: Good evening, So I’ve been working on Haskell user-facing tooling in general for some years. By that I mean the level of Emacs talking with Haskell tools. I wrote the interactive-haskell-mode (most functionality exists in this file https://github.com/haskell/haskell-mode/blob/master/haskell-process.el#L1 ). which launches a GHCi process in a pipe and tries very earnestly to handle input/output with the process reasonably. For Emacs fanciers: Written in Elisp, there’s a nice command queue that you put commands onto, they will all be run on a FIFO one-by-one order, and eventually you’ll get a result back. Initially it was just me using it, but with the help of Herbert Riedel it’s now a mode on equal footing with the venerable inferior-haskell-mode all ye Emacs users know and love. It’s part of haskell-mode and can be enabled by enabling the interactive-haskell-mode minor mode. For years I’ve been using GHCi as a base and it’s been very reliable for almost every project I’ve done (the only exceptions are things like SDL and OpenGL, which are well known to be difficult to load in GHCi, at least on Linux). I think we’ve built up a good set of functionality https://github.com/haskell/haskell-mode/wiki/Haskell-Interactive-Mode purely based on asking GHCi things and getting it to do things. I literally use GHCi for everything. For type-checking, type info, I even send “:!cabal build” to it. Everything goes through it. I love my GHCi. Now, I’m sort of at the end of the line of where I can take GHCi. Here are the problems as I see them today: 1. There is no programmatic means of communicating with the process. I can’t send a command and get a result cleanly, I have to regex match on the prompt, and that is only so reliable. At the moment we solve this by using \4 (aka ‘END OF TRANSMISSION’). Also messages (warnings, errors, etc.) need to be parsed which is also icky, especially in the REPL when e.g. a defaulted Integer warning will mix with the output. Don’t get me started on handling multi-line prompts! Hehe. 2. GHCi, as a REPL, does not distinguish between stdout, stderr and the result of your evaluation. This can be problematic for making a smooth REPL UI, your results can often (with threading) be interspersed in unkind ways. I cannot mitigate this with any kind of GHCi trickery. 3. It forgets information when you reload. (I know this is intentional.) 4. Not enough information is exposed to the user. (Is there ever? ;) 5. There is a time-to-market overhead of contributing to GHCi — if I want a cool feature, I can write it on a locally compiled version of GHC. But for the work projects I have, I’m restricted to given GHC versions, as are other people. They have to wait to get the good features. 6. This is just a personal point — I’ve like to talk to GHCi over a socket, so that I can run it on a remote machine. Those familiar with Common Lisp will be reminded of SLIME and Swank. Examples for point 4 are: - Type of sub-expressions. - Go to definition of thing at point (includes local scope). - Local-scope completion. - A hoogle-like query (as seen in Idris recently). - Documentation lookup. - Suggest imports for symbols. - Show core for the current module. - Show CMM for the current module, ASM, etc. SLIME can do this. - Expand the template-haskell at point. - The :i command is amazingly useful, but programmatic access would be even better.¹ - Case split anyone? - Etc. ¹I’ve integrated with it in Emacs so that I can C-c C-i any identifier and it’ll popup a buffer with the :i result and then within that buffer I can drill down further with C-c C-i again. It makes for very natural exploration of a type. You’ve seen some of these features in GHC Mod, in hdevtools, in the FP Haskell Center, maybe some are in Yi, possibly also in Leksah (?). So in light of point (5), I thought: I’ve used the GHC API before, it can do interactive evaluation, why not write a project like “ghc-server” which encodes all these above ideas as a “drop-in” replacement for GHCi? After all I could work on my own without anybody getting my way over architecture decisions, etc. And that’s what I did. It’s here https://github.com/chrisdone/ghc-server. Surprisingly, it kind of works. You run it in your directoy like you would do “cabal repl” and it sets up all the extensions and package dependencies and starts accepting connections. It will compile across three major GHC versions. Hurray! Rub our hands together and call it done, right? Sadly not, the trouble is twofold: 1. The first problem
Re: Making GHCi awesomer?
On 10/18/2014 04:48 PM, Christopher Done wrote: Good evening, So I’ve been working on Haskell user-facing tooling in general for some years. By that I mean the level of Emacs talking with Haskell tools. [snip] You’ve seen some of these features in GHC Mod, in hdevtools, in the FP Haskell Center, maybe some are in Yi, possibly also in Leksah (?). Currently any Yi support for such things is either poor or not present. We currently also just talk to the REPL and parse stuff out. The upside is that it is possible for us to talk to any Haskell stuff natively (including GHC API/ghc-mod) so we don't need to depend as much on GHCi as emacs or other editors, at least in theory. [snip] Well, that’s everything. Thoughts? Ciao! Sounds interesting. My only request/comment is that I hope whatever conclusion you come to, the library part of it will be usable just as much (or even more) as the executable: if we can talk to the library natively then that's much easier than talking to some remote socket and parsing out data. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
From: Christopher Done chrisd...@gmail.com Subject: Making GHCi awesomer? Date: Sat, 18 Oct 2014 17:48:48 +0200 1. The first problem with this is that every three projects will segfault or panic when trying to load in a project that GHCi will load in happily. [...] People have similar complaints of GHC Mod co. “Getting it to work” is a deterrant. Do you have any examples of such projects, I've never seen any complaints about ghc-mod doing this. So, of course, this got me thinking that I could instead make ghc-server be based off of GHCi’s actual codebase. I could rebase upon the latest GHC release and maintain 2-3 GHC versions backwards. That’s certainly doable, it would essentially give me “GHCi++”. Good for me, I just piggy back on the GHCi goodness and then use the GHC API for additional things as I’m doing now. I had that idea too for ghc-mod unfortunately it's not so easy as ghci's internal API mostly consists of functions that only have side effects (i.e. don't return anything you can process further) :/ But is there a way I can get any of this into the official repo? For example, could I hack on this (perhaps with Herbert) as “ghci-ng”, provide an alternative JSON communication layer (e.g. via some ―use-json flag) and and socket listener (―listen-on ), a way to distinguish stdout/stderr (possibly by forking a process, unsure at this stage), and then any of the above features (point 4) listed. I make sure that I’m rebasing upon HEAD, as if to say ghci-ng is a kind of submodule, and then when release time comes we merge back in any new stuff since the last release. Early adopters can use ghci-ng, and everyone benefits from official GHC releases. The only snag there is that, personally speaking, it would be better if ghci-ng would compile on older GHC versions. So if GHC 7.10 is the latest release, it would still be nice (and it *seems* pretty feasible) that GHC 7.8 users could still cabal install it without issue. People shouldn’t have to wait if they don’t have to. Sounds awesome I'd love to get in on this :) --Daniel pgpyjRnxrBrjL.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
From: Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk Subject: Re: Making GHCi awesomer? Date: Sat, 18 Oct 2014 18:05:49 +0100 Sounds interesting. My only request/comment is that I hope whatever conclusion you come to, the library part of it will be usable just as much (or even more) as the executable: if we can talk to the library natively then that's much easier than talking to some remote socket and parsing out data. I agree! We should factor out useful bits in ghci into a library that can be used by other tools too since there's quite a lot of logic and workarounds in ghci that tools have to copy otherwise. --Daniel pgpIp50sYo6nf.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8.4: call for tickets, show stoppers, and timelines - oh my!
would https://ghc.haskell.org/trac/ghc/ticket/9284 be good candidate for 7.8.4 ? It looks like its the only forkProcess related bug fix that wasnt merged into 7.8.3, and impacts OS X On Mon, Oct 13, 2014 at 12:37 PM, Austin Seipp aus...@well-typed.com wrote: Hi *, After some discussion with Simon Mikolaj today, I'd like to direct you all at this: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4 This status page is the basic overview of what we plan on doing for 7.8.4. There are two basic components to this page: - Show stopping bugs. - Everything else, which is nice to have. Show stoppers are listed at the top of the page, in the first paragraph. Right now, this includes: - #9439 - LLVM mangling too vigorously. - #8819 - Arithmetic failures for unregistered systems - #8690 - SpecConstr blow-up And that's all. But what's all the other stuff? That's everything else. Aside from these tickets listed here - and any future amendments to it - all other tickets will only be considered nice-to-have. What does that mean? - It's low risk to include. - It clearly fixes the problem - It doesn't take Austin significant amounts of time to merge. For example, Tickets marked merge with no milestone are all nice-to-have. Similarly, all the *closed tickets* on this page may be re-opened and merged again[1], since most didn't make it to 7.8.4. Ditto with the remaining categories. OK, so that's the gist. Now I ask of you the following: - If you have a show-stopping bug with GHC 7.8.3, **you really, _positively_ need to file a bug, and get in contact with me ASAP**. Otherwise you'll be waiting for 7.10 most likely. - Again: if you have a show stopper, contact me. Very soon. - If there are bugs you *think* are showstoppers, but we didn't categorize them properly, let me know. Anything we accept as a show-stopper will delay the release of 7.8.4. Anything else can (and possibly will) be left behind. Luckily, almost all of the show stoppers have patches. Only #8819 does not, but I have asked Sergei to look into it for me if he has time today. Finally, I would please ask that users/developers do not include their own personal pet tickets under show stoppers without consulting me first, at least. :) If it's just nice to have, you can still pester me, of course, and I'll try to make it happen. I would like to have 7.8.4 out and done with by mid November, before we freeze the new STABLE branch for 7.10.1. That's not a hard deadline; just a timeframe I'd like to hit. Let me know if you have any questions or comments; thanks! [1] A lot of the closed tickets on this page had an improper milestone set, which is why they show up. You can mostly ignore them, I apologize. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
On 18 October 2014 19:28, Daniel Gröber d...@darkboxed.org wrote: Do you have any examples of such projects, I've never seen any complaints about ghc-mod doing this. I haven't used ghc-mod enough to have a crash happen to me. I couldn't get it to work the times I'd tried it and others make this complaint. Whereas GHCi works for everyone! Sounds awesome I'd love to get in on this :) Herbert doesn't have time to hack on it, but was encouraging about continuing with ghci-ng. I'm thinking to try forward-porting ghci-ng to GHC 7.8, or otherwise extracting GHC 7.8's GHCi again and then backporting it to 7.6. (Under the assumption that current + past is a reasonable number of GHCs to support.) I'm going to experiment with the JSON interface and I'll report back with results. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
On 2014-10-18 at 19:59:24 +0200, Christopher Done wrote: [...] Herbert doesn't have time to hack on it, but was encouraging about continuing with ghci-ng. Yeah, it's quite convenient to hack on GHCi that way as it's just an ordinary Cabal package (so it doesn't require to setup a GHC source-tree and wrangle with the GHC build-system), if you're lucky enough (which is most of the time) that the parts you want to tweak don't require changing the GHC API. I'm thinking to try forward-porting ghci-ng to GHC 7.8, Iirc all of the deltas in ghci-ng-7.6 relative to GHC 7.6.3 landed in GHC 7.8.1, so extracting the latest GHCi frontend code would be probably better. or otherwise extracting GHC 7.8's GHCi again and then backporting it to 7.6. Fwiw, I setup the ghci-ng .cabal's in such a way, that if you 'cabal install ghci-ng' with a GHC 7.4.x, you'd get a ghci-ng-7.4.2.1, while when on GHC 7.6.x, ghci-ng-7.6.3.5 would be selected. Supporting multiple major-versions of the GHC API simultanously in the same code-base could prove to be rather tedious (and make it more difficult to extract clean patches to merge back into GHC HEAD). But this is only speculation on my part, so your mileage may vary (Under the assumption that current + past is a reasonable number of GHCs to support.) I'm going to experiment with the JSON interface and I'll report back with results. You may want to be careful with the build-deps though; e.g. if you use JSON and want this to be merged back into GHC HEAD at some point, we may need something lighter than the usual go-to JSON implementation `aeson` in terms of build-deps... PS: I've added you to http://hackage.haskell.org/package/ghci-ng/maintainers/, just in case... ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
panic when building ghc head
hey all,
when doing a devel1 build i got the following panic
inplace/bin/genapply
rts/dist/build/AutoApply.cmminplace/bin/ghc-stage1 -static -H64m
-O -fasm -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
-DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i
-irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build
-Irts/dist/build/autogen -O2-c
rts/dist/build/AutoApply.cmm -o
rts/dist/build/AutoApply.oinplace/bin/ghc-stage1 -fPIC -dynamic
-H64m -O -fasm -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
-DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i
-irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build
-Irts/dist/build/autogen -O2-c
rts/dist/build/AutoApply.cmm -o
rts/dist/build/AutoApply.dyn_oinplace/bin/ghc-stage1 -static
-eventlog -H64m -O -fasm -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
-DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i
-irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build
-Irts/dist/build/autogen -O2-c
rts/dist/build/AutoApply.cmm -o
rts/dist/build/AutoApply.l_oinplace/bin/ghc-stage1 -static
-optc-DDEBUG -ticky -DTICKY_TICKY -H64m -O -fasm -Iincludes
-Iincludes/dist -Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
-DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i
-irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build
-Irts/dist/build/autogen -O2 -O0-c
rts/dist/build/AutoApply.cmm -o rts/dist/build/AutoApply.debug_o***
Core Lint warnings : in result of Desugar (after optimization) ***{-#
LINE 101 libraries/ghc-prim/GHC/Classes.hs #-}: Warning:
[RHS of $c/=_a1qs :: GHC.Types.Float
- GHC.Types.Float - GHC.Types.Bool]
INLINE binder is (non-rule) loop breaker: $c/=_a1qs{-# LINE 104
libraries/ghc-prim/GHC/Classes.hs #-}: Warning:
[RHS of $c/=_a1ql :: GHC.Types.Double
- GHC.Types.Double - GHC.Types.Bool]
INLINE binder is (non-rule) loop breaker: $c/=_a1ql{-# LINE 85
libraries/ghc-prim/GHC/Classes.hs #-}: Warning:
[RHS of $c/=_a1qZ :: forall a_a1X.
GHC.Classes.Eq a_a1X =
[a_a1X] - [a_a1X] - GHC.Types.Bool]
INLINE binder is (non-rule) loop breaker: $c/=_a1qZ
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20141018 for x86_64-apple-darwin):
tyConAppTyCon a_12
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
any ideas of how I could debug this? Or what it might be?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
On 18 October 2014 22:36, Herbert Valerio Riedel hvrie...@gmail.com wrote: Yeah, it's quite convenient to hack on GHCi that way as it's just an ordinary Cabal package (so it doesn't require to setup a GHC source-tree and wrangle with the GHC build-system), if you're lucky enough (which is most of the time) that the parts you want to tweak don't require changing the GHC API. Right, so far my work on ghc-server has all been doable as far back as GHC 7.2. Iirc all of the deltas in ghci-ng-7.6 relative to GHC 7.6.3 landed in GHC 7.8.1, so extracting the latest GHCi frontend code would be probably better. Okies! Supporting multiple major-versions of the GHC API simultanously in the same code-base could prove to be rather tedious (and make it more difficult to extract clean patches to merge back into GHC HEAD). But this is only speculation on my part, so your mileage may vary It hasn’t been too tedious to support old versions at least on ghc-server — I went back as far as 7.2, but GHC 7.6 for example is very similar to 7.8 so kind of comes “for free”. Makes sense, really. One major version bump to another is rather passable, it’s when going a few versions back that it becomes tedious. At least in my experience. I’ll see anyway. You may want to be careful with the build-deps though; e.g. if you use JSON and want this to be merged back into GHC HEAD at some point, we may need something lighter than the usual go-to JSON implementation `aeson` in terms of build-deps... Indeed, I was considering extracting and embedding a simple parser/printer from the old json package (remember that?). Served me well for years before aeson usurped it. :-) I think it can be reduced down to one module that operators on Strings. PS: I've added you to http://hackage.haskell.org/package/ghci-ng/maintainers/, just in case... Thanks! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Warning on tabs by default (#9230) for GHC 7.10
On 10/18/2014 01:25 AM, Austin Seipp wrote: Hi all, Please see here: https://phabricator.haskell.org/D255 and https://ghc.haskell.org/trac/ghc/ticket/9230 Making tabs warn by default has been requested many times before, and now that the compiler is completely detabbed, this should become possible to enable easily, and we can gradually remove warnings from everything else. Unless someone has huge complaints or this becomes a gigantic bikeshed/review (bike-review), please let me know - I would like this to go in for 7.10. On Phabricator I see a diff which adds a suppression for the warning to GHC. Is this necessary considering you say GHC is now fully detabbed? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Warning on tabs by default (#9230) for GHC 7.10
The boot libraries have not been detabbed, and that's something we can't immediately fix. However, the warnings being on by default means people should feel the burn to fix it quickly, I hope, and we can just update all of our submodules accordingly. I did notice however in the diff that I missed the fact `hsc2hs` has also not been detabbed. That can be fixed immediately, however. On Sat, Oct 18, 2014 at 5:30 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 10/18/2014 01:25 AM, Austin Seipp wrote: Hi all, Please see here: https://phabricator.haskell.org/D255 and https://ghc.haskell.org/trac/ghc/ticket/9230 Making tabs warn by default has been requested many times before, and now that the compiler is completely detabbed, this should become possible to enable easily, and we can gradually remove warnings from everything else. Unless someone has huge complaints or this becomes a gigantic bikeshed/review (bike-review), please let me know - I would like this to go in for 7.10. On Phabricator I see a diff which adds a suppression for the warning to GHC. Is this necessary considering you say GHC is now fully detabbed? -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Fwd: ASCIIDoc Grammar
Levi, thanks for sharing this! @herbert and austin, how much should we care about the doc format being easy to reparse? -- Forwarded message -- From: Levi Pearson levipear...@gmail.com Date: Sat, Oct 18, 2014 at 6:50 PM Subject: ASCIIDoc Grammar To: carter.schonw...@gmail.com I saw your question in the ghc-devs archive about asciidoc, and I figured I'd reply out-of-band since I don't subscribe to ghc-devs. Feel free to forward it there if you think it'd be useful. I have looked pretty deeply into the implementation of the canonical asciidoc as well as asciidoctor, which is a re-implementation in Ruby and which serves as the translator for github. There's no formal grammar, and it would be difficult to construct one, as it's not actually a fixed format. The asciidoc engine is actually a macro-processing engine that's designed to translate both in-line patterns and block-style patterns based on delimiters and attributes. It's driven to a large extent by a set of configuration files that define a lot of macros in a fairly general way, with just a couple of special-purpose parsing mechanisms. The macros can all be parameterized by attributes that can have default values, and this allows you to inject semantic tags or create new inline or block patterns that essentially expand to lower-level inlines/blocks with specific attributes. The back-ends can also use attributes to select how spans and blocks are rendered. It's a very flexible system, and lines up pretty well with the semantics of DocBook and XML in general. Its main advantage over something like Markdown (and it can actually be reconfigured to be very Markdown-like simply by changing regular expressions in the config files) is that it allows you to add semantic markup and higher-level document structure that's specific to your documentation project without having to touch the main engine code. That's an especially good thing as it's a bit messy and hard-to-follow. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
