caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Dario Teixeira <darioteixeira@yahoo.com>
To: blue storm <bluestorm.dylc@gmail.com>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] OSR: META files for packages containing syntax extensions
Date: Fri, 14 Mar 2008 15:33:08 +0000 (GMT)	[thread overview]
Message-ID: <983301.78248.qm@web54604.mail.re2.yahoo.com> (raw)
In-Reply-To: <527cf6bc0803131008y151941a3ka3b9e50721ba3229@mail.gmail.com>

Hi,

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

Thanks for ellucidation.  Alternatively, since the preprocessor is
oblivious to the name of the package (as you say, even Camlp5 may
only care about the name of the .cmo file), we can simply declare
this to be a documentation problem and to not enforce any convention
regarding the package name (except for the previously discussed .syntax
suffix).

Therefore, the package implementing the "openin" extension could be
called "pa_openin", "openin", or whatever the author prefers due to
historical reasons.  The only requirement is that the syntax extension
itself should reside in an "openin.syntax" subpackage.


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

I think that is also a documentation issue.  Ideally, the META files
should be constructed in such a way that the user should not have to
care about extension dependencies.  As an example, consider the Sexplib
syntax extension, which itself depends on the type-conv extension.
On my system, I have patched the META files so that this is transparent
to the Sexplib users.

Here's my META file for Sexplib:

--------------------------------------------------------
name="sexplib"
version="3.0.0"
description="Sexplib - automated S-expression conversions"
requires="bigarray"
archive(byte)="sexplib.cma"
archive(native)="sexplib.cmxa"

package "syntax" (
  requires = "sexplib,type-conv.syntax,camlp4"
  version = "3.0.0"
  description = "Syntax extension for Sexplib"
  archive(syntax,preprocessor) = "pa_sexp_conv.cmo"
  archive(syntax,toploop) = "pa_sexp_conv.cmo"
  )
--------------------------------------------------------

And the META file for Type-conv:

--------------------------------------------------------
name="type-conv"
version="1.0.0"
description="Type-conv - support library for preprocessor type conversions"

package "syntax" (
  requires = "camlp4"
  version = "1.0.0"
  description = "Syntax extension for type-conv"
  archive(syntax,preprocessor) = "pa_type_conv.cmo"
  archive(syntax,toploop) = "pa_type_conv.cmo"
  )
--------------------------------------------------------


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

I don't know if there's support for those cases (are there any in the wild?).
Perhaps some of Findlib's gurus can enlighten us...

Cheers,
Dario



      ___________________________________________________________ 
Rise to the challenge for Sport Relief with Yahoo! For Good  

http://uk.promotions.yahoo.com/forgood/


  reply	other threads:[~2008-03-14 15:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-13 12:40 Dario Teixeira
2008-03-13 13:14 ` Sylvain Le Gall
2008-03-13 13:21   ` Eric Cooper
2008-03-13 13:30     ` Sylvain Le Gall
2008-03-14 15:00       ` [Caml-list] " Dario Teixeira
2008-03-14 14:53     ` Dario Teixeira
2008-03-14 14:52   ` Dario Teixeira
2008-03-14 15:09     ` Sylvain Le Gall
2008-03-14 15:41       ` [Caml-list] " Dario Teixeira
2008-03-13 15:05 ` [Caml-list] " Stefano Zacchiroli
2008-03-13 15:30   ` Gerd Stolpmann
2008-03-13 17:08     ` blue storm
2008-03-14 15:33       ` Dario Teixeira [this message]
2008-03-14 15:51         ` Gerd Stolpmann
2008-03-16 21:34 ` [Caml-list] OSR: META files for packages containing syntax extensions (take 2) Dario Teixeira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=983301.78248.qm@web54604.mail.re2.yahoo.com \
    --to=darioteixeira@yahoo.com \
    --cc=bluestorm.dylc@gmail.com \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).