Hi Deniz, Deniz Dogan skrev:

I don't think it's a good idea (or even possible) to use a Haskell library without knowing anything about Haskell or functional programming. However, it shouldn't take too long to learn the very

Well, I guess I was asking for a tutorial which covers everything except the parts that are not normally relevant for a DSEL user. For example, I would expect the following to be left out: * Definition of data types and classes * Laziness * Monad internals * IO * etc. Things that I think should be covered: * Polymorphism * Higher-order functions * Lists * Recursion * Monadic combinators * etc. Of course, the requirements may vary from case to case, but you get the idea.

Take some the time to read the parts that are relevant to you in e.g. Learn You a Haskell for Great Good (http://learnyouahaskell.com/)

Seems like a nice and gentle tutorial, somewhat like what I imagined. However, it also seems a bit too "high school"-oriented for the audience I currently have in mind :) / Emil (who may try to write this tutorial himself at some point)

Deniz Dogan wrote:

Learn You a Haskell for Great Good (http://learnyouahaskell.com/)

Mmm, interesting. Does anybody else think it would be neat if GHCi really did colourise your input like that? (Or at least display the prompt in a different colour to user input and program output?)

On Mon, 2009-02-02 at 20:55 +0000, Andrew Coppin wrote:

Deniz Dogan wrote:

...

Learn You a Haskell for Great Good (http://learnyouahaskell.com/)

Mmm, interesting.

Does anybody else think it would be neat if GHCi really did colourise your input like that?

Bleah. More terminal hacking to break and/or slow Emacs to a crawl? No thanks. jcc

On Fri, 2009-02-06 at 08:30 +0100, Achim Schneider wrote:

Jonathan Cast wrote:

...

On Mon, 2009-02-02 at 20:55 +0000, Andrew Coppin wrote:

...

Deniz Dogan wrote:

...

Learn You a Haskell for Great Good (http://learnyouahaskell.com/)

Mmm, interesting.

Does anybody else think it would be neat if GHCi really did colourise your input like that?

Bleah. More terminal hacking to break and/or slow Emacs to a crawl? No thanks.

A while ago, I'd say that emacs looks like a decent operating system, sadly lacking a decent editor.

I always wonder how many people who say that have actually *tried* Emacs' editor.

Now it seems that it's even lacking a decent terminal.

Actually, I think the issue is just that Emacs' ANSI color parsing code is effectively O(n^2); when I really, really need colored output I run the command in a separate window (with B&W output) and switch major modes. Emacs' terminal is also lacking all the modern conveniences, like addressable cursors and builtin line-editing designed for 1970s printing terminals and practically no searching capabilities. Alternatively, you could say it's incompatible with modern Unix's biggest mistakes and worst legacy issues.

I'm really not sure what to make of all that: Would you recommend using it?

Of course. It sucks the least of any solution I've tried. Barely.

Eternal flamewars cast aside, what about integrating such a thing into yi? Yi has the advantage of working for both masochists _and_ efficient typists.

Yi has a terminal? Maybe I should try it again. jcc

On Fri, 2009-02-06 at 14:56 +0100, Deniz Dogan wrote:

2009/2/6 Jonathan Cast :

...

Emacs' terminal is also lacking all the modern conveniences, like addressable cursors and builtin line-editing designed for 1970s printing terminals and practically no searching capabilities. Alternatively, you could say it's incompatible with modern Unix's biggest mistakes and worst legacy issues.

With the risk of making this even more OT:

Emacs has three different types of shells built-in, at least to my knowledge. These are M-x shell, eshell and term. I'm not sure which one you are referring to as "Emacs' terminal", if any of them, but inf-haskell.el uses "shell" afaics.

I believe so. But the colorization support in shell-mode is supplied by comint; comint does fine with colorization normally, but I've had problems with large files in the past. (E.g., comint can't handle the colorized output from a full run of the test suite at work).

And what do you mean with "no searching capabilites?" What kind of searching are we talking here?

Emacs' incremental search (C-r, C-s). Remember that my list is a (sarcastic) list of advantages of M-x shell (and comint) over full-blown Unix terminal emulators --- I had mis-remembered that Konsole and GnomeTerm lacked builtin search capabilities. (Checking, I see that Konsole (KDE 3.5.10, which is what I have at work) does have poorish search support. But Emacs' search is still better!). jcc