Brian You probably know this, but your kind of application is a big reason that we now make GHC available as a library. (Just say 'import GHC'.) You shouldn't need to parse Haskell yourself: just call GHC's parser. You get back a syntax tree with very precise location information that can guide your editor (e.g. if you want to select a sub-exprssion). Similarly, you can call the type checker. All this is much harder with half-written programs, but it seems acceptable to re-run the process at every keystroke, or at least at every pause. Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Brian Hulley | Sent: 30 May 2006 20:00 | To: Mathew Mills; Bjorn Bringert; Christopher Brown | Cc: Walter Potter; haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] Editors for Haskell | | Mathew Mills wrote: | > With Haskell's lovely strong static typing, it is a crying shame we | > don't have an editor with immediate feedback, ala Eclipse. | | I've started writing an editor for Haskell. (It will be a commercial | product) | The first prototype was in C - now I'm re-writing from scratch in Haskell. | | It is quite a tall order to provide immediate typed feedback of an edit | buffer that will in general be syntactically incomplete but this is my | eventual aim. | | One issue in the area of immediate feedback is that Haskell's syntax is | troublesome in a few areas. Consider: | | foo :: SomeClass a => a -> a | | when the user has just typed: | | foo :: SomeClass a | | should the editor assume SomeClass is a Tycon or a class name? | | One idea I had to solve this problem was to change the syntax of Haskell | slightly so that constraints would be enclosed in {} instead of preceeding | => ie: | | foo :: {SomeClass a} a->a | | so that in | | foo :: {SomeClass | | it is already determined that SomeClass must be a class name. | | Another thing which causes difficulty is the use of qualified operators, and | the fact that the qualification syntax is in the context free grammar | instead of being kept in the lexical syntax (where I think it belongs). For | example, afaiu according to H98 (but not GHCi) it is permissible to write: | | a Prelude . + b | | -- qvarsym -> [ modid . ] varsym | | | whereas in my prototype I put all this into a level immediately above the | lexer but below the CFG so that no spaces are allowed thus: | | a Prelude.+ b -- no spaces in the qvarsym | a `Prelude.(+)` b -- a little generalization | a `Prelude.(+) b -- no need for closing ` | | (The generalization above is intended for when you don't know whether or not | the function you're qualifying has been declared as an operator but you want | to use it as an operator eg if a pop-up list would appear after you typed | `Prelude. with entries such as (+) plus add etc) | | With the above changes, it is possible to parse Haskell (or at least as much | as I got round to implementing in my C++ prototype) using a simple | deterministic recursive descent parser with only 1 token of lookahead. | | (There is possibly some confusion in the H98 report about exactly how | ambiguous expressions involving typed case alternatives might be parsed eg x | :: a->b -> if x 4 then ... but I'm hoping it will be ok to just fix the | syntax here by requiring extra brackets) | | Anyway I suppose the point of this post is to see whether or not people feel | that such changes are acceptable in an editor, or whether an editor must | adhere exactly to the standard (or whether the standard can be changed to | enable the determinism and ease of parsing necessary for interactive editing | with immediate feedback)? | | Regards, Brian. | -- | Logic empowers us and Love gives us purpose. | Yet still phantoms restless for eras long past, | congealed in the present in unthought forms, | strive mightily unseen to destroy us. | | http://www.metamilk.com | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe