comp.lang.ada
 help / color / mirror / Atom feed
* Resolving Long Filenames for Packages
@ 2018-01-24 16:23 alexander
  2018-01-24 17:21 ` Robert Eachus
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: alexander @ 2018-01-24 16:23 UTC (permalink / raw)


In my current project, I am making an attempt to elaborate on the means of which a serie of automata operates (and is structured), by building my own version of regular expressions (even though not called that, nor functioning in the exact same way.)

To compile my code I'm using AdaCore's GNAT by running the command `gprbuild`. This means I also have a project file associated with the project, which in and of itself, is looking very basic. It only contains a means of locating the main procedure and executing it.

For my experimental implementation of automata, I have ended up with six different flavors of automata, which I have put in a separate directory, because the names tend to get extremely long:

expressions-parser-automata (the directory)
    expressions-parser-automata-automaton_x.adb
    expressions-parser-automata-automaton_x.ads
    expressions-parser-automata-automaton_y.adb
    expressions-parser-automata-automaton_y.ads
    expressions-parser-automata-automaton_z.adb
    expressions-parser-automata-automaton_z.ads
    expressions-parser-automata-automaton_w.adb
    expressions-parser-automata-automaton_w.ads
    ...

This brings me to my question. Is there a better way to structure an Ada program than this?

Each executive automaton package contains a tagged type and an access type to that tagged type. As such, these files all essentially contain different sub-classes of a super automaton class.

What I'm looking to avoid are the long filenames. Preferably, I would personally want to have a similar structure to what you normally see in modern day programming languages, whereas each package has its own directory dedicated to it (and all its sub-packages), but from what I've seen that's not a thing generally done in Ada.

Once again, how would I generally go about structuring an Ada application to avoid such long filenames? Is there some sort of compiler option I can use? Can I do something about it inside my project (`gpr`) file?

Best regards,

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Resolving Long Filenames for Packages
  2018-01-24 16:23 Resolving Long Filenames for Packages alexander
@ 2018-01-24 17:21 ` Robert Eachus
  2018-01-24 21:18 ` G. B.
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Robert Eachus @ 2018-01-24 17:21 UTC (permalink / raw)


On Wednesday, January 24, 2018 at 11:23:20 AM UTC-5, alex...@junivörs.com wrote:
> In my current project, I am making an attempt to elaborate on the means of which a serie of automata operates (and is structured), by building my own version of regular expressions (even though not called that, nor functioning in the exact same way.)

Hmm. It is difficult to define a subset of regular expressions which is not a complete subset. If you have * | () and some way of defining terminal symbols you get all REs.  Supersets are easier. ;-)

As for the naming issue, I would either go with EPAA_x.ads or automaton_x.ads, there is no need to repeat the directory name since you can use a fully qualified path when needed.

Or, you can stay with the full names, and have renames where needed.  In fact, you might want to put all of the units in an (Ada) package Expressions_Parser_Automata, and rename that package as EPA. 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Resolving Long Filenames for Packages
  2018-01-24 16:23 Resolving Long Filenames for Packages alexander
  2018-01-24 17:21 ` Robert Eachus
@ 2018-01-24 21:18 ` G. B.
  2018-01-25  9:50 ` alexander
  2018-01-25 14:13 ` Stephen Leake
  3 siblings, 0 replies; 5+ messages in thread
From: G. B. @ 2018-01-24 21:18 UTC (permalink / raw)


<alexander@xn--junivrs-e1a.com> wrote:
> In my current project, I am making an attempt to elaborate on the means
> of which a serie of automata operates (and is structured), by building my
> own version of regular expressions (even though not called that, nor
> functioning in the exact same way.)
> 
> To compile my code I'm using AdaCore's GNAT by running the command
> `gprbuild`. This means I also have a project file associated with the
> project, which in and of itself, is looking very basic. It only contains
> a means of locating the main procedure and executing it.
> 
> For my experimental implementation of automata, I have ended up with six
> different flavors of automata, which I have put in a separate directory,
> because the names tend to get extremely long:
> 
> expressions-parser-automata (the directory)
>     expressions-parser-automata-automaton_x.adb
>     expressions-parser-automata-automaton_x.ads
>  (...)
>     ...
> 
> This brings me to my question. Is there a better way to structure an Ada program than this?

Ada compilers do not require this choice of file names.
They offer ways of adding compilation units to the Ada library.
File names are not part of the program’s text, so the choice
is yours, and the possibilities are found in the documentation.
That’s the User’s Guide in the case of GNAT; it has a few sections 
specifically addressing file naming schemes.

With compilers using the AdaMagic front end you could
place all those _X packages in one file and add this to the
library. Gnatchop does something similar to that for GNAT.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Resolving Long Filenames for Packages
  2018-01-24 16:23 Resolving Long Filenames for Packages alexander
  2018-01-24 17:21 ` Robert Eachus
  2018-01-24 21:18 ` G. B.
@ 2018-01-25  9:50 ` alexander
  2018-01-25 14:13 ` Stephen Leake
  3 siblings, 0 replies; 5+ messages in thread
From: alexander @ 2018-01-25  9:50 UTC (permalink / raw)


Actually, in using the `gprbuild` command, should I happen to use filenames that does not mirror the package name, the compiler tells me that the "file for the specific package" wasn't found:

`main.adb:1:06: file "expressions-parser-automata-automaton_x.ads" not found`

This occurs, for instance, when the package Expressions.Parser.Automata.Automaton_X is located in a file named automaton_x.ads (as well as a file for the body: automaton_x.adb).

This is a default behavior as according to "http://docs.adacore.com/live/wave/gnat_ugn/html/gnat_ugn/gnat_ugn/the_gnat_compilation_model.html#file-naming-rules". On that page, they also discuss how one might use non-default file-names: "http://docs.adacore.com/live/wave/gnat_ugn/html/gnat_ugn/gnat_ugn/the_gnat_compilation_model.html#using-other-file-names", but using two pragmas per non-default filename seems a slight bit excessive for something that should be a simple task.

Should anyone have any idea as to how this should be handled with GNAT's `gprbuild` with a little more ease, that information would be highly appreciated!

Thank you, so far, Robert Eachus for recommendations on how the file naming might be done.

G. B. I do briefly remember not being required to use standard filenames during compilation with the `gnatmake` command for GNAT, but in switching to `gprbuild` and the `.gpr` project files to simplify the handling of projects, I'm still to find a means of naming files whatsoever I may want.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Resolving Long Filenames for Packages
  2018-01-24 16:23 Resolving Long Filenames for Packages alexander
                   ` (2 preceding siblings ...)
  2018-01-25  9:50 ` alexander
@ 2018-01-25 14:13 ` Stephen Leake
  3 siblings, 0 replies; 5+ messages in thread
From: Stephen Leake @ 2018-01-25 14:13 UTC (permalink / raw)


On Wednesday, January 24, 2018 at 10:23:20 AM UTC-6, alex...@junivörs.com wrote:
> expressions-parser-automata (the directory)
>     expressions-parser-automata-automaton_x.adb
>     expressions-parser-automata-automaton_x.ads
>     expressions-parser-automata-automaton_y.adb
>     expressions-parser-automata-automaton_y.ads
>     expressions-parser-automata-automaton_z.adb
>     expressions-parser-automata-automaton_z.ads
>     expressions-parser-automata-automaton_w.adb
>     expressions-parser-automata-automaton_w.ads
>     ...
> Once again, how would I generally go about structuring an Ada application to avoid such long filenames? Is there some sort of compiler option I can use? Can I do something about it inside my project (`gpr`) file?
> 
> Best regards,

The absolute name of each of these files is:
 /.../expressions-parser-automata-automaton/expressions-parser-automata-automaton_w.ads

There are two ways to make that shorter; shorten the file name part, or shorten the directory part.

As you point out in a later post, shortening the file name part while keeping the same package name requires one entry in the Naming config package per file, which is tedious and error prone.

You can also flatten the package hierarchy, but I'll assume you have a good reason for that hierarchy.

Shortening the directory part is easy; just put all the files in the parent directory.

You don't give a good rationale for using a subdirectory here; you say it is because the file names are "extremely long", but putting them in a subdirectory makes the names longer, so that makes no sense. 

One reason to use a subdirectory is to make it easier to select a different set of files for a particular project; do you have other projects that use the rest of this source code, but not the files in this directory?

It would be possible to modify gprbuild to support a second convention for file names, that maps the package hierarchy to the directory hierarchy as Java does. You'd have to put up money to convince AdaCore to implement that. 

You might be able use the gprname tool to automate generating the Naming package; that tool is documented in the gprbuild manual.

Personally, I much prefer a flatter directory hierarchy - that's one reason I prefer Ada over Java - certainly not the most important reason.

-- Stephe


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-01-25 14:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-24 16:23 Resolving Long Filenames for Packages alexander
2018-01-24 17:21 ` Robert Eachus
2018-01-24 21:18 ` G. B.
2018-01-25  9:50 ` alexander
2018-01-25 14:13 ` Stephen Leake

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox