DO NOT MERGE: Compiling Eliom with the new compiler #459

Open
wants to merge 23 commits into
from

Conversation

Projects
None yet
4 participants
@Drup
Member

Drup commented Jan 1, 2017

Happy new year everyone, I come bearing eliom gifts! 馃巺

This is my WIP branch for attempting to compile eliom (the framework) with eliom (the compiler, aka eliomlang).

This needs:

New features:

  • Proper typechecking of injections and fragments. No dirty tricks.

  • Typechecking is mindful of sides, and will give good errors when using identifiers on the wrong side and various other kind of errors.

  • The default side in eliom modules is, like OCaml modules, "sideless": Code written here can be used everywhere (but cannot use special eliom features and can not use any code that has a side).
    To enter a side, like currently, use %client/server

  • Types can be given a sideness annotations. Here is a very contrived example:

    type%server ('a[@client], 'b) t = ('b, ('a * string) Eliom_client_value.t) Hashtbl.t

    The typechecker will ensure that annotations are correct (and will force you to annotate your datatypes).

  • The module language is now aware of sides, and most things you can think of should work.
    In particular, sections can be used inside flat modules (not functors):

    module M = struct
      let%server x = ...
      let%client y = ...
    end

    (See the testsuite for a set of contrived examples)

  • Only one compiler invocation needed per module.

For now, only bytecode compilation works (no blocker, just haven't taken the time to patch the opt frontend yet).

Current situation

  • All the syntax extensions have been removed
  • The tools have not been removed yet, but are useless.
  • All the Eliom_shared related things have been disabled for now. The API need to change a bit.
  • The ocamlbuild plugin has been reworked significantly, but it's still pretty much broken right now.

Currently, the main problem is the build system. ocamlbuild is very extensible ... except in the various ways that would help us, so the predefined rules don't work well. I might attempt to use solvuu (cc @agarwal) (but I'm getting a bit burned out on build systems right now).

Here is how building eliom libraries with the new compiler should work:

  • Building foo.eliomi produces one cmi: foo.cmi
  • Building foo.eliom produces two cmo: foo.client.cmo and foo.server.cmo
  • A new option, -mode client|server is available for compiling regular OCaml files, and marks the produced cmi as being client/server
  • When loading a cmi files, the compiler will detect .client.cmi and .server.cmi files (or marked files) and consider them as client/server for the purpose of typechecking.
  • When searching for dependencies, the build system should be mindful of *.client|server.* files (this is extremely badly handled by ocamlbuild).
  • When bar.eliom depends on the module Foo and there exists both a foo.client.cmi and foo.server.cmi, the eliom files should depends on both (this cause issues with ocamlbuild dependency discovering).

If anyone want to try this, bug reports related to the new compiler should be made here.

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Jan 2, 2017

Member

Note: the new compiler is 4.03.0 only for now. Will port to 4.04 when I have time.

Member

Drup commented Jan 2, 2017

Note: the new compiler is 4.03.0 only for now. Will port to 4.04 when I have time.

@agarwal

This comment has been minimized.

Show comment
Hide comment
@agarwal

agarwal Jan 2, 2017

I might attempt to use solvuu (cc @agarwal)

Let me know if I can help somehow.

agarwal commented Jan 2, 2017

I might attempt to use solvuu (cc @agarwal)

Let me know if I can help somehow.

@agarwal

This comment has been minimized.

Show comment
Hide comment
@agarwal

agarwal Jan 2, 2017

Building foo.eliomi produces one cmi: foo.cmi

Can you clarify? You do need separate cmis for client and server side, as several of your subsequent points refer to.

agarwal commented Jan 2, 2017

Building foo.eliomi produces one cmi: foo.cmi

Can you clarify? You do need separate cmis for client and server side, as several of your subsequent points refer to.

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Jan 2, 2017

Member

Can you clarify? You do need separate cmis for client and server side, as several of your subsequent points refer to.

No. eliom cmi contains more information (encoded in ppx attributes) that specificy sides of the various declarations.

The presence of .server|client.cmi comes when you have .client.ml and/or .server.ml (which happens a lot in eliom itself). Maybe we should get rid of that, that would certainly simplify things, but I was a bit wary of doing that ...

Member

Drup commented Jan 2, 2017

Can you clarify? You do need separate cmis for client and server side, as several of your subsequent points refer to.

No. eliom cmi contains more information (encoded in ppx attributes) that specificy sides of the various declarations.

The presence of .server|client.cmi comes when you have .client.ml and/or .server.ml (which happens a lot in eliom itself). Maybe we should get rid of that, that would certainly simplify things, but I was a bit wary of doing that ...

@dannywillems

This comment has been minimized.

Show comment
Hide comment
@dannywillems

dannywillems Jan 3, 2017

Member

The presence of .server|client.cmi comes when you have .client.ml and/or .server.ml (which happens a lot in eliom itself). Maybe we should get rid of that, that would certainly simplify things, but I was a bit wary of doing that ...

It would be great to get rid of these suffixes. Client (resp. server) codes must be in a client directory (resp. server). Same for shared sections.

Member

dannywillems commented Jan 3, 2017

The presence of .server|client.cmi comes when you have .client.ml and/or .server.ml (which happens a lot in eliom itself). Maybe we should get rid of that, that would certainly simplify things, but I was a bit wary of doing that ...

It would be great to get rid of these suffixes. Client (resp. server) codes must be in a client directory (resp. server). Same for shared sections.

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Jan 3, 2017

Member

It would be great to get rid of these suffixes. Client (resp. server) codes must be in a client directory (resp. server). Same for shared sections.

I disagree. With the new compiler, we should be able to get to the point where you can put your files in any directory you want, regardless of the fact that they are client, server or eliom. The separation in client and server directories is an artifact of the old compilation scheme and is pretty opposite to the point of eliom (which is to group things by what they do, not where they are executed).

If that's how you want to do things, you should be able to, but it should not be imposed.

And in particular, for eliom, I would really rather have it organized in: base/ runtime/ content/ services/ communication/. We mostly couldn't do that before, because of messiness of the build system.

Member

Drup commented Jan 3, 2017

It would be great to get rid of these suffixes. Client (resp. server) codes must be in a client directory (resp. server). Same for shared sections.

I disagree. With the new compiler, we should be able to get to the point where you can put your files in any directory you want, regardless of the fact that they are client, server or eliom. The separation in client and server directories is an artifact of the old compilation scheme and is pretty opposite to the point of eliom (which is to group things by what they do, not where they are executed).

If that's how you want to do things, you should be able to, but it should not be imposed.

And in particular, for eliom, I would really rather have it organized in: base/ runtime/ content/ services/ communication/. We mostly couldn't do that before, because of messiness of the build system.

@dannywillems

This comment has been minimized.

Show comment
Hide comment
@dannywillems

dannywillems Jan 3, 2017

Member

@Drup I suppose [%%section.start] and [%%section expr] doesn't exist anymore?

Member

dannywillems commented Jan 3, 2017

@Drup I suppose [%%section.start] and [%%section expr] doesn't exist anymore?

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Jan 3, 2017

Member

@dannywillems They do. The first one is implemented in eliomlang.ppx, the second one is handled by the compiler directly.

Member

Drup commented Jan 3, 2017

@dannywillems They do. The first one is implemented in eliomlang.ppx, the second one is handled by the compiler directly.

@FlorentBecker

This comment has been minimized.

Show comment
Hide comment
@FlorentBecker

FlorentBecker Dec 22, 2017

Contributor

Any news about this effort, anything one can do to help?

Contributor

FlorentBecker commented Dec 22, 2017

Any news about this effort, anything one can do to help?

@Drup

This comment has been minimized.

Show comment
Hide comment
@Drup

Drup Dec 22, 2017

Member

@FlorentBecker The first step would be to port my patches to the last version of the OCaml compiler. Then there are a few things to tweak/fix. Unfortunately, I don't work on Eliom anymore and the rest of the ocsigen crew doesn't have time to spare at the moment.

If you are motivated, Please go on. I will gladly answer questions.

Member

Drup commented Dec 22, 2017

@FlorentBecker The first step would be to port my patches to the last version of the OCaml compiler. Then there are a few things to tweak/fix. Unfortunately, I don't work on Eliom anymore and the rest of the ocsigen crew doesn't have time to spare at the moment.

If you are motivated, Please go on. I will gladly answer questions.

@FlorentBecker

This comment has been minimized.

Show comment
Hide comment
@FlorentBecker

FlorentBecker Dec 22, 2017

Contributor

If you are motivated, Please go on. I will gladly answer questions.

It's hard to see how much effort it's worth putting in it without knowing what the ocsigen team is up to.

Contributor

FlorentBecker commented Dec 22, 2017

If you are motivated, Please go on. I will gladly answer questions.

It's hard to see how much effort it's worth putting in it without knowing what the ocsigen team is up to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment