lilypond-devel
[Top][All Lists]
Advanced

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

## Re: Is gcc able to handle anonymous functions?

 From: Joe Neeman Subject: Re: Is gcc able to handle anonymous functions? Date: Thu, 5 Jul 2012 18:36:40 +0200

On Thu, Jul 5, 2012 at 8:44 AM, address@hidden wrote:
On 5 juil. 2012, at 08:14, Joe Neeman wrote:

On Thu, Jul 5, 2012 at 12:37 AM, address@hidden wrote:
On 4 juil. 2012, at 20:10, Marc Hohl wrote:

> Am 04.07.2012 13:29, schrieb David Kastrup:
>> Marc Hohl <address@hidden> writes:
>>
>>> Hello list,
>>>
>>> the topic is somewhat over my head, but perhaps someone with more
>>> insight can answer this question?
>> I think that gcc likely can, don't know about g++, and we don't want to
>> rely on it anyhow.
> Ok.
>
> Well then, is there an alternative?
>
> I want to get rid of bar-line.cc (issue 1320), and I have managed to get all
> definitions but Bar_line::non_empty_barline into scheme.
>
> In lily/note-spacing.cc, I have
>
> Grob *bar = Pointer_group_interface::find_grob (right_col,
>                                                     ly_symbol2scm ("elements"),
> Bar_line::non_empty_barline);
>
> The simple approach
>
> bool non_empty_barline =
> ly_scm2bool (scm_call_1 (ly_lily_module_constant ("bar-line::non-empty-barline"), right_col->self_scm ()));
>
> with
>
> (define-public (bar-line::non-empty-barline grob)
> (and (grob::has-interface grob 'bar-line)
>     (pair? (ly:grob-extent grob grob X))))
>
> doesn't work.
>
I just realized that there's an easier way to do this w/ existing code conventions.  You can overload Pointer_group_interface::find_grob so that it accepts a simple closure as the third argument.  Then, wrap the Scheme function in a simple closure.

Why not just leave the function in C++? I have nothing against porting things to scheme, but in this case it just seems like an exercise in making things more complicated, for no gain.

It's doable - the goal was to port the entire thing to Scheme.  You're right that it is much easier to write in C++.

I think it's exercises like that that help strengthen the Scheme bindings and thus lead to more customizability/extensibility.

In this case, I disagree. The function in question is used in 2 places in the C++ code, neither of which is a good candidate for customization. The only argument for porting this function in the first place is that it happened to live in the same file as some other stuff (which _did_ make sense to port). That doesn't sound like a very good argument to me.

Cheers,
Joe

reply via email to

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