Difference between revisions of "Talk:HIDE"
Jump to navigation
Jump to search
Uchchwhash (talk | contribs) m |
Uchchwhash (talk | contribs) m (fmt) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 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. |
||
| ⚫ | |||
| − | you have ''no'' idea what an IDE should be like (offence intended). Haskell is a language that needs a decent IDE the ''most''. |
||
| + | [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. |
||
| − | 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)?" |
||
| + | === The approach === |
||
| − | but I won't do that. and leave it for the next guy. |
||
| + | 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. |
||
| − | 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). |
||
| + | === Separating presentation from representation === |
||
| ⚫ | |||
| ⚫ | |||
| − | == 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. |
||
| + | This is just a funny way of ''displaying'' the original text |
||
| − | 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. |
||
| + | <hask>sequence :: Monad m => [m a] -> m [a]</hask> |
||
| − | 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! |
||
| + | The programmer can click on the displayed image to edit the underlying text. |
||
| − | 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. |
||
| + | What if we do not display the <hask>--</hask> or <hask>{- -}</hask> but instead different colors differentiate code from comments? |
||
| − | 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. |
||
| + | Haskell source gets a WYSIWYG editor (almost like modern HTML editors). |
||
| − | == 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. |
||
| + | The C-style directives can have a different color and folding. |
||
| ⚫ | |||
| + | === 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? |
||
| + | === Cons === |
||
| − | 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]''' |
||
| + | * Too much work |
||
| + | * The presentation must be "broken down" in order to edit it |
||
| ⚫ | |||
| − | == Function Level == |
||
| − | suppose you just typed <hask>map</hask> and pressed the spacebar. 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 <hask>0</hask> and press space. the IDE should complain it's not a function. so obvious. so you scratch that and say <hask>length</hask> and press the spacebar again. 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 <hask>$</hask>s explicitly a thing long forgotten (I'm a newbie, as you can imagine, and <hask>$</hask>s just send a pulse of panic to my brain). 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. |
||
| + | == Lemmih's comment on the previous (written with a flu) proposition == |
||
| − | 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. |
||
| + | So you want a full [http://www.cs.uu.nl/research/projects/proxima/ Proxima] style IDE? |
||
| − | 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). |
||
| + | [[User:Lemmih|Lemmih]] 16:23, 6 May 2006 (UTC) |
||
| − | == 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? |
||
| + | 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. |
||
| − | this sucks. and escaping quote signs. these boxes will be WYSIWYG editors for strings (<hask>FastString</hask>?). no escaping, no delimiters. well... HTML/XML convensions might be employed when you are working with hieroglyphs or whatever. |
||
| + | --[[User:Uchchwhash|Pirated Dreams]] 12:00, 7 May 2006 (UTC) |
||
| − | interpolation should be as easy as inserting a ''code'' box inside the ''string'' box. |
||
| + | 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. |
||
| − | more conveniently, XML/HTML text can be handled in a similar way, with the box being a tabbed pane containing preview. |
||
| + | [[User:Lemmih|Lemmih]] 18:47, 7 May 2006 (UTC) |
||
| − | 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. |
||
| + | : :) Who wants to write a ''great'' IDE? there are too many of those already! --[[User:Uchchwhash|Pirated Dreams]] 08:41, 6 December 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". |
||
| − | |||
| ⚫ | |||
| − | 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. |
||
| − | |||
| − | cheers! |
||
| − | |||
| ⚫ | |||
Latest revision as of 23:08, 18 January 2007
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.
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.
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.
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?
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 {- -} but instead different colors differentiate code from comments?
Haskell source gets a WYSIWYG editor (almost like modern HTML editors).
The C-style directives can have a different color and folding.
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?
Cons
- Too much work
- The presentation must be "broken down" in order to edit it
--Pirated Dreams 17:19, 1 May 2006 (UTC)
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)