[MLton] OpenGL (currying + library guidelines)
Anoq of the Sun
Mon, 25 Jul 2005 12:43:19 +0200
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
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
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...)
http://www.anoq.net/music/ - creative instrumental electronic music