Re: Resolving standoffs (was: Naming question for get_property, set_property)

[Carl Sorensen]

On 4/13/20, 6:17 AM, "lilypond-devel on behalf of David Kastrup" 
<lilypond-devel-bounces+c_sorensen=address@hidden on behalf of address@hidden> 
wrote:

    David Kastrup <address@hidden> writes:
    
    > Han-Wen Nienhuys <address@hidden> writes:
    >
    >> On Tue, Feb 11, 2020 at 10:17 PM David Kastrup <address@hidden> 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