6 ms·

Yi an editor written in Haskell

66 points by zaphar 16y ago

zaphar 16y ago
I've recently taken an interest in this editor after reaching various levels of dissatisfaction with both vim and emacs. I can get almost an perfect clone of the modal editing of vim with the hackability of emacs. It still needs some love but I've already submitted two patches and the developers were really supportive. If your looking for an excuse to do some haskell coding this might be a good option for you.
- Ixiaus 16y ago
  Emacs sates my needs well - the only downside is how ancient Emacs Lisp is. Haskell is a much more elegant language (and up to date); it would be an excellent replacement, only problem is producing all of the "modes" that I use in Emacs for Yi.
  - jrockway 16y ago
    But actually, your editor macros will read almost the same in Haskell as they do in Emacs Lisp. Some things like complicated data processing are better in Haskell, but mostly because of the speed, not the syntax. (Compare your .emacs to your xmonad.hs.) Emacs Lisp is not particularly ancient anyway, changes are committed every day.
    - cscheid 16y ago
      Anything with dynamic scoping belongs squarely in the ancient category. We're about a decade overdue for replacing Elisp with Scheme.
      - jrockway 16y ago
        Everything has dynamic scoping. Emacs 24 has lexical scoping, too. But honestly, lexical scoping reduces the chance of introducing unwanted binding at the cost of reducing the ease of "accidental" customization. Emacs' "nothing is closed" policy has worked very well for a lot of developers and users over the years. With enforced privacy, we're on the way to Eclipse, which can only be customized by 100 man teams working 18 hour days. Remember, Emacs is not your backend batch processing app. You are always in front of it, interacting with it -- if it fucks up, you fix the bug right there because you are right there.
        dataangel 16y ago
        Everything has dynamic scoping. How the heck do you figure that? The majority of languages after emacs lisp specifically avoid dynamic scoping.
        jrockway 16y ago
        Perl has it, Python has it, Ruby has it, PHP has it, Haskell has it...
        cscheid 16y ago
        How exactly does Haskell have dynamic scoping? An appropriate monad does not count.
      - loewenskind 16y ago
        Anything that only has dynamic scoping. I look forward to the day that anything that doesn't support dynamic scoping is considered ancient. It's really helpful when you need it.
    - Ixiaus 16y ago
      Good points - when I said it [ELisp] was ancient I was referring to the "dynamic scope" argument someone else deeper in the thread already mentioned. I've read a lot of conflicting opinions about it so I suppose I should stop assuming it is either good or bad and actually create my own opinion of it by doing my own research.
  - swah 16y ago
    Emacs is state all around - that can't be easy or elegant to replace with a purely functional language - or not ?
- jrockway 16y ago
  I don't think it's as hackable as Emacs. For one thing, you have to recompile Yi after every change. Sure, it's automated, but with Emacs, the change takes place immediately. (When I write XMonad extensions, I do find the process a little tedious. I have to type my extension, then see if ghci can compile it, then I have to press a key to recompile and reload xmonad, then I can try out my changes. Every. Time. In Emacs, I just press C-M-x and try my change immediately.) Really, there are two parts to editor extension. Some things are interactive hacks, and some things are structured sub-programs. Things like SLIME and CEDET are sub-programs, and they would benefit greatly from a more expressive (and faster-running language). But everything else benefits from the do-anything-you-want style of Emacs Lisp, because you can develop your development environment interactively. It's really a wonderful experience, even though you don't have closures or classes with multiple inheritance. One of my plans for the future is to replace the C core of GNU Emacs with Haskell, so that complex extensions can be more easily implemented. But Emacs Lisp will still be around for when "scripting" is good enough.
  - swah 16y ago
    Can you say what would be a complex extension to you? vc.el, erc, ediff, slime are doing well with elisp... In some way also, the most complex the extension, the more reasons you have to use a higher level language, no?
    - jrockway 16y ago
      Sure, you can manage with elisp, but it's not always the best possible way. The UNIX folks built a pretty good OS in C, even though C is a terrible language for writing an OS in. Have you ever used Gnus? Have you noticed that if you have more than 10 message in an mbox or 100 in a maildir or 1000 on an IMAP server that it becomes unusably slow? Profile, and you'll see all the time is spent doing the parsing in elisp. Having the option of using a different language that compiles to native code would make these extensions faster and equally easy to write. Use elisp for the stuff that the users are going to play with; drop down to Haskell for the data structures that manage the mail. Best of both worlds. People are always able to bend their tools to perform the work they want them to do. Ever use a flathead screwdriver to turn a phillips-head screw? It works. But it's a lot easier when you use the phillips-head screwdriver.
- deleted 16y ago
  [deleted]
- silentbicycle 16y ago
  Despite all of Emacs Lisp's faults, I don't think Haskell is a good substitute.* Haskell's design is centered around a compile phase, for static analysis and warnings. While this has advantages, it compares poorly with what elisp gives you - sure, it's a bad parody of a Lisp, but you can still rebind large portions of the system while working in it, with imperceptible downtime. * I also don't like Haskell, but wouldn't suggest OCaml either. (Lua seems born for the role, though.) I got burned hard by settling in with XMonad, only to find out that they didn't care about portability ("avoid success at all costs") - BIG waste of my time. I went back to C for my window manager. C was more stable than Haskell!
  - vito 16y ago
    Speaking of Lua and text editors, I've been keeping my eye on this for a while: http://code.google.com/p/textadept/ http://code.google.com/p/textadept/
    - silentbicycle 16y ago
      I think it's a great project, but I've got different taste in editors than that person. I would love to have an Emacs-like editor (scriptable, multiple buffers, no GUI or menus) that 1. used Lua instead of elisp, and 2. had a vi-style modal keyboard interface rather than primarily chorded keys. Oh, and not being tied to GTK is nice - I like being able to use Emacs in shells, from screen/tmux, etc. One of these days I might give in and write one, but I've already got too many projects going.
      - vito 16y ago
        Agreed. Being bound to GTK is no fun - I tried it on OS X and it was very sluggish and janky. Was very fun in Linux though.
    - lemming 16y ago
      Wow, I've been thinking about almost exactly this for a while now. I'll have to give this a try.
xtacy 16y ago
Is there a Carbon/Cocoa based version available for OSX?
- zaphar 16y ago
  There is some code for it but I'm not sure how far along it is. I don't think the Cocoa UI is very useable yet though.
  - Hemospectrum 16y ago
    In fact, at one time it was usable, but it has gotten less so, assuming it even still compiles.
    - gaius 16y ago
      The last I looked at Yi on OSX (about 3 months ago) it fails to recompile due to an incompatibility between Haskell package Dyre and the OS. So you can use it but never configure it.
deleted 16y ago
[deleted]
- contextfree 16y ago
  I ran into the same gtk2hsC2hs problem while installing yi myself a couple weeks ago, and I eventually got past it, but ... I completely forget how I did, sorry. I think gtk2hsC2hs is actually a non-Cabal-managed native application that needs to be installed separately?
  - jrockway 16y ago
    The package is called gtk2hs-buildtools. I think cairo's cabal file is wrong.
    - alec 16y ago
      I ran into this the other day, too. According to a gtk2hs developer, it's a limitation in cabal: http://sourceforge.net/mailarchive/message.php?msg_name=46AAE0E9-1A2D-4403-96B2-75200F4BD884%40in.tum.de http://sourceforge.net/mailarchive/message.php?msg_name=46AA...
mhd 16y ago
Let's hope this has a better future than Efuns[1], the Ocaml emacs clone. More likely that most of its unique features will be assimilated into vim plugins and Emacs modes. [1]: http://pauillac.inria.fr/cdrom_a_graver/prog/unix/efuns/eng.htm http://pauillac.inria.fr/cdrom_a_graver/prog/unix/efuns/eng....

66 points by zaphar 16y ago

I've recently taken an interest in this editor after reaching various levels of dissatisfaction with both vim and emacs. I can get almost an perfect clone of the modal editing of vim with the hackability of emacs. It still needs some love but I've already submitted two patches and the developers were really supportive. If your looking for an excuse to do some haskell coding this might be a good option for you.

Ixiaus 16y ago
Emacs sates my needs well - the only downside is how ancient Emacs Lisp is. Haskell is a much more elegant language (and up to date); it would be an excellent replacement, only problem is producing all of the "modes" that I use in Emacs for Yi.
- jrockway 16y ago
  But actually, your editor macros will read almost the same in Haskell as they do in Emacs Lisp. Some things like complicated data processing are better in Haskell, but mostly because of the speed, not the syntax. (Compare your .emacs to your xmonad.hs.) Emacs Lisp is not particularly ancient anyway, changes are committed every day.
  - cscheid 16y ago
    Anything with dynamic scoping belongs squarely in the ancient category. We're about a decade overdue for replacing Elisp with Scheme.
    - jrockway 16y ago
      Everything has dynamic scoping. Emacs 24 has lexical scoping, too. But honestly, lexical scoping reduces the chance of introducing unwanted binding at the cost of reducing the ease of "accidental" customization. Emacs' "nothing is closed" policy has worked very well for a lot of developers and users over the years. With enforced privacy, we're on the way to Eclipse, which can only be customized by 100 man teams working 18 hour days. Remember, Emacs is not your backend batch processing app. You are always in front of it, interacting with it -- if it fucks up, you fix the bug right there because you are right there.
      - dataangel 16y ago
        Everything has dynamic scoping. How the heck do you figure that? The majority of languages after emacs lisp specifically avoid dynamic scoping.
        jrockway 16y ago
        Perl has it, Python has it, Ruby has it, PHP has it, Haskell has it...
        cscheid 16y ago
        How exactly does Haskell have dynamic scoping? An appropriate monad does not count.
    - loewenskind 16y ago
      Anything that only has dynamic scoping. I look forward to the day that anything that doesn't support dynamic scoping is considered ancient. It's really helpful when you need it.
  - Ixiaus 16y ago
    Good points - when I said it [ELisp] was ancient I was referring to the "dynamic scope" argument someone else deeper in the thread already mentioned. I've read a lot of conflicting opinions about it so I suppose I should stop assuming it is either good or bad and actually create my own opinion of it by doing my own research.
- swah 16y ago
  Emacs is state all around - that can't be easy or elegant to replace with a purely functional language - or not ?
jrockway 16y ago
I don't think it's as hackable as Emacs. For one thing, you have to recompile Yi after every change. Sure, it's automated, but with Emacs, the change takes place immediately. (When I write XMonad extensions, I do find the process a little tedious. I have to type my extension, then see if ghci can compile it, then I have to press a key to recompile and reload xmonad, then I can try out my changes. Every. Time. In Emacs, I just press C-M-x and try my change immediately.) Really, there are two parts to editor extension. Some things are interactive hacks, and some things are structured sub-programs. Things like SLIME and CEDET are sub-programs, and they would benefit greatly from a more expressive (and faster-running language). But everything else benefits from the do-anything-you-want style of Emacs Lisp, because you can develop your development environment interactively. It's really a wonderful experience, even though you don't have closures or classes with multiple inheritance. One of my plans for the future is to replace the C core of GNU Emacs with Haskell, so that complex extensions can be more easily implemented. But Emacs Lisp will still be around for when "scripting" is good enough.
- swah 16y ago
  Can you say what would be a complex extension to you? vc.el, erc, ediff, slime are doing well with elisp... In some way also, the most complex the extension, the more reasons you have to use a higher level language, no?
  - jrockway 16y ago
    Sure, you can manage with elisp, but it's not always the best possible way. The UNIX folks built a pretty good OS in C, even though C is a terrible language for writing an OS in. Have you ever used Gnus? Have you noticed that if you have more than 10 message in an mbox or 100 in a maildir or 1000 on an IMAP server that it becomes unusably slow? Profile, and you'll see all the time is spent doing the parsing in elisp. Having the option of using a different language that compiles to native code would make these extensions faster and equally easy to write. Use elisp for the stuff that the users are going to play with; drop down to Haskell for the data structures that manage the mail. Best of both worlds. People are always able to bend their tools to perform the work they want them to do. Ever use a flathead screwdriver to turn a phillips-head screw? It works. But it's a lot easier when you use the phillips-head screwdriver.
deleted 16y ago
[deleted]
silentbicycle 16y ago
Despite all of Emacs Lisp's faults, I don't think Haskell is a good substitute.* Haskell's design is centered around a compile phase, for static analysis and warnings. While this has advantages, it compares poorly with what elisp gives you - sure, it's a bad parody of a Lisp, but you can still rebind large portions of the system while working in it, with imperceptible downtime. * I also don't like Haskell, but wouldn't suggest OCaml either. (Lua seems born for the role, though.) I got burned hard by settling in with XMonad, only to find out that they didn't care about portability ("avoid success at all costs") - BIG waste of my time. I went back to C for my window manager. C was more stable than Haskell!
- vito 16y ago
  Speaking of Lua and text editors, I've been keeping my eye on this for a while: http://code.google.com/p/textadept/ http://code.google.com/p/textadept/
  - silentbicycle 16y ago
    I think it's a great project, but I've got different taste in editors than that person. I would love to have an Emacs-like editor (scriptable, multiple buffers, no GUI or menus) that 1. used Lua instead of elisp, and 2. had a vi-style modal keyboard interface rather than primarily chorded keys. Oh, and not being tied to GTK is nice - I like being able to use Emacs in shells, from screen/tmux, etc. One of these days I might give in and write one, but I've already got too many projects going.
    - vito 16y ago
      Agreed. Being bound to GTK is no fun - I tried it on OS X and it was very sluggish and janky. Was very fun in Linux though.
  - lemming 16y ago
    Wow, I've been thinking about almost exactly this for a while now. I'll have to give this a try.

xtacy 16y ago

Is there a Carbon/Cocoa based version available for OSX?

zaphar 16y ago
There is some code for it but I'm not sure how far along it is. I don't think the Cocoa UI is very useable yet though.
- Hemospectrum 16y ago
  In fact, at one time it was usable, but it has gotten less so, assuming it even still compiles.
  - gaius 16y ago
    The last I looked at Yi on OSX (about 3 months ago) it fails to recompile due to an incompatibility between Haskell package Dyre and the OS. So you can use it but never configure it.

deleted 16y ago

[deleted]

contextfree 16y ago
I ran into the same gtk2hsC2hs problem while installing yi myself a couple weeks ago, and I eventually got past it, but ... I completely forget how I did, sorry. I think gtk2hsC2hs is actually a non-Cabal-managed native application that needs to be installed separately?
- jrockway 16y ago
  The package is called gtk2hs-buildtools. I think cairo's cabal file is wrong.
  - alec 16y ago
    I ran into this the other day, too. According to a gtk2hs developer, it's a limitation in cabal: http://sourceforge.net/mailarchive/message.php?msg_name=46AAE0E9-1A2D-4403-96B2-75200F4BD884%40in.tum.de http://sourceforge.net/mailarchive/message.php?msg_name=46AA...

mhd 16y ago

Let's hope this has a better future than Efuns[1], the Ocaml emacs clone. More likely that most of its unique features will be assimilated into vim plugins and Emacs modes. [1]: http://pauillac.inria.fr/cdrom_a_graver/prog/unix/efuns/eng.htm http://pauillac.inria.fr/cdrom_a_graver/prog/unix/efuns/eng....