Reminds me of Nock (the abstract machine for Urbit). Nock handles data as either base-two arbitrary-precision integers (i.e. bitstrings) or cons cells. There's no string type or integer type; both are just untagged streams of ones and zeroes. Basically, they're what some languages call "symbols" or "atoms" or "interned strings": where in, say, Erlang you'd have either the atom 'hello' or the list-of-codepoints "hello" or the binary-string <<"hello">>, in Nock the VM would only know that it's holding onto the number 448378203247 (i.e. 0x68656c6c6f—the bitstring ASCII representation of the characters for "hello".)
In Nock, instead of beta reduction privileging certain types (e.g. symbols, closures) as having special meanings at the head of a cons cell, Nock just defines a mapping between integers and functions. Effectively, Nock is a Lisp-2: the f in (f x) and the f in (g f) have different meanings.
In fact, in Nock, both the meaning of the f in (g f), and the meaning of the f in (g (f x)), are entirely determined by g—you could think of this as every Nock function being a hygenic macro, though it's more than that. This seems dangerous, but Nock is supposed to be a "VM target language" only: the source languages that compile to it are left to define their own "platform semantics" by restricting and making guarantees on how arguments to functions in those languages will be evaluated (eagerly/lazily, early/late-bound, pre-beta-reduced like a function or post-beta-reduced like a macro, etc.) They're also left to define dynamic/lexical scoping rules, by leaving the g the responsibility of resolving the f—and the x, if it wants—in (g (f x)).
Comments
Reminds me of Nock (the abstract machine for Urbit). Nock handles data as either base-two arbitrary-precision integers (i.e. bitstrings) or cons cells. There's no string type or integer type; both are just untagged streams of ones and zeroes. Basically, they're what some languages call "symbols" or "atoms" or "interned strings": where in, say, Erlang you'd have either the atom 'hello' or the list-of-codepoints "hello" or the binary-string <<"hello">>, in Nock the VM would only know that it's holding onto the number 448378203247 (i.e. 0x68656c6c6f—the bitstring ASCII representation of the characters for "hello".)
In Nock, instead of beta reduction privileging certain types (e.g. symbols, closures) as having special meanings at the head of a cons cell, Nock just defines a mapping between integers and functions. Effectively, Nock is a Lisp-2: the f in (f x) and the f in (g f) have different meanings.
In fact, in Nock, both the meaning of the f in (g f), and the meaning of the f in (g (f x)), are entirely determined by g—you could think of this as every Nock function being a hygenic macro, though it's more than that. This seems dangerous, but Nock is supposed to be a "VM target language" only: the source languages that compile to it are left to define their own "platform semantics" by restricting and making guarantees on how arguments to functions in those languages will be evaluated (eagerly/lazily, early/late-bound, pre-beta-reduced like a function or post-beta-reduced like a macro, etc.) They're also left to define dynamic/lexical scoping rules, by leaving the g the responsibility of resolving the f—and the x, if it wants—in (g (f x)).