Editors for Haskell

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Editors for Haskell

Walt Potter
All,

I hope that this is the right place for this question.

I'm using Haskell (GHC and Hugs) on several different platforms.  
Windows, OS X and Linux systems.

I'd like to have an IDE that works well for medium to large size  
projects. I know of Eclipse and hIDE.
Vim works fine but I'd like more. hiDE seems to be "in process."

What would you suggest?  I'll be asking my students to use the same IDE.

Thanks, Walt
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

C.M.Brown
Hi Walt,

For Mac OS X I would strongly recommend using Sub Etha Edit. Its a  
very simple editor to use, and offers a lot of power and flexibility.  
It also has a Haskell highlighting mode.

You can find it at:

http://www.codingmonkeys.de/subethaedit/

Chris.

On 25 May 2006, at 16:02, Walter Potter wrote:

> All,
>
> I hope that this is the right place for this question.
>
> I'm using Haskell (GHC and Hugs) on several different platforms.  
> Windows, OS X and Linux systems.
>
> I'd like to have an IDE that works well for medium to large size  
> projects. I know of Eclipse and hIDE.
> Vim works fine but I'd like more. hiDE seems to be "in process."
>
> What would you suggest?  I'll be asking my students to use the same  
> IDE.
>
> Thanks, Walt
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Jeremy O'Donoghue
In reply to this post by Walt Potter
Hi Walt,

> I'm using Haskell (GHC and Hugs) on several different platforms.
> Windows, OS X and Linux systems.

Assuming that you want your students to be able to use any of the
above platforms, the only options I know of which work well on all of
the platforms are Emacsen, Vim, hIDE, Eclipse and JEdit.

> I'd like to have an IDE that works well for medium to large size
> projects. I know of Eclipse and hIDE.
> Vim works fine but I'd like more. hiDE seems to be "in process."

Much as I love Emacs, I can possibly imagine that you'd prefer to
spend the course teaching Haskell, rather than how to use your editor.

I personally found Eclipse very difficult to get on with, although YMMV.

Although I don't use it much any more, I found JEdit to be very
straightforward to use (very good menu-based GUI, plenty of features,
syntax highlighting for most languages any sane person could want, and
generally very easy to pick up). It's very underrated IMHO.

The main reason I switched is that it does slow down with lots (>20,
some very large) of files open. Emacs is better with very large
projects (I mean > 10,000 files here), which is why I use it. I'd
recommend it as a very good editor / simple IDE for people who don't
want to spend their life learning to use their editor...

HTH

Regards
Jeremy
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Editors for Haskell

Thomas Davie

On May 25, 2006, at 6:14 PM, Jeremy O'Donoghue wrote:

> Hi Walt,
>
>> I'm using Haskell (GHC and Hugs) on several different platforms.
>> Windows, OS X and Linux systems.
>
> Assuming that you want your students to be able to use any of the
> above platforms, the only options I know of which work well on all of
> the platforms are Emacsen, Vim, hIDE, Eclipse and JEdit.
>
>> I'd like to have an IDE that works well for medium to large size
>> projects. I know of Eclipse and hIDE.
>> Vim works fine but I'd like more. hiDE seems to be "in process."

When working on Macs I've found SubEthaEdit to be by far the best  
Haskell editor, emailing the guy tends to have quite good results in  
terms of getting it free if you say you're involved in education.

Bob
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Editors for Haskell

Brian Hulley
Thomas Davie wrote:
> When working on Macs I've found SubEthaEdit to be by far the best
> Haskell editor, emailing the guy tends to have quite good results in
> terms of getting it free if you say you're involved in education.


Although I do hope that some people choose to pay for the software so that
the guy can earn his living! :-)

Regards Brian (someone who is also trying to live by writing an editor...)

--
Logic empowers the living and justifies the dead

http://www.metamilk.com 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Bjorn Bringert-2
In reply to this post by C.M.Brown
Hi Chris,

I followed your advice and tried SubEthaEdit. It seems to work really  
well, except that I can't figure out how to get it to indent my  
Haskell code correctly. What I expected was something like the Emacs  
Haskell mode where I can hit tab to cycle between the different  
reasonable indentations for a line. Am I right that SubEthaEdit does  
not have this feature? Or did I not RTFM enough? Maybe it's just me,  
but I find it difficult to write Haskell code without it.

/Björn

On May 25, 2006, at 8:10 AM, Christopher Brown wrote:

> Hi Walt,
>
> For Mac OS X I would strongly recommend using Sub Etha Edit. Its a  
> very simple editor to use, and offers a lot of power and  
> flexibility. It also has a Haskell highlighting mode.
>
> You can find it at:
>
> http://www.codingmonkeys.de/subethaedit/
>
> Chris.
>
> On 25 May 2006, at 16:02, Walter Potter wrote:
>
>> All,
>>
>> I hope that this is the right place for this question.
>>
>> I'm using Haskell (GHC and Hugs) on several different platforms.  
>> Windows, OS X and Linux systems.
>>
>> I'd like to have an IDE that works well for medium to large size  
>> projects. I know of Eclipse and hIDE.
>> Vim works fine but I'd like more. hiDE seems to be "in process."
>>
>> What would you suggest?  I'll be asking my students to use the  
>> same IDE.
>>
>> Thanks, Walt
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Mathew Mills
With Haskell's lovely strong static typing, it is a crying shame we don't
have an editor with immediate feedback, ala Eclipse.


On 5/29/06 6:55 PM, "Bjorn Bringert" <[hidden email]> wrote:

> Hi Chris,
>
> I followed your advice and tried SubEthaEdit. It seems to work really
> well, except that I can't figure out how to get it to indent my
> Haskell code correctly. What I expected was something like the Emacs
> Haskell mode where I can hit tab to cycle between the different
> reasonable indentations for a line. Am I right that SubEthaEdit does
> not have this feature? Or did I not RTFM enough? Maybe it's just me,
> but I find it difficult to write Haskell code without it.
>
> /Björn
>
> On May 25, 2006, at 8:10 AM, Christopher Brown wrote:
>
>> Hi Walt,
>>
>> For Mac OS X I would strongly recommend using Sub Etha Edit. Its a
>> very simple editor to use, and offers a lot of power and
>> flexibility. It also has a Haskell highlighting mode.
>>
>> You can find it at:
>>
>> http://www.codingmonkeys.de/subethaedit/
>>
>> Chris.
>>
>> On 25 May 2006, at 16:02, Walter Potter wrote:
>>
>>> All,
>>>
>>> I hope that this is the right place for this question.
>>>
>>> I'm using Haskell (GHC and Hugs) on several different platforms.
>>> Windows, OS X and Linux systems.
>>>
>>> I'd like to have an IDE that works well for medium to large size
>>> projects. I know of Eclipse and hIDE.
>>> Vim works fine but I'd like more. hiDE seems to be "in process."
>>>
>>> What would you suggest?  I'll be asking my students to use the
>>> same IDE.
>>>
>>> Thanks, Walt
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> [hidden email]
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Brian Hulley
Mathew Mills wrote:
> With Haskell's lovely strong static typing, it is a crying shame we
> don't have an editor with immediate feedback, ala Eclipse.

I've started writing an editor for Haskell. (It will be a commercial
product)
The first prototype was in C - now I'm re-writing from scratch in Haskell.

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?

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

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Ben Franksen-2
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

S. Doaitse Swierstra-2
In reply to this post by Walt Potter

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 [hidden email] 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

John Meacham
In reply to this post by Brian Hulley
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


--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: 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


  


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Daniel McAllansmith-2
On Wednesday 31 May 2006 11:32, George Beshers wrote:

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

I certainly agree.  I've ended up loathing any editor which unilaterally
decides to change what I've typed.  That _might_ be because they weren't done
properly... maybe.

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

It might have been mentioned before but I think IntelliJ's 'Idea' does an
excellent job as a java editor.  It'd be worth looking at for... ideas, as it
were.
It doesn't automatically correct anything, when it detects an error it makes
it obvious by highlighting the offending code, putting marks on the scrollbar
and colouring an indicator.
When the cursor is on an error you can hit a key-combo to bring up a list of
potential remedial actions.

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

Idea is, more or less, transactional.  It's 'refactorings' can affect multiple
entities, and they're stored in a local history so you can rollback when you
want to.
I'm not sure it'd run too well on that sort of machine though. :)

For what it's worth, I'd love a Haskell editor the likes of Idea (and better).  
Lots of refactory-goodness, auto-importing of functions, function suggestion
from type, display of inferred types, etc, etc, etc

Daniel
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

John Meacham
On Wed, May 31, 2006 at 12:19:40PM +1200, Daniel McAllansmith wrote:

> On Wednesday 31 May 2006 11:32, George Beshers wrote:
> > 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).
>
> I certainly agree.  I've ended up loathing any editor which unilaterally
> decides to change what I've typed.  That _might_ be because they weren't done
> properly... maybe.

Oh, I did not mean error correcting parsers as in something that would
change what you wrote, I meant ones that can deal with parse errors in a
local fashion without catastrophically failing to parse the whole
program. Parsers that can recover from incomplete input. parser
combinators might be a better solution as their grammer can actually be
guided and changed by what is in scope rather than fixed at the parser
generator phase.

editors should never change what the person wrote in general without
some prodding by the user IMHO.

        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Brian Hulley
In reply to this post by S. Doaitse Swierstra-2
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 [hidden email] 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 

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Thomas Hallgren-4
In reply to this post by Brian Hulley
Brian Hulley wrote:

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

You are in luck, because according to the Haskell 98 Report, qualified
names are in the lexical syntax!

        http://www.haskell.org/onlinereport/syntax-iso.html

So, C.f is a qualified name, but C . f is composition of the Constructor
C with the function f.

--
Thomas H

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Brian Hulley
Thomas Hallgren wrote:

> Brian Hulley wrote:
>
>>
>> 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).
>
> You are in luck, because according to the Haskell 98 Report, qualified
> names are in the lexical syntax!
>
> http://www.haskell.org/onlinereport/syntax-iso.html
>
> So, C.f is a qualified name, but C . f is composition of the
> Constructor C with the function f.

Thanks for pointing this out. Although there is still a problem with the
fact that var, qvar, qcon etc is in the context free syntax instead of the
lexical syntax so you could write:

        2 `    plus      ` 4
        (    Prelude.+
               {- a comment -} ) 5 6

I think this must have been what was in the back of my mind. To make parsing
operator expressions simple (ie LL1), it is necessary to somehow treat `
plus    ` as a single lexeme, but by having such a thing in the CFG instead
of the lexical grammar, a "lexeme" can then occuply multiple lines (which
means you can't associate each line with a list of lexemes for incremental
parsing)...
Allowing "lexemes" to contain spaces and comments also makes fontification a
bit more tricky.
Also, I can't see any sense in making such things part of the CFG instead of
just keeping them lexical - whoever would want to put spaces in a var, qcon
etc?
I suppose it's not an impossible problem to solve but it just makes life a
lot harder for no good purpose that I can see.

Best 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Editors for Haskell

Malcolm Wallace
"Brian Hulley" <[hidden email]> wrote:

> Thanks for pointing this out. Although there is still a problem with
> the  fact that var, qvar, qcon etc is in the context free syntax
> instead of the  lexical syntax so you could write:
>
>         2 `    plus      ` 4
>         (    Prelude.+
>                {- a comment -} ) 5 6

You appear to be right.  However, I don't think I have ever seen a piece
of code that actually used the first form.  People seem to naturally
place the backticks right next to the variable name.  Should we consider
the fact that whitespace and comments are permitted between backticks to
be a bug in the Report?  It certainly feels like it should be a lexical
issue.

On the other hand, the second form looks a lot like just bracketting an
ordinary expression, and whitespace and comments can frequently be seen
in such a position.  If we disallow whitespace in the backtick case, it
would feel wrong to permit it in the parenthesised "dual".

Does anyone from the original language committee have any memory of why
these choices were taken?

Regards,
    Malcolm
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Editors for Haskell

Simon Marlow-5
Malcolm Wallace wrote:

> "Brian Hulley" <[hidden email]> wrote:
>
>
>>Thanks for pointing this out. Although there is still a problem with
>>the  fact that var, qvar, qcon etc is in the context free syntax
>>instead of the  lexical syntax so you could write:
>>
>>        2 `    plus      ` 4
>>        (    Prelude.+
>>               {- a comment -} ) 5 6
>
>
> You appear to be right.  However, I don't think I have ever seen a piece
> of code that actually used the first form.  People seem to naturally
> place the backticks right next to the variable name.  Should we consider
> the fact that whitespace and comments are permitted between backticks to
> be a bug in the Report?  It certainly feels like it should be a lexical
> issue.

I tend in the other direction: I'd rather see as much as possible pushed
into the context-free syntax.  The only reason that qualified
identifiers are in the lexical syntax currently is because of the clash
with the '.' operator.

I'm not sure I can concisely explain why I think it is better to use the
context-free syntax than the lexical syntax, but I'll try.  I believe
the lexical syntax should adhere, as far as possible, to the following rule:

   juxtaposition of lexemes of different classes should not affect
   the lexical interpretation.

in other words, whitespace between different lexemes is irrelevant.  I
know this rule is violated in many places in the Haskell lexical syntax,
but at least for me it serves as a guideline for what is tasteful.  For
example, it rules out `x` as a lexeme, because ` ought to be a reserved
symbol, and then `x` would be a justaposition of 3 lexemes.  This also
explains to me why I think many of GHC's syntactic extensions are ugly
(42#, (#..#), $x, [d|..|], etc.).  However, it's really hard to extend
the lexical syntax and stick to this rule, especially if you want to add
brackets.  So you should consider this a rant, nothing more.

Cheers,
        Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12