On Fri, Jul 6, 2012 at 9:51 AM, David Kastrup
<address@hidden> wrote:
Joe Neeman <
address@hidden> writes:
> 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.
Pointer_group_interface::find_grob is needed here.
That may be useful at some point, but it's orthogonal to what's going on here.
I think being able to move the _entire_ chunk of functionality to Scheme
makes _excellent_ sense since it means we arrive at a piece of
functionality that can serve as a template for _user_ written
functionality without requiring recompilation.
The entire chunk of functionality has already been ported. That is not the issue.
A chunk of Scheme code with "just" one or two semi-trivial C++ functions
required to complete it is useless for that purpose.
The semi-trivial C++ function is _not_ useful for the scheme code. It is used in two parts of the C++ code. However, because it belonged to the same file as various other functions that were being ported, Marc was planning to port this semi-trivial function to scheme also, and then call the new scheme function from C++ code.
In the amount of time we've spent discussing this, we could have rewritten the function in scheme, haskell, perl, and brainf*ck by now. I really think that the best thing is just to leave the function where it is and stop worrying.
Cheers,
Joe