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

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
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core