ANNOUNCE: ghc-src version 0.2.0
ghc-src 0.2.0 has been released. ghc-src is a Haskell parser with full support for every GHC extension. It is a refactored version of the Haskell parser used internally by GHC and is meant as a replacement for haskell-src-exts, although it might have other uses. The package is cabalized and lives under Langauge.Haskell.GHC.* in the module hierarchy. Darcs repo: http://scannedinavian.org/~lemmih/ghc-src/ -- Friendly, Lemmih
On Tue, Aug 23, 2005 at 04:10:51PM +0200, Lemmih wrote:
ghc-src 0.2.0 has been released.
ghc-src is a Haskell parser with full support for every GHC extension. It is a refactored version of the Haskell parser used internally by GHC and is meant as a replacement for haskell-src-exts, although it might have other uses. The package is cabalized and lives under Langauge.Haskell.GHC.* in the module hierarchy.
Darcs repo: http://scannedinavian.org/~lemmih/ghc-src/
ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter. John -- John Meacham - ⑆repetae.net⑆john⑈
On 8/23/05, John Meacham <john@repetae.net> wrote:
On Tue, Aug 23, 2005 at 04:10:51PM +0200, Lemmih wrote:
ghc-src 0.2.0 has been released.
ghc-src is a Haskell parser with full support for every GHC extension. It is a refactored version of the Haskell parser used internally by GHC and is meant as a replacement for haskell-src-exts, although it might have other uses. The package is cabalized and lives under Langauge.Haskell.GHC.* in the module hierarchy.
Darcs repo: http://scannedinavian.org/~lemmih/ghc-src/
ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter.
Parsing Haddock comments would be pretty easy. However, compilers probably wont find ghc-src very usable since it has no placeholders for post-parsing information (such as inferred types). -- Friendly, Lemmih
On Wed, 2005-08-24 at 00:29 +0200, Lemmih wrote:
On 8/23/05, John Meacham <john@repetae.net> wrote:
On Tue, Aug 23, 2005 at 04:10:51PM +0200, Lemmih wrote:
ghc-src 0.2.0 has been released.
ghc-src is a Haskell parser with full support for every GHC extension. It is a refactored version of the Haskell parser used internally by GHC and is meant as a replacement for haskell-src-exts, although it might have other uses. The package is cabalized and lives under Langauge.Haskell.GHC.* in the module hierarchy.
Darcs repo: http://scannedinavian.org/~lemmih/ghc-src/
ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter.
Parsing Haddock comments would be pretty easy. However, compilers probably wont find ghc-src very usable since it has no placeholders for post-parsing information (such as inferred types).
However it would be great for replacing the parser that haddock currently uses! This would be a nice thing to do, that is make haddock use this parser, since then it would accept exactly the same language that ghc accepts. When running haddock I often have to fix things where haddock is stricter than ghc's parser. And haddock's current error messages are not very good, they do not give source locations very accurately, unlike ghc which has excelent parser error messages. Duncan
On Tue, Aug 23, 2005 at 04:10:51PM +0200, Lemmih wrote:
ghc-src 0.2.0 has been released.
ghc-src is a Haskell parser with full support for every GHC extension. It is a refactored version of the Haskell parser used internally by GHC and is meant as a replacement for haskell-src-exts, although it might have other uses.
I heard that there is some combinator-based Haskell parser that also is equivalent to GHC's Happy-based one, and is within 10% of its performance. I had thought that I read that GHC might even start using it. Does anybody know if the combinator-based one is available? Thanks, Brian
Brian Smith wrote:
I heard that there is some combinator-based Haskell parser that also is equivalent to GHC's Happy-based one, and is within 10% of its performance. I had thought that I read that GHC might even start using it. Does anybody know if the combinator-based one is available?
This work has been done Arthur Baars -- he actually replaced the ghc parser by his combinator parser and build Ghc + standard libraries with it which took 10% longer than using the Happy parser. You should probably contact him to get more information. One interesting thing is that the combinator parser can use syntax macros and thus extend the syntax of Haskell at compile time in a type-safe way. All the best, -- Daan Leijen. ps. When you check out Arthur's webpage, be sure to read the "Typing dynamic typing" article -- it is a great paper!
Thanks, Brian
------------------------------------------------------------------------
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Daan is right, I wrote a parser for GHC using Doaitse Swierstra's parsing combinator library (http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/index.html). I needed a drop-in replacement for GHC's Happy parser, to make a prototype for syntax macros. Syntax Macros allow a programmer to extend a language with new syntax. Combinator based parsers parsers can be dynamically extended, making them suitable for implementing syntax macros. Unfortunately, I never had time to really finish the syntax macro implementation. But I did finish the combinator based parser for GHC. I tested it by having GHC( with combinator parser) compile itself and all the libraries. This took about 10% longer than with the original GHC, so in practice its speed is acceptable. The parser is really a drop-in replacement for GHC 6.2.1. You only need to replace Parser.hs, add a line to Lexer.x and to a Makefile. I do not have time to maintain a combinator based parser for GHC. So if you like, I can send you the code. Arthur On 30-aug-05, at 5:13, Daan Leijen wrote:
Brian Smith wrote:
I heard that there is some combinator-based Haskell parser that also is equivalent to GHC's Happy-based one, and is within 10% of its performance. I had thought that I read that GHC might even start using it. Does anybody know if the combinator-based one is available?
This work has been done Arthur Baars -- he actually replaced the ghc parser by his combinator parser and build Ghc + standard libraries with it which took 10% longer than using the Happy parser. You should probably contact him to get more information. One interesting thing is that the combinator parser can use syntax macros and thus extend the syntax of Haskell at compile time in a type-safe way.
All the best, -- Daan Leijen.
ps. When you check out Arthur's webpage, be sure to read the "Typing dynamic typing" article -- it is a great paper!
Thanks, Brian ---------------------------------------------------------------------- -- _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On Tuesday 30 August 2005 13:04, Arthur Baars wrote:
Daan is right, I wrote a parser for GHC using Doaitse Swierstra's parsing combinator library (http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/index.html).
Very interesting. I tried to download it but I had no success. How exactly do I "checkout the whole uust tree"? Ben
You can check them out using CVS as follows: cvs -d:pserver:anonymous@cvs.cs.uu.nl:/data/cvs-rep login cvs -d:pserver:anonymous@cvs.cs.uu.nl:/data/cvs-rep checkout uust I'll ask Doaitse to add this information to the web page. Arthur On 30-aug-05, at 13:53, Benjamin Franksen wrote:
On Tuesday 30 August 2005 13:04, Arthur Baars wrote:
Daan is right, I wrote a parser for GHC using Doaitse Swierstra's parsing combinator library (http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/index.html).
Very interesting. I tried to download it but I had no success. How exactly do I "checkout the whole uust tree"?
Ben _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
2005/8/24, John Meacham <john@repetae.net>:
ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter. John
I think that it could be more useful to preserve all comments. Haddock can filter out only the haddock style comments but there are tools that use another style of comments. Cheers, Krasimir
On 8/24/05, Krasimir Angelov <kr.angelov@gmail.com> wrote:
2005/8/24, John Meacham <john@repetae.net>:
ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter. John
I think that it could be more useful to preserve all comments. Haddock can filter out only the haddock style comments but there are tools that use another style of comments.
I can't really imagine what the AST would look like if it should support comments in arbitrary places. -- Friendly, Lemmih
On Wed, 2005-08-24 at 10:56 +0200, Lemmih wrote:
On 8/24/05, Krasimir Angelov <kr.angelov@gmail.com> wrote:
2005/8/24, John Meacham <john@repetae.net>:
ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter. John
I think that it could be more useful to preserve all comments. Haddock can filter out only the haddock style comments but there are tools that use another style of comments.
I can't really imagine what the AST would look like if it should support comments in arbitrary places.
Haddock annoations cannot appear in arbitrary places. They can be attached to the top level module, exported symbols, function defeinitions, function arguments, data types, data constructors (and possibly one or two things I've forgotten). So they can all be attached to sensible places in the AST. Duncan
On Wed, 2005-08-24 at 10:14 +0100, Duncan Coutts wrote:
On Wed, 2005-08-24 at 10:56 +0200, Lemmih wrote:
On 8/24/05, Krasimir Angelov <kr.angelov@gmail.com> wrote:
2005/8/24, John Meacham <john@repetae.net>:
ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter. John
I think that it could be more useful to preserve all comments. Haddock can filter out only the haddock style comments but there are tools that use another style of comments.
I can't really imagine what the AST would look like if it should support comments in arbitrary places.
Haddock annoations cannot appear in arbitrary places.
They can be attached to the top level module, exported symbols, function defeinitions, function arguments, data types, data constructors (and possibly one or two things I've forgotten). So they can all be attached to sensible places in the AST.
Oh, wait. I misunderstood. Ignore me. :-) Duncan
On Wed, Aug 24, 2005 at 10:14:58AM +0100, Duncan Coutts wrote:
On Wed, 2005-08-24 at 10:56 +0200, Lemmih wrote:
On 8/24/05, Krasimir Angelov <kr.angelov@gmail.com> wrote:
2005/8/24, John Meacham <john@repetae.net>:
ooh. neat. any chance it could be extended to preserve haddock comments and attach them to the right places? I thought it would be really cool if compilers could use the haddock documentation when printing out error messages and be able to query documentation as well as type info from inside the interpreter. John
I think that it could be more useful to preserve all comments. Haddock can filter out only the haddock style comments but there are tools that use another style of comments.
I can't really imagine what the AST would look like if it should support comments in arbitrary places.
Haddock annoations cannot appear in arbitrary places.
They can be attached to the top level module, exported symbols, function defeinitions, function arguments, data types, data constructors (and possibly one or two things I've forgotten). So they can all be attached to sensible places in the AST.
Ideally, the parser would not try to look inside the haddock comments, but would just look at the character indicator to attach them to the right place in the AST and just store them as raw strings. that way the parse doesn't fail due to misformed comments and one is free to use different documentation styles (perhaps latex or html comments or something else wacky) as long as the attachment points and indicators are the same. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (8)
-
Arthur Baars -
Benjamin Franksen -
Brian Smith -
Daan Leijen -
Duncan Coutts -
John Meacham -
Krasimir Angelov -
Lemmih