Re: Standalone parser

[Etienne Gagnon <egagnon@sprynet.com>]

Mariusz Nowostawski wrote:
> I wonder whether it would be possible to generate (or modify generation
> of) the parser in such a way, that one do not need ca.mcgill.sable.util.*
> in its own package hierarchy.

Hi Mariusz.

There are currently two good reasons to have the SableUtil in its own
package.

(1) Copyright
-------------
You will notice that classes in SableUtil are NOT in the public domain.
They are copyrighted by many individuals, and they are licensed under
the GNU Library General Public License (LGPL). This means that when you
build a framework with SableCC, the generated framework is divided in
two parts: (i) classes generated from the input file, that are
copyrihted by the author of the input file, and (ii) SalbeUtil classes
that are copyrighted by their respective authors.

The LGPL requires that any application that uses the library be
distributed (i) with the library source code (you don't have to provide
the source code for the application), and (ii) that it is possible to
modify the library (fix bugs) and run the application using the modified
library (as long as the interface of the library is stable). [The
application should also mention that it uses the library, and how to
find its source code when it displays copyright information and/or in
its documentation. See the license for details].

The esaiest way to fulfill these requirements is to simply distribute
sableutil-1.11.jar AS IS with the remaining of the application.
sableutil-1.11.jar includes a copy of the LGPL and the source code along
the compiled classes. Additionally, sableutil-1.11.jar can be directly
put on the CLASSPATH.

(2) Multiple parsers/lexers
---------------------------
If you look at the grammars for Java, you will see that in fact you
generate two lexers and one parser, in two different packages. This
would mean, if we were to have a local copy of SableUtil in each
package, that you would have two versions of SableUtil classes in a
single program. This would not be nice. It would take more space and
possibly cause compilation problems in "cross package" code.


In conclusion, I will raise your hope a little. The SableUtil dependency
will probably be eliminated as soon as a <JDK 1.2 only> version of
SableCC is released. This is because most classes in SableUtil (used by
generated frameworks) are simply an implementation of the JDK 1.2
Collection API. So, if we were not to  support the JDK 1.1, we could
simply generate the very few remaining classes in local packages (Cast,
Switch, Switchable,...).


I hope this explains the situation to you, and helps you conform with
the requirements of the LGPL on SableUtil copyrighted code;-).

Etienne
-- 

----------------------------------------------------------------------
Etienne Gagnon, M.Sc.                   e-mail: gagnon@sable.mcgill.ca
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
----------------------------------------------------------------------