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

[Valentin Villenave]

On Fri, Dec 2, 2011 at 1:05 AM, David Kastrup <address@hidden> wrote:
> The reason is that eval-string in Guile does not set
> port-line/port-filename to sensible values and I use them for making
> sensible error messages actually pointing to the source of the error.

What would be "sensible values" here? Does it imply that the standard
syntax documented in Guile's manual no longer apply here?

In other words: what concrete changes could make this work?

>> And in proper
>> REPL, non-embedded guile it does work.
>
> Of course it doesn't since #{ #} would not be defined.

... That not withstanding, of course.

> Should be quite easier now.

I don't doubt it. What I'd need is a few pointers as to how.

> Anyway, we are talking about a
> _development_ version.  The changes _all_ passed _all_ regression
> tests.  If you want to avoid breakage in development versions, you have
> two options:
> a) contribute regression tests for your use cases

We've talked about that, and I will indeed.

> c) make a proper bug report once things break for you

See above in the thread. How is my first post here not a valid bug report?

> Personally, I consider option
> d) Try to discredit work being done with ominous postings missing useful
>   information
> not helpful.  I understand that you are pissed off when your scores and
> work patterns (and apparently nobody else's) stop working.  You know how
> to keep this from happening in future.

I wish I knew. Not pissed off, though. I think I get what you've been
trying to achieve wrt LilyPond syntax and I have no doubt it is an
improvement compared to how we dealt with Scheme previously.

> If you are doing things nobody
> else does, it is your responsibility to commit appropriate regtests
> and/or participate in testing.  Trying to piss off others as
> compensatory treatment is not likely to create conditions making either
> yourself or others happier in the long run.

I have no intention of "pissing off" anyone, including you. (One of my
former messages did sound a bit rude, but that's merely because I
accidentally sent it too soon before elaborating on the issue I was
experiencing.)

> I pushed a fix to staging that just skips location data when Guile does
> not set it to useful values or types.  You don't need the ugly "display"
> in your code anymore, by the way.

I know. I just wanted to demonstrate something that *did* work
previously, and now doesn't.

If you think preserving location data is preferable, then by no means
should you change it only for my hacks to keep working. As I said, all
I'm asking for in that case would be a way to work around the new
behavior. (If at all possible.)

> So you are making an appeal to "everybody" to join into a campaign
> against "inconsistent" handling of "existing code", due to the bad
> disruptive things David does.  Why doesn't that existing code exist in
> the regtests?

That BS and I hope you know it. It is customary for me (and others) to
introduce my postings with "hi everbody", that doesn't make it a
campaign. And "disruptive" doesn't necessarily mean "bad". But it _is_
disruptive from where I'm standing (where I'm standing is: on top of a
pile of dirty, hackish code, and I haven't denied that once).

> Valentin, bugs will happen.  Using eval-string is actually bypassing the
> normal interplay of Scheme and Lilypond interpreters, and it is quite
> likely that there are much better ways for doing what you are doing.

There certainly are. Since I haven't been able (yet) to learn how to
do delayed evaluation in Guile (with hooks and everything), this is my
way of working around my limited skills so far.

> Since Guile does not bother providing useful location data, the error
> messages (when errors occur) will be close to useless.  They _always_
> were close to useless before the last batch of changes causing your
> problem.  They aren't anymore, but that will not help you when using
> eval-string since eval-string does not set them to useful values for
> some unfathomable reason.  Yes, this caught me on the wrong foot.

I (think I) get it. I used to assume lacking location data was just
normal in this kind of cases.
Do you think there could be proposals to be made upstream about that?
(i.e. fixing Guile itself instead of compensating within Lily?)

> Those should certainly be reported and fixed.  But I am also currently
> working on changes that will indeed be more disruptive to existing code
> relying on less than pretty or comprehensible behavior of Lilypond.

Oh. Though times ahead for me, then :-)

> They _will_ break existing complex code at the Scheme level even after
> all bugs are shaken out.  And for good reason.  And no convert-ly magic
> will be able to fix that.  Those changes will come with changes in the
> regtests and in Lilypond's Scheme code because of that.
> So be sure to participate in the feedback loop in a timely and
> productive manner.

Thanks for the heads-up. I guess there's be a lot of work involved for
Scheme-based frameworks compatibility (such as Nicolas' or Reinhold's,
even though their code certainly is cleaner than mine).

> I am pretty sure that you'll
> appreciate most changes for ongoing work and wish that they had been
> done earlier.  But if you really need complex documents meddling with
> Lilypond internals to stay working without change, there is no real
> option except keeping old versions of Lilypond around.

I don't mind changes, as long as they're documented and have as few
unfortunate side-effects as possible. For example, replacing # with $
whereever needed wasn't that big of a deal; what proved "disruptive"
in this case was the change in ly:parser-include-string behavior
(which you fixed), and in eval-string (which you seem to have
addressed, and I'm on my way to check it now). It turns out the
eval-string thing was done on purpose to preserve location data, but I
couldn't find the relevant documentation for this change (if there's
any).

Now, using old versions is also an option -- especially for now, since
we're talking 2-months old or so. Which is why there's no emergency
for you to deal with my specific issues, especially if there's more to
come. But if this conversation can lead to more regtests and a
smoother transition (if at all possible), then there's something to
gain for both of us, and for the community at large.

Cheers,
Valentin.