https://wiki.haskell.org/index.php?title=Yhc/API/Compiler&feed=atom&action=historyYhc/API/Compiler - Revision history2024-03-29T06:23:08ZRevision history for this page on the wikiMediaWiki 1.35.5https://wiki.haskell.org/index.php?title=Yhc/API/Compiler&diff=1662&oldid=prevNeilMitchell at 02:39, 15 January 20062006-01-15T02:39:24Z<p></p>
<p><b>New page</b></p><div>{{Yhc}}<br />
<br />
I want an API to Yhc, [[GHC]] has one, and I don't want the other compiler authors laughing at us :) This page is more notes for a potential API, rather than documentation of an existing one. If you would like an additional feature, just list it.<br />
<br />
== Sample Definitions ==<br />
<br />
-- first stage, lexing!<br />
data Pos = Pos {file :: FileName, line :: Int, pos :: Int}<br />
data Lex = {- Lexemes -} | InlineComment String | MultilineComment String | WhiteSpace String<br />
type LexPos = (Lex, Pos)<br />
<br />
lex :: String -> [LexPos] -- lex Haskell bits<br />
lexAll :: String -> [LexPos] -- also lex white space and comments<br />
<br />
output :: ParseTree -> [LexPos] -> String<br />
<br />
-- QUESTION:<br />
-- should the standard lexer just lex white space, and pass it onwards<br />
-- what about moving to BLG?<br />
-- that will handle bracketing first, then lexing<br />
-- you can always run the BLG in Lex only mode, just not do it that way for the compiler<br />
-- or offer to dump the bracketed version out before higher merging has been done<br />
<br />
-- ONE OPTION:<br />
-- lexOnly - not used by the compiler at all, using the lex phase plus some additional rules?<br />
-- maybe entirely separate, just distribute a stadalone lexer if people want it?<br />
-- bracketLex - first step, as the compiler does it - a bracketLex tree, possibly with comments/spaces<br />
<br />
-- Group should not be run when spaces and comments are in the source!<br />
-- would anyone ever want the source with just lexing, i.e. before bracketing?<br />
<br />
-- we want round tripping, converting from input to output, can that be done?<br />
<br />
<br />
<br />
<br />
<br />
data ParseTree = ... | Position Pos ParseTree<br />
<br />
data Lex = ... | Comment String<br />
<br />
data Pos = Pos String Int Int<br />
<br />
-- maybe with an annotation mechanism<br />
data ParseTree x = ... | ParseAnnotation x (ParseTree x)<br />
<br />
<br />
parse :: FilePath -> IO ParseTree<br />
lexer :: FilePath -> IO [(Pos, Lex)]<br />
<br />
dependancies :: ParseTree -> IO [FilePath]<br />
<br />
typeCheck :: ParseTree -> TypedParseTree<br />
<br />
desugar :: ParseTree -> ParseTree<br />
<br />
desugarCase :: ParseTree -> ParseTree<br />
desugarListComprehension :: ParseTree -> ParseTree<br />
<br />
<br />
bytecode :: ParseTree -> ByteCode<br />
<br />
-- we were gonig to have a separate bytecode manip library, maybe put that in here?<br />
<br />
}}}<br />
<br />
== Round Tripping ==<br />
<br />
You want to parse the code to the parse tree, modify it in some way, then write it out again. How?<br />
<br />
Options: lex returns everything, whitespace and comments included. Then have a parse tree phase. A modified parse tree can go back and look at the lex, along with the positions of the parse tree elements, and decide where things should end up.<br />
<br />
But this assumes using lex first, which we don't want - we want preprocess, bracket, lex group (at least i do, and i will fight for this). so how? You can still lex, take the tokens returned from lex, intersperse them with the ParseTree, then write them out again. It means "lex/bracketing" the whole thing twice, but really, is that a problem? It will not be done by the compiler, but would be done by the type annotator, by HaRe, and I'm sure we can think of a few more utilities. Round tripping would be really nice.<br />
<br />
== Users ==<br />
<br />
Potential or real, just use cases really so we make sure we've got all the functionality<br />
<br />
=== Catch ===<br />
<br />
Formal verifier for haskell programs. Will want parsing, no type checking, desugaring. Finding out where desugared lumps came from is important.<br />
<br />
=== HaRe ===<br />
<br />
Refactorer. Important to be able to output the syntax tree again, with comments intact and with indentation preserved exactly as it was before.<br />
<br />
=== Salmon ===<br />
<br />
Like haddock. Important to see comments, and be able to attach them. Type checker would be very handy.</div>NeilMitchell