The Flare Programming Language
flarelang.sourceforge.net
flarelang.sourceforge.net
I can't tell if this is satire or not
I think with the right language idioms, and good IDE support to mitigate the verbosity, an XML based language could be pretty good.
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!
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.
this 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
Wow, that brings back memories.
It was the "Github" before Github, but for SVN/CVS.
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);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.
freudian slip of the caps lock, but I'm leaving it for the irony.