Re: Why context-free? (Nick Maclaren)
20 Oct 2005 00:00:53 -0400

          From comp.compilers

Related articles
[15 earlier articles]
Re: Why context-free? (Neelakantan Krishnaswami) (2005-10-13)
Re: Why context-free? (Darius Blasband) (2005-10-13)
Re: Why context-free? (2005-10-14)
Re: Why context-free? (Darius Blasband) (2005-10-19)
Re: Why context-free? (2005-10-19)
Re: Why context-free? (2005-10-19)
Re: Why context-free? (2005-10-20)
Re: Why context-free? find@my.address.elsewhere (Matthias Blume) (2005-10-23)
Re: Why context-free? (Lasse =?ISO-8859-1?Q?Hiller=F8e?= Petersen) (2005-10-23)
Re: Why context-free? (2005-10-23)
Re: Why context-free? (2005-10-26)
Re: Why context-free? (SM Ryan) (2005-10-26)
Re: Why context-free? (2005-10-26)
[5 later articles]
| List of all articles for this month |

From: (Nick Maclaren)
Newsgroups: comp.compilers
Date: 20 Oct 2005 00:00:53 -0400
Organization: University of Cambridge, England
References: 05-10-053 05-10-061 05-10-083 05-10-109
Keywords: syntax, design
Posted-Date: 20 Oct 2005 00:00:53 EDT

Darius Blasband <> writes:
|> I think they would not, and therefore, I see no need to design non-CF
|> design languages. Non-CF constructs do not lead to better expressions of
|> programming constructs.

That sounds perilously close to dogma! I agree that the use of such
constructs should be justified.

However, my experience is that most people think in a context-full
fashion, and so there is a strong argument for designing a language
where controlled aspects of the context are first-class parts of the

|> But I'd be glad to be shown an example where a non-CF construct
|> actually brings some added value that so CF construct would have.

Easy. Consider the switch/case statement. The syntax of the labels
is dependent on the type of the controlling expression. Now, that can
be handled by the use of context-free grammars and attributes, at the
expense of requiring an expression to be parsable typelessly.

Where I was thinking of using it more generally was to allow
extensible syntax of the following form (simplified for example):

        <keyword> <type expression> <rest of construct>

Expressions and each such construct would be describable in a
context-free fashion, and there would be some very strong way of
recognising the end of a construct. The selection of construct is
determined by a combination of the keyword and type of the expression.

The point is that this is easy to parse and diagnose. Never mind the
theory - think of how to write a compiler for it :-) The Phoenix
command language used very much this model, and it was/is also common
in application-level languages.

Nick Maclaren.

Post a followup to this message

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