Re: Scheme syntax vs. other languages

[David Kastrup]

James Harkins <address@hidden> writes:

> On Thu, Jun 7, 2012 at 12:24 PM,  <address@hidden> wrote:
>> Joseph Rushton Wakeling <address@hidden> writes:
>>> I've also included a few of D's safety features with assert() commands
>>> to ensure that the variables have the properties required.
>>>
>>> //////////////////////////////////////////////////////////////////
>>> struct LilyPitch
>>> {
>>>     int octave;
>>>     int notename;
>>
>> What is an int?  Why do I need these lines?
>
> Quite an amusing exercise, demolishing the D example. I have half a
> mind to do the same thing with the original scheme example, but I
> expect I'll get bored with it about halfway through. Nonetheless, to
> start off:
>
> (define (naturalize-pitch p)
>   (let ((o (ly:pitch-octave p))
>         (a (* 4 (ly:pitch-alteration p)))
>         ;; alteration, a, in quarter tone steps,
>         ;; for historical reasons
>         (n (ly:pitch-notename p)))
>
> For starters, I'm already lost. It's next to impossible, without at
> least months of practice working with LISP or scheme, to have a strong
> intuitive sense of which ( and ) belong together (at least, without an
> editor like emacs that highlights matching brackets).
>
> It's very easy for the experienced schemer to underestimate the
> difficulty this poses -- even to programmers who are experienced in
> other languages (let alone the novice programmers that all of this is
> supposed to invite into the world of extending LilyPond).
>
> Second: *Prefix* notation for math and comparison operations? This is
> supposed to be easier for the novice?

Nope.  It is consistent.  And you don't get the point either: this was
not supposed to be a general programming language shootout.  It was the
question what works as an _extension_ _language_ for LilyPond.

> D is obviously the wrong fit for an lp extension language, but scheme
> has a couple of strikes against it right from the start.

Sure, it requires getting into.  Not that D doesn't.  The rules of
Scheme syntax can be learnt in one afternoon.  The syntax may not
exactly resemble mathematical notation or plain language, but it is
simple and regular.  If we were out for natural language, our extension
language for LilyPond would be COBOL.

Scheme has a low lexical and syntactical impact, and the price for that
is a uniform syntax, and a uniform syntax has few structuring visual
elements.  One payback for that is that you can do syntax
transformations in a predictable and reliable way.

Lua has a low data structure impact (just one data structure, the
table), and the price for that is paid in computational complexity.

It turns out that both of these extreme cases are actually significant
advantages for an _extension_ language since the extension features
don't get into a food and mindframe fight with the system they are
supposed to extend.

I am currently reworking the context property system.  Scheme has
vectors and lists.  What I need is a vector I can grow with a reasonable
tradeoff on performance.  Guess what: lists can grow in Scheme.  Vectors
can't.

Lua has only tables, and growing them at their end is quite efficient.
Shrinking a Scheme _list_ at the _beginning_ is totally efficient and
natural, and you can't do that well in Lua.  But it's actually not
needed all that much in typical use cases.

Both languages are fully dynamic and have an interpreter.  That's
important for an extension language.  I don't see that D is that.

Now implementing the _primitives_ of LilyPond in a compilable general
purpose programming language with good efficiency: not much of a beef
with that here.  Just don't confuse this with the problem of extending
LilyPond.  The "Extending LilyPond" guide does not talk about C++.  And
it is a good thing that it doesn't, and doesn't need to.

I don't know _any_ system or language where the syntactical ties into
the extension language are as thorough as between LilyPond and Guile.
It may be a nightmare for intelligent editors, but it is also a good
illustration of the potential of Guile/Scheme.  But it could be quite
more thorough.  For one thing, the structure of XML is rather close to
that of Scheme, so there is potential for pattern-based conversion of
music expressions to MusicXML (and of course, pattern-based conversion
to other music expressions).

So the overall tradeoffs in the language choice are, all in all, solid
working material.  This concerns the choice of Scheme: the particular
implementation, Guile, has a lot more specific advantages and drawbacks
than the general choice.

At the current point of time, being able to talk with the Guile
developers and have them listen is a definitive advantage.  I will
readily admit that over the history of development, this is not the
overall situation that in particular Han-Wen had to work with.

> And I was right... I did get bored with it. But that's because it's
> kind of pointless. More useful, maybe, would be to compare lp's scheme
> functions against a comparable implementation in, say, Lua (which is
> designed for extension-writing).

I think this is missing the point somewhat.  For comparing the
usefulness as an extension language, it is more interesting to look at
the usage of Scheme in ly/* rather than in scm/*.  The stuff in scm/* is
more or less self-contained and could be written in other languages, but
that's a shoot-out with a different focus.

> For the record, I'm no apologist for D (I don't know anything about it
> and it looks rather fussy at first glance, not interesting to me). But
> scheme is superficially less than appealing as well. I'd say
> supercollider is more legible (though obviously the sc interpreter
> isn't a good candidate to integrate into another environment).

Try writing programs in TeX one day.  It's a blind programming language
(TeX's stomach) that can do assignments but not make decisions based on
the results, and a lame programming language (TeX's mouth) that can make
decisions based on the values of variables, but not change them.  Both
run only loosely synchronized, and there are things where you can use
only one of them.

And still, a LaTeX ecosystem could be grown based on _that_ total design
catastrophe.

-- 
David Kastrup