💾 Archived View for republic.circumlunar.space › users › dbane › gemlog › 2022-09-05.gmi captured on 2024-05-12 at 16:00:04. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
I have a small backlog of posts to get out, this is the first one.
I've read and enjoyed several blog posts like this. In particular, Prolog was an eye-opener for me. I studied it in college, but didn't realise until long afterwards that there was an industrial-quality infrastructure and libraries beyond the fragment we learned, perfectly suitable for commercial software development.
My minor contribution to the genre is for Standard ML. First, I recommend a book, it is much better than this post.
Unix System Programming in Standard ML
Returning to my own opinion, what compiler to use? I recommend Poly/ML, it may not be the fastest, but it *is* a native code compiler and can target the platforms I'm interested in.
Next, tools and/or libraries. SWI-Prolog made good progress by just offering a JavaDoc-like documentation generator and unit test framework.
For documentation generation, I recommend Natural Docs. This is available in OpenBSD's package collection, it's the old version 1.52 but still fine. It's applicable to any language with comments. The required config file and an example marked-up signature follow.
Config file, to go in "naturaldocs" dir
Sample marked-up module interface
For testing, as an experiment I'm trying to express the test cases as contracts instead, using the library in mltonlib (which despite the name is not all specific to mlton). Time will tell how well this works.
Finally, a build system is something that's lacking for SML. So I use the same build system that mltonlib uses, extended slightly based on reading sml-buildscripts too.
This has all been integrated into a CI pipeline, which can be extended to handle deployment.
Coding nowadays can involve integrating various open source libraries into your application. There are two tools to manage this for SML: Smackage and smlpkg. But I could only get Smackage to work.
Smackage supports fetching source code to a well-known location; and running commands like "make ..." there. I wrote .smackspec files to define packages for code I wanted to use, and the maintainers were very helpful in accepting these pull requests and tagging so that Smackage could work.
This handles fetching & loading dependencies. For the final dump of an ELF file to disk, I use one line from sml-buildscripts but no more. This turns out to be almost identical to how some test code from mltonlib built too.
If build times are a problem in future, I can switch over to the PolyML Make feature, but that will then be non-portable.
I'm happy with this. In particular, it lets me integrate new libraries quickly. For example, once I fixed up sml_tk enough to build, all I had to do was write ".smackspec" and ".use" files to integrate it.