Re: Why context-free?

Tony Finch <dot@dotat.at> wrote:
>nmm1@cus.cam.ac.uk (Nick Maclaren) wrote:
>>
>>In the case I am thinking of, which started this, I am thinking of at
>>least three phases: lexing, parsing/type matching, and scope and
>>inheritance checking. To keep the middle phase within bounds, it is
>>clearly necessary to keep the type matching really simple and really
>>just part of the parsing.
>It sounds like you are assuming a language with a nugatory type system.


No. It is hard to explain briefly, but I will try. In most sane
languages, the syntactic nature of an object (e.g. an object or type
name) is visible during parsing. Algol 68 broke that with modes and
operators, which caused havoc far beyond its usefulness. Fortran
breaks that with external functions. C99 sort of breaks it in a few
places.


However, many languages either don't do that for types or have rules
such that the type of a just-parsed construct involves some evaluation
that goes beyind parsing. This very rarely adds anything to the
language except the ability to leave out casts, but does mean that the
type of a construct is not reliably and easily visible during parsing.
So you had better NOT use them in the syntax rules.


My assertion (based on experience) is that requiring explicit type
specifications is a minor problem for competent programmers and, while
hated by incompetent ones, helps them against themselves. And it also
allows the use of types as first-class syntactic properties. As I
say, it has been done.


>Doesn't scope checking affect type checking?


It depends on the language :-) But you may not understand what I mean
by that - I am talking about much more advanced checking than the
simple static scopes of the Algols, C or Fortran 90 and am wanting to
introduce the ability for rigorous, largely compiled, checking of the
relative scope of pointers and objects. That has been a neglected
approach since Algol 68, and (for reasons that are nor germane) the
myth that garbage collectors are a solution is, er, so much collective
garbage.


I am also talking about the integration of things like exception
handling (including signals), BCPL/C longjmp etc. In a statically
checked fashion! All easy, and with prior art, PROVIDED that the
language makes it possible.


Regards,
Nick Maclaren.

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