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] |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.