[Baypiggies] Mini languages - possible short talk in the future?

[Shannon -jj Behrens]

On 5/10/06, Ken Seehart <ken at seehart.com> wrote:
>  Shannon -jj Behrens wrote:
> On 5/7/06, Ken Seehart <ken at seehart.com> wrote:
>
>  Never mind, this is really trivial.  Any C++ code that is outside my
>  "cellclass" block is passed on unmodified. The only recursion I have to
> deal
>  with in my grammar is a C++ function body.  And since I don't actually need
>  to process the function body, I just need to recursively scan for a pair of
>  matching braces (not rocket science).  Everything else is regular
>  expressions.  I definitely don't need an LALR parser for this :-)
>
>   So I don't have any further questions.
>
>   Thanks Dennis and Dennis for your comments.
>
>   - Ken
>
>   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
>
>  I once interviewed at a company that had implemented a mini-language
>  on top of C++ using templates and operator overloading.  Apparently,
>  they had even overloaded the comma operator.
>
>  /me shudders
>
>  -jj
>
>  Yikes.  Template abuse is pretty scary stuff.  Here's a scary book on the
> subject,
>  for those who are interested. :
> http://boost-consulting.com/mplbook/
>
>  Kind of reminds me of people who get way into John Conways "Life", and
> build
>  computers and things out of glider guns.

Heh, I did my senior thesis on Conway's game of "Life", but now we're
*way* off topic ;)

>  Perhaps a more elegant way to do metaprogramming would be to kind of squish
>  python into the preprocessor phase.

Agreed.  Both the QT folks and the GTK folks have special
preprocessors.  The QT one is mandatory, the GTK one is not.

>  I recommend making sure you actually have a good reason to do this kind of
> thing.
>  Usually more straightforward techniques suffice (e.g. write your program in
> python
>  and use extending and embedding).  But good reasons do exist.
>
>  Anyway, I have successfully completed my NICL compiler.  It really works!
>
>  NICL code -> [preprocessor (cpp)] -> [NICL translator] -> [compiler (gcc)]
> -> object code
>
>  If there is interest, I'd be willing to give a short talk on the topic some
> time:
>    "How to extend the C++ grammar using Python"
>
>  The documentation on my language is here:
>
>
> http://www.neuralintegrator.com/documentation/ni_book/nicl.st

Happy Hacking,
-jj