Re: Extension Languages

> IS there any specific reason why one would choose to utilise an prefix
> notation language for extensions to an editor as opposed to infix orr
> post-fix?


I think Emacs uses Lisp as its base language because Lisp is so well
adapted to running interpretively and in a constantly changing
environment. Also, because of its simpler syntax, I'd argue that you get
more "bang for your buck," i.e., the size of the interpreter is fairly
small compared to the amount of functionality you get.


In Lisp this comes mainly from its uniform treatment of code and data
structures; since it's interpreted out of data structures that have had
very little preprocessing, it would need to do substantial parsing on the
fly in order to support C-like infix notation.


You can think of a spectrum of linguistic simplicity vs. ease of use by
human programmers:


  notation: infix prefix postfix
  example: C, Pascal Lisp Forth, PostScript
  syntax: parens, opers, ... parentheses "none"
  humans: easy okay hard
  machines: hard okay easy


Languages on the left end of this spectrum require a lot of parsing effort
(relatively speaking) and have a lot of redundancy in their grammars,
which translates to being fairly easy for humans to read and work with.
Languages on the right end have absolutely minimal syntax (generally just
a linear sequence of words, without even parentheses to make the grouping
clear), which makes them trivial to implement but hard to use. Lisp comes
in the middle, being reasonably easy and cheap to implement, and
reasonably easy for human programmers to use.


There's nothing stopping you from doing a Lisp-like language that uses
postfix operators, but people generally don't because the interpreter has
an easier time of it if the operator comes first. I've also seen
languages which are Lisp-like in essence, but with C-like parsers added on
top to make them more palatable. In other words, they have a parser which
reads "a+b" into the list "(+ a b)". This can be a big help for novices,
but Lisp purists prefer to work directly with the list representation so
that they know what they're dealing with.


With a good indenting editor like Emacs, Lisp can be quite easy to read
despite the sparse syntax. With some experience it becomes just as
readable as a C-like language for anything except heavy arithmetic (where
infix is still the Right Answer). My own experience with PostScript is
that it doesn't scale as well; I've never seen an automatic indenter for
it, and it's not clear that tricks like indentation could ever be as
illuminating for it as they are for Lisp.


Despite its being "just" an editor extension language, I've written a
successful 50,000 line application in Emacs Lisp (Emacs Calc). I've seen
other Emacs applications and editing packages which were, if not that
large, at least large enough to be feasible only in a fairly "real"
language. I don't think I could ever do something as ambitious as Calc in
PostScript; even though the language is, technically speaking, strong
enough for such a task, I'd go nuts trying to keep track of it all.


Interestingly, Emacs includes an Emacs Lisp compiler that translates to a
byte-coded stack machine which is probably similar to the stack language
that John Davis described here recently. Emacs's byte-code interpreter is
probably less bulletproof than John's, and therefore more streamlined,
since it knows the byte codes will only come from a (presumably correct)
byte-compiler. So even Emacs finds a tight postfix system to be most
efficient, though too crufty to expect humans to use directly.


-- Dave
--

Return to the comp.compilers page.
Search the comp.compilers archives again.