Barry SCHWARTZ (Barijo ŜVARC) (chemoelectric) wrote,
Barry SCHWARTZ (Barijo ŜVARC)
chemoelectric

Wow, this is easy

I hadn’t realized how much trouble the lack of static type-checking in Unicon was causing me. Admittedly, I know much better what I am doing this time, re-writing in Objective Caml, but now things tend to work the first or second time, because non-sensible code tends to be non-compilable. Yet the terseness for this code has been roughly that of Unicode; partly because, although Caml is extremely strict about types, I infrequently have to declare them, because the compiler infers the types of values from their context.

Even the most recent error I did find turned out to be avoidable if I had declared new abstract types for certain values represented by integers; I had mistaken keys and values for each other when working on an association table; now the keys are of type CharCode.t and the values are of type GID.t, so the compiler would have refused to compile the broken code, but at the time both keys and values were of the built-in type ‘int’, and the code was compilable but incapable of sustaining its own life.

In several cases where I used object classes in Unicon I have changed to using modules in OCaml, because these were more natural in those cases, and of course to learn the module system; my previous Caml programming was with Caml Special Light, which had a different module system.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments