having noted the somewhat high-nosed, arrogant tone of your answer
Too bad you failed to note how high-nosed and arrogant your own "Seriously...!" sounded :-)
Anyone into compiler construction and wanting to / trying to use your language would want a grammar
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:
if then else = "if" condition "then" statement "else" statement
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.