Hello,
Over the past few months, I have been working on an implementation of the
ML Basis system for Poly/ML. It supports the complete mlb spec and is available
both as a library and a cli tool:
https://github.com/vqns/polymlb
On a side note, I have been trying to implement incremental compilation by caching
compiled .mlb files (i.e compiler namespaces) and exporting and reimporting them
through {save,load}ModuleBasic. I have however been running into the issue that
exporting each .mlb to a different on-disk module causes opaque types mismatch
when reimporting them. What would be the reason for that?
I have managed to work around it by exporting everything to the same file, but
that result in a fairly large cache, e.g ~45mb for smlfmt (1.2mb executable, 15k loc).
I suppose the reason for that is that I export the basis library as well, but I'm not sure
there is a solution for that.
Dear SML people,
There is an OCaml feature proposal by Alistair O'Brien that would
finally introduce tuple indexing in OCaml -- we currently have only
whole-tuple pattern matching:
RFC:
https://github.com/johnyob/ocaml-RFCs/blob/tuple-projections/rfcs/tuple_pro…
discussion: https://github.com/ocaml/RFCs/pull/57
Of course this raises the Very Important Question of whether indexing
should be 0-based or 1-based.
The argument in favor of 0-based is that it is what we use for arrays,
so more consistent, standard in most programming languages. The argument
in favor of 1-based is that it is arguably more intuitive (but the
inconsistency with arrays weakens this claim noticeably), and that SML
uses it.
Question: you have a lot more experience using tuple indexing. In your
opinion, if this was to be decided again for a new system (no
backward-compatibility concerns), would you still recommend using
1-based indices, or would you be more in favor of 0-based indices?
P.S.: You may be amused to learn that OCaml recently introduced "labeled
tuples" (looking like `(x:1, y:2)` in expressions and `(x:int * y:int)`
in types), which are basically a restricted version of SML structural
records -- type inference does not try very hard and requires an
annotation in practice.
P.P.S: Is there still a mailing-list for the SML/NJ crowd? All I could
find were github discussions (https://github.com/orgs/smlnj/discussions)
and an invite-only Zulip.