[TCLCORE] TIP457 - [eatargs]

[Mathieu Lafon]

On Sun, May 21, 2017 at 3:06 PM, Alexandre Ferrieux
<alexandre...@gmail.com> wrote:
> Here's how I would [eatargs] it :-)
>
> proc log args {
> eatargs {{level -name level -switch {{debug 0} {error 3}} -default 1}
> {time -name {time timestamp}}
> {message} }
> ...
> }
>
> The variables can be thought of as populated by [eatargs] at runtime,
> though the CompileProc of [eatargs] will prepare their slots in the
> LVT.

Thanks Alexandre, I have a better idea of your alternate proposal.
This is somewhat similar to the 'Argument Parsing extension' approach
mentionned in the TIP (Cyan Ogilvie's paper).

It's still awkward for me to dissociate the argument specification
from the proc. New users may be confused by the fact that they should
declare their local variables in [eatargs] instead of [proc] if they
want to use extended specifiers.

Even with a separated command, the argument specification will
probably need to be linked to the proc in some way if we want
introspection and also probably to cache the parsing of the
specifiers.

-- Mathieu

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

On Sun, May 21, 2017 at 6:48 PM, Mathieu Lafon <mla...@gmail.com> wrote:
> On Sun, May 21, 2017 at 3:06 PM, Alexandre Ferrieux
> <alexandre...@gmail.com> wrote:
>> Here's how I would [eatargs] it :-)
>>
>> proc log args {
>> eatargs {{level -name level -switch {{debug 0} {error 3}} -default 1}
>> {time -name {time timestamp}}
>> {message} }
>> ...
>> }
>>
>> The variables can be thought of as populated by [eatargs] at runtime,
>> though the CompileProc of [eatargs] will prepare their slots in the
>> LVT.
>
> Thanks Alexandre, I have a better idea of your alternate proposal.
> This is somewhat similar to the 'Argument Parsing extension' approach
> mentionned in the TIP (Cyan Ogilvie's paper).

Yes, absolutely. And if memory serves, Steve Landers brought it forth
long before I did on this list.

> It's still awkward for me to dissociate the argument specification
> from the proc. New users may be confused by the fact that they should
> declare their local variables in [eatargs] instead of [proc] if they
> want to use extended specifiers.

Well, "new users" are also easily unsettled by many unusual features of Tcl.
Making it superficially resemble Python is not, IMHO, a good strategy
to attract quality programmers.
Keeping it true to its principles of a minimal grammar (only beaten by
early Lisp and Forth) works better.
My proposal tries to hit a compromise, keeping Tcl's spirit while
offering reasonable support for the idiom of the day.

> Even with a separated command, the argument specification will
> probably need to be linked to the proc in some way if we want
> introspection and also probably to cache the parsing of the
> specifiers.

Requiring that [eatargs] be at the beginning of the body (except for
comments) sounds like a simple yet efficient contract.
In addition to "optimistic parsing for sunny days", supporting static
analysis tools, there's also the obvious support for runtime
introspection: nothing prevents [eatargs], in its CompileProc, from
doing most of what you're currently doing. So, the local vars will
remain as fast as always, and [info younameit] can retrieve the
argspec as well.
Again, the idea is not *at all* to ditch your exemplary implementation
of arg-munging itself, just to change the way it is invoked: most of
your code would be reused.

-Alex

[Mathieu Lafon]

On Sun, May 21, 2017 at 10:48 PM, Alexandre Ferrieux
<alexandre...@gmail.com> wrote:
> Again, the idea is not *at all* to ditch your exemplary implementation
> of arg-munging itself, just to change the way it is invoked: most of
> your code would be reused.

I'm not firmly opposed to this change if this proposal is globally
rejected by TCT members and users, althought I still find it confusing
for users.

But as long as most TCT members have remained silent or neutral, I
don't know on which side the consensus can be. You are the only one
which has explicitely stated he would vote NO.

-- Mathieu

[Peter da Silva]

This would not satisfy the bounty because for small procs the overhead of an additional command would be too high.

[Colin McCormack]

Seems to me, Peter, that you could implement the call to ::eatargs' C implementation from within a new command, so the overhead would be negligible.  The additional benefit would be that other command forms could use the same arg protocol.

The only thing you wouldn't have is ::proc redefined before a ::rename.  Would that be a deal-breaker?

Colin

[Peter da Silva]

The original point to this proposal was that named arguments are a far more maintainable approach to program design than proc’s optional positional arguments. We have seen too many bugs in our code and other people’s code as well due to simply losing track of the number and order of optional arguments. There are few if any Tcl commands that use the syntax that proc encourages, and for good reason.

 

Implementing special case code for argument processing in C is lightweight and efficient, and it’s about as easy as implementing optional positional arguments... so where named arguments are easy to do they are overwhelmingly preferred.

 

So this proposal, to make it as easy and preferred as in C.

 

Adding overhead for this code, even the conceptual overhead of having to use a different proc command, will mean that the inefficient and buggy optional positional parameters will remain the default.

 

This has been brought up in the previous discussion on a number of occasions, but I will just re-iterate it. Improving proc to make procs a peer with native-C commands will be a game-changer and will, over time, massively improve the reliability and robustness of Tcl code.

[Colin McCormack]

Responses intercut,

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

The original point to this proposal was that named arguments are a far more maintainable approach to program design than proc’s optional positional arguments.

And indeed alternatives should be available.

We have seen too many bugs in our code and other people’s code as well due to simply losing track of the number and order of optional arguments.

Personally, I haven't suffered that problem.  I tend to prefer to keep the interfaces simple, and thereby avoid it.  I know that not everyone's code base is as easily refactorable.

There are few if any Tcl commands that use the syntax that proc encourages, and for good reason.

The tacit assumption being that Tcl commands can be expected to resemble procs in their calling signature?  I don't believe that assertion is well-founded.

 Implementing special case code for argument processing in C is lightweight and efficient, and it’s about as easy as implementing optional positional arguments... so where named arguments are easy to do they are overwhelmingly preferred.

I think Tcl should support many argument processing techniques.

 So this proposal, to make it as easy and preferred as in C.

You mean, I think, easy and preferred but completely *unlike* that of C, perhaps?

The proposal can make a single style easy, but clearly it can never *make* it preferred.  I doubt that trying to force people to prefer one particular style is unachievable. 

 Adding overhead for this code, even the conceptual overhead of having to use a different proc command, will mean that the inefficient and buggy optional positional parameters will remain the default.

Nobody *has* to use a different ::proc command ... not yet, anyway.

If ::FAProc is as beneficial as you contend, they will use it because they prefer it ... if your company wants to mandate it as the house-preferred style, they can use ::rename.  As long as ::proc stays as is, that will cause no problems.

 This has been brought up in the previous discussion on a number of occasions, but I will just re-iterate it. Improving proc to make procs a peer with native-C commands will be a game-changer and will, over time, massively improve the reliability and robustness of Tcl code.

I see no very useful useful definition of peer, as it applies to procs and C, in which proc isn't already a peer of C commands.

I don't mean there aren't differences, of course: Tcl is slower and Tcl procs generally have simpler signatures than C functions.

One way I can imagine ::FAProc commands coming to more closely resemble Tcl's C command implementations is that they will, should people actually adopt your preferred protocol, come to more often carry around a complex and noisy signature.

I really don't think this will change the game in the way you suggest.

Colin.

[Peter da Silva]

> You mean, I think, easy and preferred but completely *unlike* that of C, perhaps?

I don’t understand the point you’re making here. Are you misinterpreting my comment about Tcl commands implemented in C to be a comment on C syntax?

I would also repeat that the proposal does not impact existing procs in any way, and doesn’t change any existing use of the proc command. This was a long discussed, deliberated, and careful process that carefully avoids stepping on the existing proc syntax.

> I see no very useful useful definition of peer, as it applies to procs and C, in which proc isn't already a peer of C commands.

Indeed. That’s the problem.

[Colin McCormack]

"Peer" is such a nice word.  Susceptible to so many possible interpretations.  So many that I would be loathe to use it in the connection you have, lest I waltz myself into thinking something that was untrue, or at least unexamined.

Pardon my ignorance, what precisely *did* you mean by it?

Colin

[Colin McCormack]

On Mon, 22 May 2017, 22:30 Peter da Silva, <peter....@flightaware.com> wrote:

> You mean, I think, easy and preferred but completely *unlike* that of C, perhaps?

I don’t understand the point you’re making here. Are you misinterpreting my comment about Tcl commands implemented in C to be a comment on C syntax?

I guess I'm purposely conflating two things: that unlike the proc arg protocol, your proposal will exactly *not* resemble that of C, from which Tcl's is derived.

I am permitted that conflation, I think, because you were ambiguous in your use of "C", using the language to stand for the particular use to which it is put in Tcl C command implementations. 

I am suggesting that I consider that difference between what you propose to make "preferred" and what is *actually* available in C represents a loss to Tcl.

I would also repeat that the proposal does not impact existing procs in any way, and doesn’t change any existing use of the proc command. This was a long discussed, deliberated, and careful process that carefully avoids stepping on the existing proc syntax.

I am aware that the proposal side steps interference with existing ::proc.

> I see no very useful useful definition of peer, as it applies to procs and C, in which proc isn't already a peer of C commands.

Indeed. That’s the problem.

I don't believe it's been a problem in any of *my* code.  So I don't believe it can be *the* problem you refer to, but haven't really defined.

I actually doubt that the problem you have obliquely referred to is *the* problem you have, if this is your best shot at a solution.

Colin

[Joe English]

Mathieu Lafon wrote:
> On Sun, May 21, 2017 at 10:48 PM, Alexandre Ferrieux

> > Again, the idea is not *at all* to ditch your exemplary implementation
> > of arg-munging itself, just to change the way it is invoked: most of
> > your code would be reused.
>
> I'm not firmly opposed to this change if this proposal is globally
> rejected by TCT members and users, althought I still find it confusing
> for users.
>
> But as long as most TCT members have remained silent or neutral, I
> don't know on which side the consensus can be. You are the only one
> which has explicitely stated he would vote NO.

For what it's worth: TIP#457 revision 1.21 looks pretty good to me,
and I would vote for it in its current form.

(I've been staying out of the discussion, having little of
value to add, but will note that early on I shared many of the
concerns Colin recently raised. However, the TIP as currently
drafted addresses those concerns to my satisfaction, and --
somewhat to my own surprise -- it has my support. I think
it's a clear improvement over what we currently have in Tcl.)


--Joe English

jeng...@flightlab.com

[Alexandre Ferrieux]

On Mon, May 22, 2017 at 2:03 PM, Peter da Silva
<peter....@flightaware.com> wrote:
> This would not satisfy the bounty because for small procs the overhead of an additional command would be too high.

Since you're not quoting anything, I'll assume you're talking about
[eatargs] in general.
Now why would [eatargs] necessarily incur overhead beyond that of a
single bytecode instruction ? Is that what you call "too high" ? Given
the complexity of the arg-eating itself, that's pretty surprising.

-Alex