Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!swiss.ans.net!news.dfn.de!Germany.EU.net!EU.net!uknet!festival!edcogsci!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Subject: Re: newbie questions answered
Message-ID: <Cx410M.6I0@cogsci.ed.ac.uk>
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: bute.aiai.ed.ac.uk
Organization: AIAI, University of Edinburgh, Scotland
References: <36hsec$7es@mojo.eng.umd.edu>
Date: Mon, 3 Oct 1994 18:36:22 GMT
Lines: 28

In article <36hsec$7es@mojo.eng.umd.edu> mheinick@eng.umd.edu (Mark Heinicke) writes:
>
>Thanks to the many who answered my questions with FAQ pages and
>suggestions.  One thing I've noticed: most of the interpreters
>seem to be written in C.  Makes me wonder if I should just stick
>to C (or learn C++) and write my own functions.  Would save me
>learning Lisp, but I guess I'd have to write a hell of a lot
>more code.

Perhaps you should look at some Lisps that can be linked into C
programs.  Elk and libscheme, for instance.  There are problems
with just writing your own functions in C.  For instance, there's
no source notation for symbols.  You can call a lookup procedure
(e.g. symbol("abc"), but that repeats the lookup cost for every
reference.  Another example: no closures.

That Lisps are written in C suggests that there are solutions
to these programs, but the code must be written in a somewhat
awkward and limited way.  A Lisp interpreter written in C
might have a table of all the symbols it needs, and if you
took that approach you'd have to extend the table every time
you wrote a function that referred to a new symbol.

(The table would typically be an array of pointers to symbol
structs and the indexes might be ints.  You'd #define indexes
that were more meaningful, or maybe use an enumeration.)

-- jeff
