Joel de Guzman <[EMAIL PROTECTED]> writes:
> João Abecasis wrote:
>> Joel de Guzman wrote:
>>> So, going back to John's experiment, I'd like the final qbk code
>>> to be:
>>>
>>> [template alpha[] '''α''']
>>> [template super[text] '''<superscript>'''[text]'''</superscript>''']
>>> [template pow[a, b] [a]'''<superscript>'''[b]'''</superscript>''' ]
>>>
>>> Notice [text], [a] and [b] are bracketed. They are essentially
>>> templates that exist only in the duration of the template body
>>> (that is their scope). Notice too that alpha[] is a nullary
>>> template.
>
> Disagree. They are needed. Otherwise, we'll end up with obscure
> naming conventions like __a__ again. Take note that the template
> body is just about any quickbook phrase/block. a, in the pow
> example above is actually a template that exists in the duration
> of the template body of pow. I'd like template invocations to
> always be explicit: bracket them; hence [a].
Are you the least bit worried about clashes with, e.g.
int[3]
and
x[0]
??
>> I'd make the nullary brackets optional. They may be needed to avoid
>> ambiguity with a bracketed expression at the beginning of the
>> definition, but in other situations they look superfluous.
>>
>> Another thing we can consider is dropping the comma. I think this looks
>> more quickbooky:
>>
>> [template pow[a b] [a]'''<superscript>'''[b]'''</superscript>''' ]
>
> Agreed. That's doable. I'm also considering allowing certain punctuation
> characters as template identifiers. I think it is safe if the
> invocation is always explicit. That would allow us to rewrite many
> of the builtins, such as [*bold], as templates. So, right now, I
> notice that a template identifier is either:
>
> * a single char punctuation (e.g. '*', '_', '^', etc.)
> * a C-style identifier
>
> Having that, we can extensively simplify the qbk code to around 10%
> its original size. If we add variadic args to templates, then we can
> go further and have the tables and the doc-info prefix as templates.
> But I guess that's a battle for another day :)
I really like the direction of driving more functionality into the
"library."
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Boost-docs mailing list
[email protected]
Unsubscribe and other administrative requests:
https://lists.sourceforge.net/lists/listinfo/boost-docs
