Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2138
| From | Aaron Gray <aaronngray@gmail.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Compiler implementation language preference ? |
| Date | 2018-12-21 04:17 -0800 |
| Organization | Compilers Central |
| Message-ID | <18-12-010@comp.compilers> (permalink) |
| References | <18-05-009@comp.compilers> <18-12-007@comp.compilers> |
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]
Back to comp.compilers | Previous | Next — Previous in thread | Find similar
Compiler implementation language preference ? Michael Justice <nullcompiler@gmail.com> - 2018-05-22 04:58 -0400
Re: Compiler implementation language preference ? w.clodius@icloud.com (William Clodius) - 2018-05-23 10:14 -0600
Re: Compiler implementation language preference ? Walter Banks <walter@bytecraft.com> - 2018-06-07 12:58 -0400
Re: Compiler implementation language preference ? rockbrentwood@gmail.com - 2018-11-09 14:29 -0800
Re: Compiler implementation language preference ? Kaz Kylheku <157-073-9834@kylheku.com> - 2018-11-10 04:00 +0000
Re: Compiler implementation language preference ? Kaz Kylheku <157-073-9834@kylheku.com> - 2018-11-10 04:20 +0000
Re: Compiler implementation language preference ? Richard <portempa@aon.at> - 2018-11-10 15:06 +0100
Re: Compiler implementation language preference ? Walter Banks <walter@bytecraft.com> - 2018-11-10 21:46 -0500
Re: Compiler implementation language preference ? Nick <ibeam2000@gmail.com> - 2018-11-13 02:14 -0800
Re: Compiler implementation language preference ? Aaron Gray <aaronngray@gmail.com> - 2018-12-19 11:54 -0800
Re: Compiler implementation language preference ? steve kargl <sgk@REMOVEtroutmask.apl.washington.edu> - 2018-12-19 23:19 +0000
Re: Compiler implementation language preference ? Aaron Gray <aaronngray@gmail.com> - 2018-12-21 04:17 -0800
csiph-web