Scryer-prolog: Add embedded help predicate.
help/0 and help/1, like in SWI-Prolog, that would be quite useful http://www.swi-prolog.org/pldoc/man?section=help
XVilka
All 3 comments
@UWN as a quiet observer and being new to prolog systems, why don't you think help predicates should be available? Are there downsides?
kastiglione
on 30 Mar 2019
Please let me offer my (unsolicited) perspective: I did not downvote this suggestion, because I am glad that people are interested in contributing and have the courage to suggest something.
Still, there are significant downsides for implementors in getting sidetracked with things that can also be covered (and possibly even better covered) in other ways. Take SICStus Prolog for example, where the entire documentation is available as Info pages that can be browsed with Emacs, and searched in their entirety with Emacs. This is a key attraction of SICStus Prolog, and in my opinion worth emulating. It makes a built-in help system unnecessary.
As another example, take SWI-Prolog itself: It has hundreds of features, even including a toy Emacs implementation (where important key strokes of actual Emacs behave differently), the mentioned built-in help system, a tracer etc., yet still lacks many of the most essential features that are needed to implement advanced Prolog applications (such as strong syntactic guarantees, a useful interface to attributed variables, a working version of CLP(Q), efficient lists of characters for double-quoted strings etc.). This shows that there is a real risk for implementors to get caught up in tasks that do not improve the core system. Let how this has turned out serve as a warning for implementors.
Please do not take any downvotes personally: In this case, if I read them correctly, they only express the downvoter's (in this case: valuable) opinion that the main effort should better be aimed elsewhere. At least as I see it, the key promise of Scryer Prolog is the potential to get a lean, fast, and ISO compliant Prolog system that provides the right key ingredients for implementing sophisticated and elegant Prolog applications, without getting sidetracked in other tasks.
Since there is barely any other system like that, especially among those that are also freely available, that would make Scryer Prolog rather unique and precious.
triska
on 11 May 2019
Well, if it stays in the way of core features - sure, it should be closed. But, imho, it can be marked low-priority and postponed to better times.
P.S. I have high hopes for this project too.
XVilka
on 11 May 2019
Related issues
notoria
路
3Comments
jburse
路
5Comments
XVilka
路
3Comments
UWN
路
4Comments
mkohlhaas
路
3Comments
Most helpful comment
Please let me offer my (unsolicited) perspective: I did not downvote this suggestion, because I am glad that people are interested in contributing and have the courage to suggest something.
Still, there are significant downsides for implementors in getting sidetracked with things that can also be covered (and possibly even better covered) in other ways. Take SICStus Prolog for example, where the entire documentation is available as Info pages that can be browsed with Emacs, and searched in their entirety with Emacs. This is a key attraction of SICStus Prolog, and in my opinion worth emulating. It makes a built-in help system unnecessary.
As another example, take SWI-Prolog itself: It has hundreds of features, even including a toy Emacs implementation (where important key strokes of actual Emacs behave differently), the mentioned built-in help system, a tracer etc., yet still lacks many of the most essential features that are needed to implement advanced Prolog applications (such as strong syntactic guarantees, a useful interface to attributed variables, a working version of CLP(Q), efficient lists of characters for double-quoted strings etc.). This shows that there is a real risk for implementors to get caught up in tasks that do not improve the core system. Let how this has turned out serve as a warning for implementors.
Please do not take any downvotes personally: In this case, if I read them correctly, they only express the downvoter's (in this case: valuable) opinion that the main effort should better be aimed elsewhere. At least as I see it, the key promise of Scryer Prolog is the potential to get a lean, fast, and ISO compliant Prolog system that provides the right key ingredients for implementing sophisticated and elegant Prolog applications, without getting sidetracked in other tasks.
Since there is barely any other system like that, especially among those that are also freely available, that would make Scryer Prolog rather unique and precious.