help wanted - compiler for a new language, written in Modula-2

[m***@gmail.com]

I am working on a new computer language, and have written a first cut recursive descent transpiler (converting from the new language into AS3 and JavaScript), but need someone to redo the compiler using top down operator precedence (as presented in the lectures by Douglas Crockford), using the Pratt method, which is a fusion of left-right precedence parsing and top down recursive descent. It would be a lot faster than the backtracking that is currently in my compiler. If you know what this all means, and program in modula-2, then please send me a note.

Currently using the ADW modula-2 compiler on Windows, but have a very nice cross-platform low level library that has a version for the P1 compiler.

Will pay commensurate with skill and quality of output.

[j***@gmail.com]

Perhaps combine it with the MC project?

[c***@gmail.com]

Is the grammar for your new language LL-1 ?

Sincerely
Carl Glassberg
----

Post by m***@gmail.com
I am working on a new computer language, and have written a first cut recursive descent transpiler (converting from the new language into AS3 and JavaScript), but need someone to redo the compiler using top down operator precedence (as presented in the lectures by Douglas Crockford), using the Pratt method, which is a fusion of left-right precedence parsing and top down recursive descent. It would be a lot faster than the backtracking that is currently in my compiler. If you know what this all means, and program in modula-2, then please send me a note.
Currently using the ADW modula-2 compiler on Windows, but have a very nice cross-platform low level library that has a version for the P1 compiler.
Will pay commensurate with skill and quality of output.

[m***@gmail.com]

i have an EBNF grammar for the language; it is an indented language like Python. It isn't that hard to parse, about the same size grammar as Swift. After watching the Crockford video on youtube about the simplicity and speed of the Pratt methodology, it is clear that the compiler will be much faster with less backtracking if it uses that approach. A real sticking point in my first cut compiler which was purely recursive descent is that error recovery is very hard to do in recursive descent, and a huge amount of extra code exists to exit out of deeply nested function calls. This was always a weak spot in the Wirth code examples which i learned from. Production compilers are very different than academic versions, as nice error messages are a must for the next 100 million programmers to be. It includes in the language a full 2D graphics and event model and a graph database, as well as shell scripting capabilities. It is designed to replace the full development stack for mobile and web development, which means it is aiming directly at the largest single software development market which is interactive graphics applications for mobile + web. Basically you write your code in a single language. With no make scripts, no package managers, no external database, no frameworks at all, and under 30 API functions for a typical program. It will be competing against Eve, Elm, Red, and a few other "next-gen" languages.

[Marco van de Voort]

Post by m***@gmail.com
i have an EBNF grammar for the language; it is an indented language like
Python. It isn't that hard to parse, about the same size grammar as
Swift. After watching the Crockford video on youtube about the simplicity
and speed of the Pratt methodology, it is clear that the compiler will be
much faster with less backtracking if it uses that approach. A real
sticking point in my first cut compiler which was purely recursive descent
is that error recovery is very hard to do in recursive descent, and a huge
amount of extra code exists to exit out of deeply nested function calls.
This was always a weak spot in the Wirth code examples which i learned
from.

Strangely I always considered the Wirth languages the ones with good error
handling support, and that was often attributed to them typically being RD
as almost LL(1) languages too.

It might simply be a bad fit for your particular language though.

[Chris Burrows]

Post by m***@gmail.com
A real
sticking point in my first cut compiler which was purely recursive descent
is that error recovery is very hard to do in recursive descent, and a huge
amount of extra code exists to exit out of deeply nested function calls.
This was always a weak spot in the Wirth code examples which i learned
from.

How old were these examples that you were using? The strategy used by Wirth in his latest Project Oberon compiler does not have that problem. He describes the strategy as follows:

"Also, the language Oberon is designed with the property that most large constructs begin with a unique symbol, such as IF, WHILE, CASE, RECORD, etc. These symbols facilitate the recovery of the parsing process in the erroneous text. More problematic are open constructs which neither begin nor end with key symbols, such as types, factors, and expressions. Relying on heuristics, the source text is skipped up to the first occurrence of a symbol which may begin a construct that follows the one being parsed. The employed scheme may not be the best possible, but it yields quite acceptable results and keeps the amount of program devoted to the handling of erroneous texts within justifiable bounds."

For the full source code of including extensive documentation of his RISC5 Oberon compiler and the operating system that was built entirely using the language see 'Project Oberon 2013' at:

https://people.inf.ethz.ch/wirth/

If your compiler is having difficulty parsing your language then you should consider that as a warning sign that humans may have similar difficulties when trying to fully comprehend your language. I'd advise you to rethink the language design for areas that are causing you specific problems.

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com/RISC5

[trijezdci]

This post might be inappropriate. Click to display it.

[Pascal J. Bourguignon]

Post by trijezdci

Post by m***@gmail.com
This was always a weak spot in the Wirth code examples which i learned from.

Wirth never taught error recovery. His examples were meant to
illustrate the general process of recursive descent, not its error
recovery. You may want to read other authors who actually cover error
recovery. For example Dick Grune.

On the other hand, when you have a fast (unsophisticated, therefore
correct and fast) compiler, you can easily compile up to the first
error, correct it in the IDE, and then compiler again up to the next
error.

Error recovery was important when you used batch compilers in batch
environments, but not when you're compiling interactively in an
interactive IDE.

[trijezdci]

This post might be inappropriate. Click to display it.