{"id":20425268,"url":"https://github.com/catseye/equipage","last_synced_at":"2026-03-09T10:30:59.806Z","repository":{"id":142239913,"uuid":"133376897","full_name":"catseye/Equipage","owner":"catseye","description":"MIRROR of https://codeberg.org/catseye/Equipage : The purely concatenative language that Carriage might've been","archived":false,"fork":false,"pushed_at":"2023-12-12T20:35:12.000Z","size":35,"stargazers_count":6,"open_issues_count":0,"forks_count":1,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-03-05T04:45:02.359Z","etag":null,"topics":["concatenative","concatenative-language","esolang","esoteric-programming-language","purely-concatenative"],"latest_commit_sha":null,"homepage":"https://catseye.tc/node/Equipage","language":"PureScript","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"unlicense","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/catseye.png","metadata":{"files":{"readme":"README.md","changelog":"HISTORY.md","contributing":null,"funding":null,"license":null,"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}},"created_at":"2018-05-14T14:49:12.000Z","updated_at":"2023-10-25T08:31:03.000Z","dependencies_parsed_at":"2025-01-15T15:08:42.892Z","dependency_job_id":"83a6dda6-8f07-4d27-a7d5-59b150993a8c","html_url":"https://github.com/catseye/Equipage","commit_stats":null,"previous_names":[],"tags_count":3,"template":false,"template_full_name":null,"purl":"pkg:github/catseye/Equipage","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FEquipage","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FEquipage/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FEquipage/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FEquipage/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/catseye","download_url":"https://codeload.github.com/catseye/Equipage/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/catseye%2FEquipage/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":["concatenative","concatenative-language","esolang","esoteric-programming-language","purely-concatenative"],"created_at":"2024-11-15T07:12:44.840Z","updated_at":"2026-03-09T10:30:59.786Z","avatar_url":"https://github.com/catseye.png","language":"PureScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"Equipage\n========\n\n_Try it online_ [@ catseye.tc](https://catseye.tc/installation/Equipage)\n| _Wiki entry_ [@ esolangs.org](https://esolangs.org/wiki/Equipage)\n| _See also:_ [Carriage](https://codeberg.org/catseye/Carriage#carriage)\n∘ [Wagon](https://codeberg.org/catseye/Wagon#wagon)\n∘ [Oxcart](https://codeberg.org/catseye/Oxcart#oxcart)\n\n- - - -\n\nEquipage is the language that [Carriage][] might have been had I not been\nso concerned about quoting.  (See \"[Discussion: Quoting][]\", below.)\n\nEquipage is a purely concatenative programming language.  In this context,\nthat means:\n\n-   Every symbol in the language is associated with a function that\n    takes stacks to stacks.\n-   The meaning of a program text is the sequential composition of the\n    functions associated with those symbols.\n\nThus, the meaning of a program is a function that takes stacks to stacks.\nSince the program generally only deals with one stack at a time, it is\nalso possible to think of this as a single stack (\"the\" stack) which gets\nmodified over time.\n\nThe stack contains zero or more elements, and each element may be one of\ntwo kinds of values: unbounded integers, and functions which take stacks\nto stacks.  The stack is generally accessed in a LIFO fashion, with a few\nstrategic exceptions.\n\nHere is a table mapping the legal Equipage symbols to functions.\n\n    !        apply\n    ;        push *apply* onto the stack\n    .        push *compose* onto the stack\n    $        push *pop* onto the stack\n    \\        push *swap* onto the stack\n    +        push *add* onto the stack\n    -        push *sub* onto the stack\n    %        push *sign* onto the stack\n    ~        push *pick* onto the stack\n    1        push *one* onto the stack\n    \u003cspace\u003e  nop\n\n(where `\u003cspace\u003e` represents any whitespace character.)\n\nAnd here is an informal description of the functions named in the above table.\n\n    apply:   pop a function off the stack and apply it to the rest of the stack\n    compose: pop a function g, then a function h, off the stack, then push g∘h\n    pop:     pop a value off the stack and discard it\n    swap:    pop a value a, then a value b, off the stack, then push a, then push b\n    add:     pop a value a, then a value b, off the stack, then push a + b\n    sub:     pop a value a, then a value b, off the stack, then push b - a\n    sign:    pop a value off the stack, then push 1, 0, or -1, depending on its sign\n    pick:    pop a value n off the stack, then copy the n'th element on the stack\n             and push it onto the stack.  If n is negative, work from bottom of stack.\n    one:     push the value 1 onto the stack\n    nop:     do nothing to the stack.  (identity function.)\n\nSo.  Here is an example program text:\n\n    1!$!\n\nGiven the above table, this program maps to the function\n\n    push(one) ∘ apply ∘ push(pop) ∘ apply\n\nwhich can be thought of operationally as doing the following when run:\n\n*   pushes the function `one` onto the stack\n*   pops the function `one` off the stack and applies it, which pushes the integer\n    1 onto the stack\n*   pushes the function `pop` onto the stack\n*   pops the function `pop` off the stack and applies it, which pops the integer 1\n    off the stack and discards it\n\nThe remainder of this document gives some examples of Equipage programs,\nwhich also serve as test cases, and then discusses some aspects of the\nlanguage's design.\n\n[Carriage]: http://esolangs.org/wiki/Carriage\n[Discussion: Quoting]: #discussion-quoting\n\nEquipage Tests\n--------------\n\n    -\u003e Tests for functionality \"Interpret Equipage Program\"\n\n    -\u003e Functionality \"Interpret Equipage Program\" is implemented by\n    -\u003e shell command \"bin/equipage %(test-body-file)\"\n\n    -\u003e Functionality \"Interpret Equipage Program\" is implemented by\n    -\u003e shell command\n    -\u003e \"python3 impl/equipage.py/equipage.py %(test-body-file)\"\n\none, apply\n----------\n\nPushing numbers on the stack.  Note stacks are outputted top-to-bottom.\n\n    1!\n    ===\u003e [1]\n\n    1!1!\n    ===\u003e [1,1]\n\napply (deferred)\n----------------\n\napply, as a function which is pushed onto the stack.\n\n    1;!\n    ===\u003e [1]\n\nadd\n---\n\nPop two values, then push their sum.\n\n    1!1!+!\n    ===\u003e [2]\n\nnop\n---\n\nSpace and newline are both whitespace is nop.\n\n    1!  1!1!+!\n    1!1!+!1!+!\n    ===\u003e [3,2,1]\n\nswap, pop\n---------\n\nTest `\\` (swap) and `$` (pop).\n\n    1!  1!1!+!  1!1!+!1!+!   \\!$!\n    ===\u003e [3,1]\n\nsub\n---\n\nTest `-`.\n\n    1!  1!1!+!  1!1!+!1!+!   +!+!  1!-!\n    ===\u003e [5]\n\nsign\n----\n\nTest `%` (sign).\n\n    1!1!+!1!+!   %!\n    ===\u003e [1]\n\n    1!1!-!1!-!   %!\n    ===\u003e [-1]\n\n    1!1!-!       %!\n    ===\u003e [0]\n\npick\n----\n\npick with a positive index picks from the top of the stack.\n\n    1!  1!1!+!  1!1!+!1!+!    1!              ~!\n    ===\u003e [3,3,2,1]\n\n    1!  1!1!+!  1!1!+!1!+!    1!1!+!          ~!\n    ===\u003e [2,3,2,1]\n\nPicking from the very top of the stack has the effect of\nduplicating the top stack element, so the idiom for `dup`\nfound in some other languages is `1!~!`.\n\npick with a negative index picks from the bottom of the stack.\n\n    1!  1!1!+!  1!1!+!1!+!    1!1!-!1!-!      ~!\n    ===\u003e [1,3,2,1]\n\n    1!  1!1!+!  1!1!+!1!+!    1!1!-!1!-!1!-!  ~!\n    ===\u003e [2,3,2,1]\n\npick with a zero index is zero, always.\n\n    1!  1!1!+!  1!1!+!1!+!    1!1!-!          ~!\n    ===\u003e [0,3,2,1]\n\ncompose\n-------\n\nCompose pop and swap into a single function, and apply it.\n\n    1!  1!1!+!  1!1!+!1!+!    \\$.!    !\n    ===\u003e [3,1]\n\nidiom: compose + pick + apply = call\n------------------------------------\n\nOne idiom we forsee being used in Equipage is creating re-usable\nfunctions using composition (on primitives and other functions)\nand storing them at the bottom of the stack.  When one wishes to\nuse one of these functions, one would pick it using its known\n(negative!) index, and apply it.\n\nCreate a function which pushes 2 onto the stack, and apply it\nseveral times.\n\n    11+.!.!\n    1!1!-!1!-!~!;!\n    1!1!-!1!-!~!;!\n    1!1!-!1!-!~!;!\n    ===\u003e [2,2,2,\u003cfn\u003e]\n\n(Yes, the code to fetch and apply the function, is longer than\nthe function itself.  So it goes.)\n\nCreate a function which doubles the value on the stack, and\napply it to 1 several times.\n\n    1~+.!.!\n    1!\n    1!1!-!1!-!~!;!\n    1!1!-!1!-!~!;!\n    1!1!-!1!-!~!;!\n    ===\u003e [8,\u003cfn\u003e]\n\nidiom: sign + pick = if\n-----------------------\n\nIf we push a onto the stack, then b, then take the sign of a value,\nthen add one, then perform a pick, we will get a if the value was\npositive and b if the value was zero.  If a and b are functions,\nwe can then apply the one we get.\n\nIn this example, a is 2, b is 3, and the value is zero.\n\n    1!1!+!  1!1!+!1!+!\n    1!1!-!\n    %!1!+!~!\n    ===\u003e [3,3,2]\n\nIn this example, a is 2, b is 3, and the value is 4.\n\n    1!1!+!  1!1!+!1!+!\n    1!1!+!1!1!+!+!\n    %!1!+!~!\n    ===\u003e [2,3,2]\n\nIt's possible to do a variant of this that picks from the bottom\nof the stack.  We'll see how to do that in a more exhaustive test\nbelow.\n\nidiom: pick self + apply = loop\n-------------------------------\n\n'self' could be provided any number of ways, but if the function\nthat's currently executing is one of the common utility functions\nfrom the bottom of the stack (first idiom), it's simplest to\njust pick it like that.\n\nThis is an infinite loop.  For that reason, it's not written as a\nFalderal test.\n\n    11-1-~;.!.!.!.!.!.!\n    1!1!-!1!-!~!;!\n\nfinally: if + loop = while loop\n-------------------------------\n\nLet's pop all values off the stack until we hit a zero, and then stop.\n\nPseudocode:\n    \n    def f1:\n        duplicate value on stack\n        if it is zero,\n            stop\n        else,\n            pop it off\n            f1\n\n    push 2, 0, 2, 1\n    f1\n\nThe result should be `[0,2,\u003cfunctions\u003e]`.\n\nWorking out the pseudocode a bit:\n\n    def f1:\n        duplicate value on stack\n        take the sign\n        if it is zero,\n            f3 (i.e. -3, pick, apply)\n        else,\n            f2 (i.e. -2, pick, apply)\n\n    def f2:\n        pop a value off the stack\n        f1\n\n    def f3:\n        do nothing\n\n    push 2, 0, 2, 1\n    f1\n\nTranslating the pseudocode to Equipage:\n\n    1~%1-1-1-~;\n    .!.!.!.!.!.!.!.!.!.!\n\n    $11-1-~;\n    .!.!.!.!.!.!.!\n\n    1$\n    .!\n\n    11+11-11+1\n    .!.!.!.!.!.!.!.!.!\n    !\n\n    11-1-~;\n    .!.!.!.!.!.!\n    !\n\nLet's test these parts in isolation a bit maybe.\n\nInitial stack:\n\n    11+11-11+1\n    .!.!.!.!.!.!.!.!.!\n    !\n    ===\u003e [1,2,0,2]\n\nNop:\n\n    1$\n    .!\n    !\n    ===\u003e []\n\nRun f1 initially (here, f1 is nop):\n\n    1$\n    .!\n    \n    11-1-~;\n    .!.!.!.!.!.!\n    !\n    ===\u003e [\u003cfn\u003e]\n\nEverything but run.\n\n    1~%1-1-1-~;\n    .!.!.!.!.!.!.!.!.!.!\n    \n    $11-1-~;\n    .!.!.!.!.!.!.!\n    \n    1$\n    .!\n    \n    11+11-11+1\n    .!.!.!.!.!.!.!.!.!\n    !\n    \n    11-1-~;\n    .!.!.!.!.!.!\n    ===\u003e [\u003cfn\u003e,1,2,0,2,\u003cfn\u003e,\u003cfn\u003e,\u003cfn\u003e]\n\nThe final result:\n\n    1~%1-1-1-~;\n    .!.!.!.!.!.!.!.!.!.!\n    \n    $11-1-~;\n    .!.!.!.!.!.!.!\n    \n    1$\n    .!\n    \n    11+11-11+1\n    .!.!.!.!.!.!.!.!.!\n    !\n    \n    11-1-~;\n    .!.!.!.!.!.!\n    !\n    ===\u003e [0,2,\u003cfn\u003e,\u003cfn\u003e,\u003cfn\u003e]\n\nDiscussion: Computational Class\n-------------------------------\n\nEquipage stores data on a LIFO stack; thus there is reason to suspect that\nit might not be Turing-complete, as it cannot access data arbitrarily.\n\nHowever, we should consider the following:\n\n*   The `swap` function allows us to access the top two elements on the\n    stack arbitrarily, and an element can be an integer value, with no\n    bounds imposed on its size.  Equipage can increment, decrement, and\n    branch if the value is zero.  Therefore it seems plausible that one\n    could implement a 2-counter [Minsky machine][] in Equipage.\n*   The `pick` function allows us to read from the bottom of the stack\n    (but not write to it.)  Careful manipulation of the index from which\n    values are being picked might allow one to simulate a queue in the\n    upper portion of an ever-growing stack, and it seems plausible that\n    this queue could be used to implement a [Tag system][].\n*   Finally, Equipage allows the construction of new functions from\n    existing functions through composition; data and data structures can\n    be encoded in these functions in the manner of [Church numerals][];\n    and it seems plausible that, given a Turing machine, one could\n    construct an Equipage function which, when applied, simulates one\n    step (or many steps) of that machine, simply by evaluating to a\n    suitably modified version of itself.\n\n[Minsky machine]: http://esolangs.org/wiki/Minsky_machine\n[Tag system]: http://esolangs.org/wiki/Tag_system\n[Church numerals]: http://esolangs.org/wiki/Church_numeral\n\nDiscussion: Quoting\n-------------------\n\nPurely concatenative languages are almost embarassingly easy to interpret,\nin a functional language:\n\n*   **map** each symbol to a function\n*   **compose** all those functions into a single function, in a **fold**\n*   **apply** that single funciton\n\nThey are correspondingly easy to parse.  While most programming languages\nrequire a context-free (or even context-sensitive) grammar to describe\ntheir syntax, a purely concatenative language can be parsed with a regular\nexpression.  (And in Equipage's case, not even a complex one.)\n\nBut many, probably most, concatenative languages are not purely so; that is,\nwhen specifying the program they incorporate some operations over and above\nfunction composition.\n\nOne such useful thing is quoting — being able to nest subprograms within\na program, basically.  This seems to be how many of them deal with function\ndefinitions.\n\nBut this nesting is exactly what requires the grammar to be context-free.\n\nCarriage dealt with the issue of quoting by providing two interpretations\nof the program text: one where it is all quoted, another where it is all\ncomposed into a single function.  This is very esolang.  But was, I must\nadmit, somewhat unsatisfying (otherwise why would I be writing this.)\n\nEquipage's approach is to have almost every instruction \"already quoted\".\nThat is, every symbol except `!` simply pushes a function onto the stack.\nIf you need to actually apply it, you have to do that \"manually\", by\nfollowing it with `!`.\n\nThis results in long chains of `x!y!z!` for some instructions x, y, and z,\nand when you want to compose functions out of existing functions\nespecially, long chains of `.!.!.!` whose length must match the number of\ncomposition operations involved in composing the constituent functions.\n\nBut if we're willing to add somewhat more complexity to the language,\nwe can make something that is virtually the equivalent of syntactic\nquoting.\n\n### EquipageQ ###\n\n    -\u003e Tests for functionality \"Interpret EquipageQ Program\"\n\n    -\u003e Functionality \"Interpret EquipageQ Program\" is implemented by\n    -\u003e shell command \"bin/equipage -Q %(test-body-file)\"\n\n    -\u003e Functionality \"Interpret EquipageQ Program\" is implemented by\n    -\u003e shell command\n    -\u003e \"python3 impl/equipage.py/equipage.py -Q %(test-body-file)\"\n\nWe can define a minor dialect of Equipage, which we will call EquipageQ,\nwhich lets us handle quoting in a syntactically nicer way.\n\nEquipageQ adds a special value, MARKER, which can appear on the stack.\nIt also adds two new symbols to the vocabulary:\n\n    (        push *mark* onto the stack\n    )        push *define* onto the stack\n\n(Note that, by having these symbols push functions onto the stack, we\nare following the Equipage approach.  We will need to apply these with\n`!` when we want to use them.)\n\nThe definition of those functions being\n\n    mark:    push a MARKER onto the stack\n    define:  keep popping functions off the stack, composing them,\n             until a MARKER is popped; then push the resulting function\n             onto the stack\n\nThat lets us write `wxyz.!.!.!` as `(!wxyz)!`, which is simpler,\nbecause we don't need to be careful that the number of compose\noperations matches the number of functions being composed.\n\nAnd that lets us write the above program like:\n\n    (! 1~%1-1-1-~; )!\n    (! $11-1-~; )!\n    (! 1$ )!\n    (! 11+11-11+1 )!!\n    (! 11-1-~; )!!\n    ===\u003e [0,2,\u003cfn\u003e,\u003cfn\u003e,\u003cfn\u003e]\n\nWe can further say that if `define` exhausts the stack without seeing\na MARKER it acts as if there was a MARKER at the very bottom of the\nstack.  This permits us to say what the meaning of an Equipage program\nis, even if it contains unbalanced parentheses.  This is of course not\na full compensation for not having them as a syntactic construct, which,\nfor the price of having a parsing phase, buys you things like being\nable to detect unbalanced parentheses without running the program.\n\nHappy concatenating!  \nChris Pressey  \nLondon, UK  \nJune 12th, 2018\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcatseye%2Fequipage","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcatseye%2Fequipage","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcatseye%2Fequipage/lists"}