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.
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.
I see no reason you couldn't add an embedded lisp to Yi. It's actually on my list of things to try eventually. I do agree the compile step is annoying but I've found myself frustrated enough times with elisp's:
* dynamic scoping. The lack of closures is pretty limiting.
I can live without the objects and inheritance but I really really want closures.
* key bindings parsing. Vimpulse is basically incapable of implementing some of my most often used vim commands because of the way the key bindings are parsed.
Both of those things prompted me to go looking for an alternative and this is what I found. It's been fun so far, perhaps I'll hit a wall again and get dissatisfied but for now it's a handy hack on something in haskell project.
Agree, but I feel like the Emacs core is more stable and complete than the Yi core. Every time I try to do something with Yi, I think, "oh, that's why I still use Emacs".
Perfectly understandable. However I need something to hack on in haskell to polish my skills so I figure I can just use emacs while I work to make Yi useable for everyday.
I miss Hugs (http://www.haskell.org/hugs/) for this reason. ghci is up to date, yes, but Hugs was much nicer as an environment. I even used to use it as my default calculator :) sigh!
> (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.)
No you don't. You must've gotten use to old versions while this is true. Make your change and then restart right away -- if it won't compile you'll get an error popup but xmonad will continue chugging along merrily by running the last good version of your xmonad.hs.
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.
An mp3 player and a calendar are not operating systems. If your contention is that C is terrible for actual OS development you'll need a better argument.
UNIX gives top-level (userland, not root) programs a "raw access to registers and the memory allocator". Incredibly low level things which aren't needed, and are a source of errors, some of which are security breaches. This is bad™.
The question is "why did they do that" ? The most obvious answer is C: If you write your OS in C, you will most likely make C-like APIs, which don't properly hide low-level stuff, but are easier to implement (the "Worse is Better" principle).
Wait, you want the OS to do memory allocation of individual variables and garbage collection?
And if you are writing X86 code you don't have a choice about register access - and why is that a problem anyway?
Do you want an OS that is actually a virtual machine? I don't. I want an OS that lets me use my CPU.
> If you write your OS in C, you will most likely make C-like APIs,
That's a fundamental misunderstanding. The API are written for the _hardware_. Did you forget there was an actual computer in there? It's nice and all to go high level, but at the end of the day you have a CPU and memory and you need to use it.
> Wait, you want the OS to do memory allocation of individual variables and garbage collection?
Almost, if not outright yes. Current OS'es already do manage memory in some ways, so they could as well do more work, so you don't have to re-invent that wheel every time you write a new compiler. Having a full blown virtual machine as an OS actually sound very promising : you can for instance migrate from X86 to ARM transparently, re-compiling nothing but the kernel. You can reduce hardware support for fancy features, simplifying it.
Now, a good enough compromise could be a layer of compatibility for a garbage collected language. And we already have plenty of these.
> The API are written for the _hardware_.
You got that backwards. The API is written for humans to use the hardware. If the hardware is complex and quirky, it's the job of the API to make it simple and straightforward. It's nice and all to go low level, but at the end of the day you have to get things done. You sound like you need every last drop of performance out of your CPU. When you really do, then you may want to do your work in kernel space with no runtime check at all. But most of the time, you don't.
To sum up, an OS written in C will most likely have a C-like API (I note that you didn't disagree with that). There's still the high-level vs low-level debate, but it basically has the same structure as the GPL vs BSD debate. I prefer high-level and GPL, on the grounds that they eventually enable more. You seem to prefer low level (and BSD?), on the grounds that they permit more (which is not the same at all). We could go on, but if we actually disagree on that point, I don't know how we could convince each other.
In practice high level is more complex and quirky then low.
Low level has just a few well defined interfaces. High level has tons, and high level is not flexible either.
An OS will have a C like API not because of C, but because that's how computers work. C was written to copy the computer.
And what I said has nothing to do with GPL vs BSD, I don't think your analogy applies. And I don't agree with what you assume I meant about high/low permit/enable.
I simply said that an OS is made to handle an actual real computer, and it's written that way. It has nothing to do with C, it has to do with hardware.
Personally I prefer a mix - define the low level and allow using it. On top of that make tons of high level helper functions, but always make sure that even if you use the high level functions you are still allowed to use the low level if you want.
> I simply said that an OS is made to handle an actual real computer, and it's written that way. It has nothing to do with C, it has to do with hardware.
This is one of the most widespread and major misunderstanding about computers. Computer science is not about computers; Just like astronomy is not about telescopes (Dijkstra).
The only thing that really matter about computers is that they are communicating Turing-complete machines. Every communicating Turing-complete hardware on the planet is therefore the same, modulo the necessary emulation layer (performance is becoming secondary, so let's pretend it's not a problem).
What we want as humans is communicating Turing-complete machines that are easy to use. That's a fact about us, not about hardware. Therefore, OS APIs should depend on us, not on hardware. Having an OS whose API is influenced by the actual hardware is a pity. Making an OS whose API is influenced by the actual hardware is a shame.
For most people, "operating system" is not synonymous with "kernel". I like C, but a lot of userland programs that are often considered to offer "operating system" functionality could tolerate being written in a safer language. OTOH, C is probably "good enough" as the lingua franca.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.