Re: Calendar package

Re: Calendar package

[singlespeeder]

If (when?) the calendar package is updated can someone please not break the
existing interface and leave it entirely as is.

I currently develop systems that have to compile with different Ada 83 and
Ada 95 compilers on different OSs (Dec Ada on OpenVMS/Gnat on Windows). The
one thing that keeps biting me - despite backward compatibility is the way
that interfaces have changed between standards. I thought respecting
interface concepts was generally agreed to be A Good Thing, and can't
believe that Ada 95 didn't follow this philosophy.

Where the Ada 95 standard defined a new package (e.g. Command_Line) I can
write my own package body (or at least the bits I use) from the Ada 95 spec,
and write the code as if the Ada 95 package exists. Simple. Where Ada95
broke an existing Ada83 package (Text_IO gives me jip) I am often caught out
and so far I just use the lowest common denominator. Why?

Because I don't want to write my own Text_IO that implements all the Ada 83
Text_IO features that I currently use and extends it for the Ada 95
features, nor do I want to do conditional compilation (which I was doing for
a while but it got unwieldy even with make).

If someone wants to add more functionality to an existing Ada predefined
package can they please create a new package (e.g. Text_IO2) and leave the
existing package alone.

Thanks.

singlespeeder

Re: Calendar package

[Robert A Duff]

"singlespeeder" <singlespeeder@32sixteen.com> writes:

> I currently develop systems that have to compile with different Ada 83 and
> Ada 95 compilers on different OSs (Dec Ada on OpenVMS/Gnat on Windows). The
> one thing that keeps biting me - despite backward compatibility is the way
> that interfaces have changed between standards. I thought respecting
> interface concepts was generally agreed to be A Good Thing, and can't
> believe that Ada 95 didn't follow this philosophy.

Ada 9X was intended to be *very* compatible with Ada 83.  The only time
that was violated were for very good reasons (or so we thought).
Perhaps you can give some examples?

Note that if different Ada 83 compilers were already different, then you
can't blame it on Ada 95.

- Bob

Re: Calendar package

[singlespeeder]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:<wcc7l1l4e95.fsf@world.std.com>...
> Ada 9X was intended to be *very* compatible with Ada 83.  The only time
> that was violated were for very good reasons (or so we thought).
> Perhaps you can give some examples?
>
> - Bob

A trivial example of where I don't believe backward compatibility doesn't
work as well as it could.

In package Text_IO there is a new enumeration File_Mode, Append_File.

We develop mainly in an Ada 95 (speedier toolset) with the compiler set to
issue warning about Ada 83 incompatibilities - but it's not perfect. We have
had instances where programmers (er, me) use the new File_Mode and break the
code when we move it back to the Ada 83 environment. Yes this example was
trivial and easy to fix but there are/have been worse cases.

If the extended file handling functions that use new file modes had been in
Text_IO2 I wouldn't have the opportunity to break Ada 83 code without
explicitly using the new package.

We use some (not all) of the features of the Ada.Command_Line package, and
we have been able to implement just those bits we want on the VMS and Ada
83, whilst using the provided package on Windows and Ada 95.

In general where we want to use Ada 95 features in Ada 83 code, we find it
easier to write a cut down version of an Ada 95 package (and stub out those
routines we don't implement) than extend an existing package. The code then
looks like Ada 95 code.

I just think that existing packages and routine interfaces should have been
respected and new/extended functionality should have gone into new
packages/interfaces.

singlespeeder

Re: Calendar package

[Robert A Duff]

"singlespeeder" <singlespeeder@32sixteen.com> writes:

> "Robert A Duff" <bobduff@world.std.com> wrote in message
> news:<wcc7l1l4e95.fsf@world.std.com>...
> > Ada 9X was intended to be *very* compatible with Ada 83.  The only time
> > that was violated were for very good reasons (or so we thought).
> > Perhaps you can give some examples?
> >
> > - Bob
> 
> A trivial example of where I don't believe backward compatibility doesn't
> work as well as it could.
> 
> In package Text_IO there is a new enumeration File_Mode, Append_File.
> 
> We develop mainly in an Ada 95 (speedier toolset) with the compiler set to
> issue warning about Ada 83 incompatibilities - but it's not perfect. We have
> had instances where programmers (er, me) use the new File_Mode and break the
> code when we move it back to the Ada 83 environment. Yes this example was
> trivial and easy to fix but there are/have been worse cases.

What I meant was that Ada 95 was designed so that correct Ada 83
programs would be correct Ada 95 programs, with the same meaning, except
in rare circumstances.  You're complaining about the other direction:
moving Ada 95 code to Ada 83, which was not a goal of the Ada 9X
project.

It's almost impossible to implement "pragma Ada_83" exactly right.

- Bob