[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (Adding code to SableCC)



Hi Chris.

>The changes you propose for SableCC sound useful, I look forward to Version
>3.


That's the problem of announcing what I am doing. People start to have
expectations;-)

>I agree that normally one shouldn't be playing around with the AST
>structure, indeed I'm not.  What I needed was two extra classes, after
>building the AST I walk it using a delegator sub-class of
DepthFirstAdapter,
>for each call in* and out* this delegator calls the matching in* and out*
>calls in a supplied set of classes.  I therefore needed to write a
delegator
>and a base delegate classes. Both of these need to duplicate the in* and
>out* methods of DepthFirstAdapter.  It seems to me easier, for both initial
>development and maintenance, and less error-prone to use GenAnalyses to
>build the classes.  Overriding the analyses.txt files and making some
>changes to GenAnalyses provided the route I needed to generate custom
>classes.  It is that ability to automatically generate custom classes which
>I would find useful.


I am very happy to learn that you did not intend to change the AST
structure.

>Another reason that springs to mind for allowing overriding of the analysis
>macros is ease of porting the constructed parser.  It appears to me that it
>would be feasible to generate non-java parsers just be changing the .txt
>files, and supplying a few supporting classes/methods/functions.

You have a very good point as far as the ease of maintenance of SableCC, and
the generation of compilers in other languages.

The generation of compilers on other languages was already in the very far
and long term path of SableCC. In fact, if you hadn't noticed yet, SableCC
grammars have almost no tie to any specific implementation language. The
only Java specific concession I have made is the "Package" declaration. In
the future, it could be removed and become a command line parameter. Or,
preferably, I could add a "language specific" section to a grammar (with a
subsection for each language). This section would be restricted to very
limited scope language dependent directives. The big advantage being that
porting a grammar from one language to another would be a matter of seconds
(or minutes). If there is anymore work to do (to port a grammar), it is not
in the grammar file, but in source files written in the implementation
language (so they can be debugged directly:-). So the same grammar could be
shared by different compilers built using different languages.

Integrating your code would make it easy, for instance, to generate C++ ASTs
with SableCC. But I would like to get my other changes in before we get to
this. It would give SableCC 3 a clear advantage over other existing tools.
This would be harder to debate using the current version. (Yes, politics and
good timing are key for the success of a product, even a free one;-)

>
>As for code updates I see your problem w.r.t. copyright, but I always
>thought that the intention of the GPL/LGPL was that the requirement for
>release was an appropriate copyright disclaimer.  Whilst I can understand
>any desire to remove the administrative overhead of filing and maintaining
>those disclaimers, I don't see the requirement for lawyers.  But, SableCC
is
>your software and so the issue of code changes is up to you.
>

OK. I am ready to accept contributions that are made under the GNU LGPL (or
the public domain). But I need this:

1- The contributed code should be in separate classes,
   as much as possible.
2- Modifications to existing classes should be minimal,
   and packaged as diffs on a specific SableCC version.
   (e.g. SableCC version 2.5).
3- You should send me by postal mail, the two following
   signed documents:
  a) A copyright disclaimer SIGNED BY YOUR employer, as
     outlined at the end of the GNU LGPL text.
  b) A document SIGNED BY YOU, that confirms the copyright notice.
     Specifically, it should confirm that you license your
     modifications/additions to SableCC under the GNU Library General
     Public License. You should also include the text of the copyright
     notice on the signed page and the text of the GNU LGPL as
     appendix.

If you put your code under the public domain, please change the 3rd
requirement as appropriately.

The 3rd requirement is to simplify the handling if any future confirmation
request. If, for instance, a book publisher, or some company wants a written
proof that the code is legally under the GNU LGPL, I will be able (as
primary distributor of SableCC) to actually provide such a proof, without
having to search for each contributor and ask for written proof at that
point of time. It might prove quite hard to do.

(By the way, I could provide such a written proof for existing code, but
DON'T ASK FOR IT, unless you really have some obligation to do so. I know
that some book publishers are not yet quite comfortable with the "online"
way of doing things, so they require such written proofs. I know of no
software publisher that goes that far. Sun, Microsoft and others rely on
unsigned license agreements, when they distribute software online. It's just
that the publishing industry is lagging many years behind, as usual. ;-)

Etienne