It’s a beautiful construction. It reminds me a bit of the “canonical” quicksort in Haskell [1].
Neither of these implementations is going to be displacing absl::btree_map or std::sort any time soon, but I do feel we have a lot of “room at the bottom” for making simple and elegant code practical on real machines.
[1] https://stackoverflow.com/questions/7717691/why-is-the-minim...
Edit: replaced poorly formatted code with SO link.
It seems like whether this represents a mutable or immutable data structure depends on the operations you allow. If polling with nonvar() is allowed, couldn’t you see variables mutate as you do more unification? But if it’s not allowed, I guess you get a variable to be defined later?
Compare with a Promise. If you can check whether it resolved, you can see it mutate. If the only operation allowed is to await it then from the code’s point of view, it might be considered an immutable reference to the pending result.
Partially instantiated data structures are also available in Haskell (via Laziness), in OCaml (via tail modulo cons, https://inria.hal.science/hal-03146495/document) and Koka (via constructor contexts, https://dl.acm.org/doi/pdf/10.1145/3656398)
I don't get where the `-` comes from in `key-value` result lines after the "refactoring" title. I feel like it should stay a `,` like at the beginning. Can someone more knowledgeable in Prolog explain that? Is that because of an hidden use of this `to_list` predicate that comes later in the post?
A classic library, you can play with it here: https://ciao-lang.org/playground/#https://github.com/ciao-la...
This is philosophically intriguing.
I am actually working on a logical query language that's a successor to prolog here: https://memelang.net/02/. Any feedback appreciated!
I've noticed quite a lot of Prolog content lately. I don't know if it's just a case of the Baader–Meinhof phenomenon, but it looks to me that recent article[1] about Prolog being able to improve LLM reasoning abilities renewed some interest in the language.
[1] https://shchegrikovich.substack.com/p/use-prolog-to-improve-...
[dead]
Partial instantiation is cool and all, but tbh I prefer just capturing the initial incomplete attributes in one complete record, pass that around, and then instantiate the real thing when you have all attributes
data class IncompletePerson(val name: String)
data class Person(
val name: String,
val email: String
)
or data class Person(
val initialAttributes: IncompletePerson,
val email: String
)
if you want to nest it.if you're the type to instead do this
data class Person(
val name: String,
val email: String?
)
I never want to work with your code. Now, there's no disambiguation between the complete object and the incomplete one, I always have to check before doing anything with it, and people will inevitably try send an incomplete object someplace that can't handle it and generate bugs.
I've never used it in production, but I have a deep love of Prolog, just because of how different it is from any other programming language I've used. As a programming paradigm, it found it as eye-opening as functional programming. What I found interesting is that you are operating on logical statements and pattern matching, which often means that the same "function" can be used for multiple different things. For example:
append([], List, List).
append([Head|Tail], List, [Head|Rest]) :- append(Tail, List, Rest).
Is a simple list append function: append(X, Y, Z) is a predicate that match if Z is the list of all elements of X, followed by all elements of Y. You can use it to concatenate lists, of course. But you can also use it to confirm that a particular list start with a particular sequence, or ends with a particular sequence! The idea that the same predicate can be used in multiple different ways is really fascinating to me. I have no idea to what extent that would scale in a large system, but it's very interesting