[Haskell-cafe] Editors for Haskell

[Doaitse Swierstra]

On 2006 mei 30, at 17:33, Brian Hulley wrote:

> 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.

If you use my parsercombinators, and are willing to work on the  
grammar I think this can in principle be done. The combinators  
automatically "correct" incorrect (i.e. in this case incomplete)  
input, but:
  - you may really need some time to tune the grammar so the  
corrections are what a user might expect (there are many hooks for  
doing so, but it will takje some effort, since this s also a human  
interface issue)
  - making a Haskell grammar that parsers top-down is not an easy  
task, and making it LL1 is definitely impossible, but also not needed  
if you use my combinators
  - we could in principle provide you with a complete parser for  
Haskell using our combinators that was tested by replacing the GHC  
parser with this parser, and that worked (contact athurb at cs.uu.nl to  
get a copy of his code)
  - did you think about how to handle the offside rule? If not, the  
good news is that we have combinators for that too.

  Doaitse Swierstra



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

Not only the =>, but e.g. the commonality between patterns and  
expressions makes left factorisation a not so simple task.

>
> 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
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe