Re: Scheme syntax vs. other languages

[David Kastrup]

James Harkins <address@hidden> writes:

>> > 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.
>
> I'm certainly in no position to argue for another extension language
> for LP -- just saying up front that isn't the purpose of this
> e-mail. Just throwing an opinion into the pot.
>
> In my SuperCollider work, more and more I prefer a coding style that
> favors legibility over concision.

No question about that, but they are not necessarily opposite.
Mathematical notation is quite concise: try reading the original
algorithm of Euler in its original notation, or Arabic treatments on
algebra at pre-Renaissance time.  They are tedious for all the verbosity
they have to use instead of notation.

> I find scheme to be impossible to read without an editor that
> highlights matching brackets.

It needs to be properly formatted.  Just dumping a form with "display"
should be compared to reading the output of disassembly or a code
obfuscator.

> I can start to make sense out of it once the editor shows me which ()
> belong together.

That's the job of the programmer, and of course he should enlist the
help of the editor when necessary.

> That's an obstacle -- it pushes learning lisp into the category of
> Things I Really Ought to Do Someday If for No Reason Other Than
> Building Character. I may yet do that for LP and/or Emacs, but it's
> intimidating -- and if it's intimidating for me, I expect it's more so
> for other LP users.

Programming is intimidating.  The average level of complexity for simple
music functions should not lead to insurmountable mountains of parens.

Yes, that it is the _only_ actual punctuation/structuring element and
there are no other elements for expressions, statements, blocks and so
on _is_ not using human potential for recognition of visual groups best.

The average programming language has a lexer tokenizing individual
tokens, and a parser translating its input into a syntax tree which is
then processed by the compiler/interpreter.  For better or worse, with
Scheme/Lisp the print form of the syntax tree _is_ already valid input
for the interpreter.  A tree is a simple data structure, and thus its
printout, as a direct rendition, does not have an abundance of
punctuation.

It is a tradeoff.  Scheme/Lisp gives such trees a reasonably
human-readable structure and print form.  Since they still correspond
1:1 to a program's parse tree, fast-paced nesting of uniform elements
for non-trivial constructs is not really possible to avoid.  You get
considerable expressive and manipulative power in return.

Doing the equivalent of syntax manipulation with macro programming just
does not work with languages like Lua: textual manipulations are much
more complex.

For human-readable bulk material, LilyPond has its own input language.
For efficient work, we use C++.  For manipulating music and other
transformatory stuff, Scheme is not the worst compromise as a middle
layer.  But cooperation and handoff between layers certainly leaves a
lot of potential for improvement.

In particular, for understanding the architecture of LilyPond, I think
that too much C++ is required.

> But yes, scheme has a lot going for it here.

In my opinion, it is good enough for putting it to work.  I am more
annoyed with its data structures (and our lack of tying them into the
C++ layer) than its syntax.

I am currently working on understanding Goops and how to tie it into
LilyPond, and the main problem I currently have is that Goops is totally
flexible.  You can make it do almost anything with little effort, but
that does not mean that everything is a good idea.  For one thing, it is
not obvious which of the things you can do come with what kind of cost
in memory and efficiency, so I am reading a lot of its _implementation_
to get a feeling for that.  And for another, it is so powerful that it
is flavorless: you need to develop a _style_ of inheritance and
structuring you want to use.  It's not prescribed.

I expect the results to make a lot of sense and be intuitive and
convenient to use: there is enough freedom to implement them in this
manner.  But it is quite a bit of work in the mean time.

-- 
David Kastrup