On 4/13/20, 6:17 AM, "lilypond-devel on behalf of David Kastrup"
<lilypond-devel-bounces+c_sorensen=byu....@gnu.org on behalf of d...@gnu.org>
wrote:
David Kastrup <d...@gnu.org> writes:
> Han-Wen Nienhuys <hanw...@gmail.com> writes:
>
>> On Tue, Feb 11, 2020 at 10:17 PM David Kastrup <d...@gnu.org> wrote:
>>
>>> > the reason being that it is better if the source code looks like plain
>>> C++,
>>> > even though they might actually be macros that do advanced magic.
Having
>>> > normal looking source code helps editors and tooling (astyle,
>>> clang-format)
>>> > make sensible decisions.
>>>
>>> get_property (pointer, "property")
>>> set_property (pointer, "property", value);
>>>
>>> would achieve that as well. Doesn't look like a member function, but
>>> the thing looking like a member function also never actually was one.
>>>
>>>
>> Earlier you said:
>>
>> "and for "reasons" I
>> need to know the type, so the call would become something akin to"
>>
>> how does this work for the above?
>
> decltype (*(pointer))
>
> Basically the macro does not need to know the type by name, just in some
> manner it can tell the compiler.
>
> For the current syntax ->get_property ("property") I just have no
> conceivable handle to get at the type of the pointer.
Well, it turns out that Han-Wen decided to veto this approach and
unilaterally changed the status of the respective patch from "Push" to
"Waiting". Now the problem with this kind of extensive restructuring
patch is that it becomes stale rather fast which is the reason why it is
not feasible to maintain them in parallel with ongoing development.
It looks to me like we have only two people who have weighed in on the patch:
the author (David K.) and one reviewer (Han-Wen). Since we have only two votes
(1 for, 1 against), there is no resolution.
I have been holding off comments, waiting to see where things go. I'd now like
to make my opinions known.
1) David has an excellent track record of making challenging things easier to
do by thinking carefully about the implications of potentially arbitrary
syntax. For example, the parser has been made more robust, and the scheme
interaction with the LilyPond parser has become much easier. Because David has
such an excellent track record in this regard, I am inclined to favor allowing
this patch.
2) Han-Wen believes that this syntax change is potentially bad for at least the
following reasons:
a) The approach "seems laborious"
b) The approach will make it hard to add new grob-properties at runtime
(David K. disagrees with this item -- in fact he believes it will force us to
provide a proper interface for registering user-added properties).
c) Uses more memory -- lots of bytes per Grob. David K. says it only uses
~500 bytes per Grob type, not per Grob.
d) Interferes with Guile 2 adoption. David K. says the current patch has no
effect on Scheme; further work on Scheme is in the future.
e) It's not necessary to make all these changes in the code base to do the
experiments that David K. wants to do.
3) Han-Wen has proposed that David's future development be based on a separate
branch, rather than master. Once the benefits are shown, Han-Wen has promised
to help merge the separate development branch into the mainline. David states
that working on stale code (diverged from master) for an indefinite period of
time is a significant hindrance to moving forward.
4) Although I'm recognized as a smart guy in my world, the events surrounding
this proposed change have demonstrated to me that the LilyPond project is
fortunate to have brilliant people working on it. I feel like I'm not even in
the same area code as Han-Wen and David. Thanks to both of you!
I think for me, the bottom line is that David has proposed a reason why the
proposed new syntax is better than the existing syntax. The reason is a little
bit vague to me, but I trust David in this kind of situation. Han-Wen has
identified some potential warning issues about the new syntax, to which David
has responded. The only issue that Han-Wen raises for which I'm not satisfied
an answer exists is item b) above. If this patch breaks something users
currently can do (adding new grob-properties at runtime) without providing
another facility to do so, I think that's a legitimate concern. On the other
hand, I think that David's proposed memoization is likely to be very useful.
David, do you agree that as it stands now, your patch precludes adding grob
properties at runtime? If so, would it be reasonable to add the infrastructure
for adding grob properties at runtime to this patch?
Han-Wen, do you agree that David has addressed your concerns about memory and
Guile2? If so, and he could resolve your concerns about adding grob properties
at runtime, would you be willing to accept this syntax change?
From where I stand, the only think keeping me from giving a LGTM is the
possible difficulty in adding new grob properties at runtime. But I don’t have
a clear sense of how significant that problem is.
Thanks,
Carl
Han-Wen did not propose an alternate syntax in that discussion. His
argument is that he wants the macro call to look more like a method
call, but a macro does not have the same information that the compiler
has, and this precludes experimentation with type-dependent
implementations of the part done by the macro.
That is not a problem according Han-Wen because he thinks he would not
be able to derive substantial benefits from that if he pursued that
approach.
That is kind of an uncommon objection and situation compared to the
previous decade of consensus-based development, so we have two questions
of which we need to answer at least one here:
a) what kind of syntax that would be acceptable to Han-Wen as well as
others and would allow developers to work with type-aware macro code for
the purpose of inlined property access would be feasible otherwise
b) in case where a consensus cannot be achieved after a reasonable
discussion, how do we arrive at a decision, possibly based on the
consequences.
In this case, we are talking about a large-scale cosmetic change in a
macro syntax call that opens up strictly more possibilities without
enforcing any particular implementation. That may make a difference for
finding a solution for this particular standoff, but the kind of
conflict and argument here suggests that there may also come future
occasions where we will have to decide how to deal with non-consensus
decisions in situations that are governed by significantly different
tradeoffs.
The relevant discussion partly is in the mailing list thread I now
followed up to and that started a few months ago, and in the Rietveld
issue at
<https://codereview.appspot.com/573670043>
The patch status changes and their justifications are at
<https://sourceforge.net/p/testlilyissues/issues/5882/>
--
David Kastrup
