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

I haven't, and you're right: I was wrong in thinking that there was an
execution overhead.

Colin.

On Mon, 22 May 2017, 21:13 Peter da Silva, <pete...@flightaware.com>
wrote:

> I guess you haven’t been following the discussion. For procs not using the> new syntax there is no increase in overhead. The new syntax has been> carefully designed to not conflict with existing procs in any way. Unless> an argument has three or more elements the new code will never be called at> any point.>>>> *From: *Colin McCormack <mcc...@gmail.com>> *Date: *Friday, May 19, 2017 at 10:11 PM> *To: *Tcl Core List <tcl-...@lists.sourceforge.net>> *Subject: *[TCLCORE] There is no justification for modifying [proc] for> named parameters>>>> 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