lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Discuss signature for new function \annotate (new version)


From: David Kastrup
Subject: Re: Discuss signature for new function \annotate (new version)
Date: Tue, 11 Jun 2013 20:59:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> I think David has given some valuable clues as to what makes LISP
> different from most other languages.

The one thing that it has going as an extension language tied tightly
into LilyPond itself is that it does not come with a competing syntax of
its own.  It's just matched parens.  That also makes editor support
reasonably tolerable (the most important thing is being able to match
parens) in spite of having several languages mixed in the source file.

> I can accept that this offers some benefits (and maybe even
> substantial ones) - it's just so sad I can't 'feel' them as advantages
> compared to the wall of obscureness one is faced for a long time.

I consider that characterization pretty absurd considering the
complexity of almost all other languages.  Lua is a language renowned
for its simplicity: its syntax definition fits on a single A5 page
(disregarding operator priorities) with maybe 25 definitions or so.

Scheme does not have a syntax definition worth speaking about ("read
syntax" has about 5 rules or so, and I can't think of anything that
needs semantic nesting apart from parens and quotes, and lexical
matching apart from double quotes).

Or operator priorities.  Or operators.

There is no "wall of obscureness" short of unfamiliarity, and there is
no excuse for "facing it for a long time" except never reading up on it.
There is not enough material to last "a long time" unless you don't
actually bother getting acquainted with it in the first place.

What actually takes getting used to is writing in a functional style.
Scheme has a loop construct called "do" which is more or less like a for
loop in C, and that's something better avoided if you want to arrive at
a readable style: thinking more in terms of expressions than control
structures tends to match the somewhat single-minded expression syntax
better and makes it easier to "get into the flow".

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]