I am looking at starting up a development project, and I am very strongly
leaning towards using Common Lisp as the development language.
I have used LWW 4.0 a little bit, and have tried the free version of ACL5,
but I was wondering if anyone could give me some good information on the
advantages/drawbacks of these two implementations (I get the impression
they are the leading ones).
Specifically, I am looking at issues of development productivity, database
support, COM support, CORBA support, documentation, support, cost, GC
performance, portability (between Windows and Linux), etc. The lisp.org
site gives some information, but it is very neutral in it's offering. I
want some good information on the comparison.
I have been somewhat frustrated by Franz's failure to quote me a price on
their environment, but suspect their product is superior (gut feel).
Morgan Rodwell
FlyByNight Software
Calgary, Canada
"Morgan Rodwell" <········@home.com> writes:
> Specifically, I am looking at issues of development productivity, database
> support, COM support, CORBA support, documentation, support, cost, GC
> performance, portability (between Windows and Linux), etc. The lisp.org
> site gives some information, but it is very neutral in it's offering. I
> want some good information on the comparison.
>
> I have been somewhat frustrated by Franz's failure to quote me a price on
> their environment, but suspect their product is superior (gut feel).
I believe both support all of the above.
You'll have difficulties finding any reasoned comparisons since few
people will have done major projects in comparable circumstances with
both of them. It seems a lot of programming magazines are of the
impression that the complexity of writing a Hello World program or a
little calculator consist a good review of a new programming
environment.
This said, what I like about Allegro is the documentation. Lispworks
has about as many interesting extensions and has comparable
functionality but is in my experience far worse documented. You'll
often find yourself using the excellent browsers in the environment
because all sorts of stuff simply isn't documented. I like the design
of CAPI, but half of the things you need to know to write an
application aren't in the docs. You need to use the class browser to
find slots and functions you need.
What's nice about Lispworks is the environment. I believe it's almost
the same under Windows as under Linux, where there are a lot of
differences with Allegro.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> writes:
> What's nice about Lispworks is the environment. I believe it's almost
> the same under Windows as under Linux, where there are a lot of
> differences with Allegro.
Though at this point I'm a much stronger advocate of LispWorks than ACL
based purely on company ethics, I have to say that ACL's Emacs and
XEmacs environment is excellent as well, and on Windows they have this
very prototypical-looking IDE that's kinda typical in the VB/Java/VC++
world, which a lot of people probably like. Moreover, while using their
IDE, you can still use Emacs or XEmacs as your editor. With the ilisp
package in (X)Emacs, you can do quite a bit too, though the graphical
ones are better for viewing class hierarchies and things. When I used
ACL in grad school, I used it on Unix, and there was thing thing called
"Composer" or something like that, and it was graphical, and you could
do similar things. As Duane Rettig mentioned in a recent post, these
tools are important for large-scale Common Lisp projects. If you use a
free implementation, you will have to make stronger use of editor tools
such as OO Browser, etags, etc.
Both ACL and LispWorks have great environments, without question. I'm
not exactly sure why Harlequin took the trouble to write their
emacs-like editor, but it *definitely* proves concept, since it looks to
me like it was done completely in Common Lisp, using CAPI. If this
doesn't prove that CAPI works, I don't know what does. Even Visual Cafe
(the Java IDE from Symmantec (sp?)) is mostly written in VC++. So they
didn't have the balls to use Java to write the IDE. LispWorks is
definitely very cool like that.
dave
In article <···············@mint-square.mit.edu>, David Bakhash
<·····@alum.mit.edu> wrote:
> Both ACL and LispWorks have great environments, without question. I'm
> not exactly sure why Harlequin took the trouble to write their
> emacs-like editor,
Maybe because editor facilites are useful in many GUI applications?
Using the built-in editor substrate makes it very simple.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <···············@mint-square.mit.edu>, David Bakhash
> <·····@alum.mit.edu> wrote:
>
> > Both ACL and LispWorks have great environments, without question. I'm
> > not exactly sure why Harlequin took the trouble to write their
> > emacs-like editor,
>
> Maybe because editor facilites are useful in many GUI applications?
> Using the built-in editor substrate makes it very simple.
Well, wouldn't you say that Franz's eli package is as good as
built-in? I would. I prefer (X)Emacs over any other editor, by far.
Of course, that's why I use ilisp with Harlequin. My point in stating
the above is that with (X)Emacs, you have an extensible editor that so
many people already use, and that's standard on most systems -- and
that's lisp-based. So why not use it?
I remember going through contortions a few years ago making Mentor
Graphics (CAD) interface with XEmacs instead of its own notepad-liked
editor (which of course I hated). But the point is that people who
write code generally get wedded to their editors, and it's not always
good to make them sever ties with it. I like the CAPI-based editor
bundled with LispWorks; just not as much as (X)Emacs. But I still
think they could have saved some work by writing an elisp extension
instead. Others may argue this.
dave
In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
<·····@alum.mit.edu> wrote:
> Well, wouldn't you say that Franz's eli package is as good as
> built-in? I would.
I wouldn't.
> I prefer (X)Emacs over any other editor, by far.
Actually an editor like FRED (of MCL, which is my preferred typing
"engine") is much snappier. It is better integrated and can
be extended with the full power of Common Lisp. Every
text dialog item in an application is a full instance
of FRED ( just doing (make-instance 'fred-window) or
(ED) creates one. I just like to write my editor
extensions in Common Lisp using CLOS and stuff and
not stay with an archaic Lisp dialect (Emacs Lisp).
(Just to give an idea what things could look like:
an IDE using FRED is for example Apple Dylan:
http://corporate-world.lisp.de/mcl/apple-dylan-ide.jpg ).
> Of course, that's why I use ilisp with Harlequin. My point in stating
> the above is that with (X)Emacs, you have an extensible editor that so
> many people already use, and that's standard on most systems -- and
> that's lisp-based. So why not use it?
My point was, that the editor engine is useful in applications -
wo why not write one?
> bundled with LispWorks; just not as much as (X)Emacs. But I still
> think they could have saved some work by writing an elisp extension
> instead. Others may argue this.
AFAIK LispWorks can be used from within Emacs.
I'm not saying that XEmacs is not cool - I'm just saying
that some people (like me) prefer other Lisp-based
(integrated) editors.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> I'm not saying that XEmacs is not cool - I'm just saying
> that some people (like me) prefer other Lisp-based
> (integrated) editors.
agreed, and I wasn't arguing the contrary. I think that since I
do a lot of development of my little 14.1" Vaio laptop, I don't have
that much screen space, and so I like the idea of a single application
doing it all. The only application out there can come close to this
is XEmacs, and even that falls short (due to weakness with respect to
web browsing). Also, I do admit that elisp is not the best dialect of
CL.
> (Just to give an idea what things could look like: an IDE using FRED
> is for example Apple Dylan:
> http://corporate-world.lisp.de/mcl/apple-dylan-ide.jpg ).
Yeah. I can see how lots of people would like that, and that XEmacs
couldn't easily produce that (though it can produce that with some
stuff like speedbar, etc.)
dave
In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
<·····@alum.mit.edu> wrote:
> > (Just to give an idea what things could look like: an IDE using FRED
> > is for example Apple Dylan:
> > http://corporate-world.lisp.de/mcl/apple-dylan-ide.jpg ).
>
> Yeah. I can see how lots of people would like that, and that XEmacs
> couldn't easily produce that (though it can produce that with some
> stuff like speedbar, etc.)
The last time I saw something like that, was Lucid's "Energize" -
their C++ development system. It was supposed to give
C++ users the power of Lisp interactive IDEs (integrated development
environments). It had two effects: it sunk Lucid (and unfortunately
their Lisp business) and finally led to XEmacs, since their
IDE was based on Lucid Emacs.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
"David Bakhash" <·····@alum.mit.edu> escribi� en el mensaje
···················@cadet.dsl.speakeasy.net...
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> web browsing). Also, I do admit that elisp is not the best dialect of
It's going to be replaced with GUILE, no? :-?
"Fernando Rodriguez" <···@mindless.com> writes:
> "David Bakhash" <·····@alum.mit.edu> escribi� en el mensaje
> ···················@cadet.dsl.speakeasy.net...
> > Rainer Joswig <······@corporate-world.lisp.de> writes:
> >
> > web browsing). Also, I do admit that elisp is not the best dialect of
>
> It's going to be replaced with GUILE, no? :-?
I certainly hope not. that would be a step in the wrong direction.
If that happens it's over for XEmacs.
dave
Centuries ago, Nostradamus foresaw a time when David Bakhash would say:
>"Fernando Rodriguez" <···@mindless.com> writes:
>
>> "David Bakhash" <·····@alum.mit.edu> escribi� en el mensaje
>> ···················@cadet.dsl.speakeasy.net...
>> > Rainer Joswig <······@corporate-world.lisp.de> writes:
>> >
>> > web browsing). Also, I do admit that elisp is not the best dialect of
>>
>> It's going to be replaced with GUILE, no? :-?
>
>I certainly hope not. that would be a step in the wrong direction.
>If that happens it's over for XEmacs.
It seems more likely that if GNU Emacs "moved towards Guile," XEmacs
might react by "moving towards Common Lisp."
--
········@hex.net - <http://www.ntlug.org/~cbbrowne/editors.html>
When your hammer is C++, everything begins to look like a thumb.
-- Steve Hoflich on comp.lang.c++
········@knuth.brownes.org (Christopher Browne) writes:
> It seems more likely that if GNU Emacs "moved towards Guile," XEmacs
> might react by "moving towards Common Lisp."
I really hope so. But why wait for GNU Emacs to move and then react?
Why not lead the pack and go CL right away?
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
Andreas Eder <············@t-online.de> writes:
>········@knuth.brownes.org (Christopher Browne) writes:
>> It seems more likely that if GNU Emacs "moved towards Guile," XEmacs
>> might react by "moving towards Common Lisp."
>I really hope so. But why wait for GNU Emacs to move and then react?
>Why not lead the pack and go CL right away?
Compatibility with old elisp packages.
For the record, the announced plans for guile in emacs are that guile
first gets an elisp frontend (the main feature being dynamic scope, of
course) and that the typical emacs package remains written in elisp,
not Scheme.
Insofar the plan is not to move Emacs to Scheme, the plan is "just" to
exchange the lisp implementation in Emacs (to get speed, threads,
optionally for newly written packages a dialect with static scope
etc.).
Disclaimer: Am an outsider of the emacs/guile development myself, but
since noone else pointed out the misconception in the thread, this
posting is probably better than nothing.
Disclaimer2: All this does not matter as long as noone steps forward
to do the work. Whoever does the work will have a big impact on the
exact direction.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <·············@counter.bik-gmbh.de>,
········@counter.bik-gmbh.de (Martin Cracauer) wrote:
> For the record, the announced plans for guile in emacs are that guile
> first gets an elisp frontend (the main feature being dynamic scope, of
> course) and that the typical emacs package remains written in elisp,
> not Scheme.
Hmm, wouldn't it be easier to write an ELisp frontend for
Common Lisp?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <·············@counter.bik-gmbh.de>,
> ········@counter.bik-gmbh.de (Martin Cracauer) wrote:
>
> > For the record, the announced plans for guile in emacs are that guile
> > first gets an elisp frontend (the main feature being dynamic scope, of
> > course) and that the typical emacs package remains written in elisp,
> > not Scheme.
>
> Hmm, wouldn't it be easier to write an ELisp frontend for
> Common Lisp?
Of course it would be. But the point here is that the GNU people have
hopelessly adopted Guile, and that's what they want everything's
extension language to look like.
dave
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <·············@counter.bik-gmbh.de>,
> ········@counter.bik-gmbh.de (Martin Cracauer) wrote:
>
> > For the record, the announced plans for guile in emacs are that guile
> > first gets an elisp frontend (the main feature being dynamic scope, of
> > course) and that the typical emacs package remains written in elisp,
> > not Scheme.
>
> Hmm, wouldn't it be easier to write an ELisp frontend for
> Common Lisp?
I think Sam Steingold already has:
http://www.podval.org/~sds/data/cllib.zip
(I have no idea how complete it is).
--
The above are my opinions,
and my opinions only.
Rainer Joswig <······@corporate-world.lisp.de> writes:
>In article <·············@counter.bik-gmbh.de>,
>········@counter.bik-gmbh.de (Martin Cracauer) wrote:
>> For the record, the announced plans for guile in emacs are that guile
>> first gets an elisp frontend (the main feature being dynamic scope, of
>> course) and that the typical emacs package remains written in elisp,
>> not Scheme.
>Hmm, wouldn't it be easier to write an ELisp frontend for
>Common Lisp?
Quite even, I'd say. The problem with CL however is that most do not
support being treated as an extension library (yes, strickly speaking
you can, but the Scheme implementations intended for this are
much friendlier).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <·············@counter.bik-gmbh.de>
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> For the record, the announced plans for guile in emacs are that guile
> first gets an elisp frontend
If my old notes don't mislead me, this can be found at
http://gemacs.sourceforge.net.
········@knuth.brownes.org (Christopher Browne) writes:
> It seems more likely that if GNU Emacs "moved towards Guile," XEmacs
> might react by "moving towards Common Lisp."
Moving towards CL would seem like the wrong direction to me, since
Guile isn't just Scheme, it's intended to handle multiple languages
through translation (although at the moment I don't think there are
many fully working translators). The move to Guile involves an Emacs
Lisp to Guile translator rather than rewriting everything in Scheme.
If people prefer to use Common Lisp, maybe it'd be better to write a
CL translator for Guile, then other projects using Guile could also
benefit.
Andy
--
Andy Smith ·····@cam.ac.uk
St John's College, Cambridge, CB2 1TP, UK (07989) 453208
Andy Smith <·····@cam.ac.uk> writes:
> > It seems more likely that if GNU Emacs "moved towards Guile,"
> > XEmacs might react by "moving towards Common Lisp."
> Moving towards CL would seem like the wrong direction to me, since
> Guile isn't just Scheme, it's intended to handle multiple languages
> through translation (although at the moment I don't think there are
> many fully working translators). The move to Guile involves an
> Emacs Lisp to Guile translator rather than rewriting everything in
> Scheme. If people prefer to use Common Lisp, maybe it'd be better
> to write a CL translator for Guile, then other projects using Guile
> could also benefit.
One important thing to consider is that CL2Scheme translation is
harder than the other direction (which is triviality defined,
relatively speaking).
After months of Guile programming for the snd package (a sound package
I found on http://www.freshmeat.net which is truly amazing, highly
extensible, and very well done), I realize that I despise Guile. Even
back when I was writing code for the Festival Text-to-Speech engine
(another amazing package), I was hating it. I'd love to list all the
(dozens) of really pressing reasons why Scheme is not the language of
choice for XEmacs, and why CL is. If the Tk package were thread-safe,
and Perl threads worked better, then I'd even argue that Perl was a
better langauge to write an editor (and extension language) in than
Scheme/Guile.
But, just so I'm not seeming to rant on and on, let me tell why I
despise Guile.
1) Guile has a bunch of non-standard-looking extensions to provide
CL-like functionality, and is mostly broken and ugly. Among those
are:
o macros (with no really useful auxilliary tools for handling
them)
o specialized defun/defmacro for handling CL-style parameter
lists, also incomplete (with respect to Common Lisp), and yet
people use it (which just shows that they *really* want Common
Lisp in the first place).
o their packaging system (define-module ...) and (use-module ...)
stuff, all slapped-on.
2) Shared namespace with functions and variables.
I'm sure others will pick up from here.
One thing that Guile has done, which has definitely led to a lot of
its success and adoption, is interfacing with C very well. For
example, it's very easy for C programmers to write these "modules"
mostly in C, so they're pretty fast, and they even make it mostly easy
to call the guile stuff from C, and have some C macros that facilitate
this. Callbacks in CL tend to be more complicated, from what I've
seen.
The Gimp also is pretty impressive. No one would argue that it's a
weak product, and is only as good as it is because Guile has done a
nice job of interfacing to C. So I can't really say that if XEmacs
started using Guile that it would be a disaster. It just won't be a
step in the right direction.
BTW, as long as we're here, what is the right CL to use for an editor?
I'd say CMUCL, since it's supposedly the best free Lisp out there and
supports networking, threads, Garnet/CLX, etc. But the downside is
that it doesn't run on too many platforms (e.g. MS Windows). CLISP,
my favorite free implementation, runs on everything and its mother,
but lacks some features that might be useful for an editor.
Also, I think that it would be best to write as much of the editor in
CL as possible, unlike (X)Emacs, which are still highly written in C.
Maybe using the GTK would be useful, and that (from what I've heard)
has been done from Common Lisp, somewhere, somehow. This would be
great since even GTK works under Windows.
Let's just go with this CLISP idea, linking to GTK. The two
directions that people could go would be:
1) Write an :elisp package and compile and load existing elisp files.
Optionally, write a emacs bytecode -> CLISP bytecode
translator/compiler, though it would be best to just recompile
everything in elisp into the CLISP bytecodes.
2) repair all the dynamically-scoped Emacs Lisp stuff out there (way
too much work!)
the problem with (2) is that some developers have used the brokenness
of elisp as features to "simplify" their programs (I'm guilty of this
too, since I've always considered elisp as hacking). But it's really
better than maintaining crappy code.
The Common Lisp package system can handle making this all work, with
whole new definitions of things like `let', `defun', ... so I guess
(1) could work just by defining the EMACS-LISP package, and
implementing all of the elisp stuff so it works (like goto-char and
stuff). There are some differences in syntax, of course, like ?o
instead of #\o and elisp's [1 2 3] for vectors, but hopefully reader
extensions like #'SET-MACRO-CHARACTER can handle some of these issues.
In this case, I would look more at the project as writing an
interesting CL-based environment than writing a fancy editor.
dave
David Bakhash <·····@alum.mit.edu> writes:
> One thing that Guile has done, which has definitely led to a lot of
> its success and adoption, is interfacing with C very well. For
> example, it's very easy for C programmers to write these "modules"
> mostly in C, so they're pretty fast, and they even make it mostly
> easy to call the guile stuff from C, and have some C macros that
> facilitate this. Callbacks in CL tend to be more complicated, from
> what I've seen.
I agree, although for simple stuff I have found CMUCL's Alien
interface to be pretty useful.
> The Gimp also is pretty impressive. No one would argue that it's a
> weak product, and is only as good as it is because Guile has done a
> nice job of interfacing to C. So I can't really say that if XEmacs
> started using Guile that it would be a disaster. It just won't be a
> step in the right direction.
The Gimp doesn't use Guile. I'm pretty sure the Gimp scheme
interpreter isn't R5RS.
> 2) repair all the dynamically-scoped Emacs Lisp stuff out there (way
> too much work!)
>
> the problem with (2) is that some developers have used the
> brokenness of elisp as features to "simplify" their programs (I'm
> guilty of this too, since I've always considered elisp as hacking).
> But it's really better than maintaining crappy code.
I used to think that dynamic scoping was totally evil, and after a
while of programming Emacs Lisp I started to wonder why it was
dynamically scoped in the first place. I came across the following
reference:
http://www.gnu.org/software/emacs/emacs-paper.html#SEC18
In article <··························@meta.verbum.org>, Colin Walters
<·······@cis.ohio-state.edu> wrote:
> I used to think that dynamic scoping was totally evil, and after a
> while of programming Emacs Lisp I started to wonder why it was
> dynamically scoped in the first place. I came across the following
> reference:
>
> http://www.gnu.org/software/emacs/emacs-paper.html#SEC18
Well, stuff of this is in CL, too. But today we pass complex
objects around, instead of a multitude of arguments.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> Well, stuff of this is in CL, too. But today we pass complex objects
> around, instead of a multitude of arguments.
Could you expand on this a bit? I'm not sure what you mean by
"complex object". How could a complex object replace dynamic scoping?
In article <··························@meta.verbum.org>, Colin Walters
<·······@cis.ohio-state.edu> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > Well, stuff of this is in CL, too. But today we pass complex objects
> > around, instead of a multitude of arguments.
>
> Could you expand on this a bit? I'm not sure what you mean by
> "complex object". How could a complex object replace dynamic scoping?
>
Hmm, in Common Lisp for example you have variables like
*print-length* to control the printer:
? (apropos "*PRINT-" "COMMON-LISP")
*PRINT-ARRAY*, Value: T
*PRINT-BASE*, Value: 10
*PRINT-CASE*, Value: :UPCASE
*PRINT-CIRCLE*, Value: T
*PRINT-ESCAPE*, Value: T
*PRINT-GENSYM*, Value: T
*PRINT-LENGTH*, Value: NIL
*PRINT-LEVEL*, Value: NIL
*PRINT-LINES*, Value: NIL
*PRINT-MISER-WIDTH*, Value: 40
*PRINT-PPRINT-DISPATCH*, Value: ...
*PRINT-PRETTY*, Value: NIL
*PRINT-RADIX*, Value: NIL
*PRINT-READABLY*, Value: NIL
*PRINT-RIGHT-MARGIN*, Value: NIL
In CLIM you have complex objects to capturing the
state of drawing:
A basic-medium object has slots:
("PORT" "SHEET" "FOREGROUND" "BACKGROUND" "INK" "TEXT-STYLE"
"DEFAULT-TEXT-STYLE" "MERGED-TEXT-STYLE" "LINE-STYLE" "TRANSFORMATION"
"REGION" "+Y-UPWARD-P" "STATE-CACHED-P")
So instead
(let ((*ink* +white+)
(*medium* a-medium))
(do-something))
you'd say
(setf (medium-ink a-medium) +white+)
(do-something a-medium)
(setf (medium-ink a-medium) +whatever+)
or
(with-drawing-options (a-medium :ink +white+)
(do-something a-medium))
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Tim Bradshaw
Subject: Re: Comparison of CL Implementations?
Date:
Message-ID: <ey3u2bmpb53.fsf@cley.com>
* Rainer Joswig wrote:
> (with-drawing-options (a-medium :ink +white+)
> (do-something a-medium))
These things are potentially a hideous nightmare.
Consider this:
(progn
(process-run-function "Perhaps green"
#'(lambda ()
(with-drawing-options (m :ink +green+)
...))
(process-run-function "Perhaps red"
#'(lambda ()
(with-drawing-options (m :ink +red+)
...))
What colours get drawn?
OK, you could argue that this kind of situation isn't that relevant to
CLIM, but it is relevant in general: if you have some object with a
lot of state which you are going to `bind' like this, then exciting
things are going to happen in a multithreaded lisp.
The standard, awful, way around this is:
(defmacro with-xxx ((foo new) &body body)
`(without-interrupts
(unwind-protect ...)))
There are less bad ones -- perhaps a lock on the object so that only
other threads which bind state in the same object will wait -- but I
can't think of a really good one, short of allocating a whole new
object instead of altering state within it.
The whole use of *PRINT-x* variables is quite interesting in this
respect. It's kind of obvious that there should be some `printer
control' object which you can pass to printer functions, and then just
one special variable. But then, if these things have mutable state,
it's really easy to fall into the trap above. At least with printer
control variables the normal variable binding mechanisms make sure
that things happen like you expect. Another approach I've heard
suggested is to have the printer-control state be an attribute of the
stream, but this has fairly similar problems.
So maybe special variables aren't quite so bad, after all.
--tim
Tim Bradshaw <···@cley.com> writes:
> OK, you could argue that this kind of situation isn't that relevant to
> CLIM, but it is relevant in general: if you have some object with a
> lot of state which you are going to `bind' like this, then exciting
> things are going to happen in a multithreaded lisp.
>
> The standard, awful, way around this is:
>
> (defmacro with-xxx ((foo new) &body body)
> `(without-interrupts
> (unwind-protect ...)))
Yeah. Good point. But depending on what you've got in the body of
that, it might not be nice to put the WITHOUT-INTERRUPTS (though I
think it might be more appropriate to use WITHOUT-PREEMPTION (LW) or
WITHOUT-SCHEDULING (ACL) since they're less drastic, and you get what
you need. But really, while I agree with the UNWIND-PROTECT being
there, I don't think one should put the WITHOUT-*** there in such
situations. (see below)
All this stuff about thread-safeness just makes one wonder about state
in general. If you had code like what was mentioned in the earlier
post:
(setf (medium-ink a-medium) +white+)
(do-something a-medium) ; preemption might occur before/after this
(setf (medium-ink a-medium) +whatever+)
then, as the application programmer, you'd have to know to put that
body inside the WITHOUT-*** anyway if you wanted it to be thread-safe,
and you knew that the object were shared among different threads. So
when you define the macro `with-xxx' you probably should NOT put the
WITHOUT-***, and leave it to the user of the macro to enclose it
inside the WITHOUT-***. So it would look like:
(without-preemption
(with-drawing-options (...)
(...)))
Same goes for the LETF macro. I've never seen a LETF implementation
that took threads into consideration. And if you did something like:
(letf (((point-x point) (- (point-y point)))
((point-y point) (point-x point)))
(do-transformation-1 point)
(do-transformation-2 point)
...)
Well, then you could risk getting screwed badly here when dealing with
multiple threads. In recent posts, we discussed threading with
respect to global variables and for some of the commercial
implementations there are solutions. But when there's mutation inside
an object like a list or struct, then you the programmer must
explicitly protect your data.
dave
In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
<·····@alum.mit.edu> wrote:
> All this stuff about thread-safeness just makes one wonder about state
> in general. If you had code like what was mentioned in the earlier
> post:
>
> (setf (medium-ink a-medium) +white+)
> (do-something a-medium) ; preemption might occur before/after this
> (setf (medium-ink a-medium) +whatever+)
>
> then, as the application programmer, you'd have to know to put that
> body inside the WITHOUT-*** anyway if you wanted it to be thread-safe,
> and you knew that the object were shared among different threads. So
> when you define the macro `with-xxx' you probably should NOT put the
> WITHOUT-***, and leave it to the user of the macro to enclose it
> inside the WITHOUT-***. So it would look like:
>
> (without-preemption
> (with-drawing-options (...)
> (...)))
Well, Ralf Moeller did similar stuff like that in his
graphics lib for MCL. You would use "graphic contexts" (gcontext)
which capture the interesting state. The user visible
drawing functions are implemented like this:
(defmethod draw-framed-rect ((view simple-view) gcontext left &optional top right bot)
(with-gcontext-installed (view gcontext)
(with-rectangle-arg (r left top right bot) (#_FrameRect r))))
Where the WITH-GCONTEXT-INSTALLED macro looks like:
(defmacro with-gcontext-installed ((view gcontext) &body forms)
(let ((view-var (gensym))
(gcontext-var (gensym))
(view-gcontext-var (gensym)))
`(let* ((,view-var ,view)
(,gcontext-var ,gcontext)
(,view-gcontext-var (view-gcontext ,view-var)))
(without-interrupts
(with-focused-view ,view-var
(if (eq ,view-gcontext-var ,gcontext-var)
(progn
(#_PenPat (gcontext-pen-pattern ,view-gcontext-var))
(#_PenMode (gcontext-pen-mode ,view-gcontext-var))
(#_PenSize :long (gcontext-pen-size ,view-gcontext-var)))
(progn
(#_PenPat (gcontext-pen-pattern ,gcontext-var))
(#_PenMode (gcontext-pen-mode ,gcontext-var))
(#_PenSize :long (gcontext-pen-size ,gcontext-var))
(let ((font (gcontext-font ,gcontext-var)))
(if (null font)
(set-view-font ,view-var (view-default-font view))
(set-view-font ,view-var font)))
(setf (view-gcontext ,view) ,gcontext)))
. ,forms)))))
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> Well, Ralf Moeller did similar stuff like that in his graphics lib
> for MCL. You would use "graphic contexts" (gcontext) which capture
> the interesting state. The user visible drawing functions are
> implemented like this:
Yeah. it's definitely *safer* to throw the WITHOUT-INTERRUPTS in
there -- especially in GUI code, since it is very likely the case that
the gcontext in there would be used by multiple threads. But in more
general cases, such as LETF, it's not always a good bet.
It's a subtle point, and so maybe what's safer is better. I'm not
experienced enough in this to know for sure.
dave
From: Tim Bradshaw
Subject: State objects (was Re: Comparison of CL Implementations?)
Date:
Message-ID: <ey3n1hdpx0x.fsf_-_@cley.com>
* David Bakhash wrote:
> Yeah. it's definitely *safer* to throw the WITHOUT-INTERRUPTS in
> there -- especially in GUI code, since it is very likely the case that
> the gcontext in there would be used by multiple threads. But in more
> general cases, such as LETF, it's not always a good bet.
The underlying point I was trying to make earlier in the thread is
that without-preemption constructs are a really bad sign, except in
very special circumstances, because they *completely* serialize your
code -- every other thread gets stopped, regardless of what it's doing.
Consider something like this, assuming some reader-control object and
that this macro uses without-interrupts or something.
(with-reader-options ((*reader-control* :base 16))
(read *user-input*))
Now your whole system is hung until the user types something.
If you really need to serialize just `binding' values in an object,
then you should have a lock on that object, because at least then
people doing other stuff don't hang up.
> It's a subtle point, and so maybe what's safer is better. I'm not
> experienced enough in this to know for sure.
If it costs that much to be safe, I think it's not that subtle!
However, it turns out that Lisp has the seeds of its own redemption
here. The trick is to forget all this fancy OO-programming rubbish
and pretend it's 1958. How do you implement your state control
object? The same way you implement all objects, you do it with lists,
specifically alists. `Pah! primitive!' I hear you say. But look:
(defmacro with-bindings ((o &rest kvps) &body body)
(labels ((bexp (btail)
(if (null btail)
o
`(cons (cons ',(first btail)
,(second btail))
,(bexp (cddr btail))))))
`(let ((,o ,(bexp kvps)))
,@body)))
(defvar *printer-control* '((:case . :upper)
(:base . 10)
(:escape . t)
...))
(with-bindings ((*printer-control*
:base 16))
...)
Thread-safe, and cheap. With a small amount of work it could
stack-allocate the bindings too, so it needn't even cons.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> There are less bad ones -- perhaps a lock on the object so that only
> other threads which bind state in the same object will wait -- but I
> can't think of a really good one, short of allocating a whole new
> object instead of altering state within it.
Why not pass state objects which capture all the necessary
information around?
> The whole use of *PRINT-x* variables is quite interesting in this
> respect. It's kind of obvious that there should be some `printer
> control' object which you can pass to printer functions, and then just
> one special variable. But then, if these things have mutable state,
> it's really easy to fall into the trap above. At least with printer
> control variables the normal variable binding mechanisms make sure
> that things happen like you expect. Another approach I've heard
> suggested is to have the printer-control state be an attribute of the
> stream, but this has fairly similar problems.
>
> So maybe special variables aren't quite so bad, after all.
No, they aren't bad - carefully used. But they have a similar
problem: If you set a special variable, for what does the
setting should have effect?
a) for this "situation"? Whatever situation means: file stream,
window, network stream?
b) globally? So everybody can set globally your printing options?
potentially a bad idea.
c) per process? Does every process have it's own set of
special variables? So that when we bundle a stream
and a process, we magically get the right (per stream)
settings? But then, now we have more than one
*print-length* .
d) per binding? So you have processes and streams and
setting a variable either sets the global or a binding
that was in effect when you created that process/stream
combination?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Tim Bradshaw
Subject: Re: Comparison of CL Implementations?
Date:
Message-ID: <ey3pum9q07r.fsf@cley.com>
* Rainer Joswig wrote:F
> Why not pass state objects which capture all the necessary
> information around?
I'm not sure I understand this. The problem I'm trying to describe is
that if you use objects with mutable state, which you `bind' by
mutating the state, then essentially this is a shallow-binding
system, *but* the threading system doesn't know about it, so bad
things can happen.
> No, they aren't bad - carefully used. But they have a similar
> problem: If you set a special variable, for what does the
> setting should have effect?
The great advantage of special variables is that there is a
system-supported method of binding them as well as assigning to them,
and in a threaded Lisp things will happen `right'. So you can always
finesse the problems you mention of not knowing for whom the setting
has effect, by binding it rather than assigning. There are (as you
pointed out) still problems of knowing what happens with things like
threads -- are variables rebound per-thread or something? -- and
whether assigning is altering the top-level value of just a binding,
but the pass-around-a-state-object approach *also* has all these
problems.
--tim
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··························@meta.verbum.org>, Colin Walters
> <·······@cis.ohio-state.edu> wrote:
>
> > I used to think that dynamic scoping was totally evil, and after a
> > while of programming Emacs Lisp I started to wonder why it was
> > dynamically scoped in the first place. I came across the following
> > reference:
> >
> > http://www.gnu.org/software/emacs/emacs-paper.html#SEC18
I don't think that this reference gives a really good argument for the
default behavior of variables to be dynamically scoped. For example,
take the case in elisp:
(defun foo ()
(let ((baz 3))
(bar)))
(defun bar ()
baz)
this would work just fine in elisp, but would obviously be bad CL
code. But with the addition of the:
(declare (special baz))
inside the LET, it would work as it would in elisp. But I don't think
that the elisp creator(s) wanted to implement declarations. So there
were probably a lot of issues. Also, if you're designing an
interpreter for Lisp, I think it's significantly easier to just give
all variables dynamic scope. So essentially, these decisions were
made for the purposes of simplifying implementation, and not for
making a better environment for programming.
the link you provided makes a simple argument that can be handled by
DEFVAR or DEFPARAMETER. So it's really not an argument for why Emacs
Lisp is the way it is.
dave
In article <··············@cadet.dsl.speakeasy.net>,
David Bakhash <·····@alum.mit.edu> writes:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
>> In article <··························@meta.verbum.org>, Colin Walters
>> <·······@cis.ohio-state.edu> wrote:
>>
>> > I used to think that dynamic scoping was totally evil, and after a
>> > while of programming Emacs Lisp I started to wonder why it was
>> > dynamically scoped in the first place. I came across the following
>> > reference:
>> >
>> > http://www.gnu.org/software/emacs/emacs-paper.html#SEC18
>
> I don't think that this reference gives a really good argument for the
> default behavior of variables to be dynamically scoped. For example,
> take the case in elisp:
Uh, this paper is talking about the TECO version of Emacs! If you read the
section entitled "Successors of Emacs", after mentioning Multics Emacs and
ZWEI, it says "The essential improvement was the substitution of an excellent
programming language, Lisp, for the makeshift extended TECO used in EMACS." So
all of the talk about dynamic scoping is with respect to TECO.
Later in the same paragraph, it says "Another improvement has been in the
data structure used to represent the editing buffer: Multics EMACS developed
the technique of using a doubly-linked list of lines, each being a string.
This technique is used in ZWEI as well." So why'd GNU Emacs go to the "gap"
method? Is it easier for C programmers/libraries? I always liked the doubly
linked list of lines myself.
Mike McDonald
·······@mikemac.com
From: Tim Bradshaw
Subject: Re: Comparison of CL Implementations?
Date:
Message-ID: <ey3hf7lplrn.fsf@cley.com>
* Mike McDonald wrote:
> Later in the same paragraph, it says "Another improvement has been in the
> data structure used to represent the editing buffer: Multics EMACS developed
> the technique of using a doubly-linked list of lines, each being a string.
> This technique is used in ZWEI as well." So why'd GNU Emacs go to the "gap"
> method? Is it easier for C programmers/libraries? I always liked the doubly
> linked list of lines myself.
I think gap-based systems have quite good characteristics.
File I/O can be amazingly good -- you can probably read a buffer in
one OS call (+ allocate memory) and write it in 2.
Buffer positions are integers with a check as to which side of the gap
you're on. Regions in the buffer are pairs of integers.
Insertion and deletion are trivial -- move the gap, adjust the length
of the bit you're inserting/deleting at the end of.
No need to even think about lines except in redisplay. You can edit
arbitrary binary files without stress.
Generally nothing needs to waste time dealing with line ends all over
the place.
Probably better memory locality.
Of course it can be bad if you insert or delete at a `bad' choice of
places in the buffer because you end up doing lots of, possibly large,
memory copies.
Redisplay is harder with a gap.
--tim
Tim Bradshaw wrote in message ...
>* Mike McDonald wrote:
>
>> Later in the same paragraph, it says "Another improvement has been in
the
>> data structure used to represent the editing buffer: Multics EMACS
developed
>> the technique of using a doubly-linked list of lines, each being a
string.
>> This technique is used in ZWEI as well." So why'd GNU Emacs go to the
"gap"
>> method? Is it easier for C programmers/libraries? I always liked the
doubly
>> linked list of lines myself.
>
>I think gap-based systems have quite good characteristics.
The main problem with them is that it's hard to have "lines" (1)
as first-class objects, meaning that it's hard to have polymorphism,
meaning that it's hard to have "interesting" (2) behavior.
(1) By a "line", I mean a thing that, roughly speaking, stretches
from left to right (or right to left) across the window. A line can
contain all kinds of things, text and graphics alike.
(2) "Interesting" means, graphical display, markup, etc.
(Sorry to mention Dylan, but...) The editor I did in Dylan -- Deuce
by name -- does some interesting things with polymorphic lines,
and the doubly-linked representation also extends to sections of
the buffer itself, meaning the buffers can be composed in other
interesting ways, such as "all callers of X" or "all subclasses of C".
This would have been very tough with a gap-based structure.
The big trade-off is, of course, space and speed. These first-class
objects cost you in space (about 2 bytes for every byte of source
file, the last time I measured), and in speed. On the other hand,
processors are fast and memory is cheap...
Colin Walters <·······@cis.ohio-state.edu> writes:
> I used to think that dynamic scoping was totally evil, and after a
> while of programming Emacs Lisp I started to wonder why it was
> dynamically scoped in the first place. I came across the following
> reference:
>
> http://www.gnu.org/software/emacs/emacs-paper.html#SEC18
i think the problem isn't the existance of dynamically scoped
variables (after all, common-lisp has these too), but the lack of
lexical variables (lexical-let notwithstanding).
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
sysengr
David Bakhash <·····@alum.mit.edu> writes:
> One important thing to consider is that CL2Scheme translation is
> harder than the other direction (which is triviality defined,
> relatively speaking).
Yes, but it's worth bearing in mind that CL and Scheme aren't the only
languages people will be interested in using with Guile. I don't know
exactly why they chose Scheme instead of CL or some other language as
the base, but I can certainly see benefits in using a less complex
language with less overhead, when in many cases the full range of CL
features would not be needed.
> 1) Guile has a bunch of non-standard-looking extensions to provide
> CL-like functionality, and is mostly broken and ugly. Among those
> are:
>
> o macros (with no really useful auxilliary tools for handling
> them)
>
> o specialized defun/defmacro for handling CL-style parameter
> lists, also incomplete (with respect to Common Lisp), and yet
> people use it (which just shows that they *really* want Common
> Lisp in the first place).
I don't think defmacro is meant to be used directly, more as a base
for the R5RS syntax extension system, which for Guile is defined in
the (ice-9 syncase) module.
> o their packaging system (define-module ...) and (use-module ...)
> stuff, all slapped-on.
Well, it's slapped on in that there isn't a standard module system in
Scheme so it's Guile-specific, but I don't think it's particularly
badly done.
> 2) Shared namespace with functions and variables.
That's a matter of personal preference; if you learnt Lisp before
Scheme you probably prefer separate namespaces, but personally I find
the separate namespaces in (Common|Emacs) Lisp confusing and annoying.
> The Gimp also is pretty impressive. No one would argue that it's a
> weak product, and is only as good as it is because Guile has done a
> nice job of interfacing to C. So I can't really say that if XEmacs
> started using Guile that it would be a disaster. It just won't be a
> step in the right direction.
Ah...much as I like Guile, the Gimp doesn't use it (I think they plan
to change over, but haven't yet). Script-Fu is interpreted using SIOD
(Scheme In One Defun, a tiny and fairly featureless implementation of
some of Scheme). The Gimp's internals are made available through its
own procedural database system, which AFAIK isn't linked to Guile. It
might well be better if it was in Guile, but at the moment it isn't.
Andy
--
Andy Smith ·····@cam.ac.uk
St John's College, Cambridge, CB2 1TP, UK (07989) 453208
In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
<·····@alum.mit.edu> wrote:
> One important thing to consider is that CL2Scheme translation is
> harder than the other direction (which is triviality defined,
> relatively speaking).
In the CMU Lisp archive is such a beast (CL on Scheme), IIRC.
> BTW, as long as we're here, what is the right CL to use for an editor?
>
> I'd say CMUCL, since it's supposedly the best free Lisp out there and
> supports networking, threads, Garnet/CLX, etc. But the downside is
> that it doesn't run on too many platforms (e.g. MS Windows). CLISP,
> my favorite free implementation, runs on everything and its mother,
> but lacks some features that might be useful for an editor.
CMU CL has already Hemlock (It�s editor written in CL).
So take CLisp this time. ;-)
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
> <·····@alum.mit.edu> wrote:
>
> > One important thing to consider is that CL2Scheme translation is
> > harder than the other direction (which is triviality defined,
> > relatively speaking).
>
> In the CMU Lisp archive is such a beast (CL on Scheme), IIRC.
There is a compatibility package (the link below for those
interested). But please note that it's NOT Common Lisp, and it's a
far cry from it.
ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/code/library/cl2scm/0.html
All this does is implement the following functions and macros from CL:
CL MIT Scheme (if different)
-----------------------------------------------------------
AREF AREF & ARRAY-SET!
ARAAY-DIMENSION
ARRAY-DIMENSIONS
ARRAY-RANK
ASH
COMPILE
CONCATENATE
COUNT
COUNT-IF
DEFMACRO
DO*
DOLIST
DOTIMES
ELT
FIND
FILL
FUNCALL
INTEGER-LENGTH
LENGTH CL-LENGTH
LOGAND
LOGANDC2
LOGCOUNT
LOGIOR
LOOP
MAPCAN
MAPCAR MAP & MAP-VEC
NSUBSTITUTE-IF
NSUBSTITUTE-IF-NOT
POSITION
PRINT
PROG1
PSETQ
PUSH
READ-LINE
SEARCH
SET
SETF
SETQ SETQ & SETQQ
SORT CL-SORT
STRING CL-STRING
TIME
(TYPEP OBJ 'ATOM) ATOM?
UNLESS
WHEN
WITH-OPEN-FILE
Not only that, but the LOOP implementation is just for things like:
(loop
(print "hello world (again)"))
and not that this stuff doesn't really give you the CL environment;
just some of the functions that you get with CL (and missing quite a
few still, such as #'FORMAT). But even if these were there, it would
still be far from Common Lisp.
> > BTW, as long as we're here, what is the right CL to use for an
> > editor?
> > I'd say CMUCL, since it's supposedly the best free Lisp out there
> > and supports networking, threads, Garnet/CLX, etc. But the
> > downside is that it doesn't run on too many platforms (e.g. MS
> > Windows). CLISP, my favorite free implementation, runs on
> > everything and its mother, but lacks some features that might be
> > useful for an editor.
> CMU CL has already Hemlock (It�s editor written in CL). So take
> CLisp this time. ;-)
Well, if that's the case, and Hemlock has some of the basic
functionality that (X)Emacs has (e.g. buffers, windows, frames), then
I'm surprised that someone hasn't already written some package that
lets Hemlock run elisp code. Wouldn't that just be the ultimate
editor? If I could run VM, MailCrypt, Calc, Gnus, ilisp, BBDB, dired,
strokes, calendar, and all the stuff I use regularly in (X)Emacs, and
then also be able to extend it using Common Lisp, I'd give it a shot.
dave
In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
<·····@alum.mit.edu> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
> > <·····@alum.mit.edu> wrote:
> >
> > > One important thing to consider is that CL2Scheme translation is
> > > harder than the other direction (which is triviality defined,
> > > relatively speaking).
> >
> > In the CMU Lisp archive is such a beast (CL on Scheme), IIRC.
>
> There is a compatibility package (the link below for those
> interested). But please note that it's NOT Common Lisp, and it's a
> far cry from it.
I was thinking of:
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/bbn/0.html
"This directory contains the sources and binaries for BBN Butterfly
Common Lisp and BBN Butterfly Scheme. These programs have been
publicly released by BBN for the use of the programming community.
This software is unlikely to run on any machine other than the
butterfly without significant work; but it might make a good starting
point for a free implementation of Common Lisp."
BBN Butterfly Common Lisp is implemented in BBN Butterfly Scheme, AFAIK.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> I was thinking of:
>
> http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/bbn/0.html
Yeah. I'd heard of that implementation, but didn't know until now
that it was written in Scheme. But it's no surprise, of course.
Scheme is certainly a powerful enough language to express Common Lisp.
Has anyone used Butterfly Common Lisp? How is it? I've never heard
of anyone using it before in real applications. What Schemes does it
run under (besides Butterfly Scheme, of course). Is Butterfly Scheme
pretty standard as far as Schemes go?
If a CL implementation is complete, and works reasonably well, then I
don't really care what it's implemented in, even if I dislike that
language. For example, I'm perfectly happy using CLISP, and I know
it's written in C. I'm happy it's written in C because it's likely
the best langauge to use for the purpose. But CL also bootstraps
pretty well, and so no matter *what* underlying language you write CL
in, you end up being able to write a lot of it in CL -- something that
I don't see done as I look through the files in Butterfly CL.
dave
David Bakhash <·····@alum.mit.edu> writes:
> The Gimp also is pretty impressive. No one would argue that it's a
> weak product, and is only as good as it is because Guile has done a
> nice job of interfacing to C. So I can't really say that if XEmacs
> started using Guile that it would be a disaster. It just won't be a
> step in the right direction.
I actually work with Spencer Kimball, co-author of the Gimp. He said
it uses some other funky engine, not Guile, but I can't remember what.
(I've never played much with its guts...)
Funny story: as a practical joke, a friend of his ripped out the
entire Scheme engine and integrated the Gimp with Tcl instead. This
code never ended up in public, though.
--
vsync
http://quadium.net/
(cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner
(cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
vsync <·····@quadium.net> writes:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > The Gimp also is pretty impressive. No one would argue that it's a
> > weak product, and is only as good as it is because Guile has done a
> > nice job of interfacing to C. So I can't really say that if XEmacs
> > started using Guile that it would be a disaster. It just won't be a
> > step in the right direction.
>
> I actually work with Spencer Kimball, co-author of the Gimp. He said
> it uses some other funky engine, not Guile, but I can't remember what.
> (I've never played much with its guts...)
It's called Script-fu.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> wrote:
+---------------
| vsync <·····@quadium.net> writes:
| > [The Gimp] uses some other funky engine, not Guile...
|
| It's called Script-fu.
+---------------
Which in turn is just SIOD Scheme (per my previous reply) with a bunch of
primitives added. See <URL:http://www.gimp.org/~adrian/scripts/test.scm>
for some sample code.
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
vsync <·····@quadium.net> wrote:
+---------------
| I actually work with Spencer Kimball, co-author of the Gimp. He said
| it uses some other funky engine, not Guile, but I can't remember what.
+---------------
"SIOD" a.k.a. "Scheme in One Defun" a.k.a. "Scheme in One Day".
<URL:http://people.delphi.com/gjc/siod.html> It's roughly an R3RS
Scheme, with a bunch of miscellaneous but useful extensions
(including a lot of C library & Unix hooks). Its main claim to fame
is that it's *small* and fast-starting, and easy to integrate into
C programs to provide an extension language. Its main drawback (IMHO)
is that its "roughly R3RS" syntax & primitives are *way* too different
from the current R5RS.
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Network Engineering http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
Andy Smith <·····@cam.ac.uk> writes:
> ········@knuth.brownes.org (Christopher Browne) writes:
>
> > It seems more likely that if GNU Emacs "moved towards Guile," XEmacs
> > might react by "moving towards Common Lisp."
>
> Moving towards CL would seem like the wrong direction to me, since
> Guile isn't just Scheme, it's intended to handle multiple languages
> through translation (although at the moment I don't think there are
> many fully working translators). The move to Guile involves an Emacs
> Lisp to Guile translator rather than rewriting everything in Scheme.
> If people prefer to use Common Lisp, maybe it'd be better to write a
> CL translator for Guile, then other projects using Guile could also
> benefit.
"The Right Thing" would be to convince RMS that the whole Guile thing is
misguided. :)
Any taker? :)
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Andy Smith <·····@cam.ac.uk> writes:
>
> > ········@knuth.brownes.org (Christopher Browne) writes:
> >
> > > It seems more likely that if GNU Emacs "moved towards Guile," XEmacs
> > > might react by "moving towards Common Lisp."
> >
> > Moving towards CL would seem like the wrong direction to me, since
> > Guile isn't just Scheme, it's intended to handle multiple languages
> > through translation (although at the moment I don't think there are
> > many fully working translators). The move to Guile involves an Emacs
> > Lisp to Guile translator rather than rewriting everything in Scheme.
> > If people prefer to use Common Lisp, maybe it'd be better to write a
> > CL translator for Guile, then other projects using Guile could also
> > benefit.
>
> "The Right Thing" would be to convince RMS that the whole Guile thing is
> misguided. :)
Which part do you mean is misguided? Using scheme as the core
for a generic scriping facility or trying to develop a generic
scripting facility?
I'm not privy to all the discussion & details, but my take is as
follows. The idea of guile wasn't to be the best language for emacs.
The idea was to have one core scripting interpreter which could be
used in all GNU software. It's also supposed to be language neutral
in the sense of ultimately being able to interpret other languages,
such as TCL, Python, perl, awk, a C-like scripting language, etc. The
point is to be able to script all utilities in whatever language you
want to. I'd think the biggest impact would be on gdb, bash, awk &
emacs. The acid test is whether it works for emacs.
Being a good general scripting language requires that it at least not
look big, slow & complex. Scheme at least wins on the *perception*
that it's small & simple compared to Common Lisp. In practice one
will generally want more machinery than is in R5RS, but that can come
in to some extent as separate libraries, thus keeping the core
interpreter itself small-looking.
There was also an issue of building on existing work. Whereas there
are lots of scheme interpreters designed/advertised for embedding,
there aren't any Common Lisp systems for such. It also has to be
GPLable by the FSF.
When you try to get all that, then scheme isn't a bad choice. At
least it's scheme and not perl or Python or TCL or ...
--
Harvey Stein
Bloomberg LP
·······@bfr.co.il
In article <···············@blinky.bloomberg.com>, ·······@bfr.co.il
(Harvey J. Stein) wrote:
> There was also an issue of building on existing work. Whereas there
> are lots of scheme interpreters designed/advertised for embedding,
> there aren't any Common Lisp systems for such.
There are. I don't know how widely they are used, though.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <···············@blinky.bloomberg.com>, ·······@bfr.co.il
> (Harvey J. Stein) wrote:
>
> > There was also an issue of building on existing work. Whereas there
> > are lots of scheme interpreters designed/advertised for embedding,
> > there aren't any Common Lisp systems for such.
>
> There are. I don't know how widely they are used, though.
Names & references please...
--
Harvey Stein
Bloomberg LP
·······@bfr.co.il
In article <···············@blinky.bloomberg.com>, ·······@bfr.co.il
(Harvey J. Stein) wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > In article <···············@blinky.bloomberg.com>, ·······@bfr.co.il
> > (Harvey J. Stein) wrote:
> >
> > > There was also an issue of building on existing work. Whereas there
> > > are lots of scheme interpreters designed/advertised for embedding,
> > > there aren't any Common Lisp systems for such.
A quick check at Lisp.org and the Lisp FAQ should find enough
info that several attempts have been made in this direction.
So saying "there aren't any Common Lisp systems for such"
is a bit quick...
ECoLisp (ECL, Eco Common Lisp) is a Common Lisp implementation
which compiles Lisp functions into C functions
that use the C stack and standard procedure call conventions.
This lets Lisp and C code be easily mixed. It is designed to
be used as a C library from any C application. ECL also
includes MTCL, a multithread facility, and CLOS.
http://www.di.unipi.it/~attardi/software.html
http://citeseer.nj.nec.com/attardi95embeddable.html
http://www.acm.org/pubs/citations/proceedings/lfp/224139/p30-attardi/
See also ECLS (http://www.arrakis.es/~worm/ecls.html).
> >
> > There are. I don't know how widely they are used, though.
>
> Names & references please...
Some are not really CL. But what would you expect
from an embeddable Lisp:
From http://www.lisp.org/table/systems.htm and the Lisp FAQ:
- LinkLisp
- L
- ECoLisp (there is now a newer version: ECLS)
- WCL (updated, compiles to shared libraries)
- Eclipse (no longer available?)
- CLICC (old, compiles to plain C)
- jlisp
- librep
XLisp has been embedded, IIRC.
CONS, based on AKCL/IBUKI CL (formerly from IBUKI)
Lisp-to-C (formerly from Chestnut)
Gensym has internally a Lisp that's used inside G2
and doesn't need a GC.
I guess there are even more.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> A quick check at Lisp.org and the Lisp FAQ should find enough
> info that several attempts have been made in this direction.
> So saying "there aren't any Common Lisp systems for such"
> is a bit quick...
<List of embeddable lisp implementations deleted>
> Some are not really CL. But what would you expect
> from an embeddable Lisp:
Well, that's part of the point. The issue was "why not Common Lisp
for Emacs instead of Scheme". When you get to things like XLisp,
you've gotten pretty far from Common Lisp, at which point it's not
clear that using it is any less objectionable to those wanting Emacs
in Common Lisp than using Scheme is.
--
Harvey Stein
Bloomberg LP
·······@bfr.co.il
In article <···············@blinky.bloomberg.com>, ·······@bfr.co.il
(Harvey J. Stein) wrote:
> Well, that's part of the point. The issue was "why not Common Lisp
> for Emacs instead of Scheme". When you get to things like XLisp,
> you've gotten pretty far from Common Lisp,
Which is not really true, see below.
> at which point it's not
> clear that using it is any less objectionable to those wanting Emacs
> in Common Lisp than using Scheme is.
XLisp is available for a long time. If people were interested
it could have moved in the Common Lisp direction.
XLISP-Plus, Winterp and XLISP-Stat are derivatives.
So let's look into the documentation of XLISP-PLUS:
XLISP-PLUS is an enhanced version of David Michael Betz's XLISP to
have additional features of Common Lisp. XLISP-PLUS is distributed
for the IBM- PC family and for UNIX, but can be easily ported to
other platforms. Complete source code is provided (in "C") to allow
easy modification and extension.
Since XLISP-PLUS is based on XLISP, most XLISP programs will run on
XLISP- PLUS. Since XLISP-PLUS incorporates many more features of
Common Lisp, many small Common Lisp applications will run on
XLISP-PLUS with little modification. See the section starting on page
111 for details of the differences between XLISP and XLISP-PLUS.
Many Common Lisp functions are built into XLISP-PLUS. In addition,
XLISP defines the objects 'Object' and 'Class' as primitives.
'Object' is the only class that has no superclass and hence is the
root of the class heirarchy tree. 'Class' is the class of which all
classes are instances (it is the only object that is an instance of
itself).
...
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
On Thu, 14 Sep 2000 15:43:56 +0200, Rainer Joswig
<······@corporate-world.lisp.de> wrote:
>
>XLisp is available for a long time. If people were interested
>it could have moved in the Common Lisp direction.
>XLISP-Plus, Winterp and XLISP-Stat are derivatives.
>
xlisp-stat is even a lot more common lisp like, except for the object
system, which is protype based. There is a port of closette for
xlisp-stat.
see:
http://www.stat.umn.edu/~luke/xls/xlsinfo/xlsinfo.html
and for common lisp compatibility code:
http://www.cs.nwu.edu/academics/courses/c25/programs/xlisp/
Marc
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
······@No-Such-Domain.anywhere (see.signature) writes:
> On Thu, 14 Sep 2000 15:43:56 +0200, Rainer Joswig
> <······@corporate-world.lisp.de> wrote:
>
> >
> >XLisp is available for a long time. If people were interested
> >it could have moved in the Common Lisp direction.
> >XLISP-Plus, Winterp and XLISP-Stat are derivatives.
> >
>
> xlisp-stat is even a lot more common lisp like, except for the object
> system, which is protype based. There is a port of closette for
> xlisp-stat.
Have either of you used xlisp & xlispstat?
I've used xlispstat extensively. I've also use xlisp (or xlisp-plus,
depending how you look at it) & winterp. Luke Tierney's done a lot of
good work in making it closer to Common Lisp, both adding missing
Common Lisp features & and removing differences, but it still has a
ways to go before I'd call it Common Lisp. Not to mention the
fundamental differences btw it and Common Lisp, such as no CLOS, no
fractions, no bignums, vectorized arithemtic operators (in xlispstat,
not in xlisp), etc.
I think it's different enough that a serious Common Lisp programmer
who's complaining about Emacs being written in Scheme would still
complain if they switched & decided to use xlisp instead.
--
Harvey Stein
Bloomberg LP
·······@bfr.co.il
From: Reini Urban
Subject: Re: Comparison of CL Implementations?
Date:
Message-ID: <39c3963e.881269238@judy>
Harvey J. Stein wrote:
>Marco Antoniotti <·······@cs.nyu.edu> writes:
> > "The Right Thing" would be to convince RMS that the whole Guile thing is
> > misguided. :)
>
>Which part do you mean is misguided? Using scheme as the core
>for a generic scriping facility or trying to develop a generic
>scripting facility?
scheme is okay, only guile is the problem.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
······@xarch.tu-graz.ac.at (Reini Urban) writes:
> Harvey J. Stein wrote:
> >Marco Antoniotti <·······@cs.nyu.edu> writes:
> > > "The Right Thing" would be to convince RMS that the whole Guile thing is
> > > misguided. :)
> >
> >Which part do you mean is misguided? Using scheme as the core
> >for a generic scriping facility or trying to develop a generic
> >scripting facility?
>
> scheme is okay, only guile is the problem.
So you're saying the only problem is the core scheme interpreter?
What don't you like about it? What would you have prefered?
BTW, there's work going on now to replace the core interpreter with
qscheme's VM, if that helps any.
--
Harvey Stein
Bloomberg LP
·······@bfr.co.il
In article <···············@blinky.bloomberg.com>, ·······@bfr.co.il
(Harvey J. Stein) wrote:
> ······@xarch.tu-graz.ac.at (Reini Urban) writes:
>
> > Harvey J. Stein wrote:
> > >Marco Antoniotti <·······@cs.nyu.edu> writes:
> > > > "The Right Thing" would be to convince RMS that the whole Guile thing is
> > > > misguided. :)
> > >
> > >Which part do you mean is misguided? Using scheme as the core
> > >for a generic scriping facility or trying to develop a generic
> > >scripting facility?
> >
> > scheme is okay, only guile is the problem.
>
> So you're saying the only problem is the core scheme interpreter?
> What don't you like about it? What would you have prefered?
>
> BTW, there's work going on now to replace the core interpreter with
> qscheme's VM, if that helps any.
What is qscheme??? ;-)
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig wrote in message ...
>What is qscheme??? ;-)
http://www.sof.ch/dan/qscheme/index-e.html
(The author claims it to be really fast, but I haven't seen it
in action, yet)
cheers,
felix
From: Reini Urban
Subject: Re: Comparison of CL Implementations?
Date:
Message-ID: <39c776c2.1135353371@judy>
Harvey J. Stein wrote:
>······@xarch.tu-graz.ac.at (Reini Urban) writes:
> > scheme is okay, only guile is the problem.
>
>So you're saying the only problem is the core scheme interpreter?
>What don't you like about it? What would you have prefered?
it's not the scheme interpreter itself, it's more the culture behind.
but I won't say anything more on this.
I would have preferred a cleaner scheme, for example with more scheme
than c.
······@xarch.tu-graz.ac.at (Reini Urban) writes:
> Harvey J. Stein wrote:
> >······@xarch.tu-graz.ac.at (Reini Urban) writes:
> > > scheme is okay, only guile is the problem.
> >
> >So you're saying the only problem is the core scheme interpreter?
> >What don't you like about it? What would you have prefered?
>
> it's not the scheme interpreter itself, it's more the culture behind.
> but I won't say anything more on this.
>
> I would have preferred a cleaner scheme, for example with more scheme
> than c.
I would have preferred the real thing.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Reini Urban
Subject: Re: Comparison of CL Implementations?
Date:
Message-ID: <39c8e758.1229710960@judy>
Marco Antoniotti wrote:
>······@xarch.tu-graz.ac.at (Reini Urban) writes:
>> Harvey J. Stein wrote:
>> >······@xarch.tu-graz.ac.at (Reini Urban) writes:
>> > > scheme is okay, only guile is the problem.
>> >
>> >So you're saying the only problem is the core scheme interpreter?
>> >What don't you like about it? What would you have prefered?
>>
>> it's not the scheme interpreter itself, it's more the culture behind.
>> but I won't say anything more on this.
>>
>> I would have preferred a cleaner scheme, for example with more scheme
>> than c.
>
>I would have preferred the real thing.
of course. but remember, there's still RMS.
maybe he just disliked germans (CLISP), CMUCL was obviously too big.
and it was not from MIT.
In article <···················@judy>,
······@xarch.tu-graz.ac.at (Reini Urban) writes:
> of course. but remember, there's still RMS.
> maybe he just disliked germans (CLISP), CMUCL was obviously too big.
> and it was not from MIT.
I thought the proble with CMUCL was that is was free, not Free.
Mike McDonald
·······@mikemac.com
In article <····················@typhoon.aracnet.com>,
Mike McDonald <·······@mikemac.com> wrote:
>
> I thought the proble with CMUCL was that is was free, not Free.
This is so confusing. Why don't you use simple English
words like "libre" and "gratis"?
--d
·······@mikemac.com (Mike McDonald) writes:
> I thought the proble with CMUCL was that is was free, not Free.
Public Domain is about as Free as it gets. It just doesn't have any
guarantee that derived works remain so.
I think CMUCL has Symbolics code in it though, which is hardly likely
to endear it to RMS.
-dan
--
http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm
... back soon, with luck
Daniel Barlow <···@telent.net> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
> > I thought the proble with CMUCL was that is was free, not Free.
>
> Public Domain is about as Free as it gets. It just doesn't have any
> guarantee that derived works remain so.
>
> I think CMUCL has Symbolics code in it though, which is hardly likely
> to endear it to RMS.
I am not aware of any such code. The only thing that was non-free by
DFSG standards was defsystem, but Marco Antoniotti's work on a truly
free defsystem is a drop in replacement for it.
I have not gone over every bit of code in the system, so I could
ofcourse be mising something.
--
Craig Brozefsky <·····@red-bean.com>
LispWeb -- Mailing list for Lisp Based Web Development
Homepage: http://www.red-bean.com/lispweb
Craig Brozefsky <·····@red-bean.com> writes:
> > I think CMUCL has Symbolics code in it though, which is hardly likely
> > to endear it to RMS.
>
> I am not aware of any such code. The only thing that was non-free by
> DFSG standards was defsystem, but Marco Antoniotti's work on a truly
> free defsystem is a drop in replacement for it.
I didn't _say_ it was non-free. I said it was Symbolics. Look at
src/code/loop.lisp, which contains both a Symbolics copyright message
and (what looks like) a MIT-style license for same.
Sorry for any confusion my remark may have caused.
-dan
Craig Brozefsky <·····@red-bean.com> writes:
> Daniel Barlow <···@telent.net> writes:
>
> > ·······@mikemac.com (Mike McDonald) writes:
> >
> > > I thought the proble with CMUCL was that is was free, not Free.
> >
> > Public Domain is about as Free as it gets. It just doesn't have any
> > guarantee that derived works remain so.
> >
> > I think CMUCL has Symbolics code in it though, which is hardly likely
> > to endear it to RMS.
>
> I am not aware of any such code. The only thing that was non-free by
> DFSG standards was defsystem, but Marco Antoniotti's work on a truly
> free defsystem is a drop in replacement for it.
Well, I didn't do much. I just tracked down Mark Kantrowitz and
repackaged DEFSYSTEM to make it DFSG compliant.
I believe that there was some discussion between the CMUCL folks and
RMS about making CMUCL *the* GNU CL. If I remember correctly they
stumbled upon the problem of having the copyright transferred to the
FSF. Some time later the CMU people were able to put CMUCL in the
Public Domain.
People from CMU will be able to fill in the details.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
······@xarch.tu-graz.ac.at (Reini Urban) writes:
> Harvey J. Stein wrote:
> >Marco Antoniotti <·······@cs.nyu.edu> writes:
> > > "The Right Thing" would be to convince RMS that the whole Guile thing is
> > > misguided. :)
> >
> >Which part do you mean is misguided? Using scheme as the core
> >for a generic scriping facility or trying to develop a generic
> >scripting facility?
>
> scheme is okay, only guile is the problem.
Scheme + all the libraries and extensions to make it like Common Lisp
is okay. :)
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
In article <···············@octagon.mrl.nyu.edu>,
Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>······@xarch.tu-graz.ac.at (Reini Urban) writes:
>
>> Harvey J. Stein wrote:
>> >Marco Antoniotti <·······@cs.nyu.edu> writes:
>> > > "The Right Thing" would be to convince RMS that the whole Guile thing is
>> > > misguided. :)
>> >
>> >Which part do you mean is misguided? Using scheme as the core
>> >for a generic scriping facility or trying to develop a generic
>> >scripting facility?
>>
>> scheme is okay, only guile is the problem.
>
>Scheme + all the libraries and extensions to make it like Common Lisp
>is okay.
I don't think any library-based extension of
Scheme can hope to capture the namespace and scoping
restrictions of CL. Although it can mimic the
continuation restrictions fairly easily.
--d
In article <············@news.gte.com>, ····@goldshoe.gte.com (Dorai
Sitaram) wrote:
> >Scheme + all the libraries and extensions to make it like Common Lisp
> >is okay.
>
> I don't think any library-based extension of
> Scheme can hope to capture the namespace and scoping
> restrictions of CL. Although it can mimic the
> continuation restrictions fairly easily.
>
> --d
If it could do the rest, it'd be just fine.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
"Fernando Rodriguez" <···@mindless.com> writes:
[emacs lisp]
> It's going to be replaced with GUILE, no? :-?
I seriously doubt that will happen in the near future (i.e. the next
two years). Emacs Lisp, although it certainly has its flaws (no
closures!), has been very successful at its job. One only has to look
at tools like Gnus, PCL-CVS, and Ilisp to see that.
Although I do remember learning in a linguistics class about a theory
that what we can think is limited by our language. Sometimes I wonder
what kind of applications Emacs would have today if it was based on a
more elegant extension language (like CL or Scheme).
Colin Walters <·······@cis.ohio-state.edu> writes:
> Emacs Lisp, although it certainly has its flaws (no closures!), has
> been very successful at its job. One only has to look at tools like
> Gnus, PCL-CVS, and Ilisp to see that.
C-h f lexical-let <ENTER>
> Although I do remember learning in a linguistics class about a
> theory that what we can think is limited by our language. Sometimes
> I wonder what kind of applications Emacs would have today if it was
> based on a more elegant extension language (like CL or Scheme).
First off, elisp is better than Scheme. In fact, scheme is so simple
that I've seen a reasonably small package where Scheme is implemented
in elisp.
dave
David Bakhash <·····@alum.mit.edu> writes:
> C-h f lexical-let <ENTER>
Well, I hope you agree that this is kind of ugly. But, of course
Emacs Lisp is Turing-complete, so we can implement other languages and
features on top of it. It's just a question of elegance and
accessibility.
> First off, elisp is better than Scheme. In fact, scheme is so
> simple that I've seen a reasonably small package where Scheme is
> implemented in elisp.
Well, Scheme has closures and such "built in", and is just in general
a more modern language than Elisp, so I would still prefer Scheme over
Elisp. However, I probably would like something more CL-ish over
either of them...
In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
<·····@alum.mit.edu> wrote:
> Yeah. I can see how lots of people would like that, and that XEmacs
> couldn't easily produce that (though it can produce that with some
> stuff like speedbar, etc.)
Another features that an external editor has a hard time
to support are "presentations". There were attempts
to let an Xemacs listener buffer act like an CLIM or DW
listener (where printed/drawn objects are remembered and
are mouse sensitve). Well, this is tough. One similar feature
which is really hard to mimic and I have seen it until now only
on the Lisp machine is that a presentation parser can parse
from another window, from text to objects. Typically this has
scenarios like the following three:
1) one editor with a minibuffer: You have typed an extended
command which wants arguments (like "Show CLOS Generic Function"
wants the function). Now the minibuffer accepts the
function from other panes on the same level.
2) one editor with a type-out window (a temporary window that
runs from the top over the current window, while that is suspended).
The type-out window runs a listener command loop which accepts
commands and Lisp objects - the listener now accepts input
also from the underlying editor screen.
3) one editor and one listener side by side. The listener
also parses input from the editor.
See an example at
http://corporate-world.lisp.de/lispm/zmacs-listener.jpg .
Here I've typed "Show Class Initargs" (well, sort of.
I typed "init c-sh-/" and clicked on one of the commands)
in the Dynamic Lisp Listener 2 and the listener then asks for
a class (a class object or a class-name). All classes
displayed/drawn/presented in the listener would now be
mouse sensitive. Moving the mouse over to the Zmacs frame,
shows that there the word "http-ui" is mouse sensitive,
since it really is currently a class in the lisp system.
Any other words not denoting classes are not mouse
sensitive.
This is highly cool, since it makes your Lisp source code
*active*. A buffer is no longer a dead sequence of characters,
but like a dynamic collection of active objects. "Dynamic Windows"
parses the textual representations in the source code to
actual Lisp objects in your system. If you would be asked for a
pathname, all external representations of pathnames in
the source would be mouse sensitive. If you would be asked
for an integer between one and three, all ones, twos and threes
would be mouse sensitive. Etc.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig wrote in message ...
>In article <··············@cadet.dsl.speakeasy.net>, David Bakhash
><·····@alum.mit.edu> wrote:
>
>> Yeah. I can see how lots of people would like that, and that XEmacs
>> couldn't easily produce that (though it can produce that with some
>> stuff like speedbar, etc.)
>
>Another features that an external editor has a hard time
>to support are "presentations". There were attempts
>to let an Xemacs listener buffer act like an CLIM or DW
>listener (where printed/drawn objects are remembered and
>are mouse sensitve). Well, this is tough. One similar feature
>which is really hard to mimic and I have seen it until now only
>on the Lisp machine is that a presentation parser can parse
>from another window, from text to objects. Typically this has
>scenarios like the following three:
>
>This is highly cool, since it makes your Lisp source code
>*active*. A buffer is no longer a dead sequence of characters,
>but like a dynamic collection of active objects. "Dynamic Windows"
>parses the textual representations in the source code to
>actual Lisp objects in your system. If you would be asked for a
>pathname, all external representations of pathnames in
>the source would be mouse sensitive. If you would be asked
>for an integer between one and three, all ones, twos and threes
>would be mouse sensitive. Etc.
>
I wonder if the world will ever catch up to this. One thing
that is a huge step backwards -- bear with me for a minute --
it the GUI. As a first step for usability, GUI's are very good,
but the problem is, people stopped thinking at that point.
People look at a command line interface like anything on
Unix and immediately conclude that command line UIs
suck, which, in the case of Unix and DOS is true. People
have stopped looking for a hybrid, mixed-mode graphical
and command-line UI. IMO, Genera was too command-line
oriented, but it is possible to do a much better mixed-mode
UI in CLIM. CLIM's problem is, of course, that it does only
a fair job on native look-and-feel.
I actually have a presentation layer for DUIM -- the Dylan
successor to CLIM -- that does a good job of both. What
it lacks is:
- a super-cool interactive input editor
- production quality
The metaphor that pops into my head about GUI's is that
of an infant: infants point at somthing they want, and/or
directly manipulate it. Once they grow up (linguistically),
they trade this in for a more powerful, more abstract UI,
namely language. It's harder to learn this sort of UI, but
in the long run it's easier to use and more powerful. UIs
on computers are still in the infant stage, except for
Unix-like command line interfaces, which are autistic.
"Scott McKay" <···@mediaone.net> writes:
> The metaphor that pops into my head about GUI's is that of an
> infant: infants point at somthing they want, and/or directly
> manipulate it. Once they grow up (linguistically), they trade this
> in for a more powerful, more abstract UI, namely language.
I'd agree with this, since people who know their way around a cmd line
interface can usually get what they want more easily than people with
graphical UIs. But yeah, the overhead to CLIs is often too expensive
to *want* to do it.
> UIs on computers are still in the infant stage, except for Unix-like
> command line interfaces, which are autistic.
Yeah. autistic is an excellent word. They're very advanced in a way,
and yet lack any social understand (i.e. what people really want).
Doesn't mean you can't get good at them, though.
I think the Unix tradeoff with cmd-line UIs is that Unix hackers were
lazy typers. That's the only way I can explain why they'd prefer:
% ls -l
to
% (ls :long-listing-p t)
But I'd like to know what you really mean when you talk about how
cmd-line UIs are "autistic".
dave
David Bakhash wrote in message ...
>"Scott McKay" <···@mediaone.net> writes:
>% ls -l
>
>to
>
>% (ls :long-listing-p t)
>
>But I'd like to know what you really mean when you talk about how
>cmd-line UIs are "autistic".
I said that I though traditional command line UI's are autistic.
I use this word because they are not at all interactive. They
understand a few cryptic interactions, and give you (at most)
a few cryptic responses.
Genera (and TOPS-20, for that matter) had much more "live"
command line interfaces that included context-senstitive input,
where the context varied dynamically depending on what had
been previously typed, true context-sensitive help, completion,
etc, etc. It was a vast difference, and enough to make some
strong GUI proponents of my acquaintence re-evaluate their
positions on this subject.
"Scott McKay" <···@mediaone.net> writes:
> I said that I though traditional command line UI's are autistic.
> I use this word because they are not at all interactive. They
> understand a few cryptic interactions, and give you (at most)
> a few cryptic responses.
This is a nice characterization of command line interfaces (CLIs).
One of the more abstract ways of describing user interfaces is that
CLIs rely on a conversational metaphor; in contrast, graphical user
interfaces (GUIs) rely on what Ed Hutchins calls a "model world"
metaphor. But, as someone pointed out a long time ago, interacting
with Unix is not very much like any normal human conversation: you say
a few words, and the machine spits back a huge mass of information.
You stare at each other for a while, and repeat the process. The
interaction can be flexible and powerful, but it certainly doesn't
exploit all of our skills in communication.
--
Rob St. Amant
in article ·······················@typhoon.ne.mediaone.net, Scott McKay at
···@mediaone.net wrote on 2000.09.10 8:06 AM:
> The metaphor that pops into my head about GUI's is that of an infant: infants
> point at somthing they want, and/or directly manipulate it. Once they grow up
> (linguistically), they trade this in for a more powerful, more abstract UI,
> namely language. It's harder to learn this sort of UI, but in the long run
> it's easier to use and more powerful. UIs on computers are still in the
> infant stage, except for Unix-like command line interfaces, which are
> autistic.
This is a good point. Keep in mind, however, that communicating through
"text" is not the same thing as communicating through "language". What we
might think of as "language" -- that which you can see written down -- is
really a very rich medium of communication that includes stress, intonation,
pauses, hand, facial, and body positions and motions, etc.
Pointing, clicking, and moving things with a mouse is not necessarily an
"infantile" means of communication, it's just that non-infants have learned
additional and more sophisticated means of communication. In fact, we never
give up gestures, we simple become more expert in using them.
Moving "beyond" simple point-click-and-drag interfaces does not necessarily
mean giving them up altogether. The Apple Newton pen-based interface, for
example, allowed for communicating with various "gestures" that aren't
easily performed with a mouse, and which could be quite natural and organic
for the user to perform with a stylus. But it still understood pointing,
selecting, and dragging.
On the other hand, a computer system that could be communicated with using
voice, gesture, and other physical indicators might be good at some things,
but sometimes writing something down, or pressing a button or two, would
still be a more efficient means of communication. This is true for
communicating between humans, as well.
--
Chris Page
Mac OS Guy
Palm, Inc.
let mail-to = concatenate( "Chris Page <page", ·@", "best.com>");
Hi
I wonder if you could explain in this forum (or on the free-clim
mailing list) how to get presentation types working on a regular
CL. What I am really getting at is: can you build presentation types
in an implementation independent way?
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
On Sun, 10 Sep 2000 15:06:40 GMT, "Scott McKay" <···@mediaone.net> wrote:
> it the GUI. As a first step for usability, GUI's are very good,
> but the problem is, people stopped thinking at that point.
This paper might be relevant, especially for its discussion of the role of
language:
The Anti-Mac Interface
http://www.acm.org/cacm/AUG96/antimac.htm
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
David Bakhash <·····@alum.mit.edu> wrote in article
<···············@mint-square.mit.edu>...
{snip!}
>
> Both ACL and LispWorks have great environments, without question. I'm
> not exactly sure why Harlequin took the trouble to write their
> emacs-like editor, but it *definitely* proves concept, since it looks to
> me like it was done completely in Common Lisp, using CAPI. If this
> doesn't prove that CAPI works, I don't know what does. Even Visual Cafe
> (the Java IDE from Symmantec (sp?)) is mostly written in VC++. So they
> didn't have the balls to use Java to write the IDE. LispWorks is
> definitely very cool like that.
>
Just for your information: Borland Delphi's IDE is written in Delphi (some
of it uses assembler calls, but that can be done in Delphi), and Borland's
JBuilder is built in Java. I'm rather impressed that Harlequin/Xanalysis
did that.
Morgan
"Morgan Rodwell" <········@home.com> writes:
> David Bakhash <·····@alum.mit.edu> wrote in article
> Just for your information: Borland Delphi's IDE is written in Delphi
> (some of it uses assembler calls, but that can be done in Delphi),
> and Borland's JBuilder is built in Java. I'm rather impressed that
> Harlequin/Xanalysis did that.
yeah. well I never said anything about Boreland's products. But
while we're there, I must admit that I like Boreland (especially
Interbase, which is the best free database out there right now). I've
always been impressed by their work.
dave
"David Bakhash" <·····@alum.mit.edu> escribi� en el mensaje
····················@mint-square.mit.edu...
> not exactly sure why Harlequin took the trouble to write their
> emacs-like editor, but it *definitely* proves concept, since it looks to
> me like it was done completely in Common Lisp, using CAPI. If this
BUt it still lacks syntax highlighting: it might be a minor annoyance, but
it's still an annoyance...
"Fernando Rodriguez" <···@mindless.com> wrote in message
······················@m2newsread.uni2.es...
>
> "David Bakhash" <·····@alum.mit.edu> escribi� en el mensaje
> ····················@mint-square.mit.edu...
> > not exactly sure why Harlequin took the trouble to write their
> > emacs-like editor, but it *definitely* proves concept, since it looks to
> > me like it was done completely in Common Lisp, using CAPI. If this
>
> BUt it still lacks syntax highlighting: it might be a minor annoyance, but
> it's still an annoyance...
>
I simply don't use its editor because of that, but nothing that xemacs
can't solve...
"Fernando Rodriguez" <···@mindless.com> writes:
> "David Bakhash" <·····@alum.mit.edu> escribi� en el mensaje
> ····················@mint-square.mit.edu...
> > not exactly sure why Harlequin took the trouble to write their
> > emacs-like editor, but it *definitely* proves concept, since it looks to
> > me like it was done completely in Common Lisp, using CAPI.
I understand Harlequin wanted to create an integrated programming
environment in the style of the Lisp Machines, on standard hardware.
(But that was before I joined.) I think all the clever little
features are worth it, even if it never did quite catch up to Genera.
Yes, it is written in CL; LispWorks only has about 3000 lines of C in
it, for initialization purposes mostly. And it uses CAPI, although
when it was first written, it used the LW Toolkit under OpenLook (yes,
it's been that long).
> BUt it still lacks syntax highlighting: it might be a minor annoyance, but
> it's still an annoyance...
It'll be in the next release, 4.2.
--
Pekka P. Pirinen, Harlequin Limited, Cambridge, UK
On the Internet nobody knows if you're a dog, but they will still treat
you like one. -me
"Pekka P. Pirinen" <·····@harlequin.co.uk> escribi� en el mensaje
···················@harlequin.co.uk...
> I understand Harlequin wanted to create an integrated programming
> environment in the style of the Lisp Machines, on standard hardware.
> (But that was before I joined.) I think all the clever little
> features are worth it, even if it never did quite catch up to Genera.
Are there any plans to continue in that direction? Lisp programming
environments seem to have stagnated for some years, while C/C++ environments
are catching up. MS VC even lets you (under certain circumstances) change
the source while debugging and continue executing the app without
recompiling. This seemed like a Lisp-only feature, but...
> > BUt it still lacks syntax highlighting: it might be a minor annoyance,
but
> > it's still an annoyance...
>
> It'll be in the next release, 4.2.
Scheduled for? O:-)
David Bakhash <·····@alum.mit.edu> writes:
> I'm not exactly sure why Harlequin took the trouble to write their
> emacs-like editor, but it *definitely* proves concept, since it
> looks to me like it was done completely in Common Lisp, using CAPI.
> If this doesn't prove that CAPI works, I don't know what does.
They did the same thing with Harlequin Dylan (now Functional
Developer[1]) as well. An extensible emacs-like editor called Deuce
was written in Dylan. The full source is available under an open
source license.
[1] http://www.functionalobject.com
--
http://www.double.co.nz/dylan
http://www.double.co.nz/cl
Chris Double wrote in message ...
>David Bakhash <·····@alum.mit.edu> writes:
>
>> I'm not exactly sure why Harlequin took the trouble to write their
>> emacs-like editor, but it *definitely* proves concept, since it
>> looks to me like it was done completely in Common Lisp, using CAPI.
>> If this doesn't prove that CAPI works, I don't know what does.
>
>They did the same thing with Harlequin Dylan (now Functional
>Developer[1]) as well. An extensible emacs-like editor called Deuce
>was written in Dylan. The full source is available under an open
>source license.
BTW, Deuce wasn't meant to be extensible the same way that
gnu emacs is extensible. It's meant to be extensible by a hacker
with Deuce sources, but it was never intended to have a real
extension language like emacs. Had I written it in Lisp and had
'eval' available, I might have been more ambitious in this area.
So no fair making fun of Deuce for failiing to implement an
explicit non-goal. ;-)
On 07 Sep 2000 15:02:12 -0400, David Bakhash <·····@alum.mit.edu> wrote:
> ones are better for viewing class hierarchies and things. When I used
> ACL in grad school, I used it on Unix, and there was thing thing called
> "Composer" or something like that, and it was graphical, and you could
Franz still sells the product (Allegro Composer).
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Morgan Rodwell" <········@home.com> writes:
I don't know what platforms you're on, but since you mentioned COM I'm
assuming Windows. I think you should reconsider, but that's another
story. We'll limit this to things that would run on a PC, either
running Linux or Windows.
> Specifically, I am looking at issues of development productivity
probably a good thing to do, since it narrows down your options.
> database support
Well, for both free and commercial implementations of CL, I think you're
good on lots of them, including:
o CLISP (PostGreSQL support)
o CMUCL (see MaiSQL, for example)
o ACL (ODBC, maybe more)
o LW (ODBC and vendor-specific drivers like Oracle)
o CormanLisp (???) -- not sure about database support
> COM support
this will rule out CMUCL I think. I think CLISP might also be out of
the running. However, the others can still work, AFAIK.
> CORBA support
I think you might lose here on CormanLisp, but not 100% sure. ACL and
LW support Corba, but I'm not sure to what extents (i.e. how conformant
they are). Again, I always question the need for Corba.
> documentation
The HyperSpec is there, and all of them have well-documented
extensions.
> support
I think that between this newsgroup, companies, and docs, you'll be fine.
> cost
this is where you will lose hard on only one particular implementation,
but all the others are reasonable.
> GC
If you are already sure that you'll need to tune GC, then I can just say
that I've done it a bit on ACL, and it certainly lets you do so. Same,
I'm guessing, for the others, though I've never done it on them.
> performance
If this is a heavy networking/database application, and it's well-coded,
then I doubt that the performance will be such a strong function of
speed of the compiled code from your Lisp system.
> portability (between Windows and Linux), etc.
I think that everything above works on Windows and Linux except CMUCL on
Windows and CormanLisp on Linux.
----------------
The reason I divided the above the way I did is that I think it's useful
to reconsider some of the constraints in order to use a different
implementation. If someone asked me which I cared more about, cost or
other stuff, I'd likely say other stuff. But when I recently talked to
two companies and one gave me a quote 15 times bigger than the other's,
(which was already a couple of thousand bucks), I had to do a
(decf *options*)
If you *really* need everything you stated above, then I'd strongly
suggest LispWorks. It's a good Common Lisp, well supported (I've had
the best experiences dealing with Harlequin's (now Xanalys) support
crew, and they always promptly, efficiently, and correctly handled my
issues). Their Lisp supports Corba, MS-specific stuff that I don't know
much about, has a very nice database interface (SQL, ODBC), works under
Windows and Linux, and several other environments, and is very
cost-effective and fairly priced. Also, it has amazingly useful
extensions.
dave
David Bakhash wrote:
> "Morgan Rodwell" <········@home.com> writes:
>
> > CORBA support
>
> I think you might lose here on CormanLisp, but not 100% sure. ACL and
> LW support Corba, but I'm not sure to what extents (i.e. how conformant
> they are). Again, I always question the need for Corba.
>
In my experience, ACL and lispworks both have good CORBA support for
simple servers. If you want to do something more complex and require a
POA, then lispworks is currently your only option. Franz is supposed to
be working on POA, but that is about all I know.
> > documentation
>
> The HyperSpec is there, and all of them have well-documented
> extensions.
>
Lispworks documentation is, well, lacking at times. And sometimes even
inaccurate. But their technical support is excellent. As someone else
has pointed out, it will take a little patience on your part to figure
out the ins and outs of some of the lispworks features.
> > support
>
> I think that between this newsgroup, companies, and docs, you'll be fine.
>
Sunil
In article <················@everest.com>, Sunil Mishra
<············@everest.com> wrote:
> Lispworks documentation is, well, lacking at times. And sometimes even
> inaccurate. But their technical support is excellent. As someone else
> has pointed out, it will take a little patience on your part to figure
> out the ins and outs of some of the lispworks features.
It would be nice when they would deliver the source code (as much as
possible) with Lispworks. This would be a big win for them.
MCL has a lot of attraction just because of that and that its
users have contributed tons of system specific extensions
over the years - this has not happened the same way on the
Unix or PC platforms. I'd like to see that happen.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <···············@mint-square.mit.edu>, David Bakhash
<·····@alum.mit.edu> wrote:
> other stuff, I'd likely say other stuff. But when I recently talked to
> two companies and one gave me a quote 15 times bigger than the other's,
> (which was already a couple of thousand bucks), I had to do a
>
> (decf *options*)
How about the length of *FEATURES* ? ;-)
> If you *really* need everything you stated above, then I'd strongly
> suggest LispWorks. It's a good Common Lisp, well supported (I've had
> the best experiences dealing with Harlequin's (now Xanalys) support
> crew, and they always promptly, efficiently, and correctly handled my
> issues). Their Lisp supports Corba, MS-specific stuff that I don't know
> much about, has a very nice database interface (SQL, ODBC), works under
> Windows and Linux, and several other environments, and is very
> cost-effective and fairly priced. Also, it has amazingly useful
> extensions.
On Windows I have only used LispWorks and found it quite
usable. The development environment is quite complete
and it comes with a lot of libraries. Drawbacks are,
well, the Windows platform (NT has some funky memory
management), and the UIMS doesn't update busy windows.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Reini Urban
Subject: Re: Comparison of CL Implementations?
Date:
Message-ID: <39c38eba.879345221@judy>
Morgan Rodwell wrote:
>I have been somewhat frustrated by Franz's failure to quote me a price on
>their environment, but suspect their product is superior (gut feel).
I have found the exact prices for everything on their website.
it's hefty (esp. considering the dollar exchange rate now) but it is
okay.
$ 1.750 per package, $ 1.750 single plus $ 1.750 for the runtime.
but you'll need the whole enterprise ed. (AllegroStore,...) which is
even more.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
From: Reini Urban
Subject: Re: Comparison of CL Implementations?
Date:
Message-ID: <39c60054.1039499721@judy>
Reini Urban wrote:
>Morgan Rodwell wrote:
>I have found the exact prices for everything on their website.
>it's hefty (esp. considering the dollar exchange rate now) but it is
>okay.
>$ 1.750 per package, $ 1.750 single plus $ 1.750 for the runtime.
>but you'll need the whole enterprise ed. (AllegroStore,...) which is
>even more.
oops. sorry for the infringement. it's not on their webpage.
this was the price from last month, for me personally.
In article <··················@judy>,
Reini Urban <······@sbox.tu-graz.ac.at> wrote:
>Morgan Rodwell wrote:
>>I have been somewhat frustrated by Franz's failure to quote me a price on
>>their environment, but suspect their product is superior (gut feel).
>
>I have found the exact prices for everything on their website.
>it's hefty (esp. considering the dollar exchange rate now) but it is
>okay.
>$ 1.750 per package, $ 1.750 single plus $ 1.750 for the runtime.
>but you'll need the whole enterprise ed. (AllegroStore,...) which is
>even more.
$1.750 is hefty? I see more than that in abandoned
coins on the road when I pedal to work. Oh,
you're using Euro notation... Never mind!
--d