Quantcast

There is no justification for modifying [proc] for named parameters

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

There is no justification for modifying [proc] for named parameters

Colin McCormack-3
I don't think modifying [proc] to support a particular protocol for names args is a good idea.

I think the protocol [proc] currently has for args is sufficient and I don't think any extension of it is warranted, nor required by the Flight Aware Bounties [FABs].

I think that the challenges outlined by FABs would be amply met by defining a different command FAProc in C and packing whatever functionality is required into FAProc.

I think that the notion that [proc] needs to be extended (at a runtime cost and at documentation and implementation complexity cost) to cover a particular calling protocol is really a co-opting of the [proc] name, and not an addition of functionality.

I think that the remedy for "but I want *all* my proc to be FAProc" is [rename].  I am not aware of what, in the FABs, actually require proc to be pre-[renamed] as it were.

I am not aware of what benefit there is in adding processing cost to traditional proc, either for the users of FAProc or the users of proc.

I will now closely paraphrase the FABs to try to understand why redefining the verb proc might gain FlightAware (or anyone) anything substantive.

I paraphrase the FABs for clarity:

"A first class, high-performance, non-hackish way to do named parameters" which "must be first class, i.e. can't be a proc that wraps procs with a bunch of scaffolding" and a Named Parameter Protocol (example FAProc declaration given) which would 'replace' (traditional proc declaration given) and which is to be (and here's the kicker) "implemented as a first class thing in the Tcl code" and not to be implemented as "some proc that generates a proc or something lame like that"

The bounty is attracted to a "first class thing" which implements a names parameter protocol, which is not itself implemented as a call to proc 'or something lame like that' ... vague much?

Analysis:  any "first class thing" could be either a command or some kind of modification to the parser which applied only to calls to the proc command.  I'm going to assume the former, because the latter seems particularly poorly conceived.

It seems to me that the 'replace' part of the bounty specification is amply satisfied by [replace proc AFProc] and that the AFProc command, if implemented in C or some other method which is not "lame" would satisfy the bounty requirements.

The requirements of the bounty seem to have been reinterpreted somehow as an imperative to modify the implementation of proc.  They are not.

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.

Unless FA get to pay $10k to impose new overhead on every proc call ever, for no concomitant benefit, I think the idea of modifying [proc] to save FA (et al) the time it takes to run [rename] is a *very* bad idea.  I should state, clearly, that I don't think FA get to pay $10k to impose new overhead, nor that FA want that, nor that they would obtain any benefit at all from doing that ... I think they just got carried away with how implementing language extensions in Tcl is 'lame' (which I doubt) and forgot to properly specify what they mean by "first class thing."

I have no personal desire to prevent FA from getting their "first class Tcl thing" which isn't "lame like a proc", but I really don't feel any impetus to impose a FA performance load on every [proc] call so their requirements might be satisfied in what seems to be the lamest way possible.

Colin


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mathieu Lafon
Hello Colin,

On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3

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, <[hidden email]> wrote:
Hello Colin,

On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3
Erratum: clearly when I say 'computation time' when speaking of overhead, I should have said 'computation time or space.'

On Sat, 20 May 2017, 18:23 Colin McCormack, <[hidden email]> 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, <[hidden email]> wrote:
Hello Colin,

On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Alexandre Ferrieux
In reply to this post by Mathieu Lafon
On Sat, May 20, 2017 at 10:38 AM, Mathieu Lafon <[hidden email]> wrote:
> 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.

Though you already know my position (close to Colin's), I'll take this
opportunity to clarify the counter-proposal:

 - it clearly must be in C (thus reuse 99% of your impressive work)

 - it could either be proc-like (like Colin's FAproc) or a simpler
runtime handler ([eatargs $args] or even [eatargs] since [info level
0] introspection allows for it). My preference goes to the second
since it's simpler / less tentacular and works well with oo methods
and apply.

 - it would prefer, as a secondary goal, to have it as a bundled
extension like Thread and Tk rather than in the core, for a probation
period. Reason is twofold: (1) there's room for months of refinement
of the script-level API ; (2) its ubiquity might complicate
Tcl-to-other-lang translation. By "secondary goal" I mean I would
still vote YES (after reasonable arm twisting) if only the first two
goals were satisfied. Otherwise, as it stands, it is NO.

-Alex

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3

I think the [eatargs] thing is fine, and clearly FAProc could trivially be implemented in terms of it.

A real show-stopper for me with the "let's extend proc" approach (if I had any actual say in the matter of what Tcl as implemented becomes, which I don't) is that [proc] as [FAProc] becomes radically dissimilar to all the other command-generating commands [CGCs].

If the fundamental script-level CGC is no longer able to simulate, or be simulated by, the others then Tcl loses enormously.

Colin


On Sat, 20 May 2017, 18:42 Alexandre Ferrieux, <[hidden email]> wrote:
On Sat, May 20, 2017 at 10:38 AM, Mathieu Lafon <[hidden email]> wrote:
> 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.

Though you already know my position (close to Colin's), I'll take this
opportunity to clarify the counter-proposal:

 - it clearly must be in C (thus reuse 99% of your impressive work)

 - it could either be proc-like (like Colin's FAproc) or a simpler
runtime handler ([eatargs $args] or even [eatargs] since [info level
0] introspection allows for it). My preference goes to the second
since it's simpler / less tentacular and works well with oo methods
and apply.

 - it would prefer, as a secondary goal, to have it as a bundled
extension like Thread and Tk rather than in the core, for a probation
period. Reason is twofold: (1) there's room for months of refinement
of the script-level API ; (2) its ubiquity might complicate
Tcl-to-other-lang translation. By "secondary goal" I mean I would
still vote YES (after reasonable arm twisting) if only the first two
goals were satisfied. Otherwise, as it stands, it is NO.

-Alex

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mathieu Lafon
In reply to this post by Colin McCormack-3
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 <[hidden email]> 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, <[hidden email]> wrote:
>>
>> Hello Colin,
>>
>> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3
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, <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> wrote:
>>
>> Hello Colin,
>>
>> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3

Argh, I meant "in Tcl", of course.


On Sat, 20 May 2017, 19:45 Colin McCormack, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> wrote:
>>
>> Hello Colin,
>>
>> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3

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, <[hidden email]> wrote:

Argh, I meant "in Tcl", of course.


On Sat, 20 May 2017, 19:45 Colin McCormack, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> wrote:
>>
>> Hello Colin,
>>
>> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mathieu Lafon
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 <[hidden email]> 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, <[hidden email]> wrote:
>>
>> Argh, I meant "in Tcl", of course.
>>
>>
>> On Sat, 20 May 2017, 19:45 Colin McCormack, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]>
>>>> 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, <[hidden email]> wrote:
>>>> >>
>>>> >> Hello Colin,
>>>> >>
>>>> >> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]>
>>>> >> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3

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, <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> wrote:
>>
>> Argh, I meant "in Tcl", of course.
>>
>>
>> On Sat, 20 May 2017, 19:45 Colin McCormack, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]>
>>>> 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, <[hidden email]> wrote:
>>>> >>
>>>> >> Hello Colin,
>>>> >>
>>>> >> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]>
>>>> >> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3

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, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> wrote:
>>
>> Argh, I meant "in Tcl", of course.
>>
>>
>> On Sat, 20 May 2017, 19:45 Colin McCormack, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]>
>>>> 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, <[hidden email]> wrote:
>>>> >>
>>>> >> Hello Colin,
>>>> >>
>>>> >> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]>
>>>> >> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3

*degradation


On Sat, 20 May 2017, 20:24 Colin McCormack, <[hidden email]> wrote:

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, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> wrote:
>>
>> Argh, I meant "in Tcl", of course.
>>
>>
>> On Sat, 20 May 2017, 19:45 Colin McCormack, <[hidden email]> 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, <[hidden email]> 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 <[hidden email]>
>>>> 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, <[hidden email]> wrote:
>>>> >>
>>>> >> Hello Colin,
>>>> >>
>>>> >> On Sat, May 20, 2017 at 5:11 AM, Colin McCormack <[hidden email]>
>>>> >> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Kevin Kenny-6
In reply to this post by Colin McCormack-3
On 05/20/2017 04:53 AM, Colin McCormack 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.
>

In an ideal implementation of this, the overhead, for procs that do not
use the new functionality, will be all in proc definition, not proc
execution.

Since proc definition is a vanishingly rare event compared with churning
away in inner loops, I expect that for typical scripts the overhead will
not be measurable.

It would appear that Mathieu thought that you were speaking of
execution-time overhead.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mathieu Lafon
In reply to this post by Colin McCormack-3
Colin,

My intent was not to denigrate your analysis but to try to calm things
down. Sorry for having triggered the opposite...

We have a disagreement on how this should have been implemented. I
have chosen to modify proc argument specifiers after having proposed
other options (including a dedicated command to call a proc :
http://www.tcl.tk/cgi-bin/tct/tip/view/457?ver=1.7) and received
feedback in that way. The initial FA bounty description was requiring
that it must work with unmodified proc, so the spirit of the bounty
seems to favor keeping proc and not adding a separate command.

Having chosen to modify proc, this implies impact on code, performance
and documentation, which I have tried to keep minimal, but are
inherent to that decision. I have carefully ensured that the new code
is well separated so that it is easy to review and maintain and that
the proc not using extended specifiers are not impacted in any way.

Regarding the two proposals made by Alexandre :

- Adding a new FAproc command will require to duplicate a lot of code
already present in proc, leading to more maintenance. Users may find
confusing to have a separate command and new users may not find it.

- Adding a runtime handler seems to be limited to argument parsing,
where the current proposal is a base framework which can be easily
extended to later support other usecase on proc arguments (type
assertion, doc-string, ...). Unless I don't get the intent, it seems
necessary to specify the named arguments when calling the command.
Users may find counter-intuitive to have to specify the arguments in a
second time (I assume proc only use 'args' in that case).

I don't have any strong positions on any alternate proposal, I only
want to give my current proposal a chance to be considered.

-- Mathieu


On Sat, May 20, 2017 at 12:41 PM, Colin McCormack <[hidden email]> 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, <[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3
In reply to this post by Kevin Kenny-6


On Sat, 20 May 2017, 23:32 Kevin Kenny, <[hidden email]> wrote:

In an ideal implementation of this, the overhead, for procs that do not
use the new functionality, will be all in proc definition, not proc
execution.

I would hope that's the case here.


Since proc definition is a vanishingly rare event compared with churning
away in inner loops, I expect that for typical scripts the overhead will
not be measurable.

I agree with you that for many (probably most) scripts the definition of procs is vanishingly rare.  It follows that any reasonable overhead in the service of a desired facility in defining a command is probably warranted.

This argument is a more effective argument in favour of writing FAProc in Tcl than it is to extend proc.  That someone finds such an implementation 'lame' is no argument at all for modifying proc.

It would appear that Mathieu thought that you were speaking of
execution-time overhead.

I see.  Thank you for interpreting his misunderstanding to me.

Colin


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3
In reply to this post by Mathieu Lafon


On Sat, 20 May 2017, 23:36 Mathieu Lafon, <[hidden email]> wrote:
Colin,

My intent was not to denigrate your analysis but to try to calm things
down. Sorry for having triggered the opposite...

We have a disagreement on how this should have been implemented. I
have chosen to modify proc argument specifiers after having proposed
other options (including a dedicated command to call a proc :
http://www.tcl.tk/cgi-bin/tct/tip/view/457?ver=1.7) and received
feedback in that way. The initial FA bounty description was requiring
that it must work with unmodified proc, so the spirit of the bounty
seems to favor keeping proc and not adding a separate command.

I am blissfully unaware of the orifinal terms of the bounty, but as I read it now there is absolutely no requirement that proc be modified.

I am also really dismayed that one might be able to bid for mods to core commands.

Having chosen to modify proc, this implies impact on code, performance
and documentation, which I have tried to keep minimal, but are
inherent to that decision. I have carefully ensured that the new code
is well separated so that it is easy to review and maintain and that
the proc not using extended specifiers are not impacted in any way.

I have no reason to cast aspersions on your code.  I merely seek to criticise your quite arbitrary choice to modify proc to insert functionality like this.


Regarding the two proposals made by Alexandre :

- Adding a new FAproc command will require to duplicate a lot of code
already present in proc, leading to more maintenance. Users may find
confusing to have a separate command and new users may not find it.

I don't believe code is ever required to be duplicated.  Refactoring proc so as to expose an interface which FAproc can use would always be an option.

- Adding a runtime handler seems to be limited to argument parsing,
where the current proposal is a base framework which can be easily
extended to later support other usecase on proc arguments (type
assertion, doc-string, ...).

Since the proposal was, I believe, to implement named arguments, I can well understand why one would expect it to be limited to argument handling.

Unless I don't get the intent, it seems
necessary to specify the named arguments when calling the command.
Users may find counter-intuitive to have to specify the arguments in a
second time (I assume proc only use 'args' in that case).

It sould be possible (I think trivial) to use such a handler to implement FAProc in all its glory and wonder, however it's conceived or the concept evolves.

I don't have any strong positions on any alternate proposal, I only
want to give my current proposal a chance to be considered.

Well, I considered it, and I think changing proc so its resultant command no longer resembles those of apply, namespace ensemble, interp, coroutine etc is a great mistake.

Colin


-- Mathieu


On Sat, May 20, 2017 at 12:41 PM, Colin McCormack <[hidden email]> 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, <[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Andreas Leitgeb
In reply to this post by Colin McCormack-3
Colin McCormack <[hidden email]> wrote (mix of some mail)
> I am also really dismayed that one might be able to bid for mods to core
> commands.

The bid may have been motivation for mlafon to spend his time to fine-design
and implement it, but it has not more impact on TCT's decision, than a mere
suggestion of someone. IOW, you can bid someone to implement something, but
you cannot "bid something into the core".

> I have no reason to cast aspersions on your code.  I merely seek to
> criticise your quite arbitrary choice to modify proc to insert
> functionality like this.

This looks really strange, Colin: you write you wouldn't want it in the
core "for it would then have proc interfaces be different from apply's
or OO-method's."  The opposite is true: if the named arguments were done
as a separare faproc, *then* faproc-generated commands would be singly
more powerful than plain proc/apply/methods.

The current implementation is done at a level so that apply and oo-methods
also benefit for free from it, just like proc, so most (if not all) of
these CGC would still be equivalent!  And then they're also a step closer
towards equivalence to what standard compiled commands do.

That the TIP also covers apply and oo-methods has been repeatedly stated
here...


Another more fundamental aspect of TIPs in general:
A TIP is a proposal, with the author's intention to "improve Tcl".

Apparently, there is not always a consensus about whether something *is*
an improvement or not,  but it makes no sense at all to say: "but you
could do some of it in <this-roundabout-way> or <that-roundabout-way>."
The very point of a TIP is, that the respective author is *not* fine
with the workarounds, and *therefore* suggests a change to *improve*
Tcl towards *not* needing the workarounds.

Without "improvements" we still wouldn't have $var, {*}-expansion,
and maybe "proc" itself would be an extension to download and compile
separately...


> I don't believe ...

and discussions here would be more compact, if some of these beliefs or
disbeliefs were checked against facts before being thrown in as arguments.

Even if FA's bounty *could* be met with a different solution, then this
TIP proposes a particular solution, and this solution shall be judged,
or an alternative proposal made (if the objective is agreed but only the
approach disapproved).

That "FA demands introspectability" is not the only point against some
parseargs-approach. The point is rather that introspection *is* a worthy
concept to care for. And FA just added it as a condition, as they appa-
rently didn't fancy a half-a..ed solution - neither would I.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Colin McCormack-3
I see now why mlafon was anxious about a flamefest arising - enter the co-sponsor, and now it's like some tag-team of issue-avoidance.

If nothing else comes out of this discussion, I would hope it's the distinction between a command improvement (which Andreas et al argues this is) and a Tcl improvement (which I argue it is not.)

Responses intercut below.

On Sun, 21 May 2017, 01:47 Andreas Leitgeb, <[hidden email]> wrote:
Colin McCormack <[hidden email]> wrote (mix of some mail)
> I am also really dismayed that one might be able to bid for mods to core
> commands.

The bid may have been motivation for mlafon to spend his time to fine-design and implement it, but it has not more impact on TCT's decision, than a mere suggestion of someone. IOW, you can bid someone to implement something, but you cannot "bid something into the core".

It was a throw-away line on my part, but I think it's worth saying.  There's no allegation of corruption, merely a recognition that the TCT votes on TIPs, but the specifier of TIPs specifies mods.

A major problem of this TIP is that it exploits the fact that the ::proc argument protocol [PAP] is very loose, by restricting it and imposing consequential and potential incompatibility on *every* PAP forever after.

To improve Tcl, this TIP doesn't have to be merely an Improvement to PAP as implemented by ::proc, it has to be the best *possible* improvement to PAP, because it modifies a fundamental command and thereby forecloses on a presumably infinite number of possible future PAPs.

That's a heavy responsibility which the TIP doesn't seek to rise to.

The first TIP that restricts any fundamental Tcl command like this is also the last one.

By paying to restrict ::proc, one selects which possible ::proc-restriction will drive out any other possible proc restriction.  In this case, one bids a modification into the core which is *not* materially entailed by the stated specified requirements.  It's a land-grab, where the real estate occupied is the name ::proc.

> I have no reason to cast aspersions on your code.  I merely seek to
> criticise your quite arbitrary choice to modify proc to insert
> functionality like this.

This looks really strange, Colin: you write you wouldn't want it in the
core "for it would then have proc interfaces be different from apply's
or OO-method's."  The opposite is true: if the named arguments were done as a separare faproc, *then* faproc-generated commands would be singly more powerful than plain proc/apply/methods.

I think Alexandre's counter-proposal for a generic arg-handler at runtime is better for precisely that reason.  Any user of the other CGCs  could elect to follow FA's arg protocol [FAP] if the author wished.

I think that, if given the option to include FAP, most authors probably wouldn't, but this TIP takes away even that choice.

The current implementation is done at a level so that apply and oo-methods also benefit for free from it, just like proc, so most (if not all) of
these CGC would still be equivalent!  And then they're also a step closer
towards equivalence to what standard compiled commands do.

Oh!  So the TIP modifies *all* CGCs?  I was unaware of that, from reading it.  That's troubling. 

That the TIP also covers apply and oo-methods has been repeatedly stated
here...

I read the TIP just then, I didn't see that stated.  What of all the other CGCs?  Is your argument against fragmenting the arg protocols in the manner I mention seriously that you're proposing to change a larger subset of them than I'd realised?

Another more fundamental aspect of TIPs in general:
A TIP is a proposal, with the author's intention to "improve Tcl".

Apparently, there is not always a consensus about whether something *is* an improvement or not,  but it makes no sense at all to say: "but you
could do some of it in <this-roundabout-way> or <that-roundabout-way>."
The very point of a TIP is, that the respective author is *not* fine
with the workarounds, and *therefore* suggests a change to *improve*
Tcl towards *not* needing the workarounds.

And of course the problem with any improvement is that if it forecloses other changes it can be a local maximum.  Instead of proposing a new CGC with a new name which has extra options, this proposal coopts the name ::proc to include those options.

Is this the best of all possible ::procs?  I doubt it, but I don't know, and I see no evidence in the TIP that the authors have considered that weighty question.

That a given author has elected to implement their proposed command improvement in a certain way is really no guarantee that the improvement couldn't be improved.

I see absolutely no argument even attempted that the arbitrary choice to modify ::proc in (a way which practically cannot be reversed) is necessary, or desirable, or minimal or an improvement to Tcl (although any increase in functionality of a given command can be trivially be construed as an improvement to that command.)

The *only* justification I have seen for the choice to mod ::proc, rather than to create a new CGC is that FA paid for just that (and, incidentally, I see no evidence for that in the bounty specification.)

Such a major change to a fundamental command in Tcl isn't so much a design choice, in my opinion, as a fundamental mistake.

Without "improvements" we still wouldn't have $var, {*}-expansion,
and maybe "proc" itself would be an extension to download and compile
separately...

Those were genuine improvements, and *much* more consideration was given to their Tcl-wide effects than has been given to this.

Moreover: {*} went through rapid revision from {expand}, demonstrating that its authors were flexible enough to reconsider their initial design choices when presented with better ones (see Alexandre's counter-proposal.)

If I were you, I wouldn't cite $var in support of your radical language mod, because it too easily leads to a discussion about $() and WTF is between those parentheses.

> I don't believe ...

and discussions here would be more compact, if some of these beliefs or
disbeliefs were checked against facts before being thrown in as arguments.

That's almost a tautology, no?

I don't know that 'compact discussion' is really the highest good when addressing radical language modification, lest it turn out to be mutilation, unless of course one stands to directly benefit from speedy resolution.

Even if FA's bounty *could* be met with a different solution, then this
TIP proposes a particular solution, and this solution shall be judged,
or an alternative proposal made (if the objective is agreed but only the
approach disapproved).

As an aside, I would like to have seen "the objective" defined more clearly and with less of the "or something lame like that" verbiage, which seems like dog whistling, and which isn't susceptible to rational analysis (but I repeat myself.)

If you're really maintaining that the objective is specified, you might be kind enough to direct me to where the objective of modifying ::proc is specified as a requirement, and where it's justified over the available alternatives.

That "FA demands introspectability" is not the only point against some
parseargs-approach. The point is rather that introspection *is* a worthy
concept to care for. And FA just added it as a condition, as they appa-
rently didn't fancy a half-a..ed solution - neither would I.

I missed that specification/demand.  Perhaps you could point me to it.

Colin


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
123
Loading...