I figured I better at least start the Onyx Spec page, so I did. You can find it in the Menu. Built in types are there now. Onyx Spec
I have decided to design, and build my own computer language. It will be called Onyx. I agree, that is a pretty big task. So we will take a bit at time. Design Criteria I don’t really have a whole lot yet. You might think of onyx as C++ EXCEPT - meaning, it acts like C++ EXCEPT these differences. Over time the list will grow and I’ll turn it into a full-feature language spec.
Last time, we looked at the lexer and supporting staff. This time, we will look at the primitive parser and final usage.
Back in this post, I said about Spirit .. …it would be very feasible to write a lexical analyzer that makes a token object stream available via a ForwardIterator and write your grammar rules based on that. But is it ? really? The short answer is - Yes it is feasible, but probably not a good idea. The long answer is the journey we’ll take on the next two posts.
Dynamic Exceptions have their flaws. Herb Sutter has proposed a replacement known as Static Exceptions . Lets look at it a bit. Before we do, we need to look at the C+11 feature std::error_code std::error_code and Friends Anyone who has done any coding in C knows about good old errno, the global int that many system functions will set to signal a problem. This, of course, has many problems, not the least of which is that different platforms could and did use different integer values to represent the same error.
Pivots (turning a column’s values into actual columns) is a very common activity. Spreadsheet programs have robust support for it. But Standard SQL? Not so much. The Problem Create Table orders ( orderNumber int, sku char(3), quantity int, salesPerson varchar(10) ); insert into orders values ( 1, 'ZR34', 2, 'Mary'), ( 1, 'AS99', 1, 'Mary'), ( 2, 'ZR34', 1, 'Jim'), ( 2, 'MB01', 1, 'Jim'); The ubiquitous order table with the SKU, quantity and sales person.
This time around, we will use a custom parser to handle the keywords. I really hadn’t planned on making this a series, but there you go. This will be the last - I think. Upgrades I started from the code from the last post, but did make a minor adjustment. I made underbar (’’) a valid character in an identifier. auto const ualnum = alnum | char('_'); auto const reserved = lexeme[symtab >> !
The ink hadn’t dried1 on my Identifier Parsing post when I realized that there was indeed a better way to handle multiple keywords. In that post I stated that a symbols<T> parser would not help because it suffered the same problem as lit(). Which is true. What I missed was that, of course, you could use the same trick with symbols as you did with lit() to make it work.
I thought I would take a moment and document my current development environment. The main computer runs windows 10. However, the development computer is actually a VirtualBox ArchLinux client running on that Win 10 box. I use X11 Forwarding to display back to an cygwin/X server running on the host. I am currently using Codelite as my IDE, though it has some rough edges. GNU compiler suite rounds things out.
In Boost.Spirit X3, parsing identifiers is a bit tricky. If you are used to the distinction between lexical analysis and syntactical analysis (as I am), Spirit can take some getting used. Lexical analysis is done in the same grammar as the syntactical analysis. So the ubiquitous IDENT token type is now a grammar rule. To be sure, it doesn’t have to be this way. Spirit parsers work on iterator pairs, so it would be very feasible to write a lexical analyzer that makes a token object stream available via a ForwardIterator and write your grammar rules based on that.