The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
I translated your text with Google translate and found out that it is about an UDEMY course "WPF e XAML em PORTUGUÊS".
I think the problem that you have no subscribers is caused by the fact that it is written in portuguese which narrows down the audience, so I would advise to translate it into English.
But it may also be a question of time before you get subscribers, as your course is quite new.
So in my Rolex lexer reboot, I'm potentially adding a way to specify lexer rules using eXtensible Backus-Noir Form instead of regex (although you can also use regex)
My parsers already allow for this. But I'm thinking of including this feature in my lexer directly.
This creates a strange problem for me, wherein as soon as I add this feature my lexer documents fit the exact same format as my parser documents.
Well, the what is that if you pass the same document to a parser that you pass to the lexer you'll get different results, and you shouldn't. You should get just the terminals rendered by the lexer generator. That way the parser can work with the lexer from the same spec document.
But if i pass one of these documents to my lexer, it will treat all of the elements as terminals! why would it not?
My options are to make a new file format specifically to distinguish between this one and XBNF, or to make Rolex only render parts of the XBNF document - the terminal parts. It's kind of counterintuitive that last bit, but it's the Right(TM) result.
Fortunately with the last option if you only use regex in it, none of the above matters. But if you start using BNF in it, it will get confused as to what's a terminal and what's not, forcing you to mark every terminal declaration with the terminal attribute.
I don't like that.
I might make a command line option to either force the document to be a lexer document, or to force it to be treated as a parser document.
This is confusing even to explain. There has to be a better way.
BNF has a much wider, fascinating, usage in the history of modern logic, and, computer science: [^]
The origin of BNF is not as important as its impact on programming language development. During the period immediately following the publication of the ALGOL 60 report BNF was the basis of many compiler-compiler systems. Some directly used BNF like "A Syntax Directed Compiler for ALGOL 60" developed by Edgar T. Irons and "A Compiler Building System" Developed by Brooker and Morris. Others changed it to a programming language. The Schorre Metacompilers made it a programming language with only a few changes. <class name=""> became symbol identifiers dropping the enclosing <,> and using quoted strings for symbols of the target language. Arithmetic like grouping provided simplification that removed using classes where grouping was its only value. The META II arithmetic expression rule shows grouping use. Output expressions placed in a META II rule are used to output code and labels in an assembly language. Rules in META II are equivalent to a class definitions in BNF. The Unix utility yacc is based on BNF with code production similar to META II. yacc is most commonly used as a parser generator, and its roots are obviously BNF. BNF today is one of the oldest computer-related languages still in use.
The way Panini nailed it some 2500+ years ago [^] fascinates me ... if i had another life, I'd study Sanskrit grammar.
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali