so you are building an IDE for Haskell, right?
you have no idea what an IDE should be like (offence intended). Haskell is a language that needs a decent IDE the most. now I could say mundane things like "Haskell can infer types, why don't we have the IDE check and insert it automatically (with comments)?"
but I won't do that. and leave it for the next guy.
Haskell is a very structured language but the language has different structures at different levels. unless the language goes through a dramatic change, it's not gonna change much. but yes, although the language is simple, when you are writing something in it, you get distracted by simple yet annoying things (some of them have been taught for so long that now people are under the impression that they are inseparable from programming itself).
1 Module level
what does Haskell have here? the module name followed by a where followed by definitions. so indentation would require every definition to be to the right of the where occurrence. what a waste. the IDE should keep modules abstractly. the module keyword, the where clause, just shouldn't be there.
what about the export list? perhaps this is the one thing that makes sense about the module declaration syntax after all. but that basically means writing and commenting on the functions or constructors at two different places. one of them, the export list, has this odd characteristics of being seperated by commas, and you are completely lost where to place your comments. if you put them after the comma, of course, they would logically belong to the next entry.
why not let the IDE take care of that? every function and constructor should have a checkbox that lets you decide whether or not you are exporting it, and it should just pop-up when your cursor is over that function name!
another innovative(!) idea is to color the background of the function body that is being exported green (or, ionno, light magenta), while the default is ivory.
importing should be just like that. with hiding something being as easy as ticking the box off. should there be a name clash, the IDE itself should complain.
2 Type level
at this level Haskell is so concise that nothing significant can be done I guess... apart from occasionally helping the programmer with the list of classes this type instantiates, or perhaps detect clashes like overlapping instances instantly. may be it's too late at night and my head's not working.
hang on, what if we have for all, exists, and logical implication symbols at this level? may be greek letters for type variables?
is this a proposed language change? no! this is just a funny way of displaying the original text sequence :: Monad m => [m a] -> m [a]
3 Function Levelsuppose you just typed
indentation is interesting. you type where and the box you enter grows downwards when you type enter but stays to the right of the where keyword. of course, the box is collapsible.
of course, I won't certify a Haskell IDE "reasonable" unless it has a drop down list of the possible constructors of a sum type when doing a case analysis (or pattern matching).
4 Resource Level
now this is new! now that you have little boxes to insert things into, let's imagine you can mark these floating boxes with shades in the background and no annoying borders just by moving the move over the start of the box where suddenly a combo box like arrow shows up (like MS Word auto correct thingie) and you can select what the content of the box is. use your imagination. I'm going to use strings.
what is the first thing you learned when you started programming? that when you are programming, it's just plain text being manipulated by a weak manipulator being parsed linearly (one-pass) and so \n means new line, \t means tab (which you, now a days, don't use at all!) \r is .. erm, well, depends on your operating system why you are gonna need that, \f is a form feed (what the hell is that anyway?). \a is bell, was it?this sucks. and escaping quote signs. these boxes will be WYSIWYG editors for strings (
interpolation should be as easy as inserting a code box inside the string box.
more conveniently, XML/HTML text can be handled in a similar way, with the box being a tabbed pane containing preview.
the most important thing ever is the comments. syntax highlighting does help, but there is a nasty rule saying a documentation piece is followed by a piece of code it belongs to. this sucks. let there be a boundary for each function, anything written with the "comment" font(!) is a comment. yes, perhaps there should be a tool button with which instead of picking fonts you pick what kind of a thing you are about to enter.
commenting and uncommenting being as easy as selecting and changing "font" should make experimenting with different implementations very easy while making sure you don't lose your deprecated code. debugging code can have a different "font".
5 Low Level
so what am I really asking for? code kept in a structure, rather than a text file. half-digested already. when communicating with the compiler itself, it can always regenerate what's hidden. line numbers, guys, can be calculated.
so you want the IDE to be written in Haskell? why don't we have a guru with us enjoying the ride with us? the point is, if someone deeply involved with Haskell's type system is forced to write GUI applications, surely his/her concept of programming will be turned upside down. who knows, the type system might have to face innovations and renovations.
--Pirated Dreams 17:19, 1 May 2006 (UTC)
So you want a full Proxima style IDE?
Lemmih 16:23, 6 May 2006 (UTC)
hell yeah, man, thanks for the link. I'm checking it out. why don't you build it on top of Proxima, should be easy enough. --Pirated Dreams 12:00, 7 May 2006 (UTC)
The guy wrote a 200 page long PhD thesis on the topic, and even then, didn't solve all the problems. In my opinion, writing a great IDE isn't trivial. If you disagree, feel free to take the first step.
Lemmih 18:47, 7 May 2006 (UTC)