From: Didier Verna on
pjb(a)informatimago.com (Pascal J. Bourguignon) wrote:

> However, there are also object systems written for C.
>
> Objective-C is an obvious one.
>
> COS another with some influences from Objective-C and some from CLOS:
> http://sourceforge.net/projects/cos

Didn't know about that. Puzzling.

We digress, but I remember reading a book from a guy claiming that he
didn't have to use C++ because he could do OO in C, and the book was
about proving that by constructing a set of CPP macros to implement the
object layer. That reading was... well...

I wish I remembered the name.

--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/

Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 didier(a)xemacs.org
From: Rainer Joswig on
In article <mux7ie6yufb.fsf(a)uzeb.lrde.epita.fr>,
Didier Verna <didier(a)lrde.epita.fr> wrote:

> pjb(a)informatimago.com (Pascal J. Bourguignon) wrote:
>
> > However, there are also object systems written for C.
> >
> > Objective-C is an obvious one.
> >
> > COS another with some influences from Objective-C and some from CLOS:
> > http://sourceforge.net/projects/cos
>
> Didn't know about that. Puzzling.

Dynace
http://algorithms.us/software/dynace/intro.html
"Dynace is a preprocessor, include files and a library which
extends the C and C++ languages with advanced object
oriented capabilities, automatic garbage collection
and multiple threads. Dynace is designed to solve
many of the problems associated with C++ while being
easier to learn and containing more flexable
object oriented facilities. Dynace is able to add
facilities previously only available in languages
such as Smalltalk and CLOS without all the overhead
normally associated with those environments."


>
> We digress, but I remember reading a book from a guy claiming that he
> didn't have to use C++ because he could do OO in C, and the book was
> about proving that by constructing a set of CPP macros to implement the
> object layer. That reading was... well...
>
> I wish I remembered the name.

--
http://lispm.dyndns.org/
From: viper-2 on
On May 6, 3:00 pm, Rainer Joswig <jos...(a)lisp.de> wrote:
> In article
> <7a360a2d-c283-41d4-a4f5-40c176fb4...(a)a70g2000hsh.googlegroups.com>,
>
> viper-2 <visio...(a)mail.infochan.com> wrote:
> > On May 6, 12:14 pm, Didier Verna <did...(a)xemacs.org> wrote:
> > > viper-2 <visio...(a)mail.infochan.com> wrote:
> > > > On May 6, 3:57 am, Didier Verna <did...(a)xemacs.org> wrote:
>
> > > You have got to be kidding me. I don't see how being dynamically
> > > scoped by default helps you in any way (even in a self-blah-blah editor
> > > in which user options could simply be defined in terms of CL's
> > > defparameter). I don't see how not having lexical scope helps you in any
> > > way either.
>
> > Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
> > no CLOS.
>
> Well, RMS worked on the Lisp Machine. He even wrote manuals for it.
> He wrote for example the Zmail manual
> and co-wrote the Window System Manual. He knew the system very well.
> Including Flavors, the object system. He himself wrote an
> object-system before there was Flavors. Lisp Machine Lisp was
> dynamically scoped with some support for closures.
> There was more experience with dynamically scoped Lisps at that time.
>
> > The reasons for the use of dynamic scoping have to do with
> > the design decisions RMS made at the time he decided to rewrite his
> > TECO based EMACS. I believe (but I could be wrong here) that at the
> > time, Steele's and Sussman's Scheme project performed poorly with
> > lexical scoping. Dynamic scoping was thought to be more efficient; see
> >http://www.gnu.org/software/emacs/emacs-paper.html#SEC17.
>
> Well, the language Elisp could have been changed - if lexical scope
> or an object system had been important to the language users.

It seems that I got the chronology wrong. RMS wrote EMACS Lisp after
he had already implemented Common Lisp for the Lisp Machine. His
design was constrained by physical limitations of that time. He just
emailed to say this:


| I designed Emacs Lisp in 1984. I had already
| implemented Common Lisp for the MIT Lisp
| Machine and I did not like it much. Also, it was
| too big. In 1984 I had to simplify Emacs Lisp
| very much to make GNU Emacs fit in the
| memory spaces that were available. That is
| why the only looping construct was `while', and
| the only list mapping function was `mapcar'.


agt


From: Rainer Joswig on
In article
<c10670d0-6e9a-4093-b86b-e4487aec23b9(a)b1g2000hsg.googlegroups.com>,
viper-2 <visionat(a)mail.infochan.com> wrote:

> On May 6, 3:00 pm, Rainer Joswig <jos...(a)lisp.de> wrote:
> > In article
> > <7a360a2d-c283-41d4-a4f5-40c176fb4...(a)a70g2000hsh.googlegroups.com>,
> >
> > viper-2 <visio...(a)mail.infochan.com> wrote:
> > > On May 6, 12:14 pm, Didier Verna <did...(a)xemacs.org> wrote:
> > > > viper-2 <visio...(a)mail.infochan.com> wrote:
> > > > > On May 6, 3:57 am, Didier Verna <did...(a)xemacs.org> wrote:
> >
> > > > You have got to be kidding me. I don't see how being dynamically
> > > > scoped by default helps you in any way (even in a self-blah-blah editor
> > > > in which user options could simply be defined in terms of CL's
> > > > defparameter). I don't see how not having lexical scope helps you in any
> > > > way either.
> >
> > > Remember that Elisp (a variant of MacLisp) preceded Common Lisp, hence
> > > no CLOS.
> >
> > Well, RMS worked on the Lisp Machine. He even wrote manuals for it.
> > He wrote for example the Zmail manual
> > and co-wrote the Window System Manual. He knew the system very well.
> > Including Flavors, the object system. He himself wrote an
> > object-system before there was Flavors. Lisp Machine Lisp was
> > dynamically scoped with some support for closures.
> > There was more experience with dynamically scoped Lisps at that time.
> >
> > > The reasons for the use of dynamic scoping have to do with
> > > the design decisions RMS made at the time he decided to rewrite his
> > > TECO based EMACS. I believe (but I could be wrong here) that at the
> > > time, Steele's and Sussman's Scheme project performed poorly with
> > > lexical scoping. Dynamic scoping was thought to be more efficient; see
> > >http://www.gnu.org/software/emacs/emacs-paper.html#SEC17.
> >
> > Well, the language Elisp could have been changed - if lexical scope
> > or an object system had been important to the language users.
>
> It seems that I got the chronology wrong. RMS wrote EMACS Lisp after
> he had already implemented Common Lisp for the Lisp Machine. His
> design was constrained by physical limitations of that time. He just
> emailed to say this:
>
>
> | I designed Emacs Lisp in 1984. I had already
> | implemented Common Lisp for the MIT Lisp
> | Machine and I did not like it much. Also, it was
> | too big. In 1984 I had to simplify Emacs Lisp
> | very much to make GNU Emacs fit in the
> | memory spaces that were available. That is
> | why the only looping construct was `while', and
> | the only list mapping function was `mapcar'.
>
>
> agt

Memory WAS tiny then. The Mac of 1984 had 128kbyte RAM.
The Apple Lisa from 1983 had 1 MB RAM.

'Macintosh Allegro CL' by Coral from 1987 wanted a Mac with 1 MB RAM!
HUGE UGLY BLOATED COMMON LISP!!!

Then the bloat got out of control! Imagine, MCL 2.0 demanded a Mac
with a minimum of 4MB RAM and 6 MB disk!!!

;-)

--
http://lispm.dyndns.org/