Re: Standard Ada Preprocessor

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: Portability of course is an important issue. This becomes even more
: important to Open Sourced projects, since they must be easy to
: compile and maintain for all/most flavours of UNIX, and different
: Windows environments (native and/or CYGWIN etc.)

"native and/or CYGWIN" is a distinction that IMO amounts to saying
"not portable and/or portable", at least for your average C command
line tool or X11 program. How would you compile a Unix program
not using one of the Unix libraries/services provided with or for
Windows?

No preprocessor can help here, unless it magically provides
a mapping from a cooperating sequence of API calls found in the
Unix world to a cooperating sequence of APIs calls found
in the Windows world.

Or are you saying that Ada code shoud use #ifs all over the place,
neglecting language features?  IMHO, a program is portable if it
uses *abstraction*, for example a good separation a la MVC.
Abstraction is more easily expressed in a Ada than in CYGWIN's
perceived "standard" language, I think. A program is
not portable in this sense if it is a Unix command line tool and
happens to run on top of a Unix layer, or if it is an X11 program
and runs in the presence of an X server that has been ported to
Windows.

: Failing that, everyone must bake their own solution to this
: problem. Many maintain that by centralizing problem code into
: separate libraries works well enough. But this does not help
: in the cases where a product can be compiled with different
: options turned on or not (say from a Makefile).

How could #ifs or text substitutions make any difference?
If the maintenance has to happen in my head so to speak, that is
if I have to know which #if surround what specialisation, I'd
rather stay with my language and use what is provided for
expressing a difference in a type's components say. Example

struct _gna {
  int x;
  int y;
#if defined(__S1__)
  int z;
#else
  short z;
#endif
} *S;

I don't see the advantage, even if the distinction appears
"centralised" (?).

: In other cases,
: it may mean enhancements involve maintenance of several parallel
: modules, instead of one centralized location.

Why not use language means to check modules for compliance
with the common requirements?
"display help on topic_abc_123 in a dialogue window" could well be
mapped to an abstract operation.
 

-- Georg

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: Even if you have the same target hardware and two different compilers 
: (even from the same manufacturer sometimes!) you can have statements 
: that will compile on one but not on the other.

But then this is not an issue of program portability, but of
compiler differences or compiler bugs. To some extent Source Code Versioning
software and branches can help.

: Isolation with separate 
: bodies is sometimes difficult to do and always complicates the build 
: process. Some form of conditional compilation would make the job easier.

I'd prefer a conditional build process. IMHO, there should be a
declarative language for build processes, integrated with one
or more "source languages". ACE files (Eiffel), Project files (Ada),
VCS integration/awareness etc.
 
: Naturally that has risks and can lead to all sorts of abuse.

If you keep the #ifs out of the code, and instead declare the
target/compiler dependences in documents of their own right,
to be processed by a configuration preprocessor, that risk isn't
there, I think.


-- Georg

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:

: E:\Ada\Test>system_names
: system_names
:  The Available System Names are: SYSTEM_NAME_GNAT.
: 
:  Current System.System_Name is: SYSTEM_NAME_GNAT.
: 
: Is there any compiler that produces a useful output?

ObjectAda:
 The Available System Names are: S370, I80X86, I80386, MC680X0,
VAX, TRANSPUTER, RS_6000, MIPS, HP9000_PA_RISC, HP9000_300,
SPARC.

 Current System.System_Name is: I80386.

Re: Standard Ada Preprocessor

[Marin David Condic]

Better than Gnat, but still not terribly useful if you want to make code 
that will compile on both a Gnat and an Aonix platform.

MDC

Georg Bauhaus wrote:
> 
> ObjectAda:
>  The Available System Names are: S370, I80X86, I80386, MC680X0,
> VAX, TRANSPUTER, RS_6000, MIPS, HP9000_PA_RISC, HP9000_300,
> SPARC.
> 
>  Current System.System_Name is: I80386.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Dmitry A. Kazakov]

On Thu, 22 Jan 2004 13:19:08 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>Robert I. Eachus <rieachus@comcast.net> wrote:
>
>: E:\Ada\Test>system_names
>: system_names
>:  The Available System Names are: SYSTEM_NAME_GNAT.
>: 
>:  Current System.System_Name is: SYSTEM_NAME_GNAT.
>: 
>: Is there any compiler that produces a useful output?
>
>ObjectAda:
> The Available System Names are: S370, I80X86, I80386, MC680X0,
>VAX, TRANSPUTER,

Should that mean they have a compiler for Inmos T805? I am impressed!

> RS_6000, MIPS, HP9000_PA_RISC, HP9000_300, SPARC.
>
> Current System.System_Name is: I80386.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: Better than Gnat, but still not terribly useful if you want to make code 
: that will compile on both a Gnat and an Aonix platform.

What kind of difficulties do you see that could be better solved
by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
versa? Dependence on pragmata?)

I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p.
Ada source text is chopped where necessary using make.
(Operating) System specific routines are are assembled into a
package hierarchy (which I naively had top-level-named "System" (and
that triggers a bug box in GCC 34 after looping (the maintainers
say that, obviously, a library unit should not be modified...)))
Then a branch renames package Systems.Windows, another renames
package Systems.UNIX (or similarly).

The problem that leads GNAT 3.15p to reject another unit is
apparently a bug in GNAT 3.15p that has been fixed in GCC 34.
I like this better than having to construct sources around a
compiler bug/limitation using hopefully temporary preprocessor #ifs.


-- Georg

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Marin David Condic <nobody@noplace.com> wrote:
> : Better than Gnat, but still not terribly useful if you want to make code 
> : that will compile on both a Gnat and an Aonix platform.
> 
> What kind of difficulties do you see that could be better solved
> by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
> versa? Dependence on pragmata?)

MDC pointed out that you cannot conditionally do "with"
as one example. Implementation defined pragmas are
another area of difficulty. Optional features are
a pain to deal with since there is no way to feed
values into a compile process (using make),
without creating make "steps" that process the
source code before hand (ie. this becomes a manual
preprocessing step).

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: MDC pointed out that you cannot conditionally do "with"
: as one example.

Withing or not cannot be an option unless another possibly
related conditional requires a unit or not.
If there is no other conditional text, renaming an empty
package will do.

: Implementation defined pragmas are
: another area of difficulty. Optional features are
: a pain to deal with since there is no way to feed
: values into a compile process (using make),
: without creating make "steps" that process the
: source code before hand (ie. this becomes a manual
: preprocessing step).

So what is the greater pain?
To me, placing conditionals near the conditional sections is
tempting, but usually leads to #ifs all over the place.  It is
like writing tasking constructs without language support, or
like wrting your own dispatcher.  If we had a way to declare for
any of the 2**N compilations which conditions are to be met, and
which parts of the program text have to be in place for one of the
compilations, configuration could be done in a systematic manner,
with the help of a computer program that does configuration checking,
and with a readable statement (declarative in style) of the programs
dependences.


-- Georg

Re: Standard Ada Preprocessor

[Marin David Condic]

I agree that if you can isolate something down in a low-level "System 
Dependency" package and swap those out easily, that you have *an* answer 
to some (if not all) problems. I've done this thousands of times. I've 
described cases elsewhere in this thread that *must* be dealt with at 
compile time (either by having separate configuration dependent units 
and some kind of conditional build tools or by having conditional 
compilation.) I'll bet you've even encountered things like a given 
declaration that works fine on one compiler but doesn't work on another 
or a statement that is legal and compiles for one compiler but is 
illegal for another. There are all sorts of allowed compiler differences 
- without even bringing up the subject of trying to get around compiler 
bugs.

So if there's issues that have to be resolved at compile time and I 
can't guarantee that there is some external configuration management 
and/or build tools available to make maintaining separate units possible 
(if not always desirable) then I want some kind of conditional 
compilation to help me maintain a single body of code that works for 
more than one configuration.

MDC


Georg Bauhaus wrote:
> What kind of difficulties do you see that could be better solved
> by a preprocessor? (Things supported in GNAT but not ObjectAda or vice
> versa? Dependence on pragmata?)
> 
> I have code that is compiled by OA 722, by GCC 34, but not by GNAT 3.15p.
> Ada source text is chopped where necessary using make.
> (Operating) System specific routines are are assembled into a
> package hierarchy (which I naively had top-level-named "System" (and
> that triggers a bug box in GCC 34 after looping (the maintainers
> say that, obviously, a library unit should not be modified...)))
> Then a branch renames package Systems.Windows, another renames
> package Systems.UNIX (or similarly).
> 
> The problem that leads GNAT 3.15p to reject another unit is
> apparently a bug in GNAT 3.15p that has been fixed in GCC 34.
> I like this better than having to construct sources around a
> compiler bug/limitation using hopefully temporary preprocessor #ifs.
> 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
> : MDC pointed out that you cannot conditionally do "with"
> : as one example.
> 
> Withing or not cannot be an option unless another possibly
> related conditional requires a unit or not.
> If there is no other conditional text, renaming an empty
> package will do.

Perhaps I don't understand your point here, but if I
supply a parameter on the command line to the compiler
that says I am compiling with GNAT (or PDcurses or
whatever), then I can at compile time choose what
packages I am going to "need". I don't find any
reason to see prevent a conditional compile condition
here.

> : Implementation defined pragmas are
> : another area of difficulty. Optional features are
> : a pain to deal with since there is no way to feed
> : values into a compile process (using make),
> : without creating make "steps" that process the
> : source code before hand (ie. this becomes a manual
> : preprocessing step).
> 
> So what is the greater pain?
> To me, placing conditionals near the conditional sections is
> tempting, but usually leads to #ifs all over the place.  

If you have #ifs all over the place, it is because you
need them ;-)   Granted much of this abuse on the C/C++
side is related to how C/C++ works in the first place.
So drawing parallels to C should be done carefully.

There is still a strong need for conditional compilation.
Not for embedded work, since you have very specific
targets for that code. But if Ada is to support the
general purpose computing environment, and to support
portability, it must have better facilities for the
portability issues that come up.

 > It is
> like writing tasking constructs without language support, or
> like wrting your own dispatcher.  If we had a way to declare for
> any of the 2**N compilations which conditions are to be met, and
> which parts of the program text have to be in place for one of the
> compilations, configuration could be done in a systematic manner,
> with the help of a computer program that does configuration checking,
> and with a readable statement (declarative in style) of the programs
> dependences.

Tell me, how do you solve the situation where API call to your
OS requires 3 parameters on one platform, and 2 on another? No
if statement can solve that for you.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Marin David Condic]

Even in embedded work it is sometimes important. I might have code that 
relates to some breadboard version of the system that dummies up some 
stuff that exists differently on the "real" hardware. Or I might want to 
make a version of some of the code that operates on a workstation by 
faking out hardware that exists in the real unit. Or I might have 
multiple turns of a hardware board that each have peculiarities that 
need to be coded around. Or I might have multiple versions of an RTOS 
with variations on system calls that change from one version to the next.

I've encountered all of these in real-world situations and sometimes I 
might have dealt with them by having separate bodies (often really 
difficult to manage in practice) or I dealt with them via conditional 
compilation because I was using C. I just know it happens enough where 
conditional compilation would be a useful thing and not always a matter 
of abuse. If someone thinks it isn't really needed because it can be 
dealt with via some kind of CM or build process - I'd suggest they need 
to work in some of the environments I've been in where you either don't 
have the tools or there are all sorts of complications that make this 
really hard to do.

Conditional compilation isn't always pretty - but then neither are rep 
clauses or other things that are regularly done because that's the 
easiest way to get the job done.

MDC

Warren W. Gay VE3WWG wrote:
> 
> There is still a strong need for conditional compilation.
> Not for embedded work, since you have very specific
> targets for that code. But if Ada is to support the
> general purpose computing environment, and to support
> portability, it must have better facilities for the
> portability issues that come up.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:4011CF46.3040001@noplace.com...
...
> I've encountered all of these in real-world situations and sometimes I
> might have dealt with them by having separate bodies (often really
> difficult to manage in practice) or I dealt with them via conditional
> compilation because I was using C. I just know it happens enough where
> conditional compilation would be a useful thing and not always a matter
> of abuse. If someone thinks it isn't really needed because it can be
> dealt with via some kind of CM or build process - I'd suggest they need
> to work in some of the environments I've been in where you either don't
> have the tools or there are all sorts of complications that make this
> really hard to do.

You want to change the language because you've had to work in poorly managed
shops with insufficient tools? Sure, we all do what we have to do to get the
job done, but that hardly justifies a major language change (and one where
no obvious workable solution springs to mind).

> Conditional compilation isn't always pretty - but then neither are rep
> clauses or other things that are regularly done because that's the
> easiest way to get the job done.

I think you're comparing apples to oranges. Rep clauses are an elegant way
of getting the job done; the only alternative is bit mask operations and
those are a lot harder to understand. And they certainly aren't about just
interfacing to hardware - I use them a lot to reduce storage use without
making critical parts too slow. So I guess I'd say that rep. clauses ARE
pretty. You'd be better off picking on Access_to_Address_Conversions or
something like that -- except that no one much uses any of those packages.
Perhaps because they are ugly.

I'm not personally against conditional compilation, I just don't see any way
to integrate a useful form of it into the language. (I don't think it is
necessary in an ideal world, but the world is hardly ideal - people write
gibberish in C and Java after all.) The form that Janus/Ada has (and we no
longer use in new code because it isn't flexible enough) is a pure binary
in-or-out scheme intended solely for marking debugging code. ('@' is either
compiled as a comment "--" or as a space ' ' depending on the command line
options.) Pragmas have a number of problems: they can't be used in some
parts of the code (for example, formal_parts and discriminant_parts); such a
pragma would violate "good taste in pragmas" as laid out in 2.8; and enough
people think that they're ugly to prevent them from being used this way.
(GNAT's pragma Debug was considered and discarded for this reason.) Some
sort of syntax would be needed, and that seems like it would be pretty
heavy. (And I have no idea what it ought to look like.)

If you want to propose something, feel free, but remember that the ARG is
not taking new topics anymore, so unless you can find a way to coordinate it
with an existing AI, it will have to wait for Ada 1Z.

                      Randy.


All-in-all, it seems like there

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> Tell me, how do you solve the situation where API call to your
> OS requires 3 parameters on one platform, and 2 on another? No
> if statement can solve that for you.

Of course it can, see above.  I sometimes feel dirty having two Ada 
templates bound (by the linker) to the same C function, and depending on 
configuration constants to insure that I make call with the correct 
parameters for this environment.  But I do it.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Marin David Condic]

Rep clauses are ugly in the sense that "In A Perfect World" we'd want to 
let the compiler worry about how to represent data. Inherently, they 
make the code compiler and target dependent. By their very existence, 
you can't just hand someone some body of code and say "Trust me. It will 
compile & run on your machine..." Rep clauses are actually one of the 
better arguments for needing conditional compilation. (Target A? Use 
this rep! Target B? Use that one!)

Oh sure. They are better than a sharp stick in the eye and if you have 
to  control representation, they're an elegant solution. But they are 
still "Butt Ugly" in the sense that the instant you use one, you can't 
promise that the code will work *anywhere* except on the one 
compiler/target where you built it.

As for submitting something to the ARG? I'll leave that to the language 
lawyers. They'll come up with far better proposals than I could ever 
write - so long as they think the idea might be a good one. I'm just the 
end-user of Ada - a customer - expressing what he thinks would make the 
language more usable on a day-to-day level. We're a dwindling herd, so 
maybe those opinions ought to get some attention by the people who make 
and sell Ada. Hope springs eternal! :-)

MDC

Randy Brukardt wrote:
> 
> I think you're comparing apples to oranges. Rep clauses are an elegant way
> of getting the job done; the only alternative is bit mask operations and
> those are a lot harder to understand. And they certainly aren't about just
> interfacing to hardware - I use them a lot to reduce storage use without
> making critical parts too slow. So I guess I'd say that rep. clauses ARE
> pretty. You'd be better off picking on Access_to_Address_Conversions or
> something like that -- except that no one much uses any of those packages.
> Perhaps because they are ugly.



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Marin David Condic wrote:

> Rep clauses are ugly in the sense that "In A Perfect World" we'd want to 
> let the compiler worry about how to represent data. Inherently, they 
> make the code compiler and target dependent. By their very existence, 
> you can't just hand someone some body of code and say "Trust me. It will 
> compile & run on your machine..." Rep clauses are actually one of the 
> better arguments for needing conditional compilation. (Target A? Use 
> this rep! Target B? Use that one!)

Somebody wrote an article (for Ada Letters I think) on how to write 
representation specifications that are legal (and identical!) for 
bigendian and little endian hardware.  Anyone remember it?  I tend now 
to target only x86 family machines, where MMX, 3dNow!, SSE, and SSE2 
give me enough headaches. ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Marin David Condic]

Possible. But endianness is *not* the only reason for the existence of 
rep clauses. So while you *might* write portable endianness code, you 
can't figure that's the answer to everything. Somewhere a rep clause is 
going to work for one target and you'll need a different rep clause for 
a different target. Until all compilers and environments are exactly 
alike, you'll have some kind of problem like this.

MDC

Robert I. Eachus wrote:
> 
> Somebody wrote an article (for Ada Letters I think) on how to write 
> representation specifications that are legal (and identical!) for 
> bigendian and little endian hardware.  Anyone remember it?  I tend now 
> to target only x86 family machines, where MMX, 3dNow!, SSE, and SSE2 
> give me enough headaches. ;-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[tmoran]

>Rep clauses are ugly in the sense that "In A Perfect World" we'd want to
>let the compiler worry about how to represent data. Inherently, they
>make the code compiler and target dependent. By their very existence,
>you can't just hand someone some body of code and say "Trust me. It will
  I don't understand what you use rep clauses for.  I normally use them
when a data structure must be shared outside my program, by a hardware
device, an OS call, another program, etc.  For those, the rep clause does
not change when you change compiler or target machine - unless your target
*requires* a change because it demands a different representation.  Not
even a perfect compiler could do that automatically.

Re: Standard Ada Preprocessor

[Marin David Condic]

A simple case: Suppose you are developing for an embedded box but you 
want to do some simple "Smoke Testing" on a PC. For the embedded box, 
you need a rep clause for some register. For the PC you're dummying that 
up with something and don't want a rep clause at all. (Or the PC 
compiler barfs on the rep clause that the embedded compiler accepts.) It 
would be nice to say "If compiling for the PC with Aonix, use this code 
(no rep), but if compiling for the target with the Gnat compiler, go use 
that code..."

I've also run into situations where the hardware weenies are working as 
fast as we software bozos are and every few weeks, you're getting new 
turns of a board with different hardware in it. You still need to 
compile for earlier boards but now you have something different - 
probably with a different rep clause. I don't want to go into some 
complex CM and build process just for the developmental stuff - I just 
need a quick and dirty answer to being able to get the code to work on 
two (or more) boxes short-term.

That's why I'm saying that conditional compilation may be ugly and 
intellectually unsatisfying and not "The Perfect World" but often you've 
got circumstances that make it the best, expedient choice for fixing a 
real world situation. And yes, I agree it can be abused. Maybe there is 
some way of making it simple enough to get a job done but not powerful 
enough to make an atrocity.

But its been observed that there never has been a programming language 
in which it has been the least bit hard to write bad code. Maybe we can 
just accept that and live with it.

MDC


tmoran@acm.org wrote:
> 
>   I don't understand what you use rep clauses for.  I normally use them
> when a data structure must be shared outside my program, by a hardware
> device, an OS call, another program, etc.  For those, the rep clause does
> not change when you change compiler or target machine - unless your target
> *requires* a change because it demands a different representation.  Not
> even a perfect compiler could do that automatically.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Marin David Condic" <nobody@noplace.com> wrote in message
news:401272E3.4040506@noplace.com...
...
> Oh sure. They are better than a sharp stick in the eye and if you have
> to  control representation, they're an elegant solution. But they are
> still "Butt Ugly" in the sense that the instant you use one, you can't
> promise that the code will work *anywhere* except on the one
> compiler/target where you built it.

There is hardly any (useful) code that will work *anywhere*. Most existing
free Ada code won't run on Janus/Ada out of the box because Integer is
16-bit -- and thus a lot of operations overflow. (Of course, there's no
problem with proper type declarations, but those are rare.) And a lot of
code is dependent in some way on the target - for GUI or output devices or
whatever. Certainly adding a rep. clause has little effect on that.
Especially if your world view pretty much starts and ends with PC hardware
(as mine does practically).

We build Claw from the ground up with the intent of making it portable to
every Windows compiler -- yet there a quite a few differences that we have
to deal with. So rep. clauses don't bother me; it is extremely rare that
they would make code less portable than it already is.

> As for submitting something to the ARG? I'll leave that to the language
> lawyers. They'll come up with far better proposals than I could ever
> write - so long as they think the idea might be a good one.

The language lawyers are unlikely to even pay any attention to it unless you
submit a worked out change request. We have enough such requests that we
certainly aren't looking for more!

I view this is list pretty much as what Robert Dewar called a "chat list" -
a place where people gripe a lot, turn molehills into mountains (and vice
versa), and you can't gauge much of anything by the conversations here. I
read this list mainly as part of my work for one of my other hats (webmaster
at adaic.org) -- I'm trolling for newsworthy items. There have been
occassional ideas where I got excited enough to propose something to the ARG
("private with" is the one that comes to mind), but these days I feel
swamped enough that it would have to be a stupendous idea before I'd make
more work for myself.

So, if you want something done, you need to take action to make a proposal
on Ada-Comment. It certainly doesn't need to be perfect - and even if it is,
the ARG would change it all around before standardizing it - but if no one
asks, it's very unlikely that the topic would even come up. Griping here may
feel good, but it has virtually no impact on the future of Ada.

                          Randy.



 I'm just the
> end-user of Ada - a customer - expressing what he thinks would make the
> language more usable on a day-to-day level. We're a dwindling herd, so
> maybe those opinions ought to get some attention by the people who make
> and sell Ada. Hope springs eternal! :-)

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Marin David Condic wrote:

> A simple case: Suppose you are developing for an embedded box but you 
> want to do some simple "Smoke Testing" on a PC. For the embedded box, 
> you need a rep clause for some register. For the PC you're dummying that 
> up with something and don't want a rep clause at all. (Or the PC 
> compiler barfs on the rep clause that the embedded compiler accepts.) It 
> would be nice to say "If compiling for the PC with Aonix, use this code 
> (no rep), but if compiling for the target with the Gnat compiler, go use 
> that code..."

You are familar with RM 13.1(22) right?  "An implementation need not 
support representation items containing nonstatic expressions, except 
that an implementation should support a representation item for a given 
entity if each nonstatic expression in the representation item is a name 
that statically denotes a constant declared before the entity."

I know it is Implemenation Advice, but especially for Address 
representation specifications it is almost required of any decent 
compiler that they support at least this.  If you don't understand how 
to read it look at the "Rosen trick":

function Random(Gen: Generator) return Float is
    Local: Generator;
    for Local'Address use Gen'Address;
begin
    ....
end Random;

The value of Gen'Address is definitely non-static.  But it is easy for a 
compiler to "get it right" in this case because the value of 
Local'Address each time the declaration of Local is elaborated.

What has this got to do with Marin's complaint?  He thinks that invalid 
representation clauses must be illegal.  If they are non-static they 
can't be illegal because the value to be set at run-time is wrong. 
Either the compiler will raise Program_Error at run-time or execution of 
the invalid representation clause will make the program erroneous.  See 
for example RM 13.3(13): "If an Address is specified, it is the 
programmer's responsibility to ensure that the address is valid; 
otherwise, program execution is erroneous."

Since the address in the representation clause need not be static, your 
program can set it at run-time depending on the hardware involved.  You 
mean you have never done that?  I have code with address clauses that 
depend on system calls made at run-time.

So loosen up a little Marin, and try writing non-static representation 
clauses.  Remember 13.1(22) that I referenced above, and that 'Size for 
objects (but not subtypes) must be static, RM 13.3(41). But you should 
be able to do a lot more with Rep clauses than you have done so far. ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3241 bytes --]

What's the URL for Ada-comment?

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:10160jcm6ma1acf@corp.supernews.com...
> "Marin David Condic" <nobody@noplace.com> wrote in message
> news:401272E3.4040506@noplace.com...
> ...
> > Oh sure. They are better than a sharp stick in the eye and if you have
> > to  control representation, they're an elegant solution. But they are
> > still "Butt Ugly" in the sense that the instant you use one, you can't
> > promise that the code will work *anywhere* except on the one
> > compiler/target where you built it.
>
> There is hardly any (useful) code that will work *anywhere*. Most existing
> free Ada code won't run on Janus/Ada out of the box because Integer is
> 16-bit -- and thus a lot of operations overflow. (Of course, there's no
> problem with proper type declarations, but those are rare.) And a lot of
> code is dependent in some way on the target - for GUI or output devices or
> whatever. Certainly adding a rep. clause has little effect on that.
> Especially if your world view pretty much starts and ends with PC hardware
> (as mine does practically).
>
> We build Claw from the ground up with the intent of making it portable to
> every Windows compiler -- yet there a quite a few differences that we have
> to deal with. So rep. clauses don't bother me; it is extremely rare that
> they would make code less portable than it already is.
>
> > As for submitting something to the ARG? I'll leave that to the language
> > lawyers. They'll come up with far better proposals than I could ever
> > write - so long as they think the idea might be a good one.
>
> The language lawyers are unlikely to even pay any attention to it unless
you
> submit a worked out change request. We have enough such requests that we
> certainly aren't looking for more!
>
> I view this is list pretty much as what Robert Dewar called a "chat
list" -
> a place where people gripe a lot, turn molehills into mountains (and vice
> versa), and you can't gauge much of anything by the conversations here. I
> read this list mainly as part of my work for one of my other hats
(webmaster
> at adaic.org) -- I'm trolling for newsworthy items. There have been
> occassional ideas where I got excited enough to propose something to the
ARG
> ("private with" is the one that comes to mind), but these days I feel
> swamped enough that it would have to be a stupendous idea before I'd make
> more work for myself.
>
> So, if you want something done, you need to take action to make a proposal
> on Ada-Comment. It certainly doesn't need to be perfect - and even if it
is,
> the ARG would change it all around before standardizing it - but if no one
> asks, it's very unlikely that the topic would even come up. Griping here
may
> feel good, but it has virtually no impact on the future of Ada.
>
>                           Randy.
>
>
>
>  I'm just the
> > end-user of Ada - a customer - expressing what he thinks would make the
> > language more usable on a day-to-day level. We're a dwindling herd, so
> > maybe those opinions ought to get some attention by the people who make
> > and sell Ada. Hope springs eternal! :-)
>
>
>

Re: Standard Ada Preprocessor

[Marin David Condic]

I'm not talking about addresses. Have you never seen a rep clause on a 
record, for example, that a given compiler will refuse to accept even if 
it is syntactically legal? I don't happen to have one sitting in my back 
pocket at the moment, but I *know* I've coded up valid rep clauses on 
records that compilers have spit out and refused to accept. Technically, 
it is legal for an implementation to refuse just about any rep clause it 
doesn't want to be bothered with - so perhaps you've got it coded up one 
way for one compiler and another way for another compiler.

Perhaps there's some arcane trick that can be pulled to change rep 
clauses on a record on the fly, but I've not seen it (and it sure starts 
sounding *far* more complex than decrypting a simple conditional 
compilation directive - maybe this is what frustrates me about the 
opposition to a conditional compile: Everyone holds out some cumbersome, 
complex, arcane trickery that is orders of magnitude more difficult to 
understand and utilize properly as an answer in order to avoid something 
that is capable of being pretty simple & basic.). What I *have* seen is 
rep clauses that a compiler refuses to accept - and hence I can't even 
*get* to runtime because I've got compile errors. Legal or not - Moral 
or not - I still have to get a job done and a conditonal compilation 
directive of some sort would fix the problem.

MDC

Robert I. Eachus wrote:
> 
> You are familar with RM 13.1(22) right?  "An implementation need not 
> support representation items containing nonstatic expressions, except 
> that an implementation should support a representation item for a given 
> entity if each nonstatic expression in the representation item is a name 
> that statically denotes a constant declared before the entity."
> 
> I know it is Implemenation Advice, but especially for Address 
> representation specifications it is almost required of any decent 
> compiler that they support at least this.  If you don't understand how 
> to read it look at the "Rosen trick":
> 
> function Random(Gen: Generator) return Float is
>    Local: Generator;
>    for Local'Address use Gen'Address;
> begin
>    ....
> end Random;
> 
> The value of Gen'Address is definitely non-static.  But it is easy for a 
> compiler to "get it right" in this case because the value of 
> Local'Address each time the declaration of Local is elaborated.
> 
> What has this got to do with Marin's complaint?  He thinks that invalid 
> representation clauses must be illegal.  If they are non-static they 
> can't be illegal because the value to be set at run-time is wrong. 
> Either the compiler will raise Program_Error at run-time or execution of 
> the invalid representation clause will make the program erroneous.  See 
> for example RM 13.3(13): "If an Address is specified, it is the 
> programmer's responsibility to ensure that the address is valid; 
> otherwise, program execution is erroneous."
> 
> Since the address in the representation clause need not be static, your 
> program can set it at run-time depending on the hardware involved.  You 
> mean you have never done that?  I have code with address clauses that 
> depend on system calls made at run-time.
> 
> So loosen up a little Marin, and try writing non-static representation 
> clauses.  Remember 13.1(22) that I referenced above, and that 'Size for 
> objects (but not subtypes) must be static, RM 13.3(41). But you should 
> be able to do a lot more with Rep clauses than you have done so far. ;-)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Peter Richtmyer]

I have not read the entire thread. Bottom lines for me:
    1) too bad Ada does not have a preprocessor
    2) I needed one, so I created one

It has served me well for 4 years on Win2000, Solaris, HP/UX,
and LynxOS. Not elegant but very useful to me, to take code
home at night, develop/test on Win2000, then back to work with the
same source code (preparsed) to continue to develop/test on Solaris 
(or other). 

I have included some files:

   PreProcess.pm    -- the preprocessor
   PreCheck.pm      -- checks for conditionals
   and some sample DOS batch files

Use if you like, ignore otherwise           :-)
I hope it will help someone out there.

Peter

======================== PreProcess.pm ==========================
#!/usr/bin/perl -s

package Devel::PreProcess;
#IO:   use IO::File;
#use vars qw( $Conditionals $StripPreserve $StripDelete );
#use vars qw( $CMNT $CNDT $GenAda $fh $fhout $to_file $line_number );

$RETURN_CODE = 0;    # code returned to system or caller
#              0  -  OK  
#             -1  -  Command Line option error.
#             -2  -  Could not open the input file or none specified.
#             -3  -  Could not open the output file or none specified.

goto PAST_HELP;  #### We put 'HELP' up here so you can see it easily. 
:-)

PRINT_HELP:
   print <<"END_HELP";

                            Devel::PreProcess
                            v  1.7   01/25/04
            Generate conditional compile code for source code   

From a command line,

    sh> perl -s Devel/PreProcess.pm -Flags sourcefile > targetfile
  or
    sh> perl -s Devel/PreProcess.pm -Flags sourcefile  [targetfile]
    
Or in a Perl script,

    use Devel::PreProcess qw( Flags );
    Devel::PreProcess::parse_file( $sourcefile [, $targetfile]  );

DESCRIPTION

This package processes source files and outputs a modified version
according to several user-setable option flags, as detailed below.

Each of the flag names listed below can be used as above, with a
hyphen on
the command line, or as one of the arguments in an import statement.
Each
of these flags are mapped to the scalar package variable of the same
name.

Option -Conditionals 

  (True is the default)
  (Use Noconditionals to turn it off)

  If true, parse_file will utilize a simple conditional inclusion
scheme, as follows.

    --#__COND__ if expr1
    ...     
    --#__COND__ elsif expr2
    ...
    --#__COND__ else
    ...
    --#__COND__ endif

  The "elsif" line is optional, and there may be more than one such
line.
  The "else" line is optional.

  The provided Perl expression (expr1) is evaluated, and unless it is
true,
  everything up to the next conditional declaration is made into
special comment
  lines ("--#"). If "false" then sucessive elsif conditionals, if
preset, are
  evaluated as in any "if ... elsif  ... else ... endif" logic. 
 
  In addition, a single line may be conditional'd using the following
format:

   --#{expr3} source code first line here;
   some more source code on second line; --#{expr4}

  When these expressions (expr3 and expr4) are evaluated, when True
then the line
  will be output in the format of the second line above so that the
Ada code is
  active. When an expression is False, then the output will be in the
format of
  the second above. 

  For example, lines below were preprocessed with "-demo" on command
line:
     -- TESTING: this is demo line   --#{$demo}
     --#{!$demo}    -- TESTING: not a demo line  

  WARNING: This does not work correctly in some environments unless
there are
  spaces after the "}" and/or before the "--#" when at the end of a
line.

  The conditional functionality can be combined with Perl's -s switch,
  which allows you to set flags on the command line, such as:

    perl -s Devel/PreProcess.pm  -Switch filter.test

  You can use any name for your switch, and the matching scalar
variable
  will be set true; the following code will only be used if you supply
  the argument as shown below.

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  If the Switch variable (entered on the command line as in the
example above)
  is true then the output file will contain:

    --#__COND__ if $Switch
       put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  Thus, the two Ada lines of code will be compiled.
  If the Switch variable is false then the output file will contain:

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
    --#      put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  Since the "if" and "elsif" conditions are Perl conditionals, they
can
  be compound conditionals. Use "&&" for AND, "||" for OR, etc. And
use
  the "!" for NOT. For example:

    --#__COND__ if ($green && ! ($apple || $pear))

  In addition, the "if ... endif" blocks can be nested.

  In reality, it is legal to have white-space between the "--#" and
the "__COND__"
  portions of a conditional statement.

  It should be noted that one of the strengths of this preprocessor is
that the
  output from one "run" can be used as the input to the next run. For
example, if
  code is being developed on two different computing environments
(e.g. home and
  work), then the code can be generated using a "-home" switch. The
code would be
  developed and tested some at home, with changes made. Then the code
would be
  run through with the "-work" switch set, and development and test
would continue
  on the same source code at work.  


Option -StripPreserve

  This option will cause all lines beginning with the Conditional
Comment prefix
  ("--#"  or its replacement using option "CMNT" described below) on
the output
  side of the logic to be replaced with a blank line in the output
stream.

Option -StripDelete

  This option will cause all lines beginning with the Conditional
Comment prefix
  ("--#"  or its replacement) on the output side of the logic to be
deleted, that
  is, not written to the output stream.

Option -CMNT="comment-string"

  This option will replace the Conditional Comment string "--#" with
the
  "comment-string" provided. Thus  -CMNT="--$$$" would specify an
alternative for
  conditional comment string for Ada, while  -CMNT="#*#*" could be
used to
  specify a conditional comment string when preparsing Perl source
code.

Option -CNDT="conditional-string"

  This option will replace the Conditional string "__COND__" with the 
  "conditional-string" provided. This is the string that comes after
the CMNT
  string to specify a line with "if", "elsif", "else" and "endif"
statements.

Option -LEFT="left-side"

  This option will replace the "{" as the string on the left side of a
single-line
  conditional with "left-side"

Option -RIGHT="right-side"

  This option will replace the "}" as the string on the right side of
a single-line
  conditional with "right-side"

  So, if entered " -LEFT="{{"  -RIGHT="}}" then the single-line
conditionals
  would be similar to:  --#{{expr5}}

  Care must be taken, certain special charaters need to be "escaped".
For example,
  a left paren by itself will not work (you will get a program error).
 So:
        -LEFT="("  will not work,  use  -LEFT="\("

BUGS AND CAVEATS

Option Flags -CMNT and -CNDT msy not work when calling from another
Perl script. (Workaround: just make a separate copy of the pgm that
has
the desired defaults.)

END_HELP
    exit ($RETURN_CODE);
################3############## Change History
#################################

# ver    date                           description
# ---  --------  ---------------------------------------------------------------
# 1.7  01/25/04  Editorial changes only
# 1.6  07/10/03  Minor pattern-matching change
# 1.5  03/26/01  If the output is a directory, then use the same
filename
#                as the input, for writing to the output directory.
# 1.4b 11/07/00  Some clean-up, comments, deleted code, ... 
# 1.4a  9/26/00  Corrected "help"
# 1.4  09/25/00  Had to make changes to work with perl5 on HP.
# 1.3a  9/25/00  Documentation update only. No CODE changes.
# 1.3  03/06/00  Adding the single-line conditional.     --#{$test}
# 1.2  02/28/00  Clean up.
#
# 1.1 02/27/00  Commenting out the "IO::File" logic with #IO:  prefix
and
#               replacing it with old-style I/O so I can run for now
on systems
#               that do not have the IO package.
#
# 1.0 02/26/00  Original
PAST_HELP:
#
# Change the variables below to change the "syntax" of the
conditionals:
#
$CMNT         = "--#";
$CNDT         = "__COND__";
$LEFT         = "{";
$RIGHT        = "}";
#
$Conditionals = 1;   

# @psuedo_INC - directories to search for modules
#use vars qw( @psuedo_INC );

# really constants below - is there better way of making constants in
Perl 5?
#use vars qw( $EOF $ELSIF $ELSE $ENDIF );
     $EOF    = 1;
     $ELSIF  = 2;
     $ELSE   = 3;
     $ENDIF  = 4;

# %Importers - maps file inclusion keywords to their import methods
#use vars qw( %Importers );
#%Importers = (
#  'require' => '',
#  'use' => 'import',
#  'no' => 'unimport',
#);

# Devel::PreProcessor->import( 'StripPreserve', 'Conditionals', ... );
sub import {

  my $package = shift;
  foreach ( @_ ) {
    if ( m/Conditionals/i )        {
      $Conditionals = 1;
    } elsif ( m/Noconditionals/i ) {   ### PMR not tested yet
      $Conditionals = 0;               ### PMR not tested yet
    } elsif ( m/h/i )  {
      goto PRINT_HELP;
    } elsif ( m/help/i )  {
      goto PRINT_HELP;
    } elsif ( m/StripPreserve/i )  {
      $StripPreserve = 1;
    } elsif ( m/StripDelete/i )    {
      $StripDelete = 1;
    } elsif ( m/LibPath:(.*)/i )   {
      @INC = split(/\:/, $1);
    } elsif ( m/CMNT=(.*)/)        {   ### PMR not tested yet
      $CMNT = $1;                      ### PMR not tested yet
    } elsif ( m/CNDT=(.*)/)        {   ### PMR not tested yet
      $CNDT = $1;                      ### PMR not tested yet
    } elsif ( m/RIGHT=(.*)/)       {
      $RIGHT = $1;    
    } elsif ( m/LEFT=(.*)/)        {
      $LEFT = $1;       
    } else                         {
      die "unkown import";
    }
  }
}

# If we're being run from the command line, look for certain options 
# on the command line after program name.
unless ( caller ) {

  goto PRINT_HELP                          if ( $main::help ||
$main::h ) ;
  goto PRINT_HELP                          if ( $main::Help ||
$main::H ) ;
  $Conditionals    = 0                     if ( $main::Noconditionals
);
  $Conditionals  ||= $main::Conditionals;
  $StripPreserve ||= $main::StripPreserve;
  $StripDelete   ||= $main::StripDelete;
  $CMNT            = $main::CMNT           if ($main::CMNT);
  $CNDT            = $main::CNDT           if ($main::CNDT);
  $LEFT            = $main::LEFT           if ($main::LEFT);
  $RIGHT           = $main::RIGHT          if ($main::RIGHT);
  my $in_source    = shift @ARGV;       # input filename
  my $out_source   = shift @ARGV;       # output filename

  parse_file ( $in_source,  $out_source  );
} 
# ------------------------------ parse_file
------------------------------------
#
# Calling:   parse_file ( $infilename [,  $outfilename] );
#
# This routine is called by the mainline above. But it can also be
called
# by an external program.
#
sub parse_file {
    #
    # before doing much, let's make sure that any overrides to
conditional
    # matching variables are legal.
    #
## NEED to get this to work, and one for the {$test}

    if ( eval ("$line =~ /$CMNT\s*$CNDT/") )  {
        print "ERROR: You entered an illegal string for CMNT or CNDT
\n";
        print "       CMNT='$CMNT', CNDT='$CNDT' \n";
        print "       Use a backslash '\\' before certain special
characters. \n";
        die   "Try Again";
    }

    my $infilename  = shift;                       # the file to
preparse
    #IO:  $fh     = IO::File->new($infilename);          # global
inputfile handle
    open ( INPUT, $infilename )  ||  die "Unable to open input file
$infilename";
            
    my $outfilename = shift;                       # the file to write
to
    if ($outfilename) {                            # if output file
specified
        # -----------------------------------------------------------
        # if the output filename is a directory, just use it and 
        # the input filename for the complete output name.
        # -----------------------------------------------------------
        if (-d $outfilename) {
        
          @inparts = split(/[\\\/]/, $infilename);   # split into
parts separated by "\" or "/"
          $fname = $inparts[$#inparts];              # the last part
is the input file name
          $outfilename .= "/$fname"; 
        }
        
        #IO:   $fhout  = IO::File->new("> $outfilename"); #     open
output file
        open ( OUTPUT, "> $outfilename" )  ||  die  "Unable to open
output file $outfilename" ;
        $to_file = 1;                              #     "writing to
file"
    } else {                                       # else
        $to_file = 0;                              #     "writing to
stdout"
    }
    
    
    my $top_eof = parse_block ( 1, 1 );      # parse entire file 
    die "Program terminating before End-of-File - too many endif's ? "
 if ($top_eof != $EOF);
}
# ------------------------------ parse_block
-------------------------------------
#
#  $rtn = parse_block ( $level, $GenAda );
#
# Parses a "block" of code. If "$level" = 1, then this "block" is the
entire file.
# Since we always want to generate Ada for the file-level, $GenAda = 1
for level = 1.
# While parsing lines in a block, if we find a "conditional if", then
that is
# the start of an embedded block, and this routine is called
recursively to parse
# that block. 
#
# $rtn - these are the values that can be passed back from
parse_block, and they
#        tell you why we returned from the routine. If not "EOF", then
$_ has the
#        line of source code with the Conditional Commented statement,
and it has
#        not been printed yet.
#           $EOF    = 1;
#           $ELSIF  = 2;
#           $ELSE   = 3;
#           $ENDIF  = 4;
#
sub parse_block {

    my $level  = shift;   # What level of recursion (1 = outermost)
    my $GenAda = shift;   # Whether it is OK to generate Ada
                          #   out of cond-commented code

    LINE: 
    while( 1 ) {
      # 
      # Get a new line of code. If we hit eof, then return EOF.
      #
      #IO:  return ($EOF) if (! defined ($_ = $fh->getline) ); 
      return ($EOF) if (! ($_ = <INPUT>) );       
   
      $line_number ++;
      #
      # if this is a COND "endif", "elsif", or "else" then
      #    return to previous block with the code for this line
      #
      return ($ENDIF) if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*endif/i );  
      return ($ELSIF) if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*elsif\s+/i );  
      return ($ELSE)  if ( $_ =~ /^\s*$CMNT\s*$CNDT\s*else\s+/i );
      #
      # If this line is a special conditional "if"
      #     evaluate the conditional that is on the 'if'
      #     write it if writeing cond comments
      #     call this routine recursively with level nbr and
conditional results
      #
      if ( $Conditionals && /^\s*$CMNT\s*$CNDT\s?(.*)$/i ) {
          my $conditional = $1;
          if ( $conditional =~ s/^if //i ) {

              write_if ("$_");               # write cond "if" line
"as-is" (unless stripping)
              my $This_GenAda = eval "package main;\n$conditional";
              my $We_Had_GenAda = 0;
              #
              # Why $We_Had_GenAda ?
              # If this "if block" turns out ot be a complex block
such as "if-elsif-else"
              # Then we need to keep track of whether or not we have
had one "true"
              # sub-block within it. After one true sub-block, all
others must be false.
              # Once we have had that "true" sub-block, $We_Had_GenAda
will = true.
              #
              SUB_BLOCK:
              while ( 1 ) {
                 my $eob = parse_block ( ($level + 1), ($This_GenAda
&& $GenAda && (not $We_Had_GenAda ))  );
                 $We_Had_GenAda  = ($This_GenAda && $GenAda) || 
$We_Had_GenAda;
                 die "End-of-File reached while in a Conditional
Compile block" if ($eof);
                 write_if ("$_"); # write line that ended block /
sub-block
                 
                 next LINE       if ($eob == $ENDIF);  # done with
entire block

                 if ($eob == $ELSE) {
                     $This_GenAda = ! $We_Had_GenAda;    # set up this
block GenAda
                     #$This_GenAda = not $We_Had_GenAda;    # set up
this block GenAda
                     next SUB_BLOCK;                       # parse the
"else" subblock
                 }
                 die "Program error - bad EOB" if ($eob != $ELSIF);
                 
                 # Parse the "condition" part out of line and evaluate
it true / false
                 /^\s*$CMNT\s*$CNDT\s?elsif(.*)$/i;
                 $conditional = "$1";
                 $This_GenAda = eval "package main;\n$conditional";
                 # will loop back to SUB_BLOCK and parse this "elsif"
sub-block.
              }      
          } else {
              print "$_";
              die "conditional above is out of place";
          }
      }  
      # look for a single line conditional.
      local ($SCOND) = "";
      local ($SLINE) = "";
 
      if ( /^(\s*$CMNT\s*$LEFT.*$RIGHT)(.*)$/ ) {
         #print "TEMP found $1 in --#\${LEFT}xxxx\$RIGHT} line and $2
after it\n";
         $SCOND = $1;
         $SLINE = $2;
      }
      if ( /^(.*)($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) {
         #print "TEMP found '$1' before '$2' \n"; 
         $SCOND = $2;
         chomp($SCOND);
         $SLINE = $1;
      }
      if (  $SCOND  )  {
          $SCOND =~ /$CMNT\s*$LEFT(.*)$RIGHT/;
          if ( eval "package main;\n$1" )  {
              &write_if ("$SLINE $SCOND\n");          
          } else {
              &write_if ("$SCOND $SLINE\n");
          }
          next LINE;
      }
      #
      # If we are in the outer level (not within a COND block), then
we do not even
      # have to look at the line of code. Just write it (if..)
      #
      if ($level == 1) {
          #
          # We could make a check here for a "--$COMM" line. That
would be a straggler,
          # outside of a conditional, so we could alert the officials
about it.
          # 
          write_if ("$_");    # local routine to write if OK to write
          next LINE;
      }
      #
      # $GenAda can only be true if we are processing conditionals and
we found
      # a conditional that evaluated True.
      #
      ##print "                            \$GenAda = $GenAda \n";
      if ($GenAda)   {
          #          
          # This line must NOT be a COND comment. If it is now, 
          # then remove the COND part.
          #
          if ( /^\s*$CMNT(.*)$/i ) {
              write_if ("$1\n");
          } else {
              write_if ("$_");
          }                 
          next LINE;
      } 
      #
      # If we are processing conditionals and this line should be
commented out,
      # then make sure that it is a conditional comment before calling
write routine.
      # 
      #if ($Conditionals && not $GenAda) {
      if ($Conditionals && ! $GenAda) {
          if ( /^\s*$CMNT/ ) {
              write_if ("$_");
          } else {
              write_if ("$CMNT$_");
          } 
          next LINE;                
      }         
      die "We found a condition that this humble programmer did not
anticipate.";
  } # end loop  

}  # end sub parse_block

# ---------------------------------------------------------------------------------------
#sub write_if ($line);
#
#  write the line unless the "StripPreserve" or "StripDelete" flag is
set
#  and this is a conditional comment. 
#
sub write_if {

   $_ = shift;                            #
   if ( /^\s*$CMNT/ ) {                   # if a cond commment
      return if ($StripDelete);           #     delete the line if we
are strip-deleting.
      if ($StripPreserve) {               #     if strip-replacing
with blank line
          write_line ("\n");              #         substitute a blank
line
          return;                         #
      }                                   #
   }
   # If this is NOT a comment, but has the "one-line" conditional at
the right end
   # and we are stripping comments, Then we want to keep the line
except for the
   # conditional at the right end.
   #   
   if ( /^(.*) ($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) {
       if ( $StripDelete  ||  $StripPreserve ) {
          write_line ("$1\n");
          return;
       }
   }
   write_line ("$_");                     # write the line as-is
}
# ---------------------------------------------------------------------------------------
#
# Write it to stdout or the file (if specified).
#
sub write_line {

    my $line = shift;
    if ( $to_file ) {
       #IO:  $fhout->print ($line);
       print OUTPUT "$line";
    } else {
       print "$line";
    }
}
#-----------

1;

__END__

=head1 NAME

Devel::PreProcess -  Source code preprocessing.

=head1 SYNOPSIS

From a command line,

    sh> perl Devel/PreProcess.pm -Flags sourcefile > targetfile
  or
    sh> perl Devel/PreProcess.pm -Flags sourcefile  [targetfile]

Or in a Perl script,

    use Devel::PreProcess qw( Flags );
    Devel::PreProcess::parse_file( $sourcefile [, $targetfile]  );

=head1 DESCRIPTION

This package processes source files and outputs a modified version
according to several user-setable option flags, as detailed below.

Each of the flag names listed below can be used as above, with a
hyphen on
the command line, or as one of the arguments in an import statement.
Each
of these flags are mapped to the scalar package variable of the same
name.

=over 4

=item Conditionals 

(True is the default)
(Use Noconditionals to turn it off)

If true, parse_file will utilize a simple conditional inclusion
scheme, as follows.

    --#__COND__ if expr1
    ...     
    --#__COND__ elsif expr2
    ...
    --#__COND__ else
    ...
    --#__COND__ endif

The "elsif" line is optional, and there may be more than one such
line.
The "else" line is optional.

The provided Perl expression (expr1) is evaluated, and unless it is
true,
everything up to the next conditional declaration is made into comment
lines. If "false" then sucessive elsif conditionals, if preset, are
evaluated
as in any "if ... elsif  ... else ... endif" logic. 

The conditional functionality can be combined with Perl's C<-s>
switch,
which allows you to set flags on the command line, such as:

    perl -s Devel/PreProcess.pm -Conditionals -Switch filter.test

You can use any name for your switch, and the matching scalar variable
will be set true; the following code will only be used if you supply
the argument as shown below.

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

If the Switch variable is true then the output file will contain:

    --#__COND__ if $Switch
       put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

Thus, the two Ada lines of code will be compiled.
If the Switch variable is false then the output file will contain:

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
    --#      put_line ("so these two lines will be printed"); 
    --#__COND__ endif

Since the "if" and "elsif" conditions are Perl conditionals, they can 
be a compound conditional. Use "&&" for AND, "||" for OR, etc. For
example:

    --#__COND__ if ($green && ($apple || $pear))

In addition, the "if ... endif" blocks can be nested.

In reality, it is legal to have white-space between the "--#" and the
"__COND__"
portions of a conditional statement.

=item StripPreserve

This option will cause all lines beginning with the Conditional
Comment prefix
("--#"  or its replacement) on the output side of the logic to be
replaced with
a blank line in the output stream.

=item StripDelete

This option will cause all lines beginning with the Conditional
Comment prefix
("--#"  or its replacement) on the output side of the logic to be
deleted, that
is, not written to the output stream.

=item CMNT="comment-string"

This option will replace the Conditional Comment string "--#" with the
"comment-string" provided. Thus  -CMNT="--$$$" would specify an
alternative for
conditional comment string for Ada, while  -CMNT="#*#*" could be used
to
specify a conditional comment string when preparsing Perl source code.

=item CNDT="conditional-string"

This option will replace the Conditional string "__COND__" with the 
"conditional-string" provided. This is the string that comes after the
CMNT
string to specify a line with "if", "elsif", "else" and "endif"
statements.


=back

=head1 EXAMPLES


=head1 BUGS AND CAVEATS

Option Flags -CMNT and -CNDT may not work when calling from another
Perl script. (Workaround: just make a separate copy of the pgm that
has
the desired defaults.)

=head1 PREREQUISITES

This package should run on standard Perl 5 installations, but 
may not run on earliest Perl 5 releases or incomplete installations.

=head1 STATUS AND SUPPORT

This release of Devel::PreProcess is intended primarily for limited
private
use. Not all options (especially "caller" options) have been tested.

=head1 AUTHORS AND COPYRIGHT

This program was adapted from a Devel::PreProcessor.pm from 
Evolution Online Systems, Inc. E<lt>www.evolution.comE<gt>, which had
Copyright restrictions on it. It is felt that the changes to it are 
significant enought that the Copyright is not applicable.
Nevertheless,
credit is given to them for the basic program structure. Also, an
email from them said it is OK to use it in this way. 

The modifications were made by Peter Richtmyer, RISYS, Portsmouth, RI.
Others may use and modify it, just don't sell it or package it for
sale.

============================= PreCheck.pm
===============================
#!/usr/local/bin/perl -s

package Devel::PreCheck;
#IO:   use IO::File;
#use vars qw( $Conditionals $StripPreserve $StripDelete );
#use vars qw( $CMNT $CNDT $GenAda $fh $fhout $to_file $line_number );

$RETURN_CODE = 0;    # code returned to system or caller
#              0  -  OK  
#             -1  -  Command Line option error.
#             -2  -  Could not open the input file or none specified.
#             -3  -  Could not open the output file or none specified.

goto PAST_HELP;  #### We put 'HELP' up here so you can see it easily. 
:-)

PRINT_HELP:
   print <<"END_HELP";

                            Devel::PreCheck
                                 v  2.1
              Check for conditional compile code in source code   

From a command line,

    sh> perl -s Devel/PreCheck.pm -Flags sourcefile 
    
Or in a Perl script,

    use Devel::PreProcess qw( Flags );
    Devel::PreProcess::parse_file( $sourcefile );

DESCRIPTION

This package processes source files and outputs a 
   0 - no conditional statements found
   1 - found 

Each of the flag names listed below can be used as above, with a
hyphen on
the command line, or as one of the arguments in an import statement.
Each
of these flags are mapped to the scalar package variable of the same
name.

Option -Conditionals 

  (True is the default)
  (Use Noconditionals to turn it off)

  If true, parse_file will utilize a simple conditional inclusion
scheme, as follows.

    --#__COND__ if expr1
    ...     
    --#__COND__ elsif expr2
    ...
    --#__COND__ else
    ...
    --#__COND__ endif

  The "elsif" line is optional, and there may be more than one such
line.
  The "else" line is optional.

  The provided Perl expression (expr1) is evaluated, and unless it is
true,
  everything up to the next conditional declaration is made into
special comment
  lines ("--#"). If "false" then sucessive elsif conditionals, if
preset, are
  evaluated as in any "if ... elsif  ... else ... endif" logic. 
 
  In addition, a single line may be conditional'd using the following
format:

   --#{expr3} source code first line here;
   some more source code on second line; --#{expr4}

  When these expressions (expr3 and expr4) are evaluated, when True
then the line
  will be output in the format of the second line above so that the
Ada code is
  active. When an expression is False, then the output will be in the
format of
  the second above. 

  For example, lines below were preprocessed with "-demo" on command
line:
     -- TESTING: this is demo line   --#{$demo}
     --#{!$demo}    -- TESTING: not a demo line  

  WARNING: This does not work correctly in some environments unless
there are
  spaces after the "}" and/or before the "--#" when at the end of a
line.

  The conditional functionality can be combined with Perl's -s switch,
  which allows you to set flags on the command line, such as:

    perl -s Devel/PreProcess.pm  -Switch filter.test

  You can use any name for your switch, and the matching scalar
variable
  will be set true; the following code will only be used if you supply
  the argument as shown below.

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  If the Switch variable (entered on the command line as in the
example above)
  is true then the output file will contain:

    --#__COND__ if $Switch
       put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  Thus, the two Ada lines of code will be compiled.
  If the Switch variable is false then the output file will contain:

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
    --#      put_line ("so these two lines will be printed"); 
    --#__COND__ endif

  Since the "if" and "elsif" conditions are Perl conditionals, they
can
  be compound conditionals. Use "&&" for AND, "||" for OR, etc. And
use
  the "!" for NOT. For example:

    --#__COND__ if ($green && ! ($apple || $pear))

  In addition, the "if ... endif" blocks can be nested.

  In reality, it is legal to have white-space between the "--#" and
the "__COND__"
  portions of a conditional statement.

  It should be noted that one of the strengths of this preprocessor is
that the
  output from one "run" can be used as the input to the next run. For
example, if
  code is being developed on two different computing environments
(e.g. home and
  work), then the code can be generated using a "-home" switch. The
code would be
  developed and tested some at home, with changes made. Then the code
would be
  run through with the "-work" switch set, and development and test
would continue
  on the same source code at work.  


Option -CMNT="comment-string"

  This option will replace the Conditional Comment string "--#" with
the
  "comment-string" provided. Thus  -CMNT="--$$$" would specify an
alternative for
  conditional comment string for Ada, while  -CMNT="#*#*" could be
used to
  specify a conditional comment string when preparsing Perl source
code.

Option -CNDT="conditional-string"

  This option will replace the Conditional string "__COND__" with the 
  "conditional-string" provided. This is the string that comes after
the CMNT
  string to specify a line with "if", "elsif", "else" and "endif"
statements.

Option -LEFT="left-side"

  This option will replace the "{" as the string on the left side of a
single-line
  conditional with "left-side"

Option -RIGHT="right-side"

  This option will replace the "}" as the string on the right side of
a single-line
  conditional with "right-side"

  So, if entered " -LEFT="{{"  -RIGHT="}}" then the single-line
conditionals
  would be similar to:  --#{{expr5}}

  Care must be taken, certain special charaters need to be "escaped".
For example,
  a left paren by itself will not work (you will get a program error).
 So:
        -LEFT="("  will not work,  use  -LEFT="\("

BUGS AND CAVEATS

Option Flags -CMNT and -CNDT msy not work when calling from another
Perl script. (Workaround: just make a separate copy of the pgm that
has
the desired defaults.)

END_HELP
    exit ($RETURN_CODE);
################3############## Change History
#################################

# ver    date                           description
# ---  --------  -----------------------------------------------------------------
# 1.0 03/26/00  Original, copied from PreProcess.pm
# 2.0 06/08/03  In addition to looking for a string like "--#__COND__"
#               at the beginning of a line, must also look for a 
#               string like "--#{...}" at the beginning or end of a
line.
# 2.1 07/10/03  Minor pattern-matching change

PAST_HELP:
#
# Change the variables below to change the "syntax" of the
conditionals:
#
$CMNT         = "--#";
$CNDT         = "__COND__";
$LEFT         = "{";
$RIGHT        = "}";
#
$Conditionals = 1;   

# @psuedo_INC - directories to search for modules
#use vars qw( @psuedo_INC );

# %Importers - maps file inclusion keywords to their import methods
#use vars qw( %Importers );
#%Importers = (
#  'require' => '',
#  'use' => 'import',
#  'no' => 'unimport',
#);

# Devel::PreProcessor->import( 'StripPreserve', 'Conditionals', ... );
sub import {

  my $package = shift;
  foreach ( @_ ) {
    if ( m/Conditionals/i )        {
      $Conditionals = 1;
    } elsif ( m/Noconditionals/i ) {   ### PMR not tested yet
      $Conditionals = 0;               ### PMR not tested yet
    } elsif ( m/h/i )  {
      goto PRINT_HELP;
    } elsif ( m/help/i )  {
      goto PRINT_HELP;
    } elsif ( m/LibPath:(.*)/i )   {
      @INC = split(/\:/, $1);
    } elsif ( m/CMNT=(.*)/)        {   ### PMR not tested yet
      $CMNT = $1;                      ### PMR not tested yet
    } elsif ( m/CNDT=(.*)/)        {   ### PMR not tested yet
      $CNDT = $1;                      ### PMR not tested yet
    } elsif ( m/RIGHT=(.*)/)       {
      $RIGHT = $1;    
    } elsif ( m/LEFT=(.*)/)        {
      $LEFT = $1;       
    } else                         {
      die "unkown import";
    }
  }
}

# If we're being run from the command line, look for certain options 
# on the command line after program name.
unless ( caller ) {

  goto PRINT_HELP                          if ( $main::help ||
$main::h ) ;
  goto PRINT_HELP                          if ( $main::Help ||
$main::H ) ;
  $Conditionals    = 0                     if ( $main::Noconditionals
);
  $Conditionals  ||= $main::Conditionals;
  $CMNT            = $main::CMNT           if ($main::CMNT);
  $CNDT            = $main::CNDT           if ($main::CNDT);
  $LEFT            = $main::LEFT           if ($main::LEFT);
  $RIGHT           = $main::RIGHT          if ($main::RIGHT);
  my $in_source    = shift @ARGV;       # input filename

  parse_file ( $in_source  );
} 
# ------------------------------ parse_file
------------------------------------
#
# Calling:   parse_file ( $infilename );
#
# This routine is called by the mainline above. But it can also be
called
# by an external program.
#
sub parse_file {
    #
    # before doing much, let's make sure that any overrides to
conditional
    # matching variables are legal.
    #
## NEED to get this to work, and one for the {$test}

    if ( eval ("$line =~ /$CMNT\s*$CNDT/") )  {
        print "ERROR: You entered an illegal string for CMNT or CNDT
\n";
        print "       CMNT='$CMNT', CNDT='$CNDT' \n";
        print "       Use a backslash '\\' before certain special
characters. \n";
        die   "Try Again";
    }

    my $infilename  = shift;                       # the file to
preparse
    #IO:  $fh     = IO::File->new($infilename);          # global
inputfile handle
    #print ("open ( INPUT, $infilename ) \n"); 
    open ( INPUT, $infilename )  ||  die "Unable to open input file
$infilename";
            

    while (<INPUT>) {
      
      # print "looking for $CMNT$CNDT in: $_\n";
      
      if (  /^\s*$CMNT\s*$CNDT/i ) {
         print "Found conditional in: file $infilename \n";
         close (INPUT);
         exit 1;          # found conditional 
      } 
  
      # print "looking for $CMNT$LEFT...$RIGHT at beginning of: $_\n";
    
      if ( /^(\s*$CMNT\s*$LEFT.*$RIGHT)(.*)$/ ) {
         print "Found conditional in: file $infilename \n";
         close (INPUT);
         exit 1;          # found conditional 
      } 

        print "looking for $CMNT$LEFT...$RIGHT at end of: $_\n";

      if ( /^(.*)($CMNT\s*$LEFT.*$RIGHT\s*)$/ ) {
         print "Found conditional in: file $infilename \n";
         close (INPUT);
         exit 1;          # found conditional 
      } 

    }
    print "DID NOT FIND CONDITIONAL in FILE: $infilename \n";
    close (INPUT);
    exit 0;               # no conditionals found
}
#-----------

1;

__END__

=head1 NAME

Devel::PreProcess -  Source code preprocessing.

=head1 SYNOPSIS

From a command line,

    sh> perl Devel/PreProcess.pm -Flags sourcefile > targetfile
  or
    sh> perl Devel/PreProcess.pm -Flags sourcefile  [targetfile]

Or in a Perl script,

    use Devel::PreProcess qw( Flags );
    Devel::PreProcess::parse_file( $sourcefile [, $targetfile]  );

=head1 DESCRIPTION

This package processes source files and outputs a modified version
according to several user-setable option flags, as detailed below.

Each of the flag names listed below can be used as above, with a
hyphen on
the command line, or as one of the arguments in an import statement.
Each
of these flags are mapped to the scalar package variable of the same
name.

=over 4

=item Conditionals 

(True is the default)
(Use Noconditionals to turn it off)

If true, parse_file will utilize a simple conditional inclusion
scheme, as follows.

    --#__COND__ if expr1
    ...     
    --#__COND__ elsif expr2
    ...
    --#__COND__ else
    ...
    --#__COND__ endif

The "elsif" line is optional, and there may be more than one such
line.
The "else" line is optional.

The provided Perl expression (expr1) is evaluated, and unless it is
true,
everything up to the next conditional declaration is made into comment
lines. If "false" then sucessive elsif conditionals, if preset, are
evaluated
as in any "if ... elsif  ... else ... endif" logic. 

The conditional functionality can be combined with Perl's C<-s>
switch,
which allows you to set flags on the command line, such as:

    perl -s Devel/PreProcess.pm -Conditionals -Switch filter.test

You can use any name for your switch, and the matching scalar variable
will be set true; the following code will only be used if you supply
the argument as shown below.

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

If the Switch variable is true then the output file will contain:

    --#__COND__ if $Switch
       put_line ("you hit the switch!");
          put_line ("so these two lines will be printed"); 
    --#__COND__ endif

Thus, the two Ada lines of code will be compiled.
If the Switch variable is false then the output file will contain:

    --#__COND__ if $Switch
    --#   put_line ("you hit the switch!");
    --#      put_line ("so these two lines will be printed"); 
    --#__COND__ endif

Since the "if" and "elsif" conditions are Perl conditionals, they can 
be a compound conditional. Use "&&" for AND, "||" for OR, etc. For
example:

    --#__COND__ if ($green && ($apple || $pear))

In addition, the "if ... endif" blocks can be nested.

In reality, it is legal to have white-space between the "--#" and the
"__COND__"
portions of a conditional statement.

=item StripPreserve

This option will cause all lines beginning with the Conditional
Comment prefix
("--#"  or its replacement) on the output side of the logic to be
replaced with
a blank line in the output stream.

=item StripDelete

This option will cause all lines beginning with the Conditional
Comment prefix
("--#"  or its replacement) on the output side of the logic to be
deleted, that
is, not written to the output stream.

=item CMNT="comment-string"

This option will replace the Conditional Comment string "--#" with the
"comment-string" provided. Thus  -CMNT="--$$$" would specify an
alternative for
conditional comment string for Ada, while  -CMNT="#*#*" could be used
to
specify a conditional comment string when preparsing Perl source code.

=item CNDT="conditional-string"

This option will replace the Conditional string "__COND__" with the 
"conditional-string" provided. This is the string that comes after the
CMNT
string to specify a line with "if", "elsif", "else" and "endif"
statements.


=back

=head1 EXAMPLES


=head1 BUGS AND CAVEATS

Option Flags -CMNT and -CNDT msy not work when calling from another
Perl script. (Workaround: just make a separate copy of the pgm that
has
the desired defaults.)

=head1 PREREQUISITES

This package should run on standard Perl 5 installations, but 
may not run on earliest Perl 5 releases or incomplete installations.

=head1 STATUS AND SUPPORT

This release of Devel::PreProcess is intended primarily for limited
private
use. Not all options (especially "caller" options) have been tested.


=head1 AUTHORS AND COPYRIGHT

This program was adapted from a Devel::PreProcessor.pm from 
Evolution Online Systems, Inc. E<lt>www.evolution.comE<gt>, which had
Copyright restrictions on it. It is felt that the changes to it are 
significant enought that the Copyright is not applicable.
Nevertheless,
credit is given to them for the basic program structure. Also, an
email from them said it is OK to use it in this way. 

The modifications were made by Peter Richtmyer, RISYS, Portsmouth, RI.
Others may use and modify it, just don't sell it or package it for
sale.

============================ BAT_PREP.BAT
================================
 echo off
 REM   BAT_PREP.BAT
 REM   03/26/01
 REM   04/12/01 added .txt files for help template
 REM   11/07/01 added logic to create output dir if needed
 REM   06/08/03 chgd ".scr" to ".script"
 REM
 REM   need to call this with at least two parameters:
 REM
 REM     1 = sending directory
 REM     2 = receiving directory
 REM     3 - 9 = (optional) the Perl variable names for preprocessing.
 REM
 REM  for example:
 REM
 REM     bat_prep  D:\my_dir  D:\my_dir2  -demo   -gnat
 REM 
 REM   remember we do not WANT TO COPY .BAT FILES
 
if not exist %1 echo #### ERROR in BAT_PREP.BAT, the Sending dir does
not exist: %1 ####
if not exist %1 pause
call CREATE_DIR_IF_NEEDED %2

echo   ABOUT TO COPY ALL .ada, .adb, .ads, .script, .txt gnat.* FROM
%1 TO %2  CTL-C to QUIT
pause

 rem the options like "-demo" must have a dash before them
 rem from %1 to %2 with booleans: %3 %4 %5 %6 %7 %8 %9

 rem ARE YOU SURE?  BACK UP FIRST?????


 rem echo about to copy all %1\*.txt   to   %2
 rem pause
 copy %1\*.txt                 %2 

 rem echo about to copy all %1\*.script   to   %2
 rem pause
 copy %1\*.script              %2  

 rem echo about to copy all %1\gnat.*   to   %2
 rem pause
 copy %1\gnat.*                %2 

 PAUSE                    

 for %%f in (%1\*.ada %1\*.ads %1\*.adb) do call bat_chk_convert.bat
%%f  %2   %3 %4 %5 %6 %7 %8 %9

 pause                                  -- check results

========================= BAT_CHK_CONVERT.BAT
==========================
 echo off
 REM   BAT_CHK_CONVERT.BAT
 REM   03/26/01
 REM
 REM   need to call this with at least two parameters:
 REM
 REM     1 = sending directory
 REM     2 = receiving directory
 REM     3 - 9 = (optional) the Perl variable names for preprocessing.
 REM
 REM  for example:
 REM
 REM     bat_chk_convert  D:\my_dir  D:\my_dir2  -demo   -gnat
 REM 
 rem the options like "-demo" must have a dash before them
 rem from %1 to %2 with booleans: %3 %4 %5 %6 %7 %8 %9
 rem Note that we only want to preprocess if we have to.
 rem otherwise we use a "copy" command so the file date does not
change.
 
 rem pause
  
  rem first see if there are any conditionals ("--#") in the file

  rem echo    calling PreCheck.pm %3 %4 %5 %6 %7 %8 %9   %1
  perl -s C:\perl\bin\PreCheck.pm %3 %4 %5 %6 %7 %8 %9   %1    

  if not errorlevel 1 goto copyfile

 rem  echo           PreProcess.pm  %3 %4 %5 %6 %7 %8 %9   %1     %2

 perl -s C:\perl\bin\PreProcess.pm  %3 %4 %5 %6 %7 %8 %9   %1     %2

 goto end

:copyfile 

 copy %1  %2  

:end

rem pause
======================= CREATE_DIR_IF_NEEDED.BAT
=======================
echo off
 REM   CREATE_DIR_IF_NEEDED.BAT
 REM
 REM   11/07/01 new
 REM
 REM   need to call this with parameters
 REM
 REM     1 = directory to check, and add if it does not exist
 REM
 REM  for example:
 REM
 REM    call  CREATE_DIR_IF_NEEDED  D:\my_dir  
 REM 
 
if not exist %1 echo Creating the output dir: %1
if not exist %1 mkdir %1
if not exist %1 echo #### ERROR: could not create output dir: %1 ####
if not exist %1 pause

Re: Standard Ada Preprocessor

[tmoran]

>Lines: 1496
  While appreciating the offer of the program, I really do prefer not
to have exceedingly large ( > 100 line, say) newsgroup messages.  Better
to just post a link to a web site.

Re: Standard Ada Preprocessor

[Marin David Condic]

Well, there you go. Ada doesn't provide a "standard" way to do it - 
perhaps out of some sense of technical purity. People still find it an 
attractive way to fix the problems they have maintaining things for two 
or more platforms. What do they do? They home-grow an answer that solves 
their problem (while not being portable) - or they go use a language 
that gives them what they want.

MDC


Peter Richtmyer wrote:
> I have not read the entire thread. Bottom lines for me:
>     1) too bad Ada does not have a preprocessor
>     2) I needed one, so I created one
> 
> It has served me well for 4 years on Win2000, Solaris, HP/UX,
> and LynxOS. Not elegant but very useful to me, to take code
> home at night, develop/test on Win2000, then back to work with the
> same source code (preparsed) to continue to develop/test on Solaris 
> (or other). 
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

RE: Standard Ada Preprocessor

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Robert I. Eachus [mailto:rieachus@comcast.net]
...
| 
| Somebody wrote an article (for Ada Letters I think) on how to write 
| representation specifications that are legal (and identical!) for 
| bigendian and little endian hardware.  Anyone remember it?

Could be :
 
- Endian-Safe Record Representation Clauses for Ada programs
  Mike Mardis, Ada Letters, December 99.

or 
- Endian-Independent Record Representation Clauses
  Norman H, Cohen, Ada Letters Jan/Feb 94

-- 
lionel Draghi

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Marin David Condic wrote:

> I'm not talking about addresses. Have you never seen a rep clause on a 
> record, for example, that a given compiler will refuse to accept even if 
> it is syntactically legal? I don't happen to have one sitting in my back 
> pocket at the moment, but I *know* I've coded up valid rep clauses on 
> records that compilers have spit out and refused to accept. Technically, 
> it is legal for an implementation to refuse just about any rep clause it 
> doesn't want to be bothered with - so perhaps you've got it coded up one 
> way for one compiler and another way for another compiler.
> 
> Perhaps there's some arcane trick that can be pulled to change rep 
> clauses on a record on the fly, but I've not seen it (and it sure starts 
> sounding *far* more complex than decrypting a simple conditional 
> compilation directive - maybe this is what frustrates me about the 
> opposition to a conditional compile: Everyone holds out some cumbersome, 
> complex, arcane trickery that is orders of magnitude more difficult to 
> understand and utilize properly as an answer in order to avoid something 
> that is capable of being pretty simple & basic.). What I *have* seen is 
> rep clauses that a compiler refuses to accept - and hence I can't even 
> *get* to runtime because I've got compile errors. Legal or not - Moral 
> or not - I still have to get a job done and a conditonal compilation 
> directive of some sort would fix the problem.

Sigh, if you want to win the debate, fine, but I can't help you.  If you 
want to have an easier time of it when writing implementation dependent 
code, pay attention.

My point is not that I have a magic wand that can be waved over your 
program to reduce the amount of implementation code to zero.  My point 
is that if you are willing to do things the Ada way instead of the C 
way, the number of system dependent files becomes very small.

It would be nice if you could write your code so that all of the that 
code depended on System, so you didn't need to maintain multiple 
versions.  To some extent that is a bug in the language that we 
discussed in this thread.  (Implementations where System.Name is 
useless.)  What I am trying to say, is use these techniques, and you 
will end up with one or two files that need to be changed when porting.

If you want to use a preprocessor to maintain that file, fine.  Many Ada 
compilers actually supply one, or you can use cpp.  Personally my style 
is to provide a "generic" version and to expect those who port the code 
to tailor it.  Optimally, that file contains only a package body, but 
doing that requires going to extremes you might not like.  Just to give 
one example,  You might define two interfaces for some OS calls and 
choose which one to use every time the interface is called.  This 
requires that the code that calls them, and the parameters passed, are 
in a nested scope.  This often adds extra overhead to system calls. 
Worth it?  You choose.  But putting all the system dependent cruft in 
one compilation unit in my experience, should be automatic.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Lionel.DRAGHI@fr.thalesgroup.com wrote:

> Could be :
>  
> - Endian-Safe Record Representation Clauses for Ada programs
>   Mike Mardis, Ada Letters, December 99.
> 
> or 
> - Endian-Independent Record Representation Clauses
>   Norman H, Cohen, Ada Letters Jan/Feb 94

Thanks!  It happened to be Norm's paper that I remembered.  But I guess 
it must be time to publish such a paper again. ;-)

Actually, I assume that Mike's paper is an update based on Ada 95, and 
that if there are any changes in this area in Ada 0Y, that a new paper 
will be needed.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

>   #if sizeof(int) == 16

Ah, yes, 128-bit integers. Of course, this is not an issue in Ada, since 
we declare appropriate numeric types.

> And what I find amusing is that except for a few that
> appreciate this issue, we've heard of every ugly
> work-around possible, rather than face the issue
> square in the eye. This is just my opinion mind you,
> and perhaps small things amuse me ;-)

As someone who has faced the issue and never used a preprocessor, but 
has had to read code that does, I find a good design that hides the 
dependencies to be far more readable. Eachus has also faced the issue 
without using a preprocessor, with similar results. As the ARM says, Ada 
emphasizes "program readability over ease of writing". Preprocessors do 
the opposite.

Preprocessors are a coder's solution; information hiding is a software 
engineer's solution. Perhaps to the question, "Do you like debugging?" 
which is very accurate at distinguishing coders from software engineers, 
we should add, "Do you like preprocessors?"

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Matrix 10 POSIX environments x 10 versions of the same, x 4
> different versions of a curses library. That leaves you with
> 400 different custom (possibly groups of) packages to work
> with. Real slick indeed. :(

One standard POSIX-Ada binding and one application-specific screen 
control package leaves me with 4 different package bodies to deal with, 
each of which contains code specific to one curses library. The code for 
a specific curses library is in one place, so I don't have to hunt all 
over the code for the bits that deal with that library when I have to 
change something.

If you want to handle those package bodies as one big file that you 
preprocess to get the desired version for a platform, go ahead. The 
payoff was in creating the application-specific package.

The point should always be "what does the application require?", not 
"what does the platform/environment provide?" Once you've done that you 
can always hide the differences behind an application-specific interface.

>> So I don't believe in preprocessors for Ada code.  
> 
> Think "conditional compilation". I see the "how" as an
> implementation detail, that need _not_ track the C/C++
> experience.

This thread is about a standard preprocessor (see the subject). But as 
someone who has done this kind of thing without a preprocessor and 
prefer the results, I'm convinced that what's needed is a portable way 
to tell the compiler to use the package body from the Win32 directory, 
or from the UNIX directory, or from the VMS directory.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Stephane Richard" <stephane.richard@verizon.net> wrote in message
news:XNPQb.5318$Ig2.1236@nwrdny02.gnilink.net...
> What's the URL for Ada-comment?

There is a page describing access to Ada-Comment at:

http://www.adaic.com/standards/articles/comment.html

              Randy.

Endian-Independent Rep Clauses (was: Standard Ada Preprocessor)

[Jeffrey Carter]

Robert I. Eachus wrote:

> Lionel.DRAGHI@fr.thalesgroup.com wrote:
> 
>> Could be :
>>  
>> - Endian-Safe Record Representation Clauses for Ada programs
>>   Mike Mardis, Ada Letters, December 99.
>>
>> or - Endian-Independent Record Representation Clauses
>>   Norman H, Cohen, Ada Letters Jan/Feb 94
> 
> 
> Thanks!  It happened to be Norm's paper that I remembered.  But I guess 
> it must be time to publish such a paper again. ;-)
> 
> Actually, I assume that Mike's paper is an update based on Ada 95, and 
> that if there are any changes in this area in Ada 0Y, that a new paper 
> will be needed.
> 

IIRC, it addresses the fact that Default_Bit_Order is static, thanks to 
an AI, and uses static universal math based on Boolean'Pos 
(Default_Bit_Order = <one_of_the_choices>) to calculate bit positions. 
I've done this kind of thing; it requires long expressions for bit 
numbers, but works fine.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:
> Warren W. Gay VE3WWG wrote:
> 
>>   #if sizeof(int) == 16
> 
> Ah, yes, 128-bit integers. Of course, this is not an issue in Ada, since 
> we declare appropriate numeric types.

Oops! Substitute 4 or 8 for 16!

>> And what I find amusing is that except for a few that
>> appreciate this issue, we've heard of every ugly
>> work-around possible, rather than face the issue
>> square in the eye. This is just my opinion mind you,
>> and perhaps small things amuse me ;-)
> 
> As someone who has faced the issue and never used a preprocessor, but 
> has had to read code that does, I find a good design that hides the 
> dependencies to be far more readable. 

Of course this is to be "preferred".

> Eachus has also faced the issue 
> without using a preprocessor, with similar results. As the ARM says, Ada 
> emphasizes "program readability over ease of writing". Preprocessors do 
> the opposite.

And two people's experience does not equate to
"everyone's" ;-)

> Preprocessors are a coder's solution; information hiding is a software 
> engineer's solution. Perhaps to the question, "Do you like debugging?" 
> which is very accurate at distinguishing coders from software engineers, 
> we should add, "Do you like preprocessors?"

As said before, I prefer a portable platform neutral code
as much as the next guy. But when you start writing bindings
and such that must bind to _many_ different situations,
this simply becomes impractical.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Matrix 10 POSIX environments x 10 versions of the same, x 4
>> different versions of a curses library. That leaves you with
>> 400 different custom (possibly groups of) packages to work
>> with. Real slick indeed. :(
> 
> One standard POSIX-Ada binding 

Impossible. Some UNIces provide some API structure members,
while others don't, or provide something else again. Yes,
you can dumb it down to a "standard" (or omit non-universal
functionality), but by doing so you throw away functionality.
I find that unacceptable.

> and one application-specific screen 
> control package leaves me with 4 different package bodies to deal with, 
> each of which contains code specific to one curses library. 

Ah, but you cannot assume that the binding for PDcurses,
is going to be the same for all different POSIX platforms!
Going from POSIX, to X Windows, to Win32, will change the
interfaces again. It is not this simple, as the level of
support changes depending upon the platform, and version
of the same (in some cases). Try it in an open sourced
project (as I have), and you'll be a little wiser for it.

> If you want to handle those package bodies as one big file that you 
> preprocess to get the desired version for a platform, go ahead. The 
> payoff was in creating the application-specific package.
> 
> The point should always be "what does the application require?", not 
> "what does the platform/environment provide?" 

When you code "bindings" you have to consider both. Sometimes
you can push the application requirments into the thick
binding, developing some distance from the thin one. But at
some level, you will _still_ have to look at OS and C library
level "requirements". Develop some Open Sourced code in
without gnatprep, and we'll see how portable it is ;-)

> Once you've done that you 
> can always hide the differences behind an application-specific interface.

There is hiding to be sure. But down at the C and OS level,
things get rather ugly when trying to be "portable". The
fault of this is not so much Ada, but trying to interface
to a predominantly non-Ada world.

>> Think "conditional compilation". I see the "how" as an
>> implementation detail, that need _not_ track the C/C++
>> experience.
> 
> This thread is about a standard preprocessor (see the subject). But as 
> someone who has done this kind of thing without a preprocessor and 
> prefer the results, I'm convinced that what's needed is a portable way 
> to tell the compiler to use the package body from the Win32 directory, 
> or from the UNIX directory, or from the VMS directory.

That functionality would help. But there is still a need for
more than that.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: For example, you'd pretty much have to have a different package
: for every POSIX-like environment, because of changes like what
: was included in the stat(2) structure (and others). Worse, you'd
: have to matrix it out to the various releases of Linux, FreeBSD,
: NetBSD, OpenBSD, Solaris, IRIX, HPUX etc. You cannot hope to
: accommodate all of these differences by package names.

Not throwing in everything, (though that adds combinations no
matter which method is chosen to deal with the variety),
the following works for me (and also in more complex arrangements).
I will have to make exactly two changes if I want to switch the
OS/POSIX combination:

with OS;    -- see next
procedure run is

   use OS.BSD;

   sample_file: constant := -321;
   --  just any unlikely file descriptor, don't create havoc

   --  We need C.int comparisons for function returns, so:
   use type int;
begin

   --  bad style and all sorts of things...

   if C_MINUS_1 = lockf(sample_file, F_LOCK, 8192) then
      raise Program_Error;
   end if;

end run;


with Systems.BSD_x86;
-- with other Systems as well...
package OS is

   package BSD renames Systems.BSD_x86.FantasyBSD.Non_Standard_POSIX;

   -- package Linux renames ...;

   -- package SUNOS renames ...;

   -- package MacOS renames ...;

end OS;


package Systems is
end Systems;


with Interfaces.C;    use Interfaces;
package Systems.BSD_x86 is

   --  POSIX items for all flavours of BSD for x86.
   -- As there are allegedly both Standard POSIX items and non-standard
   -- ones on some (possibly older) systems, see Warren W. Gay's posting,
   -- there is a Non_Standard_POSIX and a Standard_POSIX package in
   -- each BSD variant package.

   -- ----------------
   -- FantasyBSD
   -- ----------------
   package FantasyBSD is

      package Non_Standard_POSIX is

         use type C.int;

         C_MINUS_1: constant C.int := -1;
         --  indicating a failing function

         F_LOCK: constant C.int := 3_4829; -- surprising value

         subtype off_t is C.long;
         subtype int is C.int;

         function lockf
           (file_descriptor: int;
            function_number: int;
            bytes: off_t)
           return int;
         pragma import(C, lockf);

      end Non_Standard_POSIX;

      package Standard_POSIX is

         --  rename needed functions from ISO Ada Bindings

      end Standard_POSIX;

   end FantasyBSD;


   -- ----------------
   -- OpenBSD
   -- ----------------
   package OpenBSD is
   end OpenBSD;


   -- ----------------
   -- FreeBSD
   -- ----------------
   package FreeBSD is
   end FreeBSD;

   -- ...

end Systems.BSD_x86;



georg@strudel:~/rsrc/Ada/wg$ gnatmake run
gcc -c run.adb
gcc -c os.ads
gcc -c systems.ads
gcc -c systems-bsd_x86.ads
gnatbind -x run.ali
gnatlink run.ali
georg@strudel:~/rsrc/Ada/wg$ ./run

raised PROGRAM_ERROR : run.adb:15 explicit raise
georg@strudel:~/rsrc/Ada/wg$ 


Most outstanding bug: the program has been compiled on
Linux strudel 2.4.18 #1 Fri May 2 17:22:29 CEST 2003 i686 unknown ;-)


: I get frustrated with the short sightedness of the "not invented
: here syndrome". But maybe, that is just me. ;-)

Hm. Plan 9's C enviroment does well without #ifdefs, even though
it has to provide this environment for different architectures.
This is reported to be confusing for those who have unfortunately
been told to use

#if defined __THIS_HEADER__

in header files, as a replacement for a design that keeps things
separate so multiple inclusion does not occur.

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Warren W. Gay VE3WWG wrote:

> As said before, I prefer a portable platform neutral code
> as much as the next guy. But when you start writing bindings
> and such that must bind to _many_ different situations,
> this simply becomes impractical.

I feel here like I am being castigated for something I have never said. 
  (No, I am not saying Warren is attacking me, just that I have the 
feeling that I am not getting my point across.)

The problem is that there is an underlying philosophical difference, and 
until and unless you accept the "Ada" philosophy you will be 
uncomfortable programming in Ada.  Once you "get it" Ada becomes as 
comfortable as well broken-in shoe.  There are still some minor lumps 
and bumps--but you don't notice them.

For a second assume that there are things that do require a preprocessor 
to do in Ada.  Now look at the long debate here, from the point of view 
that one group uses preprocessor directives in with clauses and the 
public part of packages, while I argue that this is poor programming 
practice and that all preprocessor directives belong in unit bodies 
where possible, and as few such bodies as possible.

And actually that IS the way I feel.  With one minor exception.  When 
you do the necessary work to collect all of the pre-processor decorated 
code in one spot, surprise!  There isn't any left.

But there is really a trick to this, and it is important to understand. 
  In the military the problem is known as micro-management.  Problems 
and issues should be addressed at the right level, without solutions 
imposed from above which may not be appropriate in a particular situation.

In Ada where this often comes up is in representation clauses.  You 
either tell the compiler to "do it right" with alignment directives, or 
lay things out bit-by-bit with rep clauses.  If there is an 
implementation INdependent format you have to follow, sometimes because 
you are interfacing directly to some special-purpose hardware.  Fine, 
use static layouts.  But these are, by their nature not compiler 
dependent in any way.  The hardware you interface with, or the other 
computer system you interface with, or whatever, specifies the layout. 
If some compiler can't support those rep clauses, it is not time for 
preprocessor directives, it is time to either fix the compiler or get a 
new one.  The bits MUST look exactly like that, it is not an option.

The second case is where you want the bits laid out a certain way for 
efficiency.  Fine, no problem...and no rep clause required or needed. 
That is the compiler's job.  You may use alignment clauses and specify 
that some components are aliased, but the compiler will take all that 
into account when it lays out the record.  If two compilers do it 
differently on different hardware because, say, Integer is a different 
size?  Not a problem.  If you needed the records to be identical on 
different hardware, you would have specified things that way.

So as far as I am concerned, the case of rep specs that compile on one 
compiler and not on another is almost uninteresting.  If you care, it is 
a big problem.  But it has to be fixed by fixing (or replacing) one 
compiler.  A pre-processor CAN'T help.  If you are trying to use 
pre-processor directives to force efficient layouts on each different 
platform, you are micro-managing.  Let each compiler choose the layout 
it thinks is best.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Jeffrey Carter wrote:

> This thread is about a standard preprocessor (see the subject). But as 
> someone who has done this kind of thing without a preprocessor and 
> prefer the results, I'm convinced that what's needed is a portable way 
> to tell the compiler to use the package body from the Win32 directory, 
> or from the UNIX directory, or from the VMS directory.

Amen!  Incidently, I use symbolic links.  It is a little more 
complicated that using search paths in environment variables, but I feel 
it gives me better control.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Alexandre E. Kopilovitch]

Jeffrey Carter wrote:

> I'm convinced that what's needed is a portable way 
> to tell the compiler to use the package body from the Win32 directory, 
> or from the UNIX directory, or from the VMS directory.

A pragma for use after package's specs:

  #pragma Remote_Body (Store_Name = "Bodies");

(relegating all other to a particular compiler and its User's Guide...)

- something like this?





Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:
> Jeffrey Carter wrote:
> 
>> One standard POSIX-Ada binding 
> 
> Impossible. Some UNIces provide some API structure members,
> while others don't, or provide something else again. Yes,
> you can dumb it down to a "standard" (or omit non-universal
> functionality), but by doing so you throw away functionality.
> I find that unacceptable.

There is a standard POSIX-Ada binding (Florist is an implementation of 
this standard) to the POSIX standard. If you want something not in this 
standard, obviously you're going to have to provide it yourself on some 
platforms. If you're on a platform that doesn't provide some of the 
functionality, then it's not a POSIX system. In neither case are you 
dealing with different versions of POSIX.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Endian-Independent Rep Clauses

[Robert I. Eachus]

Jeffrey Carter wrote:

> IIRC, it addresses the fact that Default_Bit_Order is static, thanks to 
> an AI, and uses static universal math based on Boolean'Pos 
> (Default_Bit_Order = <one_of_the_choices>) to calculate bit positions. 
> I've done this kind of thing; it requires long expressions for bit 
> numbers, but works fine.

Not really, just declare:

Bits: constant := System.Bit_Order'Pos(System.Default_Bit_Order);

then go on from there.
-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Endian-Independent Rep Clauses

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Jeffrey Carter wrote:
> 
> > IIRC, it addresses the fact that Default_Bit_Order is static, thanks
> > to an AI, and uses static universal math based on Boolean'Pos
> > (Default_Bit_Order = <one_of_the_choices>) to calculate bit
> > positions. I've done this kind of thing; it requires long
> > expressions for bit numbers, but works fine.
> 
> Not really, just declare:
> 
> Bits: constant := System.Bit_Order'Pos(System.Default_Bit_Order);
> 
> then go on from there.

Here's a real-life example:

package SAL.Endianness is
   Bit_Order      : constant := 1; -- 1 or -1
   High_Bit_First : constant := 0; -- 0 or 1
   Low_Bit_First  : constant := 1; -- opposite of High_Bit_First

   --  Use one of these, corresponding to the natural size of the
   --  record you are laying out.
   LSBit_8  : constant := High_Bit_First *  7;
   LSBit_16 : constant := High_Bit_First * 15;
   LSBit_24 : constant := High_Bit_First * 23;
   LSBit_32 : constant := High_Bit_First * 31;
   LSBit_56 : constant := High_Bit_First * 55;
end SAL.Endianness;

with SAL.Endianness; use SAL.Endianness;
package body DA.Digital is

   type Analog_Collection_Mode_Type is record
      Spare_1   : Interfaces_More.Unsigned_30;
      Data      : Interfaces_More.Unsigned_2;
   end record;

   for Analog_Collection_Mode_Type use record
      Spare_1 at 0 range
        Low_Bit_First  * (LSBit_32 + Bit_Order *  2) + High_Bit_First * (LSBit_32 + Bit_Order * 31) ..
        High_Bit_First * (LSBit_32 + Bit_Order *  2) + Low_Bit_First  * (LSBit_32 + Bit_Order * 31);

      Data at 0 range
         Low_Bit_First  * (LSBit_32 + Bit_Order *  0) + High_Bit_First * (LSBit_32 + Bit_Order *  1) ..
         High_Bit_First * (LSBit_32 + Bit_Order *  0) + Low_Bit_First  * (LSBit_32 + Bit_Order *  1);

   end record;
   for Analog_Collection_Mode_Type'Size use 32;

    ...
end DA.Digital;

There is probably a way to improve the SAL.Endianness package, so I
don't need more than one. I was unable to find a smaller expression
for the rep clauses.

-- 
-- Stephe

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:e9gRb.4112$qU3.177385@news20.bellglobal.com...
> Jeffrey Carter wrote:
>
> > Warren W. Gay VE3WWG wrote:
> >
> >> Matrix 10 POSIX environments x 10 versions of the same, x 4
> >> different versions of a curses library. That leaves you with
> >> 400 different custom (possibly groups of) packages to work
> >> with. Real slick indeed. :(
> >
> > One standard POSIX-Ada binding
>
> Impossible. Some UNIces provide some API structure members,
> while others don't, or provide something else again. Yes,
> you can dumb it down to a "standard" (or omit non-universal
> functionality), but by doing so you throw away functionality.
> I find that unacceptable.

What is the point of having that functionality? Any code depending on it is
by definition not portable. If you can't abstract a reasonable facimile of
it, it probably isn't worth using. Otherwise, it will poison your whole
application, and lock it to a few targets.

What Claw does for features that aren't available on the current target is
to raise Not_Supported_Error (which hopefully the caller can do something
useful with, such as fall back to something that is supported). Thus, the
interface is as rich as possible. That probably won't work everywhere, but
if you want portability, you have to eliminate functionality that is
available only a few targets. (Which is why embedded code pretty much cannot
be portable by definition.)

               Randy.

Re: Endian-Independent Rep Clauses

[Robert I. Eachus]

Stephen Leake wrote:
...
> There is probably a way to improve the SAL.Endianness package, so I
> don't need more than one. I was unable to find a smaller expression
> for the rep clauses.

You can use the method I recommended for defining the contents of 
SAL.Endianness in a manner that derives it all from 
System.Default_Bit_Order.  Then it is really worth defining some 
additional constants there that make it easier to define some common 
fields.  i.e.

Byte1_First: constant := ....
Byte1_Last constant := ...

Then you can layout things using those constants.  The way I do it is to 
put all the cruft into one package spec, then when I need a bit position 
defined that isn't in there, I add it.  It could grow like Topsy, but I 
found that mostly I needed about a dozen values.  (But it is worth 
noting that I had two sets, one set that was right for String layouts 
and another for numbers.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Endian-Independent Rep Clauses

[Jeffrey Carter]

Stephen Leake wrote:
> 
> Here's a real-life example:
> 
> package SAL.Endianness is
>    Bit_Order      : constant := 1; -- 1 or -1
>    High_Bit_First : constant := 0; -- 0 or 1
>    Low_Bit_First  : constant := 1; -- opposite of High_Bit_First

Derive these from System.Default_Bit_Order.

I generally like to predefine a collection of useful bit numbers as well.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Develop some Open Sourced code in
> without gnatprep, and we'll see how portable it is ;-)

Here's some Q&D open source, GPLed code to solve the following 
requirments, assuming that the proposed Ada.Directories is not 
available: List the names of all the files in the current directory, 
sorted in String order (that is, the order defined by "<" for String), 
one per line.

Sure, this is a simple problem, but I don't have the time to work a 
significant problem. If you think a more complex problem should be used, 
  provide the problem and your solution to it.

All the OS and compiler dependencies are in the subunit Fill. I have 
provided a body for fill that works with GNAT 3.15p on any OS GNAT 
supports (because GNAT has already hidden the details of doing this on 
different OSes in GNAT.OS_Lib). Provide a different body for Fill for 
another compiler or OS, and explain why you need a preprocessor to do so.

It's possible to push the OS and compiler dependencies down even further 
in this example, but I don't think it's necessary.

Warning: Over 100 LOC follows. I apologize for the long posting, but am 
unable to respond to the challenge in a timely manner otherwise. Feel 
free to skip it if you like. I've used an 80-character line length, but 
some lines may wrap.

-- File Lister: a sample open-source project without a preprocessor

-- Copyright (C) 2004 by Jeffrey R. Carter

-- This is free software; you can redistribute it and/or modify it under
-- terms of the GNU General Public License as published by the Free Software
-- Foundation; either version 2, or (at your option) any later version.
-- This software is distributed in the hope that it will be useful, but WITH
-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
-- for more details. Free Software Foundation, 59 Temple Place - Suite
-- 330, Boston, MA 02111-1307, USA.

-- The root package for the File Lister software.

package File_Lister is
    pragma Pure;
end File_Lister;

-- The list must be instantiated at the library level because it uses a
-- controlled type.
-- Print_One must be declared here so we can pass its 'access to the list's
-- Iterate procedure.

with Ada.Strings.Unbounded;
with PragmARC.Assignment;
with PragmARC.List_Unbounded;
package File_Lister.Lists is
    procedure Assign is new PragmARC.Assignment
    (Element => Ada.Strings.Unbounded.Unbounded_String);

    package File_List is new PragmARC.List_Unbounded
    (Element => Ada.Strings.Unbounded.Unbounded_String);

    procedure Print_One
       (Item     : in out Ada.Strings.Unbounded.Unbounded_String;
        Context  : in out File_List.Context_Data'Class;
        Pos      : in     File_List.Position;
        Continue :    out Boolean);
    -- Print Item to standard output, followed by a line terminator.
end File_Lister.Lists;

with Ada.Text_IO;
package body File_Lister.Lists is
    procedure Print_One
       (Item     : in out Ada.Strings.Unbounded.Unbounded_String;
        Context  : in out File_List.Context_Data'Class;
        Pos      : in     File_List.Position;
        Continue :    out Boolean)
    is
       use Ada.Strings.Unbounded;
       use Ada.Text_IO;
    begin -- Print_One
       Put_Line (Item => To_String (Item));
       Continue := True;
    end Print_One;
end File_Lister.Lists;

-- Main procedure for File Lister

with Ada.Strings.Unbounded;
with File_Lister.Lists;
procedure File_Lister.Program is
    use File_Lister.Lists;

    procedure Fill (List : in out File_List.Handle) is separate;
    -- Fill List with information about the files in the current
    -- directory.

    List  : File_List.Handle;
    Dummy : File_List.Context_Data;
begin -- File_Lister.Program
    Fill (List => List);
    List.Sort (Less_Than => Ada.Strings.Unbounded."<"'access);
    List.Iterate (Action => Print_One'access, Context => Dummy);
end File_Lister.Program;

-- File_Lister.Program.Fill: version for GNAT 3.15p on all platforms.
-- Replace to accomodate other platforms or compilers.

with Ada.Strings.Unbounded;
with GNAT.Directory_Operations;
separate (File_Lister.Program)
procedure Fill (List : in out File_List.Handle) is
    use Ada.Strings.Unbounded;
    use GNAT.Directory_Operations;

    Dir  : Dir_Type;
    Name : String (1 .. 1_000);
    Last : Natural;
    Info : Unbounded_String;
    Pos  : File_List.Position;
begin -- Fill
    Open (Dir => Dir, Dir_Name => Get_Current_Dir);

    Get_All : loop
       Read (Dir => Dir, Str => Name, Last => Last);

       exit Get_All when Last <= 0;

       Info := To_Unbounded_String (Name (Name'First .. Last) );
       List.Append (Item => Info, After => List.Last, New_Pos => Pos);
    end loop Get_All;

    Close (Dir => Dir);
end Fill;

I've created lists of Unbounded_Strings exceeding 3,000 strings without 
any memory problems on a Win98 machine with 64 KB of memory, so I doubt 
there are many situations where this program will have memory problems. 
Providing error handling is left as an exercise for the reader.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Standard Ada Preprocessor

[Pascal Obry]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:

> Impossible. Some UNIces provide some API structure members,
> while others don't, or provide something else again. Yes,
> you can dumb it down to a "standard" (or omit non-universal
> functionality), but by doing so you throw away functionality.
> I find that unacceptable.

Well yet if the standard offers 99% of the functionality you need it remains
you to do the work for the remaining 1% ! Not that bad :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Endian-Independent Rep Clauses

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Stephen Leake wrote:
> ...
> > There is probably a way to improve the SAL.Endianness package, so I
> > don't need more than one. I was unable to find a smaller expression
> > for the rep clauses.
> 
> You can use the method I recommended for defining the contents of
> SAL.Endianness in a manner that derives it all from
> System.Default_Bit_Order.  

Yes, others have suggested that. I haven't found it to be worth the
time, yet.

> Then it is really worth defining some additional constants there
> that make it easier to define some common fields. i.e.
> 
> Byte1_First: constant := ....
> Byte1_Last constant := ...

Hmm. I guess Byte1_First is 8 for little endian, and Byte1_Last is 15?
But it depends on the size of the whole record for big endian, so it
can't be a constant. That's what LSBit_32 etc is for. I have LSBit_56
because I encountered a 56 bit record once.

I guess I could have Byte1_of_4_first, Byte1_of_5_first, etc.

> Then you can layout things using those constants. The way I do it is
> to put all the cruft into one package spec, then when I need a bit
> position defined that isn't in there, I add it. It could grow like
> Topsy, but I found that mostly I needed about a dozen values. (But
> it is worth noting that I had two sets, one set that was right for
> String layouts and another for numbers.)

Could you post an example from real code? Or perhaps for the record I
posted? All I get from your message is "it's possible to do better";
if I could figure it out from that, I'd have done it already :).

-- 
-- Stephe

Re: Endian-Independent Rep Clauses

[Stephen Leake]

Jeffrey Carter <spam@spam.com> writes:

> Stephen Leake wrote:
> > Here's a real-life example:
> > package SAL.Endianness is
> >    Bit_Order      : constant := 1; -- 1 or -1
> >    High_Bit_First : constant := 0; -- 0 or 1
> >    Low_Bit_First  : constant := 1; -- opposite of High_Bit_First
> 
> Derive these from System.Default_Bit_Order.

Someday I'll do that :).

> I generally like to predefine a collection of useful bit numbers as
> well.

Hmm. In the systems I've built, I haven't noticed that any one bit
number occurs more often than another; are you saying you have?

Can you post a real example of your style of rep clause? That might
help me understand your approach better.

-- 
-- Stephe

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

>>>>> "JC" == Jeffrey Carter <spam@spam.com> writes:

    JC> Warren W. Gay VE3WWG wrote:
    >> Jeffrey Carter wrote:
    >> 

    >>> One standard POSIX-Ada binding

    >> Impossible. Some UNIces provide some API structure members,

    >> while others don't, or provide something else again. Yes,
    >> you can dumb it down to a "standard" (or omit non-universal
    >> functionality), but by doing so you throw away functionality.
    >> I find that unacceptable.

    JC> There is a standard POSIX-Ada binding (Florist is an implementation of
    JC> this standard)  to the  POSIX standard. If  you want something  not in
    JC> this standard, obviously  you're going to have to  provide it yourself
    JC> on some platforms.  If you're on a platform  that doesn't provide some
    JC> of the  functionality, then it's not  a POSIX system.  In neither case
    JC> are you dealing with different versions of POSIX.

Which does not matter if what you are doing is maintaining a program
which is running on multiple platforms and is compiled with multiple
compilers. The program has to run even if the platform does not
support a standard package like Florist. How many platforms is Florist
really available on, btw.? 

What matters is how do I do this while keeping the code readable and
maintainable.

One way to combat the combinatorial explosion of platforms * compiler
* library is to explicitly test for the features of the environment
you really need to know, not assume something because of a particular
platform/compiler. This is the approach typically used by projects
using the 'configure' tool.

I would really like to have some standard configuration tool which
could take such parameters as input and produce a version of the
system tailored to the environment in which it is to be compiled and
run. 

In absence of this, I have to do the job manually, or use some kind of
preprocessing. Btw., such a configuration tool would have to keep the
exact same information internally as the condtional compilation rules
handled by the preprocessor. The only difference is that with the
preprocessor, the programmer can see the rules as part of the program
text. 


    JC> -- 
    JC> Jeff Carter
    JC> "Beyond 100,000 lines of code you
    JC> should probably be coding in Ada."
    JC> P. J. Plauger
    JC> 26


-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
: One way to combat the combinatorial explosion of platforms * compiler
: * library is to explicitly test for the features of the environment
: you really need to know, not assume something because of a particular
: platform/compiler. This is the approach typically used by projects
: using the 'configure' tool.

Only to some extent is this test possible with this approach.
Some GNU software authors must frankly tell you that unless
you use a know combination of compiler (i.e. gcc ;-) and OS (i.e.,
Unix or Wunix),
  "... non-default environments can expose bugs in the system header
   files, crippling compilation in _very_ non-obvious ways.  Because
   of that, we define them only on well-tested architectures where we
   know they will work."
(from wget config-post.h "1.9+cvs-dev")

And promtly como --c --strict lets me translate the source,
but without --remarks, it does not tell me that usleep is not
defined. So for a double argument to usleep which has been
manually range checked, the conversion to long is not done...

The configure approach has always been a nightmare for me the moment
I had to deviate from the assumptions that the configure script
is known to verify.

: I would really like to have some standard configuration tool which
: could take such parameters as input and produce a version of the
: system tailored to the environment in which it is to be compiled and
: run. 

Yes. But do you think it will ever be produced by programmers (who
like to creatively write programs)?
Collegues tell me that CM is tedious, always the same, automatic,
boring, wast of time, etc. etc., they want a DWIM procedure.
And when I answer that configuration
management, installation procedures, installation testing routines
and so one are 50% of software development, I'm on my own.

So the trick will be to turn CM into a programming problem, so
programmers and mathematicians will be instrested in solving it.


-- Georg

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
> : One way to combat the combinatorial explosion of platforms * compiler
> : * library is to explicitly test for the features of the environment
> : you really need to know, not assume something because of a particular
> : platform/compiler. This is the approach typically used by projects
> : using the 'configure' tool.
> 
> Only to some extent is this test possible with this approach.
> Some GNU software authors must frankly tell you that unless
> you use a know combination of compiler (i.e. gcc ;-) and OS (i.e.,
> Unix or Wunix),
>   "... non-default environments can expose bugs in the system header
>    files, crippling compilation in _very_ non-obvious ways.  Because
>    of that, we define them only on well-tested architectures where we
>    know they will work."
> (from wget config-post.h "1.9+cvs-dev")

Yes, you depend very much on how intelligent the configure scripts are, and you
cannot count on it being automatically portable to another platform,
but in my experience it is more portable and more readable then trying to cover
all platform/compiler/os versions explicitly.

This is from experience of developing/maintaining a > 1000 KLOC project on diverse 
platforms, like FreeBSD, Linux, AIX, HP-UX, Solaris, and Windows for several years.

> 
> And promtly como --c --strict lets me translate the source,
> but without --remarks, it does not tell me that usleep is not
> defined. So for a double argument to usleep which has been
> manually range checked, the conversion to long is not done...
> 
> The configure approach has always been a nightmare for me the moment
> I had to deviate from the assumptions that the configure script
> is known to verify.
> 

Yes, of course. As soon as you introduce new kinds of system dependencies, 
you have to revice the configure script. The hard part is figuring out
which part of your code is really system dependent. You usually find it
out by trying to port your system.

Remember the saying about there is no such thing about portable 
software, only software which has been ported :-)

> : I would really like to have some standard configuration tool which
> : could take such parameters as input and produce a version of the
> : system tailored to the environment in which it is to be compiled and
> : run. 
> 
> Yes. But do you think it will ever be produced by programmers (who
> like to creatively write programs)?
> Collegues tell me that CM is tedious, always the same, automatic,
> boring, wast of time, etc. etc., they want a DWIM procedure.
> And when I answer that configuration
> management, installation procedures, installation testing routines
> and so one are 50% of software development, I'm on my own.
> 
> So the trick will be to turn CM into a programming problem, so
> programmers and mathematicians will be instrested in solving it.
> 
> 
> -- Georg

In addition, you need it to be available without too much effort.
Isn't turning CM into a programming problem exactly what you do by using a 
preprocessor?


-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Georg Bauhaus wrote:


> So the trick will be to turn CM into a programming problem, so
> programmers and mathematicians will be instrested in solving it.

No, I think the right approach is to keep improving Ada for software 
engineers and let programmers use C++.  We are doomed to live in a world 
where most code is poorly designed.  All we can do is try to keep an 
island of sanity, and try to insure that Ada is used where quality is 
critical.  (I am not saying there is no well designed C++ out there. 
There is, but it is the exception, not something you can expect.)
-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:
> Warren W. Gay VE3WWG wrote:
> 
>> As said before, I prefer a portable platform neutral code
>> as much as the next guy. But when you start writing bindings
>> and such that must bind to _many_ different situations,
>> this simply becomes impractical.
> 
> I feel here like I am being castigated for something I have never said. 
>  (No, I am not saying Warren is attacking me, just that I have the 
> feeling that I am not getting my point across.)

It could be argued that MDC, lurkers and I are not getting
our point across ;-)

> The problem is that there is an underlying philosophical difference, and 
> until and unless you accept the "Ada" philosophy you will be 
> uncomfortable programming in Ada.  Once you "get it" Ada becomes as 
> comfortable as well broken-in shoe.  There are still some minor lumps 
> and bumps--but you don't notice them.

The "Ada phylosophy" works until you start interfacing to many
foreign components (normally C ones) that cannot be relied upon
to be the same. You cannot even rely on the same API to be
available, in some cases. This is where things get real ugly.

The practical side of many bindings, requires me to deal
with portability issues in a "C wrapper". This may not always
be entirely possible to avoid because of C macros, but I
would like to put more code into Ada than into C. But I
can't, because Ada cannot deal with the portability issues.
That is, unless I resort to processes outside of the language
(like gnatprep and code generation).

I would just like people to look at some of the "practical"
issues without resorting to quoting "ivory tower" notions.
Again, all of this would be _optional_ anyway. The military
can outlaw it for all I care, but for general purpose
computing, it needs to be addressed.

> For a second assume that there are things that do require a preprocessor 
> to do in Ada.  Now look at the long debate here, from the point of view 
> that one group uses preprocessor directives in with clauses and the 
> public part of packages, while I argue that this is poor programming 
> practice and that all preprocessor directives belong in unit bodies 
> where possible, and as few such bodies as possible.

I am not against any of these techniques. What I am against
is the notion that "no, we don't do it that way because it
might get abused". There is a need for it in the GP case,
perhaps not in the military and embedded case. But if you're
only going to do the later, than why add an Annex to deal
with COBOL interfaces and features?

> And actually that IS the way I feel.  With one minor exception.  When 
> you do the necessary work to collect all of the pre-processor decorated 
> code in one spot, surprise!  There isn't any left.

Point to some major open sourced work, where it can be
compiled and installed on Win32, Linux and many flavours
of *NIX, and I might believe this. Why is it that large
portions of Florist is generated code? I know that C macros
demand this, but what about the API issues? This says
preprocessing all over it.

> But there is really a trick to this, and it is important to understand. 
>  In the military the problem is known as micro-management.  Problems and 
> issues should be addressed at the right level, without solutions imposed 
> from above which may not be appropriate in a particular situation.

The military can make its own rules and enforce them. But again,
*sigh*, in the general purpose world, things need to be a bit
more flexible.

> In Ada where this often comes up is in representation clauses.  You 
> either tell the compiler to "do it right" with alignment directives, or 
> lay things out bit-by-bit with rep clauses.  If there is an 
> implementation INdependent format you have to follow, sometimes because 
> you are interfacing directly to some special-purpose hardware.  Fine, 
> use static layouts.  But these are, by their nature not compiler 
> dependent in any way.  The hardware you interface with, or the other 
> computer system you interface with, or whatever, specifies the layout. 
> If some compiler can't support those rep clauses, it is not time for 
> preprocessor directives, it is time to either fix the compiler or get a 
> new one.  The bits MUST look exactly like that, it is not an option.

If you are binding to an API that returns a structure, and on
one platform you get 3 members back, and on another you get 5,
then just how is any Ada construct going to address this? What
if the order of member placement is different? These are the
kind of portability issues that Ada programmers must wrestle
with when binding to existing code.

> The second case is where you want the bits laid out a certain way for 
> efficiency.  Fine, no problem...and no rep clause required or needed. 
> That is the compiler's job.  You may use alignment clauses and specify 
> that some components are aliased, but the compiler will take all that 
> into account when it lays out the record.  If two compilers do it 
> differently on different hardware because, say, Integer is a different 
> size?  Not a problem.  If you needed the records to be identical on 
> different hardware, you would have specified things that way.

Again, you look at the simple cases where everything is the
same. When dealing with portability issues, you are looking
at representation issues where the interfaces are DIFFERENT.

> So as far as I am concerned, the case of rep specs that compile on one 
> compiler and not on another is almost uninteresting.  If you care, it is 
> a big problem.  But it has to be fixed by fixing (or replacing) one 
> compiler.  A pre-processor CAN'T help.  If you are trying to use 
> pre-processor directives to force efficient layouts on each different 
> platform, you are micro-managing.  Let each compiler choose the layout 
> it thinks is best.

Your examples _are_ uninteresting. The interesting ones are the
ones that differ according to platform, platform version, and
the choice of library(ies) used.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Jeffrey Carter wrote:
>>> One standard POSIX-Ada binding 
>>
>> Impossible. Some UNIces provide some API structure members,
>> while others don't, or provide something else again. Yes,
>> you can dumb it down to a "standard" (or omit non-universal
>> functionality), but by doing so you throw away functionality.
>> I find that unacceptable.
> 
> There is a standard POSIX-Ada binding (Florist is an implementation of 
> this standard) to the POSIX standard. If you want something not in this 
> standard, obviously you're going to have to provide it yourself on some 
> platforms. If you're on a platform that doesn't provide some of the 
> functionality, then it's not a POSIX system. In neither case are you 
> dealing with different versions of POSIX.

So your message to the Ada world is that if Florist
can't give you access to that O/S feature, then you
should be using C?  That's a progressive Ada answer. ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Ole-Hjalmar Kristensen wrote:

>>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes:
>     JC> Warren W. Gay VE3WWG wrote:
>     >> Jeffrey Carter wrote:
>     >>> One standard POSIX-Ada binding
>     >> Impossible. Some UNIces provide some API structure members,
>     >> while others don't, or provide something else again. Yes,
>     >> you can dumb it down to a "standard" (or omit non-universal
>     >> functionality), but by doing so you throw away functionality.
>     >> I find that unacceptable.
>     JC> There is a standard POSIX-Ada binding (Florist is an implementation of
>     JC> this standard)  to the  POSIX standard. If  you want something  not in
>     JC> this standard, obviously  you're going to have to  provide it yourself
>     JC> on some platforms.  If you're on a platform  that doesn't provide some
>     JC> of the  functionality, then it's not  a POSIX system.  In neither case
>     JC> are you dealing with different versions of POSIX.
> 
> Which does not matter if what you are doing is maintaining a program
> which is running on multiple platforms and is compiled with multiple
> compilers. The program has to run even if the platform does not
> support a standard package like Florist. How many platforms is Florist
> really available on, btw.? 

Listen, C programmers do this thing every day. "If some feature
is available, then do it this way, else do 'it' in a more
inferior way".

Just because you write to "any platform", doesn't mean you
have to dumb down the code for all platforms. If one O/S gives
me an efficient way to do something, and I care to take
advantage of this, then I can do just that with conditional
compilation.

By saying that an Ada program would never do that, has again
condemned it to be inferior in some cases (which, IMO,
is an entirely unnecessary limitation).

> What matters is how do I do this while keeping the code readable and
> maintainable.

Of course! I could argue that conditional compilation may
make it clearer where I'd run into portability problems
on some platforms, because the different offending code
is right in front of me (vs sitting somewhere else,
unexplored).

> One way to combat the combinatorial explosion of platforms * compiler
> * library is to explicitly test for the features of the environment
> you really need to know, not assume something because of a particular
> platform/compiler. This is the approach typically used by projects
> using the 'configure' tool.

Yes, and that ./configure tool generates files that drive
a conditional compile process. But no amount of Ada if
statements can help you with conditionally with-ing certain
packages, and conditional code that have to distinguish
between the code that must work around differences and
limitations, and deal with optional members of records etc.

But this horse has been beaten to death already in this
thread, and I see no reason to expand upon it again.

> I would really like to have some standard configuration tool which
> could take such parameters as input and produce a version of the
> system tailored to the environment in which it is to be compiled and
> run. 

This is just a high level statement of what has already
been discussed. So how are you going to _implement_ this?

   1. Preprocessing?
   2. Conditional compilation?
   3. Generate source code?

The problem with #3 (which is what you seem to be suggesting)
is that when there is a compile time problem, or a maintenance
issue, you end up wanting to work with the generated files. BUT,
you know you have to remember to work with the original INPUT
files, that were used to generate it. #3 actually describes
the gnatprep case, and there are options to make it easier
to work this way (eg. an option that relates the line #
back to the one in the original input file). But every once
in a while, I end up modifying the wrong file by accident.
I hate this. Conditional compilation would be a better
solution for the developer because it is less error prone,
and it is more natural.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Georg Bauhaus wrote:
>> So the trick will be to turn CM into a programming problem, so
>> programmers and mathematicians will be instrested in solving it.
> 
> No, I think the right approach is to keep improving Ada for software 
> engineers and let programmers use C++.  

OUCH. I can't believe you said that.

Perhaps this is getting to the root of the "real" problem. ;-)

Perhaps we "lowly programmers" need to ditch Ada, and reinvent
our own flavour of the same. After all, only "lowly programmers"
would need to worry about such dirty things as portability.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:
: 
: What about address clauses to achieve overlays? 
: What about rep clauses in general? Any of these things (and more!) could 
: be criticized as leading to "Bad Software Engineering" - but they serve 
: a useful purpose and the developer is advised to use them judiciously.

(Interestingly, Controlled types disallow overlays ;-)

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> So your message to the Ada world is that if Florist
> can't give you access to that O/S feature, then you
> should be using C?  That's a progressive Ada answer. ;-)

It's impossible to correct willful ignorance. You claimed you had to 
deal with 10 different versions of "POSIX". My answer is that there is 
exactly one POSIX. If you're after things not part of POSIX, that has 
nothing to do with POSIX.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Robert I. Eachus wrote:

> No, I think the right approach is to keep improving Ada for software 
> engineers and let programmers use C++.  We are doomed to live in a world 
> where most code is poorly designed.  All we can do is try to keep an 
> island of sanity, and try to insure that Ada is used where quality is 
> critical.  (I am not saying there is no well designed C++ out there. 
> There is, but it is the exception, not something you can expect.)

What's really needed is to only allow software engineers to choose 
languages and design software. Coders can only write small, well 
specified pieces of code for the designs developed by software engineers.

The problem is distinguishing software engineers from coders and the 
economic pressures for poor quality software.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Standard Ada Preprocessor

[David Starner]

On Tue, 27 Jan 2004 13:00:31 -0500, Warren W. Gay VE3WWG wrote:
> Perhaps this is getting to the root of the "real" problem. ;-)
> 
> Perhaps we "lowly programmers" need to ditch Ada, and reinvent
> our own flavour of the same. After all, only "lowly programmers"
> would need to worry about such dirty things as portability.

My feelings too. 15 years ago, someone made a killing by releasing a
Turbo Pascal for under a hundred bucks, and made Pascal a major language.
Free software has helped drop the off-the-shelf price of a complete Un*x
system with C, C++, Pascal and Lisp compilers to under a hundred bucks.
But I still get quoted a price of $700 for an Ada compiler. Maybe that's
fine for ye system engineers, but programmers, especially we student
programmers, don't have a wealth of money to drop on compilers. Perhaps I
need to find a new hammer.

Re: Standard Ada Preprocessor

[Ludovic Brenta]

David Starner <dvdeug@email.ro> writes:

> My feelings too. 15 years ago, someone made a killing by releasing a
> Turbo Pascal for under a hundred bucks, and made Pascal a major language.
> Free software has helped drop the off-the-shelf price of a complete Un*x
> system with C, C++, Pascal and Lisp compilers to under a hundred bucks.
> But I still get quoted a price of $700 for an Ada compiler. Maybe that's
> fine for ye system engineers, but programmers, especially we student
> programmers, don't have a wealth of money to drop on compilers. Perhaps I
> need to find a new hammer.

See my post about Debian GNU/Linux :)

-- 
Ludovic Brenta.

Re: Standard Ada Preprocessor

[Georg Bauhaus]

David Starner <dvdeug@email.ro> wrote:
 
: Free software has helped drop the off-the-shelf price of a complete Un*x
: system with C, C++, Pascal and Lisp compilers to under a hundred bucks.
: But I still get quoted a price of $700 for an Ada compiler.

Hm. I see one compiler for $0, one for $195, one for EUR 8xx,
and variations on the topic. With each you can get additions,
like libraries for creating GUIs, etc. In all, from the little
I know, these products can be called "professional versions",
even without major "additions".

What do you have to pay if you want the "professional versions"
of Delphi, C++, Lisp? More in most cases.

Marketing.


-- Georg

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com...
...
> I hate this. Conditional compilation would be a better
> solution for the developer because it is less error prone,
> and it is more natural.

I couldn't disagree. Now, try to figure out a natural way to express such
conditional compilation in Ada. I can't (and I've tried to solve this
problem for 20 years.) If you don't have a non-ugly way to solve the
problem, the chances of anything being done about it are zero.

There have been similar issues with similar resolutions in the history of
Ada. For instance, you'd can't usefully redefine "*" and "/" on fixed point
types in Ada 95. The problem is well known, but without a solution, it was
never fixed in Ada 95. Tucker recently proposed a solution that appears to
work, so we'll probably fix this in Ada 200Y.

But without a workable solution, there can be no new feature. (And, because
not everyone finds this necessary, the solution needs to be clean and
well-integrated into the rest of the language.)

                    Randy.

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:fGxRb.49248$Kg6.361048@news20.bellglobal.com...
...
> Perhaps we "lowly programmers" need to ditch Ada, and reinvent
> our own flavour of the same. After all, only "lowly programmers"
> would need to worry about such dirty things as portability.

Everyone has to worry about portability. But "software engineers" use CM and
design to manage the problem, rather than trying to sweep it under a rug.
Conditional compilation, if present, would be used in very, very restricted
circumstances.

             Randy.

Re: Standard Ada Preprocessor

[Robert A Duff]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:

> The "Ada phylosophy" works until...

I'm rather skeptical of talk about "Ada philosophy".  I agree with you
and MDC that the issue is a very practical one.  It's all well and good
to recommend encapsulating system dependencies in package bodies and so
forth.  But you still need some mechanism to select which body to use in
each case.  I don't see any advantage to using make-file hackery for
that, over using #ifdef's.

The fact that some C programs are ugly due to overuse of #ifdefs is not
a good reason to outlaw preprocessors.  First of all, scattering #ifdefs
all over the place is not necessary, even in C, given a good design.
Second, if Ada had a preprocessor, it wouldn't be used as in C: to
define enumeration types, to write pragma-inline functions, to write
generics.  It would be used sparingly.

> I would just like people to look at some of the "practical"
> issues without resorting to quoting "ivory tower" notions.

I agree.

> I am not against any of these techniques. What I am against
> is the notion that "no, we don't do it that way because it
> might get abused".

I agree.  The language designer's job is to prevent mistakes,
not to prevent deliberate abuse.

- Bob

Re: Standard Ada Preprocessor

[Randy Brukardt]

"David Starner" <dvdeug@email.ro> wrote in message
news:pan.2004.01.27.18.56.15.347278@email.ro...
> On Tue, 27 Jan 2004 13:00:31 -0500, Warren W. Gay VE3WWG wrote:
> ... 15 years ago, someone made a killing by releasing a
> Turbo Pascal for under a hundred bucks, and made Pascal a major language.

About the same time, RRS offers Janus/Ada for $99. It certainly didn't make
Ada more popular... (And it should be remembered that Turbo Pascal was the
third such low priced Pascal. Anybody remember the $29 JRT Pascal that
preceded it? There's more to it than the price...)

> Free software has helped drop the off-the-shelf price of a complete Un*x
> system with C, C++, Pascal and Lisp compilers to under a hundred bucks.
> But I still get quoted a price of $700 for an Ada compiler.

For the record, you can buy Janus/Ada for as little as $195 (with only 90
days of support, and no GUI tools).

> Maybe that's
> fine for ye system engineers, but programmers, especially we student
> programmers, don't have a wealth of money to drop on compilers. Perhaps I
> need to find a new hammer.

Ada doesn't have the sort of sugar daddies that a lot of these other
languages to. So far as I know, all existing Ada compilers are produced by
companies that make substantial portions of their revenue from their Ada
development systems. Giving them away isn't going to improve the bottom
line.

For instance, here at RRS, virtually all of our revenue is from Ada
development tools. If we started to give them away for free, there would be
a number of effects: (1) Support costs would jump dramatically. With far
more users, there would be far more questions to answer and bugs to track
down. We'd have to implement a "triage" system - which is precisely what you
don't like about ACT. (2) Revenue would drop to zero - we have no other
products. We've never sold much support, probably because we answer
questions from anyone with one of our products, supported or not. (3)
Because of (1) and (2), we'd need to find another revenue source. What ever
that is, it would remove most of the resources from the Ada compiler. So the
net effect would be to completely stall development of the Ada compiler.
That's unlikely to help you or anyone else.

Your complaint really seems to boil down to not liking the policies of the
maintainer of GNAT. The obvious solution in the Open Source world is to find
another maintainer. All you have to do is figure how those people will be
funded (or convinced to do a full-time job for free).

                               Randy.

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:XdxRb.49218$Kg6.359124@news20.bellglobal.com...
...
> The "Ada phylosophy" works until you start interfacing to many
> foreign components (normally C ones) that cannot be relied upon
> to be the same. You cannot even rely on the same API to be
> available, in some cases. This is where things get real ugly.
>
> The practical side of many bindings, requires me to deal
> with portability issues in a "C wrapper". This may not always
> be entirely possible to avoid because of C macros, but I
> would like to put more code into Ada than into C. But I
> can't, because Ada cannot deal with the portability issues.
> That is, unless I resort to processes outside of the language
> (like gnatprep and code generation).

I've always thought that CM really needs to be applied on a per-line basis.
That is, you should be able to branch individual lines of a source file.
Clearly, such a system must be integrated with an editor, and should be able
to cleanly handle multiple versions of a system.

With such a system, you could cleanly manage any sort of differences without
making the source code harder to read. It's unfortunate that such systems
have never appeared in use.

                       Randy.

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com...
> ....
>>I hate this. Conditional compilation would be a better
>>solution for the developer because it is less error prone,
>>and it is more natural.
> 
> I couldn't disagree. Now, try to figure out a natural way to express such
> conditional compilation in Ada. I can't (and I've tried to solve this
> problem for 20 years.) If you don't have a non-ugly way to solve the
> problem, the chances of anything being done about it are zero.

I agree that an elegant solution should always be sought.
Especially if you are looking at the far reaching consequences
of "language changes".  But if this problem has existed for
20 years and no solution has come to light, then maybe it
is time to consider a less elegant solution?

> But without a workable solution, there can be no new feature. (And, because
> not everyone finds this necessary, the solution needs to be clean and
> well-integrated into the rest of the language.)
> 
>                     Randy.

I don't think it is a matter of "no solution exists". It is a
matter of "elegancy" as you have already stated. No one here
has come out and said "it won't work". There are simply biases
against the approaches, which vary from "Ada doesn't do it that
way" to "it's ugly". But solutions do exist.

To satisfy both camps, I would make the use of such a feature
something you have to enable (by compile option). Then by
default, you would get what you have always had.

The objection of course is that if some developers start to use
it, then someday you might have to maintain code that uses it.
But for shops that can mandate tools and conventions, you can
mandate against its use anyway. This brings us back to a matter
of preference.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> So your message to the Ada world is that if Florist
>> can't give you access to that O/S feature, then you
>> should be using C?  That's a progressive Ada answer. ;-)
> 
> It's impossible to correct willful ignorance. You claimed you had to 
> deal with 10 different versions of "POSIX". My answer is that there is 
> exactly one POSIX. If you're after things not part of POSIX, that has 
> nothing to do with POSIX.

Fine: read "POSIX-like" then. Everyone wants to be
a lawyer ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:e9gRb.4112$qU3.177385@news20.bellglobal.com...
>>Jeffrey Carter wrote:
>>>Warren W. Gay VE3WWG wrote:
>>>>Matrix 10 POSIX environments x 10 versions of the same, x 4
>>>>different versions of a curses library. That leaves you with
>>>>400 different custom (possibly groups of) packages to work
>>>>with. Real slick indeed. :(
>>>
>>>One standard POSIX-Ada binding
>>
>>Impossible. Some UNIces provide some API structure members,
>>while others don't, or provide something else again. Yes,
>>you can dumb it down to a "standard" (or omit non-universal
>>functionality), but by doing so you throw away functionality.
>>I find that unacceptable.
> 
> What is the point of having that functionality? Any code depending on it is
> by definition not portable. 

Performance!

Some platforms for instance support asynchronous I/O.
Some with bugs, others not at all. If you are writing
servers, that BTW are very performance sensitive, then
if you can determine that asynch I/O works properly
(and well) on a given platform, then you're going to
use it! Anything less is inferior.

For platforms where asynch I/O is defective or just
plain busted, you'll do things the plain old way you
always did it (with a corresponding hit in performance).

It doesn't take much imagination to see the need for
this type of thing.

> What Claw does for features that aren't available on the current target is
> to raise Not_Supported_Error (which hopefully the caller can do something
> useful with, such as fall back to something that is supported). 

That will really help performance. Let's add some unnecessary
exceptions!

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> I think the right approach is to keep improving Ada for software 
> engineers and let programmers use C++.
No, thanks. We programmers will use all the languages we see as good and
possible for our current task and circumstances. Including Visual Basic, Java,
Lisp, Smalltalk, assemblers etc., and including certainly Ada and C++.

>  We are doomed to live in a world where most code is poorly designed.
Code is man-made, and man-made things of all kinds are mostly poorly designed.

>  All we can do is try to keep an island of sanity,
Island can't be defended by itself. It was proven several times that even
good air forces cannot defend their airbases by themselves, without sufficient
support on the ground.

Certainly you know all that very well.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
>> Develop some Open Sourced code in
>> without gnatprep, and we'll see how portable it is ;-)
> 
> Here's some Q&D open source, GPLed code to solve the following 
> requirments, assuming that the proposed Ada.Directories is not 
> available: List the names of all the files in the current directory, 
> sorted in String order (that is, the order defined by "<" for String), 
> one per line.
> 
> Sure, this is a simple problem, but I don't have the time to work a 
> significant problem. If you think a more complex problem should be used, 
>  provide the problem and your solution to it.

Precisely the problem: all solutions proposed have been
towards simple problems.

Try writing a binding to curses, to run with:

   - UNIX real curses
   - GNU curses
   - PDcurses

then, make it compile and work for win2k, Linux, Solaris,
and HPUX. Do it without gnatprep or code generation.

Yes, you can dumb this assignment down to a few curses calls
and be successful at this. But try providing the full complement
of functionality for each of the above curses libraries.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Pascal Obry wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:
>>Impossible. Some UNIces provide some API structure members,
>>while others don't, or provide something else again. Yes,
>>you can dumb it down to a "standard" (or omit non-universal
>>functionality), but by doing so you throw away functionality.
>>I find that unacceptable.
> 
> Well yet if the standard offers 99% of the functionality you need it remains
> you to do the work for the remaining 1% ! Not that bad :)
> 
> Pascal.

Who guarantees that it will only be 1%? ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Robert I. Eachus wrote:

> Jeffrey Carter wrote:
> 
>> This thread is about a standard preprocessor (see the subject). 

You're right. But if you followed the thread, we progressed
from there ;-)

> But as 
>> someone who has done this kind of thing without a preprocessor and 
>> prefer the results, I'm convinced that what's needed is a portable way 
>> to tell the compiler to use the package body from the Win32 directory, 
>> or from the UNIX directory, or from the VMS directory.
> 
> Amen!  Incidently, I use symbolic links.  It is a little more 
> complicated that using search paths in environment variables, but I feel 
> it gives me better control.

Ostriches, with head in a warm sandy place.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Robert A Duff wrote:

> I'm rather skeptical of talk about "Ada philosophy".  I agree with you
> and MDC that the issue is a very practical one.  It's all well and good
> to recommend encapsulating system dependencies in package bodies and so
> forth.  But you still need some mechanism to select which body to use in
> each case.  I don't see any advantage to using make-file hackery for
> that, over using #ifdef's.

I completely and totally agree.  One of the things I love about Ada is 
the ability to avoid messing around with makefiles.

But this again totally misses what I keep saying about Ada 
pre-processors.  I don't avoid them intentionally.  It is just that if I 
get to the body of one of these implementation dependent packages, I 
usually write it using ifs and case statements planning to convert to 
#ifdefs later if needed.

This allows me to use one Ada compiler to (compile-time) debug the Ada 
code completely.  But once it compiles cleanly I don't switch to 
pre-processor directives for the fun of it.  I wait until I need it. 
I'm still waiting...

If your experience is different, fine.  But why are we arguing?  I never 
said that Ada compilers shouldn't support pre-processors, or that they 
shouldn't be used.  I just suggested waiting until it is needed.

I'm going to get back to work on some Ada code I hope to post soon. 
Again, if it needs a pre-processor to make it portable, I'll use one. 
But I don't expect it to happen.

Now if you think there should be a STANDARD Ada pre-processor, that is 
fine with me as well.  Just don't expect the ARG to develop the 
standard, form a PRG or whatever instead.  The ARG already has enough to do.

>>I am not against any of these techniques. What I am against
>>is the notion that "no, we don't do it that way because it
>>might get abused".

Definitely not my position.  I am the typical engineer.  I work very 
hard at being lazy.  So I will use whatever tools make my life easier. 
In this case, my "ivory tower notion" is that if I can do it in Ada, or 
with a pre-processor, I'll do it in Ada, even if it takes a little more 
design effort up front.  I know that when I am deep into schedule 
pressure and design changes I will thank myself.


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
> : For example, you'd pretty much have to have a different package
> : for every POSIX-like environment, because of changes like what
> : was included in the stat(2) structure (and others). Worse, you'd
> : have to matrix it out to the various releases of Linux, FreeBSD,
> : NetBSD, OpenBSD, Solaris, IRIX, HPUX etc. You cannot hope to
> : accommodate all of these differences by package names.
> 
> Not throwing in everything, (though that adds combinations no
> matter which method is chosen to deal with the variety),
> the following works for me (and also in more complex arrangements).
> I will have to make exactly two changes if I want to switch the
> OS/POSIX combination:
> 
> with OS;    -- see next
> procedure run is
> 
>    use OS.BSD;
...

But this gets back to maintaining many mostly parallel
pieces of code. For some projects, this is very
incovenient.

There I said it.

I wish for more convenience to deal with portability.

> : I get frustrated with the short sightedness of the "not invented
> : here syndrome". But maybe, that is just me. ;-)
> 
> Hm. Plan 9's C enviroment does well without #ifdefs, even though
> it has to provide this environment for different architectures.

How does this help the Ada scenario?  I am not saying that
some situations cannot be best addressed with separately
maintained packages/bodies. But it is not the best solution
for some projects that are very platform sensitive (see
earlier posts for why).

> This is reported to be confusing for those who have unfortunately
> been told to use
> 
> #if defined __THIS_HEADER__
> 
> in header files, as a replacement for a design that keeps things
> separate so multiple inclusion does not occur.

C header files are a mess. Ada packages are soooo different
from C, that we don't need to even go there. However, there
is a case to conditionally with a package, just as a C
program has a case for conditionally #include-ing.

I can't add to the plan9 case, since I've not dug too deep
into it. Unless they change their copyright restrictions,
I will not make any investment of my time there.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Simon Wright]

David Starner <dvdeug@email.ro> writes:

> My feelings too. 15 years ago, someone made a killing by releasing a
> Turbo Pascal for under a hundred bucks, and made Pascal a major
> language.  Free software has helped drop the off-the-shelf price of
> a complete Un*x system with C, C++, Pascal and Lisp compilers to
> under a hundred bucks.  But I still get quoted a price of $700 for
> an Ada compiler. Maybe that's fine for ye system engineers, but
> programmers, especially we student programmers, don't have a wealth
> of money to drop on compilers. Perhaps I need to find a new hammer.

This doesn't make sense.

The latest GCC distribution comes with C, C++, Fortran, Java, Pascal,
Python, Perl, and --- yes --- Ada. All at practically zero cost.

If I want a supported environment for any of those I will have to pay
money. For example, Dr Dobb's is advertising the Intel C++ compiler
for Linux at a special discount price of $378.

The Ada compiler for $700 is probably the Aonix one? They have a free
download too, again not supported (though they do have a mailing
list).

-- 
Simon Wright                               100% Ada, no bugs.

Re: Standard Ada Preprocessor

[Alexandre E. Kopilovitch]

Warren W. Gay wrote:

> >> So the trick will be to turn CM into a programming problem, so
> >> programmers and mathematicians will be instrested in solving it.
> > 
> > No, I think the right approach is to keep improving Ada for software 
> > engineers and let programmers use C++.  
>
> OUCH. I can't believe you said that.
But what you expected? It is exactly you who provoked that. You was given
many good explanations, but you continued to insist infinitely on your
viewpoint, without taking a break for consideration of arguments of your
opponent to good depth.

> Perhaps this is getting to the root of the "real" problem. ;-)
Certainly NO.

> Perhaps we "lowly programmers" need to ditch Ada, and reinvent
> our own flavour of the same.
This is simply nonsense. You, and even "we" simply have no skills that are
necessary for reaching anything comparable.

> After all, only "lowly programmers"
> would need to worry about such dirty things as portability.
Oh, perhaps you really need a year of real software engineering practice.
Or get a good friend of that kind. It seems that you should not rely upon your
imagination in this matter.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Ada Preprocessor

[David Starner]

On Tue, 27 Jan 2004 22:13:36 +0000, Simon Wright wrote:

> This doesn't make sense.
> 
> The latest GCC distribution comes with C, C++, Fortran, Java, Pascal,
> Python, Perl, and --- yes --- Ada. All at practically zero cost.

You're a bit confused. Python and Perl don't come with GCC, and Pascal
isn't a part of the standard GCC distribution.
 
> If I want a supported environment for any of those I will have to pay
> money.

You see two states: the free level and the supported level. Because of how
I work, I see three: the unsupported (which may cost a pretty penny, but
you won't get much direct support), the professionally supported (I've at
least heard of places where you pay huge bucks and get engineers at your
beck and call) and something in-between that a lot of free software
reaches, maybe call it the casually supported.

If I submit a bug report on the C compiler in GCC, it will get examined,
treated respectfully and it's not even inconceivable that a fix will get
backported in the release branch, either by the GCC maintainers or by the
Debian maintainers. It is high importance to all people working on most of
those compilers that they continue to run in the latest released GCC and
libc. I've submitted a documentation bug on GNAT that has not been dealt
with. There are two GCC frontends in risk of being dropped in the GCC 3.5
release because of large structural changes; Fortran 77, which has no
active maintainers, and Ada. The cumulative effect is that GNAT is
effectively unsupported, where most of the other compilers (Fortran 77
excepted) are casually supported.

As GNAT is the only Ada compiler that is Free software, that has a
negative effect on how Ada is viewed in the world of Free software, and
how a programmer who intends his programs to end up in the world of Free
software should react.

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Some platforms for instance support asynchronous I/O.
> Some with bugs, others not at all. If you are writing
> servers, that BTW are very performance sensitive, then
> if you can determine that asynch I/O works properly
> (and well) on a given platform, then you're going to
> use it! Anything less is inferior.
> 
> For platforms where asynch I/O is defective or just
> plain busted, you'll do things the plain old way you
> always did it (with a corresponding hit in performance).

If the performance on these latter systems is unacceptable, then you 
don't have a solution for those systems. If it is acceptable, then you 
have no portability problem, since you can use the plain old way on all 
systems and achieve acceptable performance. Either way you have no 
problem with or without a preprocessor.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Try writing a binding to curses, to run with:
> 
>   - UNIX real curses
>   - GNU curses
>   - PDcurses
> 
> then, make it compile and work for win2k, Linux, Solaris,
> and HPUX. Do it without gnatprep or code generation.

Where's the specification for "curses" that I'm to write a binding to? 
Clearly it's no larger than the intersection of the 3 curses packages 
you named. Where's your solution, that cannot be achieved with a 
preprocessor?

If you're asking for everything in all 3 packages, then why not say 
"Give me a binding to everything and make it compile and work on 
everything?" That's not requirements for a realistic application; 
they're pie-in-the-sky wishing for a DWIM system.

> Yes, you can dumb this assignment down to a few curses calls
> and be successful at this. But try providing the full complement
> of functionality for each of the above curses libraries.

This is your problem. Give me requirements for an application that needs 
to do X, Y, Z, and W. Show me your solution and why you think a 
preprocessor is necessary for it. Then I can show you how I can do it 
without a preprocessor.

I met your challenge. It's time to put your time where your mouth is and 
meet mine.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> Ostriches, with head in a warm sandy place.

An ad hominem attack! How nice! A sure sign of an indefensible position.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: Standard Ada Preprocessor

[Jeffrey Carter]

David Starner wrote:

> If I submit a bug report on the C compiler in GCC, it will get examined,
> treated respectfully and it's not even inconceivable that a fix will get
> backported in the release branch, either by the GCC maintainers or by the
> Debian maintainers. It is high importance to all people working on most of
> those compilers that they continue to run in the latest released GCC and
> libc. I've submitted a documentation bug on GNAT that has not been dealt
> with. There are two GCC frontends in risk of being dropped in the GCC 3.5
> release because of large structural changes; Fortran 77, which has no
> active maintainers, and Ada. The cumulative effect is that GNAT is
> effectively unsupported, where most of the other compilers (Fortran 77
> excepted) are casually supported.

It seems from this and an earlier post that you've submitted bug reports 
for C that were not dealt with, and have submitted bug reports for GNAT 
that were not dealt with. But since you've submitted bug reports for C 
that were dealt with, but have yet to submit a bug report for GNAT that 
has been dealt with, you seem to conclude that support for C is better 
than support for GNAT.

FWIW, I've submitted at least one bug report on a public version of GNAT 
that was dealt with.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: Standard Ada Preprocessor

[Georg Bauhaus]

David Starner <dvdeug@email.ro> wrote:
: 
: I've submitted a documentation bug on GNAT that has not been dealt
: with.

Where have you sent them? to report@ or to GCC's bugzilla?
Many of the handful of reports I have sent to both addresses have
been answered, sometimes with most helpful additional comments.
(I'm not a customer. One documentation bug.)
This includes reports sent only recently to GCC's Ada maintainers
via Bugzilla, with answers from people with ACT and non-ACT
addresses.


: There are two GCC frontends in risk of being dropped in the GCC 3.5
: release because of large structural changes; Fortran 77, which has no
: active maintainers, and Ada. The cumulative effect is that GNAT is
: effectively unsupported, where most of the other compilers (Fortran 77
: excepted) are casually supported.

I don't follow. GNAT, ifaik, is the GCC based compiler offered by
ACT. GCC contains an Ada front end which appears rather tightly coupled
with ACT's GNAT sources. You can check this if you look at the
extensive ChangeLog in the gcc/gcc/ada directory.


: As GNAT is the only Ada compiler that is Free software, that has a
: negative effect on how Ada is viewed in the world of Free software, and
: how a programmer who intends his programs to end up in the world of Free
: software should react.

I know of only 2 Free Software C compilers, and of one Free Software
C++ compiler. If these numbers are correct, how should they have the
opposite effect on the views of these popular languages?


--  Georg

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: 
: But this gets back to maintaining many mostly parallel
: pieces of code.

Well, yes. It is very centralised though.
The ideal scenario for me would be a declaration (using
clickable check boxes or editing text) that
effectively creates a program view. This means, I specify
what I want at a high level and the computer compiles this
into a corresponding source text view.

When I see

if <this>
context_clause_A
fi
source
source
if <this>
variant_A
else
variant_B
fi
source
source
if <this>
addition_A
fi
source

this looks like assembly language to me, with all its flexibility.
But why do we build higher level text structures and compilers?


It is interesting that programmers and in particular those
with an engineering attitude have not built machinery to solve
the problem in a high level systematic manner. Why?

There is an opportunity to sell something, or selling support,
or starting a community effort...

-- Georg

Re: Standard Ada Preprocessor

[Stephen Leake]

David Starner <dvdeug@email.ro> writes:

> ... Because of how
> I work, I see three: the unsupported (which may cost a pretty penny, but
> you won't get much direct support), the professionally supported (I've at
> least heard of places where you pay huge bucks and get engineers at your
> beck and call) 

One such place is Ada Core Technologies, the maintainers of GNAT, the
Free Software Gnu Ada compiler.

> and something in-between that a lot of free software reaches, maybe
> call it the casually supported.

Like Lynx OS, VxWorks (not free software; also not very good support).

> If I submit a bug report on the C compiler in GCC, it will get
> examined, treated respectfully and it's not even inconceivable that
> a fix will get backported in the release branch, either by the GCC
> maintainers or by the Debian maintainers. It is high importance to
> all people working on most of those compilers that they continue to
> run in the latest released GCC and libc. I've submitted a
> documentation bug on GNAT that has not been dealt with. 

As a paying customer, I get fast and excellent response from ACT. I
have submitted many bug reports.

> There are two GCC frontends in risk of being dropped in the GCC 3.5
> release because of large structural changes; Fortran 77, which has
> no active maintainers, and Ada. The cumulative effect is that GNAT
> is effectively unsupported, where most of the other compilers
> (Fortran 77 excepted) are casually supported.

I don't know where you get your information; ACT says otherwise. They
are making it a high priority to keep the Ada in the gcc distribution
working and up-to-date. Not as high a priority as satisfying paying
customers, of course. But they see a good Free Software Ada compiler
as excellent advertising for their services. In the past, they have
released public versions of GNAT, usually based on slightly old
versions of gcc. Now, they are trying to keep up with the current gcc
versions, since they see that as even better advertising.

> As GNAT is the only Ada compiler that is Free software, that has a
> negative effect on how Ada is viewed in the world of Free software,
> and how a programmer who intends his programs to end up in the world
> of Free software should react.

Getting the facts is always a good idea ...

-- 
-- Stephe

Re: Standard Ada Preprocessor

[Jeff C,]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.46.1075258237.2270.comp.lang.ada@ada-france.org...
> David Starner <dvdeug@email.ro> writes:
>
>
> > There are two GCC frontends in risk of being dropped in the GCC 3.5
> > release because of large structural changes; Fortran 77, which has
> > no active maintainers, and Ada. The cumulative effect is that GNAT
> > is effectively unsupported, where most of the other compilers
> > (Fortran 77 excepted) are casually supported.
>
> I don't know where you get your information; ACT says otherwise. They
> are making it a high priority to keep the Ada in the gcc distribution
> working and up-to-date. Not as high a priority as satisfying paying
> customers, of course. But they see a good Free Software Ada compiler
> as excellent advertising for their services. In the past, they have
> released public versions of GNAT, usually based on slightly old
> versions of gcc. Now, they are trying to keep up with the current gcc
> versions, since they see that as even better advertising.
>


Actually, he probably gets  his information from the gcc mailing list. It is
indeed true
that there is a chance (probably a good chance) that there will be no Ada
front end in
gcc 3.5 (which may actually be gcc 4.0...but that is a different matter).

That is not to say that Ada would not re-appear in 3.5.1 or 4.1. The issue
is that gcc
is getting ready to fold in a major infrastructure change that requires some
heavy modification
to the front ends. This is a major upgrade to the compiler and currently
creates a compiler
that runs a little slower but produces code that runs a little faster.  The
reason that it is still a "good thing"
is that in theory it will be easier to roll in new optimizations into the
compiler and actually make it much
better in the future.

Even the Ada maintainers on the gcc mailing list have indicated that Ada
support should not be a show
stopper for a 3.5 or 4.0 release. They have also indicated that they would
likely roll in the needed changes
at some point but that it is not a high priority.

So things are not as bad as they sound but certainly not as good as they
could be.

Re: Standard Ada Preprocessor

[David Starner]

On Tue, 27 Jan 2004 21:50:19 -0500, Stephen Leake wrote:

> As a paying customer, I get fast and excellent response from ACT. I
> have submitted many bug reports.

I'm not doubting that. 
 
>> There are two GCC frontends in risk of being dropped in the GCC 3.5
>> release because of large structural changes; Fortran 77, which has
>> no active maintainers, and Ada. The cumulative effect is that GNAT
>> is effectively unsupported, where most of the other compilers
>> (Fortran 77 excepted) are casually supported.
> 
> I don't know where you get your information; ACT says otherwise. 

In <http://gcc.gnu.org/ml/gcc/2004-01/msg00999.html>
Richard Kenner writes:

***
    > As it is today, it is impossible to build an Ada compiler with the
    > branch.

[...]

At some point in the not too distant future, the Ada front end will handle
function-at-a-time and then converting it to using tree-ssa might be
something that the tree-ssa folks can either do or help with, but I don't see
this is a major timing issue: even if we had one release of GCC (say 3.5)
that didn't support Ada, it wouldn't be fatal and should not hold up tree-ssa
if it were ready before the Ada conversion was done.

***

It's a long thread, and Robert Dewar and Richard Kenner restate that basic
point a few times.

> They
> are making it a high priority to keep the Ada in the gcc distribution
> working and up-to-date.

In <http://gcc.gnu.org/ml/gcc/2004-01/msg01970.html>
Arnaud Charlet <charlet at ACT-Europe dot FR> writes

***

[...]
Note that GCC 3.3 contains a pretty bad Ada compiler (possibly
worse than 3.2 which was not very good either), so it is not recommended
to use it for anything else than bootstrapping newer versions as
far as Ada is concerned.

***

GCC 2.95 was the first release of GCC after the EGCS branch became
mainline. There was almost four years between that release and GCC 3.3,
and they have not produced a compiler that runs on the post-EGCS code that
they consider good.

> Getting the facts is always a good idea ...

Yes, it is. 

Re: Standard Ada Preprocessor

[Dmitry A. Kazakov]

On Tue, 27 Jan 2004 16:41:50 -0500, "Warren W. Gay VE3WWG"
<warren@ve3wwg.tk> wrote:

>Randy Brukardt wrote:
>> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
>> news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com...
>> ....
>>>I hate this. Conditional compilation would be a better
>>>solution for the developer because it is less error prone,
>>>and it is more natural.
>> 
>> I couldn't disagree. Now, try to figure out a natural way to express such
>> conditional compilation in Ada. I can't (and I've tried to solve this
>> problem for 20 years.) If you don't have a non-ugly way to solve the
>> problem, the chances of anything being done about it are zero.
>
>I agree that an elegant solution should always be sought.
>Especially if you are looking at the far reaching consequences
>of "language changes".  But if this problem has existed for
>20 years and no solution has come to light, then maybe it
>is time to consider a less elegant solution?

Conditional compilation is not less elegant it is disastrous. Ada
design is based on contracts. A conditional compilation contradicts to
this very principle. What kind of contract has Foo?

#if ...
procedure Foo (X : in out Integer);
#else
type Foo is record
   X : String;
end record;
#end if

IMO the solution is abstract packages.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:

> Ole-Hjalmar Kristensen wrote:
> 
> >>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes:
> >     JC> Warren W. Gay VE3WWG wrote:
> >     >> Jeffrey Carter wrote:
> >     >>> One standard POSIX-Ada binding
> >     >> Impossible. Some UNIces provide some API structure members,
> >     >> while others don't, or provide something else again. Yes,
> >     >> you can dumb it down to a "standard" (or omit non-universal
> >     >> functionality), but by doing so you throw away functionality.
> >     >> I find that unacceptable.
> >     JC> There is a standard POSIX-Ada binding (Florist is an implementation of
> >     JC> this standard)  to the  POSIX standard. If  you want something  not in
> >     JC> this standard, obviously  you're going to have to  provide it yourself
> >     JC> on some platforms.  If you're on a platform  that doesn't provide some
> >     JC> of the  functionality, then it's not  a POSIX system.  In neither case
> >     JC> are you dealing with different versions of POSIX.
> > Which does not matter if what you are doing is maintaining a program
> > which is running on multiple platforms and is compiled with multiple
> > compilers. The program has to run even if the platform does not
> > support a standard package like Florist. How many platforms is Florist
> > really available on, btw.?
> 
> Listen, C programmers do this thing every day. "If some feature
> is available, then do it this way, else do 'it' in a more
> inferior way".
> 

For the past 20 years, I think about 90% of the code I have been writing
is C or C++, so please cool down...
I think you may have misread my answer. The sentence 
"Which does not matter if what you are doing is maintaining..." is answer to
"There is a standard POSIX-Ada binding...".

To re-state my position: It does not matter that there is a standard POSIX-Ada
binding if I am maintaining a program on a platform where this standard 
POSIX binding does not exist. I still have to get my system working, somehow.
The problem does not go away because of this standard binding.

> Just because you write to "any platform", doesn't mean you
> have to dumb down the code for all platforms. If one O/S gives
> me an efficient way to do something, and I care to take
> advantage of this, then I can do just that with conditional
> compilation.
> 
> By saying that an Ada program would never do that, has again
> condemned it to be inferior in some cases (which, IMO,
> is an entirely unnecessary limitation).
> 
> > What matters is how do I do this while keeping the code readable and
> > maintainable.
> 
> Of course! I could argue that conditional compilation may
> make it clearer where I'd run into portability problems
> on some platforms, because the different offending code
> is right in front of me (vs sitting somewhere else,
> unexplored).
> 

I never said conditional compilation was bad.

> > One way to combat the combinatorial explosion of platforms * compiler
> > * library is to explicitly test for the features of the environment
> > you really need to know, not assume something because of a particular
> > platform/compiler. This is the approach typically used by projects
> > using the 'configure' tool.
> 
> Yes, and that ./configure tool generates files that drive
> a conditional compile process. But no amount of Ada if
> statements can help you with conditionally with-ing certain
> packages, and conditional code that have to distinguish
> between the code that must work around differences and
> limitations, and deal with optional members of records etc.
> 

I agree. My point was simply that there is an alternative to test for
compiler/platform.

> But this horse has been beaten to death already in this
> thread, and I see no reason to expand upon it again.
> 
> > I would really like to have some standard configuration tool which
> > could take such parameters as input and produce a version of the
> > system tailored to the environment in which it is to be compiled and
> > run.
> 
> This is just a high level statement of what has already
> been discussed. So how are you going to _implement_ this?
> 
>    1. Preprocessing?
>    2. Conditional compilation?
>    3. Generate source code?
> 
> The problem with #3 (which is what you seem to be suggesting)
> is that when there is a compile time problem, or a maintenance
> issue, you end up wanting to work with the generated files. BUT,
> you know you have to remember to work with the original INPUT
> files, that were used to generate it. #3 actually describes
> the gnatprep case, and there are options to make it easier
> to work this way (eg. an option that relates the line #
> back to the one in the original input file). But every once
> in a while, I end up modifying the wrong file by accident.
> I hate this. Conditional compilation would be a better
> solution for the developer because it is less error prone,
> and it is more natural.
> 
> -- 
> Warren W. Gay VE3WWG
> http://ve3wwg.tk
> 

It's been a while since I worked actively with CM systems, but basically 
the idea is that you select the variant you want to work on, make your
changes, and then commit your changes to the system to integrate them with
the other variants. Yes, you easily get into problems when wanting to work
with generated files. (Unless the compiler is integrated with the CM
system in such a way that the output of the compiler is related to the 
original file, and you do not see the intermediate file at all).

What you do with a conditional compilation system is to code the exact same
information as the CM system needs to keep internally into the source code.
As you point out, sometimes it may not be desirable to hide this information,
other times it may be for the sake of easily seeing the variant you are
working on.

Please observe that I am not arguing against conditional compilation.
Given the state of the art, it may well be the best solution in a number
of circumstances.

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Standard Ada Preprocessor

[Marin David Condic]

The hiding of system/target/compiler dependent stuff in a body is all 
well and good. (I'm not convinced that it can *always* be hidden in a 
body and even if it can, that's another layer of indirection that 
sometimes starts posing unnecessary overhead for applications that might 
care about that.)

Sure, isolate it in a body. Write a monograph about how to hide 
compiler, target, OS, and other platform dependencies in a body. I'll 
try to follow it. Now give me a way to select *which* body I want via 
some standard compiler mechanism that I can count on having available. 
Shell scripts, makefiles or other build process mechanisms are simply 
pushing *that* problem off in another layer of indirection - and its a 
non-portable, uncertain layer at that.

MDC



Robert A Duff wrote:
> 
> I'm rather skeptical of talk about "Ada philosophy".  I agree with you
> and MDC that the issue is a very practical one.  It's all well and good
> to recommend encapsulating system dependencies in package bodies and so
> forth.  But you still need some mechanism to select which body to use in
> each case.  I don't see any advantage to using make-file hackery for
> that, over using #ifdef's.
> 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

Jeffrey Carter <spam@spam.com> writes:

> Warren W. Gay VE3WWG wrote:
> 
> > Some platforms for instance support asynchronous I/O.
> > Some with bugs, others not at all. If you are writing
> > servers, that BTW are very performance sensitive, then
> > if you can determine that asynch I/O works properly
> > (and well) on a given platform, then you're going to
> > use it! Anything less is inferior.
> > For platforms where asynch I/O is defective or just
> > plain busted, you'll do things the plain old way you
> > always did it (with a corresponding hit in performance).
> 
> If the performance on these latter systems is unacceptable, then you
> don't have a solution for those systems. If it is acceptable, then you
> have no portability problem, since you can use the plain old way on
> all systems and achieve acceptable performance. Either way you have no
> problem with or without a preprocessor.

Ever heard about competing products?

> 
> -- 
> Jeff Carter
> "Son of a window-dresser."
> Monty Python & the Holy Grail
> 12
> 

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Standard Ada Preprocessor

[Marin David Condic]

That would be nice. It would be even nicer if it was done in some manner 
that one could expect to exist on at least some wide variety of 
platforms. The thing is that it *isn't* available at the moment - or at 
least not in a practical way. Some kind of conditional compilation is 
not difficult to implement and *could* be available in short order. 
(Doesn't even really need the ARG - just an agreement by most of the 
vendors to use some mechanism like a pragma. The hypothetical line-level 
CM might even work by *generating* the pragma {or whatever} around the 
code.) So we could A) wait around for the world to become perfect or b) 
do something that gets a sub-optimal answer available in a reasonable 
timeframe. You could guess which I'd prefer. :-)

MDC

Randy Brukardt wrote:
> 
> 
> I've always thought that CM really needs to be applied on a per-line basis.
> That is, you should be able to branch individual lines of a source file.
> Clearly, such a system must be integrated with an editor, and should be able
> to cleanly handle multiple versions of a system.
> 
> With such a system, you could cleanly manage any sort of differences without
> making the source code harder to read. It's unfortunate that such systems
> have never appeared in use.
> 
>                        Randy.
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Marin David Condic]

David Starner wrote:
 >
 >
 > My feelings too. 15 years ago, someone made a killing by releasing a
 > Turbo Pascal for under a hundred bucks, and made Pascal a major
 > language.

It was probably more than 15 years ago - Early 1980's?


 > Free software has helped drop the off-the-shelf price of a complete
 > Un*x system with C, C++, Pascal and Lisp compilers to under a hundred
 > bucks. But I still get quoted a price of $700 for an Ada compiler.
 > Maybe that's fine for ye system engineers, but programmers,
 > especially we student programmers, don't have a wealth of money to
 > drop on compilers. Perhaps I need to find a new hammer.

In fairness, something like Gnat has forced the cost of Ada compilers
down too. Gnat is available at no cost and is of reasonable quality for
most work. And there are compilers such as MSVC++ that will come in at a
$700 price tag (or thereabouts - I've not priced it recently) as well.
So Ada is at least in the ballpark.

Where Ada may be weaker than other languages is in the area of what all
surrounds the compiler itself. Things like Java present a more "Total 
Solution" to the potential buyer.

MDC
-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Alexandre E. Kopilovitch wrote:
> Robert I. Eachus wrote:
>  
>>I think the right approach is to keep improving Ada for software 
>>engineers and let programmers use C++.
> 
> No, thanks. We programmers will use all the languages we see as good and
> possible for our current task and circumstances. Including Visual Basic, Java,
> Lisp, Smalltalk, assemblers etc., and including certainly Ada and C++.

Agreed. I was being a little flip in the comment.  My meaning was that 
programmers tend to ignore the software engineering issues raised by C++.

I expect software engineers to continue to use whichever language is 
most appropriate for the purpose.  I've probably now written more Ada 
than PL/I but it is close.  (Remember I helped develop an Ada compiler 
that ran on Multics, and then worked on Stratus VOS for a while.) C is 
probably now third instead of Fortran. Since I tend to be heavily into 
numeric/linear algebra code, I still write Fortran from time to 
time--but more C than Fortran.  I haven't written much Pascal in the 
last twenty years, but that could change.  Same for BASIC, although some 
people do use Visual BASIC for user interfaces, that is not the type of 
code I usually write. (I learned C++ and did some programming in it just 
for the experience.  In fact, I did the same thing with Prolog and a 
couple of other languages.)

I don't know if you consider SQL, XML, and HTML as a programming 
languages, but recently I have written a lot of all three.  And of 
course I have done my share of sh, csh, and Lisp programming.  I even 
programmed some numerics code in APL...

>> We are doomed to live in a world where most code is poorly designed.
> 
> Code is man-made, and man-made things of all kinds are mostly poorly designed.

That is usually referred to as Sturgeon's Law: "Sure, 90% of science 
fiction is crud. That's because 90% of everything is crud." ;-)

>> All we can do is try to keep an island of sanity,
> 
> Island can't be defended by itself. It was proven several times that even
> good air forces cannot defend their airbases by themselves, without sufficient
> support on the ground.
> 
> Certainly you know all that very well.

Of course.  Again my meaning was not that we should give up entirely, 
but that some fights were not worth fighting over and over again.  In 
fact, to restate my position:

1) There are good pre-processors available for Ada, for when you need to 
use a preprocessor with Ada.

2) There is no need for a STANDARD Ada pre-processor, because most of 
the need for that sort of thing in Ada is better done in Ada.  I'd 
rather spend my efforts in the standards area on making Ada a 99% 
solution instead of a 90% solution.

3) I have discovered lots of "tricks" that allow you to avoid using a 
pre-processor with Ada.  Here they are.  If you like, you can use them. 
  If you don't like, fine.

4) In particular, remembering that addresses in address clauses need not 
be static is a huge help.  In fact, I have sometimes put declarations 
with address clauses in inner scopes.  Then I made the addresses 
non-static according to Ada rules just so that the (unused) record 
declaration will compile with a different compiler.

Also use named numbers to make "portable" representation clauses 
tolerable. I always put the complex expressions in one package 
specification and write:

"for Some_Record_Type use
    Component_1 at Start_1 range First_Bit_1 .. Last_Bit_1;
    Component_2 at Start_2 range First_Bit_2 .. Last_Bit_2;
    Component_3 at Start_3 range First_Bit_3 .. Last_Bit_3;
    ..."

Wherever record rep clauses are needed. Of course, Start_n, First_Bit_n, 
and Last_Bit_n are named numbers (usually more descriptive) from that 
package.  That way the decision as to whether to have multiple versions 
of that one file, or use complicated (static) expressions to handle both 
little and big endian architectures can be made when I need to port the 
application to a new environment.  Having all of the numbers used in rep 
specs in one place is a big help however you manage them, so I do it 
even if I am never planning to port the code to a new compiler or OS.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Michael Bode]

Stephen Leake <stephen_leake@acm.org> writes:

> As a paying customer, I get fast and excellent response from ACT. I
> have submitted many bug reports.

Just being curious: roughly what is the price per seat for GNAT
support? I don't want to ask ACT because I'm not likely to become a
paying customer.

-- 
PGP Key: http://home.t-online.de/home/michael_bode/downloads/michael_bode.key

Re: Standard Ada Preprocessor

[Pascal Obry]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:

> Try writing a binding to curses, to run with:
> 
>    - UNIX real curses
>    - GNU curses
>    - PDcurses
> 
> then, make it compile and work for win2k, Linux, Solaris,
> and HPUX. Do it without gnatprep or code generation.

Maybe you'll call AWS a small project. It works on Windows, Linux,
Solaris, MacOS-X, FreeBSD... No gnatprep.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Standard Ada Preprocessor

[Simon Wright]

Marin David Condic <nobody@noplace.com> writes:

> Sure, isolate it in a body. Write a monograph about how to hide
> compiler, target, OS, and other platform dependencies in a
> body. I'll try to follow it. Now give me a way to select *which*
> body I want via some standard compiler mechanism that I can count on
> having available. Shell scripts, makefiles or other build process
> mechanisms are simply pushing *that* problem off in another layer of
> indirection - and its a non-portable, uncertain layer at that.

I'm probably missing the point here, but as I recall the C side of
things has a humungous incomprehensible heap of autoconf, m4, shell
scripts, GNU make only, imake .. people are happy enough with that,
where's the problem on the Ada side in selecting the right source file
variant?

I've just added support for arrays to my UML-to-Ada generator, under
pressure. I _know_ I'm going to regret it, people are just bound to
decide to (eg) implement their own associations using them rather than
rely on the built-ins .. if you give people a bad feature they will
use it badly. Of course the market rules here, shame really ..

-- 
Simon Wright                               100% Ada, no bugs.

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:KVARb.52238$Kg6.385745@news20.bellglobal.com...
> Randy Brukardt wrote:
...
> > I couldn't disagree. Now, try to figure out a natural way to express
such
> > conditional compilation in Ada. I can't (and I've tried to solve this
> > problem for 20 years.) If you don't have a non-ugly way to solve the
> > problem, the chances of anything being done about it are zero.
>
> I agree that an elegant solution should always be sought.
> Especially if you are looking at the far reaching consequences
> of "language changes".  But if this problem has existed for
> 20 years and no solution has come to light, then maybe it
> is time to consider a less elegant solution?

Updating the Ada standard is as much a political process as it is a
technical one. In this case, I and others tried to get a solution added to
Ada 95. There was too much opposition at that time. Given that nothing has
changed, I'd expect the same result if the same solutions are presented.
Indeed, we have a meta-rule that we won't even waste time on issues decided
during Ada 95's development unless there is significant new information.
(The few that have come up, like 'in out' for functions, have ended up with
precisely the same results as the last time - even with new information.)

The only new information that I could think of that would help here would be
an elegant solution. Certainly, the fact that the problem exists - or its
scope - haven't changed a bit in the last 12 years. I'm going to spend my
time on issues that have a chance to be approved (like a limited containers
library), not tilting at windmills. (I've done enough of that in the last
couple of years.)

Otherwise, you'll get have to use a non-standard solution like Gnatprep.

                Randy.

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:a%ARb.52241$Kg6.386478@news20.bellglobal.com...
> Randy Brukardt wrote:
...
> > What is the point of having that functionality? Any code depending on it
is
> > by definition not portable.
>
> Performance!
>
> Some platforms for instance support asynchronous I/O.
> Some with bugs, others not at all. If you are writing
> servers, that BTW are very performance sensitive, then
> if you can determine that asynch I/O works properly
> (and well) on a given platform, then you're going to
> use it! Anything less is inferior.

Truly high-performance applications are by definition, not portable. The
parts that aren't high-performance might be sharable, but again, this is a
larger granularity than conditional compilation would be good for. Taking
your example, you need to use tasks to make asynch. I/O work. If you don't
have asynch. I/O, you probably don't want the tasks, either (because they
have a substantial overhead in most cases), especially as the I/O may very
well block all of the tasks. So large parts of the code will need to be
different.

...
> > What Claw does for features that aren't available on the current target
is
> > to raise Not_Supported_Error (which hopefully the caller can do
something
> > useful with, such as fall back to something that is supported).
>
> That will really help performance. Let's add some unnecessary
> exceptions!

Different problem. We're trying to get the code to run unmodified on as many
targets as possible. Having it being self-adapting is very valuable in that
aim. (Hopefully, even the binarys can run on most targets unmodified.)

                             Randy.

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:r4BRb.52247$Kg6.387022@news20.bellglobal.com...
...
> Try writing a binding to curses, to run with:
>
>    - UNIX real curses
>    - GNU curses
>    - PDcurses
>
> then, make it compile and work for win2k, Linux, Solaris,
> and HPUX. Do it without gnatprep or code generation.

We had this problem with our JWindows text window library. (That was a
pre-cursor to Claw.) Our solution to this particular problem was to use none
of the above (we didn't trust the C code much anyway, particularly on SCO.),
and instead we directly intepreted the Termcap structures. That was a mess,
but it worked pretty well on all of the platforms that we tried it on.
(Which included Suns, Alphas, and the Unisaurs.)

These days, its not clear that that would work, but so what? No one in their
right mind used curses back then (late 80's) and I fail to see how that's
changed now.

                Randy.

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Pascal Obry wrote:

> Maybe you'll call AWS a small project. It works on Windows, Linux,
> Solaris, MacOS-X, FreeBSD... No gnatprep.

I wonder if the definition of a small project is like the definition of 
AI. Those who say computers can't be intelligent keep raising the bar as 
things they said a computer couldn't do are accomplished.

-- 
Jeff Carter
"What I wouldn't give for a large sock with horse manure in it."
Annie Hall
42

Re: Standard Ada Preprocessor

[Alexandre E. Kopilovitch]

Robert I. Eachus wrote:

> I don't know if you consider SQL, XML, and HTML as a programming 
> languages,
Well, 3 different answers for them:

1) HTML is not a programming language, and any attempt to make it
a programming language is fundamentally wrong;

2) SQL is controversial thing. Personally I don't see it as a programming
language, on similar ground as for RPG. Both are too fixed on purpose (this
and goal-orientation are different things).

3) about XML I'm still not sure. From its popular presentation it does not
seem a programming language; but SAX somehow changes the picture. Probably
the decisive feature is DTD, but it is not clear (at least for me) *what*
is (or may be) programmed within a DTD, and to which limits.

> 2) There is no need for a STANDARD Ada pre-processor, because most of 
> the need for that sort of thing in Ada is better done in Ada.  I'd 
> rather spend my efforts in the standards area on making Ada a 99% 
> solution instead of a 90% solution.
Ok, but there is one thing, which was mentioned by many in this thread (and
perhaps by you also): the need to have multiple bodies for a package and
to choose between them according to particular configuration. This need
certainly does not require preprocessor, but perhaps it will be good to
add some standard language construct for that - which communicates to a
compiler the fact that the body of particular package must be picked from
non-standard place. Nothing more than that - all other information (compiler
option formats etc.) need not and cannot be standardized. Something like

  pragma Remote_Body;

>From other side, I wonder, why - if something like this is really needed -
it was not already added to existing compilers as an implementation-defined
feature. Or it was?



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Standard Ada Preprocessor

[Stephen Leake]

David Starner <dvdeug@email.ro> writes:

> <snip summary of gcc thread>

Ok, thanks for the update. 

This is a typical problem with open source/bazarre development
projects. If one subgroup has significantly different goals than the
general group, they will get left out.

ACT has much higher quality goals than the general gcc group. I prefer
it that way.

-- 
-- Stephe

Re: Standard Ada Preprocessor

[Stephen Leake]

Michael Bode <m.g.bode@web.de> writes:

> Stephen Leake <stephen_leake@acm.org> writes:
> 
> > As a paying customer, I get fast and excellent response from ACT. I
> > have submitted many bug reports.
> 
> Just being curious: roughly what is the price per seat for GNAT
> support? 

I'm paying $18k per year for 5 seats. But it varies (a lot) for
different targets and hosts, and for different combinations of products.

-- 
-- Stephe

Re: Standard Ada Preprocessor

[David Starner]

On Wed, 28 Jan 2004 22:03:18 -0500, Stephen Leake wrote:

> This is a typical problem with open source/bazarre development
> projects. If one subgroup has significantly different goals than the
> general group, they will get left out.

I hardly see how this is a problem with open source. If
Microsoft had an Ada frontend to their compiler, and was looking
to replace the middle layer with a all-around superior one, do
you think they'd hesitate to release a new Visual C++ because Visual
Ada wasn't ported to the new middle end?
 
> ACT has much higher quality goals than the general gcc group. 

Any evidence for this, or is this just jingoism?

Re: Standard Ada Preprocessor

[Ole-Hjalmar Kristensen]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:a%ARb.52241$Kg6.386478@news20.bellglobal.com...
> > Randy Brukardt wrote:
> ...
> > > What is the point of having that functionality? Any code depending on it
> is
> > > by definition not portable.
> >
> > Performance!
> >
> > Some platforms for instance support asynchronous I/O.
> > Some with bugs, others not at all. If you are writing
> > servers, that BTW are very performance sensitive, then
> > if you can determine that asynch I/O works properly
> > (and well) on a given platform, then you're going to
> > use it! Anything less is inferior.
> 
> Truly high-performance applications are by definition, not portable. The
> parts that aren't high-performance might be sharable, but again, this is a
> larger granularity than conditional compilation would be good for. Taking
> your example, you need to use tasks to make asynch. I/O work. If you don't
> have asynch. I/O, you probably don't want the tasks, either (because they
> have a substantial overhead in most cases), especially as the I/O may very
> well block all of the tasks. So large parts of the code will need to be
> different.

You do not need tasks if you have asynchronous IO like the mechanisms available 
under POSIX, Solaris or Windows. You can use tasks with asynchronous IO of course,
but you do not need them.

If you do not have asynchroous IO you definitely want to use tasks, precisely
because on many (most?) platforms doing IO from one task will not block
other tasks.

Usually you get better performance with async IO than with using tasks, because
there usually will be more internal locks set in the OS, effectively stopping
you from executing multiple IO operations in parallel as efficiently as with
async IO.

> 
> ...
> > > What Claw does for features that aren't available on the current target
> is
> > > to raise Not_Supported_Error (which hopefully the caller can do
> something
> > > useful with, such as fall back to something that is supported).
> >
> > That will really help performance. Let's add some unnecessary
> > exceptions!
> 
> Different problem. We're trying to get the code to run unmodified on as many
> targets as possible. Having it being self-adapting is very valuable in that
> aim. (Hopefully, even the binarys can run on most targets unmodified.)
> 
>                              Randy.
> 

Yes, but he is trying to get the code to run unmodified on many platforms by 
making it adaptive at compile time. Same goal, different means.

> 
> 
> 

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Standard Ada Preprocessor

[Georg Bauhaus]

David Starner <dvdeug@email.ro> wrote:
: 
: Any evidence for this, or is this just jingoism?

Users of GNAT 3.15p have been able to work with 3.15p
for quite long. The 3.4 branch (not even released yet) of GCC has
an Ada front end which includes many corrections and improvements.
What is wrong with working with GCC 3.4 compilers if it is better
than 3.15p?

Latest and greatest = highest score in version number?
Versionitis.


Georg

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Alexandre E. Kopilovitch <aek@vb1162.spb.edu> wrote:
: 
: 3) about XML I'm still not sure. From its popular presentation it does not
: seem a programming language; but SAX somehow changes the picture.

XML is a well defined term, and the hint it has in its
name is "markup language". SAX stands for Simple API for XML
parsers, not a programming language.



-- Georg

Re: Standard Ada Preprocessor

[Marin David Condic]

Well, let's sum it up this way: Its possible to have a given statement 
that works in environment A but not in B. For B you need an alternate 
statement. The decision has to be made at compile time because its the 
compiler that rejects the statement, so you can't wait until runtime and 
look at some configuration parameter to decide which statement to use. 
That leaves you with these choices:

1) Have the two alternate lines in the same file & let the compiler 
decide (based on some condition) which to actually read & interpret.

2) Build your own pre-processor because the compiler writers won't do 
the job in a standard way for you - but this is really no different than 
having the compiler decide. Its still indicating in the source code 
which line to compile.

2) Have the two alternate lines in two alternate files and let the build 
process decide which to actually send to the compiler. (Substitute the 
word "line" for "file" and you see the problem is identical - just using 
different mechanisms for which line to let the compiler try to interpret.)

You aren't fundamentally changing the problem - just where it will be 
dealt with. If the argument against conditional compilation is that it 
will make ugly, incomprehensible code, then that same argument goes 
against the build process. It is, after all, some set of instructions 
that will be obeyed by the computer and hence a kind of programming 
language, so giving *it* the responsibility is just going to result in 
ugly, incomprehensible code at the build level. Only it won't be 
portable and you can't count on it being there and someone who doesn't 
know what's going on with the different bodies of code is likely to 
bugger it up. Not to mention the other related maintenance problems such 
as not having all the code relating to one specific conceptual function 
in one place - the "unnormalized database" situation described (I think) 
by Warren.

So worrying about adding a feature that has the potential to be abused 
is, in my mind, a non-starter. The feature *will* be added *somewhere* 
so long as people have to manage code that must work in more than one 
environment. One camp says "Your life will be so much better if only you 
push that problem off to the build process level rather than the source 
code level." Another camp says "I've been there and done that and I 
think that at least some of the time, I'd rather deal with that problem 
at the source code level".

The problem is inherently unpleasant no matter which way you go. But you 
*will* have to deal with it and IMHO, *sometimes* I want to deal with it 
at the source code level because it creates the fewest headaches for me. 
The fact that someone might abuse it is also a non-starter. People can 
abuse *anything* in a programming language. (Look at the religious wars 
over using something like the predefined type "Integer" - some think its 
handy and convenient and others think it is apostasy and should never be 
used at all under any circumstances. Yet its in the language and Ada 
programs are probably still better built on average than those in some 
other languages. Life goes on in an imperfect world.)

MDC



Simon Wright wrote:
> 
> I'm probably missing the point here, but as I recall the C side of
> things has a humungous incomprehensible heap of autoconf, m4, shell
> scripts, GNU make only, imake .. people are happy enough with that,
> where's the problem on the Ada side in selecting the right source file
> variant?
> 
> I've just added support for arrays to my UML-to-Ada generator, under
> pressure. I _know_ I'm going to regret it, people are just bound to
> decide to (eg) implement their own associations using them rather than
> rely on the built-ins .. if you give people a bad feature they will
> use it badly. Of course the market rules here, shame really ..
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Marin David Condic]

Its odd how the whole "Open Source" movement was supposed to avoid rigid 
heierarchies and "let a hundred flowers bloom" so to speak. Everyone 
would be free to do what they wanted and there would be all sorts of 
variations on software products and everything would be so beautiful. 
But once Open Source products get out there, they rather quickly have to 
re-invent the whole heierarchy and rigid control that quashes individual 
variants. Irony runs rampant! :-)

MDC

Stephen Leake wrote:

> 
> This is a typical problem with open source/bazarre development
> projects. If one subgroup has significantly different goals than the
> general group, they will get left out.



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Preben Randhol]

On 2004-01-29, Marin David Condic <nobody@noplace.com> wrote:
> Its odd how the whole "Open Source" movement was supposed to avoid rigid 
> heierarchies and "let a hundred flowers bloom" so to speak. Everyone 

No, it wasn't. You are confusing it with the Bazaar model which is something
else entirely.



-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:

> On Tue, 27 Jan 2004 16:41:50 -0500, "Warren W. Gay VE3WWG"
> <warren@ve3wwg.tk> wrote:
>>Randy Brukardt wrote:
>>>"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
>>>news:ZwxRb.49242$Kg6.360396@news20.bellglobal.com...
>>>....
> Conditional compilation is not less elegant it is disastrous. Ada
> design is based on contracts. A conditional compilation contradicts to
> this very principle. What kind of contract has Foo?
> 
> #if ...
> procedure Foo (X : in out Integer);
> #else
> type Foo is record
>    X : String;
> end record;
> #end if
> 
> IMO the solution is abstract packages.

I have presented the case as far as I have energy for it.
The discussions here have lead me to conclude that I'll
have to blaze my own trail (with help from gnatprep), as
I have always had to do. I never expected much
agreement on this anyway. It was however, interesting to
hear that I am not the only one to share this opinion.

Having said my piece on this, and I'm signing off.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:KVARb.52238$Kg6.385745@news20.bellglobal.com...
>>Randy Brukardt wrote:
> ....
>>>I couldn't disagree. Now, try to figure out a natural way to express
> such
>>>conditional compilation in Ada. I can't (and I've tried to solve this
>>>problem for 20 years.) If you don't have a non-ugly way to solve the
>>>problem, the chances of anything being done about it are zero.
>>
>>I agree that an elegant solution should always be sought.
>>Especially if you are looking at the far reaching consequences
>>of "language changes".  But if this problem has existed for
>>20 years and no solution has come to light, then maybe it
>>is time to consider a less elegant solution?
> 
> Updating the Ada standard is as much a political process as it is a
> technical one. In this case, I and others tried to get a solution added to
> Ada 95. There was too much opposition at that time. Given that nothing has
> changed, I'd expect the same result if the same solutions are presented.
> Indeed, we have a meta-rule that we won't even waste time on issues decided
> during Ada 95's development unless there is significant new information.
> (The few that have come up, like 'in out' for functions, have ended up with
> precisely the same results as the last time - even with new information.)

I can only agree with this. Please understand, that this was
not a discussion that "we should include X in 200Y". That is
too much further down the road. The discussion stemmed from
the wider context of "Why is Ada Unpopular?"  I then wanted
to discuss the merits of addressing conditional compilation.

To say that it was ready for a proposal, would be naive ;-)

But the discussion here was useful. In my mind, unless
the general concensous changes, there does not seem to be
an acceptable solution to the majority on this topic.
But as I said in another post, it was interesting to
note from others that agreed there was a need to be
addressed there.

> The only new information that I could think of that would help here would be
> an elegant solution. Certainly, the fact that the problem exists - or its
> scope - haven't changed a bit in the last 12 years. 

To this I was only suggesting that if an elegant solution
does not emerge in 12-20 years, then perhaps there is
none. And if this is the conclusion, then perhaps it is
time to lower the "standard" a bit, to address practical
needs.

 > I'm going to spend my
> time on issues that have a chance to be approved (like a limited containers
> library), not tilting at windmills. (I've done enough of that in the last
> couple of years.)
> 
> Otherwise, you'll get have to use a non-standard solution like Gnatprep.
> 
>                 Randy.

A sensible thing to do. ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Ole-Hjalmar Kristensen wrote:
> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> writes:
>>Ole-Hjalmar Kristensen wrote:
>>>>>>>>"JC" == Jeffrey Carter <spam@spam.com> writes:
>>>
>>>    JC> Warren W. Gay VE3WWG wrote:
>>>    >> Jeffrey Carter wrote:
>>>    >>> One standard POSIX-Ada binding
>>>    >> Impossible. Some UNIces provide some API structure members,
>>>    >> while others don't, or provide something else again. Yes,
>>>    >> you can dumb it down to a "standard" (or omit non-universal
>>>    >> functionality), but by doing so you throw away functionality.
>>>    >> I find that unacceptable.
>>>    JC> There is a standard POSIX-Ada binding (Florist is an implementation of
>>>    JC> this standard)  to the  POSIX standard. If  you want something  not in
>>>    JC> this standard, obviously  you're going to have to  provide it yourself
>>>    JC> on some platforms.  If you're on a platform  that doesn't provide some
>>>    JC> of the  functionality, then it's not  a POSIX system.  In neither case
>>>    JC> are you dealing with different versions of POSIX.
>>>Which does not matter if what you are doing is maintaining a program
>>>which is running on multiple platforms and is compiled with multiple
>>>compilers. The program has to run even if the platform does not
>>>support a standard package like Florist. How many platforms is Florist
>>>really available on, btw.?
>>
>>Listen, C programmers do this thing every day. "If some feature
>>is available, then do it this way, else do 'it' in a more
>>inferior way".
> 
> For the past 20 years, I think about 90% of the code I have been writing
> is C or C++, so please cool down...

I am calmer today ;-)

> I think you may have misread my answer. The sentence 
> "Which does not matter if what you are doing is maintaining..." is answer to
> "There is a standard POSIX-Ada binding...".
> 
> To re-state my position: It does not matter that there is a standard POSIX-Ada
> binding if I am maintaining a program on a platform where this standard 
> POSIX binding does not exist. I still have to get my system working, somehow.
> The problem does not go away because of this standard binding.

Ok, yes. And my original point was that Florist does not
cover all of your POSIX-like needs anyway. To get equal
footing with C/C++ environments, you need Ada bindings to
all of the shared libraries that GNU/Linux provides
for example. As you understand, this is where things
get necessarily ugly.

>>>What matters is how do I do this while keeping the code readable and
>>>maintainable.
>>
>>Of course! I could argue that conditional compilation may
>>make it clearer where I'd run into portability problems
>>on some platforms, because the different offending code
>>is right in front of me (vs sitting somewhere else,
>>unexplored).
> 
> I never said conditional compilation was bad.

I'll reiterate that readable code is first on my list
also. But I would like the choice to forgo that for
thin bindings. I don't there there is much justification
for it outside of thin bindings.

...
> Please observe that I am not arguing against conditional compilation.
> Given the state of the art, it may well be the best solution in a number
> of circumstances.

Which was really my thrust in this thread. If an elegant
solution has not emerged, then it is time to look at the
"requirments" for such. One of them is suspect ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:

> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:a%ARb.52241$Kg6.386478@news20.bellglobal.com...
>>Randy Brukardt wrote:
> ....
>>>What is the point of having that functionality? Any code depending on it
> is
>>>by definition not portable.
>>
>>Performance!
>>
>>Some platforms for instance support asynchronous I/O.
>>Some with bugs, others not at all. If you are writing
>>servers, that BTW are very performance sensitive, then
>>if you can determine that asynch I/O works properly
>>(and well) on a given platform, then you're going to
>>use it! Anything less is inferior.
> 
> Truly high-performance applications are by definition, not portable. 

This is a "head in the sand" argument, if I may say so. C/C++
code does this every day. To say that Ada shouldn't or needn't
is statement of denial. That is my only point.

>>>useful with, such as fall back to something that is supported).
>>
>>That will really help performance. Let's add some unnecessary
>>exceptions!
> 
> 
> Different problem. We're trying to get the code to run unmodified on as many
> targets as possible. Having it being self-adapting is very valuable in that
> aim. (Hopefully, even the binarys can run on most targets unmodified.)
> 
>                              Randy.

This is like probing hardware when Linux boots. Hardware is
getting better, so that probes don't hang etc., but this adds
time to the boot process, and for some hardware configs, is
unstable and leads to hangs.

Testing a version of a Linux kernel for a working asynch I/O
API or not, seems much like the same thing. Its ugly, its
dangerous and leads to more problems than it solves. It is
much better to work all of that out at compile time, and never
deal with it again.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Try writing a binding to curses, to run with:
>>
>>   - UNIX real curses
>>   - GNU curses
>>   - PDcurses
>>
>> then, make it compile and work for win2k, Linux, Solaris,
>> and HPUX. Do it without gnatprep or code generation.
> 
> Where's the specification for "curses" that I'm to write a binding to? 
> Clearly it's no larger than the intersection of the 3 curses packages 
> you named. Where's your solution, that cannot be achieved with a 
> preprocessor?

The idea is to put the Ada programmer on an even keel with
the C/C++ programmer on the same platform. If from C you
can call GNU curses API xyz (or functionality provided by xyz),
they by George, it would be nice for the Ada program to take
advantage of the same feature (caveat: thick bindings do not
always make this comparison trivial, but think functionality).

By the same token, xyz may not be available to the PDcurses
programmer on some or all platforms. Win32 may be more restricted
for example.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> "Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
> news:r4BRb.52247$Kg6.387022@news20.bellglobal.com...
> ....
>>Try writing a binding to curses, to run with:
>>
>>   - UNIX real curses
>>   - GNU curses
>>   - PDcurses
>>
>>then, make it compile and work for win2k, Linux, Solaris,
>>and HPUX. Do it without gnatprep or code generation.
> 
> We had this problem with our JWindows text window library. (That was a
> pre-cursor to Claw.) Our solution to this particular problem was to use none
> of the above (we didn't trust the C code much anyway, particularly on SCO.),
> and instead we directly intepreted the Termcap structures. That was a mess,
> but it worked pretty well on all of the platforms that we tried it on.
> (Which included Suns, Alphas, and the Unisaurs.)

Well, I would agree that the ideal solution would be to
rewrite all GNU libraries in Ada. I would agree that a
POSIX kernel in Ada would be nice (or AdaOS). But until
that happens, I don't have the luxury of rewriting
everything ;-)

> These days, its not clear that that would work, but so what? No one in their
> right mind used curses back then (late 80's) and I fail to see how that's
> changed now.
> 
>                 Randy.

Curses is far from dead. There are still a large number of
text mode terminals used around the globe.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Marin David Condic wrote:

> You aren't fundamentally changing the problem - just where it will be 
> dealt with. If the argument against conditional compilation is that it 
> will make ugly, incomprehensible code, then that same argument goes 
> against the build process. It is, after all, some set of instructions 
> that will be obeyed by the computer and hence a kind of programming 
> language, so giving *it* the responsibility is just going to result in 
> ugly, incomprehensible code at the build level. 

There's a general SW engineering principle called localization. You 
don't lump your code for dealing with a 4-line LCD display in with the 
code for dealing with a temperature sensor just because they're both 
hardware. Similarly, you shouldn't want your code for doing something 
platform dependent on one platform lumped in with your code for another 
platform, nor your code for doing things lumped in with your code for 
deciding which code to use for this build.

Separating concerns this way makes everything easier to understand. I 
can look at the code for dealing with a VMS file system without having 
to understand the code for selecting a VMS file system; I can look at 
the code for selecting the file system without having to look at the 
code for dealing with file systems.

That said, it would be nice to have a standard, portable way to select 
different bodies for a build, but even without it, the advantages of 
separating these independent concerns seem clear.

-- 
Jeff Carter
"Many times we're given rhymes that are quite unsingable."
Monty Python and the Holy Grail
57

Re: Standard Ada Preprocessor

[David Starner]

On Thu, 29 Jan 2004 11:14:20 +0000, Georg Bauhaus wrote:

> Latest and greatest = highest score in version number?
> Versionitis.

Using the version of the GNAT compiler that comes with my distribution,
and hence the one that matches the latest C compiler has many advantages.
If I have an obscure code generation bug on little endian MIPS or some
other obscure architecture, it's probably not one that C and C++
programmers have already found and got fixed, and it may get fixed without
switching major compiler versions. I'm able to compile on a larger
percentage of the architectures that my C colleagues can, due to people
porting GNAT on GCC-head instead of an ancient branch, and due to the
number of architectures that were added to new GCC. Also, some of the Ada
libraries come precompiled for the GNAT version that comes with my
distribution, and the Ada compiler and debuggers and other programs are
tested against that version of GCC and the distribution. Old versions of
GNAT do not support the libc I'm using, for one thing.

Re: Standard Ada Preprocessor

[Georg Bauhaus]

David Starner <dvdeug@email.ro> wrote:
: On Thu, 29 Jan 2004 11:14:20 +0000, Georg Bauhaus wrote:
: 
:> Latest and greatest = highest score in version number?
:> Versionitis.
: 
: Using the version of the GNAT compiler that comes with my distribution,
: and hence the one that matches the latest C compiler has many advantages.

I don't understand the "hence".

:  I'm able to compile on a larger
: percentage of the architectures

the ancient obscure ones you mentioned?

: that my C colleagues can, due to people
: porting GNAT on GCC-head instead of an ancient branch, and due to the
: number of architectures that were added to new GCC.

I gather then that this is not a personal computer architecture?
If not, a handheld? A cell phone?
If you will be developing software for sale for one of the
new million sellers, might not some support be very helpful?

: Also, some of the Ada
: libraries come precompiled for the GNAT version that comes with my
: distribution, and the Ada compiler and debuggers and other programs are
: tested against that version of GCC and the distribution. Old versions of
: GNAT do not support the libc I'm using, for one thing.

True. But you aren't saying that GCC 3.4 is old when it is not yet
released or that it is old in a year or so?


-- georg

Re: Standard Ada Preprocessor

[Simon Wright]

Marin David Condic <nobody@noplace.com> writes:

> 1) Have the two alternate lines in the same file & let the compiler
> decide (based on some condition) which to actually read & interpret.

The point I was fumbling towards is that you now have _two_
complicated things, probably:

* the external autoconf or whatever setup that decides from the
  environment whether some feature is present and sets the result in
  environment variables, a config.h or a makefile;

* and the source code that uses the condition.

-S

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7visiufpr5.fsf@smaug.pushface.org...
> Marin David Condic <nobody@noplace.com> writes:
>
> > 1) Have the two alternate lines in the same file & let the compiler
> > decide (based on some condition) which to actually read & interpret.
>
> The point I was fumbling towards is that you now have _two_
> complicated things, probably:
>
> * the external autoconf or whatever setup that decides from the
>   environment whether some feature is present and sets the result in
>   environment variables, a config.h or a makefile;
>
> * and the source code that uses the condition.

Right. There is no such thing as a compile-time solution that doesn't change
some code or management artifact like build scripts. If you're using
conditional compilation, you have to set the choice of which to use
somewhere. You're going to have to manage that code or scripts with some
form of configuration management per configuration. You cannot avoid this
part of the problem on anything but the tiniest one-person projects (where
you might actually be able to remember a bucket of special command-line
switches - but as I get older, I find I can't even do that anymore...). So,
given that you have a solution to the managment of separate code/build
scripts, why would you not apply it to managing separate specs and bodies?
And clearly, separate implementation-dependent code is always preferable
(and don't forget that subunits also can be used to keep
implementation-dependent stuff separate).

There are cases where Ada's existing conditional compilation doesn't work
(or makes the code much harder to read), but they're rare enough that going
further is a very tough sell.

                          Randy.

Re: Standard Ada Preprocessor

[Randy Brukardt]

"Warren W. Gay VE3WWG" <warren@ve3wwg.tk> wrote in message
news:qQbSb.57519$Kg6.643416@news20.bellglobal.com...
> Randy Brukardt wrote:
...
> > Different problem. We're trying to get the code to run unmodified on as
many
> > targets as possible. Having it being self-adapting is very valuable in
that
> > aim. (Hopefully, even the binarys can run on most targets unmodified.)
> >
>
> This is like probing hardware when Linux boots. Hardware is
> getting better, so that probes don't hang etc., but this adds
> time to the boot process, and for some hardware configs, is
> unstable and leads to hangs.
>
> Testing a version of a Linux kernel for a working asynch I/O
> API or not, seems much like the same thing. Its ugly, its
> dangerous and leads to more problems than it solves. It is
> much better to work all of that out at compile time, and never
> deal with it again.

I would be likely to base the decision whether or not to use a feature (say
asynch I/O) on the version information provided by the kernel. (I'm
presuming that Linux isn't so primitive that it doesn't have
version/distribution/supported features queries.) Plus, of course, lots of
upfront testing. Thus, the same info that you're using at compile-time would
be used to choose which implementation to use.

I readily admit that doing this is easier on Windows, where the number of
versions is somwhat bounded, and it's possible to get information (not
always right, of course) in one place. (Window emulators always try to match
the real thing as closely as possible, so they tend to be less incompatible
than the different versions of the real thing...)

                      Randy.

Re: Standard Ada Preprocessor

[Chad R. Meiners]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:101gi766nkf57b6@corp.supernews.com...
> These days, its not clear that that would work, but so what? No one in
their
> right mind used curses back then (late 80's) and I fail to see how that's
> changed now.

I always thought they called it curses due to the foul language I used when
trying to get it to work properly ;-)

Win32 console API's on the other hand are a dream compared to my experience
with curses ;-)

-CRM

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Preben Randhol wrote:

> No, it wasn't. You are confusing it with the Bazaar model which is something
> else entirely.

And most people who have read "The Cathedral and the Bazaar" prefer the 
Cathedral approach for operating systems kernels (look at Linux) and 
compilers (such as GCC and GNAT).

One person, Linus Torvalds, approves all additions and changes to the 
Linux kernel.  That doesn't mean that the Cathedral model is used fof 
the rest of Linux, in fact there are many developers and teams working 
on the same and different parts of Linux.  But having one kernel chain, 
and controlled releases of new versions allows the rest of Linux to use 
the Bazaar model.

I won't even try to describe the problems with GCC that occured recently 
due to a forking of the compiler development chains, but by the end of 
this year I hope we will all be back to a single gcc chain.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Randy Brukardt wrote:

> Updating the Ada standard is as much a political process as it is a
> technical one. In this case, I and others tried to get a solution added to
> Ada 95. There was too much opposition at that time. Given that nothing has
> changed, I'd expect the same result if the same solutions are presented.
> Indeed, we have a meta-rule that we won't even waste time on issues decided
> during Ada 95's development unless there is significant new information.
> (The few that have come up, like 'in out' for functions, have ended up with
> precisely the same results as the last time - even with new information.)
> 
> The only new information that I could think of that would help here would be
> an elegant solution. Certainly, the fact that the problem exists - or its
> scope - haven't changed a bit in the last 12 years. I'm going to spend my
> time on issues that have a chance to be approved (like a limited containers
> library), not tilting at windmills. (I've done enough of that in the last
> couple of years.)
> 
> Otherwise, you'll get have to use a non-standard solution like Gnatprep.

What Randy says is 100% correct.  There is a lot of work invovled in 
updating a language standard, and this time around there is no full-time 
team working on Ada 0Y, so things that didn't make the cut in Ada 9X are 
even less likely to get in this time.

However, having said that, I will continue to work on making it easier 
to use Ada in place of a pre-processor language.  The main requirements 
for that, as they have been all along, are major goals of the Ada 
community.  As long as there is "only one Ada," and Ada compilers do 
static code elimination, then it is possible to use Ada if and case 
statements for conditional code.

Yes, I know that there are some things you can't do this way.  But I 
haven't found them to be a big deal.  For example, if I have numeric 
code that uses 32 and 36-bit integers depending on target, I know how to 
define a portable integer type that doesn't require creating a 36-bit 
integer type on hardware that doesn't support it.

Floating-point is a bit harder, but there what really changes is whether 
there is a type with more precision than IEEE double, and what it is 
called. That IS a case where I do have multiple bodies, but since the 
code for machines that support IEEE extended and those that don't is 
totally different, I don't mind mantaining separate bodies.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Standard Ada Preprocessor

[Marin David Condic]

I don't think I've ever said that it was "bad" to localize dependencies 
and try to isolate this stuff. Quite the contrary. But if you could 
scatter system dependencies all over the code or scatter conditional 
compilation all over the code, why couldn't it be done all over the 
whole system, just at the file level? Why couldn't a project of 100 
files have 50 for one system and 50 for another system and not have 
anything "localized" in that sense? So my contention is that it can be 
abused no matter where you push the problem.

Often system dependencies are *not* isolated - people write code all the 
time that works for only one system. Good, bad or somewhere in between - 
its still done. Offering some kind of conditional compilation doesn't 
really change that much.

That said, I'd be inclined to agree that perhaps the problem could be 
solved with some portable means of selecting different bodies for a 
build. Its a reasonable compromise that at least tends to encourage 
isolation of dependencies at some appropriate level. I don't know that 
it solves *every* problem, but it probably fixes enough of them that the 
rest wouldn't matter much.

Remember that one of the big strengths of Ada is its assistance on 
making *portable* code by providing strong *standard* mechanisims for 
dealing with system dependencies. Everything from specifying numeric 
accuracy up through tasking is an attempt to say "If the implementation 
is compliant to the standard, you go compile for the platform and your 
code will work." Providing a mechanism for dealing with compile-time 
dependencies is just going down that same path a little further.


MDC

Jeffrey Carter wrote:
> 
> There's a general SW engineering principle called localization. You 
> don't lump your code for dealing with a 4-line LCD display in with the 
> code for dealing with a temperature sensor just because they're both 
> hardware. Similarly, you shouldn't want your code for doing something 
> platform dependent on one platform lumped in with your code for another 
> platform, nor your code for doing things lumped in with your code for 
> deciding which code to use for this build.
> 
> Separating concerns this way makes everything easier to understand. I 
> can look at the code for dealing with a VMS file system without having 
> to understand the code for selecting a VMS file system; I can look at 
> the code for selecting the file system without having to look at the 
> code for dealing with file systems.
> 
> That said, it would be nice to have a standard, portable way to select 
> different bodies for a build, but even without it, the advantages of 
> separating these independent concerns seem clear.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Marin David Condic]

I never said it was pretty. :-) I just said that the problem of dealing 
with compiler dependencies, environment dependencies and system 
dependencies is real and that we don't seem to have a really good 
portable answer to it sometimes. I'm suggesting there might be something 
the language could do to make dealing with that easier - if not 
prettier. I'm open to suggestions.

MDC

Simon Wright wrote:
> 
> The point I was fumbling towards is that you now have _two_
> complicated things, probably:
> 
> * the external autoconf or whatever setup that decides from the
>   environment whether some feature is present and sets the result in
>   environment variables, a config.h or a makefile;
> 
> * and the source code that uses the condition.
> 
> -S


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Marin David Condic]

That's a fair point. No matter what you do, you'll have to have some 
kind of "outside the language" mechanism for specifying which path you 
want to go down and that isn't under the control of the language.

But do consider this: Something like "gnatmake" has pretty much 
eliminated for me needing to worry about build scripts in most 
situations. The *language* goes out and figures out what is out of date 
and what needs to be included in the build. So long as I can point to a 
single pile of files and say "there's a build in there somewhere - you 
go figure it out...", Ada does a marvelous job with it. Compared to C, 
this is a major improvement in many respects.

So it might not be that much of a stretch to ask something like gnatmake 
to go decide which way to branch in selecting files from two or more 
alternate paths within that pile of files. Something as simple as saying 
'gnatmake -buildstring="Go Down Path A"' might be sufficient so long as 
there was some way of picking up the "Path A" variants of files via some 
language mechanism so that I knew I could take the same pile of files 
and hand them off to Janus Ada or Aonix or any other compliant compiler 
and know that someone with little familiarity with my pile of code could 
use minimal instructions and direct an appropriate build for his platform.

It all goes to enhancing Ada's ability to be "The Portability Language". 
It already does so much in that respect that I think its a shame it 
can't seem to find a way to get around the fact that no two compilers or 
environments are ever going to be identical. "Outside The Language" 
solutions exist - but then we're no better than C (or other languages) 
in that regard. In some ways worse since at least C provides a (maybe at 
times ugly) way of directing the compiler down alternate paths.

MDC

Randy Brukardt wrote:
> 
> Right. There is no such thing as a compile-time solution that doesn't change
> some code or management artifact like build scripts. If you're using
> conditional compilation, you have to set the choice of which to use
> somewhere. You're going to have to manage that code or scripts with some
> form of configuration management per configuration. You cannot avoid this
> part of the problem on anything but the tiniest one-person projects (where
> you might actually be able to remember a bucket of special command-line
> switches - but as I get older, I find I can't even do that anymore...). So,
> given that you have a solution to the managment of separate code/build
> scripts, why would you not apply it to managing separate specs and bodies?
> And clearly, separate implementation-dependent code is always preferable
> (and don't forget that subunits also can be used to keep
> implementation-dependent stuff separate).
> 
> There are cases where Ada's existing conditional compilation doesn't work
> (or makes the code much harder to read), but they're rare enough that going
> further is a very tough sell.
> 
>                           Randy.
> 
> 
> 
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Pascal Obry]

Marin,

> The hiding of system/target/compiler dependent stuff in a body is all well
> and good. (I'm not convinced that it can *always* be hidden in a body and
> even if it can, that's another layer of indirection that sometimes starts
> posing unnecessary overhead for applications that might care about that.)

Pragma Inline could be used to avoid that.

> Sure, isolate it in a body. Write a monograph about how to hide compiler,
> target, OS, and other platform dependencies in a body. I'll try to follow
> it. Now give me a way to select *which* body I want via some standard
> compiler mechanism that I can count on having available.

:) You know that this is not portable. Ada has nothing to do with file system
and configuration management.

> Shell scripts, makefiles or other build process mechanisms are simply
> pushing *that* problem off in another layer of indirection - and its a
> non-portable, uncertain layer at that.

I do this with a makefile, lot of GNU software are doing that from a configure
script. Using ClearCase you can use a specific view for the target/OS/hardward
whatever you want the view to me... But I repeat this is not a compiler issue
but a Configuration Management one. Use the on that best fits for your
project.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> Warren W. Gay VE3WWG wrote:
> 
>> Ostriches, with head in a warm sandy place.
> 
> An ad hominem attack! How nice! A sure sign of an indefensible position.

Fair enough. I hear that ostrich meat is tasty ;-)

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
> : 
> : But this gets back to maintaining many mostly parallel
> : pieces of code.
> 
> Well, yes. It is very centralised though.
> The ideal scenario for me would be a declaration (using
> clickable check boxes or editing text) that
> effectively creates a program view. This means, I specify
> what I want at a high level and the computer compiles this
> into a corresponding source text view.

True, but there are other factors to consider in
development. Mind you this is a "developer convenience"
issue, but once you compile and/or debug, and you
realize that line 905 of xyz.adb needs to be changed,
where must the real editing be done? Probably not the
file that the compiler used, because it was generated
by some other tool. Often what happens is the xyz.adb
gets edited, and the change is lost.

Tracing back to the where the change really has to go
is inconvenient, if not extremely so. If you're trying
to sort out a problem with open sourced project(s), then
you have to sort out how the creator/maintainer set things
up for you (each project will be different). Again, I
find this annoying at best.

> When I see
> 
> if <this>
> context_clause_A
> fi
> source
> source
> if <this>
> variant_A
> else
> variant_B
> fi
> source
> source
> if <this>
> addition_A
> fi
> source
> 
> this looks like assembly language to me, with all its flexibility.

Yes, this is ugly, but not always _this_ ugly. Furthermore,
if this ugliness were confined only to thin bindings, I
could live with that. No Ada programmer wants to see this
throughout his project.

> But why do we build higher level text structures and compilers?

I don't understand your point here.

> It is interesting that programmers and in particular those
> with an engineering attitude have not built machinery to solve
> the problem in a high level systematic manner. Why?
> 
> There is an opportunity to sell something, or selling support,
> or starting a community effort...
> 
> -- Georg

I think the real reason is that people are holding out for
the "ivory tower" (aka "elegant") solution. There is nothing
wrong with this in principle, but I think it is fair to say
that after 12-20 years, if no solution has emerged, then the
standard has been set too high.

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Chad R. Meiners wrote:

> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:101gi766nkf57b6@corp.supernews.com...
> 
>>These days, its not clear that that would work, but so what? No one in
>> their
>>right mind used curses back then (late 80's) and I fail to see how that's
>>changed now.
> 
> I always thought they called it curses due to the foul language I used when
> trying to get it to work properly ;-)

Some serial terminals do tend to have that effect on
developers and users alike ;-)

> Win32 console API's on the other hand are a dream compared to my experience
> with curses ;-)
> 
> -CRM

That is probably true, at least until you need the blinking
attribute. The problem is sufficiently difficult that the
blink attribute does not exist in PDcurses (yet), where it
can be used in win32 environments.
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Jeffrey Carter]

Marin David Condic wrote:

> So it might not be that much of a stretch to ask something like gnatmake 
> to go decide which way to branch in selecting files from two or more 
> alternate paths within that pile of files. Something as simple as saying 
> 'gnatmake -buildstring="Go Down Path A"' might be sufficient so long as 
> there was some way of picking up the "Path A" variants of files via some 
> language mechanism so that I knew I could take the same pile of files 
> and hand them off to Janus Ada or Aonix or any other compliant compiler 
> and know that someone with little familiarity with my pile of code could 
> use minimal instructions and direct an appropriate build for his platform.

There was a posting on gnatlist today about the -X switch to GNAT and 
the use of project files to accomplish this. One can declare different 
lists of source directories, each associated with a meaningful 
identifier. One can then specify an identifier to -X and GNAT will use 
that list of source directories.

This is not portable, but it may serve as a good basis for defining 
something that could become standard.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

Re: Standard Ada Preprocessor

[Frank J. Lhota]

> Fair enough. I hear that ostrich meat is tasty ;-)

... and low in fat.

Re: Standard Ada Preprocessor

[Georg Bauhaus]

Warren W. Gay VE3WWG <warren@ve3wwg.tk> wrote:
: you
: realize that line 905 of xyz.adb needs to be changed,
: where must the real editing be done? Probably not the
: file that the compiler used, because it was generated
: by some other tool. Often what happens is the xyz.adb
: gets edited, and the change is lost.

Hm, how can that be when you have deterministic rules
that will lead to one source text view given N configuration
inputs? Of course programmers will have to be aware that
they have to consider the configuration with care.

:> this looks like assembly language to me, with all its flexibility.
: 
: Yes, this is ugly, but not always _this_ ugly. Furthermore,
: if this ugliness were confined only to thin bindings, I
: could live with that. No Ada programmer wants to see this
: throughout his project.
: 
:> But why do we build higher level text structures and compilers?
: 
: I don't understand your point here.

Assembly language may be useful here and there but it seems like
programming is mostly done in higher level languages. If configuration
with conditionals in source files and assembly languge are considered
analogous, my expectation is that it makes sense to create a higher
level language for configuration. From another comment in this thread
I conclude that ClearCase has something like this.


-- Georg

Re: Standard Ada Preprocessor

[Marin David Condic]

That there is an implemented answer at least gives people something to 
try and then throw stones at. I kind of like the fact that Gnat seems to 
not be afraid to experiment with practical solutions & see how well or 
poorly they operate in the real world. It might even be a place to 
implement some kind of conditional compilation within files and test it 
out. :-)

MDC

Jeffrey Carter wrote:
> 
> There was a posting on gnatlist today about the -X switch to GNAT and 
> the use of project files to accomplish this. One can declare different 
> lists of source directories, each associated with a meaningful 
> identifier. One can then specify an identifier to -X and GNAT will use 
> that list of source directories.
> 
> This is not portable, but it may serve as a good basis for defining 
> something that could become standard.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Marin David Condic]

You mean like when the compiler is supposed to detect that a 
specification is out of date and recompile whatever depends on it? :-)

Let's be practical. Ada specifies things that require some kind of 
"Outside The Source File" action to take place. Its not technically 
impossible or outside the bounds of a language standard to do that. You 
could write a rule that said some logical name or function would exist 
that an implementation is required to get a string into at compile time 
and that the string could be used for conditional compilation via a 
pragma or some other mechanism. There could be ways of specifying within 
the language how to connect different filenames to different packages 
just like there's a mechanism to associate an Ada logical package name 
with some actual file right now.

The exact details of how a user does it from the outside might not be 
portable - but then neither is the means of invoking the Ada compiler on 
some set of files right now.

MDC

Pascal Obry wrote:
> 
> 
> :) You know that this is not portable. Ada has nothing to do with file system
> and configuration management.
> 
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Marin David Condic]

If there is no elegant solution, then the alternatives are to create an 
inelegant one or live with the problem. Or switch to a language that has 
the inelegant solution. My concern is with the last alternative. People 
look at Ada and say "I can't make it do what I want it to do..." The Ada 
advocates say "Well, you can but you have to turn your head just right, 
stand on one leg, blink your eyes three times...." Or some version of 
"Go solve it with a tool outside the language...." So the developer 
does: He uses C++.

We don't have to make Ada look like C, C++ or Java, but we ought to aim 
for at least providing a way of doing important things that these 
languages can do in some Ada-ish manner.

You can't stop people from wanting things you don't like. You can refuse 
to sell it to them (as one should, if it is immoral), but that just 
sends them off to someone who *will* sell it to them.

MDC

Warren W. Gay VE3WWG wrote:
> 
> I think the real reason is that people are holding out for
> the "ivory tower" (aka "elegant") solution. There is nothing
> wrong with this in principle, but I think it is fair to say
> that after 12-20 years, if no solution has emerged, then the
> standard has been set too high.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Standard Ada Preprocessor

[Mark]

late to the party and jumping in the middle of discussion [sorry]
  please see:

 http://www.digitalmars.com/d/index.html
   look for The C Preprocessor Versus D

  for a different approach to getting rid of the preprocessor but
maintaining some of the primary usage.

Re: Standard Ada Preprocessor

[Frank J. Lhota]

"Mark" <prenom_nomus@yahoo.com> wrote in message
news:c5b88987.0402010709.1d27a8a3@posting.google.com...
> late to the party and jumping in the middle of discussion [sorry]
>   please see:
>
>  http://www.digitalmars.com/d/index.html
>    look for The C Preprocessor Versus D
>
>   for a different approach to getting rid of the preprocessor but
> maintaining some of the primary usage.

It's interesting to see the Ada concepts that have made it into D, including
the use of in / out / in out parameter modes.

Re: Standard Ada Preprocessor

[Martin Krischik]

Frank J. Lhota wrote:

> "Mark" <prenom_nomus@yahoo.com> wrote in message
> news:c5b88987.0402010709.1d27a8a3@posting.google.com...
>> late to the party and jumping in the middle of discussion [sorry]
>>   please see:
>>
>>  http://www.digitalmars.com/d/index.html
>>    look for The C Preprocessor Versus D
>>
>>   for a different approach to getting rid of the preprocessor but
>> maintaining some of the primary usage.
> 
> It's interesting to see the Ada concepts that have made it into D,
> including the use of in / out / in out parameter modes.

But the sad point is that D hasn't got ranges.

With Regards


Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> If there is no elegant solution, then the alternatives are to create an 
> inelegant one or live with the problem. Or switch to a language that has 
> the inelegant solution. My concern is with the last alternative. People 
> look at Ada and say "I can't make it do what I want it to do..." The Ada 
> advocates say "Well, you can but you have to turn your head just right, 
> stand on one leg, blink your eyes three times...." 

This would give me trouble ;-)
...
> We don't have to make Ada look like C, C++ or Java, but we ought to aim 
> for at least providing a way of doing important things that these 
> languages can do in some Ada-ish manner.

Which was the point of the discussion.

> 
> You can't stop people from wanting things you don't like. You can refuse 
> to sell it to them (as one should, if it is immoral), but that just 
> sends them off to someone who *will* sell it to them.
> 
> MDC

I was tempted to compare this with "gun control", but
that might lead to another entirely OT thread ;-)
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Frank J. Lhota]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1113821.JAX30lkfSv@linux1.krischik.com...
> But the sad point is that D hasn't got ranges.

... but it does have array slices.

Re: Standard Ada Preprocessor

[stephen.freeman9]

This argument about C (and D) is very interesting - I have been working on
Safety related work (Uk Defstan SIL 3/ Sil 4 software and  DO178b level a)
for flying aircraft.  We use Ada (Spark Ada at that) to develop code.
However the world in general knows C not Ada.  D helps to strengthen C as
does Misra (see Misra 2 for latest invocation)  but as said - what is
lacking is definition of ranges (and strong typing) . A possible solution
I'm working on is "E" for want of a more novel name.  This should look like
C but ask the programmer to define typedef's for each logically different
type s/he is using and as a comment specify the ranges that that is valid
for.  It then needs a pre-processor to parse that to check for
inconsistancies. (perhaps convert it to Ada?)


"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message
news:sWxSb.74$bn1.6@nwrdny02.gnilink.net...
> > Fair enough. I hear that ostrich meat is tasty ;-)
>
> ... and low in fat.
>
>

Re: Standard Ada Preprocessor

[Jacob Sparre Andersen]

Warren W. Gay VE3WWG wrote:

> So the challenge is to use the best technology (Ada) and yet be
> capable of accomodating a large range of "environments".

Agreed.

But don't you agree that allowing a preprocessor to work on package
specifications isn't exactly good Ada style.  Then you can't trust the
package specifications anymore.  Although I prefer a simple "choose an
appropriate package body" method, I can see some benefits of allowing
full preprocessing of package bodies.

My main problem right now is: Is it possible to specify a sensible
common method for asking the compiler questions about the target
environment?  How?

My first thought was to tell the user (of the compiler) to give the
compiler some appropriate flags, indicating the information needed for
selecting which package bodies to choose.  But that would still leave
the problem of making those configuration decisions to the user
instead of automating them.

Could we ask the compilers to be able to tell us if some library (a
string indicating a library name) exists in a specific version (a
string indicating a version)?  What do compiler vendors say to that?

What other kinds of compile time switches do we want to be able to
make?  Either based on user choice or on the configuration of the
target system.

> I think because of the targeted end user, Open Sourced projects have
> a special "need", compared to perhaps the "typical" Ada project
> (whatever that is ;-)

Yes.  But users of Open Source software already seem to have agreed to
use Autoconf/Automake as their "standard" compile-time configuration
tool.  How does that work on non-Unix systems BTW?

> I never suggested that someone should just plop it into the ARG's
> lap without doing homework/whatever. All I can do is speak for
> myself here, and say that I just wanted to have an open discussion
> on the merits of some sort of conditional compilation.

Good.  Maybe we can actually come up with a suggestion we can sell to
the ARG.

> The result of this discussion seems to suggest that most are
> resisting the idea, for different reasons. So be it. Maybe with
> time, resistance to the idea will fade as more people try to address
> the practical problems that Open Sourced projects face in Ada. One
> can hope ;-)

I hope we can find a solution that makes it easier for people who
receive a source code package with an Ada program to just compile and
run the program, _without_ letting the whole C preprocessor hell loose
in Ada too.

Greetings,

Jacob
-- 
"Hungh. You see! More bear. Yellow snow is always dead give-away."

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jacob Sparre Andersen wrote:

> Warren W. Gay VE3WWG wrote:
...
> But don't you agree that allowing a preprocessor to work on package
> specifications isn't exactly good Ada style.  

No argument. But I do have a problem to solve. The problem
is ugly, and the solution might be ugly too ;-)

> Then you can't trust the
> package specifications anymore.  Although I prefer a simple "choose an
> appropriate package body" method, I can see some benefits of allowing
> full preprocessing of package bodies.

You might be using a different meaning for "trust"
than I use. As I see it, it need not be any different
trust-wise than #included source code in a C program.
You know in advance that certain elements will be compiled
certain way in certain environments. I can trust that to
be the case no matter how many times that is called upon.

I can also trust that things will be compiled in the
other environments that will use them. I see no real
issue here. I'll agree however, that it is bad style
and ugly.

> My main problem right now is: Is it possible to specify a sensible
> common method for asking the compiler questions about the target
> environment?  How?

That is the problem for Ada that has remained unsolved
for (IMO) too long.

> My first thought was to tell the user (of the compiler) to give the
> compiler some appropriate flags, indicating the information needed for
> selecting which package bodies to choose.  But that would still leave
> the problem of making those configuration decisions to the user
> instead of automating them.

The problem that exists now is not generating the configuration.
That can be done a multitude of ways, and is done in Open
Sourced projects all over the place. The problem is taking
it from configuration to source code. That is where the
rubber hits the road right now. C/C++ deal with this just
fine. Ada is challenged here.

> Could we ask the compilers to be able to tell us if some library (a
> string indicating a library name) exists in a specific version (a
> string indicating a version)?  What do compiler vendors say to that?
> 
> What other kinds of compile time switches do we want to be able to
> make?  Either based on user choice or on the configuration of the
> target system.

It is not up to the compiler to know what configuration to
use. But given directions about the configuration, the job
is to generate a compiled version of that solution ;-)

>>I think because of the targeted end user, Open Sourced projects have
>>a special "need", compared to perhaps the "typical" Ada project
>>(whatever that is ;-)
> 
> Yes.  But users of Open Source software already seem to have agreed to
> use Autoconf/Automake as their "standard" compile-time configuration
> tool.  How does that work on non-Unix systems BTW?

Again, Autoconf et al work fine for C/C++ systems. It requires
real gyrations to use it with Ada ;-)

Presumably, Autoconf could be used in a CYGWIN environment,
though I have not tried it myself. Windows is in some ways
much easier to config for, since there are fewer variations
than exist in the *NIX/*BSD world. There are of course, still
variations, and one has to be concerned about what optional
components are installed etc. The general approach to Windows
seems to be to provide an Intel binary (setup) to do that work.

>>The result of this discussion seems to suggest that most are
>>resisting the idea, for different reasons. So be it. Maybe with
>>time, resistance to the idea will fade as more people try to address
>>the practical problems that Open Sourced projects face in Ada. One
>>can hope ;-)
> 
> I hope we can find a solution that makes it easier for people who
> receive a source code package with an Ada program to just compile and
> run the program, _without_ letting the whole C preprocessor hell loose
> in Ada too.
> 
> Greetings,
> 
> Jacob

The fact that a conditional compilation feature is made available,
does not require it to be used. Just by mandating that it is
not done by default should help. Certainly safety critical
systems where perhaps this type of thing would not be tolerated,
you can mandate that it never be used.

So given the above, the real resistance is boils down to the
argument "I don't want to ever see it".
-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk

Re: Standard Ada Preprocessor

[Jacob Sparre Andersen]

Warren W. Gay VE3WWG wrote:
> Jacob Sparre Andersen wrote:
> > Warren W. Gay VE3WWG wrote:

> > But don't you agree that allowing a preprocessor to work on
> > package specifications isn't exactly good Ada style.
> 
> No argument. But I do have a problem to solve. The problem is ugly,
> and the solution might be ugly too ;-)

:-(

Do you have any examples, where you would have, or actually have, used
a preprocessor on package specifications?  (I hope I haven't missed
some in the discussion)

I probably make too simple systems, but I find it hard to imagine
cases, where it wouldn't be more appropriate to - at least - keep the
variant parts of the code away from package specifications.

> > Then you can't trust the package specifications anymore.  Although
> > I prefer a simple "choose an appropriate package body" method, I
> > can see some benefits of allowing full preprocessing of package
> > bodies.
> 
> You might be using a different meaning for "trust" than I use. As I
> see it, it need not be any different trust-wise than #included
> source code in a C program.  You know in advance that certain
> elements will be compiled certain way in certain environments. I can
> trust that to be the case no matter how many times that is called
> upon.

My problem is that if the package specifications vary with the target
environment, that means that all the code using that package also may
have to vary with the target environment, and thus propagate use of
conditional compilation. - I doubt that the ARG would let that into
the standard.

> > My main problem right now is: Is it possible to specify a sensible
> > common method for asking the compiler questions about the target
> > environment?  How?
> 
> That is the problem for Ada that has remained unsolved for (IMO) too
> long.

Haven't anybody tried to put a suggestion together?

> > My first thought was to tell the user (of the compiler) to give
> > the compiler some appropriate flags, indicating the information
> > needed for selecting which package bodies to choose.  But that
> > would still leave the problem of making those configuration
> > decisions to the user instead of automating them.
> 
> The problem that exists now is not generating the configuration.

I am not sure I agree.

> That can be done a multitude of ways, and is done in Open Sourced
> projects all over the place.

Yes, but the Open Source world has a de-facto standard for doing it.
We should either get those tools to support Ada as well as they
support C and C++ or make an easier and safer solution for Ada.

> The problem is taking it from configuration to source code. That is
> where the rubber hits the road right now. C/C++ deal with this just
> fine. Ada is challenged here.

I would say that that part is close to trivial - if we can agree to
which granularity to support.  At one extreme there is the current
situation with no formalised conditional compilation, somewhere in
between there is letting the compiler choose appropriate package
bodies given the configuration parameters, and at the other extreme we
have mandating something like the C preprocessor.

Personally I would like to have the solution of letting the compiler
choose appropriate package bodies.  But without some level of
automated detection of the target environment, it wouldn't be of much
use, and I could just as well handle it myself as I do today.

> It is not up to the compiler to know what configuration to use. But
> given directions about the configuration, the job is to generate a
> compiled version of that solution ;-)

I can understand your point of view, but if we really want to compete
with `./configure && make && su -c make install`, we have to do better
than that.

If users have to find out which versions of which libraries are on
their systems _and_ how to tell the compiler that information, we are
already _far_ behind what I can do myself with existing tools and
without much work.

> Again, Autoconf et al work fine for C/C++ systems. It requires real
> gyrations to use it with Ada ;-)

Sure?  I have never had to create an Autoconf/Automake configuration
from scratch, but I find it hard to imagine that it requires excessive
amounts of work to get it to do the testing needed to configure an Ada
program.

> The fact that a conditional compilation feature is made available,
> does not require it to be used.

Right.  But programmers have an awful habit of using whatever tools
available.

> So given the above, the real resistance is boils down to the
> argument "I don't want to ever see it".

If you are talking about full C preprocessor style conditional
compilation, you are certainly right.

If we are talking about some intermediated solution, where the public
part of package specifications are untouched by the conditional
compilation mechanism _and_ we can include some implementation advise
about the compiler guessing or asking the user the questions needed to
resolve the conditional compilation, then I will most likely support
it.

Jacob
-- 
"I don't want to gain immortality in my works.
 I want to gain it by not dying."

Re: Standard Ada Preprocessor

[Dmitry A. Kazakov]

On 10 Feb 2004 22:49:28 +0100, Jacob Sparre Andersen <sparre@nbi.dk>
wrote:

>My problem is that if the package specifications vary with the target
>environment, that means that all the code using that package also may
>have to vary with the target environment, and thus propagate use of
>conditional compilation. - I doubt that the ARG would let that into
>the standard.

Sure. The solution should be based on a contract model.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Standard Ada Preprocessor

[Warren W. Gay VE3WWG]

Jacob Sparre Andersen wrote:

> Warren W. Gay VE3WWG wrote:
>>Jacob Sparre Andersen wrote:
>>>Warren W. Gay VE3WWG wrote:
>>>But don't you agree that allowing a preprocessor to work on
>>>package specifications isn't exactly good Ada style.
>>
>>No argument. But I do have a problem to solve. The problem is ugly,
>>and the solution might be ugly too ;-)
> 
> :-(
> 
> Do you have any examples, where you would have, or actually have, used
> a preprocessor on package specifications?  (I hope I haven't missed
> some in the discussion)

I've kind of run out of steam on this thread. I've pointed out
some general examples in the earlier parts of this thread.

>>So given the above, the real resistance is boils down to the
>>argument "I don't want to ever see it".
> 
> If you are talking about full C preprocessor style conditional
> compilation, you are certainly right.

No, actually (this has been discussed earlier in this thread).
Remember that some of C/C++'s problems are related to #include
which is quite different that with-ing a package. However, there
are times when you want to with one package over another (for
example you want to use the GNAT.* package(s) when using GNAT,
and something else to replace if compiling with another compiler).
This is just one example and of course you need to conditionally
compile code depending upon which package(s) you have with-ed
because the functionality may not be the same (certainly the
hierarchical names for the package defined items are different
also).

-- 
Warren W. Gay VE3WWG
http://ve3wwg.tk