Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code

I stand by my statement: "An SML program which successfully typechecks
will not bomb at runtime". Such a program may include a storage leak and
therefore (ultimately) run out of memory, but it will not core-dump except
in this eventuality. "bomb" = "core-dump" in my vocabulary (under Unix).
Since alloc (and free) is implicit in SML, storage leaks are reasonably
rare and easily rectifiable (they are usually infinite loops).


Quasi-SML programs (e.g. an undoable thread pre-emptive scheduling and
management system which I maintain, which compiles with the SML/NJ
compiler but is not strictly SML) may not obey this rule (but in practice
do). Such code is very unusual (for instance, a 30k line compiler I once
worked on was _entirely_ pure SML). Of course typechecked SML code
contains bugs, but the few remaining bugs are of the `irritatingly subtle'
variety which crop up in any language. Removing them is easier than in
(say) C because one doesn't have to check through all the different
possible sources of the bug.


This is the nature of SML; if you regard the type system as too
restrictive, don't use SML. Having hacked extensively in both C and SML I
am in a position to state that the programming cycles (for me) compare
like this (on similar-sized pieces of code):


C: (edit-compile)x20, (edit-compile-bomb)x20, (edit-compile-run)x50
SML: (edit-typecheck)x5, (edit-compile-storageleak)x3, (edit-compile-run)x10


Nick Haines nickh@cmu.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.