grammar
Allan Adler
According to the CWEB manual, if I've understood it correctly, cweave
takes into account the grammar of C in formatting the document in TeX.
My impression of the more easily retargeted literate programming languages
such as noweb is that they achieve their generality by not getting involved
in the grammar of the target language or its prettyprinting conventions.
Assuming that is correct, I'm wondering whether there are ways to make
a retargetable program such as noweb accept as one of its inputs a
grammar in Backus-Naur Form of the target language (or language(s), if
the document will involve more than one) and some specification of the
prettyprinting convention for the language(s).
--
Ignorantly,
Allan Adler <a...@zurich.csail.mit.edu>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.
rtr...@googlemail.com
Allan Adler wrote:
> According to the CWEB manual, if I've understood it correctly, cweave
> takes into account the grammar of C in formatting the document in TeX.
> My impression of the more easily retargeted literate programming languages
> such as noweb is that they achieve their generality by not getting involved
> in the grammar of the target language or its prettyprinting conventions.
>
> Assuming that is correct, I'm wondering whether there are ways to make
> a retargetable program such as noweb accept as one of its inputs a
> grammar in Backus-Naur Form of the target language (or language(s), if
> the document will involve more than one) and some specification of the
> prettyprinting convention for the language(s).
This is correct to the extent that CWEB does indeed have a form of
grammar that gets used to pretty print the code. Unfortunately, it is
not a BNF grammar. And there is very good reason for this: CWEB must
cope with code fragments. Have a look at the CWEB program ('tis
published as a CWEB document somewhere).
There is SpiderWeb, which can generate language specific WEBs. I have
used this in the past and it works fine.
Ages, and ages ago I looked into creating what you ask for, a WEB
system that can pretty-print using an annotated BNF grammar. The first
complication is that you need the ability to parse fragments of code.
This can be solved by making every terminal and non-terminal symbol in
your grammar be a start symbol. Next you need a parsing technology that
can cope with such a beast, something along the lines of an Earley
parser.
It is possible to get reasonably far, but I failed when I could not
manage to annotate grammars in such a way to produce pleasing output
for wide ranges of code fragments.
Ever since I have found a love for unpretty-printed code ;-)
Robby
Allan Adler
> Allan Adler wrote:
> > According to the CWEB manual, if I've understood it correctly, cweave
> > takes into account the grammar of C in formatting the document in TeX.
[snip]
> > Assuming that is correct, I'm wondering whether there are ways to make
> > a retargetable program such as noweb accept as one of its inputs a
> > grammar in Backus-Naur Form of the target language (or language(s), if
> > the document will involve more than one) and some specification of the
> > prettyprinting convention for the language(s).
>
> This is correct to the extent that CWEB does indeed have a form of
> grammar that gets used to pretty print the code. Unfortunately, it is
> not a BNF grammar. And there is very good reason for this: CWEB must
> cope with code fragments. Have a look at the CWEB program ('tis
> published as a CWEB document somewhere).
OK, I'll look for it.
> There is SpiderWeb, which can generate language specific WEBs. I have
> used this in the past and it works fine.
Thanks. There are so many web programs that I easily get lost in trying
to navigate among them. I think I tried without success to install
SpiderWeb on a couple of occasions, but I'll take another look.
> Ages, and ages ago I looked into creating what you ask for, a WEB
> system that can pretty-print using an annotated BNF grammar.
Before I discuss the specific problems you encountered, let me ask this:
did you ever make the code you wrote available in case anyone wants to
try to take it further? If you wrote the code in CWEB, you could structure
the document to address all the difficulties you encountered.
> The first
> complication is that you need the ability to parse fragments of code.
> This can be solved by making every terminal and non-terminal symbol in
> your grammar be a start symbol. Next you need a parsing technology that
> can cope with such a beast, something along the lines of an Earley
> parser.
OK. I don't know anything about Early parsers other than what I just
now read in the historical notes in the Red Dragon book.
> It is possible to get reasonably far, but I failed when I could not
> manage to annotate grammars in such a way to produce pleasing output
> for wide ranges of code fragments.
How flexible is the facility for adding or modifying annotations? For
example, suppose you had an interactive version of your program that let
you define and save annotations and to see what effects they had on a
certain test fragments.
> Ever since I have found a love for unpretty-printed code ;-)
In view of your insightful description of trying to deal with that
problem, that makes sense. Since you say you've used Spidery Web with
some success, do you know what it is that Spidery Web does that avoids
the problems you encountered.
Actually, as I recall from the CWEB manual, even cweave doesn't always
produce optimal formats for chunks of code, and sometimes adjustments
need to be made "by hand" to correct for that. Why wouldn't that be
an adequate remedy for the problems you had with your program? I guess
the art lies in realizing that you have to make a certain kind of correction
much too frequently and then come up with a modification to the rules that
makes it happen less frequently.
rtr...@googlemail.com
Allan Adler wrote:
> rtr...@googlemail.com writes:
>
> > There is SpiderWeb, which can generate language specific WEBs. I have
> > used this in the past and it works fine.
>
> Thanks. There are so many web programs that I easily get lost in trying
> to navigate among them. I think I tried without success to install
> SpiderWeb on a couple of occasions, but I'll take another look.
>
Well, my experience dates back 15 years, so technology may well have
moved on to a stage where the Spidery Web code will need some tweaking.
> > Ages, and ages ago I looked into creating what you ask for, a WEB
> > system that can pretty-print using an annotated BNF grammar.
>
> Before I discuss the specific problems you encountered, let me ask this:
> did you ever make the code you wrote available in case anyone wants to
> try to take it further? If you wrote the code in CWEB, you could structure
> the document to address all the difficulties you encountered.
Terribly sorry, it was my Masters Thesis and it was not very
successfull
(I include every aspect of my code in that assessment as well).
> OK. I don't know anything about Early parsers other than what I just
> now read in the historical notes in the Red Dragon book.
You need a parser approach that can generate a whole forest of parse
trees from a given piece of code. And then you need to choose which of
the trees makes most "sense".
> How flexible is the facility for adding or modifying annotations? For
> example, suppose you had an interactive version of your program that let
> you define and save annotations and to see what effects they had on a
> certain test fragments.
Because it was such a short project, I constrained myself to line
breaks
and indentation (and possibly some fonts). The whole idea for BNF
annotations
came from an earlier project that I was involved in, where we made a
Spidery Web for a specification language (called Deva) that used
two-dimensional syntax.
(I cannot find the TR that described the Spidery Web implementation any
more, but you can see the result of some of the pretty-printing here:
http://swt.cs.tu-berlin.de/publ/1993/Santen:TR93.ps.gz )
The fallout from the earlier project was: we need an easier way to
write
down pretty-printing rules.
> > Ever since I have found a love for unpretty-printed code ;-)
>
> In view of your insightful description of trying to deal with that
> problem, that makes sense. Since you say you've used Spidery Web with
> some success, do you know what it is that Spidery Web does that avoids
> the problems you encountered.
SpiderWeb uses the same approach that Knuth's Web used. My memory
is very hazy on how it exactly worked. I vaguely remember that you
started
with a word (or sequence of words) of your code and you find a rule
that
combines those into a chunk (there was a very specific word that Knuth
used to name these chunks, but it escapes me just now). And then chunks
get combined with more code or other chunks, and whenever that happens
pretty-print instructions are interspersed.
So, the whole philosophy is quite different to building a parse tree,
there
never is a tree, just a list of words and print instructions that gets
built up
from left to right.
> Actually, as I recall from the CWEB manual, even cweave doesn't always
> produce optimal formats for chunks of code, and sometimes adjustments
> need to be made "by hand" to correct for that. Why wouldn't that be
> an adequate remedy for the problems you had with your program? I guess
> the art lies in realizing that you have to make a certain kind of correction
> much too frequently and then come up with a modification to the rules that
> makes it happen less frequently.
It was all in the spirit of getting it to do the right thing without
user intervention.
I think that was a widespread mantra at the time (first half of the
nineties). I think
the reasoning went, that if you have manual intervantion then you might
as well
stick with the established Web stuff.
In general, I find that LP programs tend to have quite short code
fragments,
where pretty-printing is not actually very crucial. A good modern day
LP tool
would create fabulous HTML or PDF documents with tons of hovertext and
crossreference links.
Robby
Dr Engelbert Buxbaum
> Assuming that is correct, I'm wondering whether there are ways to make
> a retargetable program such as noweb accept as one of its inputs a
> grammar in Backus-Naur Form of the target language (or language(s), if
> the document will involve more than one) and some specification of the
> prettyprinting convention for the language(s).
Why not use a separate tool for pretty-printing, like Pretzel? The "one
task, one program" aproach instead of the egg-laying wool-milk-pig.
Allan Adler
> Why not use a separate tool for pretty-printing, like Pretzel? The "one
> task, one program" aproach instead of the egg-laying wool-milk-pig.
Thanks, it's downloading now.
Joe Riel
> Dr Engelbert Buxbaum <engelber...@hotmail.com> writes:
>
>> Why not use a separate tool for pretty-printing, like Pretzel? The "one
>> task, one program" aproach instead of the egg-laying wool-milk-pig.
>
> Thanks, it's downloading now.
Where'd you find it? I located the PretzelBook, but haven't seen
any website/homepage. I see there's a debian package for it (pretzel),
I'll have to check it out.
--
Joe Riel
Allan Adler
Joe Riel
> Joe Riel <jo...@k-online.com> writes:
>
>> Allan Adler <a...@nestle.csail.mit.edu> writes:
>>> Dr Engelbert Buxbaum <engelber...@hotmail.com> writes:
>>>> Why not use a separate tool for pretty-printing, like Pretzel? The "one
>>>> task, one program" aproach instead of the egg-laying wool-milk-pig.
>>> Thanks, it's downloading now.
>>
>> Where'd you find it? I located the PretzelBook, but haven't seen
>> any website/homepage. I see there's a debian package for it (pretzel),
>
> I just googled "pretzel noweb".
Thanks, I was trying "pretzel pretty-printer", and things of that
nature.
--
Joe Riel
Christian Lynbech
in Spidery Web (I think, perhaps mostly as a user) in his motivation
for developing noweb wrote somewhere that in his experience, allthough
pretty printing was universally agreed to be a good thing, it was
almost impossible to reach consensus on how the pretty print should
look, thus leading Ramsey to a simple common ascii-on-screen like
output format.
In other words, pretty printing, as appealing the idea may sound, may
not be worth the trouble it will entail.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Allan Adler
that suggests that one can also try to use CWEB for an arbitrary target
language. After all, even if the language doesn't have the grammar or
pretty printing conventions of C, the results will just look like
the unpredictable results one would get from having no grammar or
pretty printing conventions, as in noweb. Is that reasoning sound?
Norman Ramsey
Allan Adler <a...@nestle.csail.mit.edu> wrote:
>> There is SpiderWeb, which can generate language specific WEBs. I have
>> used this in the past and it works fine.
>
>Thanks. There are so many web programs that I easily get lost in trying
>to navigate among them. I think I tried without success to install
>SpiderWeb on a couple of occasions, but I'll take another look.
As the author of Spidery Web, I can say with some authority that it's
quite a hack. IMO you'd be better off using noweb in conjunction with
one of the third-party prettyprinters such as pretzel or dpp. Pretzel
is even already in Debian :-)
--
Norman Ramsey
http://www.eecs.harvard.edu/~nr
Norman Ramsey
Allan Adler <a...@nestle.csail.mit.edu> wrote:
>Since noweb doesn't take into account the grammar of the target language,
>that suggests that one can also try to use CWEB for an arbitrary target
>language. After all, even if the language doesn't have the grammar or
>pretty printing conventions of C, the results will just look like
>the unpredictable results one would get from having no grammar or
>pretty printing conventions, as in noweb. Is that reasoning sound?
No. The difference is that noweb produces output that looks like the
input. CWEB produces an output that looks like an unpredictable
function of the input. But it would be entertaining to try CWEB with a
vaguely C-like language such as (say) Java...