4 ms·
I... think some humility would serve you well. You are making some very audacious claims about the data structures, -- rose tree storing data on internal
by drostie 9y ago
I... think some humility would serve you well.
You are making some very audacious claims about the data structures,
-- rose tree storing data on internal nodes rather than leaves
data AugmentedRoseTree x = ART {node :: x, children :: [AugmentedRoseTree x]}
deriving (Show, Eq, Ord, Functor)
type TNT token = [AugmentedRoseTree token]
type TN = TNT String
You seem to be making these claims on the basis that there is the following serialization of such trees:
serialize tn unlines $ concatMap linesOf tn where
linesOf (ART x subtrees) = x : [' ' : line | tree <- subtrees
, line <- linesOf tree]
Arguably there's something missing from these in the form of treating blank lines, but let's take a semantics where the deserializer deletes blank lines...
Of course as you're undoubtedly aware, the deserializer for this only gives you a `TN` and to do useful things with this requires a `TNT token` for some more interesting (semantically) token type, your approach is apparently to use the simplest tokenizer,
tokenize :: TN -> TNT [String]
tokenize = map (fmap words)
I guess I just want to point out that while syntax is certainly super important, these data-semantics are not all that novel. In fact they are a subset of s-expressions, assuming parentheses are not used in the lines themselves (and why would they be if `words` is used to parse them?):
sexpr :: [AugmentedRoseTree [String]] -> String
sexpr (ART xs subtrees) = "(" ++ unwords (xs ++ map sexpr subtrees) ++ ")"
Note that the subset you're carving out requires the S-expression to only contain bare symbols as its first several elements, with not-bare symbols being the "indented" parts.
On the flip-side, S-expressions have certainly changed the world computing-wise... I am just dubious that in reinventing a subset of them with slightly better syntax that you have fundamentally changed computing beyond what they already innovated for you.
But, if you want to start a new smallish programming language and see where it goes, this means that a lot of that way is already cleared out for you; feel free to translate Scheme[1] into your new syntax and you will be able to do some things that you are not even dreaming about yet, like macro expansion.
[1]: http://www.scheme.com/tspl4/ http://www.scheme.com/tspl4/
- nsajko 9y agoWith all the revolutionary claims at first I thought that neither of Breck or a,a,b,b,c,c,d,d,j,j,m,m,m,n,n,p,r,s,t,t,x heard about sexp, but they actually mention Lisp in the paper...
- breck 9y agoHaha, thanks for stating this. Very helpful to see the common reactions from various folks (lispers being a category of folks whose reactions I am extra curious about). I'm quite familiar with sexp, (had not seen https://srfi.schemers.org/srfi-49/srfi-49.html https://srfi.schemers.org/srfi-49/srfi-49.html before though--thanks!). What TN and ETNs allow is the power of Lisp, with many more ways to build your programs. You give up a few tiny things (like the ability to have an arbitrary number of arbitrary nodes separated by arbitrary whitespace), and in return gain new powers like visual programming, fast/simple/easy-to-parallelize top down parsers, machine written programs with perfect code, et cetera.
- breck 9y agoWhat a helpful comment, thank you! > I guess I just want to point out that while syntax is certainly super important, these data-semantics are not all that novel. I agree! The data structures and semantics aren't novel at all. Nothing there that Lisp doesn't have. > On the flip-side, S-expressions have certainly changed the world computing-wise... Agreed! > with slightly better syntax that you have fundamentally changed computing beyond what they already innovated for you. It's a great point, and that's what I think the debate will be about. What's new is the matching of the syntax with the semantics, via geometry. The "\n" and " " are arbitrary, really what's going on is the YIndent and XIndent. In my plane, the x indent is " " and shifts a node right by 1, and the y indent is "\n" and shifts a node down by one, but that is arbitrary and just because English goes in that direction. I believe there will be many tricks that will now be borrowed from geometry to augment programmers in new ways. > But, if you want to start a new smallish programming language and see where it goes, this means that a lot of that way is already cleared out for you; feel free to translate Scheme[1] into your new syntax and you will be able to do some things that you are not even dreaming about yet, like macro expansion. A SchemeETN would be great! I've played around with macros in ETNs and there are some really interesting things you can do.