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

[Kamil Skalski]

2007/1/7, Sandro Magi <smagi at higherlogics.com>:
> 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.

This code of course would be generated, but at compile-time on the
provider side, not at runtime on consumer side... I feel no sorry for
physical code duplication as long as this fact is hidden in every day
use - BUT if I really need to inspect the serialization routine, I
want to be able to do this.

>
> >> 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

Absolutely no! I'm arguing against pushing such delicate and hard task
as generating code to the runtime. One of the most insightful opinion
about macros, which appeared some time ago on this list is that macros
are not hard to write, they are hard to debug. Static multi-staged
typing helps with generating correct code, so it helps to solve this
problem - but delegating any code generation to the runtime makes it
much harder.

>
> > 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.

Of course. I also agree that the most commonly used and reliable
defaults / algorithms should be completely hidden into the framework
(OS / .NET / your own set of classes).
But for me it does not imply runtime code generation. Maybe it must be
some raw-data processing, maybe execution of dynamically typed scripts
(not that they are better than compiled plugins + good interfaces, but
usually easier and faster to write and deploy).

>
> > 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.

I agree, but it has nothing to do with  compile-time / run-time
dispute we are having here.


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

There is CAS, which I guess is quite good at isolating the execution.

>
> 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.

Most of those features as I can understand them (I'm not familiar with
all) are also possible to implement as compile-time analysis and code
generation. This has the ultimate advantage of giving you ready code
to look into, debug, analyze and feed to utility tools (like  IDE,
which shows you the class members you generated).

Maybe a little example. In my project I wanted to add the "properties"
mechanism to allow configuring its behavior. They are usually just key
value pairs of various type (integer, boolean, string). So I created a
macro to fetch the key-value pairs from data-base, generate the fields
in a specified class, layout them in nested hierarchy (they are
organized in tree like "namespaces"). Now I can access them in IDE and
code completion allows me to choose the desired key very fast. I can
also easily inspect the whole tree of properties.
This level of integration is possible just because of compile-time processing.

I think that this is turning too much into a flame-war... :(  I
suppose there are many valid examples, where run-time code generation
is more powerful, easier, etc. and I think any research to make it
more safe is a very good thing. But for me design-time / compile-time
generation has numerous advantages and I prefer making my designs go
into this direction.

>
> [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
>

Thanks for references, they all seem very interesting. I will look at
them if I have some free time :)

-- 
Kamil Skalski
http://nazgul.omega.pl