Path: utzoo!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!think.com!linus!linus!mir!dsr
From: dsr@mir.mitre.org (Douglas S. Rand)
Newsgroups: comp.lang.c++
Subject: Re: Implementing LISP in C++ (type discrimination)
Message-ID: <1991Mar13.145107.19724@linus.mitre.org>
Date: 13 Mar 91 14:51:07 GMT
References: <1991Mar8.024331.14235@searchtech.com> <27D7F621.2F5@tct.uucp> <17238@cadillac.CAD.MCC.COM> <1991Mar12.221015.22144@aero.org>
Sender: news@linus.mitre.org (News Service)
Reply-To: dsr@mir.mitre.org (Douglas S. Rand)
Organization: The MITRE Corporation
Lines: 57
Nntp-Posting-Host: mir.mitre.org

In article <1991Mar12.221015.22144@aero.org>, jordan@aero.org (Larry M. Jordan) writes:
> I'm endeavoring to implement an interpreter/compiler for a LISP-like language
> in C++.  The question I wish to have answered is "Can I implement a
> type-less lang. like LISP in C++ without resorting at some point to
> actually asking an object for its type?" I just don't see how not to.
> Also, I'm implementing a simple mark/sweep garbage collector which takes 
> liberties with Cons cell pointers to avoid recursion.  I don't see a 
> reasonable way to do this without asking objects during the mark phase
> 'are you a Cons?'. (Of course, I will need to implement the predicate 
> functions like 'null, consp, listp, etc.').   I'd also like some
> remarks on the 'reasonableness' of the implementation scheme I've 
> chosen (to be described next paragraph).
> 

Well to start with,  why not have a virtual function like GCmarkPhase
which does something with conses or their decendents but not with other
LISP objects?

> Techniques I've seen in the past for implementing LISP objects in
> languages like C or Modula-2 define an enumeration type and create
> a discriminated union using the enum as a type 'tag' or discriminant.
> XLISP and XSCHEME are implemented this way and it seems perfectly
> reasonable.  I've taken a different approach since I'm using C++.

It is if the language doesn't do this for you with virtuals.

> ... some text deleted ...
> Consequently, there are a large number of virtual methods in the base
> class Node--20+ and growing.  At first I thought there would be a lot
> of space dedicated to large vft's--sizeof(char*) * 
> NumberOfVirtualMethodsInBase for each LISP object
> derived from Node!  I was concerned about using vast amounts of memory
> for vft's.  But then I considered what the alternative would be--

Why, do you think each instance would have a copy of the vtab?  The
vtab is equivalent to a class variable.  There is one copy per class.

> using code space to check the type of the object I'm about to 
> reference as a 'Cons' object (which would be an operation that
> would widely distributed throughout the system) rather that just 
> envoke the method.  I get the error checking at the expense of a

And the type check via the virtual function call is much faster and
more foolproof.

> calling a virtual method.  I'm convinced that this experiment is 
> worthwhile to continue.
> 

Have fun.

-- 
Douglas S. Rand 
Internet:   <dsrand@mitre.org>
Snail:	    MITRE, Burlington Road, Bedford, MA 
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ