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: Urs Liska
Subject: Re: Discuss signature for new function \annotate (new version)
Date: Tue, 11 Jun 2013 16:36:05 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6

Am 11.06.2013 15:57, schrieb David Kastrup:
Urs Liska <address@hidden> writes:

Am 11.06.2013 15:11, schrieb Janek Warchoł:
2013/6/11 Urs Liska <address@hidden>:
Don't feel dumb - i don't know how to get along with scheme either ;) (yet)
After all, I'm still wondering what benefits Scheme offers.
I find it extremely reluctant to be understood (that's what it feels:
Scheme tries to avoid being understood), and I would like to have some
benefits that outweigh that effort. And so far I can't see them.

[This is a question for the conaisseurs out there]
It integrates nicely into LilyPond's syntax since it has almost no
syntax of its own and is almost effortless to cross into and out of.

It offers scoped variables and closures which also integrate nicely with
LilyPond and make it easy to program reusable code without side effects.
It has a reasonable set of data structures with automated memory
management.

Code and data structures have simple, straightforward text
representations.  As one corollary, it has a powerful
structure-preserving macro system that can do a more thorough and
reliable job at generating code than the C++ macro preprocessor and
template mechanism combined, at about 0.5% of its complexity.

As an interpretative language, it makes it easy to extend LilyPond's
functionality on the fly without needing recompilation.

A LISP family language with low-level underpinnings is what has created
the Emacs universe, arguably the longest-lived and most-extended editor
platform ever.

Most other languages have a human-readable program syntax, which a lexer
divides into lexical units and a parser recognizes and binds into
computer-readable parse trees.  LISP/Scheme has lexical units but no
parser.  Instead it has a "reader" which directly reads symbols and data
structures, most commonly lists.

The absence of an intermediate human-readable program representation is
what most people consider an initial challenge: basically, you directly
enter your parse trees into the computer.  The lack of an intermediate
syntactic layer is what makes generation, analysis, and transformation
of programs easy and powerful.

One consequence is that there is no difference between statements and
expressions.  The C redundancy of if/else with ?/: is absent as the
computer's concepts of either are the same and they are not cast into
different syntax depending on the use pattern.

If you quantify the time it takes for the frequency of surprising new
realizations about the language drops by half, the time for C++ is
measured in years, for Scheme in weeks.

Hi David,

thanks for that explanation. The parts that I understand makes sense to me. It seems my vague impression wasn't wrong that the power lies in Scheme/LISP somewhat being a 'generic' language that can be formed to about anything else. Obviously I'm still _very_ far away from a level where I can make use or even appreciate that.

Urs



reply via email to

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