A Theory of Typed Hygienic Macros:

http://lambda-the-ultimate.org/node/3986

On 10/07/2014 1:13 PM, David Jeske wrote:
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



_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to