lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 5310: find_top_context () maintenance (issue 341150043 by addr


From: dak
Subject: Re: Issue 5310: find_top_context () maintenance (issue 341150043 by address@hidden)
Date: Sun, 22 Apr 2018 06:37:49 -0700


https://codereview.appspot.com/341150043/diff/1/lily/context.cc
File lily/context.cc (right):

https://codereview.appspot.com/341150043/diff/1/lily/context.cc#newcode723
lily/context.cc:723: find_top_context (Context &where)
On 2018/04/22 13:19:45, Dan Eble wrote:
On 2018/04/21 20:58:32, dak wrote:
> And it was simpler to understand and debug.

The opposite sense is deeply ingrained in me.

But not in the LilyPond code base.  It does not pass Scheme-able values
with identity by reference as a rule.  Part of the reason is that the
identity can be verified by pointer comparison, and that is what eq?
does in the Scheme world.  In Scheme, pointers are a basic mechanism for
passing information and ensuring identity.  Changing pointers in an
irregular pattern to references is breaking a direct relation between
value and identity handling between C++ and Scheme, a relation that
actually is relevant for the Boehm GC method used in Guile 2.0 for
dealing with garbage collection.

Exactly because we do things consistently so far and don't pass Scheme
objects with identity by reference, your example is not to the point: it
would rather be

if (Context *c = find_whatever(...)) { a(p); b(p); c(p); }

So again I don't see what problem you are trying to solve.  Particularly
since the interface between SCM and C++ involves using pointers and then
converting into references via *p seems spurious and only looks as if
there cannot be null pointers.

Basically you want to abuse reference notation as some kind of value
passing contract, mixing up semantics and syntax in the process.

https://codereview.appspot.com/341150043/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]