Guile, elisp
Damien R. Sullivan
and that Guile is analogous for Scheme. Can anyone expand on these issues?
-xx- Damien X-)
Christopher Browne
> I've gotten the impression that elisp isn't considered a real or good Lisp,
> and that Guile is analogous for Scheme. Can anyone expand on these issues?
Elisp is a very archaic form of Lisp, essentially predating both
Scheme and Common Lisp, neither of which are particularly new
languages.
The vital problem is that it is _strongly_ tied to the use of dynamic
scope, which makes it difficult to use lexical-scoping-related
techniques to compile to machine code to make it Real Fast. Elisp
doesn't "do threading," either.
It's still usable enough for writing extensions to Emacs, but it's not
what you'd want to use for new systems.
Guile has certain parallels. It started as a "fork" of SCM, intended
as an easily-embeddable Scheme-in-C. Unfortunately, from there it has
grown to be a heavyweight (lots of code, lots of memory) system that's
one of the slowest Scheme implementations around. It's usable enough
for many purposes, but again, if you're starting a system from
scratch, and are looking for a Scheme to use/embed, Guile won't likely
be your first choice.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www3.sympatico.ca/cbbrowne/lisp.html
"Surely if the world can't get any other benefit from the existence of
Microsoft, at least people should stop arguing that popularity has any
connection with merit!" -- Brian Harvey <b...@anarres.CS.Berkeley.EDU>
cr88192
Lisp,
> > and that Guile is analogous for Scheme. Can anyone expand on these
issues?
>
> Elisp is a very archaic form of Lisp, essentially predating both
> Scheme and Common Lisp, neither of which are particularly new
> languages.
>
> The vital problem is that it is _strongly_ tied to the use of dynamic
> scope, which makes it difficult to use lexical-scoping-related
> techniques to compile to machine code to make it Real Fast. Elisp
> doesn't "do threading," either.
>
> It's still usable enough for writing extensions to Emacs, but it's not
> what you'd want to use for new systems.
>
> Guile has certain parallels. It started as a "fork" of SCM, intended
> as an easily-embeddable Scheme-in-C. Unfortunately, from there it has
> grown to be a heavyweight (lots of code, lots of memory) system that's
> one of the slowest Scheme implementations around. It's usable enough
> for many purposes, but again, if you're starting a system from
> scratch, and are looking for a Scheme to use/embed, Guile won't likely
> be your first choice.
I wonder if it can be much worse than mine?...
luckily at least my interpreter can shed all the extra stuff (leaving me
with just the 13k line core), but really the core is pretty bare (lacking
even a gc, which is viewed as a seperate entity, and has a cost of about 3k
lines, but would come with persistence capabilities...).
there is a "secondary core" which is about 40k lines (including primary
core), this includes much of the system except the net/graphics/... stuff,
which is about 22k lines.
I may even be moving the object system out of the primary core, at least in
part, as it will take some fairly signifigant alterations to make it work
effectively for shared consistency, though I may just create an "alternate"
object system. actually given the way my system is implemented having
parallel object systems (but with very similar behavior/properties/...) is a
possibility, and would not effect things that much (mostly as I have the
facilities in place to implement it again externally to the core without
losing any real functionality).
in general "my system" involves mass amounts of bloat and undue complexity,
but I am trying to keep this away from the core interpreter/language.
outside the core it is a tangled mass, I had just wished I could keep it
less of a mess...
oh yes, on a different post I had listed this site (which has a logo, spec,
and some screenshots, saving one from actually having to download the damn
thing, now 8MB, a fair portion misc data though...):
http://bgb-sys.sourceforge.net/
has a link to:
http://sourceforge.net/projects/bgb-sys/
where one can download stuff (if they actually want to).
I am not looking for converts, but comments (either good or bad) are
interesting at least. given that this is just a toy anyways, not much weight
rests on this, but I would like comments (ie: on the design given in the
spec).
mind you I am not going to make signifigant changes, such as someone
recently suggesting that I should make keywords objects (as opposed to
symbols that eval to themselves) and trying to deny that I was using a
single namespace or that it was a scheme variant (grr, this was all based on
a few fragments which did not much illustrate the "general" design of the
language).
functions are not the only things that can be applied, application is
extended generally to objects which have "applicative behavior", which
varies based on types.
comments are mostly requested on the spec and logo (for now). I know the
logo looks shitty, downsampling seemed to have made it look like ass...
oppinions otherwise?...
Sebastian Hanowski
>Elisp is a very archaic form of Lisp, essentially predating both
>Scheme and Common Lisp, neither of which are particularly new
>languages.
>The vital problem is that it is _strongly_ tied to the use of dynamic
>scope, which makes it difficult to use lexical-scoping-related
>techniques to compile to machine code to make it Real Fast. Elisp
As you're right in pointing out the negative aspects of dynamic scope, i'd like
to mention http://www.gnu.org/software/emacs/emacs-paper.html#SEC17 where the
use of dynamic binding in Elisp ist justified. Emacs seems like an ecological
niche where this "ancient" concept survives.
Regards
Sebastian
Christopher Browne
Yes, there is use for dynamic binding. It simplifies having data "tag
along" when you customize things as compared to needing to modify
functions to explicitly pass extra bindings.
I didn't mention the other problem with dynamic scope, which is that
it is wickedly difficult for the beginner to understand it. I haven't
seen a "simple" explanation of it, yet.
The flip side of the coin is that that is almost certainly _not_ the
only way to "skin the cat." The "modern" way would likely involve
adding additional properties to CLOS objects, which would have the
"comprehension advantage" that you'd be able to more readily see how
custom values are tagging along for the ride through function calls...
--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/sap.html
It is impossible to sharpen a pencil with a blunt axe. It is equally
vain to try to do it with ten blunt axes instead.
-- Edsger W. Dijkstra
Lauri Alanko
> The flip side of the coin is that that is almost certainly _not_ the
> only way to "skin the cat." The "modern" way would likely involve
The "modern" alternative to dynamic binding is, IMHO, "fluids" (or
"parameters" as they are called in mzscheme, or the "implicit
parameters" of Haskell). Much more explicit and easier to comprehend
than all-pervasive dynamic bindings.
Lauri Alanko
l...@iki.fi
Joe Marshall
> Elisp is a very archaic form of Lisp, essentially predating both
> Scheme and Common Lisp, neither of which are particularly new
> languages.
The *style* of Elisp predates Scheme and Common Lisp, but Elisp was
created very much after Scheme and somewhat after Common Lisp.
Jens Axel Søgaard
I didn't realize that. Was it on purpose the choice was made,
or due to ignorance [probably too strong a word]?
--
Jens Axel Søgaard
Sebastian Hanowski
>Yes, there is use for dynamic binding. It simplifies having data "tag
>along" when you customize things as compared to needing to modify
>functions to explicitly pass extra bindings.
Ever since I read this quote from Alan Perlis, taken from his "Epigrams In
Programming": "It is the user who should parameterize procedures, not their
creators." I was wondering whether this ment dynamic binding of variables. Some
experts code executes in a users customized environment.
Joe Marshall
RMS decided on it. His reasons were
1) Lexical scope was too inefficient
2) Editing state is distributed over so many parameters that
passing them as arguments or encapsulating them would be a
tremendous burden on the implementor.
At the time (early 80's), he may have been correct about the
efficiency issue. If every keystroke that went through lisp ended up
consing a closure, the performance hit would be terrible. Compilation
tricks for avoiding consing closures require a sophisticated compiler,
and emacs lisp was designed around a byte-code engine. When Edwin
(on MIT Scheme) first started running, it was quite easy to type too
fast for it to keep up.
But RMS also had a strong personal fondness for dynamic scope. At the
time, he felt that lexical scope was `the wrong thing'. (I don't know
his current opinion.) If you review the mail archives, it is clear to
see RMS's opinion on it. I wouldn't say that RMS was ignorant of
lexical scope (he wrote the first implementation of closures on the
LMI Lambda lisp machine), but I think that once he decided against it,
he refused to reconsider, even in light of improvements in processor
speed, compiler technology, and garbage collection technology.
Jens Axel Søgaard
Thanks. That makes a great deal of sense.
--
Jens Axel Søgaard
Lauri Alanko
> Thanks. That makes a great deal of sense.
Olin Shivers' "History of T" has some more background on this:
http://www.paulgraham.com/thist.html
Lauri Alanko
l...@iki.fi
David A. Herman
> http://www.paulgraham.com/thist.html
Fascinating reading. I recall from the online videos of the 1986 lectures
(http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/) that
dynamic scope was mentioned in a negative light in one of the lectures.
From Olin's history, it sounds like Jonathan Rees's decision to implement
a Scheme compiler was radical in 1982. At what point did dynamic scope
fall out of fashion? Must've been somewhere in between, unless Abelson &
Sussman were ahead of the curve in deprecating dynamic scope.
Dave
Christopher Browne
It was definitely not a result of ignorance. RMS didn't much like
Common Lisp, and it wasn't until many years later that he considered
adopting Scheme (Guile, in particular) as the "future thing."
--
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://www.ntlug.org/~cbbrowne/multiplexor.html
"Well, I wish you'd just tell me rather than trying to engage my
enthusiasm, because I haven't got one." -- Marvin the Paranoid Android
Joe Marshall
> > Olin Shivers' "History of T" has some more background on this:
> > http://www.paulgraham.com/thist.html
>
> Fascinating reading. I recall from the online videos of the 1986 lectures
> (http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/) that
> dynamic scope was mentioned in a negative light in one of the lectures.
> From Olin's history, it sounds like Jonathan Rees's decision to implement
> a Scheme compiler was radical in 1982. At what point did dynamic scope
> fall out of fashion?
I not sure that dynamic scope was ever `in fashion'. If you read AI
memo 199, June 1970, ``The Function of FUNCTION in LISP, or Why the
FUNARG Problem Should be Called the Environment Problem '' by Joel
Moses, it is clear that lexical scope was preferred, but that the
pragmatics of the technology made dynamic scope more tractable.
MACLisp was lexically scoped when compiled (but dynamically scoped
when interpreted). I don't know whether LISCOM (the PDP-6 lisp
compiler that predates NCOMPLR) was lexical or dynamic, but the manual
for it mentions `special variables', so I suspect the former.
Hartmann Schaffer
Joe Marshall <j...@ccs.neu.edu> writes:
> ...
> But RMS also had a strong personal fondness for dynamic scope. At the
> time, he felt that lexical scope was `the wrong thing'. (I don't know
> his current opinion.) If you review the mail archives, it is clear to
> see RMS's opinion on it. I wouldn't say that RMS was ignorant of
> lexical scope (he wrote the first implementation of closures on the
> LMI Lambda lisp machine), but I think that once he decided against it,
> he refused to reconsider, even in light of improvements in processor
> speed, compiler technology, and garbage collection technology.
isn't he on record as having stated that now (whenever that was) he
would have a different decision? after all, iirc he initiated the
guile project (with his "why you shouldn't use Tcl" post)
hs
--
ceterum censeo SCO esse delendam
Alex Shinn
This concept also survives strongly in Unix environment variables. As
I'm developing my own editor (unfinished project #5432967), I'm
undecided on whether this is really needed or not.
First, the arguments in that article are weak: the RMAIL command is
describing customizing a keybinding, I don't see how that necessarily
relates to scope. The insert/overwrite text mode is a better example,
except that in this particular case that behavior doesn't show off the
use of dynamic scope - a lexically scoped variable would work just as
well. This is because the insert function and other programmatic
functions (other than interactively typing characters) don't pay
attention to that variable, so there's never any point in running
(let ((overwrite-mode 'overwrite-mode-textual)) ...)
A better example is case sensitivity, where a common idiom in Elisp is
(let ((case-fold-search t)) ...)
however there are only a handle of such variables I can think of that
take advantage of dynamic scope. Also, case-fold-search is really just
a crutch for the fact that Emacs regexps don't have any internal
indication of case-sensitivity like Perl and POSIX regex's do.
There are those[1] who argue against any such modal behavior to begin
with. From a user perspective it can be confusing if the same command
works differently in different scenarios. If you really need to
distinguish, better to have two commands (i.e. closures). I'm
personally torn on this, because while I believe that in a complete,
well designed system this may be true, I also realize that you will
*never* achieve a complete system and will always be hacking on it. So
it seems better to allow this ad-hoc behavior but try to reduce its use
in favor of better abstractions.
But even given you want to allow this style of customization, dynamic
scope is not the only solution. Scheme already has a precedent for
global variables that can be temporarily shadowed in with- forms.
There's the scheme-interaction-environment to handle new top-level
definitions.
Another option is an OO approach (be it through a formal object system
or through dispatch closures). A loose OO system (such as Perl) let's
you define new slots ad-hoc. This could be done while keeping
predefined slots efficient. With such an approach, the occasional
reference to some dynamic property would simply be a slot-reference to
the local buffer object. When writing modes you could even develop some
syntax like CL's with-slots to make this more convenient.
So at the moment, while not strictly opposed to dynamic scope (as a
supplement to a primarily lexically scoped system) I can't think of
anywhere I'd want to use it in an editor.
Footnotes:
[1] http://humane.sourceforge.net/home/index.html
--
Alex
![Michael Sperber [Mr. Preprocessor]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjW1Ug-7D5rvPAe0Dy8QWlBwdoMp8sHWFACGdNTzwJ9mF7CkTQ=s40-c)
Michael Sperber [Mr. Preprocessor]
Joe> 1) Lexical scope was too inefficient [...]
Joe> At the time (early 80's), he may have been correct about the
Joe> efficiency issue.
I don't think so. (Even though I agree that this was probably his
reasoning.) The performance of the Emacs Lisp engine is truly
tectonic, and it's actually pretty hard to do worse.
Joe> When Edwin (on MIT Scheme) first started running, it was quite
Joe> easy to type too fast for it to keep up.
But you're comparing apples and oranges: Emacs is essentially written
in C, with extensions in Emacs Lisp, while Edwin was entirely written
in Scheme. Many parts of Emacs could very well be coded in Emacs
Lisp, if it weren't for the abysmal performance.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
David Rush
> Scheme already has a precedent for
> global variables that can be temporarily shadowed in with- forms.
Yes, those are generally implemented with either fluids or a
procedural abstraction around a mutable cell. Err...I guess that's
still fluids, just under a different name.
> There's the scheme-interaction-environment to handle new top-level
> definitions.
scheme-interaction-environment is not necessarily mutable by eval. :(
Someone please tell me I'm wrong on this, but IIRC, this has caused me
a lot of grief. As far as I'm concerned, without a mutable, reified
environment, eval is almost completely useless.
david rush
--
Research is what I am doing when I don't know what I am doing.
-- Wernher von Braun
Joe Marshall
Take a look at Edwin.
Edwin is the `Emacs'-type editor that comes with MIT-Scheme. It is
written completely in Scheme and uses lexical scoping as the default
model. The architecture of Edwin is similar to GNU Emacs. This is
because CPH worked with RMS to define the architecture at about the
same time that GNU Emacs was designed. If dynamic scoping were
*required* to build an editor, then Edwin could not exist.
Joe Marshall
> >>>>> "Joe" == Joe Marshall <j...@ccs.neu.edu> writes:
>
> Joe> 1) Lexical scope was too inefficient [...]
>
> Joe> At the time (early 80's), he may have been correct about the
> Joe> efficiency issue.
>
> I don't think so. (Even though I agree that this was probably his
> reasoning.) The performance of the Emacs Lisp engine is truly
> tectonic, and it's actually pretty hard to do worse.
I happen to think RMS was wrong, but it was a close call.
Part of the problem was GC. At the time, generational scavenging was
barely available on the LispM, let alone on stock hardware. It was
expected that an elisp GC would be an intrusive operation, and it was
unclear whether users would accept that. (The alternative was
Gosling Emacs. Gosmacs had its problems, but it worked under unix,
was fairly customizable, and reasonably zippy.)
With dynamic scoping, you can avoid a lot of closure creation
with no analysis and thus eliminating one of the main sources of
garbage.
David Rush
> With dynamic scoping, you can avoid a lot of closure creation
> with no analysis and thus eliminating one of the main sources of
> garbage.
This is worth noting. Esp w/rt Tom Lord's quest for the 'sweet spot'
in little language specifications.
david rush
--
Applications create possibilities for millions of credulous users,
whereas OSes impose limitations on thousands of grumpy coders...
-- Neal Stephenson in _The Return of the Command-Line_
Anton van Straaten
> Joe Marshall <j...@ccs.neu.edu> writes:
> > With dynamic scoping, you can avoid a lot of closure creation
> > with no analysis and thus eliminating one of the main sources of
> > garbage.
>
> This is worth noting. Esp w/rt Tom Lord's quest for the 'sweet spot'
> in little language specifications.
Dynamic scoping has a high cost in other ways, though: comprehensibility &
reliability of code. Even for little languages, this can be a problem.
Anton
Sebastian Hanowski
>The "modern" alternative to dynamic binding is, IMHO, "fluids" (or
I don't know if fluid-let covers the same notion, but interesting it is still.
For a good description, see
http://www.csie.ntu.edu.tw/~b7506051/docs/scheme/t-y-scheme/t-y-scheme-Z-H-10.html#node_sec_8.3
>"parameters" as they are called in mzscheme, or the "implicit parameters" of
>Haskell).
What about perl temp variables?
-s
Neil W. Van Dyke
> or "parameters" as they are called in mzscheme
And now by SRFI-39. :)
cr88192
> I don't know if fluid-let covers the same notion, but interesting it is
still.
> For a good description, see
>
http://www.csie.ntu.edu.tw/~b7506051/docs/scheme/t-y-scheme/t-y-scheme-Z-H-1
0.html#node_sec_8.3
>
least not simply). I have dynamic binding myself, which better handles
threads (though more expensive).
some tasks are also handled well with dynamic binding which would be
problematic for strictly lexical binding (ex: the "self" reference and some
"implicit arguments").
though I do try to keep use of dynamic vars minimal, often design wins over
performance...
Sander Vesik
Maybe: "better match to what teco macros had" ?
--
Sander
+++ Out of cheese error +++
Tom Lord
Jens Axel S?gaard <use...@jasoegaard.dk>:
[Re: "The *style* of Elisp"]
>> I didn't realize that. Was it on purpose the choice was made, or
>> due to ignorance [probably too strong a word]?
Sander Vesik:
> Maybe: "better match to what teco macros had" ?
I suggest:
http://www.gnu.org/software/emacs/emacs-paper.html
and, in particular
http://www.gnu.org/software/emacs/emacs-paper.html#SEC17
I don't happen to agree with that section of the paper and,
overall, I think the paper misses mentioning some of the most
brilliant parts of the Emacs architecture -- but it does
express some of the thinking there.
-t