Re: On language extensions (was Re: [Caml-list] global record)

[Eric Breck <ebreck@cs.cornell.edu>]

> From: Daniel_Bünzli <daniel.buenzli@e...>
> Subject: On language extensions (was Re: [Caml-list] global record)
>
> Contrary to lisp's macros, each syntax extension is syntactically a
> new language. Hence not only do we need to learn a new semantics but
> also a new syntax. If I have to read someone else's code I want to
> read caml code and not caml code augmented with the author's
> syntactic obsessions.
>
> In code readability, there is a trade-off between succinctness and
> syntactic regularity. Camlp4 extensions increase the former but
> decrease the latter. For me camlp4's usage should be limited to real
> domain specific languages (e.g. like coq does) and research, it
> should not be used to increase ocaml's succinctness.

Succinctness is not precisely what I was after so much as locality -  
in this case, having each option declared in a single location - as  
opposed to the type definition in one place, the default value in  
another, the Arg.spec in another, code to print the chosen value of  
each option in another, and, optionally, the de-ref-ication in  
another.  Such locality is a basic principle of software engineering,  
and in this case I don't really know how to achieve it with only a  
library (and not a syntax extension).

I'm not advocating extending the language willy-nilly, but I feel  
that any new library already requires some amount of learning to use  
its particular API, and if a small, local extension to the language  
vastly shrinks (and localizes) code required to interface to the  
library, it seems reasonable to me (IMHO).

To put it another way, I do not agree with the adage that "syntactic  
sugar causes cancer of the semicolon." :)

As far as readability, I tried to choose syntax that would make clear  
to a casual reader what was going on, but clearly I'm blinded by  
having stared at this for awhile now.  As Nicolas Pouillard points  
out, you can always unsugar the code.

Anyway, I've been using variants of this library for half a year or  
so, and I've found it very convenient, so I thought I would offer it  
to others.

> This may be seen as a matter of personal taste: it is true that I
> lean towards syntactic regularity, i.e. less syntactic constructs.
> However there is another argument against using extensions: code
> maintenance. You have no guarantee that (1) an extension will not be
> broken by the next version of the language and (2) that the author
> will continue to maintain it.

I'm not sure why either 1 or 2 is more true for a syntax extension  
than for an arbitrary library, assuming the syntax extension doesn't  
try to make large-scale changes to the grammar.

> P.S. Even for domain specific languages many things can be done in
> pure ocaml by embedding the dsl in ocaml using meta-programming
> techniques.

I'm not sure what you mean here.  I understand meta-programming to  
mean (roughly) generating code programatically.  A solution along  
those lines to my problem (locality of command-line arguments) would  
be something like this: specify the options in some file, write some  
piece of code to process this and produce an ocaml file, which is  
then compiled and linked with the main program.  I actually  
originally did something along these lines, but then decided that  
since this approach also requires defining and processing a new  
syntax (of the option file), I would use camlp4 and integrate that  
syntax into my main program.  That is, camlp4 *is* meta-programming,  
it's just that it (a) integrates the DSL into the main program, and  
(b) hides the intermediate file.

But perhaps I'm misunderstanding your point - if you could clarify  
what you mean, I'd like to know what alternate approaches are.

Finally, I have the sense (perhaps I'm completely wrong) that the  
post I'm responding to was motivated in part by a thought that  
command-line option parsing is somehow not worthy of a domain- 
specific language / syntax extension.  I suppose it is something of a  
"syntactic obsession" with me to find a clear and concise way of  
specifying such options, since I write mostly small, command-line  
programs to which I want to be able to quickly add variant  
functionality.  Clearly, the benefit to any particular program is  
small - when you write enough of them, though, the lifetime savings  
in tearing-my-hair-out is, I think, a win.

best,

-E r i c

(PS: sorry if this doesn't get threaded appropriately, I read the  
digest of the list).