[MLton] FreeBSD port broken, FIX, and a hello again note

[Jesper Louis Andersen]

Currently, the FreeBSD port is broken. This is due to an upgrade of
libgmp so it bumps from .so.6 --> .so.7. The bootstrap file is not
statically linked, so it borks on the missing libgmp.so.6.

The fix is to note that you do not need libgmp at all inside mlton, so
by symlinking .so.7 to .so.6, the compile goes through effortlessly.
I've tested a binary compiled like this on the regressions and it goes
through without any kind of error.

To maintain a FreeBSD at the newest ports-tree, I'd recommend the
following approach.

1. Get portsnap. It might be in the base system. 

2. Run portsnap fetch (it might be adviseable to
edit /etc/portsnap.conf). 

3. THIS STEP KILLS YOUR PORTS TREE AS IT WERE: Run portsnap extract

Now you have the newest ports tree. Upgrades to the ports tree with this
process is a run of portsnap fetch followed by portsnap update. This
does _not_ kill local changes to the tree.

4. Install /usr/ports/sysutils/portupgrade

5. Run portupgrade -a. This will upgrade your ports to the newest
versions. You may have to run pkgdb -F to update the dependency links of
the portupgrade database. Sometimes, when ports are upgraded, the
dependency links are not directly computeable by the portupgrade tool
and manual intervention is needed. 

6. Build The FreeBSD bootstrap file. Regress test it. It should go
through (mine did). Verify it links with the new libgmp.so.7 (ldd -v
should do the trick). 

7. Submit a patch against the port. It should contain a new checksum and
a new file name of the bootstrap file. Also, the BROKEN variable should
be removed.

I could have built the bootstrap myself, but I think it should come from
a trusted source (One with commit bit to the repository).

The severity of this for me is fairly low. I have run the above fix
after all (And did a development compile as well. Works flawlessly and
goes through all regressions). But the port faces the danger of being
expelled from FreeBSD if not updated. Rather than having to fix it when
a warning message gets mailed, I wanted to be proactive about it.

Yes, I am back on hacking SML again. I tried Haskell. 2 Problems were
noted: Performance, especially space consumption is hard. And monad
transformer stacks means you have to rewrite whole functions when you
swap monads in the stack. This is quite irritating for big programs. We
actually tried to write a bittorrent implementation via STM (STM is
read-copy-update or transactions on memory slots for concurrent threads.
It can of course be shown to be a monad. The paper is by Simon Peyton
Jones for the interested.

I also tried Scheme. It is a pretty language, but what I dislike about
it is the lack of a type system. I think my exposure to SML as a first
programming language has poisoned me. Writing bigger programs is also
hampered by the lack of a module system (Is to be fixed with R6RS
though). What I _did_ like is the SRFI process. It mimics the RFC
process from an implementation perspective of language features.

The advantage of the SRFI process is that the Basis library gets
extended by a standards process a little more loose than what the SML
Basis Library effort delivers. The main reason for the SRFI process,
however, is that different Schemes are quite non-portable (sadly). SMLs
formal definition will probably make portability simpler.