Is there anywhere (for purposes of creating tooling) a canonical list of SWI-Prolog:
directives (e.g. :- use_module(foo))
core predicates (i.e. not each and every package)
core operators
BIFs?
I’m trying to make a good syntax highlighter for Prolog in Textadept right down to making it dialect-sensitive, but it’s an uphill slog to go through page after page after page after page of documentation when a simple list is really called for. (And I can’t find anything even in the docs that explicitly states just the directives, for example.) Is there any such list? Is there any automated way to make one?
One thing you can do is use current_predicate/1 or current_predicate/2 (they behave differently in respect to autoloading).
For operators you have current_op/3.
“Directives” are not a different class of things compared to predicates. You can use predicates in the slot of a directive and it can mean something, and you can use something like use_module as a goal in a predicate body, for example.
?- current_predicate(use_module/X).
X = 1 ;
X = 2 ;
false.
What you are doing is going to be difficult to solve in the general case. I hope someone who knows better than me helps you out.
I’m not specifically interested in dealing with every edge condition, merely the typical and common use cases. In the case of current_predicate(use_module/X) for example, use_module is not being, well, used as a directive so I don’t want to syntax highlight it. The only situation in which I want it highlighted as a directive is when it is used as a directive.
But…
I also don’t want to highlight everything used in the :- foo. context as a directive because part of syntax highlighting should call attention to unusual use cases (because I mistype use_module as us_module for example, so it would be nice to have, somewhere, a canonical list of things that are intended to be used as a directive.
As @Boris says and I’m sure you are aware of, all this info is available through various inspection predicates. What is normal is hard to say. I guess it depends on the user There is a predicate property iso that tells you something is in the core standard, which might be a good indication of being normal. You can also a property built_in that tells you that it part of the core system.
Ideally you can use library(prolog_colour) to get semantic information about character ranges. That is what is used by PceEmacs, SWISH and PlDoc’s rendering of source code as HTML. In the ideal world this should drive editors through the language server protocol. This has been discussed here before. I think the overall conclusion was that highlighting support is not yet established for the language server protocol, but it might happen at some point. In the meanwhile you can probably use dedicated networking and/or shared memory to use Prolog for the highlighting but it is very editor specific.
?- predicate_property(append(_,_,_), P).
P = interpreted ;
P = visible ;
P = static ;
P = imported_from(lists) ;
P = file('/home/boris/lib/swipl/library/lists.pl') ;
P = line_count(122) ;
P = nodebug ;
P = number_of_clauses(2) ;
P = number_of_rules(1) ;
P = last_modified_generation(2921) ;
P = defined ;
false.
It turns out that it isn’t iso nor is it built_in even though I’d expect that a reasonable syntax highlighter recognizes it as a “pretty common predicate that you’d be using if you want to append or split lists”.
The take-home message for me is that, whatever @ttmrichter is trying to achieve, it is going to be a) a matter of personal opinion and b) it might involve manual work
If someone gave me this task, I would:
forget about the iso property;
collect all built-ins / imported_from(system);
throw in everything with file(.../swipl/library/*.pl);
use current_op/3 on a “clean” instance (nothing extra loaded);
I wouldn’t do that. There is practically nothing uncommon in there.
There is quite a bit of uncommon stuff there. Mostly for old legacy reasons. Others for being necessary building blocks that are themselves not very useful.
You can do that using the autoload property, but you’re getting quite some uncommon stuff.
Good, but you don’t need a clean system. Just do ?- current_op(A,B,system:C).
No real clue there. iso helps, but e.g., thread_local should be considered quite normal.
Logtalk has quite a few syntax highlighters that I assume are based on static lists of facts about Prolog/Logtalk. Personally I do not believe in Prolog syntax highlighting based on static data. Having dynamic operators makes syntax checking impossible and lacking keywords makes it really hard to get a grip on what some expression means in a particular context.
More exactly, on static lists of Logtalk built-in constructs and Prolog official and de facto standard constructs (and thus Prolog dialect agnostic).
Having a more dynamic syntax highlighting is valuable but, given the diversity of IDEs and text editors, the current status of language server protocol specs and implementations, and specially personal preference, there’s no solution that will ever satisfy all users. Often, suggesting to a programmer to switch to another text editor is like suggesting a change to hair color.
Only in the last few years I’ve had the questionable pleasure of writing code every day all day, and I have started to question many commonly accepted “truths” about what helps a person “program a computer”.
I mentioned “ergonomics” recently (apparently not a very widely used term, hmm). I use it exaclty as:
… where must add, of course, the part where we hope that the “operator” achieves what they meant to
I searched and failed to find enough convincing empirical research into the ergonomics of programming languages or tools in general (any interesting links are highly appreciated!).
On the contrary, there seems to exists a strong dislike for empirical knowledge in computer science circles. I can’t help but remeber the following quip by Dijkstra Himself:
I mention this experimental evidence —for what it is worth— because some people feel uncomfortable with conclusions that have not been confirmed in practice. [emphasis mine]
There is a predicate property 
