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

[Sandro Magi]

Kamil Skalski wrote:
>
>> Indeed, some safe dynamic programs will fail to type-check; it's the
>> trade off with any sort of static type safety.
> 
> I was rather referring to the problem of possible failure in dynamic
> programs, not possible to catch by such system.

This can only happen by explicit casting, in which the developer is
intentionally overriding the type checker.

> I think that the most
> common usage of reflection is in totally dynamic context (the paper
> divides its use-case into three groups: static - typeof (A),
> semi-static - x.GetType()   and dynamic  GetType ("anyname") where you
> have absolutely no guarantee about types of members in object
> hierarchy. In such context the typing constraints will simply have to
> be disabled to execute code generation or will fail on some casting.

Unless I'm misunderstanding your objection, this is the purpose of the
'typeif' construct; it's a static, staged version of "if (o is TYPE)".
See "intensional polymorphism" and "intensional type analysis" for the
source of this construct. It is generally used for the base types the
algorithm must handle (ie. 'int' in the limited serialization example).

> What I really consider bad is that it happens at run-time of you
> program (that is not during development / tests, but during
> production). That is why I think that making static ensures about
> dynamic code generation is quite interesting, but rather not very
> useful.

I believe you are referring to Page 10:

"If however the type to be serialised is not statically known then the
serialiser can only be invoked through a dynamically-typed invoking
function [...] Although the invoking function is dynamically-typed, the
code inside it is not (except for the initial cast). The purpose of the
cast is to prevent an object of the wrong type from being serialised."

Of course, this is no worse than currently deployed solutions in C# and
Java, and much software designed in this way is still quite useful.

Full knowledge isn't possible in such situations anyway. Take an O/R
mapping tool like NHibernate for instance; NHibernate must be able to
dynamically serialize an object to a relational table, and the type of
the object can *never* be known ahead of time.

The benefit of writing NHibernate in Metaphor is that staging the
serializer means each type will "automatically" receive a
specialized/partially-evaluated serializer which will be JIT compiled,
and thus quite fast. Only recent releases of NHibernate have just such a
JIT-compiled "serializer", and it had to be written manually using
Reflection.Emit.

> BTW, I am a great fan of static-typing and I consider Metaphor's
> system MUCH better than doing similar things by pure reflection with
> some textual code generation, which is on the other hand the most
> common technique used these days in C# and Java. So my points should
> always be placed in context of Nemerle's availability, which offers an
> "effectively" safer solutions.

I haven't developed with Nemerle's macros, but I haven't seen anything
that indicates they are safer. Except perhaps in the sense that
compile-time macros limit one to compile-time staging, thus potentially
reducing runtime errors. Is this what you meant?

If so, how would a Nemerle macro handle the generic serializer example
such that it would be safer than that provided in the Metaphor paper?

Sandro