4 ms·

Several really cool things in the language. I'm trying to wrap my head around the concept of precedence order being dynamic. And to come up with a use case when

Several really cool things in the language. I'm trying to wrap my head around the concept of precedence order being dynamic. And to come up with a use case when it would be an advantage to change precedence order dynamically. I'm sure people here at HN can come up with some good examples.

pentaphobe 4y ago
Disclaimer: entirely off the cuff Although the creator demonstrates this with `*` and `+` I could imagine this being useful within a set of higher level operators (functions) eg. perhaps you want an argument of (infix) `map` to evaluate before `map` itself Or more generally, you might have a bunch of scalar operators which you'd like to have higher precedence than collection operators which should act on the results
- JoachimS 4y ago
  Yes, but tht sounds like something you decide on once. Not, dynamically and more than once. More like "in this function call given these operands, I want '+' to be evaluated before '/'." Or I'm probably missing something.
  - pentaphobe 4y ago
    Imagine you're writing a lot of one off solutions (say, for AOC) you may end up building a small set of helpful functions you compose together Being able to customise how they compose (through precedence) lets you build a kind of DSL for your problem space No idea how often that would be used - but I can imagine hobby scenarios
pxx 4y ago
https://adventofcode.com/2020/day/18 https://adventofcode.com/2020/day/18
betaveros 4y ago
Hi, author here. I'll probably go into this in more detail in a blog post later, but the short reason for runtime precedences (briefly discussed much further down in the README) is that I wanted to be able to write chained comparisons like `x < y < z` without privileging comparison operators in the syntax, so `less_than := <; x less_than y less_than z` also has to work. This means that you can never resolve the structure of a chain of binary operators while parsing, so you have to wait until runtime. The fact that precedence is mutable at runtime is not at all important, but given the above decision, I thought I might as well go the full mile. (Also, it's funny :)
- JoachimS 4y ago
  Very cool! Thanks for the explanation. And making my mind explode. ;-)

pentaphobe 4y ago

Disclaimer: entirely off the cuff Although the creator demonstrates this with `*` and `+` I could imagine this being useful within a set of higher level operators (functions) eg. perhaps you want an argument of (infix) `map` to evaluate before `map` itself Or more generally, you might have a bunch of scalar operators which you'd like to have higher precedence than collection operators which should act on the results

JoachimS 4y ago
Yes, but tht sounds like something you decide on once. Not, dynamically and more than once. More like "in this function call given these operands, I want '+' to be evaluated before '/'." Or I'm probably missing something.
- pentaphobe 4y ago
  Imagine you're writing a lot of one off solutions (say, for AOC) you may end up building a small set of helpful functions you compose together Being able to customise how they compose (through precedence) lets you build a kind of DSL for your problem space No idea how often that would be used - but I can imagine hobby scenarios

pxx 4y ago

https://adventofcode.com/2020/day/18 https://adventofcode.com/2020/day/18

betaveros 4y ago

Hi, author here. I'll probably go into this in more detail in a blog post later, but the short reason for runtime precedences (briefly discussed much further down in the README) is that I wanted to be able to write chained comparisons like `x < y < z` without privileging comparison operators in the syntax, so `less_than := <; x less_than y less_than z` also has to work. This means that you can never resolve the structure of a chain of binary operators while parsing, so you have to wait until runtime. The fact that precedence is mutable at runtime is not at all important, but given the above decision, I thought I might as well go the full mile. (Also, it's funny :)

JoachimS 4y ago
Very cool! Thanks for the explanation. And making my mind explode. ;-)