scryer-prolog VS advent-of-code

thank you! the scryer community deserves much of the credit too. everyone is welcome and encouraged to join us at https://github.com/mthom/scryer-prolog! some exciting plans in the pipe

Djot is the markup syntax that is used for the documentation of Scryer Prolog, using a parser written in Prolog:

https://github.com/aarroyoc/djota

It works well so far. One of the few limitations I noticed so far pertains to the formatting of tables. For instance, consider the table used in library(format) to describe control sequences:

https://github.com/mthom/scryer-prolog/blob/b0566e41503a6c8d...

It contains several entries that span multiple lines, yet are meant to denote only a single row of the table, such as:

    % | `~Nr`    |  where N is an integer between 2 and 36: format the            |

language c++

I did 2016 in Haskell and 2018 in Rust. Haskell was kind of a pain since I had to do a ton of tail recursion. Rust would be a lot easier since it allows you to be imperative when you need to.

And I definitely only used a tiny subset of either language because I wanted to get the solution as quickly as possible.

[1] https://github.com/xdavidliu/advent-of-code/tree/main/2016

So I came to Haskell from Scheme background, so the tail recursion was actually natural to me. In fact, about a month ago I did 2016 Advent of Code in Haskell, and toward the end, I felt like I was abusing tail recursion [1] to write iterative algorithms like breadth-first-search by essentially "repeatedly consing on to the params of tails calls", as Lispers would probably call it.

The whole I'm wondering if I'm just writing Haskell "with a heavy Scheme accent", since I see others' Haskell code make extensive use of state monads (which I still haven't attempted to understand), and I also found others' using way more of the monadic / applicative operators like "bind", etc than I have.

I found the hard part of Haskell not the iteration, which from tail recursion was completely natural and straightforward, but rather worrying about the efficiency of the "repeatedly consing" part. For things like stacks, the cost is O(1), but for things like Data.Array, I wasn't sure how much shared structure there was; I mean it could totally be copying the entire array every time I "mutate" an element (not really, since it was still sort of "consing" onto the old array and not actually mutating it).

[1] https://github.com/xdavidliu/advent-of-code/blob/main/2016/d...