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.
in this subject i am triggered by: ‘having an overview of all the code’.
currently i am trying to make an editor which can interpret all the code before it is handed to the (swi) compiler / interpreter.
i make this with the scintilla notepad plus editor written by Neil Hodgson and i have have full access to the events and popups and colors. i have some source of this editor if you want.
eventually i want to make this editor for prolog, but first i am applying this editor to the Metta-language, a language compiler, written / implemented entirely in swi-prolog.
It is very nice if an editor can parse and understands your code, it can make suggestions to change code, check code etcetera
I mean it is not called from anywhere and a smart editor such as PceEmacs or GNU Emacs using sweep will flag it is “not called”. Same for the cross-referencing tool.
That is exactly what PceEmacs and the sweep mode of Emacs do. It is for now only used for “semantic highlighting” though. Smarter completion would be nice to have. As is, completion uses Emacs “dynamic abbreviation” search (searching the file for (nearby) words with the same prefix and failing that it searches the built-in and library predicates. That could be done a lot smarter by using context to what predicates are likely and also consider predicates from other files that are part of the application.
Note that both editors use the same library (prolog_colour) to do the highlighting. It would be nice to have a reusable library for smart completion as well. I think this stuff is also used by @jamesnvc’s LSP server.
Ok, yes what i was wanting to say is, that if you are able to program completely your own editor , you can have anything you want, like: jump to predicates, predicate listings etc, but you have to be able to parse the prolog code with it, and it is a lot of work to implement such an editor. I havent tried the new emacs yet, it might already do the job. several times i use another prolog which already has this kind of IDE , but they lack several things which make it very very hard to work with; dark theme isnt implemented , the search function is Terrible, the placing of the sub windows is horrible, CTrl-Tab doesnt work, Auto complete is the most horrible thing you can have in an editor if you cant turn it off and if it is slow, and if it works horrible ( works like a game , once you think you can choose the predicate proposal it dissapears for you and you have to go back ) in the ms dos version we had a predicate list -popup which inserted the whole predicate with variabels included
