Closed jjtolton closed 3 months ago
I also agree with this sentiment that currently Prolog documentation of best practices seems to be very scattered and not well organized. There is obviously @triska's Power of Prolog as you mentioned for the "basics", which is incredibly high quality and well organized. For more "advanced" stuff, the best materials are scattered in all kinds of places. The most organized resource seems to be @UWN's StackOverflow (there is a lot of gold there, highly recommend!).
Also, this should probably be in discussions.
I also agree with this sentiment that currently Prolog documentation of best practices seems to be very scattered and not well organized. There is obviously @triska's Power of Prolog as you mentioned for the "basics", which is incredibly high quality and well organized. For more "advanced" stuff, the best materials are scattered in all kinds of places. The most organized resource seems to be @UWN's StackOverflow (there is a lot of gold there, highly recommend!).
Also, this should probably be in discussions.
Ah, great, didn't know we had a discussions. Will move this there.
Edit: WHOA discussions is huge!!
Edit: WHOA dicsussions is huge!!
Also a lot of gold there!
moving to discussions
Hello everyone!
I'd like to propose a little initiative with the working title "The Scryer Scholar's Series".
@triska has done an amazing job with The Power of Prolog and accompanying YouTube videos to teach the philosophy and macro-level skills for writing Prolog code. I feel (and this may not be the case) that there is something of a gap in education between "the basics" of Prolog and "professional" Prolog, and experienced developers flocking to Scryer after having "seen the light", Socratically speaking, might wish to know how to write production quality Scryer Prolog.
The rest of this discussion pertains to Scryer Prolog exclusively, except insofar as comparative language studies would further an exploration of Scryer.
In case there needs to be a justification of why focus Scryer Prolog in particular:
While I think other Prologs are worth studying from a comparative language perspective and a "how can we implement this in Scryer" perspective, I find Scryer is an incredibly exciting and enticing project to engage with because: 0. I don't know how common this is amongst Prologs, but Scryer as a language is rare and special in that I have never seen a language system where the state transitions of the VM are controlled not by the host language (rust) but by the target language (Scryer), 1. the community is small but highly motivated and inviting, 3. the language is restricted and powerful enough such that some degree of "mastery" (of the included modules, anyway) seems both possible and rewarding, 4. being on the cusp of a very useful [shared library](https://github.com/mthom/scryer-prolog/issues/2464) and corresponding WASM implementation makes this practical to "export" into other runtimes, 5. it's incredibly easy to develop with thanks to [PceProlog](https://www.metalevel.at/pceprolog/) and [ediprolog](https://www.metalevel.at/ediprolog/), 6. I'm just really biased, ok??? Most experienced (non-Prolog) developers know that the next thing to do is to start reading source code others have written, which I've started doing. However, because of point 0 (above), some modules such as [`$toplevel`](https://github.com/mthom/scryer-prolog/blob/master/src/toplevel.pl) and [`loader`](https://github.com/mthom/scryer-prolog/blob/master/src/loader.pl) are particularly dense -- I have never seen VM control split between host and target language before. I've also noticed from online discussions it seems like there is a lot of "common knowledge" that professional/experienced Prolog developers know that is not "common knowledge" outside of Prolog. Even though I've been doing functional programming for over a decade, and even though Prolog is from the same intellectual heritage, it is quite special and different enough that I have not read most of the books or papers.So I can think of several great goals for the Scryer Scholar's Series:
I also realize for a lot of you, discussing the nuances of freeze/2, dif/2, difference lists, and other such topics may at this point seem trivial, the existence of reif indicates that even something basic like
dif/2
is apparently often used suboptimally! Even things like how and when to use (or never use) the cut operator seem to be fairly scattered and ingrained in the "common knowledge" of the experienced Prolog developers. I say a new modern Prolog deserves a new modern discourse on the distillation of best practices! :clinking_glasses:Epilogue
In the spirit of [Cunningham's Law](https://meta.wikimedia.org/wiki/Cunningham%27s_Law), I will happily volunteer to kick this adventure off by proposing topics and issues with a rambling and most likely incorrect analysis of modules, papers, and techniques, and when I have irritated you enough with my gross conceptual errors, please do feel free to chime in and correct me! Also, if this topic has been covered very well elsewhere, I would still love to curate and categorize these resources in the wiki in an "FAQ" format :)Thanks again and looking forward to learning with you :mortar_board: !
Edit: renamed to "Scryer Scholar's Series" for the alliteration.