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

I'm doing a bit of language-lawyering over
https://github.com/flightaware/Tcl-bounties ... which I presume is the
canonical FA Bounty.  I think I see the source of the confusion about
::proc.

In item "A first class, high-performance, non-hackish way to do named
parameters" the first line is "Invoke a proc by naming the variables and
their values rather than doing it positionally."

Right out of the gate, it's a mess.  The problem here is that you can't
"invoke a proc" in Tcl, you can only invoke a command.  I reckon there's
the source of the confusion.

I'm going to suppose that they didn't mean "invoke a proc" (which isn't
possible in any extant definition of ::proc) but "create a command which
can be invoked by naming the variables and their values rather than doing
it positionally".  That's kinda clearer.  I guess they meant, too, that the
creation of a command is meant to be by way of associating a Tcl script
with a command's name.  I would suppose, item "Needs to be natural and
"native Tcl" like for the caller" softly implies that whatever mechanism
resembles ::proc's definitional form, that it looks like ::proc ... that'd
be the simplest interpretation.

Now ... I think it's most likely that the initially ill-defined requirement
"invoke a proc" has been misinterpreted in the least destructive manner
possible while failing to properly distinguish between "a command" and "a
proc", and that this misinterpretation has been carried on and expanded in
meaning to become a supposed imperative to redefine ::proc.  That's an
obvious problem with reasoning from a contradiction, you can deduce
anything you like.

Anyway, can we dispense with the assertion that the bounty
requires/mandates ::proc modification, and conclude that it's just what the
authors chose to do?  Can we, further, surmise that the misinterpretation
as a requirement mislead them to consider only this approach and discount
other approaches? Can I posit that as a consequence, we've ended up with an
ill-considered design and a flawed proposal?

Colin

On Sun, 21 May 2017 at 10:46 Colin McCormack <mcc...@gmail.com> wrote:

> I really think your counter-proposal is best, Alexandre.  It achieves the> stated goal, it trivially permits a parallel ::proc (I have been calling> ::FAProc) and it imposes *nothing* on any part of Tcl.  It genuinely> improves Tcl, rather than putatively improving a single command.>> I have repeatedly asked what justification exists for modifying ::proc> over the ::FAProc or ::eatargs counter-proposals.  None is forthcoming.>> In my dark moments I fear that the reason the alternatives are resisted is> precisely because they renders this command putative-improvement optional,> and on some level its proponents understand that there are a slew of> packages available to do what they're proposing, and people don't use them> ... and probably not because those implementations have substantial> overheads.>> In my more forgiving moments, I consider it's just possible (particularly> in terms of the "like it or lump it" responses to suggestions) that the> authors have just fallen into myopic value-rigidity, having written> something at considerable expense to ape and extend ::proc, they are wedded> to the particular implementation choices they've made.  That's> understandable, it's human, I do it all the time.>> There's another possibility, I don't know what to think about it, that the> ::proc-mod has been commissioned - that it's a stated/explicit or even> implicit/dog-whistled requirement of the FA bounty.  I really don't know> what to think about that, if so.>> Anyway, absent a justification, I can't help but speculate about what> seems to be an irrational decision.  I hope, though, my objections to it> are reasonable and not equally irrational.>> Colin>>> On Sun, 21 May 2017 at 09:31 Alexandre Ferrieux <> alex...@gmail.com> wrote:>>> On Sat, May 20, 2017 at 4:06 PM, Mathieu Lafon <mla...@gmail.com> wrote:>> > 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 concur with Colin's answer to this: appropriate refactoring may>> avoid any duplication. But never mind, as stated, this is not my>> preferred choice.>>>> > - 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, ...).>>>> Yes, and to me this lack of ambition is a bonus. Think KISS principle.>> Do one thing at a time, and do it right. Don't open a Pandora box on>> vague promises.>> In this specific case:  type assertions and doc strings can quite>> easily fit in handlers too, or in formatted comments at the top of the>> proc's body.>>>> >  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).>>>> Please give an example, I'm lost. You may even give a hefty list of>> them, as an exercise for me to map to [eatargs] form :)>>>> -Alex>>>

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