Re: [Caml-list] OSR: META files for packages containing syntax extensions

["blue storm" <bluestorm.dylc@gmail.com>]

> Topic for discussion: for the sake of standardisation, it would be
> nice if all packages of this type were to share a common prefix.
> The most obvious candidate is "pa_".

Though this can be refined later, i think we could do something a bit
more elaborate there.
I have not used camlp4 pre-3.10 (camlp5 these days), but if i
understood correctly, prefixes were used to describe the internal
machinery of the extension : pa_ denotes a parser extension, while pr_
denotes a printer extension. I do not know of any other prefix.

With the new camlp4, those suffixes are not required, but they were
kept in order to ease the transition (i'd assume pa_r.cmo actually
refers to Camlp4Parser/Camlp4OCamlRevisedParser.cmo). This is a good
idea imho, but i think that if we stick to that convention (describing
the actual effect of an extension in his name) we should adopt a
naming convention a bit more powerful, to reflect the actual abilities
of camlp4 : for example, we can have AST filters, wich are neither
parsers nor printers.

Here would be a draft suggestion concerning this naming scheme :
- pa_ for parsers
- pr_ for printers
- pf_ for filters
- p_ in uncertain cases

Some extensions use eg. both a parser and a filter; i guess they'd
need to chose the most meaningful prefix (are they primarily intended
to modify the existing syntax, or change a behavior ?).
There are some code that can be described as a "syntax extension", but
that does not use any of the camlp4 parser/printer/filter tools. The
'extensions' using the library type-conv (
http://www.ocaml.info/home/ocaml_sources.html#type-conv ), for
example, use a specific registration mechanism. I guess the p_ prefix
would be appropriate for those corner cases.

I think it is important to keep a camlp5 compatibility (even if i'm
not sure ocamlfind support camlp5 yet); the re-use of the standard
prefixes provide this.



> Another common occurrence is for the syntax extension to rely on a runtime
> module or library included with the package.

Another common case is when the syntax extension rely on a
preprocessor-time module or library (eg. type-conv). It could be
helpful to add a description of that possibility.

Is there a way to specify a dependency on a specific preprocessor
(between camlp4o and camlp4r, for example ?). Most extension actually
won't work with both syntaxes (classical and revised), and it could be
helpful to make it apparent in the package description (although most
of the time an horrible preprocessor-runtime error will happen).
More generally, i'm concerned with the possible incompatibilities
between syntax extensions (however, this may be a bit off-topic).


Thanks for that very useful proposal.