|
Prev: You want abbreviations? You can't handle abbreviations!
Next: Hot Shop Audemars Piguet Royal Oak Watches - Audemars Piguet Minimum Price
From: Didier Verna on 7 May 2008 12:02 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 7 May 2008 12:29 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 7 May 2008 14:35 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 7 May 2008 14:57
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/ |