[Haskell-cafe] Editors for Haskell

[Brian Hulley]

Benjamin Franksen wrote:
> 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?

But the buffer will nearly always be incomplete as you're editing it.

I was kind of hoping that the syntax of Haskell could be changed so that for 
any sequence of characters there would be a unique parse that had a minimum 
number of "gaps" inserted by the editor to create a complete parse tree, and 
moreover that this parse could be found by deterministic LL1 recursive 
descent.

Haskell already seems so very close to having this property - its a real 
pity about =>

The problem is: when Haskell was designed, no one seems to have thought 
about the syntax from the point of view of making it easy to parse or 
ensuring that it would have this nice property for editing.

>
>>        foo :: {SomeClass a} a->a
>>           a Prelude.+ b        -- no spaces in the qvarsym
>>           a `Prelude.(+)` b    -- a little generalization
>>           a `Prelude.(+) b        -- no need for closing `
>
> 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.

Thanks for the feedback - I suppose I was being overly optimistic to think I 
could just change the language to suit my editor ;-).
I'll have to find a balance between what I'm able to implement and what is 
specified in Haskell98 (or Haskell' etc) - just as GHCi has done with 
qvarsym, and perhaps have different levels of conformance to H98 so people 
could choose their preferred balance between conformity and 
instantaneousness of feedback (everything would of course still be 
loaded/saved as H98).

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