From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: What is your opinion on Global Objects? Date: Fri, 21 Nov 2014 15:53:13 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <8561e9omp7.fsf@stephe-leake.org> <65f2470c-0828-4f97-9f0e-f11966896c06@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1416606795 9228 24.196.82.226 (21 Nov 2014 21:53:15 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 21 Nov 2014 21:53:15 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:23617 Date: 2014-11-21T15:53:13-06:00 List-Id: "Adam Beneschan" wrote in message news:65f2470c-0828-4f97-9f0e-f11966896c06@googlegroups.com... ... >> The symbol table for a compiler is a good candidate for a singleton. > >This doesn't seem right to me. It does to me. :-) >I haven't followed the whole discussion closely, so I might have missed >something... But >in the case of a symbol table, an Ada compiler that implements generics by >"macro >instantiation" is an example of why a symbol table should *not* be a >singleton. If the >compiler rescans the text of the generic, the entire context (i.e. what >symbols are visible) >will change while the generic is being instantiated, and then it will >change back at the end. >And of course the generic can instantiate another generic. This makes no sense whatsoever. First of all, you can't instantiate a generic by rescanning the text, because all of the objects are bound when they are initially compiled. Most likely, everything would resolve wrong. Trying to make that work would be an absolute nightmare. Our symboltable is purely a singleton; it reflects exactly the declarations available to the program at the current point in the compilation. (Our compiler is syntax-driven, so for most purposes it can be considered one pass -- we never go backwards in the source or symbols). Every change in the code changes the symboltable. (Initially, we deleted declarations as they went out of scope, but that always seemed to leave dangling pointers and was just a lot more complex than marking things as invisble.) That's why implementing ASIS is impractical in our compiler -- we don't ever have a view of the compilation as a whole to work from. Generic instantiations are implemented by copying the symboltable for the generic unit and making the changes required by the instantiation. We don't do macro expansion, but if we did, we'd do it by duplicating a tree form of the unit (in which all of the symbols are already bound). Trying to work from the text is madness (especially as our parser is also a singleton)! Now, I'm well aware that anything done in someone else's compiler is totally weird -- the things that other ARG members consider hard (or easy for that matter) often make little sense to me. I could imagine structuring a symbol table as a set of units (which would not be a singleton). [I can't imagine the Rational compiler, which supposely doesn't have a symbol table at all. But whatever.] Anyway, I think the main point is that there really is no rules. Sometimes a singleton package is the best design. Sometimes a bunch of global spagetti is about all that would ever work (that's probably the best description of the symbol table in Janus/Ada)! [We couldn't afford the code that encapsulation would have cost back on CP/M and MS-DOS -- indeed, we use jumps, not calls for elaboration because we saved the call setup code *200 units -- which was enough to make a big difference when getting code to fit into 64K RAM.] Randy.