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

[skaller <skaller@users.sourceforge.net>]

On Wed, 2006-07-19 at 21:12 -0400, Eric Breck wrote:
> > From: Daniel_Bünzli <daniel.buenzli@e...>

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

> Succinctness is not precisely what I was after so much as locality -  

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

In my opinion, the difficulty here lies in the Ocaml 
programming model.

Precisely as you say above regarding locality .. the syntax
extensions should be localised. In particular, they should
be embedded in the file that uses them -- along with
documentation -- and not specified on the command line.

For example

syntax MyExtensions;;

which could itself be implemented in ocamlp4 perhaps,
and then *that* extension converted to a builtin part
of the language.

Felix implements syntax extensions with preprocessor
statements (which can be provided in a #included file).

Of course the syntax extension should contain documentation!

Having said that, I do agree excessive extensions make
code hard to read .. and probably defeat other tools
such as ocamldoc (which even if applied to expanded 
output may report on the expanded source when one would
prefer reporting on the unexpanded input).

This form of code generation is weak compared with
systems like MetaOcaml.

Similarly, Ocaml should have 

  import List;;
  .. List.fold_left ..

so that you are required to import a separately compiled
module before using it. As a sop to existing code, 

  open List;;

could imply import. grep for either 'open' or 'import'
is then enough to establish dependencies.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net