John Maddock wrote:
> Joel de Guzman wrote:
>
>> My proposed syntax:
>>
>> x[super 2]
>>
>> does not have this problem. You do not need to add
a space between
>> x and the template /super/. It is also sufficiently
unambiguous.
>> It does not look like a common function call so you
do not have
>> to resort to some naming convention, like
double-underscores.
>>
>> If there are no objections, I'd like to switch to
this syntax to
>> templates. Applying it to macros will break
existing qbk files,
>> which I do not want to do. So, I'll just let them
be and get
>> them deprecated. That means, I'd like templates to
totally replace
>> macros.
>>
>> So, going back to John's experiment, I'd like the
final qbk code
>> to be:
>>
>> [template alpha[] '''α''']
>> [template super[text]
>>
'''<superscript>'''[text]'''</superscript&
gt;'''] [template pow[a,
>> b]
[a]'''<superscript>'''[b]'''</superscript&
gt;''' ]
>>
>> 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.
>>
>> Then...
>>
>> x[super 2]
>> [pow[x][2]]
>> [pow[alpha][2]]
>>
>> I am confident I can get this to work. Comments?
Objections?
>
> I quite like that, certainly it makes univariate macros
look just like
> quickbook built-ins, I'm not so sure about the
multivariate syntax, but I
> don't have strong objections.
>
> Hmmm, currently builtins with multiple arguments have
them separated by
> whitespace, could we preserve this behaviour and fall
back to putting []
> around arguments only if the argument contains
whitespace?
Indeed. At first I wondered what those built-ins are. So, I
noticed
builtins such as [link section.anchor Link text]. With
those, the
general syntax is:
[markup no-space space allowed here]
The first argument may not contain any space while the
second argument
may. I guess this is a special case worth considering,
otherwise, we
cannot emulate the built-ins with templates. Note that this
is a
special case for binary arguments only.
> So:
>
> [pow x 2]
>
> does what you would expect.
Ok.
> [pow x a + b]
>
> places "a + b" as the superscript, it's
the same as:
>
> [pow x [a + b]]
Ok.
> while
>
> [pow [x - y] [a + b]]
>
> separates it's arguments as you'd expect (a bad
example though in the math
> sense).
I see.
> This follows the existing rules for builtin's I think,
with the extension
> that arguments can contain deliberate whitespace if you
put [] around the
> arguments. And of course [] would be an
empty-string-argument.
>
> How does that sound?
I think that sounds logical and implementable. Thanks for
noting that.
Your comments are invaluable!
Regards,
--
Joel de Guzman
http://www.boost-cons
ulting.com
http://spirit.sf.net
_______________________________________________
Boost-docs mailing list
Boost-docs lists.sourceforge.net
Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
|