Re: Tcl C extn - Scoping in extended cmds - how to?

Hi Arijit,

so far as I know, no tcl command (C function registered as tcl
command) creates a call-stack-scope on its execution.

So having a tcl command "foo" called in the procedure "faa" won't
create a new scope, so that it may access all local variables inside
the procedure "faa".

So a solution may be to have a pure tcl "framework" with such
procedures like "block", "register", "fields", "bits", etc..
This procedures then call a matching tcl command (e.g. ::myExt::Block)
in their scope, so that "upvar" still from the tcl command at the
procedure level to access variables outside the procedure.

Take a look at the twapi extension.
There are "raw" or low level tcl commands representing the WIN32 API
and then there are tcl procedures using this tcl commands for a high
level API on top of the WIN32 API.

The same I try to do, when encapsulation a CAD C(++) API to be used
with tcl.

---

Not really knowing what you are achieving with your extension and what
it is used for the source snippet you presented ...

set var 1
block b {
register r {
field f {
bits 8
}
}
}

.... does not look for my eyes as a candiate for "scoping"! It looks
like another kind of control structure, that evaluates "script-bodies"
in the scope of the caller (here where the variable "var" is known)!

You wrote, that you want to use "upvar" etc., but is this really
necessary and needed?
I don't really understand why you want this!

As example take "nested" control structures like ...

% set asciis [list]
% foreach cmd [info commands] {
foreach char [split $cmd {}] {
lappend asciis [format {0x%02X} [scan $char {%c}]];
}
}

.... or a "selfmade" control structure ...

% set counter 1
% do {
puts $counter; incr counter;
} while {$counter <= 10}

A control structure does not deal with scopes in its bodies or
conditions! It's not needed, not necessary and would create more
complex code!

Just simply declare such commands, like "fields" to work always in the
scope of the caller, so that the call by look like this:

set var 1
field f {
echo $var
bits 8
}

This would prevent probably needless complexity and sources for
errors!

Best regards,

Martin

On Jun 28, 10:56 am, ariji...@xxxxxxxxx wrote:
Hi,

I am using Tcl C extension to create extended commands like this:

set var 1
block b {
register r {
field f {
bits 8
}
}
}

Where "block", "register", "field", "bits", etc are my extended
commands.

Now, when I do command extensions like this using
"Tcl_CreateCommand(interp, ...)", the scope actually remains the same
i.e. inside the "field" in the above example, I am actually able to
access $var. In other words, the following becomes possible.

set var 1
field f {
echo $var //This works fine...In Tcl proc scoping semantics,
it is not allowed unless upvar or global is used.
bits 8
}

But I actually want my commands to have Tcl proc semantics as far as
scoping is concerned, so that the above code becomes invalid and the
following (pure Tcl way) should only be allowed.

set var 1
field f {
upvar $var local_var
echo $local_var
bits 8
}

So, I just wanted to know if there is some way by which I can
configure my extended Tcl commands to follow the "proc" semantics as
far as scoping is concerned.

Thanks for your time and willingness to help,
Arijit


.

Relevant Pages

  • Tcl C extn - Scoping in extended cmds - how to?
    ... I am using Tcl C extension to create extended commands like this: ...
    (comp.lang.tcl)
  • Re: looking for tcl based Cisco like command line interface
    ... TinyTcl and Jim would be fine to save resources, but first is missing some newer tcl sub-/commands and later has no exec-command at all. ... Only want to install one single tcl/etcl/tclkit interpreter and a single tcl script. ... Funny, the cli can be run from any computer remote,using snmp get/get-next/set for communication to the network device, therefore got a remote console program too. ... extreme environments) based on ARM or Coldfire processor using Debian Linux/ucLinux should be extended with a CLI that is similar in behaviour, handling and naming conventions to the well known cisco command line interface (several user-visible application-specific commands, along with a help, different management operation levels like "enable", "config", line driven only, tab expansion, no special graphics or ascii terminal commands) ...
    (comp.lang.tcl)
  • Re: Language Specification - Where is it?
    ... >> the Endekalogue, the semantics aren't described ... > commands have semantics. ... The first is the semantic of the Tcl syntax and the behaviour and order ... all the rest of the language can be in theory implemented using this ...
    (comp.lang.tcl)
  • Re: Constants for catch return values?
    ... > proc like [tokenize]. ... As an aside, in TCL 8.5, I figure you could do the inverse conversion ... 101 commands that each deal with one aspect of it (except where those ... of pattern matching) Two examples of my own; I had a script that had ...
    (comp.lang.tcl)
  • Re: looking for tcl based Cisco like command line interface
    ... commands, along with a help, different management operation levels like ... As tcl is very powerful a smaller tcl to achieve faster startup may be ... cli commands to snmp get/get-next/set. ... is based on tcl it would even be possible to extend the rights of this ...
    (comp.lang.tcl)