My feedback would be to rather change the convention.
To me the fact that you have to explain anything here indicates that’s it’s maybe not such a great convention.
In most free software projects what I look for is src or src-* directories.
4 Likes
My feedback would be to rather change the convention.
Can executables without .exe and build without underscore (it could even be a hidden folder) be added to that wish list? And can the double semicolon be removed in the toplevel, too?
To me the fact that you have to explain anything here indicates that’s it’s maybe not such a great convention.
I agree; this is self-evident.
Old conventions only get replaced by using newer ones. Let’s code.
1 Like
12 posts were split to a new topic: Can the double semicolon be removed in the toplevel?
Oh, nonono, not that. The idea is
- you implement your module (let’s say, associative maps, and you implement using lists).
- Then you put an MLI file on it that doesn’t expose the type, and perhaps doesn’t even expose all the functions available on the type
- this constrains how downstream importing code can use that module
Now, you say “but a user can ignore the internals of the type, and not use those extra forbidden operations”. But this is asking a lot of users, and I can tell you that I’ve used this method to ensure – to ensure – that I don’t use forbidden operations or depend on details of the implementation of some type.
Outside of ML-like languages, this has a long history, so ML didn’t invent this. it’s very, very, very well-established in PL design, that languages can provide a way to export a module with a constrained interface, so that exploiting code can only count on the interface, and not on module-implementation details.
People who build complex systems use this capability a LOT to structure their code: it allows them to (1) implement multiple versions (e.g. list, hash, AVL versions of associative maps) with identical interfaces, making it easy and safe to switch, (2) ensure that they don’t depend too much on the details of some module.
1 Like
“bin” stands for binary. You might try to twist that it stands for bin in the sense of “bucket”. But that’s where it throw my trash in. I have to admit, that sometimes my source is trash. But I’m not suggesting to name the source-folder “trash”.
Binary has nothing to do with the OS. “app” or “exe” is more attached to MacOS or Windows. Binary data is not human readable, binary data streams are not tied to any OS. But they are tied to “not human-readable” in the whole world of IT, in contrast to a say text stream.
No, that’s not what I’m saying!
The interface exposes how to use the implementation and what is available to the user. Just that. The idea to look at the implementation to pick out “great” functions is contradicting to the concept of interfaces. I think I don’t have to explain the word “interface”. 
When I’m fluent in a language, I first implement the interface (from the POV of the user) and then do the implementation.
Just yesterday, I designed an interface in Ocaml (admittedly sketchy, I’m not fluent in Ocaml) and then went to the implementation. When writing the implementation, I realized that the simpler ones help me implement the complex ones. I already kew what I will have.
bin has long precedent in the Unix world as a directory to put executables in. Check our earlier messages where we were talking about /bin, /usr/bin, /usr/share/bin, and so on. It’s not about ‘buckets’, it’s more in the sense of ‘binary executables’. Even on macOS you will find these directories in the filesystem.
I am convinced that your irony-detector is not properly adjusted.
Irony with a markup no longer is irony.
Irony assumes that the receiver is capable enough to understand it.