A related feature is SML’s
local-in-end which I very vaguely miss (not just in Elm but in any language). So with
local-in-end you could do something like:
definition_one = ...
definition_two # which uses definition_one
definition_three # which also uses definition_one
If it were only
definition_two that used
defintion_one then you can quite nicely communicate that
definition_one is not used outside of
definition_two by simply having a
let, but if
definition_one is used by more than one it becomes very awkward to restrict its scope. You can do it, but it’s awkward. I feel that
local-in-end really “says what I mean”. Mostly, it’s nice to restrict the scope of
definition_one because then I can give it a quite short name, whereas with a larger scope I probably have to be a bit more precise in the name.
As I say, I only very vaguely miss it. But if you had that, then I would suggest that that would be one place to put in a more localised import (I haven’t used SML for a very long time, but I don’t recall being able to do localised imports using local-in-end, but it obviously could in theory be allowed).
Of course, if you generalised just a bit from there, you could just have a nested module. Since modules can already be nested there isn’t much preventing nested modules other than syntax (and the notion that a module is tied to a file).