RE: [Haskell-cafe] Re: Editors for Haskell
GHC already carefully collects up almost all messages in a data type called Message, so they are easy to re-direct. However at the moment they collected as strings (well as Pretty.Doc values actually) so they have lost their structure. I believe that at one time I had a data type for error messages, but there are so many of them and they change pretty often that it was quite a pain having a centralised data type for this. And at the time there was lots of pain and virtually no gain. Changing this would be tedious but do-able. If anyone wants to undertake it, let us know. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Thiago Arrais | Sent: 08 June 2006 20:07 | To: haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] Re: Editors for Haskell | | Imam, | | On 6/8/06, Imam Tashdid ul Alam [EMAIL PROTECTED] wrote: |- about formatted error messages (I am sure you guys | don't care), could someone build a light GHC front end | that given a .hs/.lhs file produces two XML files with | specified DTD, the parsed structure and the error | messages? | | I would really appreciate that. I am the one maintaining EclipseFP now | and I know that having the syntax-tree in XML format would help us a | lot. For now, we use our own Haskell parser (written in Java). It is | not a full parser (and maybe it'll never be), but it allows us to do | some tricks like showing a simple code outline and do some code | assistance. | | Maybe this isn't as much work as structuring the error messages. | | Cheers, | | Thiago Arrais | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Editors for Haskell
| You probably know this, but your kind of application is a big reason | that we now make GHC available as a library. (Just say 'import GHC'.) | | You shouldn't need to parse Haskell yourself: just call GHC's parser. | You get back a syntax tree with very precise location information that | can guide your editor (e.g. if you want to select a sub-exprssion). | Similarly, you can call the type checker. | | Are there any small examples of using GHC's parser? I'm a complete | newbie so perhaps I'm not checking all of the relevant locations for | docs, but I can't seem to find this parser that is being referred to. | I checked out the source tree to GHC as well, but I have no idea where | to look in there (not to mention it's a bit intimidating). Pointers | would be appreciated! The interface is exported by the module 'GHC', which is in GHC's sources in main/GHC.hs. Sadly it does not have Haddock-ised documentation, because Haddock isn't fully-featured enough to read GHC's source code. (With a bit of luck the SoC project will fix that problem.) Meanwhile, your best bet is to look at the interface and explore. There a short web page giving an example of using GHC as a library here http://haskell.org/haskellwiki/GHC/As_a_library Please add to it as you find out what to do! simon | | As part of my learning experience, I think I want to see if I can | write a haskell pastebin that does proper syntax highlighting. | Someone in #haskell suggested that I use just a lexer because using a | parser is overkill. However, I can't make this assessment until I see | how to use the parser and the information it can supply. | | Thanks, | Pete | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
hya this topic is hot, and I wonder why :s well, I've been thinking, the EclipseFP people have done more or less a fine job (I'm trying their live build, things feel natural). but the problem is, to build something like EclipseFP you have to know both Java and Haskell and on top of that you have to be very familiar with the Eclipse plug-in architecture. whining: - should have had folds for where and let clauses - the error messages are still cryptic (and unformatted!) - there was no tooltip for functions - the default color chosen for functions is way too bright - ... (many silly Java expectations follow) but what if we _ask_ eclipse.org to help us out? like, an official collaboration? they have done an excellent job promoting free software. this should be sort of a recognition for them. the point is, GUI _is_ easier to build in Java. and those people are experts. should not take much time. as for me, I'll be happy to watch the impact Haskell will have on Java fans. two things just to make sure this post is not absolutely superfluous: - without drinking anything I was feeling drunk that night and so I posted some of my hIDEous thoughts in http://www.haskell.org/haskellwiki/Talk:HIDE page. Lemmih left a note saying I was not so genuine, a project called Proxima has implemented (or at least, proposed) most of the ideas. I checked it out and was ashamed of my lack of original idea. however, though the paper was absolutely dreamy, the implementation,.. how do I put it humbly.. sucked. I am sure the Eclipse people will appreciate the Proxima ideas. please ask them to build a Proxima style IDE for Haskell. - about formatted error messages (I am sure you guys don't care), could someone build a light GHC front end that given a .hs/.lhs file produces two XML files with specified DTD, the parsed structure and the error messages? the reason for choosing XML is that not only the Java people (including Leif Frenzel) but also virtually anyone can access these information (in order to create a great IDE) immediately and without loosing the structure. cheers, Imam __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
Hi - about formatted error messages (I am sure you guys don't care), could someone build a light GHC front end that given a .hs/.lhs file produces two XML files with specified DTD, the parsed structure and the error messages? the reason for choosing XML is that not only the Java people (including Leif Frenzel) but also virtually anyone can access these information (in order to create a great IDE) immediately and without loosing the structure. This would be great, and could perhaps be used by other compilers as well, but is likely to be a lot of work. Someone will need to go through all possible Haskell error messages, probably assign an ID to each one, and write something about the exact meaning of the error message. However, this would be really really useful for beginners to find more information. I started trying to do this with Yhc, but got bored once I got past 10 error messages. (See http://www-users.cs.york.ac.uk/~malcolm/cgi-bin/darcsweb.cgi?r=yhc-devel;a=headblob;f=/src/compiler98/Error.hs for my attempt) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
Imam, On 6/8/06, Imam Tashdid ul Alam [EMAIL PROTECTED] wrote: - about formatted error messages (I am sure you guys don't care), could someone build a light GHC front end that given a .hs/.lhs file produces two XML files with specified DTD, the parsed structure and the error messages? I would really appreciate that. I am the one maintaining EclipseFP now and I know that having the syntax-tree in XML format would help us a lot. For now, we use our own Haskell parser (written in Java). It is not a full parser (and maybe it'll never be), but it allows us to do some tricks like showing a simple code outline and do some code assistance. Maybe this isn't as much work as structuring the error messages. Cheers, Thiago Arrais ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Editors for Haskell
Simon Peyton-Jones [EMAIL PROTECTED] writes: You probably know this, but your kind of application is a big reason that we now make GHC available as a library. (Just say 'import GHC'.) You shouldn't need to parse Haskell yourself: just call GHC's parser. You get back a syntax tree with very precise location information that can guide your editor (e.g. if you want to select a sub-exprssion). Similarly, you can call the type checker. Are there any small examples of using GHC's parser? I'm a complete newbie so perhaps I'm not checking all of the relevant locations for docs, but I can't seem to find this parser that is being referred to. I checked out the source tree to GHC as well, but I have no idea where to look in there (not to mention it's a bit intimidating). Pointers would be appreciated! As part of my learning experience, I think I want to see if I can write a haskell pastebin that does proper syntax highlighting. Someone in #haskell suggested that I use just a lexer because using a parser is overkill. However, I can't make this assessment until I see how to use the parser and the information it can supply. Thanks, Pete ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
Hi Pete As part of my learning experience, I think I want to see if I can write a haskell pastebin that does proper syntax highlighting. Someone in #haskell suggested that I use just a lexer because using a parser is overkill. However, I can't make this assessment until I see how to use the parser and the information it can supply. You might want to check out HsColour, which does pretty much exactly what you asked for: http://www.cs.york.ac.uk/fp/darcs/hscolour/ Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
Pete Kazmier [EMAIL PROTECTED] wrote: As part of my learning experience, I think I want to see if I can write a haskell pastebin that does proper syntax highlighting. Someone in #haskell suggested that I use just a lexer because using a parser is overkill. However, I can't make this assessment until I see how to use the parser and the information it can supply. For simple static highlighting, a lexical analysis is more than adequate. (You've seen http://www.cs.york.ac.uk/fp/darcs/hscolour, right?) You only need a full parser if you want to do (e.g.) hyperlinks from a variable usage to its definition site. (You seen Programatica as well, http://www.cse.ogi.edu/~hallgren/h2h.html right?) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Editors for Haskell
Pete Kazmier [EMAIL PROTECTED] writes: As part of my learning experience, I think I want to see if I can write a haskell pastebin that does proper syntax highlighting. Someone in #haskell suggested that I use just a lexer because using a parser is overkill. However, I can't make this assessment until I see how to use the parser and the information it can supply. Thanks for the responses and pointers to the other projects. I'll investigate those after the day-job (the one that pays the bills). As for using the lexer vs the parser, I was hoping to do things such as folding and/or nifty mouse-overs of logical blocks of code, which is why I was interested in the parser. I'm not sure if I could do the same with only a lexer. I'm basically just looking for something concrete to tinker with as I learn Haskell and it seems that Haskell is missing a snazzy pastebin. Thanks, Pete ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
One might want to take a look at:
http://www.cs.uu.nl/research/projects/proxima/
where we have built (a.o.) an editing environment for Helium programs
(a subset of Haskell),
Doaitse
On 2006 jun 02, at 10:57, Brian Hulley wrote:
Simon Marlow wrote:
Malcolm Wallace wrote:
Brian Hulley [EMAIL PROTECTED] 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.
A question here is: what is a lexeme?
For example there are floating point numbers, which are written
without spaces, but which could be considered to consist of
primitive whole-number lexemes interspersed with . e -
34.678e-98
I don't see what the difference is between them and
Prelude.+
especially since we *really* need the dot for other purposes in the
CFG such as composition and (hopefully at some point) field selection.
Since Prelude.+ is by the above argument a single lexeme, it seems
consistent to say that
`Mod.Id`
(Mod.+)
are also single lexemes. The brackets in (Mod.+) have a lexical
purpose, to turn a symbol into an id, which is very different imho
from the use of brackets to parenthesise expressions or form sections.
For example, should a parser consider ( + ) to be an incomplete
parenthesised expression with 2 gaps or an id formed from the
symbol + ? At the moment of course it would be an id but this
causes problems when you're trying to parse Haskell and highlight
incomplete expressions, because you'd expect that if the user
indended to just make an id there wouldn't be any reason to leave
spaces between the symbol and the brackets.
In many ways it would be a lot easier if the (lexical) grammar was
changed so that the turning a symbol into an id would just be
indicated by parentheses round the (unqualified part of the) symbol
alone not the whole thing thus:
Prelude.(+)
so that the first lexical rule would be
1) Parentheses around an unqualifed symbol turns it into an id
Then the ` could be used to turn a (possibly qualified) id into a
symbol:
`Prelude.plus
`Prelude.(+)
and there would be no need for a closing `, so the second rule
would be:
2) A grave before an id turns it into a symbol (that can't
subsequently be turned back into an id!)
There are at least five motivations for suggesting the above changes:
1) It allows operator expressions to be parsed by LL1 recursive
descent :-)
2) The low level details of whether or not a symbol or id is
used is kept to the lexical level
3) You can use a qualified function and an operator without
knowing in advance whether it has been declared as a symbol or an
id in the module. For example, you could type
x `Mod.
and expect to get a pop-up list of functions in Mod, such as (+)
add etc, whereas with the current rules, you'd have to go back and
add graves around the qualified function if the function was
declared as an id and remove the grave if it was already declared
as an operator.
4) Only one grave is needed :-)
5) An editor can give more feedback, by distinguishing between
incomplete expressions and the turning of symbols into ids
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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
Brian Hulley [EMAIL PROTECTED] 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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
Simon Marlow wrote:
Malcolm Wallace wrote:
Brian Hulley [EMAIL PROTECTED] 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.
A question here is: what is a lexeme?
For example there are floating point numbers, which are written without
spaces, but which could be considered to consist of primitive whole-number
lexemes interspersed with . e -
34.678e-98
I don't see what the difference is between them and
Prelude.+
especially since we *really* need the dot for other purposes in the CFG such
as composition and (hopefully at some point) field selection.
Since Prelude.+ is by the above argument a single lexeme, it seems
consistent to say that
`Mod.Id`
(Mod.+)
are also single lexemes. The brackets in (Mod.+) have a lexical purpose, to
turn a symbol into an id, which is very different imho from the use of
brackets to parenthesise expressions or form sections.
For example, should a parser consider ( + ) to be an incomplete
parenthesised expression with 2 gaps or an id formed from the symbol + ? At
the moment of course it would be an id but this causes problems when you're
trying to parse Haskell and highlight incomplete expressions, because you'd
expect that if the user indended to just make an id there wouldn't be any
reason to leave spaces between the symbol and the brackets.
In many ways it would be a lot easier if the (lexical) grammar was changed
so that the turning a symbol into an id would just be indicated by
parentheses round the (unqualified part of the) symbol alone not the whole
thing thus:
Prelude.(+)
so that the first lexical rule would be
1) Parentheses around an unqualifed symbol turns it into an id
Then the ` could be used to turn a (possibly qualified) id into a symbol:
`Prelude.plus
`Prelude.(+)
and there would be no need for a closing `, so the second rule would be:
2) A grave before an id turns it into a symbol (that can't subsequently
be turned back into an id!)
There are at least five motivations for suggesting the above changes:
1) It allows operator expressions to be parsed by LL1 recursive descent
:-)
2) The low level details of whether or not a symbol or id is used is
kept to the lexical level
3) You can use a qualified function and an operator without knowing in
advance whether it has been declared as a symbol or an id in the module. For
example, you could type
x `Mod.
and expect to get a pop-up list of functions in Mod, such as (+) add etc,
whereas with the current rules, you'd have to go back and add graves around
the qualified function if the function was declared as an id and remove the
grave if it was already declared as an operator.
4) Only one grave is needed :-)
5) An editor can give more feedback, by distinguishing between
incomplete expressions and the turning of symbols into ids
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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Editors for Haskell
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Editors for Haskell
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
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Editors for Haskell
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editors for Haskell
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
