| Store | Cart

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

From: Colin McCormack <mcc...@gmail.com>
Sat, 20 May 2017 10:41:12 +0000
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
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core

Recent Messages in this Thread
Colin McCormack May 20, 2017 03:11 am
Mathieu Lafon May 20, 2017 08:38 am
Colin McCormack May 20, 2017 08:53 am
Colin McCormack May 20, 2017 08:58 am
Mathieu Lafon May 20, 2017 10:09 am
Colin McCormack May 20, 2017 10:15 am
Colin McCormack May 20, 2017 10:16 am
Colin McCormack May 20, 2017 10:23 am
Mathieu Lafon May 20, 2017 10:31 am
Colin McCormack May 20, 2017 10:41 am
Colin McCormack May 20, 2017 10:54 am
Colin McCormack May 20, 2017 10:54 am
Mathieu Lafon May 20, 2017 02:06 pm
Colin McCormack May 20, 2017 02:53 pm
Alexandre Ferrieux May 21, 2017 12:01 am
Colin McCormack May 21, 2017 01:16 am
Colin McCormack May 21, 2017 02:04 am
Mathieu Lafon May 21, 2017 11:27 am
Alexandre Ferrieux May 21, 2017 01:06 pm
Kevin Kenny May 20, 2017 02:01 pm
Colin McCormack May 20, 2017 02:39 pm
Colin McCormack May 20, 2017 11:58 pm
Alexandre Ferrieux May 20, 2017 09:12 am
Colin McCormack May 20, 2017 09:45 am
Peter da Silva May 22, 2017 11:42 am
Colin McCormack May 22, 2017 12:05 pm
Messages in this thread