[wg-camlp4] Structured comments, shallow embeddings and deep quasiquotations

[Gabriel Scherer]

I don't really like Leo's proposal.

On the semantic side, I very much like Jeremy's idea, even if it still
has shortcomings pointed out by Alain, and partially addressed by Leo,
such as the need to get contextual information when applying a syntax
extension. I'm interested in seeing if we can go further in that
direction.

On the practical side, adding a notion of staged compilation and
namespaces to handle syntax extensions seems really overkill. I
believe I was in the same room as Alain and Leo when namespaces where
last discussed, and my personal impression was really not that they
were "likely to be included in the language in the near future" (I
would actually be surprised to see them before a monadic notation!);
there is little agreement on that.

Alain's ppx mechanism has the property of doing away with the idea
that syntax extensions have to be linked together, and I believe he is
right in pointing that out as a practical advantage. Even the previous
camlp4 mechanism had a stronger separation between syntax-time and
compile-time than in Leo's proposal, as the linking happened against
an *external* executable (which allowed other fairly independent
preprocessors to reuse the -pp option without being camlp4-related).
My gut feeling is that less coupling, rather than more, is the right
way to go -- which is not contradictory with an approach favoring
locality such as Jeremy and Leo's proposal of representing macros as
functions. I'm ready to discuss the advantages of such integration,
but I find it unlikely that their are worth tying syntax extensions to
such semantic behemoths as staged compilation and namespaces.

A reasonable compromise I would see between the point of view of Alain
and Jeremy/Leo is to have an "unsafe" interface for global
preprocessing, which we would discourage people from using by being
very good at breaking backward compatibility (we can do better than
Camlp4!), and *maintaining* at the same time one or several safer
entry point that provide the local structure and conventional syntax
that we think will bring more robustness to syntax extensions (like
type-conv can currently be seen as a protective hub around type-driven
boilerplate generation). I would have several questions:
- can Fan make use of the same unsafe interface as everyone else? I've
been impressed by some of the work done by Hongbo so far
(reimplementing the parsing stack on top of dypgen is no small feat),
and I wouldn't want this brand of work to be alienated from the
"practical" syntax extensibility people.
- what safe interface could we provide (I imagine something based on
Jeremy's proposal (plus good concrete syntax choices) with a notion of
context as in Leo's proposal; Leo, I'm a bit unclear on what kind of
GADT you're thinking of, could you elaborate? If it's as good a use of
GADTs as Alain's runtime type representations, I'm all ears.
- how should extensions built upon the safe interface be composed?
Must we link extension functions together, or use program/process
boundaries as in the wider -ppx framework? What are the
advantage/costs of either choices?
- Leo suggests using an in-language feature (namespaces) to handle
addressing of syntax extensions; what is the picture of
outside-language tools to do this? I've had reasonable luck using
'ocamlfind' as a backbone for plugin discovery in Stog. Is this what
Alain imagine users will use? Is it portable to Windows-land?

On Tue, Feb 5, 2013 at 3:19 PM, Hongbo Zhang <hongboz at seas.upenn.edu> wrote:
>
> We have the same ideas. ;-)
> proposals 1, 2, 3, 4 are implemented in Fan as well.
>
> For Proposal 4, we introduced overloaded quotations,
> {:Ast.expr| 1 + $x |} can expand to ast with or without locations. Ast with
> locations introduce a lot of unnecessary complexity when people are just
> doing code generation
>
> Proposal 3 is applied in camlp4 itself(see the quotation module)
>
> On Tue, Feb 5, 2013 at 8:50 AM, Leo White <lpw25 at cam.ac.uk> wrote:
>>>
>>> I will try to put my own proposals in that blog post early next week.
>>
>>
>> That blog post is now up:
>>
>> http://www.lpw25.net/2013/02/05/camlp4-alternative-part-2.html
>>
>> Please respond to it on this list rather than in its comment box.
>>
>> _______________________________________________
>> wg-camlp4 mailing list
>> wg-camlp4 at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/wg-camlp4
>
>
>
>
> --
> -- Regards, Hongbo
>
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4
>