http://joeduffyblog.com/2013/12/27/csharp-for-systems-programming/#comments
Note this is a new research language from msr. Lots of interesting stuff in
the comment especially about reflection.
Ben
-------- Original message --------
From "Jonathan S. Shapiro" <[email protected]>
Date: 2014/04/09 12:35 (GMT+08:00)
To Discussions about the BitC language <[email protected]>
Subject Re: [bitc-dev] Reflection and Introspection
On Tue, Apr 8, 2014 at 8:34 PM, Ben Kloosterman <[email protected]> wrote:
Re self modifying -
Are we sure that we cant call the compiler and compile this to a new "assembly"
and run that ? In most of these cases start-up time is not an issue ( since
reflection is slow anyway) . I really don't like self modifying code... there
are so many issues.
I hesitate to generalize from a limited number of examples, but let me talk for
a moment about the two examples I have been thinking about.
The first is bitblt. In the case of bitblt, the issue is that a given bitblt
operation occurs at some bit offset relative to a word boundary. Depending on
the particular bit offset, different shift instructions need to be emitted. The
argument that determines the bit offset arrives as a general runtime value, but
that value is then taken mod32 to arrive at a particular constant and thus a
particular implementation of a generic algorithm. The modulus operation can be
viewed as reducing the value to a limited number of (statically enumerable)
constants, but the number of variations is such that we don't want to
statically pre-emit all of the variations.
This example seems closely related to dependent type. There are a (large but)
limited number of concrete algorithm realizations that can be statically
checked in advance. The dynamic question is limited to choosing which of the
instantiations is to be used. The thing is: all of these can be checked in
advance, and we can model what is happening as a template expansion that has
been deferred to runtime. The reason we do not expand all of the cases at
compile time is that there are an explosive number of cases.
The loop unrolling case is qualitatively similar. It can be modeled as a
template expansion whose implementation has been deferred to runtime.
The problem with these two examples is that they are both examples of
constant-driven polyinstantiation whose implementation has been deferred to
runtime. I think it would be a mistake to imagine that these are the only cases.
On the bright side, both of these examples can be statically checked by a
relatively weak dependent type system. On the dark side, both rely on the
ability of the (static) compiler to emit code that invokes a (dynamic) code
generator. The difficulty is to know whether that invocation of the dynamic
code generator is originating from the compiler or the program itself.
Jonathan
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
