[boost] Re: Adding Loki to Boost (reprise)

From: David B. Held (dheld_at_[hidden])
Date: 2002-04-15 00:25:09

"David Abrahams" <david.abrahams_at_[hidden]> wrote in message
news:0ec001c1e41a$682d5ad0$6801a8c0_at_boostconsulting.com...
>
> http://groups.yahoo.com/group/boost/files/mpl.pdf

Here's some editing: ;)

1.2.3
"...and even if we assume that they're named according to some
convention as above, there's no way to [k]now how many members
there are."
...
"* It uses a few ad-hoc, esoteric techniques, or "hacks". The default
template argument choose1 (label<l>ed "hands off!") is one example."

According to the American Heritage Dictionary, "labeled" is the
preferred form.  This is a judgement call, obviously.

"While these techniques are[,] of course[,] a valuable part of the arsenal
of any good C++ metaprogrammer..."

This one is a bit subjective as well, but one typically offsets
parenthetical comments with commas.

1.3
"Anyone who has had to write parser tables by hand will tell you
that the impracticality of this approach is the very reason [for] YACC’s
existence."

"...the user can invoke metaprograms directly, without learning
a foreign syntax or interrupting the flow of <his> [her?] code."

I noticed that you followed what appears to be a modern convention
of using the female pronoun for cases of non-specific gender.  I'm
not sure if you intended to mix-n-match, or stick with the feminine.

"While in classical programming there is always a tension between
expressivity and correctness on one hand and efficiency on the other,
in the metaprogramming world we wield new power: [we] can move
the computation required for expressivity from runtime to compile-time."

1.4
"Re-use. More important even than the re-use of code which all
libraries provide, a well-designed generic library establishes a
framework of concepts and idioms which establish[es] a reusable
mental model for approaching problems."

Subject-verb agreement (antecedent of 'which' is framework, not
idioms).

"While in theory[,] a metaprogramming library is fully generic and
shouldn’t be concerned with these issues, in practice, support for
templates remains inconsistent..."

I wouldn't have mentioned it, as it's a judgement call, but you used
the comma in the second phrase (in practice).

"Furthermore, when programmers get bored they get sloppy<,>[;]
and buggy code is even more costly than slowly-written code."

This is downright pedantry, but independent clauses containing a
comma should be joined with a semicolon. ;)

2.1
"The template [is] also important from the point of encapsulating
the compiler workarounds..."

2.1.1
"The way [the] C++ template instantiation mechanism works
imposes some subtle limitations..."

"Clearly, the expression typename T::element type is not
valid in [the] case of T == char*, and that’s what the compiler
is complaining about."

"But this quickly becomes awkward if [it] needs to be done
repeatedly, and this awkwardness is compounded when partial
specialization is not available."

"...and that instantiation is[,] of course[,] invalid.  Also, although
in our case[,] this does not lead to a compile error, the
boost::remove pointer<T> template <gets always> [always
gets?] instantiated as well, and for the same reason (because we
are accessing it<’>s nested type member). Such unnecessary
instantiation that is not fatal from compiler’s point of view may
or may be not a problem, depending on the "weight" of the
template (how much the instantiation taxes the compiler)<,>[;]
but a general rule of thumb would be to avoid such code."

"The fact that both [the] boost::remove pointer<T> trait
template and aux::element type<T> use the same naming
convention..."

This one is a bit subjective.

"Now the compiler has no reasons instantiate both
boost::remove pointer<T> and aux::element type<T>[,]
even although they are used as actual parameters to the
select if template..."

And this.

"...that it even make[s] sense to facilitate the selection of [a? the?]
nested type member by introducing a high[-]level equivalent to
select if - the one that will do [a? the?] func::type operation
(that is called [nullary] function class application) as a part of its
invocation."

"Using it, we can re-write the above code as simpl<e>[y] as:..."

"We’ve just seen how to deal with the problem <in> when both
arguments to select if are the results of nullary function class
applications<,>[;] but in this example[,] one of the arguments (T) is
just a simple type, so the refactoring just doesn’t seem possible.
An [The] easiest [or easy] way out of this situation would be to
pass to select if a real nullary function instead of T<,> - the
one that returns T on its invocation. The Boost Metaprogramming
Library[ ]provides a simple way to do it..."

"<W>[w]hich gives us exactly what we wanted."

2.2
"...it can take types and/or non-type arguments as actual template
parameters[,] and instantiation "returns" a new type."

Two independent clauses should be joined with a comma.

"While that might be acceptable for this particular metafunction[,]
any model which prevented us..."

"(they also use the simpler term "metafunction"[,] as do we)."

2.2.1
"Trying to accomplish everything with the simple template
metafunction form would seriously limit the applicability of higher-
order metafunctions[ ]and would have an overall negative effect..."

2.2.3 "One Size Fits All?<.>"
"...since it is a regular class, it can be placed in compile-time
metadata sequences<,> and manipulated by other metafunctions
using the same protocols as for any other metadata."

"That too would hurt usability, considering that the direct
invocations of [a] library’s algorithms are far more often-used than
passing algorithms as arguments to <an>other algorithms/
functions."

2.2.4 "From Metafunction to Metafunction Class.[\n] The MPL’s
answer..."

"Metafunctions are important by encapsulating an operation into
[a] compile-time invocable entity<,>[.] <t>[T]hey give you <a>
[the] possibility to defer its execution."

Or, "They make it possible to defer execution."

I stopped at section 2.3, but if you like I will edit the rest of the
paper as well.  I indicated things that I think ought to be removed
with angle brackets, and things that should be inserted with square
brackets.  My intent is not to criticize the paper, which is written
clearly and understandably, but to make it better by addressing
minor grammar and punctuation (or typographical) errors.

It's a paper that will take a few readings to sink in, but it seems
no more difficult to follow than MC++D.

Dave