design doc for fractint formula parser
Hi All, I am trying to implement a parser for my FractaCanvas project to read fractint formulae. I have got as far as extracting tokens and checking for placement. Does anyone have any design doc that describes how parser.c works (you do use design doc don't you). David
On Tue, 2004-02-10 at 17:04, David Burnett wrote:
Hi All,
I am trying to implement a parser for my FractaCanvas project to read fractint formulae. I have got as far as extracting tokens and checking for placement. Does anyone have any design doc that describes how parser.c works (you do use design doc don't you).
OK, this is not really all that similar to what you asked for, but... I've written a parser + compiler for Fractint .frm files in Python, using the PLY parser-generator. While this may not be directly usable for you, it is at least a concise description of what I think the Fractint parser understands. It actually parses a superset of the syntax accepted by Fractint and understands a bunch of UltraFractal constructs - that may or may not be a problem for you. The lexer + parser are relatively self-contained and output an AST. You can find them at http://cvs.sourceforge.net/viewcvs.py/gnofract4d/gnofract4d/libfract4d/compi... You'll need fractlexer.py, fractparser.py, absyn.py, lex.py and yacc.py. You could also try looking at the user documentation that comes with UltraFractal - it has a good, albeit informal, description of the syntax and standard library that I found that very useful. Regards, -- Edwin
Thanks for that, as you say not quite, but certainly interesting to look through. I like the idea of supporting more than one type of formula file type. Somethign that ChaosPro seems to have taken to extremes. It certainly stretches my meagre knowledge of python (which is not a bad thing). The code seems to parse and check the tokens (something I already have working). Though it does build them into a tree, which is presumably an execution tree. I wanted to avoid lex and yacc as I want to run this as an applet, so it has to be small javaCC alone is 370k - more than 3 times as large as my applet.. I think I just have to bite the bullet and start into it. Too late tonight though. I have a dusty old copy of the dragon book, which hasn't been opened in 15 years. regards David Edwin wrote:
On Tue, 2004-02-10 at 17:04, David Burnett wrote:
Hi All,
I am trying to implement a parser for my FractaCanvas project to read fractint formulae. I have got as far as extracting tokens and checking for placement. Does anyone have any design doc that describes how parser.c works (you do use design doc don't you).
OK, this is not really all that similar to what you asked for, but...
I've written a parser + compiler for Fractint .frm files in Python, using the PLY parser-generator. While this may not be directly usable for you, it is at least a concise description of what I think the Fractint parser understands. It actually parses a superset of the syntax accepted by Fractint and understands a bunch of UltraFractal constructs - that may or may not be a problem for you.
The lexer + parser are relatively self-contained and output an AST. You can find them at
http://cvs.sourceforge.net/viewcvs.py/gnofract4d/gnofract4d/libfract4d/compi...
You'll need fractlexer.py, fractparser.py, absyn.py, lex.py and yacc.py.
You could also try looking at the user documentation that comes with UltraFractal - it has a good, albeit informal, description of the syntax and standard library that I found that very useful.
Regards, -- Edwin
On Wed, 2004-02-11 at 03:43, David Burnett wrote:
I wanted to avoid lex and yacc as I want to run this as an applet, so it has to be small javaCC alone is 370k - more than 3 times as large as my applet..
Surely however you don't need to redistribute javaCC? Most parser generators output code which you compile into your program and then are no longer required at runtime. The code they output is usually table-driven and will probably be a bit bigger than something you write by hand, but it may not be as bad as you think. Incidentally, one weird part of Fractint's parser which I haven't yet tried to emulate is that you can insert \ *in the middle of a token*, eg x = y &\ &z is the same as x = y && z. This is really painful to deal with in a standard lexer & is probably best handled by preprocessing the file with a regular expression. -- Edwin
Edwin wrote:
Incidentally, one weird part of Fractint's parser which I haven't > yet tried to emulate is that you can insert \ *in the middle of a token*, eg
x = y &\ &z
is the same as x = y && z. This is really painful to deal with in a standard lexer & is probably best handled by preprocessing the file with a regular expression.
Why is that weird? It's just an escape for a newline that allows something that is logically a single line to be broken into two lines. You are right, it's not really part of the language, and is best handled by a preprocessor. Tim
On Wed, 2004-02-11 at 16:07, Tim Wegner wrote:
Edwin wrote:
Incidentally, one weird part of Fractint's parser is that you can insert \ in the middle of a token
Why is that weird? It's just an escape for a newline that allows something that is logically a single line to be broken into two lines.
I guess weird's not the right word, but it's definitely unusual - the majority of languages I've looked at don't allow this. From the formula author's point if view it makes perfect sense. I'm mostly just bitter because I can't think of a good way to support it *and* provide sensible line numbers in my compiler error messages - but that's my problem, not Fractint's ;-) -- Edwin
perhaps not weird, but certainly strange. do we have to deal with whitepace in the middle of identifiers. ie could this happen x = y &\ &z where the next line has whitespace at the start I had been treating LF as a delimiter, so Edwins point was useful. I currently have parsing of input tokens working and rendering of output tokens.working. Now I have to get the bit in the middle working, the one that converts the input stream to the output format. Everything else was relatively easy, but this part should be fun......... Edwin, how do you find the yacc usage (or rather the output thereof) for speed db Tim Wegner wrote:
Edwin wrote:
Incidentally, one weird part of Fractint's parser which I haven't >
yet
tried to emulate is that you can insert \ *in the middle of a token*, eg
x = y &\ &z
is the same as x = y && z. This is really painful to deal with in a standard lexer & is probably best handled by preprocessing the file with a regular expression.
Why is that weird? It's just an escape for a newline that allows something that is logically a single line to be broken into two lines.
You are right, it's not really part of the language, and is best handled by a preprocessor.
Tim
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
-- regards David
participants (3)
-
David Burnett -
Edwin -
Tim Wegner