Talk:HIDE

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 insert it automatically?"

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

Module level

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.

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

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.

Function Level

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.

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. \a is bell, was it?

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.

more conveniently, XML/HTML text can be handled in a similar way, with the box having a tab for 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".

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.

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