Re: [TCLCORE] There is no justification for modifying [proc] for named parameters

I forgot: increased implementation complexity of proc is the other
deoptimisation your proposal must obviously entail.  All the same defences
are available to you as for performance degredation.

I would expect any proposal such as yours to have considered and addressed
these issues.  I didn't expect that countering my critique would be onerous
if you had already considered them.

I certainly didn't think that politely raising some fairly obvious
objections could be called a "flame-war."  Not with a straight face, anyway.

Colin

On Sat, 20 May 2017, 20:11 Colin McCormack, <mcc...@gmail.com> wrote:

> Excuse me, Mathieu, but I'm not simply "against it.">> I have raised what I consider to be cogent criticisms of a proposed course> of action, and as far as I can tell you have addressed none of them.  I> sought to understand why our opinions differ about what is best.>> To denigrate my analysis as 'flaming' doesn't discredit it, and to fail to> meaningfully engage with it surely only undermines your proposal.>> I believe that you have misread the bounty's stated requirements, if you> believe that modifying [proc] is essential to satisfying them.>> Whence did the idea arise that distorting proc was the best way to add the> functionality you appear to desire, or desire to implement?>> Colin>> On Sat, 20 May 2017, 20:02 Mathieu Lafon, <mla...@gmail.com> wrote:>>> I don't want to enter a flame-war with you. I understand that you're>> against it and I completely respect your point of view but I don't>> think I will change your mind.>>>> I admit that I have failed to reach a consensus but please respect the>> work done and the opinion of the people who have supported the work.>>>> -- Mathieu>>>>>> On Sat, May 20, 2017 at 12:23 PM, Colin McCormack <mcc...@gmail.com>>> wrote:>> > Oh, and I think I may have misused "bisimulate" ... I meant that every>> CGC>> > form should be able to imitate every other so that it's impossible for>> the>> > caller to tell when one CGC-command has been substituted by another of>> > identical functionality simply by calling it.  They should all look the>> > same.  It matters.>> >>> >>> > On Sat, 20 May 2017, 19:46 Colin McCormack, <mcc...@gmail.com> wrote:>> >>>> >> Argh, I meant "in Tcl", of course.>> >>>> >>>> >> On Sat, 20 May 2017, 19:45 Colin McCormack, <mcc...@gmail.com> wrote:>> >>>>> >>> Well, of course it's an overhead, by definition.  Are you arguing that>> >>> it's insignificant, or that it's cost effective?>> >>>>> >>> On, now, to the next element of overhead, which you haven't dealt with>> >>> (here.  I haven't been following closely, I'm sorry if you have dealt>> with>> >>> it elsewhere) which is the *considerably* more complex>> documentation.  Not>> >>> significant?>> >>>>> >>> Finally, and for me this really would end the matter (I think it's>> just>> >>> that important), the loss of ability to bisimulate CGCs in Gcl.>> >>>>> >>> Colin.>> >>>>> >>>>> >>> On Sat, 20 May 2017, 19:39 Mathieu Lafon, <mla...@gmail.com> wrote:>> >>>>>> >>>> I have not said that there are no overhead in using the new extended>> >>>> specifiers, I have said that there are no overhead if the proc is not>> >>>> using them.>> >>>>>> >>>> A proc defined with extended specifiers is flagged so that it uses a>> >>>> different code path for locals initialisation. The original and>> >>>> optimized code path is still used for proc which are not flagged.>> >>>>>> >>>> If we're discussing the impact of the added flag check in the code, I>> >>>> admit that there is an impact on the generated compiled code but I>> >>>> will not call it an overhead.>> >>>>>> >>>> -- Mathieu>> >>>>>> >>>>>> >>>> On Sat, May 20, 2017 at 10:53 AM, Colin McCormack <mcc...@gmail.com>>> >>>> wrote:>> >>>> > Hi Mathieu,>> >>>> >>> >>>> > I don't believe you.  Anything which adds functionality to an>> >>>> > optimally>> >>>> > implemented proc must add overhead to it.  You might argue that>> proc>> >>>> > as>> >>>> > implemented is sub-optimal, in which case thank you for finding a>> way>> >>>> > to>> >>>> > optimise it.  You might argue that you cannot measure any>> difference>> >>>> > between>> >>>> > the optimal and the extended versions, in which case you need to>> >>>> > measure>> >>>> > more closely.  You might argue that the difference is>> insignificant,>> >>>> > or that>> >>>> > it's worth the cost, which begs the question of why using proc to>> >>>> > provide>> >>>> > the extension is significant or not worth the cost.>> >>>> >>> >>>> > If you're honestly arguing that you have two (otherwise identical)>> >>>> > pieces of>> >>>> > code, one of which implements a discriminator and one of which>> doesn't>> >>>> > and>> >>>> > the one which performs more computation does so with no additional>> >>>> > computation time, then either I have a fundamentally flawed view of>> >>>> > what>> >>>> > computation is, or you do.>> >>>> >>> >>>> > I simply cannot buy it.>> >>>> >>> >>>> > Colin.>> >>>> >>> >>>> >>> >>>> > On Sat, 20 May 2017, 18:09 Mathieu Lafon, <mla...@gmail.com>>> wrote:>> >>>> >>>> >>>> >> Hello Colin,>> >>>> >>>> >>>> >> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <>> mcc...@gmail.com>>> >>>> >> wrote:>> >>>> >> > This re-implementation will by its nature drag on proc, will by>> its>> >>>> >> > nature>> >>>> >> > slow proc definitions which don't use the extended facilities>> >>>> >> > specified>> >>>> >> > by>> >>>> >> > AFProc. This overhead would arise and be imposed for no good>> >>>> >> > reason, but>> >>>> >> > simply because the bounty was poorly phrased.>> >>>> >>>> >>>> >> You seems to assume that the implementation add an overhead on>> proc>> >>>> >> execution, especially for proc not using the new argument>> specifiers,>> >>>> >> but this is *not* the case.>> >>>> >>>> >>>> >> Please re-read the current TIP, look at the implementation or do>> your>> >>>> >> own testing, there is no performance issue.>> >>>> >>>> >>>> >> I have carefully ensured that proc, which are not using new>> argument>> >>>> >> specifiers, are not impacted in any way. On the opposite, users>> which>> >>>> >> replace their own Tcl-pure code handling named parameter by using>> the>> >>>> >> new specifiers will have a performance gain.>> >>>> >>>> >>>> >> I am perfectly aware that some people are against this proposal. I>> >>>> >> just hope that they do not have false or outdated assumptions on>> the>> >>>> >> subject, as many parts have changed since the initial proposal.>> >>>> >>>> >>>> >> That's why I'm currently requesting a vote, so that I can have a>> >>>> >> clear>> >>>> >> position of TCT members on whether this can go into core or>> whether>> >>>> >> this should be handled completely differently.>> >>>> >>>> >>>> >> Deciding whether this should be handled in proc or handled>> >>>> >> differently>> >>>> >> (new command, calling an extension inside proc, ...) is not>> something>> >>>> >> on which we can reach a consensus (at least I have clearly failed>> to>> >>>> >> achieve that). A decision has to be done.>> >>>> >>>> >>>> >> Regards.>> >>>> >>>> >>>> >> -- Mathieu>>>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot