Re: Why context-free?

nmm1@cus.cam.ac.uk (Nick Maclaren)
20 Oct 2005 00:00:53 -0400

          From comp.compilers

Related articles
[15 earlier articles]
Re: Why context-free? neelk@cs.cmu.edu (Neelakantan Krishnaswami) (2005-10-13)
Re: Why context-free? darius@raincode.com (Darius Blasband) (2005-10-13)
Re: Why context-free? anton@mips.complang.tuwien.ac.at (2005-10-14)
Re: Why context-free? darius@raincode.com (Darius Blasband) (2005-10-19)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-19)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-19)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-20)
Re: Why context-free? find@my.address.elsewhere (Matthias Blume) (2005-10-23)
Re: Why context-free? lhp+news@toft-hp.dk (Lasse =?ISO-8859-1?Q?Hiller=F8e?= Petersen) (2005-10-23)
Re: Why context-free? stephen@dino.dnsalias.com (2005-10-23)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-26)
Re: Why context-free? wyrmwif@tsoft.org (SM Ryan) (2005-10-26)
Re: Why context-free? henry@spsystems.net (2005-10-26)
[5 later articles]
| List of all articles for this month |
From: nmm1@cus.cam.ac.uk (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 <darius@raincode.com> 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
syntax.


|> 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.


Regards,
Nick Maclaren.


Post a followup to this message

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