[MLton] OpenGL (currying + library guidelines)

[Anoq of the Sun]

I stumbled on this mail, sorry if my answer is obsolete, but
it also contains some guidelines which might be useful in general.

Mike Thomas wrote:
> Stephen wrote:
> |   * using tupled arguments
> |   * renaming values (dropping the redundant prefixes)
> 
> I also like the idea of curried functions as it makes function application
> easier to my Haskellised way of thinking - I may be missing something about
> how SML people work with curried functions though, as I'm not very
> experienced with SML.

I would also _strongly_ recommend using tupled function types.
Some guidelines, pros and mostly the cons pinned out about currying:

Pros: We know those ("we" referring to those used to
       functional programming...), it's very convenient on
       many occasions.
Cons: 1) It is possible to forget one or more of the last arguments
          in a function call. Now, if the nature of a function is
          such that it returns a useful value that one is typically
          interested in using - e.g. the result of a lookup function
          in a data structure, then you will be told if you forgot
          an argument, by the type-system of ML. However, if a
          function does not return a useful value, or if it returns
          a value that one might not always want to use, then
          it is _quite_ easy to forget an argument. If the purpose
          of a function is to give a side-effect and it just returns
          unit, then this is an obvious place where using record
          arguments or tuple arguments may be in favour of currying.
       2) The type errors that one has to deal with are usually
          a little more complex.
       3) While one ordering of the curried arguments is sometimes
          convenient, at other times it is another order of the
          arguments. It is thus not always possible to make
          a sensible ordering of the arguments for currying
          to always be most useful.
       4) Currying most likely has a computational price,
          especially if it is exported though a foreign function
          interface (FFI) or similar.

Something about FFIs, when to use libraries and when not to:

1) Certain things make very good sense to put into a library.
    This is mostly things which both have a substantial size
    and a well-defined interface (preferably with low band-width).
    This also goes for interfaces to external hardware and the likes.
    Examples: RenderMan interface, OpenGL interface, graphical user
              interface toolkits etc.
2) Certain things should never be put into libraries.
    In particular things which are small in size or have
    high-bandwidth interfaces.
    Canonical examples: The Standard ML Basis library,
                        other small utility functions.

    The best is of course for the compiler to be able to optimize
    (e.g. inline, specialize, monomorphize etc.) on such things.

    To take the argument of never passing through an FFI
    further, if the Basis Library has bugs, an application
    using the Basis might have corresponding work-around bugs,
    so just upgrading a .dll or .so with a new basis
    might actually crash applications using it - so
    not even from a maintainance point-of-view is it
    a good thing to e.g. isolate it in a .dll or .so file.

    Alas, it is not exactly very good that libc is not
    compiled into all Linux applications.
    Binary incompatibilities of libc is possibly the
    biggest headache of installing Linux applications
    today! We wouldn't want the SML Basis
    to become a similar obstacle for ML programs, would we? :)
    In fact, an ML-compiler producing Linux binaries
    without using libc could give some serious competition
    to C-programs on Linux ;)

(note: part of this mail is intended for discussion on the
SML Basis list, which explains some of the SML Basis centricness...
it's part of a longer mail that I will hopefully post there soon...)


Cheers
-- 
http://www.HardcoreProcessing.com
http://www.anoq.net/music/ - creative instrumental electronic music