RE: s-exprs + prototypes

["Anton van Straaten" <address@hidden>]

James McCartney wrote:
> > BTW, with all this talk of "objects" as the ultimate goal of
> > all programming, you might want to have a chat with some
> > FunctionalWeenies or LambdaWeenies, about the mathematical
> > properties of languages.
>
> Yup. Smug. and condescending too.

I should have phrased it differently.  I was reacting in part to the
following silly comment:

> Smug Lisp Weenies: we've taken your lambdas and now we're taking your
> s-exprs and macros. Soon there will be no leg to stand on.

However, there was a real point behind my remarks.  You have been saying
things about objects like "That everything is an object can only be a
benefit not a disadvantage."  As someone who has developed with OO languages
since the late '80s, implemented a Smalltalk-influenced OO language
extension product, and written about and trained people in OO design and
development techniques, I disagree with your perspective on objects as an
unmitigated good thing (at least as currently conceived in existing
languages).

One of the reasons I disagree relates to the discussion we've been having:
existing object systems invariably are tightly-bound semi-arbitrary
collections of features, which have typically been picked based on a mixture
of some ad-hoc vision of the language authors, as well as in reaction to
specific problems and constraints that the authors were trying to deal with.
That's fine, and it has resulted in some practical languages, but I think
it's possible to do a lot better, and one of the ways to do that is to learn
from experiences with other languages, research, and so on.

> I do own SICP, Structure of Symbolic Comp., On Lisp, Common Lisp
> (Steele), and have a bale of papers printed out on monads and
> spineless tagless G-machines that I've read over the years.

I'm really glad to hear that.  I confess, based on your comments about
objects, it sounded to me as though you were doing what a lot of people in
commercial programming have done - including myself at one time, as
described above - which is to jump on OO as a way to fill the theoretical
vacuum which has existed in programming as an ad-hoc discipline.

> I don't really care that you can implement anything in Lisp. You can in
> C too. BFD.
> But I don't want to program in Lisp. So I'm writing a language that
> does what I want.

That's great.  I didn't see anyone saying that you should be programming in
Lisp.  Earlier, I pointed out that Scheme is a a good tool for prototyping
an s-expression language, which is a simple fact, and was offered helpfully.

However, Lisp & Scheme do have things that can be learned from, especially
if you're designing languages.  I say that because that's what I found to be
the case, after years of working with OO.  There's that much-reused saying
"Those who do not understand {X} are doomed to reinvent it, poorly."  Lisp
and Scheme are a couple of the things that can substitute for X, and one
reason they're such good candidates for being that X is that they've been
used for decades as laboratories for exploring language ideas.

The impression I have from many of the anti-Lisp/Scheme comments I've seen
here is that they suffer from 'doesNotUnderstand'.  Unfortunately, the only
real way to correct that is either to work seriously with the languages in
question, or as the quote implies, reinvent the functionality which wasn't
previously understood.

(I should disclose, although I've previously inadvertently made it obvious,
that my own knowledge of Lisp proper is woefully sketchy.  The Lisp I have
experience with is Scheme, and my last significant experience with another
Lisp was many years ago, pre-Common Lisp.)

> My front door has a mutable state. And a good thing too, cause
> otherwise I couldn't leave the house.

That's a common perspective engendered by the notion of mutable objects.
I'd rather model your front door as existing in various states over time,
but at any given moment in time, its state is, for the purposes of the
model, static.  This is directly analogous to the way in which data flows
through a pure functional program.  The view that your front door is mutable
comes from collapsing its multitude of states over time into a single
conceptual object, and in the process typically losing that chronological
history of states.  The view that your front door is a single object is as
much a fiction (or model) as the model I've described; but there are
benefits to the more explicit model which takes time into account.

Ignoring history and replacing it with a single mutable object can often be
a valid modelling choice, but when you do want to model that history, using
mutable objects to do it is unnecessarily sloppy.  Even when you don't care
to model the history, having a clear understanding of the relationship
between your objects and time can be important.  Again, mutable objects
don't encourage this.

There are areas in which not mutating objects can matter a lot - for
example, in something as mundane as accounting, where you need to be able to
view an account as a history of states and/or events.  It would be very bad
if an account could simply change its state with no record of that having
happened.  (Well, it would be very bad for the owner of the account; but a
short-term win for the programmer transferring amounts between the owner's
account and his own. :)

> And I can't find an embeddable real time GC
> lisp either so, it is useless to me in more ways.

Have you seen this Paul Wilson paper on Real-Time Non-Copying Garbage
Collection:
http://www.cs.utexas.edu/users/oops/papers.html#real-time-gc
...which describes a public domain collector claimed to be "suitable for
incorporation into any garbage collected language implementation".  This
collector can be used with RScheme (an object-oriented Scheme).  Don't know
what your embeddability criteria are; RScheme can generate C code, so is
conceivably embeddable.  Back to the language prototyping idea, you could
prototype your language with something like this, then later replace the
Scheme side with your own lean mean s-expression based, macro-sporting
non-Lisp language.

On another note (pun intended), related to your intended application, are
you familiar with the sound editor SND?
http://ccrma-www.stanford.edu/software/snd/
It's scriptable with Ruby & Guile.  Not real-time afaik, but may be
interesting nonetheless.

Anton