{"id":20425340,"url":"https://github.com/catseye/exanoke","last_synced_at":"2026-03-09T10:31:46.476Z","repository":{"id":4497471,"uuid":"5636830","full_name":"catseye/Exanoke","owner":"catseye","description":"MIRROR of https://codeberg.org/catseye/Exanoke : A functional language which is syntactically restricted to primitive recursive functions","archived":false,"fork":false,"pushed_at":"2023-09-10T21:00:42.000Z","size":41,"stargazers_count":7,"open_issues_count":0,"forks_count":2,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-04-12T18:57:54.009Z","etag":null,"topics":["esolang","esoteric-language","esoteric-programming-language","functional-programming","primitive-recursion","primitive-recursive"],"latest_commit_sha":null,"homepage":"https://catseye.tc/node/Exanoke","language":"Python","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/catseye.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2012-09-01T04:13:21.000Z","updated_at":"2024-11-07T17:47:19.000Z","dependencies_parsed_at":"2025-04-12T18:55:40.415Z","dependency_job_id":"de333a2d-f94e-4da2-bc52-def6919e00ff","html_url":"https://github.com/catseye/Exanoke","commit_stats":null,"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"purl":"pkg:github/catseye/Exanoke","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FExanoke","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FExanoke/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FExanoke/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FExanoke/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/catseye","download_url":"https://codeload.github.com/catseye/Exanoke/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FExanoke/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30291807,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-09T02:57:19.223Z","status":"ssl_error","status_checked_at":"2026-03-09T02:56:26.373Z","response_time":61,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["esolang","esoteric-language","esoteric-programming-language","functional-programming","primitive-recursion","primitive-recursive"],"created_at":"2024-11-15T07:12:54.479Z","updated_at":"2026-03-09T10:31:46.450Z","avatar_url":"https://github.com/catseye.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"Exanoke\n=======\n\n_Exanoke_ is a pure functional language which is syntactically restricted to\nexpressing the primitive recursive functions.\n\nI'll assume you know what a primitive recursive function is.  If not, go look\nit up, as it's quite interesting, if only for the fact that it demonstrates\neven a genius like Kurt Gödel can sometimes be mistaken.  (He initially\nthought that all functions could be expressed primitive recursively, until\nAckermann came up with a counterexample.)\n\nSo, you have a program.  There are two ways that you can ensure that it\nimplements a primtive recursive function:\n\n*   You can statically analyze the bastard, and prove that all of its\n    loops eventually terminate, and so forth; or\n*   You can write it in a language which is inherently restricted to\n    expressing only primitive recursive functions.\n\nThe second option is the route [PL-{GOTO}][] takes.  But that's an imperative\nlanguage, and it's fairly easy to restrict an imperative language in this\nway.  In PL-{GOTO}'s case, they just took PL and removed the `GOTO` command.\nThe rest of the language essentially contains only `for` loops, so what you\nget is something in which you can only express primitive recursive functions.\n(That imperative programs consisting of only `for` loops can express only and\nexactly the primitive recursive functions was established by Meyer and Ritchie\nin \"The complexity of loop programs\".)\n\nBut what about functional languages?\n\nThe approach I've taken in [TPiS][], and that I wanted to take in [Pixley][]\nand [Robin][], is to provide an unrestricted functional language to the\nprogrammer, and statically analyze it to see if you're going and writing\nprimitive recursive functions in it or not.\n\nThing is, that's kind of difficult.  Is it possible to take the same approach\nPL-{GOTO} takes, and *syntactically* restrict a functional language to the\nprimitive recursive functions?\n\nI mean, in a trivial sense, it must be; in the original definition, primitive\nrecursive functions *were* functions.  (Duh.)  But these have a highly\narithmetical flavour, with bounded sums and products and whatnot.  What\nwould primitive recursion look like in the setting of general (and symbolic)\nfunctional programming?\n\nFunctional languages don't do the `for` loop thing, they do the recursion\nthing, and there are no natural bounds on that recursion, so some restriction\non recursion would have to be captured by the grammar, and... well, it sounds\nsomewhat interesting, and doable, so let's try it.\n\n[Pixley]: https://catseye.tc/projects/pixley/\n[PL-{GOTO}]: http://catseye.tc/projects/pl-goto.net/\n[Robin]: https://github.com/catseye/Robin\n[TPiS]: http://catseye.tc/projects/tpis/\n\nGround Rules\n------------\n\nHere are some ground rules about how to tell if a functional program is\nprimitive recursive:\n\n*   It doesn't perform mutual recursion.\n*   When recursion happens, it's always with arguments that are strictly\n    \"smaller\" values than the arguments the function received.\n*   There is a \"smallest\" value that an argument can take on, so that\n    there is always a base case to the recursion, so that it always\n    eventually terminates.\n*   Higher-order functions are not used.\n\nThe first point can be enforced simply by providing a token that\nrefers to the function currently being defined (`self` is a reasonable\nchoice) to permit recursion, but to disallow calling any function that\nhas not yet occurred, lexically, in the program source.\n\nThe second point can be enforced by stating syntactic rules for\n\"smallerness\".  (Gee, typing that made me feel a bit like George W. Bush!)\n\nThe third point can be enforced by providing some default behaviour when\nfunctions are called with the \"smallest\" kinds of values.  This could be\nas simple as terminating the program if you try to find a value \"smaller\"\nthan the \"smallest\" value.\n\nThe fourth point can be enforced by simply disallowing functions to be\npassed to, or returned from, functions.\n\n### Note on these Criteria ###\n\nIn fact, these four criteria taken together do not strictly speaking\ndefine primitive recursion.  They don't exclude functional programs which\nalways terminate but which aren't primitive recursive (for example, the\nAckermann function.)  However, determining that such functions terminate\nrequires a more sophisticated notion of \"smallerness\" — a reduction ordering\non their arguments.  Our notion of \"smallerness\" will be simple enough that\nit will be easy to express syntactically, and will only capture primitive\nrecursion.\n\n### Note on Critical Arguments ###\n\nI should note, though, that the second point is an oversimplification.\nNot *all* arguments need to be strictly \"smaller\" upon recursion — only\nthose arguments which are used to determine *if* the function recurses.\nI'll call those the _critical arguments_.  Other arguments can take on\nany value (which is useful for having \"accumulator\" arguments and such.)\n\nWhen statically analyzing a function for primitive recursive-ness, you\nneed to check how it decides to recurse, to find out which arguments are\nthe critical arguments, so you can check that those ones always get\n\"smaller\".\n\nBut we can proceed in a simpler fashion here — we can simply say that\nthe first argument to every function is the critical argument, and all\nthe rest aren't.  This is without loss of generality, as we can always\nsplit some functionality which would require more than one critical\nargument across multiple functions, each of which only has one critical\nargument.  (Much like every `for` loop has only one loop variable.)\n\nData types\n----------\n\nLet's just go with pairs and atoms for now, although natural numbers would\nbe easy to add too.  Following Ruby, atoms are preceded by a colon; while I\nfind this syntax somewhat obnoxious, it is less obnoxious than requiring that\natoms are in ALL CAPS, which is what Exanoke originally had.  In truth, there\nwould be no real problem with allowing atoms, arguments, and function names\n(and even `self`) to all be arbitrarily alphanumeric, but it would require\nmore static context checking to sort them all out, and we're trying to be\nas syntactic as reasonably possible here.\n\n`:true` is the only truthy atom.  Lists are by convention only, and, by\nconvention, lists compose via the second element of each pair, and `:nil` is\nthe agreed-upon list-terminating atom, much love to it.\n\nGrammar\n-------\n\n    Exanoke     ::= {FunDef} Expr.\n    FunDef      ::= \"def\" Ident \"(\" \"#\" {\",\" Ident} \")\" Expr.\n    Expr        ::= \"cons\" \"(\" Expr \",\" Expr \")\"\n                  | \"head\" \"(\" Expr \")\"\n                  | \"tail\" \"(\" Expr \")\"\n                  | \"if\" Expr \"then\" Expr \"else\" Expr\n                  | \"self\" \"(\" Smaller {\",\" Expr} \")\"\n                  | \"eq?\" \"(\" Expr \",\" Expr\")\"\n                  | \"cons?\" \"(\" Expr \")\"\n                  | \"not\" \"(\" Expr \")\"\n                  | \"#\"\n                  | \":\" Ident\n                  | Ident [\"(\" Expr {\",\" Expr} \")\"]\n                  | Smaller.\n    Smaller     ::= \"\u003chead\" SmallerTerm\n                  | \"\u003ctail\" SmallerTerm\n                  | \"\u003cif\" Expr \"then\" Smaller \"else\" Smaller.\n    SmallerTerm ::= \"#\"\n                  | Smaller.\n    Ident       ::= name.\n\nThe first argument to a function does not have a user-defined name; it is\nsimply referred to as `#`.  Again, there would be no real problem if we were\nto allow the programmer to give it a better name, but more static context\nchecking would be involved.\n\nNote that `\u003cif` is not strictly necessary.  Its only use is to embed a\nconditional into the first argument being passed to a recursive call.  You\ncould also use a regular `if` and make the recursive call in both branches,\none with `:true` as the first argument and the other with `:false`.\n\nExamples\n--------\n\n    -\u003e Tests for functionality \"Evaluate Exanoke program\"\n\n`cons` can be used to make lists and trees and things.\n\n    | cons(:hi, :there)\n    = (:hi :there)\n    \n    | cons(:hi, cons(:there, :nil))\n    = (:hi (:there :nil))\n\n`head` extracts the first element of a cons cell.\n\n    | head(cons(:hi, :there))\n    = :hi\n\n    | head(:bar)\n    ? head: Not a cons cell\n\n`tail` extracts the second element of a cons cell.\n\n    | tail(cons(:hi, :there))\n    = :there\n\n    | tail(tail(cons(:hi, cons(:there, :nil))))\n    = :nil\n\n    | tail(:foo)\n    ? tail: Not a cons cell\n\n`\u003chead` and `\u003ctail` and syntactic variants of `head` and `tail` which\nexpect their argument to be \"smaller than or equal in size to\" a critical\nargument.\n\n    | \u003chead cons(:hi, :there)\n    ? Expected \u003csmaller\u003e, found \"cons\"\n\n    | \u003ctail :hi\n    ? Expected \u003csmaller\u003e, found \":hi\"\n\n`if` is used for descision-making.\n\n    | if :true then :hi else :there\n    = :hi\n\n    | if :hi then :here else :there\n    = :there\n\n`eq?` is used to compare atoms.\n\n    | eq?(:hi, :there)\n    = :false\n\n    | eq?(:hi, :hi)\n    = :true\n\n`eq?` only compares atoms; it can't deal with cons cells.\n\n    | eq?(cons(:one, :nil), cons(:one, :nil))\n    = :false\n\n`cons?` is used to detect cons cells.\n\n    | cons?(:hi)\n    = :false\n\n    | cons?(cons(:wagga, :nil))\n    = :true\n\n`not` does the expected thing when regarding atoms as booleans.\n\n    | not(:true)\n    = :false\n\n    | not(:false)\n    = :true\n\nCons cells are falsey.\n\n    | not(cons(:wanga, :nil))\n    = :true\n\n`self` and `#` can only be used inside function definitions.\n\n    | #\n    ? Use of \"#\" outside of a function body\n\n    | self(:foo)\n    ? Use of \"self\" outside of a function body\n\nWe can define functions.  Here's the identity function.\n\n    | def id(#)\n    |     #\n    | id(:woo)\n    = :woo\n\nFunctions must be called with the appropriate arity.\n\n    | def id(#)\n    |     #\n    | id(:foo, :bar)\n    ? Arity mismatch (expected 1, got 2)\n\n    | def snd(#, another)\n    |     another\n    | snd(:foo)\n    ? Arity mismatch (expected 2, got 1)\n\nParameter names must be defined in the function definition.\n\n    | def id(#)\n    |     woo\n    | id(:woo)\n    ? Undefined argument \"woo\"\n\nYou can't call a parameter as if it were a function.\n\n    | def wat(#, woo)\n    |     woo(#)\n    | wat(:woo)\n    ? Undefined function \"woo\"\n\nYou can't define two functions with the same name.\n\n    | def wat(#)\n    |     :there\n    | def wat(#)\n    |     :hi\n    | wat(:woo)\n    ? Function \"wat\" already defined\n\nYou can't name a function with an atom.\n\n    | def :wat(#)\n    |     #\n    | :wat(:woo)\n    ? Expected identifier, but found atom (':wat')\n\nEvery function takes at least one argument.\n\n    | def wat()\n    |     :meow\n    | wat()\n    ? Expected '#', but found ')'\n\nThe first argument of a function must be `#`.\n\n    | def wat(meow)\n    |     meow\n    | wat(:woo)\n    ? Expected '#', but found 'meow'\n\nThe subsequent arguments don't have to be called `#`, and in fact, they\nshouldn't be.\n\n    | def snd(#, another)\n    |     another\n    | snd(:foo, :bar)\n    = :bar\n\n    | def snd(#, #)\n    |     #\n    | snd(:foo, :bar)\n    ? Expected identifier, but found goose egg ('#')\n\nA function can call a built-in.\n\n    | def snoc(#, another)\n    |     cons(another, #)\n    | snoc(:there, :hi)\n    = (:hi :there)\n\nFunctions can call other user-defined functions.\n\n    | def double(#)\n    |     cons(#, #)\n    | def quadruple(#)\n    |     double(double(#))\n    | quadruple(:meow)\n    = ((:meow :meow) (:meow :meow))\n\nFunctions must be defined before they are called.\n\n    | def quadruple(#)\n    |     double(double(#))\n    | def double(#)\n    |     cons(#, #)\n    | :meow\n    ? Undefined function \"double\"\n\nArgument names may shadow previously-defined functions, because we\ncan syntactically tell them apart.\n\n    | def snoc(#, other)\n    |     cons(other, #)\n    | def snocsnoc(#, snoc)\n    |     snoc(snoc(snoc, #), #)\n    | snocsnoc(:blarch, :glamch)\n    = (:blarch (:blarch :glamch))\n\nA function may recursively call itself, as long as it does so with\nvalues which are smaller than or equal in size to the critical argument\nas the first argument.\n\n    | def count(#)\n    |     self(\u003ctail #)\n    | count(cons(:alpha, cons(:beta, :nil)))\n    ? tail: Not a cons cell\n\n    | def count(#)\n    |     if eq?(#, :nil) then :nil else self(\u003ctail #)\n    | count(cons(:alpha, cons(:beta, :nil)))\n    = :nil\n\n    | def last(#)\n    |     if not(cons?(#)) then # else self(\u003ctail #)\n    | last(cons(:alpha, cons(:beta, :graaap)))\n    = :graaap\n\n    | def count(#, acc)\n    |     if eq?(#, :nil) then acc else self(\u003ctail #, cons(:one, acc))\n    | count(cons(:A, cons(:B, :nil)), :nil)\n    = (:one (:one :nil))\n\nArity must match when a function calls itself recursively.\n\n    | def urff(#)\n    |     self(\u003ctail #, \u003chead #)\n    | urff(:woof)\n    ? Arity mismatch on self (expected 1, got 2)\n\n    | def urff(#, other)\n    |     self(\u003ctail #)\n    | urff(:woof, :moo)\n    ? Arity mismatch on self (expected 2, got 1)\n\nThe remaining tests demonstrate that a function cannot call itself if it\ndoes not pass a values which is smaller than or equal in size to the\ncritical argument as the first argument.\n\n    | def urff(#)\n    |     self(cons(#, #))\n    | urff(:woof)\n    ? Expected \u003csmaller\u003e, found \"cons\"\n\n    | def urff(#)\n    |     self(#)\n    | urff(:graaap)\n    ? Expected \u003csmaller\u003e, found \"#\"\n\n    | def urff(#, boof)\n    |     self(boof)\n    | urff(:graaap, :skooorp)\n    ? Expected \u003csmaller\u003e, found \"boof\"\n\n    | def urff(#, boof)\n    |     self(\u003ctail boof)\n    | urff(:graaap, :skooorp)\n    ? Expected \u003csmaller\u003e, found \"boof\"\n\n    | def urff(#)\n    |     self(:wanga)\n    | urff(:graaap)\n    ? Expected \u003csmaller\u003e, found \":wanga\"\n\n    | def urff(#)\n    |     self(if eq?(:alpha, :alpha) then \u003chead # else \u003ctail #)\n    | urff(:graaap)\n    ? Expected \u003csmaller\u003e, found \"if\"\n\n    | def urff(#)\n    |     self(\u003cif eq?(:alpha, :alpha) then \u003chead # else \u003ctail #)\n    | urff(:graaap)\n    ? head: Not a cons cell\n\n    | def urff(#)\n    |     self(\u003cif eq?(self(\u003chead #), :alpha) then \u003chead # else \u003ctail #)\n    | urff(:graaap)\n    ? head: Not a cons cell\n\n    | def urff(#)\n    |     self(\u003cif self(\u003ctail #) then \u003chead # else \u003ctail #)\n    | urff(cons(:graaap, :skooorp))\n    ? tail: Not a cons cell\n\nNow, some practical examples, on Peano naturals.  Addition:\n\n    | def inc(#)\n    |   cons(:one, #)\n    | def add(#, other)\n    |   if eq?(#, :nil) then other else self(\u003ctail #, inc(other))\n    | \n    | add(cons(:one, cons(:one, :nil)), cons(:one, :nil))\n    = (:one (:one (:one :nil)))\n\nMultiplication:\n\n    | def inc(#)\n    |   cons(:one, #)\n    | def add(#, other)\n    |   if eq?(#, :nil) then other else self(\u003ctail #, inc(other))\n    | def mul(#, other)\n    |   if eq?(#, :nil) then :nil else\n    |     add(other, self(\u003ctail #, other))\n    | def three(#)\n    |   cons(:one, cons(:one, cons(:one, #)))\n    | \n    | mul(three(:nil), three(:nil))\n    = (:one (:one (:one (:one (:one (:one (:one (:one (:one :nil)))))))))\n\nFactorial!  There are 24 `:one`'s in this test's expectation.\n\n    | def inc(#)\n    |   cons(:one, #)\n    | def add(#, other)\n    |   if eq?(#, :nil) then other else self(\u003ctail #, inc(other))\n    | def mul(#, other)\n    |   if eq?(#, :nil) then :nil else\n    |     add(other, self(\u003ctail #, other))\n    | def fact(#)\n    |   if eq?(#, :nil) then cons(:one, :nil) else\n    |     mul(#, self(\u003ctail #))\n    | def four(#)\n    |   cons(:one, cons(:one, cons(:one, cons(:one, #))))\n    | \n    | fact(four(:nil))\n    = (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one (:one :nil))))))))))))))))))))))))\n\nDiscussion\n----------\n\nSo, what of it?\n\nIt was not a particularly challenging design goal to meet; it's one of those\nthings that seems rather obvious after the fact, that you can just dictate\nthat one of the arguments is a critical argument, and only call yourself with\nsome smaller version of your critical argument in that position.  Recursive\ncalls map quite straightforwardly to `for` loops, and you end up with what is\nessentially a functional version of of a `for` program.\n\nI guess the question is, is it worth doing this primitive-recursion check as\na syntactic, rather than a static semantic, thing?\n\nI think it is.  If you're concerned at all with writing functions which are\nguaranteed to terminate, you probably have a plan in mind (however vague)\nfor how they will accomplish this, so it seems reasonable to require that you\nmark up your function to indicate how it does this.  And it's certainly\neasier to implement than analyzing an arbirarily-written function.\n\nOf course, the exact syntactic mechanisms would likely see some improvement\nin a practical application of this idea.  As alluded to in several places\nin this document, any actually-distinct lexical items (name of the critical\nargument, and so forth) could be replaced by simple static semantic checks\n(against a symbol table or whatnot.)  Which arguments are the critical\narguments for a particular function could be indicated in the source.\n\nOne criticism (if I can call it that) of primitive recursive functions is\nthat, even though they can express any algorithm which runs in\nnon-deterministic exponential time (which, if you believe \"polynomial\ntime = feasible\", means, basically, all algorithms you'd ever care about),\nfor any primitive recursively expressed algorithm, theye may be a (much)\nmore efficient algorithm expressed in a general recursive way.\n\nHowever, in my experience, there are many functions, generally non-, or\nminimally, numerical, which operate on data structures, where the obvious\nimplementation _is_ primitive recursive.  In day-to-day database and web\nprogramming, there will be operations which are series of replacements,\nupdates, simple transformations, folds, and the like, all of which\n\"obviously\" terminate, and which can readily be written primitive recursively.\n\nLimited support for higher-order functions could be added, possibly even to\nExanoke (as long as the \"no mutual recursion\" rule is still observed.)\nAfter all (and if you'll forgive the anthropomorphizing self-insertion in\nthis sentence), if you pass me a primitive recursive function, and I'm\nprimitive recursive, I'll remain primitive recursive no matter how many times\nI call your function.\n\nLastly, the requisite etymological denoument: the name \"Exanoke\" started life\nas a typo for the word \"example\".\n\nHappy primitive recursing!  \nChris Pressey  \nCornwall, UK, WTF  \nJan 5, 2013\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcatseye%2Fexanoke","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcatseye%2Fexanoke","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcatseye%2Fexanoke/lists"}