[Haskell-cafe] Editors for Haskell

[George Beshers]

Well, my thesis (many moons ago I assure you) was on syntax
directed editors.  I came to the conclusion that letting the user
do what they want is a requirement, but that "heuristics" and
other "smarts" were to be avoided on the grounds that at least
for my implementation they were more trouble than they were
worth.  Thus I would avoid error correcting parsers unless you
are very confident that the correction used is at least type-safe
and that it is not "sticking things in" that are unwanted
(or even more maddening removing what I just typed and
which **was** what I wanted).

So my recommendation is that pointing out where the syntax
and typing errors are without having to leave the editor
would be great.  Then the time required to actually make the
corrections is minimal in terms of overall development time.

The "interesting" (graveyard laugh) problems revolve around
editing a library and the program that uses it at the same time
with a few obvious extensions.  The "graveyard laugh" is because
I rapidly found I needed transactions and as the implementation
was in C++ it had some very nasty pointer issues going to and
from disk.  Performance was also an issue --- but that was a
a pre-sparc  SUN, M68020 w/ 4Meg of RAM if memory serves
me correctly.

Good Luck.


John Meacham wrote:
> On Tue, May 30, 2006 at 10:33:05PM +0100, Brian Hulley wrote:
>   
>> 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.
>>     
>
> a problem is that people don't write code like they write novels. At
> least I don't. I skip around, adding the beginning and ending of
> functions and going back and filling in the center, or writing the =>
> first, then the type and going back and filling in the context. or
> taking existing code and changing it in pieces, deleting something
> there, adding it somewhere else, changing names, all of which leave
> intermediate states that arn't just truncated programs.
>
> I don't see such a property actually helping that much in terms of this
> problem. I think you have no choice but to use heuristics to decide what
> the user intends and try to limit the scope of potentially incomplete
> source souring later things typed. Although not as popular as they once
> were, error correcting parsers is a fairly advanced field in computer
> science, combined with the knowledge of what names are in scope, I think
> you can come up with fairly robust heuristics. It is by no means a
> trivial problem, but it is certainly a tractable one.
>
>         John
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell-cafe/attachments/20060530/174995db/attachment.htm