@Bubbler Can the tutorial really be wrong? It's stated so clearly.
The following compute... the sum of their squares.
And that interpretation of the program is much purer and more mathematical. Far more in line with the nature of the language.
There is a way to implement primrec where that program does, in fact, give you the sum of squares. (At least according to the quick recursive sketch I did in my head.)
> On the way back from the recursion it uses the other quotation, [*], to multiply what is now a factorial on top of the stack by the second element on the stack.
But I think there's another way to interpret that sentence.
I believe it might be applying each program to an element, and only recursively drawing on the next one when it's needed.
So, when the quoted program is +, it has arity 2, and so it immediately needs to make another recursive call.
Whereas [dup * +] can start operating on the top element, 0. It duplicates 0. It multiplies it by itself. And now there is only one element left on the stack, so when it reaches the +, it makes a recursive call to the next element.
As far as I can see, it's perfectly in line with everything else. Plus, it feels more truly recursive. Expanding out a range from n..0, and then reducing back over it doesn't feel like a true recursive call. Making recursive calls throughout the evaluation process is much truer to how recursive programs work. And this is supposed to be a seriously functional language.
> ... primrec tests whether the top element on the stack (initially the 5) is equal to zero. If it is, it pops it off and executes one of the quotations, the [1] which leaves 1 on the stack as the result. Otherwise it pushes a decremented copy of the top element and recurses.
@Bubbler Yeah, it is how I did it. It's just painfully bland. In order to implement it, you literally generates a range from n to 0, and then just reduce it back up.
It would try to apply the + to 5, but insodoing it would need a second parameter, so it would recurse one step, check for equality to 0, then fill in a 4.
@Bubbler I do understand that interpretation though, given that that's how I implemented it. The reason I discovered this bug is because I was checking my own primrec implementation, and so tried the sum of squares program with 5, and got 21909, which was radically wrong.
It's only then, that I started piecing it together, found the OEIS sequence, figured out what went wrong, and my very final step was to check the reference implementation, which acted just like mine had.
@Bubbler I don't believe so? I mean, it's possible that what I'm suggesting doesn't actually work. That it breaks down in practice in a way that I'm not yet seeing. That's very possible.
But, at least in theory, I can imagine a way to interpret that as one unit of execution, which works the way I'd like it to.
I mean, if you have a:
DEFINE square == dup *.
@Bubbler Then you can express the quoted program as [square +].
And maybe that makes it clearer how it's one unit of execution, which is squaring the top element, then adding it to the one below?
@AviFS (This is a perfectly valid definition that Thun makes in the tutorial.)
A quotation corresponds to a lambda in other languages. What you're trying to do is to arbitrarily insert a try-catch inside a lambda, which you normally can't in other languages.
@Bubbler Maybe it would help me to see what an implementation of what I'm saying would look like? Because I'm not seeing the try-catch in my head, but then again, I'm not seeing any concrete piece of code yet.
@Bubbler Part of my hesitancy is that I understood the desired design was to have stack-based to be an implementation detail in Joy.
I thought it proposed itself as a concatenative language (a new class of functional languages, contrasted with the usual applicative languages).
Ie, in most functional languages, the default operation is function application, whereas in Joy, it's function composition.
@AviFS You basically want to push the next number when it hits + because there are not enough elements on the stack. By this, you just transformed [dup * +] into [dup * try: + except: (push another number) (recurse) +]
Eg. f a in Haskell means apply f to the argument a.
Whereas f a in Joy is first applying f, then applying a. And if you think of all keywords as pure functions which take a stack as input, and return a stack as output, then all Joy programs are just one long composition of mathematically pure functions.
@AviFS "in Joy, it's functional composition". And you're transforming [dup * +] as something that is NOT a composition of dup, *, and +. That's the point.
@Bubbler So did I misunderstand the idea that Joy wasn't trying to promote stack-based thinking?
I thought Joy programs were supposed to be able to be reasoned about without thinking about stacks.
I'm also wondering: If someone read a bunch more of those essays, would there be some clarification on this? Like some more code including primrec, that further validated one of the two ideas?
@Bubbler I do see what you're saying, but I can't help feeling it can work as composition, and without any try except blocks. Again, I might have to see an implementation, or try making one myself-- which I think I may as an exercise-- to see what what I'm proposing would actually look like, and how right/wrong/impossible/try-catch-filled it really is. Right now it's just an idea in my head.
Do you see no way to interpret [0] [square +] primrec as sum of squares without breaking something, no matter how badly you want to, and how leading it looks?
By the way, if anyone wants to parse this stuff on combinators, this should concretify it:
For linear recursion over numeric types the if-part often is [null] and the first recursion part is [dup pred]. The primrec combinator has this built in. For integers the rewrite rules are:
0 [T] [R2] primrec => pop T.
i [T] [R2] primrec => i dup pred [T] [R2] primrec R2.
@Bubbler I always forget about that and do cat file.joy | ./joy
@Bubbler I don't know. The fibonacci program is taking forever. The joy tutorial is not waiting for input, like it's supposed to. And I haven't figured out the REPL yet, either.
Right, but it has user input, so I was hoping to take those functions, and make a repl. (Preferential to trying to find docs on how to get user input.)
What kept the interest of the physicist interested was... Astrophysics for large mind. Geniuses like Hawking and Einstein need your help
This challenge is a code golf challenge hosted on Code Golf Stack Exchange. The task is to generate a random image of a galaxy using any golf language, and the ...
Generate the shortest possible code in any programming language that can generate all Pythagorean triples with all values not exceeding a given integer limit. A Pythagorean triple is a set of three integers $(a, b, c)$ that satisfy the equation $a^2 + b^2 = c^2$. The program should output the tri...
Given a permutation, we can define its high-water marks as the indices in which its cumulative maximum increases, or, equivalently, indices with values bigger than all previous values.
For example, the permutation \$ 4, 2, 3, 7, 8, 5, 6, 1 \$, with a cumulative maximum of \$ 4, 4, 4, 7, 8, 8, 8, ...
def find_closest_number(numbers, query):
index = bisect_left(numbers, query)
if index == 0:
return numbers[0]
if index == len(numbers):
return numbers[-1]
before = numbers[index - 1]
after = numbers[index]
if after - query < query - before:
return after
else:
return before
I guess you could allow that, but it lets people know they're using a trait there
Otherwise they might go hunting for a struct Foo
Actually, that wouldn't be a problem
Still, good to be explicit. Looks like the Rust devs weren't too bothered by verbosity
@DLosc It might be easier to golf something starting from an ungolfed version, so you can take an entirely new approach if needed, but yeah, an accompanying golfed version would've been nice (along with an explanation of what exactly that function did)
main function fizzbuzz() -> never:
match i from [1...]:
case i % 3 == 0:
print("Fizz", end = "")
proceed
case i % 5 == 0:
print("Buzz", end = "")
proceed
any case:
print("\n")
main function fizzbuzz() -> never:
match i from [1...]:
case i % 3 == 0:
print("Fizz", end = "")
proceed
case i % 5 == 0:
print("Buzz", end = "")
proceed
any case:
print("\n")
else:
print(i)
(any case runs if any of the case blocks are matched, else runs if none are)
@Seggan There would be ambiguity between impl Foo and dyn Foo, for one
Also, you can do things like dyn Foo + Bar, and Foo + Bar on its own might be a slightly confusing type signature
And also super importantly: dyn Foo on its own isn't sized
Which means you need to Box it pretty often
And as user said, being able to tell whether something's an actual type or a trait with dyn/impl is super important because those behave very differently
Piet, 151 bytes
Try it online!
