mthom / scryer-prolog

A modern Prolog implementation written mostly in Rust.
BSD 3-Clause "New" or "Revised" License
2.08k stars 125 forks source link

Scryer Scholar's Series! #2477

Closed jjtolton closed 3 months ago

jjtolton commented 3 months ago

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:

  1. Largely inspired by @mthom's great wiki article, I thought it might be a fun idea to do a "book club" except for Scryer Prolog modules. We could do something like, start an issue per module and then collectively write a wiki article about the nuances and internals of the module.
  2. Create some wiki articles on techniques that haven't been discussed elsewhere but are "common knowledge" for experienced Prolog developers, such as "the right way to do I/O" (and other side-effecty code), working with databases, how to write a web server, CI/CD and SDLC concerns for production Prolog code, code organization for a Prolog codebase, proper Prolog code style, etc.
  3. Organize, summarize, and analyze important Prolog books and papers that are "common knowledge" for experience Prolog developers but are probably unknown to new Scryer developers.

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.

bakaq commented 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.

jjtolton commented 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.

Ah, great, didn't know we had a discussions. Will move this there.

Edit: WHOA discussions is huge!!

bakaq commented 3 months ago

Edit: WHOA dicsussions is huge!!

Also a lot of gold there!

jjtolton commented 3 months ago

moving to discussions