-
-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify documentation system: LaTeX to plDoc #142
Comments
We do have too many formats and workflows for documentation. It contributes to 'I know there's this cool thing, if only I could find it' |
@Anniepoo Yes I agree: this issue is part of a larger goal to unify (SWI) Prolog wisdom under a more unified umbrella. My idea is to segment this larger goal into smaller issues that are easy to pick up by community members. About the formats that you enumerate:
If the above would be applies we would end up with the vast majority of documentation residing in two formats: plDoc for code file and HTML/SWISH for (interactive) tutorials. |
The lpn autoconverter was written by Jan to convert the original LaTeX files for the book "Learn Prolog Now" to the SWISH-embedded form available on http://lpn.swi-prolog.org/lpnpage.php?pageid=online The students at the OS Academy did some work on improving the tool, but it still makes some mistakes. |
The manual pages on the website come from the LaTeX manual. Some pages are present as either .txt files or as .html files |
"Jan has made recent updates to SWISH that allow HTML blocks to be inserted. It is also possible to hide most of the toolbars and console panes, resulting in a Web page with interactive Prolog snippets. I envision this to be a viable format for interactive Web tutorials, but this has to be tested out with a real tutorial first." |
Some of the documentation for the pengines system is only available at http://pengines.swi-prolog.org While most of this site is obsolete, it's the only place the javascript client is documented. While thinking about larger issues re documentation, consider that we do have bits of code in other languages - javascript for pengines js client, and soon we'll have JavaPengines and others. |
So, while yes, module and predicate level documentation should be in plDoc, what about Michael Hendrix's excellent tutorial for Julian? |
8cD you know, I think we're making a piece of semantic web here. |
@Anniepoo Thanks for adding some formats I didn't even know about to the list :-) I still think that Prolog modules can largely be documented in plDoc and tutorials/manuals can largely be written in SWISH. I did not yet think about the need to document other languages like, e.g., JavaScript. Do you know of any existing solutions to documenting multi-language projects? Quasi-quoting languages may have this? To my knowledge there is no SW solution for annotating documentation. It may be possible to come up with something:
I’m probably forgetting things here but this should already cover a fair about of the strings that plDoc parses when it extracts documentation from a Prolog module. IOW it is not all that strange to (1) come up with a SW vocabulary for documentation and (2) apply this to SWI first because of its superb SW support. |
Wouter, this is an excellent goal; the implications though are very far reaching, and many things must be worked on before PlDoc or other (currently) largely ad-hoc markup languages become a suitable target for the documentation of all these libraries. For example, only yesterday, Jan himself suggested moving the CLP(FD) documentation away from PlDoc due to major shortcomings of the available formatting instructions. I will probably move the documentation to LaTeX or a different format. Richard O'Keefe raised a few excellent (and, as far as I can tell, unfortunately largely ignored) points about PlDoc in a prior discussion. Some of the issues I have so far encountered with PlDoc are:
... I have not been complaining about *reading* this stuff. I have been saying that - it is somewhere between difficult and impossible for me to write a *program* that reads it - it is excessively difficult for me to *write* this stuff because I am never quite sure what is legal and what is not and how to get various effects. ... In my view, these are all issues that should be filed and discussed in the |
I only suggested to move extensive descriptions of a library out of the source file. Clp(fd) has now Using markdown files that include lists as below, you can group the predicates as you need them.
You can keep the description around the list in markdown or, if you prefer, in LaTeX or any mixture of them. See |
OK, I will try this or move the documentation to LaTeX altogether, since I need features that are not available in Markdown. |
As recommended, I've now moved the CLP(FD) documentation to LaTeX since I need more flexibility and features than PlDoc (at least currently) provides to document the whole library coherently and efficiently. Pertaining to this discussion, here are my experiences so far:
|
`Mixing' is achieved using Markdown files. You write the book like story that documents one or more
Etc. You add a rule to the Makefile to make .tex and you use \input from the main LaTeX file. References to predicates will work automatically. References to sections are probably possible using the |
I have now done this: The CLP(FD) predicate overview is now produced from Two observations:
|
17 libraries are currently documented both in LaTeX and in plDoc. They reside in
swipl-devel/man/lib
. They document modules that reside inswipl-devel/library
.The text was updated successfully, but these errors were encountered: