Re: ML-style pattern matching in C-like languages

Russ Cox <rsc@swtch.com>
23 Dec 2005 18:03:01 -0500

          From comp.compilers

Related articles
[2 earlier articles]
Re: ML-style pattern matching in C-like languages gtg983q@mail.gatech.edu (Ben Chambers) (2005-12-15)
Re: ML-style pattern matching in C-like languages torbenm@app-2.diku.dk (2005-12-15)
Re: ML-style pattern matching in C-like languages RLake@oxfam.org.uk (2005-12-15)
Re: ML-style pattern matching in C-like languages rvclayton@acm.org (2005-12-15)
Re: ML-style pattern matching in C-like languages haberg@math.su.se (2005-12-19)
Re: ML-style pattern matching in C-like languages Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2005-12-19)
Re: ML-style pattern matching in C-like languages rsc@swtch.com (Russ Cox) (2005-12-23)
Re: ML-style pattern matching in C-like languages nr@eecs.harvard.edu (2005-12-29)
Re: ML-style pattern matching in C-like languages Vladimir.Y.Morozov@gmail.com (2006-01-18)
| List of all articles for this month |

From: Russ Cox <rsc@swtch.com>
Newsgroups: comp.compilers
Date: 23 Dec 2005 18:03:01 -0500
Organization: Compilers Central
References: 05-12-036 05-12-053
Keywords: C, design

> Do you really have to change the language C for this ? Write a
> function which does the matching. Granted, within the limits of C, the
> struct to be matched has to be built up before matching, and this
> takes some lines of code. But would you really sacrifice compatibility
> with C merely for getting some shorthand notation in return ?


Do you have to change the language? Of course not.
But if there were never occasions to change the language, why
aren't all the C++, ML, Java, Python, etc. programmers using C too?


More to the point, why do yacc and lex exist when their functionality
could have been packaged up into a library? One answer might
have been performance (they could do one-time analysis at compile
time to pre-compute the tables used at run time), but that's not
as big an issue on today's machine. The reason they're still around
is convenience. I've written parsers using a yacc library instead
of yacc itself, and it's awful. Compare:


expr: expr "+" expr { $$ = $1 + $3; }


and


static int
yyaction(Yystype *out, Yystype *in)
{
out->f = in[0].f + in[2].f;
}
yyaddrule("expr", yyaction, "expr", "+", "expr", 0);


and then multiply by 100.


Compatibility with C is very important in many contexts and not
something to be thrown away lightly, but if the benefit is significant,
then I think people will go along. It all depends on the context.


Russ


Post a followup to this message

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