[Top][All Lists]

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

Re: define-void-function or define-procedure ?

From: David Kastrup
Subject: Re: define-void-function or define-procedure ?
Date: Wed, 19 Oct 2011 11:26:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Štěpán Němec <address@hidden> writes:

> On Wed, 19 Oct 2011 10:22:09 +0200
> David Kastrup wrote:
>> What would people prefer for creating a Lilypond function that returns
>> an "unspecified" value (what the Guile read-eval-print loop takes as a
>> hint to print nothing at all) and is called for its side effect?
>> define-void-function or define-procedure?  The first is a bit more
>> C-ish, the second more Pascal-ish.  I am not going to consider
>> define-subroutine though.
> Given that in the Scheme world, "procedure" is the standard term for
> functions in general, `define-procedure' would IMO be a rather
> unfortunate name for something used to define _only_ that subset of
> procedures which return an unspecified value, if that's what you mean.

Ok.  Now unfortunately, Guile has a number of functions that one would
expect to return SCM_UNSPECIFIED, but which return something else.
hashq-set!, set-object-property! and a few others.  So I need a nice way
to tell Lilypond to ignore a Scheme expression even though it looks like
it could be used as a valid Lilypond construct.  I considered
\call #(hashq-set! ...
but it is a bit misleading since the Scheme expression would be called
anyway.  There is also
\ignore #(hashq-set! ...
but it sounds a bit like nothing would happen.
\do #(hashq-set! ...
looks nice, but due to namespace pollution, it is already taken by
Guile, quite like \eval.

All in all, I can't think of anything better than \ignore.  An
alternative syntax like ##(...) or ##[...] seems a bit too sneaky to
me.  One other possibility would be \void.  It might look a bit nicer:

\void #(hashq-set! ...)
\void #(hashq-set! ...)

rather than

\ignore #(hashq-set! ...)
\ignore #(hashq-set! ...)

It's a bit C-ish, but not all that bad, and it fits with

David Kastrup

reply via email to

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