5 ms·

I'm curious what the author means by "everything is a graph". Are graphs the primitives of the language? How are graphs defined or specified by the programmer,

I'm curious what the author means by "everything is a graph". Are graphs the primitives of the language? How are graphs defined or specified by the programmer, without using an even lower level primitive? The author says: > Give me a language where key-value maps are emulated with directed bipartite graphs So this means you can't define graphs using key-value dictionaries (like Smalltalk or Javascript with their objects primitives). So how exactly are these graphs defined? RDF format? Something I've found while trying to design languages is that the hardest part is running into contradictions and circular logic. And I feel this "everything is a graph" idea will very quickly run into this issue.

hoosieree 4y ago
Maybe the author implies APL-style programming: in APL, your base datatypes are "array of number" or "array of character" and there's first class support for multidimensional arrays and/or nested arrays. But the main thing is that all the operators take arrays as input and return arrays as output. With "everything is a graph", all your operators would expect to consume and produce graphs. So you'd have operators for parent/sibling relationships, operators for various kinds of traversals, extracting graph shape information to build higher-level operators like subgraph isomorphism (or maybe that would be a built-in operator).
- woojoo666 4y ago
  So the idea is to first define some static graphs and then use operators to construct larger (possibly dynamic) graphs? But to define those small static graphs in the first place, you have to either use key-value mappings (how Smalltalk/Javascript does it) or maybe RDF format or something.
  - hoosieree 4y ago
    That is how I imagine it, yeah. If I was designing an "APL for graphs" I would probably take a lot of inspiration from NetworkX[1]. Especially: generators for various graph types, the ability to read dicts/lists as graph data, and a huge suite of graph-related functions. But I would also want dedicated notation for the most common/composable operations like APL. I particularly like how Jq[2] "functions" are inherently combinators, and Jq has some nice semantics for mapping and filtering operations on trees, but I don't really like its syntax that much. [1]: https://networkx.org/documentation/stable/tutorial.html https://networkx.org/documentation/stable/tutorial.html [2]: https://stedolan.github.io/jq/ https://stedolan.github.io/jq/
nostrademons 4y ago
It's not really different than Lisp. Lists are not a native data representation on any computer other than a Lisp Machine, and S-exprs are a textual representation of a list, not a list itself. Also, most realistic Lisps still admit other primitive types like numbers, strings, symbols, and booleans. Many also have hashtables, structs, and binary blobs. Nobody programs with numbers represented by Peano axioms. Nevertheless, Lisp is still a very useful primitive for understanding computation, because the means of combination of these primitives are all themselves represented with Lisps. That makes for a very succinct definition for the rules that define computation, because there are fewer special cases to handle. Likewise, it makes it easy to write program-manipulating-programs, because there are fewer special cases to handle. In theory a graph-based language could have similar benefits. Most compilers already represent programs as graphs internally: there are call graphs, control flow graphs, data flow graphs, type graphs, etc. You could imagine a language that tries to make graph construction & manipulation very succinct, and then see how far it gets you. Sure, at some point you have to implement on real hardware, but you can hide the actual implementation, just like the sophisticated compiler techniques used to transform lists into efficient machine code are hidden from a Lisp programmer who just wants to write some macros.

hoosieree 4y ago

Maybe the author implies APL-style programming: in APL, your base datatypes are "array of number" or "array of character" and there's first class support for multidimensional arrays and/or nested arrays. But the main thing is that all the operators take arrays as input and return arrays as output. With "everything is a graph", all your operators would expect to consume and produce graphs. So you'd have operators for parent/sibling relationships, operators for various kinds of traversals, extracting graph shape information to build higher-level operators like subgraph isomorphism (or maybe that would be a built-in operator).

woojoo666 4y ago
So the idea is to first define some static graphs and then use operators to construct larger (possibly dynamic) graphs? But to define those small static graphs in the first place, you have to either use key-value mappings (how Smalltalk/Javascript does it) or maybe RDF format or something.
- hoosieree 4y ago
  That is how I imagine it, yeah. If I was designing an "APL for graphs" I would probably take a lot of inspiration from NetworkX[1]. Especially: generators for various graph types, the ability to read dicts/lists as graph data, and a huge suite of graph-related functions. But I would also want dedicated notation for the most common/composable operations like APL. I particularly like how Jq[2] "functions" are inherently combinators, and Jq has some nice semantics for mapping and filtering operations on trees, but I don't really like its syntax that much. [1]: https://networkx.org/documentation/stable/tutorial.html https://networkx.org/documentation/stable/tutorial.html [2]: https://stedolan.github.io/jq/ https://stedolan.github.io/jq/

nostrademons 4y ago

It's not really different than Lisp. Lists are not a native data representation on any computer other than a Lisp Machine, and S-exprs are a textual representation of a list, not a list itself. Also, most realistic Lisps still admit other primitive types like numbers, strings, symbols, and booleans. Many also have hashtables, structs, and binary blobs. Nobody programs with numbers represented by Peano axioms. Nevertheless, Lisp is still a very useful primitive for understanding computation, because the means of combination of these primitives are all themselves represented with Lisps. That makes for a very succinct definition for the rules that define computation, because there are fewer special cases to handle. Likewise, it makes it easy to write program-manipulating-programs, because there are fewer special cases to handle. In theory a graph-based language could have similar benefits. Most compilers already represent programs as graphs internally: there are call graphs, control flow graphs, data flow graphs, type graphs, etc. You could imagine a language that tries to make graph construction & manipulation very succinct, and then see how far it gets you. Sure, at some point you have to implement on real hardware, but you can hide the actual implementation, just like the sophisticated compiler techniques used to transform lists into efficient machine code are hidden from a Lisp programmer who just wants to write some macros.