Is it possible to define mutually recursive functions in Janet?

[nstgc]

I was trying to write something, and got an error regarding trying to call an undefined function in a function definition. "Silly me," I thought, "I'll just..." What?

For example, consider the following

(defn f [n]
  (if (zero? n)
    "f-done"
    (g (dec n))))

(defn g [n]
  (if (zero? n)
    "g-done"
    (f (dec n))))

Though I didn't expect it to work (and indeed it doesn't) I tried first defining (def g nil). This produced the expected result of being able to define f so that (f 0) works, but (f 1) errors because within its scope, g is nil.

Another thought was to just define f twice.

(def g nil)

(defn f [n]
  (if (zero? n)
    "f-done"
    (g (dec n))))

(defn g [n]
  (if (zero? n)
    "g-done"
    (f (dec n))))

(defn f [n]
  (if (zero? n)
    "f-done"
    (g (dec n))))

This has a similar issue in that for sufficiently large numbers (such as 3), it hits that initial definition of g as being nil. Which is somewhat unexpected.

Two workarounds I can think of are to

• pass g to f as a function argument
• merge the two together.

The last one isn't ideal as the whole point for me is to have small, clean functions. Passing a function as part of the argument seems like it should work, but it just feels kind of icky to me for some reason.

edit: Considering this is something even Python can do, perhaps I should have assumed that I'm missing some key piece of information, but at the time of writing this, it seemed like Janet's "everything is a closure" nature prohibits mutually recursive function definitions.

edit2: Indeed, me and my immutable brain overlooked something quite simple.

[CosmicToast]

I would normally use var and set for this use-case

(var g nil)

(defn f [n]
  (if (zero? n)
    "f-done"
    (g (dec n))))

(set g
 (fn [n]
   (if (zero? n)
     "g-done"
     (f (dec n)))))

(print (f 10))

You can make it cleaner by defn-ing g followed by a set to that private symbol, like so:

(var g nil)

(defn f [n]
  (if (zero? n)
    "f-done"
    (g (dec n))))

(defn- g* [n]
  (if (zero? n)
    "g-done"
    (f (dec n))))

(set g g*)

(print (f 10))

[CosmicToast]

Many professional programmers often never end up grasping the difference because understanding stuff like that is a fundamentally different skillset.
My education is actually in philosophy and english, which is an unfair advantage in that regard (on top of working in tech) :)

To answer the question concisely: these aren't tricks at all, and just things programmers should simply know, as they are merely consequences of how things are/work. In other words, the "tricks" are descriptive, rather than active.
For this specific one, here's how I recommend thinking of it:

Immutable/static/constant/etc all describe something not changing.
What that something is varies, and has different behaviors.

A binding is saying "this symbol (a type in janet referring to a bareword) has the following value".
These symbols exist in a look-up table, symbol name -> binding -> value.
When something captures ("sees", etc) a given value, it's actually capturing the binding.
You can see this in the following code (that you now have some experience with):

(def a 1)
(defn pa [] (pp a)) # this "captures" the `a` binding
(def a 2)
(pa) # prints 1

If you wanted to change the visible value, you would need to update the binding, rather than making a new one.

(var a 1)
(defn pa [] (pp a))
(set a 2)
(pa) # prints 2

The value has notably not changed, as numbers (the values in this case) are immutable.
You were modifying the binding, rather than the value.
You can never use a binding command (e.g def, var, set, etc) to mutate a value, because they modify the binding lookup table, and nothing else.

On the other hand, you can have an immutable binding (def) with mutable data, like an array:

(def a @[1 2])
(defn pa [] (pp a))
(array/push a 3)
(pa) # prints @[1 2 3]

This is because pa captured the a binding, which we did not modify or make a new one of (using def, var, or set), but instead we performed operations on the value inside of it.

This kind of comprehension difficulty is present in many languages.
You've probably heard of the never-ending confusion to do with C/C++ pointers and references: it's the same fundamental problem. You can think of C/C++ pointers as successive bindings.
So if you really wanted a book, you could read one on C that tries to explain pointers, and then apply similar principles here, but that's hardly a book "on this".
Since ultimately, these are just principles of software development in general (and, more broadly, of mental models) rather than something more specific.

[pepe]

I love your writing style @CosmicToast. I read your explanation a second time, even though nothing was surprising or new when I read it for the first time.

If I rule the world, you would be the doc editor-in-chief.

❤️

[nstgc]

@CosmicToast

Thanks for the thoughtful and thorough explanation! Again. You're really good at both writing things out as well as being patient, the latter of which is more critical. After I sent that last message I thought "that sounds so pathetic and needy". I really appreciate your patients and willingness to help me understand.

You've probably heard of the never-ending confusion to do with C/C++ pointers and references: it's the same fundamental problem. You can think of C/C++ pointers as successive bindings.

Oddly enough, once I got pointers and refs in C, I never had a problem with them again and switched from writing in Python to C. (I really hate Python and can't fathom how it ever became a thing. But to each their own, I suppose.) At least I didn't have trouble when I was actually writing in C in grad school. I've basically forgotten everything regarding it.

You were modifying the binding, rather than the value.

So... considering the following:

(def a [1])
(print a) # => <tuple 0x5636BBEC9F80>
(def a [1])
(print a) # => <tuple 0x5636BBECB390>

The real "objects" aren't the a binding, but rather the <tuple 0x5636BBEC...> they point to, and when a function closes over such a binding, it's actually capturing, say, <tuple 0x5636BBEC9F80> instead? here the hex value is like the memory address in C, and a is the pointer?

Hmm, that doesn't seem right.

(var a [1])
(defn pa []
  (print a))
(pa) # => <tuple 0x55DEABE84F80>
(set a [1])
(pa) # => <tuple 0x55DEABE862F0>

So I guess set changes the pointer? Like, it has a point to a different address? No, a is the symbol and <tuple 0x55DEABE84F80> is the binding? Which then has some value? So the "binding" is the thing that points to the memory address, and when you set a symbol you change its binding. (Forgive me if I'm just repeating what you said.) When you mutate a binding (i.e. array/push a 2), you are changing the value the binding points to?

[ianthehenry]

array/push doesn’t mutate a binding — array/push mutates arrays. It doesn’t care if those arrays come from looking up a binding or if they’re array literals or the return value of a function or whatever.

set, in your example, mutates the binding to cause it to point to a different value.

Closures in general close over bindings, not values. (In the case of a def binding, they could close over the binding’s value instead, since it will never change — this is a reasonable optimization but I don’t know if Janet does that.)

[CosmicToast]

Since you're familiar with C pointers, I'll explain in their terms.
Pretend you have int *a.

The symbol is a, it's the user-visible way to refer to the variable (which is an int pointer).
How it's materialized in the language is a different concern.
In C, it will generally have its name be mangled based on the platform and exported as a symbol (assuming it's a global).

The binding is the pointer itself, so the value of a is actually of type int* (a pointer).
The pointer has its own memory address, at which you can find the pointer (the memory address of the actual value).

The place in memory the pointer points to (so the value of *a) is the value.

To change the symbol, in C, you would take the compiled code and then modify everything to change the global tag, it is impossible to modify a symbol in C without going to the lower abstraction level (besides editing the code in the first place, of course). You cannot "rename" a value in runtime.

To change the binding, you would do a = &otherInt.
Due to C semantics, pointers are copied by value, so this will only affect future uses of, not any previous saves of a.
However, in Janet, variables are copied by reference (the binding).
You can think of all closures automatically capturing an &a (so int**).

Finally, to change the value, you would do (*a)++.
This is possible because integers are mutable in C.

Hope this clears it up!

[subsetpark]

I’ll just mention that Janet has varfn for this purpose: https://janetdocs.com/varfn

…

On Aug 14, 2023 at 1:34 PM, <Chloe Kudryavtsev ***@***.***)> wrote: Many professional programmers often never end up grasping the difference because understanding stuff like that is a fundamentally different skillset. My education is actually in philosophy and english, which is an unfair advantage in that regard (on top of working in tech) :) To answer the question concisely: these aren't tricks at all, and just things programmers should simply know, as they are merely consequences of how things are/work. In other words, the "tricks" are descriptive, rather than active. For this specific one, here's how I recommend thinking of it: Immutable/static/constant/etc all describe something not changing. What that something is varies, and has different behaviors. A binding is saying "this symbol (a type in janet referring to a bareword) has the following value". These symbols exist in a look-up table, symbol name -> binding -> value. When something captures ("sees", etc) a given value, it's actually capturing the binding. You can see this in the following code (that you now have some experience with): (def a 1) (defn pa [] (pp a)) # this "captures" the `a` binding (def a 2) (pa) # prints 1 If you wanted to change the visible value, you would need to update the binding, rather than making a new one. (var a 1) (defn pa [] (pp a)) (set a 2) (pa) # prints 2 The value has notably not changed, as numbers (the values in this case) are immutable. You were modifying the binding, rather than the value. You can never use a binding command (e.g def, var, set, etc) to mutate a value, because they modify the binding lookup table, and nothing else. On the other hand, you can have an immutable binding (def) with mutable data, like an array: (def a @[1 2]) (defn pa [] (pp a)) (array/push a 3) (pa) # prints @[1 2 3] This is because pa captured the a binding, which we did not modify or make a new one of (using def, var, or set), but instead we performed operations on the value inside of it. This kind of comprehension difficulty is present in many languages. You've probably heard of the never-ending confusion to do with C/C++ pointers and references: it's the same fundamental problem. You can think of C/C++ pointers as successive bindings. So if you really wanted a book, you could read one on C that tries to explain pointers, and then apply similar principles here, but that's hardly a book "on this". Since ultimately, these are just principles of software development in general (and, more broadly, of mental models) rather than something more specific. — Reply to this email directly, view it on GitHub (#1254 (reply in thread)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AAAXT7OANROIW3OLFDDIEFDXVJORTANCNFSM6AAAAAA3P6EBS4). You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[CosmicToast]

Ah good, then my example can be simplified to:

(var g nil)

(defn f [n]
  (if (zero? n)
    "f-done"
    (g (dec n))))

(varfn g [n]
  (if (zero? n)
    "g-done"
    (f (dec n))))

(print (f 10))

[sogaiu]

As a side note, in one the examples at janetdocs:

(var a nil)

(var b nil)

(varfn a
  [x]
  (if (zero? x)
    0
    (b x)))
    
(varfn b
  [y]
  (if (pos? y)
    1
    (a y)))

There are two var forms and two varfn forms -- not strictly necessary.

I honestly don't recall the motivation (likely just trying things out at the time), but looking at it now, reversing the declaractions of the varfn forms is easier. Possibly that's worth considering depending on one's inclinations / situation.

[bitcompost]

Is there a reason why Janet works like this? In Common Lisp and Scheme using undefined symbols in function body is fine, the closure has reference to the environment it was created in, the environment can be mutated later with defun/define to add the missing binding.

What I really like about Lisps is being able to run a partially written incomplete program.

[nstgc]

The biggest benefit is that you get unknown symbol errors at compile time instead of runtime!

Yes. I'm sure a lot of people would disagree with me (presumably not you), but I find compile time errors infinitely preferable to runtime ones. I really wish there was Haskell, but a Lisp.

[code block]

That's interesting! Next time I have a question of the form "why does...", I should definitely try that! (Assuming I remember 😅 )

[nstgc]

What I really like about Lisps is being able to run a partially written incomplete program.

@bitcompost This might be a bit contentious, but Janet is not a Lisp. It is certainly Lispy, but not a Lisp. I don't consider that a strike against Janet, my favorite programming language, but that's my take. I won't break down why (the exact definition of a Lisp has been argued ad nauseam for almost as long as Lisp has existed), but I will say that there is nothing magical about "being a Lisp" that automatically makes it better than something else. Gold is inherently more valuable than iron, but I wouldn't want to build a building out of gold. That might not be the best analogy, but it's the best you're getting this early in the morning minutes before I need to haul my ass out of the door. ;)

[bitcompost]

Another thing this relates to is interactive programming. In Lisp you can hot-reload code by attaching a REPL to a running program and redefining functions. It would be cool to replicate this workflow with Janet. I guess it should be possible with vars?

[bakpakin]

You can do this with Janet as well with (setdyn *redef* true), although it isn't the default:

Janet 1.30.0-d2dd241e linux/x64/gcc - '(doc)' for help
repl:1:> (setdyn *redef* true)
true
repl:2:> (defn a [] 10)
<function a>
repl:3:> (a)
10
repl:4:> (defn b [] (* 2 (a)))
<function b>
repl:5:> (b)
20
repl:6:> (defn a [] 20)
<function a>
repl:7:> (b)
40

[sogaiu]

For reference, IIUC, that functionality is also available via the janet -d invocation (though that also enables debugging features).