>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
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. :-)
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.
> 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.
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);
> 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.
[+] [-] Modified3019|3 years ago|reply
I can't tell if this is satire or not
[+] [-] lliamander|3 years ago|reply
I think with the right language idioms, and good IDE support to mitigate the verbosity, an XML based language could be pretty good.
[+] [-] earhart|3 years ago|reply
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!
[+] [-] JonChesterfield|3 years ago|reply
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.
[+] [-] NikkiA|3 years ago|reply
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.
[+] [-] andsoitis|3 years ago|reply
this text is from their 2001 explanation of the language. xml would probably make for very clumsy and obscured program logic.
[+] [-] agumonkey|3 years ago|reply
but he made everything from a scheme code base :D
[+] [-] alberth|3 years ago|reply
Wow, that brings back memories.
It was the "Github" before Github, but for SVN/CVS.
[+] [-] uoaei|3 years ago|reply
[+] [-] Yahivin|3 years ago|reply
[+] [-] rektide|3 years ago|reply
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.
[+] [-] ARandomerDude|3 years ago|reply
[+] [-] brundolf|3 years ago|reply
[+] [-] alangibson|3 years ago|reply
Brutal. Copyright is 2001 which I'm going to assume it's a related fact.
[+] [-] mshockwave|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] anongraddebt|3 years ago|reply
I feel like projects with this type of language/writing suggest the project won’t be successful.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] aliqot|3 years ago|reply
freudian slip of the caps lock, but I'm leaving it for the irony.
[+] [-] unknown|3 years ago|reply
[deleted]