Re: Where do you want to go tomorrow?
26 years, 4 months
Michael Sperber
Michael Sperber
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
Hrvoje> Why not add SNOBOL, for good measure?
Actually, Hrvoje, why not? It's still pretty much the most concise
language for text processing ... :-)
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
26 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
Holger Schauer <schauer(a)coling.uni-freiburg.de> writes:
> Hrvoje> Not so by design. In fact, we were discussing introduction
> Hrvoje> of a lexically scoped `let' to elisp many times. And guess
> Hrvoje> what? The proposed semantics were equivalent to those used
> Hrvoje> by CL -- lexical scope by default, dynamic scope for special
> Hrvoje> variables.
>
> Excuse me, Hrovje, where is this an argument for "not so by design"?
To rephrase: current behaviour of `let' is by no means considered a
feature. OK?
> We're arguing about probably having to change a lot of _existing_
> Emacs Lisp code
Only the code that bogusly uses special variables without declaring
them as such. This code would probably be easy enough to fix (easier
than ebola). Our byte-compiler even now warns of such code.
> Hrvoje> I don't care. Emacs is not ANSI CL. If that was the
> Hrvoje> impression I was giving, I apologize, because that is not
> Hrvoje> what I meant.
>
> But, what is then the point of substituting Emacs Lisp with another
> non-sense Lisp ?
Why do you call non-sense anything that is not strictly ANSI
conformant?
> I don't get it. If we substitute Emacs Lisp with something else, I
> would like to have an ANSI CL system (preferred) or a
> state-of-the-art RSR5-Scheme system. And, my favourite, if somebody
> wants to replace the existing lisp engine, go for a language engine
> that allows support for Emacs-Lisp, Common Lisp and Scheme (and perl
> or tcl, perhaps).
Yeah, and Java and C++. Why not add SNOBOL, for good measure?
> Hrvoje> a clear idea of what it would take. This, however, should
> Hrvoje> not mean I get no vote in the discussion. I know where I
> Hrvoje> want to end up.
>
> Please, say so, loud and clearly.
I did, but you weren't listening.
> (BTW: I haven't used CMUCL 18a, only the old 17f version. On Linux,
> this old version certainly was slow [no high speed garbage
> collection] and contained some bugs [especially the ffi], but I
> never encountered any bugs on a grown-old 17f on Sun Systems.
17f coredumped on me even on trivial examples. :-(
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The end of the world is coming... SAVE YOUR BUFFERS!
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
26 years, 4 months
Holger Schauer
Holger Schauer
>>>>"Hrvoje" == Hrvoje Niksic schrieb am 02 Jul 1998 02:58:07 +0200:
Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber
Hrvoje> [Mr. Preprocessor]) writes: Lots of elisp code can run under
Hrvoje> Common Lisp almost unchanged. This is not true for Scheme.
>> Please substantiate this. By default, for instance, `let' is
>> lexically scoped in Common Lisp, which is clearly incompatible
>> with Emacs Lisp.
Hrvoje> Not so by design. In fact, we were discussing introduction
Hrvoje> of a lexically scoped `let' to elisp many times. And guess
Hrvoje> what? The proposed semantics were equivalent to those used
Hrvoje> by CL -- lexical scope by default, dynamic scope for special
Hrvoje> variables.
Excuse me, Hrovje, where is this an argument for "not so by design" ?
We're arguing about probably having to change a lot of _existing_
Emacs Lisp code and not about the introduction of a new `lex-let'.
>> Consequently, you would need a library of macros and procedures to
>> emulate/translate Emacs Lisp functionality into Common Lisp.
Hrvoje> Quite true -- I am not denying this.
Hrvoje> I believe clisp is small enough, especially if we remove the
Hrvoje> parts we don't need.
>> This, however, means that Emacs CLisp won't be a standard Common
>> Lisp implementation anymore, and surely old CL buffs will
>> complain.
Hrvoje> I don't care. Emacs is not ANSI CL. If that was the
Hrvoje> impression I was giving, I apologize, because that is not
Hrvoje> what I meant.
But, what is then the point of substituting Emacs Lisp with another
non-sense Lisp ? I don't get it. If we substitute Emacs Lisp with
something else, I would like to have an ANSI CL system (preferred) or
a state-of-the-art RSR5-Scheme system. And, my favourite, if somebody
wants to replace the existing lisp engine, go for a language engine
that allows support for Emacs-Lisp, Common Lisp and Scheme (and perl
or tcl, perhaps). Is here somebody how followed the discussions on the
Lisp-OS/VM-Mailing Lists ? All arguments which came up here have been
discussed there already. With the following results: those who liked
Scheme, went to do some stuff in Scheme. And those, who wanted a CL
system, used CL. Guess what: I have not seen coming anything useful
out of the efforts.
Hrvoje> a clear idea of what it would take. This, however, should
Hrvoje> not mean I get no vote in the discussion. I know where I
Hrvoje> want to end up.
Please, say so, loud and clearly. I just said where I would like to
end up: with a Lisp engine supporting any flavour.
Hrvoje> I don't like CMU CL (far too slow and buggy IMHO), and I
Hrvoje> haven't worked with GCL much. It might be usable.
If you really think CMUCL is too slow and too buggy, you won't want to
consider GCL. (BTW: I haven't used CMUCL 18a, only the old 17f
version. On Linux, this old version certainly was slow [no high speed
garbage collection] and contained some bugs [especially the ffi], but
I never encountered any bugs on a grown-old 17f on Sun Systems. Note
that currently most development on CMUCL seems to be done on Intel
systems, so the situation is much likely to change [or has already
improved]. With clisp I had had problems in the past of even compiling
it under Linux.)
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer ---
Why people hate using Lisp:
"Are people suffering from parenthophobia-by-proxy, mistaking
`parens' for `parents'?" - Erik Naggum in comp.emacs.xemacs
- 1 participants
- 0 comments
[BUG]: Gnus 5.6.13 (gnus-1.18-pkg.tar.gz)
26 years, 4 months
Oscar Figueiredo
Oscar Figueiredo
I am a little confused by this one...
Signaling: (invalid-function (macro lambda (&optional n) (backquote (delete-region (progn (beginning-of-line) (point)) (progn (forward-line (\, (or n 1))) (point))))))
gnus-delete-line()
nnmail-article-group(nnml-active-number)
nnmail-check-duplication("<000e01bda598$c6d6f470$71b1e891(a)a51nt01.einev.ch>" nnml-save-mail nnml-active-number)
nnmail-process-unix-mail-format(nnml-save-mail nnml-active-number)
nnmail-split-incoming("~/.gnus-crash-box" nnml-save-mail nil nil nnml-active-number)
nnmail-get-new-mail(nnml nnml-save-nov "~/Mail" nil)
nnml-request-scan(nil "")
gnus-request-scan(nil (nnml ""))
gnus-read-active-file()
gnus-group-get-new-news(nil)
call-interactively(gnus-group-get-new-news)
Oscar
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
26 years, 4 months
Michael Sperber
Michael Sperber
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
>> If we're going to hook to a Lisp engine maintained by someone else
>> (which we hopefully will), there's no reason to take only a part of
>> it.
Hrvoje> Well, there are reasons such as size, speed, efficiency etc.
And there's maintainability.
Hrvoje> The Scheme users and implementors don't have the constraint
Hrvoje> of previous implementation of Common Lisp idioms. We do,
Hrvoje> and I would like us to preserve them.
>>
>> Sure. Let's.
Hrvoje> If we choose Scheme, I don't see the point.
The main idea to programming in Lisp-like languages has always been
that you tailor the programming idioms you use to the problem at hand,
and implement them using macros and higher-order functions.
Essentially, you embed your own "little language" into Lisp. If
there's any one Lisp programming idiom, that's it.
This doesn't happen much in Emacs Lisp because the language is not
expressive enough. It happens all the time in Common Lisp as well as
in Scheme. Scheme 48 comes with an embedded version of Icon and one
of Dylan. scsh comes with an embedded version of awk. MzScheme comes
with essentially an embedded version of Java etc. etc. etc. This all
makes perfect sense. I'm quite sure similar things exist in CL
implementations. (The CL *standard* specifies embeddings of Standard
Lisp, Franz Lisp, Lisp 1.5, Fortran, ..., ...)
Hrvoje> I don't like CMU CL (far too slow and buggy IMHO),
>>
>> Actually, CMU CL produces pretty much the fastest CL code around.
>> Unfortuntately, it only works on very few architectures.
Hrvoje> Exactly. And it's almost impossible to compile. And it's fucking
Hrvoje> huge. Etc.
I didn't mean to advocate it too much. CMU CL occasionally shows up
in language benchmarks, and does pretty well there. If and when it
works ...
Hrvoje> Clisp doesn't have a native compiler, but it would
Hrvoje> probably serve our purposes much better.
Totally.
Hrvoje> P.S.
Hrvoje> I'll forward my exchange with Bruno to the list.
Great!
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 1 participants
- 0 comments
Case for clisp
26 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
I haven't included my own contributions, but they are not really
significant. Reginald's claims about Scheme are not my own, and they
might well be incorrect -- I've included them for context only. The
most important arguments /pro/ clisp are by Bruno Haible.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Lost in Static 18 / And the storm is closing in now
------- Start of forwarded message -------
Date: Thu Jul 2 11:17:27 1998
From: Various
Subject: Digested Articles
Topics:
Re: perlemacs technical discussion
Re: perlemacs technical discussion
clisp, xemacs
Re: clisp, xemacs
Re: clisp, xemacs
----------------------------------------------------------------------
Date: 06 Feb 1998 17:25:28 -0800
From: perry(a)zso.dec.com (Reginald S. Perry)
To: Hrvoje Niksic <hniksic(a)srce.hr>
Subject: Re: perlemacs technical discussion
Message-Id: <sxlsopw1a0n.fsf(a)yakko.zso.dec.com>
Content-Type: text/plain; charset=US-ASCII
Hrvoje Niksic <hniksic(a)srce.hr> writes:
> maestrox(a)geocities.com (Nathan Froyd) writes:
>
> > > I've found Michael Sperber's arguments for using Scheme
> > > compelling.
> >
> > Scheme (especially Guile) would be attractive for a couple of
> > reasons:
> [...]
>
> For the record, Michael opposed using Guile quite vehemently (he
> argued for other Scheme variant, e.g. Rscheme). Also, not all the
> XEmacs developers favor Scheme. Unless this is handled very
> carefully, I wouldn't be surprised to see another split.
>
Question: Did anyone consider using something like Bruno Haible's
Clisp? Or do people want native compilation?
- Reggie
- ------------------
Reginald S. Perry e-mail: perry(a)zso.dec.com
Digital Equipment Corporation
Performance Manager Group
http://www.UNIX.digital.com/unix/sysman/perf_mgr/
The train to Success makes many stops in the state of Failure.
------------------------------
Date: Sun, 08 Feb 1998 02:28:57 -0800
From: "Reginald S. Perry" <perry(a)zso.dec.com>
To: Hrvoje Niksic <hniksic(a)srce.hr>
Cc: perry(a)rust.unknown (Reginald S. Perry), Steven Baur <steve(a)xemacs.org>
Subject: Re: perlemacs technical discussion
Message-Id: <9802081029.AA10961(a)yakko.zso.dec.com>
Content-Type: text/plain; charset=US-ASCII
>"Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
> The people generally desire native compilation, but I don't think it
> is paramount. I haven't been aware of Clisp. Can you provide more
> info?
Sure. First the Lisp FAQ also has info so I will aproach this answer
purely from my point of view.
Clisp is a GPLed implementation of Common Lisp. Its flavor is that it
has a CLTL1(Commom Lisp, the Language Vol. 1) feel but they have
implemented a large portion of the passed votes in CLTL2 so they are
sort of ANSI. There are a couple of cool things about Clisp. First its
executable size and memory footprint is suprisingly small for a
full-blown lisp implementation. Here are some stats from my Alpha box
running DU 4.0B
yakko> ps l -p 24127 -m
UID PID PPID CP PRI NI VSZ RSS WCHAN S TTY TIME COMMAND
9158 24127 11723 0 42 0 4.65M 888K tty I + ttyq 00:00.05 /usr/local/lib/lisp/lisp.run -M /u
yakko> ls -l /usr/local/lib/lisp
total 3112
- rwxr-xr-x 1 root system 1785856 Jan 6 12:06 lisp.run*
- rw-r--r-- 1 root system 1399572 Jan 6 12:06 lispinit.mem
In addition, He has gone through lots of trouble to tune the
implementation. It has generational garbage collection and hand tuned
assembly code for x86 and a couple of other implementations. It also
has short-float and long-float in which the long float has a variable
mantissa length, which is a multiple of 16 (or 32, depending on the
word size of the processor). These combinations mean that although the
system uses byte compilation, some operations end up being suprisingly
fast. The system runs on a lot of different machines/OSes including
NT, OS/2, and Amigia. It would seem like a nice base from which to
start although I am by no means a lisp of XEmacs expert. You might
want to talk to Bruno (Bruno Haible [haible(a)ilog.fr]) I bet he would
have some good suggestions.
So while I agree that native compilation is the best, Clisp may be a
good portable solution for people who dont have access to Unix to run
CMUCL, Linux to run Allegro CL, dont have the cash to get Commom Lisp
on Windows or want to use a CL based XEmacs but is running on OS/2 or
some other system that commercial lisp vendors wont port their wares
to.
Anyway, I will attach this message Bruno sent to the mailing list
pointing to the new location for the sources and binaries.
- Reggie
Hello all,
The home location of CLISP moves. This means:
* The mailing list was <clisp-list(a)ma2s2.mathematik.uni-karlsruhe.de>
and is now <clisp-list(a)clisp.cons.org>.
The address for administrative requests (subscribe, unsubscribe)
for clisp-list was <listserv(a)ma2s2.mathematik.uni-karlsruhe.de>
and is now <listproc(a)clisp.cons.org>.
* The FTP server was ftp://ma2s2.mathematik.uni-karlsruhe.de/pub/lisp/clisp/
and is now ftp://ftp2.cons.org/pub/lisp/clisp/.
Old versions of CLISP and binaries older than June 1995 (for 386bsd,
acorn, atari, coherent386, sco, sequent-ptx, sgi-irix4, sgi-irix5,
sun3-sunos4, sun386, sun4-sunos51, sun4-sunos52, sun4-sunos53, unixware)
are only available from http://clisp.cons.org/~haible/clisp-archive/.
* There is now a home page at http://clisp.cons.org/~haible/clisp.html.
Please update your URLs.
All of you who were subscribed to the old clisp-list on December 9, 1997,
are now subscribed to the new clisp-list. You'll find below the message
which you would have gotten if you had subscribed to the new clisp-list
manually. Please read it, and save it for the day when you want to
unsubscribe.
Many thanks to Martin Cracauer who owns clisp.cons.org and to Walnut Creek
CDROM who owns ftp2.cons.org.
Bruno Haible
<haible(a)clisp.cons.org>
=========================== welcome message =============================
You have been added to list clisp-list(a)clisp.cons.org.
The system has recorded your address as
...................
and in order for your messages to get posted (if the list accepts postings),
you will have to send them from this address.
If a message is ever rejected, please contact the list's owner: haible(a)ilog.fr
For information on this service and how to use it, send the following
request in the body of a mail message to listproc(a)clisp.cons.org:
HELP
All requests should be addressed to listproc(a)clisp.cons.org.
clisp-list(a)clisp.cons.org
This mailing list is for users of the CLISP implementation of Common Lisp
by Bruno Haible and Michael Stoll. It is the proper forum for questions
about CLISP and also bug reports, compatibility issues, problems of CLISP
on specific platforms, enhancement of CLISP, miscellaneous comments, etc.
The clisp-list is managed internally by the Boston University "listproc"
program. To be added or removed from the clisp-list or to retrieve past
articles posted to the clisp-list please send mail to:
listproc(a)clisp.cons.org
If you include the word "help" as the message body, "listproc" will return
a list of valid commands and options.
To have messages forwarded to everyone else on the clisp mailing list
send them to:
clisp-list(a)clisp.cons.org
To retrieve the past articles posted to the clisp list, send mail to
listproc(a)clisp.cons.org
including the three words "get clisp-list mailing-list-archive" as message
body.
To unsubscribe from the clisp mailing list, send mail to
listproc(a)clisp.cons.org
including the two words "unsubscribe clisp-list" as message body.
Please save this message for the day you want to unsubscribe.
About CLISP:
CLISP is a Common Lisp implementation by Bruno Haible of Karlsruhe
University and Michael Stoll of Munich University, both in Germany.
It mostly supports the Lisp described in "Common LISP: The Language
(2nd edition)" and the ANSI Common Lisp standard. It runs on
microcomputers (DOS, OS/2, Windows NT, Windows 95, Amiga 500-4000,
Acorn RISC PC) as well as on Unix workstations (Linux, SVR4, Sun4,
DEC Alpha OSF, HP-UX, NeXTstep, SGI, AIX, Sun3 and others) and needs
only 2 MB of RAM. It is free software and may be distributed under the
terms of GNU GPL. The user interface comes in German, English, French
and Spanish. CLISP includes an interpreter, a compiler, a large subset
of CLOS, a foreign language interface and a socket interface. An X11
interface is available through CLX and Garnet.
Available by anonymous ftp from ftp2.cons.org in the directory
/pub/lisp/clisp.
For more information, look at http://clisp.cons.org/~haible/clisp.html.
------------------------------
Date: Mon, 9 Feb 1998 15:14:04 +0100 (MET)
From: Bruno Haible <haible(a)ilog.fr>
To: Hrvoje Niksic <hniksic(a)srce.hr>
Subject: clisp, xemacs
Message-Id: <199802091414.PAA08897(a)halles.ilog.fr>
Hello,
Reginald Perry told me that he had suggested using CLISP inside XEmacs,
for replacing the existing bytecode engine, I assume.
Some technical points:
* CLISP is pretty close to the ANSI Common Lisp standard (except for
some exotic features which would have a noticeable efficiency penalty).
* CLISP comes with its own bytecode compiler and bytecode interpreter
engine. As with Emacs Lisp, interpreted functions are debuggable,
and bytecode is not (because all source has been thrown away).
* CLISP is very portable. Ports include Amiga, OS/2, and Win32. No such
unportable things like `unexec'.
* CLISP is very robust. All functions perform strict argument type checking.
It's very difficult to make it crash, except by extending it with
buggy C code.
* CLISP has been in use continuously by about 1000 people since 1993,
200 of them on the mailing list. This has shaked out even the smallest
bugs.
* CLISP has a very efficient memory management and garbage collector:
- The GC is compacting. Nowadays, after an uptime of a week, XEmacs'
memory size grows to 40 MB. This would go away.
- The full GC of a 1 MB world takes 0.1 seconds on a Sparc 10, much less
than XEmacs' GC. Moreover, most GCs collect only the youngest
generation of objects are thus even faster.
- The implementation of this uses all all kinds of mmap and mprotect
trickery.
* I have started implementing multithreading into CLISP (a real one, based
on kernel threads in the case of Linux and Solaris).
* A little drawback: Dealing with Lisp objects in C code is not easy
because they must be stored on the Lisp object stack during function
calls, to protect against GC. (See file doc/extend.txt in the CLISP
distribution.)
* Integration: CLISP has once been integrated with a computer algebra
system for number theory. The sources are not yet well prepared for
this task, though.
Please don't hesitate to ask me questions. I would very much like CLISP
to be useful in this way.
Greetings,
Bruno Haible
<haible(a)clisp.cons.org>
http://clisp.cons.org/~haible/clisp.html
------------------------------
Date: Tue, 10 Feb 1998 20:35:47 +0100 (MET)
From: Bruno Haible <haible(a)ilog.fr>
To: Hrvoje Niksic <hniksic(a)srce.hr>
Cc: Steven Baur <steve(a)xemacs.org>
Subject: Re: clisp, xemacs
Message-Id: <199802101935.UAA27926(a)halles.ilog.fr>
References: <199802091414.PAA08897(a)halles.ilog.fr>
<kigafbz7mfk.fsf(a)jagor.srce.hr>
Hello Hrvoje,
> What we need is a small variant of Common Lisp where we can exclude
> the junk that we don't need. Which is where Clisp comes into the
> picture -- and I must admit I like it.
Things like CLOS, LOOP, conditions, generic streams, sockets and FFI can
be easily removed from clisp, but I think these are really added values
(especially CLOS and conditions) which distinguish Common Lisp from other,
less object-oriented, Lisps.
CLISP is not yet prepared for omitting other stuff, but you just need
to tell me what you want not to have, and I can add configuration options
for them.
> OK, that's understandable. I'd like to read more about the bytecode
> implementation. Is it documented anywhere?
There is some documentation in German in the first 10% of compiler.lsp.
Otherwise the list of instructions is in bytecode.d, and the actual
bytecode interpreter is at the end of eval.d.
Basically, it's a stack machine, with multiple values in the Top Of Stack
(as required by CL). There are special bytecodes for special language
features (unwind-protect and handler-bind, for example). The set of
bytecodes has been optimized so that compiled programs take as few
space as possible.
The bytecode is platform-independent.
> Do you plan to build a native or ToC compiler in the future? It is
> not paramount, but would be a nice thing to have,
I agree that it would be nice; I have thought about a JIT-compiler
which would transform the bytecode into machine code, but it does not
yet exist.
> > * CLISP is very portable. Ports include Amiga, OS/2, and Win32. No
> > such unportable things like `unexec'.
>
> A definite plus. We are looking at replacing the `unexec'-based
> dumper with a portable one. I can elaborate on this, if you are
> interested.
I cannot imagine a portable dumper: The only portable interface for
creating executables is the system's linker. CLISP puts its data
into mmap'ed memory images (sort of self-made shared libraries).
> Also, mark-sweep GC has very bad performance with virtual memory,
> because it has to traverse all of the memory, thus paging it off swap,
> which makes for additional GC slowness. I would assume that
> generational GC (which tries to collect the most used objects first)
> fixes this?
Generational GC by itself does not consider the issue of virtual memory,
but in CLISP's generational GC I take special measures so that GC has not
to touch memory pages (every page has a small "todo" cache associated with
it, and this cache is emptied only when the page is known to be in-core).
> > * A little drawback: Dealing with Lisp objects in C code is not easy
> > because they must be stored on the Lisp object stack during
> > function calls, to protect against GC. (See file doc/extend.txt in
> > the CLISP distribution.)
>
> This sounds like a big minus. It is of crucial importance that the C
> code can access Lisp. Much of XEmacs is implemented in C, and we
> don't want to lose all of that code.
I think it'd be easy to implement the gc_protect() function currently
used by the Emacs C sources with CLISP too:
object xx;
gc_protect(xx);
... lots of code...
gc_unprotect(xx);
return;
It'd be nice if we could make up a "wish list" of things which have to
be modified in CLISP in order to help integration into XEmacs.
- gc_protect
- main program not called main()
- better documentation on what issues?
- autoloading as a primitive?
- which parts to remove?
- adding efficient low-level data types for text
- ...
Greetings
Bruno
------------------------------
Date: Tue, 10 Feb 1998 22:13:48 +0100 (MET)
From: Bruno Haible <haible(a)ilog.fr>
To: Hrvoje Niksic <hniksic(a)srce.hr>
Cc: Steven Baur <steve(a)xemacs.org>
Subject: Re: clisp, xemacs
Message-Id: <199802102113.WAA22576(a)halles.ilog.fr>
References: <199802091414.PAA08897(a)halles.ilog.fr>
<kigafbz7mfk.fsf(a)jagor.srce.hr>
<199802101935.UAA27926(a)halles.ilog.fr>
<kigd8gv2ore.fsf(a)jagor.srce.hr>
> larger Common Lisps tend to run 15M or so memory images,
> and one definitely starts to ponder removing unnecessary things.
> Clisp is much smaller
The difference in size comes definitely from compiling to bytecode, not
machine code.
> for 99% of other folks, it would be a disgrace to have to download
> (and godforbid compile!) something like CMUCL.
Only 5 people on the world know how to compile CMUCL :-)
> If the Lisp engine rewrite ever takes place, we would probably make a
> `clisp/' directory in the XEmacs sources, so that people can build
> them together.
That's fine with me.
> This sounds a lot like Emacs bytecode. One big trouble with Emacs is
> that function calls are extremely slow, which makes recursive
> algorithms drag. Also, things like `mapcar' are very slow in elisp.
> All of this results in very lispy and elegant programs being hogs in
> Emacs.
>
> How did you solve these problems under Clisp? Under Emacs, the
> funcalls are slow because they have to be safe.
Funcalls (from bytecode to bytecode) costs 3 C function calls:
interpret_bytecode_ -> funcall -> funcall_closure -> interpret_bytecode_
I've never had the impression that clisp's function calls were particularly
slow.
For example, the last time I did Gabriel's benchmarks, on a PC Pentium
133 Mhz, Linux 1.2.13, the results were:
DIV2iter 0.33
DIV2recur 0.43
(mapcar #'some-predefined-function ...) has an overhead of 1 call to
`mapcar'. (mapcar (lambda ...) ...) is optimized by inlining the lambda
(and by special bytecode instructions which occur frequently in this
context).
CLISP's weakness vs. machine-code compiling Lisps are structure accesses.
A function call to a built-in function (with 3 arguments) in clisp,
but only a single machine instruction in machine code. That's the price
of full runtime type safety.
> > I cannot imagine a portable dumper: The only portable interface for
> > creating executables is the system's linker.
>
> You got it. :-) Seriously, this is exactly what the new dumper
> does/will do. `temacs' starts up, loads all the necessary Lisp files,
> and produces several more `.c' files with all the necessary
> declarations. These `.c' files are then compiled and linked into a
> new `xemacs' executable.
Great! Finally... (Note that this wouldn't be a solution for clisp,
because normal users on machines without a linker [naked Solaris]
may want to save memory images in clisp. For XEmacs this is acceptable,
because the saving occurs only as part of the build process.)
> For instance, one should be able to create new opaque Lisp types from C.
> Look at the use of DEFINE_LRECORD_IMPLEMENTATION and
> DEFINE_BASIC_LRECORD_IMPLEMENTATION in XEmacs sources. Then we would
> reuse the existing C support for buffers, windows, extents, etc.
I'll add similar capabilities to clisp. They are not present yet.
Greetings,
Bruno
------------------------------
End of forwardcTBCoX Digest
***************************
------- End of forwarded message -------
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
26 years, 4 months
Holger Schauer
Holger Schauer
>>>>"SJT" == Stephen J Turnbull schrieb am Thu, 2 Jul 1998 15:45:35 +0900 (JST):
ms> Many features aren't part of the Scheme standard because they can
ms> be easily expressed within the language as it stands. True
ms> concepts are more important, and here CL is weak. I could go on
ms> about the virtues of hygienic macros, the evils of CL-style
ms> macros, especially in connection with module systems, the
ms> usefulness and beauty of call-with-current-continuation
ms> etc. etc. etc. Someone make me.
(Finger raised)
I do. Especially about the module system. As far as I know, Scheme
(even in RSR5) has no standarized module system (the package-system is
a familiar thing for CL-programmers. AFAIK, standarized Scheme offers
no such thing).
What about OO ? I always wanted to start using CLOS (the Common Lisp
Object System), but haven't had the urgent need to. But obviously,
many current Elisp applications could probably benefit from _any_ OO
Lisp extension.
SJT> Re: global options and keyword arguments
ms> However, Scheme idiomatics usually uses a parameterization
ms> mechanism to achieve what you're talking about; they're similar
ms> to a structured and thread-compatible version of dynamic binding.
SJT> Urk. I mean, URL please. :-)
Yes, I want to second that. In which way are "dynamic binding" and
keyword arguments connected ? And is there a *standarized* way for
keyword arguments in RSR[45] ?
What I am after: this whole discussion about the benefits of Scheme
and Common Lisp has been lead a thousands time. Why should we
re-discuss very old arguments ?
And, where is the _urgent_ need for replacing Emacs Lisp with either
Scheme or Common Lisp that makes worth the work ? Sure, I would like
to have a _real_ Common Lisp as the Lisp to program Emacs in (and
that's why I have an eye on Erik Naggum's CL-Emacs project), but I am
certainly not convinced that _replacing_ the current engine with
anything else really offers any big gains. Say, we would replace the
current engine with some (modified) foo-scheme implementation, like
say guile, or the gtk-engine. Fine, now we can have some guys that
already use that foo-Scheme implement some new bar-functionality. But
what is the benefit for the current existing system ? And is it really
true that replacing Emacs Lisp with another Lisp will encourage new
users ? I doubt it, because, well, hey, here we have another lisp
engine, that mainly consists of "Emacs Lisp" (note the quotes),
because the _essential_ things for programming Emacs is _not_ the lisp
language underneath but the functionality, and this is the real part
which makes Emacs Lisp _Emacs_ Lisp (be it that the Lisp language is
Elisp, Scheme, CL ...).
And, I'm sorry to say that, but I always thought that the major
difference between Emacs Lisp and both Scheme and Common Lisp is how
binding works and that this is not a trival problem (i.e. translating
Emacs Lisp binding to CL binding). But it's been a while since I
looked inside that topic. If this is not a problem for some
translator, please correct me and tell me why/how.
ms> (Note that the reverse is not generally possible, since Common
ms> Lisp is not properly tail-recursive and does not support control
ms> abstraction.)
AFAIK, tail-recursion is not required by the (ANSI) CL standard. Is it
part of RSR(45) ? This would be very surprising news to me.
SJT> But _we_ only care if those features would be useful to XEmacs
SJT> running Scheme idioms emulated inside a Common Lisp substrate.
SJT> No?
I second that. Where is the beef ?
SJT> Point is that a lot of the people who should contribute to this
SJT> discussion don't even know where to start asking questions. I
SJT> assume I'm not the only person totally ignorant of modern
SJT> programming language theory on this list. Is that assumption
SJT> unjustified?
Nope, as far as I am concerned this assumption pretty much applies to
me.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer ---
Why people hate using Lisp:
"Are people suffering from parenthophobia-by-proxy, mistaking
`parens' for `parents'?" - Erik Naggum in comp.emacs.xemacs
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
26 years, 4 months
Michael Sperber
Michael Sperber
>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes:
Andy> At 09:22 AM 7/2/98 +0200, Michael Sperber [Mr. Preprocessor] wrote:
>> ILU does this, indeed. However, CORBA and related IDL's are pretty
>> heavyweight currently. The sensible approach is to a have a
>> low-level FFI and build RPC support on top of it.
Andy> Would you even want IDL? I would have thought that DII would be simple
Andy> enough from elisp/scheme/clisp.
I'm not sure what your semantics are for the TLA's. "IDL" means
"Interface Definition Language" and is the generic term for languages
that describe RPC interfaces. ILU has its own IDL, so does CORBA, so
does Sun RPC. The terminology is confusing because "IDL" is often
used to specifically denote CORBA's IDL.
What's DII?
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 2 participants
- 1 comments
Re: Where do you want to go tomorrow?
26 years, 4 months
Hrvoje Niksic
Hrvoje Niksic
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
> >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
>
> Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
>
> Hrvoje> Lots of elisp code can run under Common Lisp almost
> Hrvoje> unchanged. This is not true for Scheme.
> >>
> >> Please substantiate this. By default, for instance, `let' is
> >> lexically scoped in Common Lisp, which is clearly incompatible with
> >> Emacs Lisp.
>
> Hrvoje> Not so by design. In fact, we were discussing introduction of a
> Hrvoje> lexically scoped `let' to elisp many times. And guess what? The
> Hrvoje> proposed semantics were equivalent to those used by CL -- lexical
> Hrvoje> scope by default, dynamic scope for special variables.
>
> Great. While I don't remember the proposed semantics, and don't
> necessarily agree with this, this is just as easy to implement in
> Scheme.
Have I ever denied it for this particular example? You brought up the
`let' issue.
> Hrvoje> I don't care. Emacs is not ANSI CL. If that was the
> Hrvoje> impression I was giving, I apologize, because that is not
> Hrvoje> what I meant.
>
> One important benefit in swapping the extension language would be
> that we could use library code not specifically written for XEmacs.
> There's lots and lots of library code for both Scheme and Common
> Lisp. Stripping down the language would mean we couldn't use much
> of it.
It depends on how you do the stripping.
> If we're going to hook to a Lisp engine maintained by someone else
> (which we hopefully will), there's no reason to take only a part of
> it.
Well, there are reasons such as size, speed, efficiency etc.
> Hrvoje> The Scheme users and implementors don't have the constraint
> Hrvoje> of previous implementation of Common Lisp idioms. We do,
> Hrvoje> and I would like us to preserve them.
>
> Sure. Let's.
If we choose Scheme, I don't see the point.
> Hrvoje> I don't like CMU CL (far too slow and buggy IMHO),
>
> Actually, CMU CL produces pretty much the fastest CL code around.
> Unfortuntately, it only works on very few architectures.
Exactly. And it's almost impossible to compile. And it's fucking
huge. Etc. Clisp doesn't have a native compiler, but it would
probably serve our purposes much better.
> Hrvoje> and I haven't worked with GCL much. It might be usable.
>
> Now *that*'s what I would call slow and buggy. (...)
OK, I take that back.
P.S.
I'll forward my exchange with Bruno to the list.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Lost in Static 18 / And the storm is closing in now
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
26 years, 4 months
Jareth Hein
Jareth Hein
As an aside, I've never touched CL and know nothing about it save
what little I've gleaned while working on XEmacs. For that matter,
elisp was my first introduction to lisp, although I now occasionally
do some work with scheme48 and use scsh quite a bit. So I'm biased in
that that's all I know, and having implanted Scheme into a program,
have a little experience with that.
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> >>>>> "ms" == Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes:
>
> Ah, and I do agree with your assessment that CL's goal of
> compatibility with various historically important Lisps is
> inappropriate for XEmacs's substrate. I don't really see the need for
> so many different ways of expressing a conditional, for example, and
> they always leave me with the sneaking suspicion that
>
> (cond ((this that)))
>
> (if this that)
>
> and
>
> (when this that)
>
> have different semantics, but I'm not sure what it is.... This is a
> great way to create a write-only language, IMHO.
When I first started elisp programming (and occasionally now, for that
matter) I saw all these differing ways of accomplising the same result
and just about quit because I couldn't resolve which was better to use
any any situation. As far as performance, readability, and style,
elisp seems to be a crap shoot, and I'd really like to slim that down.
Encouraging potential new contributors into overcoming 'lisp-anxiety'
is also a big plus. As there seems to be more than a little FUD
surrounding CL and the ammount of historical baggage it brings (and
the supposedly steep learning curve), I think abolishing this FUD
should be a first step for CL proponents.
> >From that page:
>
> ms> Many features aren't part of the Scheme standard because they
> ms> can be easily expressed within the language as it stands. True
> ms> concepts are more important, and here CL is weak. I could go
> ms> on about the virtues of hygienic macros, the evils of CL-style
> ms> macros, especially in connection with module systems, the
> ms> usefulness and beauty of call-with-current-continuation
> ms> etc. etc. etc. Someone make me.
>
> OK. *twist, twist, twist*
I'll fetch the hot coals... ;-)
> However, URLs where I can find out WTF the vocabulary means ahead of
> time would be vewy hehpfuh.[1] I've been to Indiana's Scheme
> Repository; I don't know where to start.
>
[snip]
>
> Point is that a lot of the people who should contribute to this
> discussion don't even know where to start asking questions. I assume
> I'm not the only person totally ignorant of modern programming
> language theory on this list. Is that assumption unjustified?
I too am at sea when it comes to theory (sad outcome of being a
self-taught programmer). I can use scheme, and I can use elisp, and
for that matter I can most probably use CL, but I am in no position to
judge which should be the next substrate for XEmacs. However, having
embedded scheme once, I would definatly be of more help in doing
somthing similar again. I'm not adverse to learning new things (it's
my personal opinion that when a person stops wanting to learn in this
trade, it's time for them to get out), so teach me!
> Footnotes:
> [1] See? I have been doing my homework. At least I know that "We're
> hunting RABBIT." Or a modern version thereof. [ObRef Bugs Bunny/Elmer
> Fudd.]
Not only am I not on language theory, but I missed THAT too... (and I
own almost every released bit of Warner animation... sniff... ;-])
--
Jareth Hein | jareth(a)camelot.co.jp | ハイン ジェラス
Toolsmith & Program lead | http://www.camelot.co.jp | 開発部チーフ
Camelot Software, Ltd. | |（株）キャメロット
"It's a sad sign of the times when 'political machine' is redefined to
include 'main-line battle tank'" - Ambassador Grossblunder
- 1 participants
- 0 comments