Re: [TCLCORE] namespace resolution of srcCmd in "interp alias"

[Dipl. I. S. G. B. <se...@us...>]

 

_[interp alias]_ creates an alias which never considers current
namespace during the creation of alias "command". 

It is just alias for given interpreter _srcPath_ to some command in the
another interpreter _targetPath_.
Even if the srcPath identifies current interpreter (e. g. is empty),
it'll never consider namespace of some frame of this interpreter by the
creation. 

Thereby, as documentation says, _srcCmd_ gives the name of a new
command, which will be created in the source interpreter (specified with
_srcPath_). It would be very strange if that would consider some frame. 

With other words, the nature of the _[interp alias]_ command is rather
frame-less. 

However, playing with _[interp]_ a bit, I must admit I see small
inconsistency now between _[interp alias]_ and _[interp eval]_: 

% namespace eval ns { interp eval {} namespace current }
::ns
% namespace eval ns { interp eval {} { proc xxx {} {} } }; info command
ns::x*
::ns::xxx

because _[interp eval], _in opposite to _[interp alias]_, seems to
consider current frame (and so create command in current namespace)...
what is a bit confusing after all (I'd rather expect that both works
more similar). 

Anyway I'd like to make both consistent to each others (just so or so it
is backwards incompatible change and would have large consequences at
script level, so definitely needs a TIP). 
-------------------------

By the way (if we speaking about frames by some commands), I never
missed the NS in the form by _[interp alias]_, but always missed it by
lambdas without given namespace for _apply_ command (where by default I
would always prefer the current namespace to global namespace): 

% namespace eval ns { apply {{} { puts "lambda in [namespace current]"
}} }
lambda in ::
% namespace eval ns { apply [list {} { puts "lambda in [namespace
current]" } [namespace current]] }
lambda in ::ns

Just because it always expects a _[list ...]_ form (so in opposite to
braced form can be never a literal), as well as not always simply
possible if the lambda shall work across namespaces (same code used in
several namespaces), without "tricks" by manipulating the list, e. g.
with linsert, lreplace or lset, like that: 

% namespace eval ns { apply [linsert {{} { puts "lambda in [namespace
current]" }} end [namespace current]] }

lambda in ::ns

what looks ugly, slow and would always expect a modification on the
lambda object. 

In my opinion this is much worse situation than with _[interp alias]_.
And I'd rather "fix" this one firstly. 

Regards,
Sergey.

29.07.2024 15:25, Gustaf Neumann (sslmail) wrote: 

> Dear all, 
> 
> I was recently caught by a mistake which is not easy to spot. In the following script, 
> - the namespace resolution of the unqualified name "NAME1" when creating a proc leads to "[namespace current]::NAME1", while 
> - the namespace resolution of the unqualified name "NAME2" when creating an alias leads to "::NAME2". 
> 
> The following snippet creates via interp alias the cmd ::log 
> 
>> namespace eval ::ns1 { 
>> proc log args {puts stderr "LOG called"} 
>> } 
>> namespace eval ::ns1::sub { 
>> 
>> proc foo {} { 
>> 
>> log foo 
>> 
>> } 
>> 
>> interp alias {} log {} ::ns1::log 
>> 
>> }
> 
> while the following leads to the result i was expecting. Same results on Tcl8 and Tcl9 
> 
> All the best 
> -g 
> 
>> namespace eval ::ns1 { 
>> proc log args {puts stderr "LOG called"} 
>> } 
>> namespace eval ::ns1::sub { 
>> proc foo {} { 
>> log foo 
>> } 
>> interp alias {} [namespace current]::log {} ::ns1::log 
>> }
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core