[Haskell-cafe] Editors for Haskell

[Benjamin Franksen]

On Tuesday 30 May 2006 20:59, Brian Hulley wrote:
> 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?

If SomeClass has been defined somewhere (in the same buffer or in some 
imported module), the editor will know whether it is a class or a type 
and can react accordingly (e.g. propose to insert '=>' or use a special 
color for 'SomeClass'). If not, then the editor should remain agnostic. 
What is the problem here? No user will expect the editor to 
unambigously parse /incomplete/ code, or will they?

> 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)?

I would not like an editor that forces me to use a special coding style 
(like using brackets where not strictly necessary). Even less would I 
like to use one that introduces non-standard syntax.

My humble opinion is that you'll have to bite the bullet and implement 
your syntax recognizer so that it conforms to Haskell'98 (including the 
approved addenda) [and addtionally however many of the existing 
extensions you'll manage to support]. It may be more difficult but in 
the end will also be a lot more useful. And you'll have to find a way 
to (unobtrusively!) let the user know whether some piece of code does 
not yet have enough context to parse it unambigously.

Ben