howto get a list of all (locally) defined variables

Hi,
is there a way, at runtime in a procedure, to print a list of all
defined variables and/or of all locally defined variables?

Rgds, paul.

 

The debugger function dump() can be used to (sort of) do this:

procedure(blah(a b c)
let((d e f)
d=a*2
e=b*3
f=c*4
dump()
)
)

d = 8
e = 15
f = 24
a = 4
b = 5
c = 6
nil

Regards,

Andrew.

 

The printFunctions command takes 3 arguments. The 3rd argument tells
it to print user defined functions also. Perhaps there should be a 4th
argument to only print user defined functions.

printFunctions(
t_pattern
[ p_outport ]
[ g_listAllFuncs ]
)
=> t

Could the same be used for variables? That is get printVariables to
only print user defined variables?

 

No. The reason it works for printFunctions, and listFunctions, is that these
normally only just public Cadence functions. With the additional argument, it
also lists functions which are not-private - i.e. functions which are not known
about - which means user defined functions.

There is no similar record of public-vs-private SKILL variables, and so the
same approach cannot be done for variables. In practice, there are very few
public SKILL global variables.

Regards,

Andrew.

 

To expand upon what Andrew is telling us, a quick history of the
"listFunctions()" command may be in order.

In about the Opus DFII 434 days, listFunctions() listed all callable
functions which did not start with an underscore, if I remember
correctly. The problem was there were many Cadence private functions
which did not start with an underscore which were callable. But it
isn't a good idea for users to call these private functions.

BEGIN SIDENOTE: A "private" function is dangerous for a Customer to use
because private functions are intended to be undocumented and
unsupported and therefore they generally are without much if any error
checking; and worse yet, they were the most often changed and deleted
of all SKILL functions (by far), causing al ost all compatibility
issues. Customers who weaned themselves off of private SKILL functions
(with Cadence help) have had few to no migration problems between
releases. END SIDENOTE

In the DFII IC44x days, many improvements were made so that Customers
could tell EXACTLY which SKILL functions were public and which were
private and even which functions were not part of the supported code.

For example, thousands of public functions were added to the SKILL
documentation (witness the SKILL Quick Reference quadrupling in size),
the SKILL cdsFinder was likewise enhanced with all the newly documented
public functions, all new private functions were named with a leading
underscore, all new public functions were named with lower-case
prefixes, the CIW: Tools->SKILL->Survey was added to product #900 to
give Customers a complete inventory of every SKILL functions called and
where and it's status, Customers were helped to convert their use of
private functions to public documented and supported functions ... and
.... the listFunctions command was changed to only list DOCUMENTED
functions.

Now we have a new problem.

The problem with the listFunctions command only listing documented
functions was that Customers could not accurately tell which functions
were actually defined at the moment with the listFunctions command
(plent of other ways existed but not so easily). So, Andrew was
instrumental in getting an IMPROVEMENT to the listFunctions command a
few years ago which allowed it to list all currently CALLABLE public
functions.

But he wanted it to be compatible for the user!

For compatibilty reasons, Cadence opted to implement \Andrew's
suggestion as an OPTIONAL new "t" argument. That is, if you use
"listFunctions() today without the optional "t" argument, it will
continue to list all documented SKILL functions, whether or not they
are callable at the moment.

If you use today's listFunctions command with the optional "t" argument
that Andew asked to be added, it will list all callable public
functions that are public. It figures out what's not public based on a
known list of functions.

Given that, the same could be done for listing variables ... but ...

What doesn't exist yet is that known list of public and private
variables.
It shouldn't be hard to create; it just isn't in any one spot as far as
I know.

Hope this helps explain a bit of historical detail,
John Gianni
-- Nothing stated by me is prior reviewed or sanctioned by my employer!

 

If you are using scheme mode, you can examine (theEnvironment)->??
to find out all the lexical variables.