>
> # 3
> Two virtues might here: Andrew’s intention is to make meta content better
> stand out, so that it cannot be confused, at a glance, with non-meta
> content. Wise. However, if the syntax is too unfamiliar, it creates
> excessive burdens on the common user.
>

But the syntax isn't really unfamiliar. Fragments look like (and parse
like) the things they contain, except they have < >'s around them. And they
are expressions.

I don't think that people writing metaprograms will be over-burdened by the
new constructs. User experience thus far bears that out. I hope that for
users accidentally exposed to metaprograms through errors, it will not be
worse than templates. (Implementing good diagnostics in a compiler is
*Hard*; I expect early implementations to suffer as much criticism as
templates and concepts---knowing a thing or two about the latter.)


By putting injected content in quotes, not only do we make it stand out
> while remaining familiar, but we also no longer need the unquote operator
> `%{…}`, the idexpr operator `|# … #|`, and possibly not the fragment syntax
> (that one is arguable though — it probably would still be nice to still
> represent a fragment as a `meta::info` object which can be reflected etc).
>

Putting things in strings doesn't make them stand out. It makes them
strings. And now your programming in the "string" domain instead of the
"code" domain.

So, I'm going to leave it at this... this paper is a lot more than just
reflection and source code injection. The following sections
after injection are also really important because they're based on
proposals that aren't mine. I tried to find a basis for metaprogramming
that would accommodate more features than I could think to design myself. I
don't think I can do that treating code as strings or token sequences and
not structured data.

The point of being holistic is to help us consider the impact of proposals.
If you suggest that injection should be done using strings, then you should
also address how that affects the features on top of it. For example,
language-level macros don't work with strings or token sequences. We
already have the preprocessor, we don't need another. I also don't know how
to support compile-time automatic differentiation when we treat functions
as strings (except by reparsing them). The compile-time I/O stuff might
work, but I'd need to see it proven out. I doubt that we want to support
JIT compilation from arbitrary text strings---that seems like a crazy large
attack surface.

Another reason I wrote the paper is to set real goal posts for
future metaprogramming proposals. Suggesting "we should do X instead of Y"
shouldn't be enough. You have to show where that change fits into the
framework and what impact that change has on everything that might come
later.