In the interest of navigating code more quickly, HTML anchor tags (#section-name) came to mind, and I thought about a convention where I add anchors to comments so I can search for sections of code.
And so on.
We are asserting a fact that there are #utilities and #grammars sections, and SWI-Prolog has predicates for locating predicates in source. Further, assorted editors, (via lsp_server or otherwise) will have predicate listing/search/navigation, making it easier to find sections of code.
PceEmacs has a “find predicate” feature with auto-complete. This would be super useful in this case - just type a “#” hit tab and jump to code sections.
BUG: Unfortunately find predicate doesn’t work for predicates whose name contains charaters that must be quoted (leading or otherwise).
In any case, this seems useful and harmless, but is a bit outside typical coding practices. So just wanted to verify it’s not a horrible idea for some reason.
Generally speaking, I’d advise against it: that’s adding to the atoms table, adding to the database, and ultimately polluting the namespace. The ideal and canonical solution remains in comments and tools that can parse those comments (not to mention, just searching for text in the file): the requirement, “code navigability”, anyway is quite orthogonal to the code itself.
E.g. some editors/languages support the #region <Title> / #endregion directives, and some support it as comments where directives do not exist, e.g. // #region / // #endregion works in JS in VSCode. And most editors nowadays anyway offer “outlining” (collapsible code blocks), which helps a lot with heavy files (thausends of lines of code), just “collapse to definitions”, and despair, often…
That said, Prolog offers extraordinary meta-programming capabilities, so I suppose you could also define your own “meta-predicates” (or just predicates, as you are doing) then use term expansion to rewrite those out, and similar, though as a solution it would remain “non-canonical”…
The idea of having machine readable sections is IMO worthwhile. It can improve documentation generation as well as code browsing. XPCE has for a long time
:- pce_group(<name>).
to attach subsequent method declarations to this group. In Prolog code I use e.g.
/*******************************
* BUFFER MENU *
*******************************/
But that is not machine readable. PlDoc introduces the syntax below, but the only type supported right now is module to attach an overall comment to a module.
/** <type> Title ...
...
*/
We could add
/** <section> Predicates about the meaning of life
Bla bla ...
*/
Would that make sense?
P.s. Your '#group' is IMO a little dubious as it indeed pollutes the namespace with unreachable predicates so you need to take care of these things in the various tools. If you want anything like that I’d go for e.g.
:- #group.
and then use term expansion. I prefer structured comments and leaving the job to PlDoc though.
Isn’t this an lsp feature of jumping to the declaration of a predicate ?
Or is this more about grouping related predicates ?
Since prolog doesn’t have nested namespace, I suppose another solution is to split things into multiple files in subdirectories ?
Has nested namespace ever been discussed for prolog ?
Over the past 51 years? Probably I’m not aware of support in any major Prolog implementation though. SWI-Prolog has something that resembles this. It supports inheriting everything it does not have from an “import module”. With a little syntactic sugar that is enough to get something useful. It is used by PlUnit: test units are sub modules of the enclosing module, i.e., they have direct access to the enclosing module, but they do not have access to each other and the enclosing module has no access to the predicates in the test unit.
Thank you this is very interesting. Although it works kind of backward to nested namespace, where the topmost namespace has access to everything and going down the tree restrict the set of visible predicates ?
Edit: this is wrong, please ignore
I’m not an expert in this field. Looking at C++ namespaces, I see that inside a nested namespace you can access the enclosing namespace without qualifying. That is what import modules do. All other access must be qualified or the other module must be imported (which is similar to using ... in several languages).
What is there is definitely not a nested namespace implementation. You’ll have to add some preprocessing and encode the nesting in the module names as the Prolog module namespace is flat.
Both were “reached” as far as my understanding goes. Of course source code (as opposed to compiled output) is the version of a program for humans to read and reason about. And I think it makes sense to have metaprogramming features to reason about code organization in a file. The “hashtag fact” is stating an actual logical fact. It’s saying “it is true that predicates exist that have been organized into a section with a particular name”. So I don’t know that it’s much worse than any other trick for organizing code. e.g. we’ve all seen/used the pattern some_predicatesome_predicate_ to organize code for readability/performance.
This is all not to say that “a way to do something is a good way to do something”. And I’m grateful for any efforts towards tooling for organizing/navigating/reasoning about code.
