Re: Symbol tables and scopes

Chris F Clark wrote:


> D> The only useful answer I ever found, is a 1:1 correspondence of
> D> definitions and their implementations. In this case every module only
> D> imports required modules, so that a global search path is neither
> D> required nor really helpful.
>
> I agree that there ought to be a way for the user to discover the
> exact correspondence between definitions and implementations and to
> preserve such correspondence reliably in the face of changing
> standards, implementations, and libraries.
>
> However, I find that giving a method of explicitly qualtifying
> references and then requiring the users to explicitly qualify their
> references is often used as a cop-out solution. I don't want to have
> to explicitly qualify a bunch of existing imported names in my
> environment just because I decided to use a new imported library (or a
> new version of some library is now available). I also don't want to
> have to explicitly list which names are coming from which library,
> since the library providers might change that.


IMO the chaos is one of the fundamental principles of C, inherited and
extended by any successors ;-)


He who wants to use C, has to accept long compilation times, for efforts
to organize the chaos araising from the specs, installations and, last
not least, from the user itself. When the existing chaos requires, that
the user disambiguates symbols by qualification, the user has to accept
this requirement.




> Not so long ago the C++ standard-holder did just that when they moved
> a bunch of previously unqualified names into the "std" namespace. I
> want to be protected from just that occurrance, so that my currently
> working software keeps working in the presence of evolving standards
> and implementations.


IMO a better solution could have been found, when the requirement for
according adaptations of existing code had been anticipated. A missed
chance for a simplification :-(




> This is why I want user configurable search rules...


This IMO follows the mentality and tradition of C users, which want to
cure symptoms by adding another processing layer on top of the existing
layers, and another one, and so on. AFAIR in the build process of open
source C projects, according to FSF rules, at least 5 different
languages are involved now. You want to add another language, for the
description of your search criteria. This may be acceptable and
consequential from your point of view, but you may understand why I
prefer a different development environment, and only grin mildly on the
problems of C users. But I know that the choice of a language is an
irrational and immutable decision, so that I'll never more try to
convert anybody to a different religion.


Nonetheless I'd be interested in a really new standard, which would
eliminate the known problems in using C for writing portable code, as
much as possible, while keeping the changes to existing code at a
minimum. But this is not the right group for such a discussion, besides
perhaps for the compiler related effects. Here a general discussion of a
*simplified* handling of symbols and scopes IMO were possible, but not a
discussion of *additional* tools and procedures.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.