The fact that its grammar cannot be expressed as EBNF (like Ada) does not mean that it's not precise and consistent. You look at some input and at the xl.syntax file, and you know exactly what parse tree you are getting out of that input. You look at the various rewrite rules (the things given by the rewrite operator -> and you know exactly what's going to be executed and why.

Overall, the grammar is much more consistent than most other languages, if only because it's so small. As I indicated elsewhere in this discussion, scanner and parser together represent some 1500 lines of C++ code, and a syntax file that is currently 62 lines long. A complete and precise description of the core language in plain english takes about 50 pages. Compare that to the 700 pages for the C++ standard, and tell me which one is easier to teach?

If you want to look at your input in a Lisp-ish syntax, you can, there's an option in the compiler to dump the parse tree in such a format. If you build the command-line compiler for XLR, it will be xlr -parse file.xl -style debug -show. You can also try -style dbghtml to see it create HTML coloured boxes corresponding to the program structure. For example, if you have the default syntax file, input http://pastebin.com/TTbCKshW turns into http://pastebin.com/wxZX2Fc0. It's absolutely deterministic.

The additional grammar rules I mentioned earlier, e.g. the distinction between statement and expression, are there to match the way we humans read code. That's what concept programming is about.

The locally function is conceptually equivalent to running its argument surrounding it with graphics state save/restore code. That's about it. So you can't deduce anything about call-by-value from it.

Now, to address your question in short, XL uses call-by-reference, and lazily evaluates the arguments as required to perform the call. Cases where you need to evaluate include: having to check against a type that is not "tree", comparing against a pattern, comparing for identity between arguments. For more details, see section 3.3. "Evaluation" of https://raw.githubusercontent..... You can also explicitly evaluate something with 'do'. In the 'if-then-else' definition given elsewhere, there is a 'do' for the bodies, to force evaluation of only that argument to if-then-else corresponding to the condition. If the condition is true, you only evaluate the true clause. If it's false, you only evaluate the false clause.

Maybe you never had to work in a large project where the project most productive guy did no care about indentation at all. Whitespace has a semantics for our brain, so we might as well make that consistent with the code. It reduces syntactic noise, in concept programming jargon.

I put the sample code on http://tao3d.sourceforge.net/ closer to the beginning. Hope that helps.

That being said, people don't seem to like the "Reveal.js" form factor too much overall. I may have to change that.

Sorry, my example was confusing. It's not about RTL it's about number of polygons. Writing most non-latin scripts in small font size tends to create zany numbers of polygons. Same thing with a few contorted latin fonts.

Too bad you failed to note how high-nosed and arrogant your own "Seriously...!" sounded :-)

Let me disappoint then. I don't think you can even write a valid EBNF for XL, it's too dynamic for that. Let me explain why.

First, scanning and parsing are really very simple. The scanner is 747 lines of code with comments. The parser is 659 lines of code with comments. The scanner produces a stream of tokens. The parser produces an abstract syntax tree built with exactly 8 node types: integer, real, text, name, infix, prefix, postfix or block. The abstract syntax tree is used both for code and for data. A list such as 1,2,3,4 is really a sequence of infix "comma" nodes with integers as leafs.

What makes it difficult to produce a valid EBNF for XL is that the precedence rules between operators are dynamic. They are initialised from a file called xl.syntax, but they can be changed at run-time. So, of course, I can write an EBNF for if-then-else that would be something like:

But that would be imprecise. In reality, with the default syntax, if X then Y else Z parses as (infix else (infix then (prefix if X) Y) Z) (using a Lisp-like notation). That happens because of the specifications of infix priorities for then and else given in xl.syntax. Furthermore, the meaning of this particular parse tree is only given by a "rewrite", i.e. a definition such as if X then Y else Z -> ifthenelse(X,Y,Z). It is intentionally not given by a grammar of any kind. Definitions like this are even more dynamic than the priorities. They are the XL equivalent of functions, so you use them all the time.

Even writing a valid EBNF for integer literals would be hard. XL accepts 16#FFFF_FFFF as a valid integer, but 12#FFFF is not valid because F is not a valid digit in base 12. Ada has the same problem, and most EBNF descriptions of based literals for Ada are wrong. This one for example over-simplifies things and considers 12#FF# as a valid number when I assume any valid Ada compiler would reject it. Of course, you could enumerate all the 36 cases to have a valid EBNF that actually represents the language, but at some point, you have to ask: "what's the point"? And if the idea is to describe a language that is only approximately XL, taking more space to do so than the valid C++ code describing what XL actually is, then that's another big "what's the point" in my book.

Finally, there are a number of priority-based shenanigans that were introduced to make the language easier to use, but make it even more complicated to describe in EBNF or anything like it. Here are two examples.

When you read write -A, you normally read this as "write(minus(A))". On the other hand, if you write A-B, you probably read this as "minus(A,B)". It's not logical, but that's how we read. That leads XL to pay attention to spaces surrounding operators to decide what you mean. I hear you "yuck", but it just works.

Another scenario is even worse. Consider write sin x, sin y. All the people I tried that with read it as "write(sin(x), sin(y))". Problem is that this reveals a priority inversion in our brain. If the comma has lower precedence than function calls, then it should read as write(sin(x)), sin(y). If it has higher precedence, then it should read as write(sin(x,sin(y)). None of them is right. For this reason, XL and therefore Tao3D have a notion of "expression vs. statement" implemented in the parser. Again, it's "yuck" for formal grammar nazis. But again, I don't care, because it just works.

Your post is long, so I'll only address a few snippets by lack of time.

The answer is complex. I try to address it in this article. It's not just for the sake of inventing a new language, it's because what I wanted to do I could not do with JavaScript.

Variables need to be declared, but an assignment does declare a variable in that scope.

The 'locally' function does not concern variables, but graphic state. It's a way to say "I don't want this rotation to escape this block". In OpenGL terminology, you can think of it as a PushMatrix/PopMatrix pair (and same for other attributes).

If you define something like:

        translate X Y Z -> translate X, Y, Z

then you probably are close to what you want. In practice, this forced me to add many parentheses (as you just did), and I found using a low-priority comma to separate arguments was much more practical.

Yes.

If someone wants to give Emscripten a try ;-)

Thanks for the encouragements.

I have other plans to achieve that same effect. What out for Buddda ;-)

Yes. You can actually see XLR as a Lisp without the parentheses.

OK, game on. Give me the syntax for the following in Lisp, Scheme, OCaml, whatever:

import Slides
slide "Example",
        * "First bullet point, with seconds: " & seconds
        * "Second bullet point"
        ** "Second level bullet point"
        blink
                * "Third level bullet point"
        anchor
                translate mouse_x, mouse_y, 200 * sin time
                color "white"
                texture "http://www.planetaryvisions.com/images_new/4128.jpg"
                rotate_y 20 * time
                sphere 200

Things like blink, anchor or slide are all functions, of course.

The project actually started in 2009. And I'm not even sure that WebGL is mature enough today for some of the things we do. It's not so long ago that Microsoft adopted it. And hey, it can't even display the background shaders on http://tao3d.sourceforge.net..... Enough people started complaining that I had to remove them.

So if WebGL is not good enough for a web page, I doubt it would be good enough for many of the features in Tao3D. But one benefit of open source is that you can try and transcode it in JavaScript and see how well it works. I'm really interested to see you display 3D extruded arabic text on your 2011 Blackberry ;-)

It's a recursive descent parser, which is technical jargon for "I know enough about parsing to drop Lex and Yacc".

There is a for XLR, work in progress (both the language and the doc).

What are the objections of the people you know to GPLv3 for a new project? I know of the objections for Linux. I also know why I like GPLv3.

The website uses Reveal.js, a presentation framework for the web. I find it useful for tutorials and such. You don't have to like it any more than you have to like the GPL v3.

I am the author of XL. So I guess I don't get it twice then ;-)

By the way, what I'm looking for is contributors to the project. So yes, I steer. I don't care about the whiners on Slashdot. Their numbers increased steadily over the past few years. It's too bad. I still remember when it was not hard to find interesting comments on Slashdot.

I try to answer questions to be helpful. Sorry if that bugs you.

BTW, some people see 'descubes' where he isn't ;-)

Here is that tells you more what this is about.