I started working on a literate programming system that
is based on lout.
It is in its embryonic state right now, but the proof of concept
is done. (The source can be viewed here: http://www.gwydiondylan.org/cgi-bin/viewcvs.cgi/www/papers/literate-lout/literatef?rev=1.3&view=auto)
My personal requirement to the implementation is the ability to
step (when debugging) directly inside the literate document, as
if it was (say) a native C source file. Symbolic debugging of code
embedded into a lout document is a must.
To this end the generated output (I will use the plain-text
backend) has to be adorned with #line statements that specify the line
numbers and filenames of the code fragments they originally come from.
Currently I employ a mildly clever hack to get hold of this information
by using definitions that introspect the .lout file itself and create cross-
reference records that contain the desired information.
Here comes a small example (of how it may look when done):
....
@Literate language { C } ### this is line 333 of file main.lout
@Begin
#include <stdio>
int main(void)
{
printf("Hello");
}
@End @Literate
....
Of course this approach does not scale, since for all @Literate
invocations the whole document is searched.
The second obstacle is that an expernal tool has a hard time
to figure out exactly which line the body of a definition begins at.
To make matters worse, in the presence of macros it is probably
impossible to even find the object that is consumed by the
@Literate symbol.
So in my next step I will attempt to modify the lout sources
to obtain a mechanism to create location info for certain
definitions (resp. of their invocation).
Here is the basic idea how I might do it:
Consider the below definition
def @Foo
right param1
named @LocationDict {} # name of the dictionary the info should go into *)
named @LocationTag {} # tag for which a record gets created
{ ..... }
*) maybe I have to leave out this parameter
@LocationDict and @LocationTag would be magic symbols (just like @Tag, @Filter and @Body) that, when present would record the location information
of each formal parameter in a relation.
So after
@Foo @LocationDict { foodict } @LocationTag {loc1} {
some stuff here (this would be line 34 of the document foo.lout)
second line
}
I could refer to the locations by opening the cross-reference:
Using this technique my wish to track source locations would be possible.
Of course there are several questions remaining:
- Is this a sensible approch, or inherently foul? Any better ideas?
- Can source locations be extracted from objects after parsing is
done at all?
- can lout definitions or definition invocations span multiple files
(e.g. using "include")?
- Is there a realistic chance that Jeff would accept any patches?
To make a long story short I'll stop here. I would be thankful for any
guidance, but I am not in a hurry, though.
I started working on a literate programming system that
is based on lout.
It is in its embryonic state right now, but the proof of concept
is done. (The source can be viewed here: )
My personal requirement to the implementation is the ability to
step directly inside the literate document, as if it was (say) a native
C source file. Symbolic debugging of code embedded into a lout
document is a must.
To this end the generated output (I will use the plain-text
backend) has to be adorned with #line statements that specify the line
numbers and filenames of the code fragments they originally come from.
Currently I employ a mildly clever hack to get hold of this information
by using definitions that introspect the .lout file itself and create cross-
reference records that contain the desired information.
Here comes a small example (of how it may look when done):
....
@Literate language { C } ### this is line 333 of file main.lout
@Begin
#include <stdio>
int main(void)
{
printf("Hello");
}
@End @Literate
....
Of course this approach does not scale, since for all @Literate
invocations the whole document is searched.
The second obstacle is that an expernal tool has a hard time
to figure out exactly which line the body of a definition begins at.
To make matters worse, in the presence of macros it is probably
impossible to even find the object that is consumed by the
@Literate symbol.
So in my next step I will attempt to modify the lout sources
to obtain a mechanism to create location info for certain
definitions (resp. of their invocation).
Here is the basic idea how I might do it:
Consider the below definition
def @Foo
right param1
named @LocationDict {} # name of the dictionary the info should go into *)
named @LocationTag {} # tag for which a record gets created
{ ..... }
*) maybe I have to leave out this parameter
@LocationDict and @LocationTag would be magic symbols (just like @Tag, @Filter and @Body) that, when present would record the location information
of each formal parameter in a relation.
So after
@Foo @LocationDict { foodict } @LocationTag {loc1} {
some stuff here (this would be line 34 of the document foo.lout)
second line
}
I could refer to the locations by opening the cross-reference:
Using this technique my desire to track source locations would be possible.
Of course there are several questions remaining:
- Is this a sensible approch, or inherently foul? Any better ideas?
- Can source locations be extracted from objects after parsing is
done at all?
- can lout definitions or definition invocations span multiple files
(e.g. using "include")?
- Is there a realistic chance that Jeff would accept any patches?
To make a long story short I'll stop here. I would be thankful for any
guidance, but I am not in a hurry, though.