[Aldor-l] Literate programming

[pip88nl at gmail.com]

On Tue, Aug 19, 2008 at 01:42:01AM -0400, root wrote:
> I recently compressed the whole src/graph graphics subdirectory
> into a single file (bookvol8.pamphlet) and the whole src/hyper
> hypertex directory into a single file (bookvol7.pamphlet). See
> <http://axiom.axiom-developer.org/axiom-website/documentation.html>
> Eventually all of Axiom will be in these books.

Compressing files into a single file is like putting them into a
subdirectory except that it's harder to find the file you are looking
for.

> Two major side-effects of making C programs like hypertex, into a
> literate program is that 
>   (a) I no longer need local include files and
>   (b) programs are single files.

With programs being single files you mean having a single .c file that is
compiled at once? That should prove to be very inconvenient and memory
demanding. Error messages would pile up.

> The first effect (a) comes from the fact that 
>    #include "foo.h"
> can be replaced by 
>    <<foo.h>>
> which has the effect of "inlining" the include file. This has two
> other effects. First, you'll discover that it is "standard practice"
> to start an include file with noise like:
>    #ifndef THISFILE
>    #define THISFILE 1
> which causes the preprocessor to only "enable" the include file once.
> However, if you look closely at the preprocessor output you'll find
> that include files are frequently included multiple times. This causes
> a lot of scan time in the compile and a lot of useless file I/O. Using
> a chunk eliminates both times.

In fact, I don't see that and as far as I know, the preprocessor can't
work like that. The preprocessed source does include the file only once.
In fact, good compilers such as gcc, icc and msvc have preprocessors that
recognise header guards and remember them so they don't have to reload
the file from disk just to see that they don't have to include it again.
I'm not sure what you are talking about, here, can you make an example
where a preprocessor will include a file twice although header guards
were provided?

> The second effect (b) is caused by the standard practice of tiny C files
> that get separately compiled and then linked. These can now be replaced by
> inlining the file using chunks, so that
>     gcc -c file1.c
>     gcc -c file2.c ...
> turns into
>     <<file1.c>>
>     <<file2.c>>
> and the result becomes a single file per user-visible command.
> 
> This approach
>    (a) eliminates multiple invocations of the compiler
>    (b) eliminates multiple accesses to include files
>    (c) eliminates preprocessor time from duplicate includes
>    (d) eliminates multiple file reads/writes
>    (e) reduces link stage processing
>    (f) enables compiler block-optimization processing and inlining.

That is a point, but currently not very interesting. The compiler doesn't
even work well without optimimsation.

>    (g) allows the use of splink, valgrind and other tools trivially

I don't see how that makes it easier to use those files. Could you
elaborate?

> Proper use of hyperlinking in the literate file allows you to walk
> all over the PDF using the adobe reader so you can do quick function
> lookups.

That's something I want from literate programming, yes. That's why I am
considering it in the first place.

> Aldor needs to become literate since Stephen and Peter won't be
> able to answer questions forever. And the answers they have given
> are already sinking into the great morass of mailing list history.

Yes. This knowledge needs to be stored with the compiler. I fully gree
with that.

Pippijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.aldor.org/pipermail/aldor-l_aldor.org/attachments/20080819/7d85f50f/attachment-0002.bin>