lilypond-user
[Top][All Lists]
Advanced

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

Re: Moving a tempo mark to the right


From: David Kastrup
Subject: Re: Moving a tempo mark to the right
Date: Fri, 01 Sep 2017 23:14:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Anthony Youngman <address@hidden> writes:

> On 01/09/17 21:36, David Kastrup wrote:
>>> I find the same thing with databases. So many people have their minds
>>> stuck in the 2-D relational world, and just cannot grasp the concept
>>> of a multi-dimensional database like Pick. Given that Pick is very
>>> much list-based (unlike SQL which is set-based), why can't I grasp a
>>> list-based language like Scheme? And Pick is very XML-like!
>> Because Scheme (like all LISP variants) does not even have a programming
>> language.  It has a clever way to write down parse trees as a
>> computer-readable data structure, bypassing the step of coding in a
>> programming language.  That makes it brilliant for structure-preserving
>> program manipulation and AI.
>
> But Scheme *IS* a language. Although I do understand exactly what you
> mean - my very first computer was a Jupiter Ace, which used Forth
> instead of BASIC.

No, Forth is a language.  It is compiled into code and the input does
not reflect the structure of the code: there is nothing delimiting a
BEGIN/UNTIL construct.  It cannot be manipulated structure-preserving.

LISP and Scheme have a REPL (read/eval/print loop).  Expressions are
_read_, evaluated, and printed.

(if (= x 3) 7 5)

is read as a list with its first element being the symbol "if", its
second element being the list (= x 3) and its third and fourth elements
being the numbers 7 and 5.  You can manipulate that list before
evaluating it, and macros do exactly that: they manipulate their
arguments into something different before it gets evaluated.

Early variants of Lisp never had a significantly compiled
representation: they just worked off the lists.  It helped that symbols
had value and function cells, rendering any further lookup unnecessary
once you had the symbol.  Guile compiles to varying degrees and does the
module lookup that connects symbols with particular variables (and thus
values) at compile time.

> So I've been exposed to that sort of thing right from the start, but I
> never really used it much.

It's completely different because Forth does not read data structures
but only single words and executes actions right away.  There is no
representation of the input to manipulate and consequently no macros
(the use of IMMEDIATE words within : ... ; sequences is not really
comparable since they do only stack manipulation and don't manipulate
actual input).

> Nothing to do with the distro - as I said I daren't upgrade. Firstly,
> gentoo has dropped KDE4 which means major UI changes which will give
> my wife panic attacks (slight exaggeration, but not much). (Plus a big
> learning curve for me.) And secondly my hardware is not quite
> trustworthy - gcc crashes a lot which I think is down to the CPU
> somewhere :-( Dunno why it's only gcc that seems to suffer (remember,
> the distro is gentoo :-)

Gcc's internal data structures tend to be quite prone to corruption.
I've had flaky memory that had no problems surviving days of elaborate
memory pattern tests but did not survive 20 minutes of kernel
compilation.  Change the memory for known good memory, and the kernel
compiled fine.  No idea what Gcc does that memory test programs fail to
account for.

-- 
David Kastrup



reply via email to

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