Hi,

Simple fasmg macro question: If I have a namespace and it contains descendant symbolic values, can I traverse the namespace upwards against symbols of the same name?

For example:

If I have a .disable symbolic value and a macro is passed a namespace

Can I walk the namespace upwards to see if any ancestor namespaces have a .disable value as 1?

The entire tree might look like:



I'm coming up with some ideas as I type this but was wondering if there was a simpler or built in way to traverse the namespace tree.

Digging deeper into fasmg but keep having to put it down before I can take full advantage of it.


Have a good one.

By design a code embedded in a namespace has no way of "knowing" that it is encapsulated this way - it allows to use NAMESPACE blocks as means of a complete separation of symbol trees of different portions of source. For example when you include a "foreign" file and you need to be sure that it cannot pollute your own namespace or modify your symbols (or that it can modify only the ones you make available to it, by making them global), namespace separation can give you that confidence - because the encapsulation (and how many levels of it are there) is designed to be "hidden" from the enclosed code.

Therefore the only way to do what you ask for would be to globally re-define NAMESPACE and END NAMESPACE as macros that would keep track of all the embeddings, and then you could traverse the tree using your own lists maintained by these macros.

On the other hand, looking at your code sample I think that what you need might be attainable another way. If instead of defining symbol with either 0 or 1 value, you can leave it undefined or define it (with any value), then simple IF DEFINED check should work for you:

Interesting, yes that perfectly fits what I was trying to achieve.

I'm going to step through some macros on my train ride home today and test out some things, especially defined and walking 'tree' namespaces. I was able to assemble some more complicated looping constructs and it seems you can redefine namespace levels while iterating through them:


The .. relative unnamed namespace also shows promise. I'm going to probably put the namespace layout in its own file, like so:



And also try match against the hierarchy. It's probably possible to parse it, keep track of counts, and iterate through those, not sure which is simpler. Simplest by far is using your method, as it stands. Want to keep tinkering...