eliom
eliom copied to clipboard
ocsigen
file extension matters
$ cat foo.ml
[%%server
let x = 42
]
$ js_of_eliom -package eliom.client -ppx -o foo.cmo foo.ml
File "foo.ml", line 1, characters 3-9:
Uninterpreted extension 'server'.
$ mv foo.ml foo.eliom
$ js_of_eliom -package eliom.client -ppx -o foo.cmo foo.eliom
(* success *)
I understand that js_of_eliom infers extra packages based on the file extension, so I can get around this by doing:
$ js_of_eliom -package eliom.client,eliom.ppx.client -ppx -o foo.cmo foo.ml
(* success *)
However, adding eliom.ppx.client to js_of_eliom is something I was avoiding due to the issue I reported on the mailing list. So now it seems my build rule needs to be: pass eliom.ppx.client if the file extension is .ml, but don't if it is .eliom. Or alternatively, require myself to follow exactly the file naming scheme assumed by the eliom command line tools (and the directory structure due to issues also reported in the same email thread). This is all very restrictive and makes building eliom projects very fragile.
The fact that eliom annotations are only avaiable in eliom files and that normal ml files are not touched at is a pretty important property.
Calling only half the ppx extensions like that is a recipe for troubles, as you discovered.
Is there a reason you don't want to rename your file to .eliom ?
Is there a reason you don't want to rename your file to .eliom ?
I certainly can. However, the minor reason was that I often start a module that generates content purely from the server side, so thus the file extension is .ml. Then I start making the content more interesting and start writing mixed client/server code. At that point I have to change the file extension from .ml to .eliom, which makes it harder to review git history. Not a big deal, but I imagined myself renaming files all the time and was thinking that maybe I'll standardize on never using the .eliom extension.
On the one hand, it's no big deal. On the other hand, since it is a trivial thing, why can't I make the choice I want. To me it indicates some design flaw that might be worth investigating. This combines with a handful of other file name and path issues, which together aren't totally trivial.
Why not start files that "could contain annotations" directly as .eliom files instead ?
Applying the eliom language extension is not "a trivial thing". The code transformation is involved, it has various build consequences (multiple cm[iox] files). It's very important, from a correctness/confidence point of view, to be able to say "okay, these files are pure OCaml without eliom stuff, we just don't touch them".
In general, as you rightfully pointed out, the current implementation of the eliom language extension is unsatisfying. The new version of this implementation should be available soonish™, and solves quite a few issues. However, it still respects the criterion that eliom annotations should only be used in eliom files.
Why not start files that "could contain annotations" directly as .eliom files instead ?
Indeed, good enough for my short term needs.
Applying the eliom language extension is not "a trivial thing".
That's not the thing I meant as being trivial. The trivial thing is to treat a file as if it is an eliom file regardless of what it's actual extension is. For example, the ocaml compiler also interprets file extensions, but provides the -impl and -intf options to let you use other extensions if you want to.
The trivial thing is to treat a file as if it is an eliom file regardless of what it's actual extension is.
Indeed, the new implementation does provide this.
If we add an option --force-eliom (or --ignore-extension, or something to that effect) to the current eliomc / js_of_eliom, would that be of any help?
