[Haskell-cafe] Editors for Haskell

[Brian Hulley]

Doaitse Swierstra wrote:
> 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
[rearranged]
> Not only the =>, but e.g. the commonality between patterns and
> expressions makes left factorisation a not so simple task.

My idea was to use a coarse grammar for parsing, rather than H98 directly, 
so that the parser could "see" common errors like

   newtype T a = T a a -- only one value may be wrapped by a newtype

The coarse grammar can be LL1.
The purpose of using LL1 is to ensure that the fontification would remain 
stable whenever the user types text from left to right ie gaps get filled in 
rather than the parser deciding on wildly different parses. (Just as type 
inference has to be predictable enough for users to get a feeling for so 
does parsing I think.)
As John pointed out, code can be edited by going back and forward filling in 
gaps but in this case there is no issue of stability to worry about.

I'm also not at all keen on using higher levels of analysis (such as knowing 
whether SomeId referes to a tycon or class name) to drive the parsing. I'm 
really wanting something quite simple so that the editor doesn't become so 
"clever" that it becomes unpredictable and annoying.

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

Thanks for the pointer - I'll keep this possibility in mind.

>  - did you think about how to handle the offside rule? If not, the
> good news is that we have combinators for that too.


In my C implementation it turned out to be quite simple to handle, but also 
was something which prevented me from using a table-based approach (although 
at the time I'd only understood the rule as inserting an implicit } whenever 
the parse would otherwise get stuck).

The needs of incremental parsing also force some changes to Haskell syntax. 
For example, currently the layout rule is switched off by an opening {, but 
this is no use if you need to maintain invariants about the structure of the 
buffer eg that you can search back and forwards for the beginning of top 
level declarations by examining the leftmost column (a simpler solution 
would have been to use a symbol such as {} at the top of a module to 
indicate that the module as a whole doesn't use layout at all). Also, 
multi-line strings (being multi-line lexemes) are a real nusiance as well, 
and I don't think they look good in any case (unlines can always be used 
instead and looks much neater imho) - so probably in the first instance at 
least I won't bother trying to support these little-used quirks and with any 
luck they'll be killed off in future versions of Haskell... ;-)

Anyway, thanks (also to everyone else who replied) - there's lots of ideas 
for me to consider,

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