> Flare is a proposal for the first "annotative" programming language. In dialects of LISP, both the program and the program data are represented as lists. In Flare, the program, program data, and ideally the program state, are all represented as well-formed XML.
this text is from their 2001 explanation of the language. xml would probably make for very clumsy and obscured program logic.
Stores everything in XML and makes multiple references to that being better than the linked lists used by lisp. I believe XML and s-expressions are equivalent - pretty sure one can losslessly round trip between them.
Beyond that I'm struggling to work out what the language is. Lots of prose to dig through. Uses a lot of unusual terminology without defining their terms, e.g. 'planar'. The few dates I see scattered around at from 2001 so it might also be abandoned.
I don't think they're 1:1 without making the XML very bloaty.
That's to say, if, as many xml libraries for lisps do, you represent (test 1 2 3) as <test>1 2 3</test> or <test><number>1</number> ... </test> then you lose the ability to represent the null list. The way around that would be to use something like <list><element value='test'/><number value='1'/> ... </list> which can then represent the null list as <list/> but you've now made the whole thing massively unwieldy.
So I can't see how it's any progression over s-expressions. Unless I suppose you break the XML syntax itself and make XML able to do things it can't at present, but then you're just reinventing s-expressions.
There's probably others in the tree! But I do think of e4x & how broadly it was lambasted/hated, when I think of how easy & pleasant jsx is.
One noteable feature of e4x was that it's a unified data model. jsx is syntax that feeds a very complex internal data model; it's in effect write-only. e4x was well mapped to simpler objects, sort of.
var person = <person><name>Bob Howard</name></person>;
console.log(person..name);
> jsx is syntax that feeds a very complex internal data model
This really depends. I feel like a broken record, I mention it so frequently, but JSX has no built in semantics. In React and other VDOM libraries it may be complex. But in Solid for instance it’s effectively the declarative subset of E4X.
The JSX data model isn't that much worse than the regular DOM. In many areas it is certainly much simpler. For a while different Virtual DOMs had somewhat different "internal" variants but as React has worked to simplify their internal model over their versions they've all mostly kind of converged at this point and React's virtual DOM objects are just about a de facto standard.
(I've done a tiny bit of virtual DOM meta-programming over the years for various reasons. It's more pleasant than you would expect. TSX has a lot of useful type information for it, even.)
> A new programming language has to be really good to survive. A new language needs to represent a quantum leap just to be in the game. Well, we're going to be up-front about this: Flare is really good.
I feel like projects with this type of language/writing suggest the project won’t be successful.
Neat; thanks for posting this! I just started tinkering with ideas in the same line of thinking a couple weeks ago; it’s good to see that there’s prior art to learn from.
I landed in the same place they did, on using XML. I think there’re a couple of advantages over S-Expressions:
* There’s always a tag. So it’s like everything is a special form. Being able to omit the tag in sexprs is nice syntactic sugar, but I’m not expecting that anyone would be writing this code in text by hand (although it’s useful to preserve the ability to do so), and I’d rather have the clarity and explicit terminators.
* Namespaces are a killer feature - that’s what makes it an open datastructure, allowing you to incorporate multiple dialects at different semantic levels. (You can tell I’ve been using MLIR a lot the past few years… :-)
* There’s a whole ecosystem of standards and tools around it. Need a standard fragment identifier? Or to canonicalize an entity? There’s a good body of specs, carefully worked out by people more experienced than I.
I dunno about their Python approach; I was thinking of a structure editor (and trying to avoid all the historical pitfalls of structure editors, which will be tricky). We’ll see how it goes. :-)
>Jumping off the extensibility of XML, the flexibility of the underlying representation enables Flare to do several fundamental things in fundamentally different ways. Flare incorporates wholly new features, as well as several popular features of other languages which have never before been brought together. The current proposed design for Flare has many proposed features intended to increase cleanliness, modularity, and safety; some of them wholly innovative, others inspired by languages including Python, Java, C++, Eiffel, Common LISP, Scheme, Perl, Haskell, and more
22 comments
[ 2.8 ms ] story [ 60.6 ms ] threadthis text is from their 2001 explanation of the language. xml would probably make for very clumsy and obscured program logic.
but he made everything from a scheme code base :D
Beyond that I'm struggling to work out what the language is. Lots of prose to dig through. Uses a lot of unusual terminology without defining their terms, e.g. 'planar'. The few dates I see scattered around at from 2001 so it might also be abandoned.
That's to say, if, as many xml libraries for lisps do, you represent (test 1 2 3) as <test>1 2 3</test> or <test><number>1</number> ... </test> then you lose the ability to represent the null list. The way around that would be to use something like <list><element value='test'/><number value='1'/> ... </list> which can then represent the null list as <list/> but you've now made the whole thing massively unwieldy.
So I can't see how it's any progression over s-expressions. Unless I suppose you break the XML syntax itself and make XML able to do things it can't at present, but then you're just reinventing s-expressions.
There's probably others in the tree! But I do think of e4x & how broadly it was lambasted/hated, when I think of how easy & pleasant jsx is.
One noteable feature of e4x was that it's a unified data model. jsx is syntax that feeds a very complex internal data model; it's in effect write-only. e4x was well mapped to simpler objects, sort of.
This really depends. I feel like a broken record, I mention it so frequently, but JSX has no built in semantics. In React and other VDOM libraries it may be complex. But in Solid for instance it’s effectively the declarative subset of E4X.
(I've done a tiny bit of virtual DOM meta-programming over the years for various reasons. It's more pleasant than you would expect. TSX has a lot of useful type information for it, even.)
Brutal. Copyright is 2001 which I'm going to assume it's a related fact.
I feel like projects with this type of language/writing suggest the project won’t be successful.
I think with the right language idioms, and good IDE support to mitigate the verbosity, an XML based language could be pretty good.
freudian slip of the caps lock, but I'm leaving it for the irony.
I landed in the same place they did, on using XML. I think there’re a couple of advantages over S-Expressions:
* There’s always a tag. So it’s like everything is a special form. Being able to omit the tag in sexprs is nice syntactic sugar, but I’m not expecting that anyone would be writing this code in text by hand (although it’s useful to preserve the ability to do so), and I’d rather have the clarity and explicit terminators.
* Namespaces are a killer feature - that’s what makes it an open datastructure, allowing you to incorporate multiple dialects at different semantic levels. (You can tell I’ve been using MLIR a lot the past few years… :-)
* There’s a whole ecosystem of standards and tools around it. Need a standard fragment identifier? Or to canonicalize an entity? There’s a good body of specs, carefully worked out by people more experienced than I.
I dunno about their Python approach; I was thinking of a structure editor (and trying to avoid all the historical pitfalls of structure editors, which will be tricky). We’ll see how it goes. :-)
Thanks again for the pointer!
Wow, that brings back memories.
It was the "Github" before Github, but for SVN/CVS.
I can't tell if this is satire or not