On Thu, Jul 10, 2014 at 12:24 AM, Matt Oliveri <[email protected]> wrote:
> > [WebCallable] class Foo {
> > [WebActionMethod] public void Action_bar() ...
> > }
>
> Now I'm thinking this pattern seems to call for a
> reflection-supporting sub-language, or at least reflection-supporting
> types.
>
> Anyway, with sufficiently powerful metaprogramming support, the
> sub-language with method introspection wouldn't have to be a built-in
> feature. In principle, the introspection/dispatch metadata structure
> could be implemented in regular BitC, and a code generator could
> translate the sub-language into regular BitC + metadata. There are a
> bunch of details that would need to be worked out.
>
Yes. An opportunity I think most (mainstream?) languages are missing today
is a standard way (sub-language?) for compile-time meta-programming to do
things like build this static mapping in a way which is an integrated and
natural part of the standard language and build.
IMHO, external code-generators create a fractured, minimally-implemented,
and seldom general set of mechanisms. T4 for C# is one of the more-general
attempts, but it makes it very clunky to (a) package macro-templates into a
library, and (b) use data-driven templates. I tried to use it, but gave up
and currently use XML/XSLT for C# code-templating (which has it's own
problems).
For me, some desired properties of a simpler and more natural compile time
metaprogramming "sub-language" are:
(a) macro parameterization should be type-and-validity checked, and have
some element of self-documentation..
For example, if I want to instante a "Foo" macro, and that requires
supplying a parameter set like [A, B, [ D, E, F] ], an error to do so
should be made clearly apparent... and it should be practical to read some
API to find out this information.
(b) it should be both easy and natural to code-generate anywhere (aka, via
a compiler understood language keyword). It should be obvious that
code-generation is occuring (this is not syntax extension).
(c) it should be easy to package up code-generation into a normal library,
which looks like any other library in the compile, and is handled directly
by the compiler and language (not wonky build-dependent steps).
----
I have never used D, but it's "macro mixin" concept looks closer than most
other mainstream options. Thinking on the fly, the simplest system I can
think of which feels close to what I want would be a compile-time keyword
(like "mixin") which takes an expression to execute at runtime, expects it
to yield a CodeGeneration interface, calls Generate() on that interface and
injects the result into the compile. Using this in C# might look something
like:
mixin
new DBTableBase("mytable", "MyTable")
DBRow("row_a",...)
DBRow("row_b",...);
Looking at it, it feels like lisp-macros. However, there would be a
sub-language syntax more like T4 or XSLT for generating the macro itself.
This same thing can be done in XML/XSLT/T4/m4, but it's MUCH more
cumbersome, especially when one wishes to reuse the macro across projects.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
