compact code representation

[Fare Rideau]

NB: Could people on the list please use more meaningful subject lines,
instead of propagating the same meaningless line when the subject
has drifted far away the original message? Thanks.

FOLLOWUP-TO: lispvm@math.gatech.edu

>>: hbaker
>: ABW

> On 29 Apr 97 at 7:48, lispos@math.gatech.edu wrote:
Alaric, will you correct your quoting software?

>> Gzipped Lisp source code is very compact.  I would suggest using it
>> rather than byte codes if your interest is _merely_ in compact code.
It might be a quick&dirty solution,
but Lisp-specific algorithms can achieve better faster compression
that allows code checking, mass allocation, and more at the same time,
while removing the need to parse the code.

Of course, developing such a format is not a priority for now
[though it may be a fun project for someone with some spare time].

>> It would be nice to be able to update the VM over time, and not be
>> locked into a bytecode that can never change.
In as much as the "bytecode" format is a faithful representation
of a valid Lisp program's ADT, then it's extensible.
Anyway, I agree that the ultimate code interchange format
to which to revert when negociating might be ASCII Lisp source.

> My favourite approach is just to define a representation for Lisp lists
> on disk in binary format. "source code" in ASCII form is just one way
> of doing this. Another is to have a symbol table followed by a tagged
> data dump,
Yeah. That's what I've been talking about for some time, ain't it?
See in the TUNES project, the file src/Migration/T3P.sgml,
(to use with the sgmltools linuxdoc formatters).
and more generally,
http://www.eleves.ens.fr:8080/home/rideau/Tunes/Subprojects.html#Migration

> where atoms all have unique type tag byte values, and lists
> are represented as the list type tag, the list length (32 bits enough
> for everyone?), and then the corresponding set of subobjects.
Oh no! We've been talking about compact code,
and now you're having 32-bit lengths???
Many LISP constructors have fixed arity; most lists are small;
huffman-like encoding of list length may be used;
or even a terminator-based list encoding,
which allows for a more regular pattern if we want to further compress
the already compact code through GZIP...

> Thus, it is the full s-expr, not some compiled form, but it's compact
> and fast to load.
Yeah.

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"