faq

Alpag was still actively developed somewhere around 2017-2018.
Currently it is in maintenance phase. I have no time to add new features to it.
Still I intend to keep it up and running, providing bug fixes and adding support for new langauge features, framework versions etc.

Alpag available for download here is actually called 'alpag free' which suggests that there was (to some degree even stil is) alpag non-free. To make alpag open source it would have to be separated from non-free version. Besides, since there is nobody else willing to maintain it (except from me), i suppose it doesn't really matter.

Generally no, but then yes. If you suggest a feature that I find worthy adding, why not. Still, in most cases, adding new features to alpag occured to be more time-consuming than I thought. This is especially true for features that influence generated code (since these must be cross checked with all other features).

Currently there are no plans to add support for other languages in 'alpag free'. Sorry.

Report bugs to
I cannot guarantee any 'service level' on this. If I have time I'll take a look into it.
There are a few more things to note here:
If the error you are reporting is a total app crash, then situation is obvious: it's a bug to be fixed. However typical problems people encounter is getting parser or lexer which basically does work, but different than expected. Which does not necessarily mean there is a bug in the tool. It can be an error in the grammar as well (and usually is). So don't expect me to spend hours checking your input files to point out your errors. If you want to report a bug of type 'incorrect parser generated' your bug report must be supported by a really sound analysis.
What a bug report should contain? Everyting: input files used, alpag version, output files you got, and what's wrong about them.

New releases of alpag may in general:

• make changes to algorithms generating parsers and lexers. This means that new release may give different lexer/parser tables than previous version.
• have changed skeleton files used to generate source code. This will result in different code generated even if input file did not change.
• and well, can also contain new bugs

This is why I strongly urge you to backup the version of alpag you were using in your development and keep it along with your code. If a new version of alpag (ever) arrives, and is buggy, you'll be able to fall back to older version.
New version may produce source code which, even if 'compatible' with older code, differs from it in some way (like even indentation or whitespace). So if you made no changes in your grammar and want see no changes in code, simply do not migrate to newer version.

There are two things to this:

• grammar syntax for lexer and parser
• overal file format

As for grammar:
Alpag is down compatible with lex/yacc. So you should be able to use any existing lex/yacc grammar with it as is (save the fact that code for rules in alpag will be C#, not C/C++).
Still, I strongly urge you to read alpag manual on syntax of its input grammar as alpag has many improvements ofer lex/yacc.
As for overall input file format:
Initial versions of alpag were trying to mimic lex/yacc as much as possible (like having sections separated by '%%') This approach was abanodened though. Currently alpag expects input file with sections separated by literal keywords like %%lrules or %%prules which tell exactly what the contents of the file is).
Summarizing, if you are using some ready lex/yacc grammar, you can paste the grammar as is, but you should tweak the file layout a bit.

Initially alpag was a set of separate tools, later merged into one. The idea behind this move was to enable:

• having lexer and parser grammar in one place.
• enable some synergy (like having common token set recognized by both lexer and parser grammar)
• mimic to some degree look and feel of tools generating combined lexer-parsers (like scanerless parsers)

and at the same time:

• maintaining all the elasticity one has with distinct lexer parser
• providing ability to easily switch between combined lexer-parsers and separate lexers and parsers
• enabling all the dirty tricks like shims, lexer hacks and any intermediate code between lexer and parser.

If you can find no benefit from this approach, at worst, consider alpag a lex and yacc in a single executable.

Alpag executable is obfuscated. With some aggressive virus scanners (typically ones used in business environments) it can be detected as dangerous app.
You can report me such cases, and I may be even able to help. Though in generall I cannot guarantee no such behaviour occurs. And I cannot guarantee that the app you get is bug/virus/threat free. So when in doubt, simply don't use it.

As you like it. I pronounce it like al-gorithm or Al Capone (but without Capone). So not like 'owl-pagh' but rather 'ahl-pagh'.