There is no other way that I can think of to describe it.  It goes like this.  I managed to get simple assignments working with the RECORD type in the C++ version of the Pascal compiler, but what an uphill battle that was, and yet I am still facing an error  <158> "No such variant or record" when the C++ version of the compiler tries to compile the original Pascal source.  So I began implementing completely new versions of the "structure" and "identifier" RECORD types, which I am integrating into my FRAME-LISP library.  In the case of the "identifier" class, I have made some progress with using the so-called "curiously recurrent template pattern" method so as to get the identifier class to inherit from as well as be encapsulated by my bTreeType<X> template class.  Then with the structure class, I am also in the process of using variations on the concept of trying to create a class factory approach static polymorphism to create class hierarchies that can be both nested as well as inherited in order to support suitable class types for such necessities as object::scalar, object::pointer, etc.

So far so good, or not so good:

Really, it's probably just another case of mis-nesting of curly braces somewhere, that I need to ferret out, either by finishing my Eliza-based code analyzer; or else I need to do a complete heap walk, in order to see if the actual problem is in declaration part.  The best way to do a proper heap walk, of course, is to completely re-implement all of the data structures in some parallel context.  This is why I need to implement an object factory, and so on.  And then, like, isn't this all of a sudden, no maybe, I have actually been down this road before, but wait a moment, what exactly is THIS?!?

So I open up the Pascal source for the compiler as a text file in visual studio, while the debugger is stopped while the same line of code is being compiled by the C++ version so that I can try to figure out what exactly is the problem, and then I just so happen to position the mouse over the name of an identifier, not in the C++ code that is being debugged, but in the Pascal code that is being compiled, and - say what?  Visual Studio recognizes the symbol INTPTR and I get this popup list!  Wait a minute!  Maybe if I was debugging a fence post problem in some kind of array indexing example, and maybe if I opened "The Adventures of Tom Sawyer", in Visual Studio, while debugging an application that used the label "fence" as a parameter for some range type, then I would get some kind of pop-over, because Visual Studio is just guessing that something might be relevant.  Yeah, so beyond the Labyrinth and Through the Looking Glass, indeed.

Now, this gets me thinking about equivalence classes, and some philosophical reasoning regarding the question "What exactly is an analogy?" Is a proper analogy formed when two or more ontological constructs share at least one equivalence class, in at least one context - irrespective of whether that particular equivalence is strong or weak?  Yeah, I think I know where this train is headed. 

Yet for whatever it's worth, maybe this is a good time to mention that the very first PASCAL program that I ever wrote, besides some Hello World demo was a program to help create strategy tables for the game of Blackjack.  Now as it turns out, not only do I STILL have my original Apple II floppies, but at some point a long, long time ago, I took the time to copy at least some of that stuff over to a Macintosh, of which, of course, at least some of THAT material got archived onto a PC format, thanks to Windows NT 4.0 Macintosh file sharing over Ethernet.

So I finally have gotten to the point that I can try compiling some VERY old code that I wrote - yes THAT long ago for UCSD Pascal on the Apple II!  Unfortunately, the new compiler isn't fully functional quite yet.  However, I am pleased to report that at least it gave an honest attempt at trying to compile this piece of "personal" history.

Now whether this particular piece of code is quite possibly one of the VERY oldest pieces of GNU software still in existence, might be some matter for debate.  Likewise, whether this WAS the exact code that the MIT count team used with THEY whatever it was that did whatever it was that they did, might also be a matter for debate, as I have never actually seen their code.  The program that I wrote simply helped prepare strategy tables by calculating the probability that the dealer would reach a certain total or else go bust whenever certain cards were removed from the deck, and thus as such, it was never meant to be a fully complete real-time card counting application.  Yet with a fast enough CPU and an appropriate hardware interface, well you get the idea.  Oh yeah.  And besides, I graduated from UC Berkeley, not MIT. ;-).

Nonetheless, earlier today I was pleasantly surprised to discover that the compiler's declaration part is handling multi-dimensional arrays somewhat correctly, even if some internal data structures are not being properly set up, within the compiler that is, and that is what is causing problems later on in COMPILER::BODYPART when attempting to access elements of an array or of a record for that matter.  Even if interestingly enough, array and record declarations, as well as the operator new all seem to be working, at least for simple record types, that is without variants.

Thus my current approach is along the lines of writing reams of debugging code for inclusion within the new compiler, for such things as performing heap walks and the like, of all TYPES, and VARIABLES. and other data structures within the application, or for perhaps any application.  Yeah, back to the hall of mirrors again, when you think about it - since I am trying to figure out an issue that involves the data structures that keep track of the data structures, and that can therefore allow, at least in principle run time tracking of data structures of any type, since that concept is in principle dynamic.  

You are in a round room, with exits, leading to the north, south, east, and west.  There are also exits to the northeast, southeast, southwest, and northwest.  This is the maze of twisty little pathways, and so on.