Create a module variable access system for C++

Create a module variable access system for C++

This replaces the previous "memoizing" ly_lily_module_constant with a
rather rigid system for importing/exporting/accessing module variables.

As opposed to the system used by ly_lily_module_constant, access will
continue to go through the respective module variables, making it
possible to also write to the respective variables.  In addition, this
ensures that any changes to the variables from the Scheme side will get
properly reflected in the C++ side, allowing for redefinitions when
debugging.

In a nutshell, ly_lily_module_constant ("ly:music?") would generally be
replaced with Lily::ly_music_p, a declaration of it looking like

  extern Variable ly_music_p;

would be placed in namespace Lily in lily/include/lily-imports.hh, and a
corresponding definition

  Variable ly_music_p ("ly:music?");

in namespace Lily in lily/lily-imports.cc .  The type Scm_module where
variables are organized can use pre-existing modules (in which case it
is initialized by calling the member function import ()) or are can
bring up a fresh module (in which case it is initialized by calling the
member function boot ()).  The startup is done in lily/guile-init.cc .

Since one of the most frequent uses of imported variables is for
function calls, the Scm_variable type (underlying the module-local
Variable type) has operator () defined to allow calling as a function.

So the previous

    scm_call_1 (ly_lily_module_constant ("ly:music?"), x);

can now be expressed as

    Lily::ly_music_p (x);


In order to avoid Srfi_1 import for a single function, also contains

Issue 4461: Don't use drop-right from (srfi srfi-1) in C++

It can perfectly amicably be replaced by more efficient code readily
available in the core.

[dak, 2015-06-25 16:18:29]

Fix several inaccurate variable imports

[dak, 2015-06-26 14:22:37]

Fix value->lily-string import, make Scm_module::import honor public interface

[Dan Eble, 2015-06-29 23:54:31]

I'd like to study this more, but I don't think I have the time to spend.

https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules.hh
File lily/include/lily-modules.hh (right):

https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules...
lily/include/lily-modules.hh:39: Scm_module (const char *name);
explicit?  Implicit construction coupled with implicit conversion to SCM could
lead to surprises.

https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules...
lily/include/lily-modules.hh:94: Module_variable (const char *name, SCM value =
SCM_UNDEFINED)
explicit?

[dak, 2015-06-30 00:30:15]

https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules.hh
File lily/include/lily-modules.hh (right):

https://codereview.appspot.com/249920043/diff/40001/lily/include/lily-modules...
lily/include/lily-modules.hh:39: Scm_module (const char *name);
On 2015/06/29 23:54:30, Dan Eble wrote:
> explicit?  Implicit construction coupled with implicit conversion to SCM could
> lead to surprises.

I don't understand what you are trying to say here.  Apparently you are arguing
for the "explicit" keyword.  We don't use any C++11 feature elsewhere in
LilyPond.

At any rate, C++ conversion rules do not permit using two implicit conversions
in a row.  You need a cast or an intermediate assignment to get both.  So I
don't see what surprise we are supposed to get here.

[Dan Eble, 2015-06-30 00:49:33]

On 2015/06/30 00:30:15, dak wrote:
> I don't understand what you are trying to say here.  Apparently you are
arguing
> for the "explicit" keyword.  We don't use any C++11 feature elsewhere in
> LilyPond.

Explicit constructors were a feature before C++11.  It's explicit conversion
methods that are new.
 
> At any rate, C++ conversion rules do not permit using two implicit conversions
> in a row.  You need a cast or an intermediate assignment to get both.

Yes, I think you're right.  If I can remember the specifics of why the lack of
explicit worried me, I'll let you know.

[dak, 2015-06-30 01:02:31]

On 2015/06/30 00:49:33, Dan Eble wrote:
> On 2015/06/30 00:30:15, dak wrote:
> > I don't understand what you are trying to say here.  Apparently you are
> arguing
> > for the "explicit" keyword.  We don't use any C++11 feature elsewhere in
> > LilyPond.
> 
> Explicit constructors were a feature before C++11.  It's explicit conversion
> methods that are new.
>  
> > At any rate, C++ conversion rules do not permit using two implicit
conversions
> > in a row.  You need a cast or an intermediate assignment to get both.
> 
> Yes, I think you're right.  If I can remember the specifics of why the lack of
> explicit worried me, I'll let you know.

I vaguely remember that stuff could become a nuisance in connection with numeric
promotion rules because promotion might get combined with implicit conversion
(at least it could in ARM times: I'd have to reexamine the current standard to
see if that is still the case).

But there are no numeric types involved here.

I'll check whether SCM("name") works.  It's actually unlikely because even if
C++ was able to use two implicit conversions in a row, it would still have the
ambiguity of deciding between Scm_module ("name") and any Scm_variable<...>
("name") for doing the conversion.

[Dan Eble, 2015-06-30 01:16:10]

On 2015/06/30 01:02:31, dak wrote:
> I vaguely remember that stuff could become a nuisance in connection with
numeric
> promotion rules because promotion might get combined with implicit conversion

Aha.  One past experience involved a number-like class which could be
initialized by a double, and there were loads of cases where one would not want
an object of that class to be constructed by accident.

> I'll check whether SCM("name") works.  It's actually unlikely because even if
> C++ was able to use two implicit conversions in a row, it would still have the
> ambiguity of deciding between Scm_module ("name") and any Scm_variable<...>

And I think another experience involved overloaded functions where the
possibility of implicit construction introduced ambiguity, but my memory of this
one is very vague.

Neither one seems to be a problem with your change, although adding "explicit"
anyway shouldn't hurt.

[dak, 2015-06-30 08:15:02]

On 2015/06/30 01:16:10, Dan Eble wrote:
>
> Neither one seems to be a problem with your change, although adding "explicit"
> anyway shouldn't hurt.

Ok, I checked that neither in assignments nor initializations "ccc" goes to SCM,
and GCC does not even mention considering it: it just says that it cannot
convert const char * to SCM.  Neither does GCC consider the use of a const char
* as a function, and again the error message does not even mention considering
it.  So there does not appear to be _any_ actual improvement to be gained by
using "explicit" apart from feeling safer without reading through 3 chapters of
the standard.  Which _is_ a tangible benefit for the programmers if not the
program.

However, "shouldn't hurt" is nice, but we don't have "explicit" anywhere else in
our code base and it is probably C++98 or something, not "classic" C++.  That
always has a bit of a risk for crossbuilding LilyPond with GUB, or for others
compiling it with older or different compilers.  When using it because of the
presence of operator SCM, there would be several other unrelated classes which
should also be getting it.

So I'll leave this as a topic for a different issue.  It does not seem
necessary, carries some risk of problems of its own, and it would warrant using
across the board in our codebase, not just in this new addition.