On Wed, Jan 27, 2010 at 09:19 -0500, Ted Unangst wrote: > On Sun, Jan 24, 2010 at 5:22 AM, Ted Unangst <[email protected]> wrote: > > So one of mg's bugs is that it's not extensible. This doesn't > > normally bother me, because I use vi. But I decided to do something > > about it. A full lisp like emacs would be a little crazy, given the > > point is to have a small editor. But tinyscheme isn't too bad. So in > > it goes. > > Let me expand on this point a little more, and ignore the demo for now. > > mg has slowly grown a number of C implemented extensions, but that's > not a scalable future. I think a real extension language is needed to > *prevent* bloat. That's my justification for the feature. Picking > the language used is a process of elimination. We have a couple > choices, but if we're going to keep it light weight, we shouldn't burn > 2k lines on a parser. So our choices are basically lisp or forth. I > assert without proof that forth is the wrong choice. > > It probably wouldn't be hard to implement the core of a lisp > interpreter myself, but I think there's some benefit for trying to > keep the language used close to a standard instead of branching out on > our own. And the two standards are Common Lisp (huge!) or Scheme. I > don't know how much or accurately tinyscheme implements scheme, but at > least at a high level all the documentation I found seems to work. > > I don't think we should worry too much about making mg slow. emacs is > not an editor with lisp, by design it's a lisp environment that > happens to start a text editor by default. I think it's obvious when > you're crossing that line, and we simply don't have to. :) > > Now the released code is, as stated, too early to be considered a > serious proposal. And the web browser extension, well, I needed to > pick something that mg clearly could not do with the existing macro > feature just to make sure this was the right approach. Doesn't mean > we want to include it by default. > > vim has indeed backed itself into a corner. vimscript isn't really > good enough, so there's piles and piles of C code backing it. That's > what I'm trying to avoid. > > Anyway, I'll work on it a little more over time. I just wanted to > show what I've got for interested parties. More to come. >
Frankly, having scheme in without any support for REPL in mg is not that awesome. What makes elisp so handy is an ability to see what happens in realtime while programming (the usual Lisp/REPL development way). Also, it makes more sense to have a R[456]RS-compliant version than just any or "tiny". P.S. mg is buggy and its source code is awful.
