[Sorry it's taken so long to reply...]


Richard A. O'Keefe [ok at atlas.otago.ac.nz] wrote:

> About 5 or 6 years ago I supervised a student whose 
> self-chosen honours project was to write some kind of 
> software tool for analysing a whole lot of programs 
> his company had in their own object-oriented extensions to
> DEC Basic (now Compaq Basic).

Same basic idea.... I have large chunks of 20+ year old
DEC/Digital/Compaq BASIC source code that I've inherited
shared responsibility for [It's a complete 'Student Information
Management System' with its own proprietary database. It's 
probably the last OpenVMS only critter of that sort left 
"in the wild" used by 150+ schools in the US/Canada].

> No, the problem was that the documentation for DEC Basic just 
> plain wasn't good enough.  It provided syntax, but was massively 
> unclear about semantics, and I'm talking about the reference manual.  
> Actually, it wasn't as clear as it could have been about syntax either.

Well.... the DEC approach to documentation appears to be
heavily tied to the idea that you can choose the language 
of your choice for a particular function and when you are 
done, if you correctly used the function calling standards 
correctly you can end up with a working program that might 
have some functions written in COBOL, some in BASIC, some
in MACRO, and even some in ADA (Or whatever language you 
want that follows the DEC function calling standards). 

So... the documentation tries to be vague enough so you
can apply it to multiple languages. Sometime that works,
sometimes not.

Of course, if you using some undocumented function that
is there for backward compatibility all bets are off....

> You'll find advice about object-oriented compiling in lots of places,
> like Sigplan notices, OOPSLA, and of course by reading the Squeak
> compiler.

Thanks.


> I don't think you are going to find designing the parse tree 
> data structure or writing the parser the hard part.

> I think you are going to find decoding all the details, and 
> then discovering all the little quirks that aren't in the current
> manual but the existing programs exploit anyway, to be the VERY 
> hard part.

That's already true %-). Fortunately I have access to people 
with over 20 years experience with this particular code.

Thanks for the suggestions/advice.

-Andy-