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

["Bünzli Daniel" <daniel.buenzli@epfl.ch>]

Le 20 juil. 06 à 03:12, Eric Breck a écrit :

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

The typechecker (indirectly) gives you that locality, it tells you  
exactly where changes are needed and frankly all this is in the same  
module, maybe even on the same page. If I have to maintain your code  
I'll understand quicker hand made code than your syntax extension  
(especially since I already know how the Arg module works).

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

Api is not new syntax. As a said before when you learn an api you  
only need to understand new semantics.

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

For small examples this can be a solution. But I usually prefer not  
to read machine generated code. Most programmer (I hope) reread their  
code and try to make it readable and elegant, a machine won't.

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

I agree on this point for 2 but not on 1. Incompatible language  
changes are rare (inexistant ?) with ocaml.

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

I was not specifically talking about your problem here, though I  
could maybe be applied. It was more on using caml to write code that  
should be written in another language (e.g. regexps, sql, etc.),  
instead of writing a horrible language extension that will allow you  
to mix both languages or use caml strings, see [1] for more information.

I'm sorry to say that but I regard (maybe out of ignorance) camlp4 as  
very low level and brittle tool (not to say hack). An obvious proof  
of this to me is the composition problem which is according to  
previous messages is not solved by camlp4.

Best,

Daniel

[1]
@article{967844,
  author = {Conal Elliott and Sigbj\&\#248;rn Finne and Oege De Moor},
  title = {Compiling embedded languages},
  journal = {J. Funct. Program.},
  volume = {13},
  number = {3},
  year = {2003},
  issn = {0956-7968},
  pages = {455--481},
  doi = {http://dx.doi.org/10.1017/S0956796802004574},
  publisher = {Cambridge University Press},
  address = {New York, NY, USA},
  }