SPAM-LOW: Re: [nem-en] Metaphor, staging, typed reflection

[Sandro Magi]

Kamil Skalski wrote:
>> Yes, you need the class/assembly, but regardless, you still need to be
>> able to populate the fields, and this requires runtime reflection and
>> compilation/code generation. I'm not sure why it's not a valid example.
> 
> Why should you generate this code if you have the author's assembly at
> hand and you can force him to implement it on his side?

Yup, that's a viable approach, but the whole point of generic/polytypic
programming is that you don't need to duplicate all this code.
Duplicated code leads to bug proliferation.

>> The end result is the same. You're trusting some dynamic code generation
>> algorithm which isn't statically checked. Metaphor gets you at least
>> part way to static checking this code generation.
> 
> Right, if you want to enforce your own algorithm of populating
> fields...

So you're arguing against generic algorithms? The default serialization
provided by a language framework should be inherently safe, and .NET
uses this reflection-field approach via IFormatter. Of course, there is
no reason why you can't also provide custom serialization logic via some
ISerializable interface, but the generic default serialization is safe.

> But it doesn't make much sense, since the implementor of
> interface knows better how he wants to serialize his objects. Maybe he
> wants to omit some fields or compute the values basing on the others.
> It is much better design to avoid runtime code-generation in this and
> other similar cases.

This argument is valid, but it is not an argument against generic
algorithms. Yes, *sometimes* the developer wants to override the
defaults, but that doesn't mean there shouldn't be defaults.

> Also the security does not seem a good argument
> here, because you need to execute code from the plugin anyway.

Not a matter of security, but a matter of robustness. It's a simple
inference backed by empirical studies: the more code you have to write,
the more bugs you will have. Generic/polytypic algorithms lead to less
code, which results in fewer bugs. Less code also makes the design more
compact, more understandable, and easier to audit. I'm sure I'm
preaching to the choir on this.

Security is also a concern, but as you say, there is little isolation in
.NET anyway, which is a bigger security issue.

In any case, serialization of a dynamic plugin is only one such example
(mobile code, active networks, etc. being others). The .NET framework is
so rich in its native capabilities that most of the examples I could
give are already provided in some ad-hoc form, so the case is less
compelling.

But if you were starting a language from scratch, static reflection ala
intensional type analysis enable the host language to provide native,
tag-free GC [1] [2], unboxed function arguments and flattened data
structures [3], dynamic linking and pickling/serialization [4], generic
equality comparison, generic data structure traversals, type-safe casts,
cloning, hashing, debugging, and nominal and structural ad-hoc
polymorphism [5], all fully statically typed. Adding staging ala
Metaphor simply enhances the achievable performance.

[6] provides a comprehensive overview of the potential benefits of
statically typed reflection if you're interested. Static reflection
seems far too useful a construct to easily dismiss.

Sandro

[1] http://www.cs.princeton.edu/~danwang/Papers/safegc/
[2] http://citeseer.ist.psu.edu/wang01typepreserving.html
[3] http://citeseer.ist.psu.edu/56471.html
[4] http://reports-archive.adm.cs.cmu.edu/anon/2000/CMU-CS-00-161M.pdf
[5] http://www.cis.upenn.edu/~dimitriv/itaname/
[6] http://www.cs.helsinki.fi/u/lealanko/alanko04types.ps.gz