On 2020/02/02 14:01:33, hanwenn wrote:
> https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm
> File scm/lily.scm (right):
>
>
https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm#newcode111
> scm/lily.scm:111: "This defines a variable @var{name} with the
starting value
> On 2020/02/01 21:37:50, dak wrote:
> > An interesting DOC string method... define-syntax doesn't have
anything like
> > that?
>
>
> no, doesn't look like it.
>
> I added all the GUILE repos I could find to cs.bazel.build, none of
the
> define-syntax uses seem to have doc strings. See
>
> https://cs.bazel.build/search?q=define-syntax%20f%3ascm%20&num=450
>
>
https://codereview.appspot.com/553480044/diff/557280043/scm/lily.scm#newcode123
> scm/lily.scm:123: (define-syntax define-session
> On 2020/02/01 21:37:50, dak wrote:
> > The problem with define-syntax is that in Guile-1.8, it doesn't work
properly
> > because of some symbol changing behavior when defined, a bug that
will not get
> > fixed any more. I wish I'd remember what it was. It was something
short like
> > \once or \temporary or so. One could use it in the LilyPond core,
but it
> failed
> > in user documents. Ah right: pretty sure it was \void (namely the
symbol
> 'void
> > being bound to something).
> >
> > That makes it hard for people to get acquainted with it and maintain
it in
> > consequence. So let's see whether we manage to muddle through in a
different
> > manner. Do you have a useful test case? Should I just draw out the
> > define-session thing and try to convince Guile-2.0 with the right
incantations
> > to byte compile it? I assume this is the same in Guile-2.2 (for
which I have
> an
> > Ubuntu package I don't need to compile)?
> >
> > Would this give us a chance to get somewhere?
>
> Please see Taylan's reply to the guile-devel list, which gives a
succinct
> explanation of why inner functions in macros can never work in the
Guile 2.x
> compiler. So we either forego compilation (at a 1.5 sec startup cost)
or we
> rewrite the macros to stop using inner functions.
That's what I am trying right now, but you cannot quote outer functions
as a value either (the problem is the value, not the innerness) so you
need to do it by name and I would like not to have to export it, so I
try with (@@ guile-user define-session-internal) but haven't found the
right incantation yet. Still fiddling. If it cannot be avoided, it
will end up as an exported define-session-internal .
> What is the problem precisely with void ? I assume that is not about
> define-session but for define-music-function, which looks like it has
a very
> complex macro expansion.
>
> Can you provide a repro scenario?
\void is used as a prefix when you want to evaluate something but not
have it used, like
\void \displayMusic { c' g' } without getting anything typeset.
There is no obvious issue per se, but the internals of define-syntax in
Guile-1.8 have a bug where it fails when 'void is defined. When you use
it in a .ly document with
#(define-syntax ...)
it fails with some obscure error. The problem may also be with
syntax-case: I don't remember the details, but it was quite obscure. I
don't know whether there are other potential symbols with the same
detrimental effects.
But basically the symptom was just that using define-syntax in a typical
manner from inside of a LilyPond document crashed with some error
completely unrelated to the actual input.
> Another option: we decide that as of LilyPond 2.21, you will need
GUILE 2.2 for
> LilyPond,
Reality check: LilyPond 2.21 will (hopefully) be out within several
weeks. We might change the basis sometimes _during_ 2.21 (namely in
time before 2.22) but the first 2.21 versions certainly will not depend
on Guile 2. Not least of all because 2.21.0 will already have far too
many changes for an unstable release. Cramming in another major change
should really happen at a later 2.21.x .
> and then we can rewrite the Scheme code without having to worry about
> G1.8 bugs. With the performance tuning on BDWGC, I think this a
viable strategy
> too.
I don't think performing a full-scale forced change that does not allow
us to benchmark the _difference_ is a good strategy. It would really be
useful to have some period during which either version would work.
As I said: the define-syntax bummer was .ly-level only, and if push
comes to shove, we could even rename \void . So there is no absolute
prohibition that I know of to use define-syntax in a .scm file outside
of the current parser module. It's just icky to use constructs not
allowed to the user.
https://codereview.appspot.com/553480044/
