Prototype Based Programming in Lisp?

Matthew Mondor mm_lists at pulsar-zone.net
Sat Jul 2 14:13:41 UTC 2016


On Sat, 2 Jul 2016 06:05:47 -0700
David McClain <dbm at refined-audiometrics.com> wrote:

> Hi All,
> 
> After having been comfortably isolated in a Lisp atmosphere for more
> than 20 years, I’m finding myself being dragged into a “new” world
> centering on Javascript and prototype based programming. It feels
> like I’m being dragged back by more than those 20 years, but in an
> effort to overcome the resistance tendencies of aging, I thought I’d
> delve a bit more deeply into this realm.
> 
> I’ve done some investigating and found the genesis in Self. But
> really, this seems like a trivial kind of pursuit for Lisp. I am
> aware of the new difficulties in making fast systems with the lack of
> classes, and troubles deciding inheritance of behaviors. 
> 
> Does anyone have some interesting insights and pointers to papers
> regarding prototype programming in Lisp?

There is various documentation available on optimizing JS, i.e. tracing
JIT, etc as it's so popular.  Unfortunately I don't have exact
references on hand without some searching myself, I haven't followed
the development in years, but I used to follow the SpiderMonkey to
TraceMonkey developments on the Mozilla js-eng mailing list, of which
archives are available.  I was an avid SpiderMonkey+JS user before I
got into Lisp, but for application programming rather than the web.
(i.e. http://mmondor.pulsar-zone.net/mmsoftware.html#js-appserv-sh )

A naive system with a prototype chain implemented as a list, and
objects implemented as hash-tables, is indeed rather slow.  In
Javascript, the programmer also should make an effort to not overly use
closures and to as possible inherit from the parent prototype objects
to avoid unnecessary object creation overhead (i.e. complex
constructors doing a lot of object-instantiation setup are slower than
a pointer to a parent object).  This is also true for functions that are
object properties, and closures often cause extra per-instance
initialization in this model.
Beware that I was still very new to Lisp, but a very naive test
implementation:
http://git.pulsar-zone.net/?p=mmondor.git;a=blob;f=mmsoftware/cl/test/prototype.lisp;hb=HEAD

There is an interesting similarity for prototype object property
references and symbol references in Lisp packages; and an approach that
can be used is to create a faster reference like an index ID or
pointer when "interning" a property/symbol, such that generated code
can use faster indexing instead of hash table lookups at runtime.
A small example of what I mean:
http://git.pulsar-zone.net/?p=mmondor.git;a=blob;f=mmsoftware/cl/test/vsymbol.lisp;hb=HEAD

But there also are many cases where inference can allow to eliminate a
lot of dynamic code to result in more static code.  ECMA also defined
extensions for less dynamic objects which are closer to Java classes,
for use when optimization is more important than flexibility.  I'm not
sure if those are currently used in JS as they were in Flash, however.

An approach could be to compile Lisp to Javascript, and to implement
the prototype system library to use the native features of the
language, and take advantage of currently optimized engines and their
dynamically-specialized JIT/VMs.  There is also asm.js and WebAssembly
which are realistic targets for an existing bytecode compiler.  There
may actually exist simpler Lisps already targetting Javascript (there
are libraries that compile a limited subset for web frameworks at
least).  Perhaps that extending such, or implementing a temporary
simpler Lisp for initial testing might be a realistic investment?

-- 
Matt



More information about the pro mailing list