Re: [Javaweb-submit] GNU Parse

[Per Cederberg]

Nic Ferrier wrote:
> In general app's have non-generic names. For example my servlet
> engine does not use gnu.servletengine, it uses
> gnu.paperclips. Paperclips is the "product name" if you like.
>
> The same is true of kawa. Per has some packages in gnu.kawa that are
> totally kawa specific.

Ok, I understand your policy. I wouldn't mind gnu.app.paperclips
and gnu.app.kawa, but I guess it's a matter of taste... :)

> You should think of a name for your app and use that as your package
> name, don't put it in a subsidiary name space.
>
> Is there a Javanese equivalent of a yacc? or a bison? Or maybe there
> is some Norwegian spin you could give the product (apologies if
> you're not Norwegian).

Well, Swedish actually. Not that I'd mind being Norwegian,
though... ;-)

But seriously, I gave it another think and came up with
"GNU Foresight" as the project name. Spinning a bit around
the look-ahead tokens. Couldn't find something like it
anywhere (strangely enough).

Now, before I launch a project at Savannah and have to
rename files in CVS, which of the following would you
prefer:

1. Everything under one (top-level) package, using the
   project name. That would be:

     gnu.foresight.* (with 3 subpackages)
         for the application and run-time libraries in
         subpackages for separation

2. Separate package for application and main library.
   That would be:

     gnu.foresight.* (with 2 subpackages)
         For the application and the code generation
         libraries.

     gnu.syntax  (or gnu.grammar)
         For the run-time library that will be used by
         all generated parsers (in theory from any app).
         Contains parser(s), tokenizer, and parse tree
         objects.

3. Separate package for application and all libraries.

     gnu.foresight.* (with 1 subpackage)
         For the application.

     gnu.syntax  (or gnu.grammar)
         For the run-time library that will be used by
         all generated parsers (in theory from any app).
         Contains parser(s), tokenizer, and parse tree
         objects.

     gnu.print.java  (or something better)
         For the Java object model that pretty-prints
         Java source code.

I personally tend to favor 2, as the code generation
library may not be so interesting for others apps.
(Not very many generate source code in any language
AFAIK).

Cheers,

/Per

--
Per Cederberg, Software Consultant
http://www.percederberg.net/software

RMS Birthday Present: It's GNU/Linux dammit! Read more at
http://www.gnu.org/gnu/why-gnu-linux.html
http://slashdot.org/article.pl?sid=03/03/16/2222254