# Talk:HIDE

(Difference between revisions)
 Revision as of 17:33, 1 May 2006 (edit)m ← Previous diff Current revision (23:08, 18 January 2007) (edit) (undo)m (fmt) (7 intermediate revisions not shown.) Line 1: Line 1: - so you are building an IDE for Haskell, right? + == A proposition for hIDE (to make it a unique editor for Haskell) == + '''WARNING!''' This proposal is not well thought and promotes 'artistic' (as opposed to 'pragmatic') views and may have several design limitations. Feel free to contribute as long as you allow yourself to dream. - you have NO idea what an IDE should be like (offence intended). Haskell is a language that needs a decent IDE the ''most''. + === The idea === - now I could say mundane things like "Haskell can ''infer'' types, why don't we have the IDE insert it automatically?" + [http://www.cs.uu.nl/research/projects/proxima/ Proxima] is more like an idea of a very general IDE that has different layers for presenting, editing, and storing documents. hIDE can be a Haskell specific implementation of it. To be precise, hIDE should store Haskell in a tree structure (preferably XML) but provide enough functionality to let the programmer completely forget about this inner representation. Of course, transformers to and fro (literate) Haskell is a must. - but I won't do that. and leave it for the next guy. + === The approach === + Proxima does not advocate a top-down editor. Haskell source code do not have deep tree structure so this is desirable. - 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). + Proxima identifies the different levels of an editor as document level (my translation: raw ASCII code), enriched document level (function and type declaration boundaries), presentation level (syntax highlight), layout level (collapsing, for example), arrangement level (word wrap, margins), and finally, rendering level. + === Separating presentation from representation === + What if we have for all, exists, and logical implication symbols displayed, instead of their ASCII equivalents? may be Greek letters for type variables? - == Module level == + $\mbox{sequence :: Monad }m\mbox{ }\implies\mbox{ }\forall \alpha.\mbox{ }[m\mbox{ }\alpha] \rightarrow m\mbox{ }[\alpha]$ - what does Haskell have here? the module name followed by a where followed by defintions. so indentation would require every definition to be behind the where occurence. 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 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. + This is just a funny way of ''displaying'' the original text - 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! + sequence :: Monad m => [m a] -> m [a] - another innovative(!) idea is to color the ''background'' of the function body that is being exported green, while the default is ivory. + The programmer can click on the displayed image to edit the underlying text. - 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. + What if we do not display the -- or {- -} but instead different colors differentiate code from comments? - == Type level == + Haskell source gets a WYSIWYG editor (almost like modern HTML editors). - 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. + - == Function Level == + The C-style directives can have a different color and folding. - suppose you just wrote "map" and pressed space. the IDE should insert two tiny shady boxes in front of your cursor, the cursor itself being inside the first. so you know there are two parameters. so you write 0 and press space. the IDE should complain it's not a function. so obvious. so you scratch that and say length and press space. the cursor still does not leave the box (it just got bigger to accomodate your cursor inside it now). WTF? what's the point? I mean, you pressed space so that you can say what the second parameter is, right? wrong. you want to finish writing your first parameter (not in this case, though)... I say we make writing down \$'s explicitly a thing long forgotten. press tab to move ahead to the second box so that the IDE can inform you via a floating tooltip that it's expecting a list of lists. a popup list gives you the list of lists available right now (in scope), and if you are not satisfied with that list, press tab again to have (parametic polymorphism taken accounted for) a list of functions that at some level produce a list of lists. + - 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. + === Pros === + * Compact presentation of code + * Faster navigation (based on the structure of the source code) + * The document has to be parsed anyway if we want refactoring, so why not? - == Resource Level == + === Cons === - 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. + * Too much work + * The presentation must be "broken down" in order to edit it - 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. \a is bell, was it? + --[[User:Uchchwhash|Pirated Dreams]] 17:19, 1 May 2006 (UTC) - this sucks. and escaping quote signs. these boxes will be WYSIWYG editors for strings (FastString?). no escaping, no delimiters. well... HTML/XML convensions might be employed when you are working with hieroglyphs or whatever. + == Lemmih's comment on the previous (written with a flu) proposition == - more conveniently, XML/HTML text can be handled in a similar way, with the box having a tab for preview. + So you want a full [http://www.cs.uu.nl/research/projects/proxima/ Proxima] style IDE? - 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. + [[User:Lemmih|Lemmih]] 16:23, 6 May 2006 (UTC) - 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". - == Low Level == + 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. - 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. + --[[User:Uchchwhash|Pirated Dreams]] 12:00, 7 May 2006 (UTC) - --[[User:Uchchwhash|Pirated Dreams]] 17:19, 1 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. + + [[User:Lemmih|Lemmih]] 18:47, 7 May 2006 (UTC) + + : :) Who wants to write a ''great'' IDE? there are too many of those already! --[[User:Uchchwhash|Pirated Dreams]] 08:41, 6 December 2006 (UTC)

## 1 A proposition for hIDE (to make it a unique editor for Haskell)

WARNING! This proposal is not well thought and promotes 'artistic' (as opposed to 'pragmatic') views and may have several design limitations. Feel free to contribute as long as you allow yourself to dream.

### 1.1 The idea

Proxima is more like an idea of a very general IDE that has different layers for presenting, editing, and storing documents. hIDE can be a Haskell specific implementation of it. To be precise, hIDE should store Haskell in a tree structure (preferably XML) but provide enough functionality to let the programmer completely forget about this inner representation. Of course, transformers to and fro (literate) Haskell is a must.

### 1.2 The approach

Proxima does not advocate a top-down editor. Haskell source code do not have deep tree structure so this is desirable.

Proxima identifies the different levels of an editor as document level (my translation: raw ASCII code), enriched document level (function and type declaration boundaries), presentation level (syntax highlight), layout level (collapsing, for example), arrangement level (word wrap, margins), and finally, rendering level.

### 1.3 Separating presentation from representation

What if we have for all, exists, and logical implication symbols displayed, instead of their ASCII equivalents? may be Greek letters for type variables?

$\mbox{sequence :: Monad }m\mbox{ }\implies\mbox{ }\forall \alpha.\mbox{ }[m\mbox{ }\alpha] \rightarrow m\mbox{ }[\alpha]$

This is just a funny way of displaying the original text

sequence :: Monad m => [m a] -> m [a]

The programmer can click on the displayed image to edit the underlying text.

What if we do not display the
--
or
{- -}

Haskell source gets a WYSIWYG editor (almost like modern HTML editors).

The C-style directives can have a different color and folding.

### 1.4 Pros

• Compact presentation of code
• Faster navigation (based on the structure of the source code)
• The document has to be parsed anyway if we want refactoring, so why not?

### 1.5 Cons

• Too much work
• The presentation must be "broken down" in order to edit it

--Pirated Dreams 17:19, 1 May 2006 (UTC)

## 2 Lemmih's comment on the previous (written with a flu) proposition

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)

:) Who wants to write a great IDE? there are too many of those already! --Pirated Dreams 08:41, 6 December 2006 (UTC)