On Dec 2, 1:29 pm, Vesa Karvonen <vesa.karvo...@[EMAIL PROTECTED]
> wrote:
> Note that introspection
> is not exactly free. Having introspection means that a lot of metadata
> needs to included in the binary and that many optimizations cannot be
> performed (or are hindered). For example, if SML provided run-time
> introspection to allow one to iterate over the values in a structure,
you
> could not, for example, safely eliminate unused values from a structure
or
> inline a definition at all use sites and then eliminate the definition.
> The compiler also couldn't make data representation optimization, such
as
> eliminating unused fields from records or unused variants from
datatypes.
> All of the previous kind of optimizations (and more) are performed
> aggressively by MLton, for example. So, introspection isn't just a
> blessing --- it is also a limitation.
I don't buy your argument. A few bytes spent in docstrings are a
non-issue when we all have hundreds of gigabytes of unused
disk space. And even if some dead code was not removed by
the compiler, would it matter much, in practice? I am of the
opinion that if an user wants an optimization, it should say so
explicitely with a compiler flag: by default he should not pay
the price of the optimization.
> Personally, I don't find introspection crucial. I've used
> introspection quite heavily in Java, for example, but mostly as a
> workaround for some other deficiency. In particular, when you have
> lightweight anonymous functions, infix operators and lightweight
> syntax for calling functions, many of the uses of introspection can be
> encoded concisely.
Yes, I understand that I can define something like
datatype ('a, 'b) function_with_docstring = FUN of ('a->'b) * string
val double = FUN (fn x => 2*x, "A function doubling its argument")
and even implement a mechanism to register all the docstrings
and possibly other informations such as names and types, but
frankly this sounds to me like a job for the language, not
for the user. As I have said before, it looks absurd to me
that information which is available to the compiler (even
if absence of a REPL the compiler knows the signatures, which
is the things which are more im****tant for a do***entation
tool, even in absence of docstrings) is hidden to the user.
And what if I wanted to code an IDE for SML? It looks
impossible without resorting to help from the underlying
implementation.
> Note that this approach is not without advantages over the ad hoc
approach
> of grepping for functions named as "test"s. In particular, it allows
you
> to conveniently define new test registration specifiers. See here for
an
> example:
>
>
http://mlton.org/cgi-bin/viewsvn.cgi/*checkout*/mltonlib/trunk/com/ss...
I will look at the example, but since I am lazy I will ask
a question before. How are implemented registers in SML?
I would go with something like this
val registerList = ref []
fun register(name, function) =
registerList := (name, function) :: ! registerList
or with a StringMap if I wanted to be able to retrieve functions
by name. However, a register works with side effects and I am told
that functional languages should avoid side effects as much as
possible; nevertheless I don't see how to avoid mutating the
reference here.
Michele Simionato
|
