rak1507's solution is exactly that, no? "a higher-order function fix fix that returns some fixed point of its argument function, if one exists." (Wikipedia)
So the function factorial takes two inputs, f and n. facorial handles the base case where n is less than or equal to 1, otherwise it returns n * f(n - 1), assuming f can handle the recursion.
@user And what inputs may I ask for? Can I take two functions and one variable, one function determines the base case, one the relationship, and a variable for the input?
<moon-child> the idea being that if the function converges, repeated applications have no effect, so it doesn't matter if you stop as soon as you reach the fixed point
So IncompleteFactorial's type signature looks like CompleteFunction -> Int, where a CompleteFunction is Int -> Int. And Fix's signature would be IncompleteFunction -> CompleteFunction.
@user story: i challenged john scholes once to write the Y in apl, because of course you can't do that. months later we wrote the lisp interpreter in dfns together, as an exercise for "young" me. when we got the tests right he looked at me like "see? it's possible" (he didn't say it, but i got the idea)
@ngn Might actually be a viable business model. It seems that every time we change something that breaks backwards compatibility in a seemingly insignificant way, we end up having customers paying us extra to either build custom versions of the interpreter without the change, or add a secret I-beam to disable the change.
E.g. we fixed a bug in ⍳ that caused ⍳⍬ to return ⎕IO instead of the correct ⊂⍬. You'd think nobody in their right mind would ever write ⍳⍬ to get ⎕IO but sure enough…
@Adám The Y combinator results in infinite recursion in a strict language like BQN, but you can implement the Z combinator. Here I've used ○⊢ to convert subjects to functions and ⊑⟨…⟩ to convert a function to a subject.
For the Y combinator you'd replace {𝕩{(𝔽𝕗)∘⊢𝕩}} with {𝕏𝕩}.
So you'd single-handedly rewrite and QA possibly tens of thousands of functions on your spare time, since management wouldn't want to pay the up-front cost?
@Adám when dealing with legacy systems, the first thing you do is extract the data. the old system can keep functioning while you're working on the replacement.
i would feel very uncomfortable working with a file format that tries to steal responsibilities from my file system
yea i think i saw that. ive just been focusing on this bytecode version. once i get it working and compiling code updating it to the newest format will be another adventure
i doubt im going to pursue converting it to a code generator for the time being. id rather use it to write applications.
@cannadayr Shouldn't be too hard, really. The only thing that might be difficult is that you have to provide •Glyph and •Decompose from the system functions to the runtime and formatter.
Which is probably actually much easier in Erlang than JS. Well, •Glyph in the runtime is weird because it can't actually work until the runtime is defined, but it's not currently used and would only be needed for optimization (primitives can't be ordered but their glyphs can be). I might remove it or try a different strategy.
