Instanciable scheme engraver

Instanciable scheme engraver

A scheme engraver definition may be a 0 argument procedure evaluating
to an a-list scheme engraver definition.  This allows to define
instance slots for a scheme engraver.

[nicolas.sceaux, 2010-02-21 10:10:28]

Hi,

This is a proof-of-concept for instanciable scheme engravers, with private
instance slots.

There is at least one issue that I have to solve before this is commitable, as
this shows the following warning:

Warning : Attempting to remove nonexisting listener.
Warning : Attempting to remove nonexisting listener.

[hanwenn, 2010-02-21 14:11:15]

On Sun, Feb 21, 2010 at 7:10 AM,  <nicolas.sceaux@gmail.com> wrote:
> This is a proof-of-concept for instanciable scheme engravers, with
> private instance slots.

Looks OK to me; maybe you'd want to pass in the context into the
function, so it can do additional switching based on properties?

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[nicolas.sceaux, 2010-02-28 15:48:40]

Le 21 févr. 2010 à 15:11, Han-Wen Nienhuys a écrit :

> On Sun, Feb 21, 2010 at 7:10 AM,  <nicolas.sceaux@gmail.com> wrote:
>> This is a proof-of-concept for instanciable scheme engravers, with
>> private instance slots.
> 
> Looks OK to me; maybe you'd want to pass in the context into the
> function, so it can do additional switching based on properties?

Isn't the context accessible through the translator argument of
e.g. the initialize function?

  (initialize . ,(lambda (translator)
                   (let ((context (ly:translator-context translator)))
                     ...

nicolas

[hanwenn, 2010-02-28 16:11:21]

On Sun, Feb 28, 2010 at 12:48 PM, Nicolas Sceaux
<nicolas.sceaux@gmail.com> wrote:

>> On Sun, Feb 21, 2010 at 7:10 AM,  <nicolas.sceaux@gmail.com> wrote:
>>> This is a proof-of-concept for instanciable scheme engravers, with
>>> private instance slots.
>>
>> Looks OK to me; maybe you'd want to pass in the context into the
>> function, so it can do additional switching based on properties?
>
> Isn't the context accessible through the translator argument of
> e.g. the initialize function?
>
>  (initialize . ,(lambda (translator)
>                   (let ((context (ly:translator-context translator)))
>                     ...

Right, but at that point the alist (and the other functions as well)
are already constructed?  Maybe you would want to switch earlier.

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[nicolas.sceaux, 2010-02-28 17:23:49]

Le 28 févr. 2010 à 17:11, Han-Wen Nienhuys a écrit :

> On Sun, Feb 28, 2010 at 12:48 PM, Nicolas Sceaux
> <nicolas.sceaux@gmail.com> wrote:
> 
>>> On Sun, Feb 21, 2010 at 7:10 AM,  <nicolas.sceaux@gmail.com> wrote:
>>>> This is a proof-of-concept for instanciable scheme engravers, with
>>>> private instance slots.
>>> 
>>> Looks OK to me; maybe you'd want to pass in the context into the
>>> function, so it can do additional switching based on properties?
>> 
>> Isn't the context accessible through the translator argument of
>> e.g. the initialize function?
>> 
>>  (initialize . ,(lambda (translator)
>>                   (let ((context (ly:translator-context translator)))
>>                     ...
> 
> Right, but at that point the alist (and the other functions as well)
> are already constructed?  Maybe you would want to switch earlier.

Right, anyway, "ça ne mange pas de pain" (as we say in French,
literally: it does not eat bread).

I've uploaded another patchset, which shows in particular how the
ambitus engraver may be implemented in scheme, after adding a few
scheme callbacks.

  <http://codereview.appspot.com/216066>

(allthough scheme-engraver-ambitus.ly would not be a regression test,
but rather an example, but I don't where such things go these days).

Nicolas

[hanwenn, 2010-03-01 02:44:06]

lgtm

[dak, 2010-03-03 13:52:24]

The use of modules oop and goops appears to me as part of a programming practice
at a different knowledge level than to be expected from the audience of this
example.

If I rewrite the example to get along without those modules, are there chances
that the results will get accepted?

[hanwenn, 2010-03-03 15:02:33]

On Wed, Mar 3, 2010 at 10:52 AM,  <dak@gnu.org> wrote:

> If I rewrite the example to get along without those modules, are there
> chances that the results will get accepted?
>
> http://codereview.appspot.com/216066/show

I think that is an excellent idea. We may want to keep both examples
though, just to show people how things work.   In any event it would
be interesting to see which of both is simpler and easier to follow.

it is somewhat disappointing that the scheme examples weighs in at 190
lines of code, vs. 220 lines for the C++ version.  Scheme engravers
would be more convincing if they could drastically reduce the amount
of code needed to write them.

-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

[nicolas.sceaux, 2010-03-04 11:21:58]

Le 3 mars 2010 à 14:52, dak@gnu.org a écrit :

> The use of modules oop and goops appears to me as part of a programming
> practice at a different knowledge level than to be expected from the
> audience of this example.
> 
> If I rewrite the example to get along without those modules, are there
> chances that the results will get accepted?

Please do, David.  There are requests for simplifications.

[dak, 2010-03-04 13:51:55]

Nicolas Sceaux <nicolas.sceaux@gmail.com> writes:

> Le 3 mars 2010 à 14:52, dak@gnu.org a écrit :
>
>> The use of modules oop and goops appears to me as part of a programming
>> practice at a different knowledge level than to be expected from the
>> audience of this example.
>> 
>> If I rewrite the example to get along without those modules, are there
>> chances that the results will get accepted?
>
> Please do, David.  There are requests for simplifications.

I think I'll have something useful tomorrow.

-- 
David Kastrup