Re: [Gnu-arch-users] tla1.1 plans

[Tom Lord]

    >>> == Jonathan Walther
    >> == Tom Lord
    > == Jonathan Walther

    >>> If it will be small, portable, and reasonably efficient, and
    >>> include support for macros, I would like to use it to create
    >>> an alternative = to "make" that also folds in the conveniences
    >>> of imake.

    >> Don't bet the farm or hold your breath or anything, but yes.  Among
    >> other things, I want to be able to run what is (more or less) SCSH.

    > Cool. Does that mean we'll have something like "here" documents?  That
    > would be very useful to me.  And I prefer the C conventions for
    > depicting strings, as opposed to the LISP ones. (\n vs. ~RP)

Heh... what a strange question to focus on and strangely framed.  I
don't see the connection between "C convetions vs. Lisp conventions"
for string syntax and here documents, or why "here" documents would be
the second thing you ask about, but:

I haven't written the reader/printer yet so the string-syntax hasn't
been decided.   I also like the C conventions simply because they'll
be harmonious with more things I'm interested in than other
alternatives.   More code reuse.  Less need for "glue code".

Systas scheme, from which I plan to migrate features, has a
"here"-document-style string syntax which I have used to good effect.
It also shares some properties with backquote -- allowing parts of a
string to be computed at run-time.  It doesn't interact with existing
Emacs lisp modes as well as I might like.

Most recently, I have been considering what might be the best option
to make an extensible reader --- the candidates including CL-style
reader tables, making a reader driven by something like a pair of
lex/yacc programs, and a very limited reader-table mechanism that
allows for new "#" forms.   I'm kind of leaning in the CL direction
because it's a pleasant blend of operationally nice and theoretically
clean -- at only a slight cost in generality.

In general, the aim of the initial release is to make a lisp that's
maximally hackable, rather than maximally featureful.   It has been my
observation that there are many "hackable" lisp implementations, but
that mistakes in the design of the core can be severely limiting in
horrible ways.

-t