[Baypiggies] Mini languages
Ken Seehart
ken at seehart.com
Sun May 7 22:48:06 CEST 2006
Dennis Allison wrote:
>Ken --
>
>"a simple language translator" is not comensurate with "a superset of C++"
>
>
>Some might say it's an oxymoron.
>
>
What I mean is that my language adds just a few elements to C++, and
these elements are so simple that
they can be easily parsed with regular expressions.
/... c++ code .../
cellclass mycell {
/(stuff that I need to parse)/
cfn /(more stuff that I need to parse)/ {
/... c++ code .../
}
/.../
}
/... more c++ code .../
/.../
The "stuff that I need to parse" can be done with trivially easy regular
expressions (no recursion).
The C++ code will be left unmodified (and I do not need to extract any
information from the C++ code).
So, while my language is technically a superset of C++, I do not intend
to implement a C++ parser :-)
For details, see the link...
http://www.seehart.com/neuralintegrator.com/documentation/ni_book/defining_cell_types.st
>It looks like what you are wanting to do is to build a little lanaague
>that you parse and output C++ object code. I do that sort of thing all
>the time; and I am sure I am not alone. There are a bunch of different
>parsing tools available in python, but if the language really is simple,
>I'd go for a recursive descent parser written in python; if it is
>expression heavy, you might want to do expressions by some bottom-up
>scheme. Trees make a nice intermediate form. The big question is what
>you want to do in terms of optimization. With a C++ target, I suppose
>that you leave that to gcc.
>
>
Well, not exactly... The input is C++ with a little extra non-c++
syntax added, and the output is pure
C++.
>You might want to reconsider your approach and use python as the language
>and C++ extensions to do the heaavy lifting, if necessary. You could, of
>course, make custom extensions for specific problems as an optimization.
>
>
Thanks, already doing that at a higher level of the program. All user
interface and high-level coding
is in python.
I've decided that a speciallized language is worth having to facilitate
rapid development of a large
number special functions that plug into my application in a specific
way. These are not python
extention functions, but are called directly by a core engine. The
function call protocol must optimized
for speed, since millions of these special functions will be executed
consecutively.
>On Sun, 7 May 2006, Ken Seehart wrote:
>
>
>>I want to implement a simple language translator (a superset of C++),
>>but I haven't done anything of this kind since college (a couple decades
>>ago). I would like to use python tools as much as possible.
>>
>>NICL code -> [C++ preprocessor (gcc)] -> [NICL translator] -> [C++
>>compiler (gcc)] -> object code
>>
>>The translator needs to be able to parse special non-c++ syntax to
>>generate c++, and leave other code intact.
>>
>>More documentation on my project here:
>>
>>http://www.seehart.com/neuralintegrator.com/documentation/ni_book/defining_cell_types.st
>>
>>I could almost get by with just a python script using regular
>>expressions (my grammar is simple enough), but I need to know a certain
>>amount of contextual information. E.g., if I am parsing "cellclass
>>mycell { ... }", the contents between the braces must be processed
>>accordingly. This means I have to know when I reach the closing brace
>>(which I can't do with regular expressions). However, I'm sure I could
>>do a prototype this way, using the assumption that the a closing brace
>>on a class matches "^};", but that would be just plain sloppy :-)
>>
>>So I think one way or another I'm stuck with implementing an LALR parser.
>>
>>I'm wondering if there is anyone in this community with experience doing
>>this kind of thing.
>>
>>- Ken Seehart
>>
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/baypiggies/attachments/20060507/d6f85793/attachment.html
More information about the Baypiggies
mailing list