Re: Compiler implementation language preference ?

On Wednesday, 19 December 2018 20:12:34 UTC, Aaron Gray wrote:
> On Tuesday, 22 May 2018 18:39:07 UTC+1, Michael Justice wrote:
> > [Mostly people use what they're used to, or in languages that are easy
> > to bootstrap on the machines they want to use. ...
>
> Pity there are no real compiler-compilers anymore, hint-hint, I am working
on one to rule them all ;)
>
> Aaron Gray
> ---
> [Please don't say you've invented another UNCOL. -John]


John,


No I am not the man from UNCOL !


I am back working on my source to source compiler-compiler in the vein of YACC
but a real compiler-compiler not just a parser generator.


I am hopefully going to have all the main parser algorithms and some little
known ones and some new ones implemented. I have my Lexical Analyser Generator
LG implemented and an working on the Parser Generator PG, and an AST generator
AG, there are a few more tools and components to this. I am using algorithms
that are much simpler, clearer, and cleaner than the existing Flex, Bison, and
Byacc. I have literally implemented the algorithms from the Dragon Book and
even simplified them a bit, and an algorithm for equivalence classes my friend
invented, and am now working on the more complex "meta machine" algorithms.
Hopefully I will be able to parse all major languages.


I am working in C++ using nothing more complex than templates. It is library
based with tools that use the library.


For example I am using the Dragon Book's Regular Expression direct to DFA
technique heres an example of the code :-


signed int DFA::GenerateRG2DFA(LexicalContext* context) {
States states;
State startState = states.newState(context->firstpos());


        this->accept[startState] = -1;
        std::deque<State> UnfinishedStates;


UnfinishedStates.push_back(startState);


        while (!UnfinishedStates.empty()) {
                signed int accept = -1;
                State state = UnfinishedStates.front();
UnfinishedStates.pop_front();
                State nextState;


for (unsigned int input = 0; input < getNumberOfInputs(); ++input) {


bitset followpos(context->getNumberOfPositions());


for (bitset::iterator position = state.positions.begin(), end =
state.positions.end(); position != end; ++position) {
if (position.isElement()) {
if (context->move(position, input))
followpos |= context->followpos(position);


signed int action = context->getAction(position);
if (action != -1 && (accept == -1 || (accept != -1 && action < accept)))
accept = action;
}
}


if (!followpos.isEmpty()) {
                                if (!(nextState = states.findState(followpos)))
UnfinishedStates.push_back(nextState = states.newState(followpos));
                        }
                        else
nextState = State::NullState;


                        (*table)[state.index - 1][input] = (isTerminalState(context,
followpos) ? -1 : 1) * nextState;
                } // end for inputs
                this->accept[state.index] = accept;
        } // end while (!W.empty())


        return startState;
}


Happy Christmas,


Aaron
[Oh, that's entirely reasonable. A lot of the cruft in lex and yacc
and its descendants dates from the era when everyhing had to fit into
64K on a PDP-11. I've never seen any reason to use LALR rather than
LR(1) if you have room for the tables. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.