Re: [Boost-docs] The beauty of LATEX

Subject: Re: [Boost-docs] The beauty of LATEX
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-30 05:30:42

on Sat Oct 29 2011, Joel de Guzman <> wrote:

> On 10/30/2011 8:29 AM, Dave Abrahams wrote:
>> on Sat Oct 29 2011, Joel de Guzman <> wrote:
>>> On 10/28/2011 4:57 PM, Matias Capeletto wrote:
>>>> I am starting to think that except for very basic Quickbook to HTML
>>>> snippets (no footnotes, no chunking), we should drop for now the idea
>>>> of making a direct Quickbook to HTML or PDF generation. I agree with
>>>> Daniel that if this is what we are looking for, then Joel's proposal
>>>> will not be enough. But Joel's idea could work very well in a
>>>> Quickbook to Docbook or LaTeX processor and, specially for generating
>>>> LaTeX, it seems very attractive. I would love to have the power and
>>>> maturity of LaTeX with the simple and clean Quickbook syntax.
>>> Alright, let me make it clear. I'm presenting this in a high-level
>>> design:
>>> 1. Preprocesors:
>>> a. The wiki can and *should be* a preprocessor.
>> Why? I don't have an opinion, but your assertion lacks any
>> supporting rationale.
> I think I've had enough supporting rationale from my previous
> posts and also from the comments that you've snipped.

Don't take it personally, man. I just didn't get it.

> Anyway:
> One word: modularity. I want to avoid a monolithic blob of code. I
> also do not want to pollute the IR language with stuff like quirky
> wiki syntax. The IR language should be 100% regular and free of
> wiki-isms and all other similar stuff.

Sure... maybe I don't know what you mean by "IR language." I normally
think of IR as a kind of data structure. If all you're saying is that
you want to parse wiki-isms before generating any IR, I'm 100% with you.
That doesn't sound quite like what I think of as a "preprocessor." A
C++ front-end parses function declarations before generating any IR,
too, and there's no remnant of C++ syntax (like curly braces) in any
sensible IR. But none of that happens in the preprocessor.

>>> b. The syntax-highlighter is another preprocessor. It should be made
>>> modular and should probably make use of a regex based highlighter
>>> already existing in the wild. THere are lots out there.
>> +1, on reuse of existing technology. But saying it's a preprocessor
>> makes it sound like it has to come first in the chain... and you've
>> already called the wiki component a preprocessor. Are you sure that's
>> what you mean?
>>> c. Code inclusion can very well be another preprocessor.
>> I'm less and less sure what you mean by preprocessor, now.
> What is not clear? I don't see why you can't have multiple
> text-to-text preprocessors in a system. Do you want me to
> just call these processors?

I want to not be confused about what you might mean by emphasizing
"pre," that's all. I guess you say "pre-processor" because the C++
preprocessor also does a text-to-text transformation... but that again
leaves me wondering why it's important to be doing a text-to-text
transformation here... not that I have anything against text, mind you

> Sure, but it's just terminology. In my perspective, anything that
> comes before the main compiler is a preprocessor.

Which stage is the main compiler in this case?

> Anyway, if it makes you happy, I can call them lexical
> processors.

It makes me less confused, so thank you.

Dave Abrahams
BoostPro Computing

This archive was generated by hypermail 2.1.7 : 2017-11-11 08:50:41 UTC