[Haskell-cafe] Editors for Haskell

[Simon Peyton-Jones]

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 at haskell.org
[mailto:haskell-cafe-bounces at 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 at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/haskell-cafe