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.