Dear Faré,
I'm sorry (but also impressed ;) to hear that you have reached the limit of
procrastination within Common Lisp.
I'm a little preoccupied until next week, but brief answers to some of your
questions are inline below...
Is there a mailing list specifically about technical details of maru,
or is FoNC the thing?
No and not really (at least not for any kind of sustained planning, design and
development discussion).
Throwing caution to the wind and misplaced trust into the toxic
smog^H^H^H^H^H^H^H^H^H^H cloud, I created maru-...@googlegroups.com (with
https://groups.google.com/forum/#!forum/maru-dev possibly being the place to
sign up, I think, assuming some cookie or other isn't poisoning my view of that
page compared to everyone else's view of it).
I am tempted to write a big introductory post containing my vision for where
Maru might go or how it might be reborn, given enough community support, but
that will not happen before next week.
* I see the gc reserves 8 bits for flags, but uses only 3. Is that a
typo? Is that done with the intent of addressing that byte directly?
No and not really (at least not explicitly). An ancient gcc generated wretched
code when the boundary was not byte-aligned. Things may be different now.
You're right that 16 Mbytes is a stingy limit for certain kinds of application.
On the other hand, given the opportunity for 5 extra bits, I'd gladly
grab one for a one-bit reference count (i.e. is the object linear so
far or not), and another one for a can-we-duplicate capability,
if/when implementing a linear lisp on top of it.
They're yours for the taking. I was waiting to have some time to reply
properly to the linear lisp thread but, since you mention it, one of the
reasons for having all accesses to object fields go through get() and set() was
to make it ridiculously easy to add read and write barriers.
* The source could use comments and documentation.
I suffer from being able to make sense of my own code many years after writing
it. Not very conducive to community process, I know.
Would you merge in patches that provide some?
Of course! I might not merge them very quickly, though, since I'd be so
unreasonable as to want to read them all first and elaborate if necessary. :)
* Speaking of documentation, could you produce an initial README, with
a roadmap of which files are which and depend on which, and how to run
the various tests, etc.? Maybe separating things in subdirectories
could help. Or not. Many Makefile targets are obsolete. A working
test-suite could help.
You almost answered your own question. I try to keep README.examples (which is
a script) working properly. It exercises a huge amount of the code, but to
find out what exactly that code is you do need to obtain some kind of
transitive closure over all the 'load's and 'require's that pull in lots of
source files.
Many Makefile targets were for temporary experiments, long abandoned, and
should be removed. Others are for exercising interesting code (that still
works and yet is not portable enough to be part of README.examples) and should
be made more prominent. (Targets that exercise a statically-typed compiler for
Maru are hiding in there somewhere, with obscure names.) Other interesting
code has no Makefile or README.examples presence at all. (Minimal SDL bindings
to open a window, render some text and then paint with the mouse is one
example, prompted by a recent discussion on this list.)
The whole thing is teetering on the edge of being rewritten in itself (as the
original three-file version of Maru was written in itself). My intention was
always to tidy things up considerably at that time.
FWIW, there is a sketch of how Maru's generalised eval works
(http://piumarta.com/freeco11/freeco11-piumarta-oecm.pdf) which is entirely
accurate in intent and approach, if a little different in some implementation
details.
* Is the idea that everyone should be doing/forking his own,
CipherSaber style, or is there an intent to share and build common
platform?
I'd love to build a common platform. Maru is in particular trying to be
malleable at the very lowest levels, so any special interest that cannot be
accommodated easily within the common platform would be a strong indicator of a
deficiency within the platform that should be addressed rather than
disinherited.
Where there is a choice between forking to add a fix or feature and clamouring
to get that fix of feature adopted into some kind of central repository, I
believe clamouring always benefits vastly more people in the long run. I
intensely dislike the github/gitorius 'clone fest' mindset because it dilutes
and destroys progress, encouraging trivial imitation rather than radical
innovation -- which, if there is any at all, finds itself fighting an
intractably high noise floor. Forking will always split a community (even if
one side is only left with a community of one) so
