🚀 go-pugleaf

In article <8440@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes:

>[lots of good clarifications of stuff I was fuzzy on]

Thanks!  I'm going to merge your comments into internals.doc
(with a global acknowledgement) if you don't object...

>[good examples of lexical binding of fns vs variables]
>You couldn't do this with a combined binding list.

Um.  Clearly, the lexical binding mechanism needs to distiguish
between binding of functions and variables.  Maybe I'm a little slow,
but it is still not obvious to me that you need separate xlenv and
xlfenv base pointers.  For example, I don't see simultaneous pushing
of one stack and popping of the other.

>>Vectors, chars, integers and so forth
>>stand outside the object hierarchy -- you can't send messages to them.
>>I'm not sure why Dave did it this way.

>Probably because the object facility is an extension of lisp. You can
>create classes of these things. There is also efficiency considerations.
>The only object oriented programming language I know of where everything
>is an object is Smalltalk, but if you look at the implementation, it does
>cheat at the low level to speed things up.

Doing CAR and CDR via messages (say), would clearly have a big
efficiency impact (barring very smart compilation).  But defining a
CLASS string and supporting messages to strings (say), doesn't present
any serious (to me) efficiency issues.  It means that xlobj.c:xsend(),
instead of using xlgaobject(), needs to check for n_type != OBJECT,
and if so, get the apppropriate class object by using n_type to index
into a C array.  Added cost to a normal xlisp message-send: about two
machine instructions.  The win would be that you could safely send
(say) a :SHOW message to any LVAL, instead of needing special-case
checking in the xlisp code. No?


--
     jsp@glia.biostr.washington.edu (Jeff Prothero)
     jsp@u.washington.edu (If above bounces.)
     Biological Structure Graphics Lab, U Washington