[MLton] Ad-hoc infix identifiers, Printf, and libraries
Matthew Fluet
fluet@cs.cornell.edu
Thu, 14 Jul 2005 20:16:28 -0400 (EDT)
> > I thought that was very cool. I've been very jealous of Haskell's `id`
> > infix syntax, and I think <\id\> is fairly concise. I had also forgotten
> > about the sectioning functions, which are also great. [...]
>
> Thanks! I'll take that as an invitation to add a page on the technique to
> the Wiki.
Please do.
> Introducing a top-level infix identifier in SML can easily break code far
> away. Thus, mnemonic names (like `when', `by', `bind') are pretty much
> off-limits for infixing at the top-level (in a library). For instance,
> different binding strengths can be useful for an identifier in different
> cases and having multiple top-level fixity declarations (with different
> binding strenghts) for an identifier might cause some rather subtle bugs.
Right. This is where a principled use of the ML Basis sytem could be a
real win. I imagine something like:
foo.mlb:
local
libA.mlb
libB.mlb
in
foo.sig
foo.sml
end
foo.sml:
structure Foo : FOO =
struct
open A B
...
end
As long as libA.mlb and libB.mlb export the right fixity directives for
their respective libraries, then within the body of Foo, you will have
them, but clients of Foo won't have them.
OTOH, I admit this might be too principled, entailing a .mlb, a .sig, and
a .sml per module. But, it means that one can very easily track down the
binding occurences.
> Do/Can SML compilers issue warnings for incompatible fixity declarations?
I don't know any that do. I don't think it would be hard to.
> You may be right. Perhaps I'm worrying too much. For application
> development top-level infix declarations are reasonably safe. For
> library development the issue is more difficult. Libraries defining
> mnemonic infix identifiers are likely to cause problems.
Again, I don't think it is that big a problem. If you choose to import a
library, it means you are interested in using it, so you want to have the
recommended infix decls in scope.