4 ms·

> And what do you mean by "s-expressions just too simple"? Isn't simplicity something to strive for? I should stress "a bit". Actually, looking closer at s-exp

by audunw 10y ago

> And what do you mean by "s-expressions just too simple"? Isn't simplicity something to strive for? I should stress "a bit". Actually, looking closer at s-expressions right now (I was writing based on what I remembered), I'd like to flip that statement. S-expressions are just a bit more complex than what I have in mind. Or alternately: they're equivalent under some trivial transformation. It depends on how you look at things - there are supposedly many different implementations of s-expressions, which support different fundamental data types. The basic idea is simpler. There are no fundamental data types, just nodes. For example a 'bit' is a node which can contain one of two child nodes ('one' or 'zero'). Any tree which represents data in memory on a computer can be expanded down to a collection of bits. Though in a text representation or tree editor the user will generally have collapsed the tree such that they don't see individual bits. What I have in mind could look more complex than s-expression in a different context though: the text file representation of the trees may have more syntactic sugar than s-expressions in lisp. The representation isn't significantly different, but the focus is. I'm focusing more on things related to type theory, schemas, how to represent patches/diffs, standardizing parsing/generation and other transforms, etc.

rini17 10y ago
I have reread your text several times, and don't get it. What do you gain by having no fundamental datatypes, only bits? What syntactical sugar is not expressible by s-expression + transformation rules? I am working on something like that too, and I'm completely fine with symbols (with their arbitrary definition by lisp and user) being the fundamental elements.
- TuringTest 10y ago
  > What do you gain by having no fundamental datatypes, only bits? I'd say what you gain is reusability, mostly. When you impose a datatype on data, it comes with a series of constraints and expectations, so you can only use the data in the ways prescribed by its type. If the data doesn't have attached a type of is own, you can use it in different ways at different contexts - this can be valuable for data transformation processes, such as compilation or system interfaces. I suppose you could get the same effect by casting the data to a new type when you change it to a new context. I've read a bunch about applying semiotics theory to programming, and changing the meaning of the symbols "on the go" is closer to the way we think (inferring meanings from the signs adequate to the current context) than the old mathematical approach of "every datum has one well-defined type, and only one".
melloclello 10y ago
You must have read about Urbit, right? Their VM's underlying language/bytecode/thing, Nock, is based on nested pairs of natural numbers, which is perhaps only slightly less unwieldy than operating on single bits. PS, if you're as enthusiastic about this idea as I am, we should talk, can I email you?
nikki93 10y ago
I think it could be neat if the spec of the s-exp was read from local hints rather than top-down prescription. You could show a color picker for color argument to a function etc. clojure.spec seems a cool tool.

by audunw 10y ago

rini17 10y ago

I have reread your text several times, and don't get it. What do you gain by having no fundamental datatypes, only bits? What syntactical sugar is not expressible by s-expression + transformation rules? I am working on something like that too, and I'm completely fine with symbols (with their arbitrary definition by lisp and user) being the fundamental elements.

TuringTest 10y ago
> What do you gain by having no fundamental datatypes, only bits? I'd say what you gain is reusability, mostly. When you impose a datatype on data, it comes with a series of constraints and expectations, so you can only use the data in the ways prescribed by its type. If the data doesn't have attached a type of is own, you can use it in different ways at different contexts - this can be valuable for data transformation processes, such as compilation or system interfaces. I suppose you could get the same effect by casting the data to a new type when you change it to a new context. I've read a bunch about applying semiotics theory to programming, and changing the meaning of the symbols "on the go" is closer to the way we think (inferring meanings from the signs adequate to the current context) than the old mathematical approach of "every datum has one well-defined type, and only one".

melloclello 10y ago

You must have read about Urbit, right? Their VM's underlying language/bytecode/thing, Nock, is based on nested pairs of natural numbers, which is perhaps only slightly less unwieldy than operating on single bits. PS, if you're as enthusiastic about this idea as I am, we should talk, can I email you?

nikki93 10y ago

I think it could be neat if the spec of the s-exp was read from local hints rather than top-down prescription. You could show a color picker for color argument to a function etc. clojure.spec seems a cool tool.