Re: [Boost-docs] The beauty of LATEX

Subject: Re: [Boost-docs] The beauty of LATEX
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-10-30 04:33:20

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.


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

>> 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? Sure, but it's just terminology.
In my perspective, anything that comes before the main compiler
is a preprocessor.

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

>> 2. IR:
>> a. There will be an (intermediate) output, call it a DOM or an
>> AST as you and Dave have been calling. It shall be patterned
>> after DocBook which has a very good structure to begin with.
>> b. The IR **IS A TREE**. It should be semantically rich and
>> extensible.
>> c. We should get rid of docbook-isms in the output.
>> d. Preprocessors need not be concerned about the full structure
>> of the full IR, just a subset. Preprocessors should only be
>> concerned about text to text translation into a subset of
>> the IR it needs to deal with.
> "text-to-text into (a subset of) the IR" doesn't sound compatible with
> the idea that the "IR **IS A TREE**." Text is typically unstructured
> data.
> I think you need to be clearer about the terms you're using.
>> Again, preprocessors should only be text to text translators,
>> much like the C++ preprocessor. It definitely should not dabble
>> with tree transformations.
> This is getting more and more confusing.

How does it make it more confusing? A preprocessor like C++'s does
not have to deal with the C++ AST. It's a simple text-to-text


Joel de Guzman

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