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

[Leo White]

On Feb 5 2013, Alain Frisch wrote:

>On 02/05/2013 06:22 PM, Leo White wrote:
>> The problem is that the quotation is in a module that is part of the
>> program. This module will be initialised at both compile-time and
>> run-time. Any effects of initialising the module will occur both times.
>> Since an OCaml program's run-time behaviour is basically defined as the
>> effects of initialising its modules this will cause confusion and bugs.
>
>As I see it, the problem is not that the code for the extension is in a 
>module, but that it is in a module which will be linked with your target 
>program.  You propose to avoid any such potential confusion by 
>segregating those modules which contain extension code from other 
>"regular modules".  Conceptually, this is not very different than 
>choosing a module prefix (e.g. "pb_", the successor of "pa_") and simply 
>ensuring in the compiler that they refuse to link pb_* modules into 
>programs; those module can only be loaded (dynamically?) in a specific 
>context (a particular "ppx" driver). It's just that you declare that 
>these pb_* units are not real modules (and introduce a specific file 
>extension instead of a prefix).

That's about right.

>But fundamentally, I still don't agree that there is a clear separation 
>between "extension code" and "program code".  In particular, an 
>extension might very well use a third-party library (e.g. an XML parser) 
>or share some code with the target program. 

Yes, it is not a hard separation between the two.

Why should we enforce a 
>strong separation, in particular if this implies some ad hoc rules in 
>the compilers?

My proposal was for a system that made extensions simple for non-experts. I 
think that it is easier to explain that extensions are like 
mini-preprocessors that live in ".mlq" files, than to explain that they are 
normal functions, but you can't use them in the same module, and you 
shouldn't include them in a module intended for run-time execution, and the 
side-effects of running the function will not be preserved etc.

Note that Haskell does not have the last two conditions because it manages 
all side-effects.

>> >> Would the code for .mlq would be compiled manually before its
>>> expanders can be used, or would this compilation happen automatically?
>>
>> They would need to be compiled, just like ".mli" files.
>
>They contain code, so I guess you meant: just like ".ml" files?

I meant that they were like ".mli" files in that they must be compiled 
before a module that refers to them can be compiled.

>>> Which technology would then be used to run this code (Dynlink, static
>>> linking, toplevel-like technology for in-process compilation/execution)?
>>
>> Probably the same technology as the top-level.
>
>This seems to contradict the "need to be compiled" above.
>

Sorry, I meant the technology that the top-level uses to do "#load" 
directives. This is probably the same as Dynlink.