Okay, I'll admit that the "#declare whose" idea was a bit silly.  And I'll
admit that some of my ideas are made of cork.  But, I've just been getting
them out there so that we can all find the one made of tungsten.

This one might be just in that direction:

As long as we're asking the parser to rename macros and declares at the
front end (e.g. #include ... #as), couldn't we just ask the parser to
rename them for us in the Backend.  And to do so in a way that none of us
possibly could with our keyboards?  There are ascii values that are
unavailable to us when we name macros; but, couldn't we make them available
to the parser?  This is what I have in mind:

Okay, let's say there are a few includes you want to use in your scene.
Let's call these "first-level includes."  You're familiar with them already
or you wouldn't be using them.  So, you're obviously going to be able to
avoid naming conflicts from items in those particular includes.

Now, assume that one or more of them also call includes.  Let's call them
"second level."  And, some of those includes might call still more - "third
level" - and so on.  That's where you might run into a naming issue.  Who
wants to have to read all those other files?

So, what if the parser could keep track of its 'include depth' and its
'include count' and then give it a renaming algorithm so that every macro
or declare 'call' in the first level and every macro or declare
'declaration' in the second level is altered identically - using
parser-only characters.  Once in the second level each call is altered
uniformly and identically to each declaration at the third level and so on.

I realize that the #ifndef() at the front of each include may interfere with
this strategy.  (User includes "A.inc" and "B.inc" and "A.inc" includes
"B.inc".  Parser thinks "already been there" and doesn't give you what
"B.inc" has to offer you.)  That needs to be addressed.

Admittedly, the parser is a black-box phenomenon to me.  I have not looked
at its source.  So, I have a question:  Could this method result in strings
of redundant macro code called by different names taking up too much memory?
 If so, would a sort of staging area of compilation be appropriate upon
exiting an include whenever it is one that has called includes itself?

Well, that's the best I've got for now.

-Randall

Post a reply to this message