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 <joel-AT-boost-consulting.com> 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.

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.

>>   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
processors.

>> 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
transformation.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com