Have Alloy developers used any parser generator tool (like ANTLR) for parsing alloy specifications, or is its parser built-in and specifically written for the alloy language purpose?
If they used external tool for Alloy parser implementation, how can I access further information regarding this (for example the grammar which is fed into the external parser generator).
Alloy uses a modified version of CUP (which is shipped with the Alloy distribution). You can find the grammar specification files (Alloy.lex and Alloy.cup) inside the edu.mit.csail.sdg.alloy4compiler.parser package. In the same package there are some bash scripts used to generate corresponding lexer/parser classes.
http://alloy.mit.edu/alloy/documentation/book-chapters/alloy-language-reference.pdf
Section B.3 has the grammar.
Can't say anything about the language implementation.
Related
I stumbled upon this post http://compilers.iecc.com/comparch/article/02-04-096
that says there are two Eiffel compilers using Earley parsing. The post is quite old.
I wonder if anyone here knows which Eiffel compilers use Earley parsers and if they are
still in use? Links are highly appreciated.
The modern Eiffel compilers that are used in production (EiffelStudio from Eiffel Software and gec from Gobo Eiffel Project - both open source) parse Eiffel code using the parsers generated by geyacc from the parser description files (here are the links for EiffelStudio and Gobo), a parser generator utility similar to GNU bison, that converts a grammar description for an LALR(1) context-free grammar, but is adapted to produce Eiffel code that is type-safe and void-safe. Neither use an Earley parser.
I am looking into GCCXML, which can parse a given header file and generates XML format of C code meta data. But GCCxml is an open source. Is there any commercial version of c code parser which works similar to GCC XML?
Thanks,
Karthick
The obvious replacement for gccxml will be clang, which is licensed under BSD license (so you can freely use it in commercial projects, do whatever you want with the code, etc.). clang used to have an xml AST dumper built-in, but it was removed at some stage. If you only need to extract specific information (such as function prototypes for IDL generation or stuff like this) it is not difficult to write a basic custom clang plugin to do this. Otherwise, you can search around for existing clang plugins which will do the job, such as this one:
https://github.com/sk-havok/clang-extract
Clang plugin tutorial: http://clang.llvm.org/docs/ClangPlugins.html
See our DMS Software Reengineering Toolkit with its C Front End for an equivalent/superset of GCCXML.
The C front end can handle a variety of C dialects (ANSI, GCC, MS). It contains a full preprocessor. It can export ASTs for the complete language (esp. including function bodies, which GCCXML does not do, IIRC) and its symbol table, both in XML format.
Here at SO there is an example dump of the AST from DMS's C++ front end. This uses the same machinery as the C front end uses.
I am implementing a proof of concept application for source-to-source transformation and need a C-parser with an API for manipulating/traversing the C-syntax tree (AST).
I have tried to use clang but I ran into various problems, like not being able to compile the tutorials using libclang, wrong architecture etc. Since this is a proof of concept application, I will defer clang to a different date.
Question
What are some software/libraries (implemented in any language) which can parse C code and which provide an API so I can build applications on top of them. I looked around, but I could not locate any free parsers.
The platforms I can use are anything on Windows or Mac or Linux, and any parsers written in C/C++/Java/Perl/Python/PHP will work.
You could try one of the available grammars for ANTLR. ANTLR has support for creating tree walkers and you can walk/manipulate the AST manually if necessary. ANTLR V3 has several grammars available including a C preprocessor, ANSI C and GNU C.
The GObject Reference Manual states that the GObject system was designed to export functions written in C to other languages by using some generic glue code. It is also noted that this glue exists for perl and python explicitly. Omitted however, is how exactly where to find and how to use it.
So, lets suppose I have written a new GObject (for the sake of simplicity, the example given in the same manual) complete with C sources and header files, compiled it, and appropriately installed it, locating it where system libraries are to be found. Now I want to instantiate and use the object in a Python program. Or a Perl Program. Or even a Java program. Or any other programming language that has glib bindings available. How exactly can this be done?
Note that I want to use the object directly, most probably through the already existing generic glue code. I am aware of the possibility to use DBus to export the object from a running C program and access it with Python. But I look for no IPC-Solution. Compiled C library objects shall be more or less directly exported to another programming language.
You're looking for GObject Introspection. Once you have that set up properly you can use PyGObject (Python), Gjs (JavaScript), Vala, etc. pretty easily.
All the languages are, obviously, different, but since you sound most intested in Python... the Python GTK+ 3 Tutorial explains the process using GTK+ as an example.
Here's a few examples below. GType and GObject are standards and do not provide the glue code. You'll just want to look for the language you want to use and see if anyone has implemented the glue yet. If not, maybe you can :)
https://wiki.gnome.org/PyGTK/WhatsNew28
http://search.cpan.org/~rmcfarla/Glib-1.020/GType.xs
Are there any tools which would convert existing GSL grammar files to GRXML grammar files ?
I expected such a tool to be alread there but couldn't find it on searching, am I missing something ?
The NuEcho NuGram grammar development environment supports this:
The NuGram platform natively support
the W3C's SRGS ABNF format with
extensions to support the development
of dynamic grammars. The ABNF format
was chosen since it is a W3C standard
and is without a doubt much more
readable and maintainable than the XML
format.
Grammars can be translated to and from
other formats as well. The currently
supported languages are: GrXML (W3C
SRGS XML), and Nuance GSL.
The NuGram platform also supports the
most widely used semantic tag
languages: W3C SISR (including the
SISR 2004 Working Draft syntax),
Nuance's GSL semantic tags, and
Nuance's OSR. tags.
I take it you're currently upgrading from Nuance 8.5 or a previous version? If you are upgrading to the Nuance Recognizer 9-10 engines, there is a tool provided for converting between versions. It isn't a perfect conversion and the converted grammars normally need some modification/refinement, but it is a good starting point.