Language-Design

For a long time I’ve been sceptical that using the file system to denote modules in a programming language is necessary. There are many good reasons to do this as things currently stand, but most of these reasons can, and arguably should, be solved with better tooling. For example from the post linked to above: why would we equate a file to a form of encapsulation? Why, would we wish to divide any application into a bunch of files in the first place. If you ask this question, you get a bunch of answers, but they mostly fall into two categories: 1. some vague notion about organisation and modularising your code and 2. it is easier to navigate whilst coding. I would argue that the first is nonsense, since no one is arguing against modularising code, only that the file system does not need to come into it. The second is potentially true, but rather speaks to a deficiency in your coding environment (text editor/IDE) rather than to the efficacy of using files to modularise a program’s source code. ...

Elm has followed many other languages in equating a file to some form of encapsulation unit, in the case of Elm this is a module, much like it is in Haskell, Java used a class. In Java it is possible to define a nested class, and in most forms of the ML family of languages (SML, O’caml) you can define nested modules. In particular there is no reason why a single file need define one and only one module. ...