Re: The beauty of LATEX

on Sat Oct 29 2011, Joel de Guzman <joel-AT-boost-consulting.com> wrote:

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

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
http://www.boostpro.com