3 ms·

I see using the choice syntax as PROLOG-esque, rather than Python-esque. When you are building simple structures to iterate upon, it makes sense to use the mor

I see using the choice syntax as PROLOG-esque, rather than Python-esque. When you are building simple structures to iterate upon, it makes sense to use the more readable comprehension syntax, where you define a list or set of items and their desired properties. Yet this terse syntax makes more sense for logic programming, where a lot of the domain logic is built upon generate-and-test patterns; you define a combinatoric search space which is the enumeration of all base value in pairs (or tuples), and check which ones are kept for the next processing steps. When using this pattern, it's clearer to be able to express the space with the shortest syntax rather than the verbose one. As for the adequacy and need for the language, I have my own ideas on what's needed for the stated use case, and I do agree with the authors that this kind of language will really be easier to learn for people without a programming background; it looks much more like mathematics than the traditional von-Neumann-architecture, continuation-based languages, and its declarative nature may make it easier to approach without having a full understanding of runtime behavior.

bmitc 4y ago
> I see using the choice syntax as PROLOG-esque, rather than Python-esque. I didn’t think otherwise. Many functional languages have comprehension syntax, and I prefer declarative programming. > When using this pattern, it's clearer to be able to express the space with the shortest syntax rather than the verbose one. How is x <- [1,2,3] or x <- {1,2,3} more verbose than x := (1|2|3) ? Also, the first and especially second are basically identical to mathematical syntax, but the first implies order better.
- TuringTest 4y ago
  True, those are not more verbose, but are merely list enumerations, not comprehension, which bundles multiple generators and tests within the same structure, e.g.: [(x, y) for x in [1, 3, 5] for y in [2, 7, 8] if x < y] It's a single monolithic expression that builds the list. The choice syntax however represents each generator and each test as separate expressions, which may even be part of different functions. This seems to offer more flexibility. For example (I don't know the exact syntax): x:=(1|2); y:=(7|8); x<y; result = (x,y) Here result is bound to the same values as in the comprehensive list; but these values are yield one at a time, instead of being part of a structure that you traverse.
  - deleted 4y ago
    [deleted]

bmitc 4y ago

> I see using the choice syntax as PROLOG-esque, rather than Python-esque. I didn’t think otherwise. Many functional languages have comprehension syntax, and I prefer declarative programming. > When using this pattern, it's clearer to be able to express the space with the shortest syntax rather than the verbose one. How is x <- [1,2,3] or x <- {1,2,3} more verbose than x := (1|2|3) ? Also, the first and especially second are basically identical to mathematical syntax, but the first implies order better.

TuringTest 4y ago
True, those are not more verbose, but are merely list enumerations, not comprehension, which bundles multiple generators and tests within the same structure, e.g.: [(x, y) for x in [1, 3, 5] for y in [2, 7, 8] if x < y] It's a single monolithic expression that builds the list. The choice syntax however represents each generator and each test as separate expressions, which may even be part of different functions. This seems to offer more flexibility. For example (I don't know the exact syntax): x:=(1|2); y:=(7|8); x<y; result = (x,y) Here result is bound to the same values as in the comprehensive list; but these values are yield one at a time, instead of being part of a structure that you traverse.
- deleted 4y ago
  [deleted]