Re: New read/eval Scheme syntax inconsistent in handling existing code

[Valentin Villenave]

On Sun, Dec 4, 2011 at 9:38 AM, David Kastrup <address@hidden> wrote:
> Apart from the rest of this ugly contraption,

You mean, uglier than using eval-string? I'm not sure what a less ugly
way of doing that would look like. (Perhaps using hooks, but I have
yet to master that.)

> there is no reason
> whatsoever why you are calling the _internals_ of making music functions
> here instead of define-music-function itself.

Absolutely none whatsoever. That was pure uncalled-for geekness from
me (at the time, it also allowed me to learn more about the
music-function internals).

> Yes, I changed the internals because the internals needed more
> information.  But the user API remained identical, and I don't
> understand why you don't use it.  It's not like things get simpler when
> you sidestep the documented API.

They sure don't. (And I'm not complaining about that.)

> This is ridiculous.  Now you use the API.  What makes you think
> eval-string is necessary for using define-music-function?

It isn't. defmacro certainly is a cleaner way to do it. That was just
to show you an example of a case where eval-string was useful to me,
re. our previous conversation.

> $ takes a look at the type of the enclosed
> expression and creates a token of the appropriate type in the input
> stream.  The type of the enclosed expression is *unspecified* so nothing
> gets inserted into the input stream by the lexer and the parser is
> completely unimpressed.

OK.

> Or put differently: the principal difference of # and $ is that $
> interprets the resulting expression and generates a token corresponding
> to its type (or in this particular case, none at all).  The premature
> evaluation is a _side-effect_ of this difference.

Thanks. I think I get it now. I was confused between the _LilyPond_
parser and the guile interpreter; when you said $(...) expressions
were evaluated instantly I misunderstood and thought you were
referring to the former.

> If would appear that you consider the side-effect more important than
> the main effect, and have for that reason decided to be smarter than
> convert-ly and replace # everywhere with $.

Well, you have to take into account where we come from: I'm not used
to convert-ly being smarter than me :-)

> Yes, if you write code relying on temporary insanities of Lilypond's
> implementation and on meddling with internals, my work on Lilypond will
> be disruptive to your document base.

Which is exactly what's happening here. And again: not once have I
been advocating that your work should be reverted back and thrown
away.

> Looks like we have lots of fun ahead.  Do me a favor and from time to
> time add material to Lilypond's documentation that would have helped you
> avoid this kind of lock-in hack programming.  Once you know how to avoid
> it.

That's the whole point of our conversation so far: I've already
identified two eligible regtests (the ly:parser-include-string thing
and the eval-string thing). And of course I have no other intention
but to document everything I can.


On a totally unrelated note (since we're talking about Scheme
evaluation), if I may quote a question that I discussed privately with
Neil last year:

On Mon, Dec 6, 2010 at 6:31 PM, Neil Puttock <address@hidden> wrote:
> This caught my eye:
> http://git.savannah.gnu.org/cgit/opus-libre.git/commit/?id=f149327afc41d869e34c29cf32b415254542ca9e
>
> I don't think there's any way around this unless you make all the
> defines procedures, though in some cases this might be a good thing
> since some of them are going to be evaluated immediately the file is
> loaded.  For example, in the following code, `foo' isn't a procedure:
> it's called immediately Guile sees it.
>
> (define bar '(hello))
> (define foo (if (pair? bar) (display "Hello World!")))
>
> This reminds me of the problem we have with identifiers: how can we
> document them automatically?  A really ineffecient method would be to
> keep an alist handy with (key . docstring) pairs, but I think the only
> way around this would be to extend the use of \description (though
> this would require all identifiers to be sequential blocks, e.g.,
>
> hideNotes =
> {
>  \description "..."
>  ...
> }
>


Cheers,
Valentin.