another way to shoot yourself in the foot?

another way to shoot yourself in the foot?

[fedya_fedyakoff]

Consider a very simple code. Suppose we have

1) a Named interface as this

--- named.ads ---

package Named is
   type Object is limited interface;

   function  name(this: Object) return String is abstract;
end Named;

2) Simple implementation

--- Some.ads ---

with Named;
with Ada.Finalization; use Ada.Finalization;
with Ada.Strings.Bounded;

package Some is

   Size : constant := 80;

   package bs is new Ada.Strings.Bounded.Generic_Bounded_Length(Size);
   use bs;

   type Object is new Limited_Controlled and Named.Object with
private;


   function Create( name: String ) return Object;

   overriding procedure Initialize(this: in out Object);
   overriding procedure Finalize(this: in out Object);

   overriding function  name(this: Object) return String;


private
   type Object is new Limited_Controlled and Named.Object with
      record
         the_name: Bounded_String;
      end record;
end Some;

--- Some.adb ---

with ada.Text_IO;

package body Some is
   package tio renames ada.Text_IO;

   function Create( name: String ) return Object is
   begin
      return O : Object do
         O.the_name := To_Bounded_String(name);
      end return;
   end Create;


   procedure Initialize(this: in out Object) is
   begin
      tio.Put_Line("Initialization Car " & this.name);
   end Initialize;

   procedure Finalize(this: in out Object) is
   begin
      tio.Put_Line("Finalization Car " & this.name);
   end Finalize;


   function name(this: Object) return String is
   begin
      return To_String(this.the_name);
   end name;

end Some;

3) Simple factory function as follows:

--- Factory ads ---
with Named;
with Some;

package Factory is
   function Create(class: String; name: String) return
Named.Object'Class;
end Factory;

--- Factory.adb ---

with Ada.Strings.Fixed; use Ada.Strings.Fixed;
with Some;

package body Factory is
   --- this one is ugly, but in sake of simplicity ...
   function Create(class: String; name: String) return
Named.Object'Class is
   begin
      if Index(class, "Some") /= 0 then
         return Some.Create(name);
      end if;
      raise Program_Error with "Unknown class " & class;
   end;
end Factory;
---------------

4) And finally main procedure

--- boom.adb ---

with ada.Text_IO;
with Named; use Named;
with Factory;
with Some;

procedure boom is
   package tio renames ada.Text_IO;
   aNamed: Some.Object := Some.Create("One");
begin
     declare
        aNamed1: Named.Object'Class := Factory.Create("Some", "Two");
     begin
        tio.put_line( "car: " & aNamed1.name ); ---booooooommm!!!
     end;

   tio.put_line( "car: " & aNamed.name );
   tio.Flush;
end boom;
-----------


All of that being compiled without even one warning, crashed at
runtime with PROGRAM_ERROR EXCEPTION_ACCESS_VIOLATION  on Windows
( compiled using gnat gpl 2008 )

Modified program  ( Named.Object, being changed to be not limited, and
Some.Object to be Controlled ) runs perfectly.

I have an idea why the program behavs like that, but i think there
must be some warning at least.

What do you think?

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Fri, 20 Jun 2008 02:03:32 -0700 (PDT), fedya_fedyakoff@inbox.ru wrote:

> Consider a very simple code. Suppose we have
[...]
> I have an idea why the program behavs like that, but i think there
> must be some warning at least.
> 
> What do you think?

This looks like a compiler bug to me. It seems that the compiler
prematurely finalizes the object created by the factory, as if the object
were non-limited. Because the object is nevertheless somewhat limited this
finalization happens in-place, on a living object... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[fedya_fedyakoff]

On 20 июн, 13:34, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 20 Jun 2008 02:03:32 -0700 (PDT), fedya_fedyak...@inbox.ru wrote:
> > Consider a very simple code. Suppose we have
> [...]
> > I have an idea why the program behavs like that, but i think there
> > must be some warning at least.
>
> > What do you think?
>
> This looks like a compiler bug to me. It seems that the compiler
> prematurely finalizes the object created by the factory, as if the object
> were non-limited. Because the object is nevertheless somewhat limited this
> finalization happens in-place, on a living object... (:-))
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Strangely, replacing
'aNamed1: Named.Object'Class := Factory.Create("Some", "Two");'

with
'aNamed1: Some.Object'Class := Some.Create("Two");'

leads program to run perfectly ...

I thought it's some type of narrowing problem ... but anyway you're
right, it seems very match as compiler bug...

Re: another way to shoot yourself in the foot?

[Ludovic Brenta]

> I thought it's some type of narrowing problem ... but anyway you're
> right, it seems very match as compiler bug...

Anyone willing to reproduce this bug with GCC 4.3 and report it to
Bugzilla if applicable?

--
Ludovic Brenta.

Re: another way to shoot yourself in the foot?

[christoph.grein]

> --- Factory ads ---
> with Named;
> with Some;
>
> package Factory is
>    function Create(class: String; name: String) return
> Named.Object'Class;
> end Factory;
>
> --- Factory.adb ---
>
> with Ada.Strings.Fixed; use Ada.Strings.Fixed;
> with Some;
>
> package body Factory is
>    --- this one is ugly, but in sake of simplicity ...
>    function Create(class: String; name: String) return
> Named.Object'Class is
>    begin
>       if Index(class, "Some") /= 0 then
>          return Some.Create(name);
>       end if;
>       raise Program_Error with "Unknown class " & class;
>    end;
> end Factory;

Since Some.Object is limited, Factory must construct in place. The
normal return statement produces a copy (I guess there should be a
warning here - no compiler bug, since the RM has nothing to say about
warnings). So use the extended return statement as in Some.Create.

(This is just a guess, dunno if it helps.)

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Fri, 20 Jun 2008 03:05:29 -0700 (PDT), christoph.grein@eurocopter.com
wrote:

>> --- Factory ads ---
>> with Named;
>> with Some;
>>
>> package Factory is
>> � �function Create(class: String; name: String) return
>> Named.Object'Class;
>> end Factory;
>>
>> --- Factory.adb ---
>>
>> with Ada.Strings.Fixed; use Ada.Strings.Fixed;
>> with Some;
>>
>> package body Factory is
>> � �--- this one is ugly, but in sake of simplicity ...
>> � �function Create(class: String; name: String) return
>> Named.Object'Class is
>> � �begin
>> � � � if Index(class, "Some") /= 0 then
>> � � � � �return Some.Create(name);
>> � � � end if;
>> � � � raise Program_Error with "Unknown class " & class;
>> � �end;
>> end Factory;
> 
> Since Some.Object is limited, Factory must construct in place. The
> normal return statement produces a copy (I guess there should be a
> warning here - no compiler bug, since the RM has nothing to say about
> warnings).

Are you sure? Then it would be worse, a language design bug. Anyway a
limited object cannot be copied, so it must be an error if an attempt is
made.

> So use the extended return statement as in Some.Create.

It already does. Did you mean in Factory as well? Like this:

function Create (class: String; name: String) return Named.Object'Class is
   begin
      if Index (class, "Some") /= 0 then
         return X : Named.Object'Class := Some.Create (name);
      end if;
      raise Program_Error with "Unknown class " & class;
   end;
end Create;

I bet it would not help.
-------------------------

Honestly I have no idea how it is managed on the language level. A limited
interface can be implemented by a non-limited object. Thus from the
declaration of a factory function, returning a class-wide of some limited
interface, the compiler cannot decide whether the result should be in-place
or not. Therefore, IMO, it must consider the worst case, i.e. an in-place
"return".

Language lawyers?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[Adam Beneschan]

On Jun 20, 3:05 am, christoph.gr...@eurocopter.com wrote:
> > --- Factory ads ---
> > with Named;
> > with Some;
>
> > package Factory is
> >    function Create(class: String; name: String) return
> > Named.Object'Class;
> > end Factory;
>
> > --- Factory.adb ---
>
> > with Ada.Strings.Fixed; use Ada.Strings.Fixed;
> > with Some;
>
> > package body Factory is
> >    --- this one is ugly, but in sake of simplicity ...
> >    function Create(class: String; name: String) return
> > Named.Object'Class is
> >    begin
> >       if Index(class, "Some") /= 0 then
> >          return Some.Create(name);
> >       end if;
> >       raise Program_Error with "Unknown class " & class;
> >    end;
> > end Factory;
>
> Since Some.Object is limited, Factory must construct in place. The
> normal return statement produces a copy

Not true.  If a function result is a limited type, a "return"
statement can be used with a function call.  The idea is that the
build-in-place would propagate.  For example, say you initialize an
object of a limited type:

  Obj : Limited_Type := Func3(Arg);

where Func3 has an extended return statement:

  return Result : Limited_Type do
    Result.Field1 := ... code to set up Result, etc.
  end return;

When this happens, I believe the effect is the same as if the code in
the extended return that sets up Result's components actually works
directly with Obj, at least semantically.  To implement this, the
address of Obj has to be passed to Func3 somehow so that Func3 can
work directly with Obj.

If, instead, you say

  Obj : Limited_Type := Func1(Something);

and Func1 does this:

  return Func2(Something_Else);

and Func2 does this:

  return Func3(Arg);

and Func3 works as above, then in effect the address of Obj gets
passed to Func1, which then propagates it to Func2, which propagates
it to Func3.  No copy (in Ada semantics) is involved.

Dmitry is right that if the language allowed this "return" to copy an
object of a limited type like this, it would be a serious language
design error, since that goes against the whole point of limited
types.  But, in fact, there is no such error.  The language is fine.

                            -- Adam

Re: another way to shoot yourself in the foot?

[Adam Beneschan]

On Jun 20, 3:26 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> Honestly I have no idea how it is managed on the language level. A limited
> interface can be implemented by a non-limited object. Thus from the
> declaration of a factory function, returning a class-wide of some limited
> interface, the compiler cannot decide whether the result should be in-place
> or not. Therefore, IMO, it must consider the worst case, i.e. an in-place
> "return".
>
> Language lawyers?

Interesting question.  I may have to look through AI's to see if this
case was discussed at all.  However, at first glance, when I look at
the wording in 7.5, it talks about the type of the *expression* that
you're using, not the expected type of the thing you're using it for.
This is true in 7.5(2.1), where it puts restrictions on where
expressions of a limited type may be used, and in 7.5(8.1), where it
says that certain expressions of a limited type (i.e. aggregates and
function calls) must be built in place.

So off the top of my head, I think that if you say

  type Int1 is limited interface;

  type Rec is new Int1 with record  -- not limited!
    ...

  function Func (...) returns Rec is ...;

  Obj : Int1'Class := Func(...);

Since the call to Func is an expression of type Rec, which is not
limited, there's no build-in-place requirement; the fact that Obj's
type is the classwide type for a limited interface isn't relevant to
that rule.  The compiler knows what type Func is, so there's no
"assume-the-worst" issue.  If, instead, we had said

  function Func2 (...) returns Int1'Class is ...;

  Obj : Int1'Class := Func2(...);

Now Func2 needs to be called in such a way that it will build the
result in place; following my previous post, this essentially means
passing the address of Obj to Func2.  But whether Func2 passes this
address on to other functions depends on what the "return" statements
in Func2 look like, and the compiler will make the appropriate
decision at that point.  So I don't think there's any "assume-the-
worst" issue here either.

                            -- Adam

Re: another way to shoot yourself in the foot?

[Robert A Duff]

christoph.grein@eurocopter.com writes:

> Since Some.Object is limited, Factory must construct in place. The
> normal return statement produces a copy ...

I haven't followed this whole thread, but I'd just like to point out
that a simple return statement:

    return <some-expression>;

is equivalent to an extended return statement:

    return Result : constant T := <some-expression> do
        null;
    end return;

where T is the result subtype of the function (presuming
Result doesn't conflict with something else around the
place).

Build-in-place is determined by the type, not by the
syntactic form of the return statement.

- Bob

Re: another way to shoot yourself in the foot?

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> Build-in-place is determined by the type, not by the
> syntactic form of the return statement.

I'm not sure I see any point to the extended return statement. Wouldn't it have 
been clearer and simpler to have done something like

    Result : return T;
    ...
begin
    ...
    return Result;

with a rule that only 1 "return variable" may be in scope at a time?

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Fri, 20 Jun 2008 23:37:11 GMT, Jeffrey R. Carter wrote:

> Robert A Duff wrote:
>> 
>> Build-in-place is determined by the type, not by the
>> syntactic form of the return statement.
> 
> I'm not sure I see any point to the extended return statement.

I agree, it was introduced solely for dealing with limited-valued
functions. IMO there should be no such thing as "limited-valued" at all.
In-place initialization should be handled by proper constructors.

> Wouldn't it have 
> been clearer and simpler to have done something like
> 
>     Result : return T;

Result : T renames return;
    -- Would be IMO better, semantically it is a renaming.

>     ...
> begin
>     ...
>     return Result;

Why this? With your syntax it is clear what is going to be returned:

function Foo return T is
   Result : return T;  -- This will be the result
begin
   ...
end Foo; -- Returns Result, obviously, as declared

> with a rule that only 1 "return variable" may be in scope at a time?

As well as that there may be no return statements returning something
else...

One problem with your proposal is:

function Foo (...) return String is
begin
   declare
      Result : return String (1..200);  -- Going to return 200 characters
   begin
      Result (1) := 'a'; -- Here the result has to be allocated
      if HALT (x) then
         return;  -- Return from Foo with Result
      end if;
   end;  -- Drop already allocated and initialized result
   return "Hallo!";  -- Return a completely different thing
end Foo;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Robert A Duff wrote:
>> Build-in-place is determined by the type, not by the
>> syntactic form of the return statement.
>
> I'm not sure I see any point to the extended return statement. Wouldn't
> it have been clearer and simpler to have done something like
>
>    Result : return T;
>    ...
> begin
>    ...
>    return Result;
>
> with a rule that only 1 "return variable" may be in scope at a time?

I actually advocated something along those lines.
I think it has (probably-solvable) problems, too.
If you're curious, look up the relevant AI.

As Dmitry pointed out, with this idea, there's no need for the "return
Result;".

- Bob

Re: another way to shoot yourself in the foot?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> One problem with your proposal is:
>
> function Foo (...) return String is
> begin
>    declare
>       Result : return String (1..200);  -- Going to return 200 characters
>    begin
>       Result (1) := 'a'; -- Here the result has to be allocated
>       if HALT (x) then
>          return;  -- Return from Foo with Result
>       end if;
>    end;  -- Drop already allocated and initialized result
>    return "Hallo!";  -- Return a completely different thing
> end Foo;

I don't see that as a problem, and anyway, the same thing can happen
with the existing syntax:

function Foo (...) return String is
begin
   return Result : String (1..200) do  -- Going to return 200 characters
      Result (1) := 'a'; -- Here the result has to be allocated
      if HALT (x) then
         goto Label;
      end if;
   end;  -- Drop already allocated and initialized result
   <<Label>>
   return "Hallo!";  -- Return a completely different thing
end Foo;

The implementation of this is "interesting" (if we replace String by a
build-in-place type).  ;-)

Instead of goto, you could cause the same issue with an exit statement,
or with an exception raised inside the return, and handled outside it
(but still inside the function).  In fact that exception case can
happen with the old-fashioned syntax:

    function Bar (...) return Limited_Unconstrained_Array is
    begin
        return (1..10 => F(...));
    exception
        when Some_Error =>
            return ...;
    end Bar;

And suppose F raises an exception on the 5th call.

- Bob

Re: another way to shoot yourself in the foot?

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> I actually advocated something along those lines.
> I think it has (probably-solvable) problems, too.
> If you're curious, look up the relevant AI.

Might be worth the effort.

> As Dmitry pointed out, with this idea, there's no need for the "return
> Result;".

True, but I find it easier to understand the function if it has the explicit 
"return Result;", even though I came to Ada from a Pascal background.

-- 
Jeff Carter
"Blessed are they who convert their neighbors'
oxen, for they shall inhibit their girth."
Monty Python's Life of Brian
83

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Sun, 22 Jun 2008 16:44:08 -0400, Robert A Duff wrote:

> I don't see that as a problem, and anyway, the same thing can happen
> with the existing syntax:
> 
> function Foo (...) return String is
> begin
>    return Result : String (1..200) do  -- Going to return 200 characters
>       Result (1) := 'a'; -- Here the result has to be allocated
>       if HALT (x) then
>          goto Label;
>       end if;
>    end;  -- Drop already allocated and initialized result
>    <<Label>>
>    return "Hallo!";  -- Return a completely different thing
> end Foo;
> 
> The implementation of this is "interesting" (if we replace String by a
> build-in-place type).  ;-)

How much interesting is it? (:-))

Unfortunately the following crazy sample crashes GNAT, but I wonder what
could be the result if it compiled:

procedure Return_Task is
   Just_For_Fun : exception;

   task type T is
      entry A;
   end T;

   task body T is
   begin
      accept A;
   end T;

   function Interesting return T is
   begin
      return X : T do
         raise Just_For_Fun;
      end return;
   exception
      when Just_For_Fun =>
         return X : T;
   end Interesting;

   X : T := Interesting;
begin
   X.A;
end Return_Task;

Should it block?

Another question is about the semantics such stuff. In which sense in-place
is it? It seems that an in-place initialization might result in n
finalizations and n+1 initializations (n>=0) of the same thing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[george.priv]

On Jun 23, 3:49 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 22 Jun 2008 16:44:08 -0400, Robert A Duff wrote:
> > I don't see that as a problem, and anyway, the same thing can happen
> > with the existing syntax:
>
> > function Foo (...) return String is
> > begin
> >    return Result : String (1..200) do  -- Going to return 200 characters
> >       Result (1) := 'a'; -- Here the result has to be allocated
> >       if HALT (x) then
> >          goto Label;
> >       end if;
> >    end;  -- Drop already allocated and initialized result
> >    <<Label>>
> >    return "Hallo!";  -- Return a completely different thing
> > end Foo;
>
> > The implementation of this is "interesting" (if we replace String by a
> > build-in-place type).  ;-)
>
> How much interesting is it? (:-))
>
> Unfortunately the following crazy sample crashes GNAT, but I wonder what
> could be the result if it compiled:
>
> procedure Return_Task is
>    Just_For_Fun : exception;
>
>    task type T is
>       entry A;
>    end T;
>
>    task body T is
>    begin
>       accept A;
>    end T;
>
>    function Interesting return T is
>    begin
>       return X : T do
>          raise Just_For_Fun;
>       end return;
>    exception
>       when Just_For_Fun =>
>          return X : T;
>    end Interesting;
>
>    X : T := Interesting;
> begin
>    X.A;
> end Return_Task;
>
> Should it block?
>
> Another question is about the semantics such stuff. In which sense in-place
> is it? It seems that an in-place initialization might result in n
> finalizations and n+1 initializations (n>=0) of the same thing.
>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Aren't tasks limited types by definitions? In which case compiler
should be giving error message..

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Mon, 23 Jun 2008 21:02:29 -0700 (PDT), george.priv@gmail.com wrote:

> On Jun 23, 3:49 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Sun, 22 Jun 2008 16:44:08 -0400, Robert A Duff wrote:
>>> I don't see that as a problem, and anyway, the same thing can happen
>>> with the existing syntax:
>>
>>> function Foo (...) return String is
>>> begin
>>>    return Result : String (1..200) do  -- Going to return 200 characters
>>>       Result (1) := 'a'; -- Here the result has to be allocated
>>>       if HALT (x) then
>>>          goto Label;
>>>       end if;
>>>    end;  -- Drop already allocated and initialized result
>>>    <<Label>>
>>>    return "Hallo!";  -- Return a completely different thing
>>> end Foo;
>>
>>> The implementation of this is "interesting" (if we replace String by a
>>> build-in-place type).  ;-)
>>
>> How much interesting is it? (:-))
>>
>> Unfortunately the following crazy sample crashes GNAT, but I wonder what
>> could be the result if it compiled:
>>
>> procedure Return_Task is
>>    Just_For_Fun : exception;
>>
>>    task type T is
>>       entry A;
>>    end T;
>>
>>    task body T is
>>    begin
>>       accept A;
>>    end T;
>>
>>    function Interesting return T is
>>    begin
>>       return X : T do
>>          raise Just_For_Fun;
>>       end return;
>>    exception
>>       when Just_For_Fun =>
>>          return X : T;
>>    end Interesting;
>>
>>    X : T := Interesting;
>> begin
>>    X.A;
>> end Return_Task;
>>
>> Should it block?
>>
>> Another question is about the semantics such stuff. In which sense in-place
>> is it? It seems that an in-place initialization might result in n
>> finalizations and n+1 initializations (n>=0) of the same thing.
> 
> Aren't tasks limited types by definitions?

Yes, they are.

> In which case compiler
> should be giving error message..

Ada 2005 introduced "Pickwickian" functions "returning" limited objects,
in-place, upon initialization. In the example, the result task of
Interesting, being constructed in the object X, is first initialized, then
finalized upon exception propagation and, finally, re-initialized again. I
suggest that the example (if legal) should hang forever, because to
finalize T one has to have a rendezvous with its entry A.

All this is confusing and counterintuitive, at least. I mean both
"Pickwickian" functions and the semantics return statements.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[Adam Beneschan]

On Jun 23, 12:49 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Sun, 22 Jun 2008 16:44:08 -0400, Robert A Duff wrote:
> > I don't see that as a problem, and anyway, the same thing can happen
> > with the existing syntax:
>
> > function Foo (...) return String is
> > begin
> >    return Result : String (1..200) do  -- Going to return 200 characters
> >       Result (1) := 'a'; -- Here the result has to be allocated
> >       if HALT (x) then
> >          goto Label;
> >       end if;
> >    end;  -- Drop already allocated and initialized result
> >    <<Label>>
> >    return "Hallo!";  -- Return a completely different thing
> > end Foo;
>
> > The implementation of this is "interesting" (if we replace String by a
> > build-in-place type).  ;-)
>
> How much interesting is it? (:-))
>
> Unfortunately the following crazy sample crashes GNAT, but I wonder what
> could be the result if it compiled:
>
> procedure Return_Task is
>    Just_For_Fun : exception;
>
>    task type T is
>       entry A;
>    end T;
>
>    task body T is
>    begin
>       accept A;
>    end T;
>
>    function Interesting return T is
>    begin
>       return X : T do
>          raise Just_For_Fun;
>       end return;
>    exception
>       when Just_For_Fun =>
>          return X : T;
>    end Interesting;
>
>    X : T := Interesting;
> begin
>    X.A;
> end Return_Task;
>
> Should it block?

I've probably lost the plot of this thread.  But in regards to the
example, I think the example is "no".  The semantics should be exactly
the same as if Interesting's body were simply "return X : T;".  The
first extended return statement that raises an exception doesn't have
any effect, in terms of starting a new task or anything like that,
because the RM explicitly says that task activation doesn't occur
until after the function returns (6.5(7)).


> Another question is about the semantics such stuff. In which sense
> in-place
> is it? It seems that an in-place initialization might result in n
> finalizations and n+1 initializations (n>=0) of the same thing.

I think the ARG has recognized that the semantics need to be better
defined, and they're working on it.  See AI05-67.

                               -- Adam

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Tue, 24 Jun 2008 07:59:35 -0700 (PDT), Adam Beneschan wrote:

> I've probably lost the plot of this thread.  But in regards to the
> example, I think the example is "no".  The semantics should be exactly
> the same as if Interesting's body were simply "return X : T;".  The
> first extended return statement that raises an exception doesn't have
> any effect, in terms of starting a new task or anything like that,
> because the RM explicitly says that task activation doesn't occur
> until after the function returns (6.5(7)).

OK, then the notorious problem of Ada 95, that a task cannot be
initialized, in the sense that upon initialization you could pass
parameters to it via a rendezvous, is still there. "Constructing functions"
do not help here, because you cannot engage a rendezvous before return. Too
bad.

Tasks finalization does not work either, because there is no destructing
functions ("malfunctions" to use the name Robert Duff suggested (:-))
anyway.

Task as a component is still no runner...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 23 Jun 2008 21:02:29 -0700 (PDT), george.priv@gmail.com wrote:
>
>> On Jun 23, 3:49 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>> wrote:
>>> On Sun, 22 Jun 2008 16:44:08 -0400, Robert A Duff wrote:
>>>> I don't see that as a problem, and anyway, the same thing can happen
>>>> with the existing syntax:
>>>
>>>> function Foo (...) return String is
>>>> begin
>>>>    return Result : String (1..200) do  -- Going to return 200 characters
>>>>       Result (1) := 'a'; -- Here the result has to be allocated
>>>>       if HALT (x) then
>>>>          goto Label;
>>>>       end if;
>>>>    end;  -- Drop already allocated and initialized result
>>>>    <<Label>>
>>>>    return "Hallo!";  -- Return a completely different thing
>>>> end Foo;
>>>
>>>> The implementation of this is "interesting" (if we replace String by a
>>>> build-in-place type).  ;-)
>>>
>>> How much interesting is it? (:-))
>>>
>>> Unfortunately the following crazy sample crashes GNAT, but I wonder what
>>> could be the result if it compiled:
>>>
>>> procedure Return_Task is
>>>    Just_For_Fun : exception;
>>>
>>>    task type T is
>>>       entry A;
>>>    end T;
>>>
>>>    task body T is
>>>    begin
>>>       accept A;
>>>    end T;
>>>
>>>    function Interesting return T is
>>>    begin
>>>       return X : T do
>>>          raise Just_For_Fun;
>>>       end return;
>>>    exception
>>>       when Just_For_Fun =>
>>>          return X : T;
>>>    end Interesting;
>>>
>>>    X : T := Interesting;
>>> begin
>>>    X.A;
>>> end Return_Task;
>>>
>>> Should it block?
>>>
>>> Another question is about the semantics such stuff. In which sense in-place
>>> is it? It seems that an in-place initialization might result in n
>>> finalizations and n+1 initializations (n>=0) of the same thing.
>> 
>> Aren't tasks limited types by definitions?
>
> Yes, they are.
>
>> In which case compiler
>> should be giving error message..
>
> Ada 2005 introduced "Pickwickian" functions "returning" limited objects,
> in-place, upon initialization. In the example, the result task of
> Interesting, being constructed in the object X, is first initialized, then
> finalized upon exception propagation and, finally, re-initialized
> again.

No, that's not the right way to look at it.  There is no single X
that is being [re]initialized twice.

X is initialized (but never activated).  The exception causes it to be
terminated -- this part is from Ada 83.

Then a different object (also called X) is created.
On successful return, this object becomes the result
object of the function -- which is also called X (the
one declared in Return_Task.  This task is activated
when Return_Task reaches its "begin".

>... I
> suggest that the example (if legal) should hang forever, because to
> finalize T one has to have a rendezvous with its entry A.
>
> All this is confusing and counterintuitive, at least. I mean both
> "Pickwickian" functions and the semantics return statements.

Well, I don't think so, but anyway, this is the only way
return of limited types can make sense.  The Ada 83 way
(return is by copy, even for limited) is just wrong.
And the Ada 95 way (return by reference) is confusing
and nearly useless.

- Bob

Re: another way to shoot yourself in the foot?

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Tue, 24 Jun 2008 07:59:35 -0700 (PDT), Adam Beneschan wrote:
>
>> I've probably lost the plot of this thread.  But in regards to the
>> example, I think the example is "no".  The semantics should be exactly
>> the same as if Interesting's body were simply "return X : T;".  The
>> first extended return statement that raises an exception doesn't have
>> any effect, in terms of starting a new task or anything like that,
>> because the RM explicitly says that task activation doesn't occur
>> until after the function returns (6.5(7)).
>
> OK, then the notorious problem of Ada 95, that a task cannot be
> initialized, in the sense that upon initialization you could pass
> parameters to it via a rendezvous, is still there.

The way to initialize tasks in Ada 95 and Ada 2005 is to pass
discriminants to the task.

>... "Constructing functions"
> do not help here, because you cannot engage a rendezvous before return. Too
> bad.

You can pass discrims whether you use constructor functions or not.

> Tasks finalization does not work either, because there is no destructing
> functions ("malfunctions" to use the name Robert Duff suggested (:-))
> anyway.

I'm not sure what the issue is, here.  Masters wait for their dependent
tasks to terminate (or be "ready" to terminate -- at a terminate
alternative) BEFORE the task objects are finalized.  So when a task
object is finalized, it is already terminated, so it doesn't make sense
to rendezvous with it.

> Task as a component is still no runner...

- Bob

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Tue, 24 Jun 2008 13:20:54 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Tue, 24 Jun 2008 07:59:35 -0700 (PDT), Adam Beneschan wrote:
>>
>>> I've probably lost the plot of this thread.  But in regards to the
>>> example, I think the example is "no".  The semantics should be exactly
>>> the same as if Interesting's body were simply "return X : T;".  The
>>> first extended return statement that raises an exception doesn't have
>>> any effect, in terms of starting a new task or anything like that,
>>> because the RM explicitly says that task activation doesn't occur
>>> until after the function returns (6.5(7)).
>>
>> OK, then the notorious problem of Ada 95, that a task cannot be
>> initialized, in the sense that upon initialization you could pass
>> parameters to it via a rendezvous, is still there.
> 
> The way to initialize tasks in Ada 95 and Ada 2005 is to pass
> discriminants to the task.

It is a very limited way, and in any case semantically it is different from
initialization parameters. A parameter is not required to outlive
initialization, while a discriminant is. Logically discriminant is a
constraint, it is by no way a parameter.

>> Tasks finalization does not work either, because there is no destructing
>> functions ("malfunctions" to use the name Robert Duff suggested (:-))
>> anyway.
> 
> I'm not sure what the issue is, here.  Masters wait for their dependent
> tasks to terminate (or be "ready" to terminate -- at a terminate
> alternative) BEFORE the task objects are finalized.  So when a task
> object is finalized, it is already terminated, so it doesn't make sense
> to rendezvous with it.

Nope, it makes a lot of sense, but it just does not work. Because a task
rarely knows if it should complete. The enclosing object does not expect
its components to prematurely finalize themselves. It is just a bad design
turned upside down:

   task type Foo is
      Start_Up (...);
      Shut_Down (...);
   end Foo;

   type T is new Ada.Finalization.Limited_Controlled with record
      X : Foo; -- No chance to make this working
      ...

There is no other option than to use access to task instead:

   type Foo_Ptr is access Foo;
   type T is new Ada.Finalization.Limited_Controlled with record
      X : Foo_Ptr; -- This is OK, but more C++ than Ada!
      ...

   procedure Initialize (Obj : in out T) is
      procedure Free is new Ada.Unchecked_Deallocation (Foo, Foo_Ptr);
   begin
      Obj.X := new Foo;
      Obj.X.Start_Up (...);
   exception
      when others => -- We don't want it leaking, right?
         Free (Obj.X); -- Probably this will hang, nevertheless...
         raise;
   end Initialize;

   procedure Finalize (Obj : in out T) is
      procedure Free is new Ada.Unchecked_Deallocation (Foo, Foo_Ptr);
   begin
      Obj.X.Shut_Down (...);
      Free (Obj.X);
   exception
      when others =>
         Free (Obj.X);
         raise;
   end Finalize;

A quite intrusive pattern, isn't it?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> Well, I don't think so, but anyway, this is the only way
> return of limited types can make sense.  The Ada 83 way
> (return is by copy, even for limited) is just wrong.
> And the Ada 95 way (return by reference) is confusing
> and nearly useless.

I don't know about "nearly useless". The only thing you could do with a limited 
function result in Ada 95 (and Ada 83) was pass it to a subprogram or entry. 
There are times when that is useful.

The new way seems to be biased towards build in place for object initialization.

-- 
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65

Re: another way to shoot yourself in the foot?

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Robert A Duff wrote:
>> Well, I don't think so, but anyway, this is the only way
>> return of limited types can make sense.  The Ada 83 way
>> (return is by copy, even for limited) is just wrong.
>> And the Ada 95 way (return by reference) is confusing
>> and nearly useless.
>
> I don't know about "nearly useless". The only thing you could do with a
> limited function result in Ada 95 (and Ada 83) was pass it to a
> subprogram or entry.

Not quite the "only" -- you could rename it.

> ...There are times when that is useful.

But in Ada 95, if you say:

    P(F(...));

where F returns limited, you are not passing a limited object,
but an implicit reference to some object that already existed before the
call to F.  You can do that more clearly by having F return
an access type.  I really think return-by-ref was a mistake.
Too bad we didn't think of it in 1992.  For that matter, too
bad JDI didn't think of it in 1980. ;-)

> The new way seems to be biased towards build in place for object
> initialization.

Well, there are only two ways a function call can be used: to initialize
a new object, or to update an existing object (i.e. on the right-hand
side of an assignment statement).  But don't forget there are a dozen or
so different ways of creating new objects (components, parameters,
parent parts of aggregates, etc).  All of these are allowed for
build-in-place function calls.  The only thing that's not allowed is the
assignment statement.

You can still say:

    P(F(...));

where F returns a limited type.  Yes, there's a new object being created
(the formal parameter of P), and F is being used to initialize that
object (in place!).  In Ada 2005, functions always return newly-created
objects, which I think is appropriate.

A couple more examples:

    X : Array_Of_Lim := (1..10 => F(...));

    if F(...).Flag then ...

The last one is pretty silly -- it creates a new limited object,
grabs a boolean flag out of it, and then throws the whole thing
away.

- Bob

Re: another way to shoot yourself in the foot?

[Ludovic Brenta]

Robert A Duff writes:
> But in Ada 95, if you say:
> 
>     P(F(...));
> 
> where F returns limited, you are not passing a limited object,
> but an implicit reference to some object that already existed before the
> call to F.
[...]
> In Ada 2005, functions always return newly-created objects, which I
> think is appropriate.

This makes me wonder whether there is an actual difference in the way
the compiler handles such returns.  For example, has GNAT changed a
lot in this area?  Do the Ada 95 and Ada 2005 compatibility modes use
antirely different compilation strategies?

>     if F(...).Flag then ...
>
> The last one is pretty silly -- it creates a new limited object,
> grabs a boolean flag out of it, and then throws the whole thing
> away.

Yes but "grabbing a boolean flag" might consist in passing the limited
object as a parameter to a primitive function named Flag, which might
then pass it down to any number of subprograms with all sorts of side
effects.  One could write an arbitrarily large program like this :)

-- 
Ludovic Brenta.

Re: another way to shoot yourself in the foot?

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> Not quite the "only" -- you could rename it.

True. I forgot that one.

> But in Ada 95, if you say:
> 
>     P(F(...));
> 
> where F returns limited, you are not passing a limited object,
> but an implicit reference to some object that already existed before the
> call to F.  You can do that more clearly by having F return
> an access type.  I really think return-by-ref was a mistake.
> Too bad we didn't think of it in 1992.  For that matter, too
> bad JDI didn't think of it in 1980. ;-)

Of course you're passing a reference, since limited types are always passed by 
reference (since Ada 95). But I don't think that the object had to exist before 
the call to F:

procedure Task_Return_Test is
    package Wrap is
       task type T;

       function F return T;
    end Wrap;

    package body Wrap is
       type T_Ptr is access T;

       function F return T is
          R : T_Ptr := new T;
       begin -- F
          return R.all;
       end F;

       task body T is
          -- null;
       begin -- T
          null;
       end T;
    end Wrap;

    procedure P (V : in Wrap.T) is
       -- null;
    begin -- P
       null;
    end P;
begin -- Task_Return_Test
    P (V => Wrap.F);
end Task_Return_Test;

This is valid Ada 95, according to a compiler.

> Well, there are only two ways a function call can be used: to initialize
> a new object, or to update an existing object (i.e. on the right-hand
> side of an assignment statement).  But don't forget there are a dozen or
> so different ways of creating new objects (components, parameters,
> parent parts of aggregates, etc).  All of these are allowed for
> build-in-place function calls.  The only thing that's not allowed is the
> assignment statement.
> 
> You can still say:
> 
>     P(F(...));
> 
> where F returns a limited type.  Yes, there's a new object being created
> (the formal parameter of P), and F is being used to initialize that
> object (in place!).  In Ada 2005, functions always return newly-created
> objects, which I think is appropriate.

I learned that functions return objects, and in this case the object is the 
actual parameter to P, not the formal parameter. The object is anonymous. Maybe 
that rule's changed for limited parameters in current Ada. But I take your point 
that F can be regarded as always building in place, wherever that place may be.

>     if F(...).Flag then ...
> 
> The last one is pretty silly -- it creates a new limited object,
> grabs a boolean flag out of it, and then throws the whole thing
> away.

It's also an example in which the object that F builds in is clearly anonymous, 
unlike the parameter of P above.

-- 
Jeff Carter
"So if I understand 'The Matrix Reloaded' correctly, the Matrix is
basically a Microsoft operating system--it runs for a while and
then crashes and reboots. By design, no less. Neo is just a
memory leak that's too hard to fix, so they left him in ... The
users don't complain because they're packed in slush and kept
sedated."
Marin D. Condic
65

Re: another way to shoot yourself in the foot?

[Robert A Duff]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Robert A Duff writes:
>> But in Ada 95, if you say:
>> 
>>     P(F(...));
>> 
>> where F returns limited, you are not passing a limited object,
>> but an implicit reference to some object that already existed before the
>> call to F.
> [...]
>> In Ada 2005, functions always return newly-created objects, which I
>> think is appropriate.
>
> This makes me wonder whether there is an actual difference in the way
> the compiler handles such returns.

Yes, very different in the case of limited types.

In Ada 83, F returns its result by copy, and the address of this copy is
passed to P.

In Ada 95, F returns the address of some object outside F,
and this address is passed to P.

In Ada 2005, the formal of P is allocated at the call site,
and the address of that is passed to F, which puts its result
there.  This address is then passed to P.  Except if the size
is not known at the call site, things get more complicated.
And if controlled types or task types are involved, then extra
implicit parameters are passed to F (who is the master of this
thing, who is supposed to activate it, etc).

>...For example, has GNAT changed a
> lot in this area?

Yes.  We're talking about months of work by at least two people at
AdaCore (one of whom was me).

>...Do the Ada 95 and Ada 2005 compatibility modes use
> antirely different compilation strategies?

Yes.  And if you try to mix them, it won't work.

>>     if F(...).Flag then ...
>>
>> The last one is pretty silly -- it creates a new limited object,
>> grabs a boolean flag out of it, and then throws the whole thing
>> away.
>
> Yes but "grabbing a boolean flag" might consist in passing the limited
> object as a parameter to a primitive function named Flag, which might
> then pass it down to any number of subprograms with all sorts of side
> effects.  One could write an arbitrarily large program like this :)

Good point.  I was talking about the case where the result is a limited
record with a component called Flag, which is silly.  You are talking
about the case where Flag is a primitive operation, which is not silly.

- Bob

Re: another way to shoot yourself in the foot?

[Robert A Duff]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> Of course you're passing a reference, since limited types are always
> passed by reference (since Ada 95). But I don't think that the object
> had to exist before the call to F:

Yes, you're right.  I was wrong to say it had to exist before.
To give the precise answer, I'd have to talk about "accessibility
levels".  Basically, in Ada 95, F returns an implicit reference
to something "outside of" F -- outside in the sense of having
a longer potential lifetime.

In Ada 2005, it's just the opposite -- F returns something created by F.

> procedure Task_Return_Test is
>    package Wrap is
>       task type T;
>
>       function F return T;
>    end Wrap;
>
>    package body Wrap is
>       type T_Ptr is access T;
>
>       function F return T is
>          R : T_Ptr := new T;
>       begin -- F
>          return R.all;
>       end F;
>
>       task body T is
>          -- null;
>       begin -- T
>          null;
>       end T;
>    end Wrap;
>
>    procedure P (V : in Wrap.T) is
>       -- null;
>    begin -- P
>       null;
>    end P;
> begin -- Task_Return_Test
>    P (V => Wrap.F);
> end Task_Return_Test;
>
> This is valid Ada 95, according to a compiler.

It is also valid Ada 95, according to the Ada 95 Reference Manual.  ;-)
It is illegal in Ada 2005.

I claim that it would be clearer (in Ada 95) for F to return an
access-to-T, since that's what is really going on.  And in Ada 2005,
you have to do it that way.

>> Well, there are only two ways a function call can be used: to initialize
>> a new object, or to update an existing object (i.e. on the right-hand
>> side of an assignment statement).  But don't forget there are a dozen or
>> so different ways of creating new objects (components, parameters,
>> parent parts of aggregates, etc).  All of these are allowed for
>> build-in-place function calls.  The only thing that's not allowed is the
>> assignment statement.
>> You can still say:
>>     P(F(...));
>> where F returns a limited type.  Yes, there's a new object being
>> created
>> (the formal parameter of P), and F is being used to initialize that
>> object (in place!).  In Ada 2005, functions always return newly-created
>> objects, which I think is appropriate.
>
> I learned that functions return objects, and in this case the object is
> the actual parameter to P, not the formal parameter. The object is
> anonymous.

No, that's not the right way to think about it (for limited types!).
The whole point of build-in-place is that the object created inside the
function at the "return", and the function result, and the actual
parameter of P, and the formal parameter of P -- are all one and the
same object!

If F said "return G(...);" and G said "return H(...);" we've got a whole
bunch of objects that are one and the same object, in the end.

As somebody mentioned, there's an AI that tries to clarify the wording
on this point.

>...Maybe that rule's changed for limited parameters in current
> Ada. But I take your point that F can be regarded as always building in
> place, wherever that place may be.

OK.

>>     if F(...).Flag then ...
>> The last one is pretty silly -- it creates a new limited object,
>> grabs a boolean flag out of it, and then throws the whole thing
>> away.
>
> It's also an example in which the object that F builds in is clearly
> anonymous, unlike the parameter of P above.

Right, at the call site, it's anonymous.  It might have a name inside F
(if F said "return Result : ...") or be anonymous inside F (if F said
"return <expression>"), but either way, it's one object.

- Bob

Re: another way to shoot yourself in the foot?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> The enclosing object does not expect
> its components to prematurely finalize themselves. It is just a bad design
> turned upside down:

It seems like everyone wishes to force dynamic context
information to be expressible as static type features,
together with implicit callback operations from
Controlled'Class.

Why not use plain old scopes when establishing context
for objects? Or generic elaboration.

Is anything wrong with having all of lifetime, startup and
cleanup of objects controlled by a combination of: nesting,
making calls, handling exceptions, and scoping?
Would Finalize be superior when calls from within it will
have to refer to all kinds of other data anyway,
even indirectly?

The Controlled subprograms are linked to a single type.
From what I know about Aspect Oriented Programming, it shows
that building modules around a single type does not always
yield the right abstraction: When the thing is seen from a
different angle, the type should have a different interface.
From yet another viewpoint, the type's operations should
cooperate differently.  In still another perspective
some abstraction is not represented by this type alone.
Instead, it would be represented by some combination of
this type and another type.

And now automatic operations like Initialize and Finalize,
hooked on a single type (and possibly discriminants---does
GNAT like at last :-) are supposed to be the solution of
all data management?

Re: another way to shoot yourself in the foot?

[Georg Bauhaus]

Ludovic Brenta wrote:
> Robert A Duff writes:

> 
>>     if F(...).Flag then ...
>>
>> The last one is pretty silly -- it creates a new limited object,
>> grabs a boolean flag out of it, and then throws the whole thing
>> away.
> 
> Yes but "grabbing a boolean flag" might consist in passing the limited
> object as a parameter to a primitive function named Flag, which might
> then pass it down to any number of subprograms with all sorts of side
> effects.  One could write an arbitrarily large program like this :)

A simple one crossed my mind immediately,

   if Earth(...).Result = 42 then ...

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Wed, 25 Jun 2008 01:35:17 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> The enclosing object does not expect
>> its components to prematurely finalize themselves. It is just a bad design
>> turned upside down:
> 
> It seems like everyone wishes to force dynamic context
> information to be expressible as static type features,
> together with implicit callback operations from
> Controlled'Class.

I am not sure what you mean. The problem of Ada is that some types are more
types than others. There shall be no such irregularities.

> Why not use plain old scopes when establishing context
> for objects?

Egh? Are you going to throw record and array types out of the language?
Back to 60s? (:-))

> Or generic elaboration.
> 
> Is anything wrong with having all of lifetime, startup and
> cleanup of objects controlled by a combination of: nesting,
> making calls, handling exceptions, and scoping?

Again, I am not sure about the meaning of above, but the lifetime of an
object is controlled by the relation to its "master." Whether the master is
the scope of a block statement or the scope of the enclosing object is not
that relevant.

> Would Finalize be superior when calls from within it will
> have to refer to all kinds of other data anyway,
> even indirectly?

It *shall* be. It is merely a matter of contract. When Finalize is an
operation of the type T, then necessarily, the object passed to it must be
of T. The rest follows.

> The Controlled subprograms are linked to a single type.

But, but it is a poor design. Constructor/destructor is bound to the class,
obviously. A class is a set of types.

> From what I know about Aspect Oriented Programming, it shows
> that building modules around a single type does not always
> yield the right abstraction: When the thing is seen from a
> different angle, the type should have a different interface.
> From yet another viewpoint, the type's operations should
> cooperate differently.  In still another perspective
> some abstraction is not represented by this type alone.
> Instead, it would be represented by some combination of
> this type and another type.

I am sorry, but this makes no sense to me. Forget about Ada's interfaces.
Interface is a [abstract] type, period. Whatever interfaces an object might
fulfill, they all are supertypes of the object's type. Where is a problem?

> And now automatic operations like Initialize and Finalize,
> hooked on a single type (and possibly discriminants---does
> GNAT like at last :-) are supposed to be the solution of
> all data management?

Yes they are. Note that constructing/destructing hooks have different rules
of composition, like aggregates and assignments have. They are not
overridden they are extended. (Ada's Finalization is bogus, alas).

Technically S derived from T has a constructor. This constructor is
generated by the compiler. It has hooks in order to initialize S and T. The
hook of T is called before the hook of S. If S'Class is constructed. Then
two new hooks are called:

1.  T -- post: can use it as T
2.  S -- post: can use it as S
3.  T'Class -- post: can use it as T'Class, e.g. dispatch to the methods of
4.  S'Class -- post: can use it as S'Class, e.g. dispatch

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:

>> And now automatic operations like Initialize and Finalize,
>> hooked on a single type (and possibly discriminants---does
>> GNAT like at last :-) are supposed to be the solution of
>> all data management?
> 
> Yes they are. Note that constructing/destructing hooks have different rules
> of composition, like aggregates and assignments have. They are not
> overridden they are extended. (Ada's Finalization is bogus, alas).

Just one point ad hoc.
Taking the notion of construction further, define the concept
of initialization.

In general, initialization of an object Obj_1 of type T1
may logically be related to the observable state of Obj_2
of type T2, where observable state means result of operations
or (component) values. As these states change while a
program is running, the dependences may not always be the same.

Obj_1's initialization may logically depend on

   F(Obj_1, ..., Obj_N),

or more generally on

   F(G_1(Obj_1_1, ..., Obj_M_1), ... G_J(Obj_1_J, ..., Obj_M_J)).

for some finite sets of objects and functions.
Basically, on anything that can be programmed into an expression
used for initializing. It may be cross unit, involve P98.T19 or not,
or A.B.T42 only if G_17(Obj_127) > 666 etc.

This "net of dependence" would mean that a constructor will have
to adjust its behavior to the current state of the program. Adjustment
may be realized through dispatching to a load of objects, other
constructors, etc. etc. etc.  IOW, every constructor becomes a huge
factory in disguise.  It has to perform case distinction.
How is this seemingly special construction different from just
normal programming?  The only added value of constructors that
I can see is that I can point to a few functions which "point to"
all this. A good addition, and not a small one. But should we
therefore abandon all other means of initializing things?

If construction turns out to be mostly normal programming, why
not use plain old language features in addition to specialized
constructor programming? For example, use local scopes and
visibility for providing (computed) initial values, even though
a scope is not an operation of a type, like a construtor function
is.

Re: another way to shoot yourself in the foot?

[Dmitry A. Kazakov]

On Wed, 25 Jun 2008 12:32:05 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:
> 
>>> And now automatic operations like Initialize and Finalize,
>>> hooked on a single type (and possibly discriminants---does
>>> GNAT like at last :-) are supposed to be the solution of
>>> all data management?
>> 
>> Yes they are. Note that constructing/destructing hooks have different rules
>> of composition, like aggregates and assignments have. They are not
>> overridden they are extended. (Ada's Finalization is bogus, alas).
> 
> Just one point ad hoc.
> Taking the notion of construction further, define the concept
> of initialization.
> 
> In general, initialization of an object Obj_1 of type T1
> may logically be related to the observable state of Obj_2
> of type T2, where observable state means result of operations
> or (component) values. As these states change while a
> program is running, the dependences may not always be the same.
> 
> Obj_1's initialization may logically depend on
> 
>    F(Obj_1, ..., Obj_N),
> 
> or more generally on
> 
>    F(G_1(Obj_1_1, ..., Obj_M_1), ... G_J(Obj_1_J, ..., Obj_M_J)).
> 
> for some finite sets of objects and functions.
> Basically, on anything that can be programmed into an expression
> used for initializing. It may be cross unit, involve P98.T19 or not,
> or A.B.T42 only if G_17(Obj_127) > 666 etc.
> 
> This "net of dependence" would mean that a constructor will have
> to adjust its behavior to the current state of the program. Adjustment
> may be realized through dispatching to a load of objects, other
> constructors, etc. etc. etc.  IOW, every constructor becomes a huge
> factory in disguise.  It has to perform case distinction.
> How is this seemingly special construction different from just
> normal programming?  The only added value of constructors that
> I can see is that I can point to a few functions which "point to"
> all this. A good addition, and not a small one. But should we
> therefore abandon all other means of initializing things?
> 
> If construction turns out to be mostly normal programming, why
> not use plain old language features in addition to specialized
> constructor programming? For example, use local scopes and
> visibility for providing (computed) initial values, even though
> a scope is not an operation of a type, like a construtor function
> is.

Because of. Information hiding. You want to promote the object as an opaque
abstract type. It is the type which is responsible for object construction.
It is just not the user's business. This is a pragmatic argument of
avoiding a huge distributed overhead of proper initialization of all
instances the given type might ever have. It is a maintenance disaster if
something gets changed.

The theoretical argument is that initialization is not equivalent to
construction. Well, it is, when types are ignored. But types does not exist
at run-time anyway. Type is an abstraction used to annotate untyped machine
code. So while the machine code might appear same, semantically it is
different [*]. Now, within a typed framework, the constructor cannot be
decomposed into subprograms, it fundamentally cannot. There is no way to
convert raw junk of bits into the same bits having the meaning of an object
of the given type.

------------
* The simplest way to illustrate this in Ada is:

   type Int is new Integer; -- The code will be same

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: another way to shoot yourself in the foot?

[Adam Beneschan]

On Jun 24, 1:31 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:

> where F returns limited, you are not passing a limited object,
> but an implicit reference to some object that already existed before the
> call to F.  You can do that more clearly by having F return
> an access type.  I really think return-by-ref was a mistake.
> Too bad we didn't think of it in 1992.  For that matter, too
> bad JDI didn't think of it in 1980. ;-)

For that matter, too bad Grace Hopper didn't think of packages,
procedures with parameters, etc., in 1959!  :-)

Unfortunately, sometimes progress only comes by learning from our
screwups.  I think I can state with certainty that there is some
absolutely essential feature X such that a comp.lang.ada poster will
legitimately be able to say, at some point in the future, "too bad
Taft, Brukardt, Duff, et al. didn't think of X in 2005".

Oh, well...

                                 -- Adam

Re: another way to shoot yourself in the foot?

[Colin Paul Gloster]

Jeffrey R. Carter <spam.jrcarter.not@spam.acm.org> wrote in message 
news:brz7k.167222$TT4.46081@attbi_s22 ...
|------------------------------------------------------------------------------|
|" Robert A Duff wrote: 
|
|[..] 
|
| 
|
|> As Dmitry pointed out, with this idea, there's no need for the "return 
|
|> Result;". 
|
| 
|
| True, but I find it easier to understand the function if it has the 
explicit |
| "return Result;"," 
|
|------------------------------------------------------------------------------|

I believe that "return Result;" is fine. It is true that it is not
necessary, in much the same way that IN is redundant for a function's
mode. Some people had criticized IN for a function for the same
reason, but people who use many languages (or instead, who do not
program much) should not be forced to memorize all the ramifications
of particular language semantics if a piece of excess syntax makes it
clear for them.

|------------------------------------------------------------------------------|
|" even though I came to Ada from a Pascal background." 
|
|------------------------------------------------------------------------------|

Speaking of which, after my unsuccessful job application to you
earlier this year (thank you for having the decency to treat my
application properly though, as did other some contributors to this
newsgroup when I applied to them, but unfortunately a number of others
were disrespectful) I very recently joined a group of people who on
average do not work predominantly as programmers. The languages which
I have been told are in some of their backgrounds are FORTRAN and C++,
and we have FORTRAN and C++ codebases which I should improve. How
better to start than by porting to Ada!?

In a room I share with some of them there are some FORTRAN books, but
there are also many Pascal books so maybe someone based here is familiar
with Pascal (but not everyone who programs and uses this room is
involved in the smae project, so I must check). I plan to glance at
some of these books and maybe eventually read them to determine which
would be worthwhile to help colleagues learn enough Ada (I do not need
them to acquire an advanced level of skill with Ada). I could use
K.N. King's "Dr. Dobb's Journal" article "Ada for Pascal Programmers",
WWW.DDJ.com/architect/184407995
, but if you have any tips they may be helpful. Available books
include:
Jensen and Wirth, "Pascal: User Manual and Report", third edition;
Ledgard, "Professional Pascal: Essays on the Practice of Programming";
McGregor and Watt, "Pascal for Science and Engineering";
Ledgard with Tauer, "Pascal with Excellence: Programming Proverbs";
"Turbo Pascal for the Mac: User's Guide and Reference Manual";
Savitch, "Pascal: An Introduction for the Art and Science of
Programming";
many Pascal books which can be found by searching on
HTTP://WebOPAC.SIB.UC.Pt/
including one by Dr. Findlay who has become a critic of Pascal and who
did not have the decency it seems to dignify my application to him
with a response (but at least that was better than some of the abuse I
received by email from other contributors to this newsgroup);
and a small collection of Ada books (at least one of which I have
read and is very good despite predating Ada 83) so I list ones which I
have not read:
Autor Berge, J.-M.
Tulo ADA avec le sourire / J.-M. Berge.
Publicao/Produo Paris : Presses Polytechniques Romandes, 1989.
Descrio fica 400 p.
SISBN 2880741645
Outro autor Olive, L.-O. Donzelle V, autor.
 Rouillard, J, autor.

(yes, someone in the group has studied French);

and

Autor Gehani, Narain.
Tulo Ada : an advanced introduction / Narain Gehani.
Publicao/Produo Englewood Cliffs : Prentice-Hall, cop. 1983.
Descri-o fica XVII, 327 p : il.
SISBN 0130039624
Assunto Linguagem ADA.

Regards,
Colin Paul Gloster 

Re: another way to shoot yourself in the foot?

[(see below)]

On 04/07/2008 21:52, in article g4m2gb$3b3$1@registered.motzarella.org,
"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote:

> many Pascal books which can be found by searching on
> HTTP://WebOPAC.SIB.UC.Pt/
> including one by Dr. Findlay who has become a critic of Pascal and who
> did not have the decency it seems to dignify my application to him
> with a response (but at least that was better than some of the abuse I
> received by email from other contributors to this newsgroup);

Are you referring to me? If so:

(a) I am not "Dr" Findlay,

(b) I am not an employer, and

(c) I have no idea what you are talking about.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: another way to shoot yourself in the foot?

[Gary Scott]

Colin Paul Gloster wrote:
> Jeffrey R. Carter <spam.jrcarter.not@spam.acm.org> wrote in message 
> news:brz7k.167222$TT4.46081@attbi_s22 ...
> |------------------------------------------------------------------------------|
> |" Robert A Duff wrote: 
> |
> |[..] 
> |
> | 
> |
> |> As Dmitry pointed out, with this idea, there's no need for the "return 
> |
> |> Result;". 
> |
> | 
> |
> | True, but I find it easier to understand the function if it has the 
> explicit |
> | "return Result;"," 
> |
> |------------------------------------------------------------------------------|
> 
> I believe that "return Result;" is fine. It is true that it is not
> necessary, in much the same way that IN is redundant for a function's
> mode. Some people had criticized IN for a function for the same
> reason, but people who use many languages (or instead, who do not
> program much) should not be forced to memorize all the ramifications
> of particular language semantics if a piece of excess syntax makes it
> clear for them.
> 
> |------------------------------------------------------------------------------|
> |" even though I came to Ada from a Pascal background." 
> |
> |------------------------------------------------------------------------------|
> 
> Speaking of which, after my unsuccessful job application to you
> earlier this year (thank you for having the decency to treat my
> application properly though, as did other some contributors to this
> newsgroup when I applied to them, but unfortunately a number of others
> were disrespectful) I very recently joined a group of people who on
> average do not work predominantly as programmers. The languages which
> I have been told are in some of their backgrounds are FORTRAN and C++,
> and we have FORTRAN and C++ codebases which I should improve. How
> better to start than by porting to Ada!?

Or Fortran 95 or Fortran 2003 (ok, 2003 is nearly available)
<snip>
> Regards,
> Colin Paul Gloster 
> 
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: another way to shoot yourself in the foot?

[Colin Paul Gloster]

On Fri, 4 Jul 2008, Bill Findlay wrote:

|------------------------------------------------------------------------|
|"On 04/07/2008 21:52, in article g4m2gb$3b3$1@registered.motzarella.org,|
|"Colin Paul Gloster" <Colin_Paul_Gloster@ACM.org> wrote:                |
|                                                                        |
|> many Pascal books which can be found by searching on                  |
|> HTTP://WebOPAC.SIB.UC.Pt/                                             |
|> including one by Dr. Findlay who has become a critic of Pascal and who|
|> did not have the decency it seems to dignify my application to him    |
|> with a response (but at least that was better than some of the abuse I|
|> received by email from other contributors to this newsgroup);         |
|                                                                        |
|Are you referring to me? If so:"                                        |
|------------------------------------------------------------------------|

Dear Bill Findlay,

I owe you an apology. In March 2008 I tried to email
BillFindlay@BlueYonder.co.UK (which bounced but I checked for the
bounce message for the first time today) despite your rather clear tip
on what the real email address is.

|------------------------------------------------------------------------|
|"(a) I am not "Dr" Findlay,"                                            |
|------------------------------------------------------------------------|

Another mistake on my part. Sorry once again.

|------------------------------------------------------------------------|
|"[..]                                                                   |
|                                                                        |
|(c) I have no idea what you are talking about."                         |
|------------------------------------------------------------------------|

Your bafflement was justified.

|------------------------------------------------------------------------|
|"--                                                                     |
|Bill Findlay                                                            |
|<surname><forename> chez blueyonder.co.uk                               |
|"                                                                       |
|------------------------------------------------------------------------|

Oops.

Yours sincerely with best regards,
Colin Paul Gloster

Re: another way to shoot yourself in the foot?

[Colin Paul Gloster]

Gary Scott <garylscott@sbcglobal.net> wrote in message 
news:NPKbk.14568$N87.10457@nlpi068.nbdc.sbc.com ...
|-------------------------------------------------------------------|
|"Colin Paul Gloster wrote:                                         |
|[..]                                                               |
|> and we have FORTRAN and C++ codebases which I should improve. How|
|> better to start than by porting to Ada!?                         |
|                                                                   |
|Or Fortran 95 or Fortran 2003 (ok, 2003 is nearly available)       |
|<snip>                                                             |
|> Regards,                                                         |
|> Colin Paul Gloster                                               |
|>                                                                  |
|>                                                                  |
|                                                                   |
|                                                                   |
|--                                                                 |
|                                                                   |
|Gary Scott"                                                        |
|-------------------------------------------------------------------|

Perhaps you would care to look again at my list posted on 16 Aug 2007
09:16:21 GMT in the thread "Interested about number crunching in Ada":

|---------------------------------------------------------------------------------|
|"In news:ZlSwi.47515$xx1.37834@newsfe09.phx timestamped Wed, 15 Aug 
|
|2007 23:43:02 -0700, "Nasser Abbasi" <n...@12000.org> posted: 
|
||-------------------------------------------------------------------------------||
||"[..] 
||
|| 
||
||I can understand one choosing Fortran over Ada, simply due to the inertia 
||
||that Fortran has in this domain, and the huge amount of existing Fortran 
||
||code out there." 
||
||-------------------------------------------------------------------------------||
| 
|
|Unfortunately so, and a reason to be sceptical of supposedly 
|
|scientific results obtained numerically. Of course, if someone can not 
|
|program well in Fortran and tries to program in Ada, the results would 
|
|still be subject to suspicion. 
|
| 
|
||-------------------------------------------------------------------------------||
||" But from a language point of view, I think Ada is definitely 
||
||better for numerical work than Fortran, but having a better language is 
not    ||
||enough in the real world. 
||
|| 
||
||Nasser" 
||
||-------------------------------------------------------------------------------||
| 
|
|True again. Some examples from news:comp.lang.fortran from June 2007 
|
|and July 2007 of problems related to using Fortran... 
|
|news:qLmdnRLQp_-G4_vbnZ2dnUVZ8qWhnZ2d@eclipse.net.uk 
|
|; 
|
|news:1183085026.130385.275600@w5g2000hsg.googlegroups.com 
|
|; 
|
|news:2007070314244816807-gsande@worldnetattnet 
|
|; 
|
|news:1i0o9u8.1enugm5jfa16aN%nospam@see.signature 
|
|; 
|
|news:5evopfF38kh8jU1@mid.individual.net 
|
|; 
|
|news:5f8t9pF39qj8tU1@mid.individual.net 
|
|; 
|
|news:468eae65$0$63187$a726171b@news.hal-pc.org 
|
|; 
|
|news:1hzmym2.geqzg2np30c0N%nospam@see.signature 
|
|; 
|
|news:1184354146.636131.244960@r34g2000hsd.googlegroups.com 
|
|; 
|
|news:1i13nsb.nie62b18grpq6N%nospam@see.signature 
|
|; 
|
|news:1i0vm88.ad0dvommy5v1N%nospam@see.signature 
|
|; 
|
|news:Tdmdnb8ULb0qehLbnZ2dnUVZ_r-onZ2d@comcast.com 
|
|; 
|
|news:yOUji.292583$p47.61895@bgtnsc04-news.ops.worldnet.att.net 
|
|; 
|
|news:1i0w2b8.1yg3e511o0w59vN%nospam@see.signature 
|
|; 
|
|news:46902291$1@news.meer.net 
|
|; 
|
|news:1i09cof.1u7n4sxq7c0cvN%nospam@see.signature 
|
|; 
|
|news:f6strg$kbr$1@online.de 
|
|; 
|
|news:f6voik$tb$2@online.de 
|
|; 
|
|news:ldmdnbU9Iec5b-TbnZ2dnUVZ_oavnZ2d@comcast.com 
|
|; 
|
|news:1i01upq.bgpxxo1o0duerN%nospam@see.signature 
|
|; 
|
|news:1182983727.411268.298580@g4g2000hsf.googlegroups.com 
|
|; 
|
|news:2007062720040816807-gsande@worldnetattnet 
|
|; 
|
|news:1i0dkkl.1jlhd8111v4wv8N%nospam@see.signature 
|
|; 
|
|news:94Dgi.9102$c06.8367@newssvr22.news.prodigy.net 
|
|; 
|
|news:M6Dgi.9103$c06.8464@newssvr22.news.prodigy.net 
|
|; 
|
|news:kNDgi.125855$Sa4.103793@bgtnsc05-news.ops.worldnet.att.net 
|
|; 
|
|news:1182994059.370009.275990@u2g2000hsc.googlegroups.com 
|
|; 
|
|news:l0Egi.236875$p47.120808@bgtnsc04-news.ops.worldnet.att.net 
|
|; 
|
|news:4683F0DF.2060806@cits1.stanford.edu 
|
|; 
|
|news:4683f755$0$63178$a726171b@news.hal-pc.org 
|
|; 
|
|news:w%Vgi.241677$p47.220353@bgtnsc04-news.ops.worldnet.att.net 
|
|; 
|
|news:46845483.3060407@cits1.stanford.edu 
|
|; 
|
|news:ajZgi.4784$cV.208@trnddc04 
|
|; 
|
|news:1182800003.825023.154970@p77g2000hsh.googlegroups.com 
|
|. 
|
| 
|
|Regards, 
|
|Colin Paul Gloster" 
|
|---------------------------------------------------------------------------------|

Let us not forget that the standardization body took different
directions in two of the latest attempts at an object-oriented Fortran
(though something similar could be said for Ada).

Regards,
Colin Paul 

Re: another way to shoot yourself in the foot?

[Gary Scott]

Colin Paul Gloster wrote:
> Gary Scott <garylscott@sbcglobal.net> wrote in message 
> news:NPKbk.14568$N87.10457@nlpi068.nbdc.sbc.com ...
> |-------------------------------------------------------------------|
> |"Colin Paul Gloster wrote:                                         |
> |[..]                                                               |
> |> and we have FORTRAN and C++ codebases which I should improve. How|
> |> better to start than by porting to Ada!?                         |
> |                                                                   |
> |Or Fortran 95 or Fortran 2003 (ok, 2003 is nearly available)       |
> |<snip>                                                             |
> |> Regards,                                                         |
> |> Colin Paul Gloster                                               |
> |>                                                                  |
> |>                                                                  |
> |                                                                   |
> |                                                                   |
> |--                                                                 |
> |                                                                   |
> |Gary Scott"                                                        |
> |-------------------------------------------------------------------|
<snip>
> || 
> ||
> ||I can understand one choosing Fortran over Ada, simply due to the inertia 
> ||
> ||that Fortran has in this domain, and the huge amount of existing Fortran 
> ||
> ||code out there." 

Better reason is that it is vastly improved in recent standards and 
continues to rapidly evolve.

> ||
> ||-------------------------------------------------------------------------------||
> | 
> |
> |Unfortunately so, and a reason to be sceptical of supposedly 
> |
> |scientific results obtained numerically. Of course, if someone can not 
> |
> |program well in Fortran and tries to program in Ada, the results would 
> |
> |still be subject to suspicion. 
> |
> | 
> |
> ||-------------------------------------------------------------------------------||
> ||" But from a language point of view, I think Ada is definitely 
> ||
> ||better for numerical work than Fortran, but having a better language is 
> not    ||
> ||enough in the real world. 

The odd syntax of Pascal-like languages annoys too many scientific 
programmers.

> ||
> || 
> ||
> ||Nasser" 
> ||
> ||-------------------------------------------------------------------------------||
> | 
> |
<snip> |
> |---------------------------------------------------------------------------------|
> 

My company has extensive Ada experience and has found it quite error 
prone, inefficient, and difficult to debug and maintain, and has 
switched almost entirely to C++.

> Let us not forget that the standardization body took different
> directions in two of the latest attempts at an object-oriented Fortran
> (though something similar could be said for Ada).

Yes, they thoughtfully surveyed dozens of other languages and cherry 
picked the best features.  They picked some from Ada, some from 
Modula...none from C/C++, but of course they added necessary 
interoperability.

> 
> Regards,
> Colin Paul 
> 
> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: another way to shoot yourself in the foot?

[Colin Paul Gloster]

I crosspost from news:comp.lang.ada to news:comp.lang.fortran .
Gary Scott posted in news:_wPbk.7600$L_.4566@flpi150.ffdc.sbc.com
on July 5th, 2008:
|-------------------------------------------------------------------------------------|
|"Colin Paul Gloster wrote:                                                           |
|> Gary Scott <garylscott@sbcglobal.net> wrote in message                             |
|> news:NPKbk.14568$N87.10457@nlpi068.nbdc.sbc.com ...                                |
|> |-------------------------------------------------------------------|              |
|> |"Colin Paul Gloster wrote:                                         |              |
|> |[..]                                                               |              |
|> |> and we have FORTRAN and C++ codebases which I should improve. How|              |
|> |> better to start than by porting to Ada!?                         |              |
|> |                                                                   |              |
|> |Or Fortran 95 or Fortran 2003 (ok, 2003 is nearly available)       |              |
|> |<snip>                                                             |              |
|> |> Regards,                                                         |              |
|> |> Colin Paul Gloster                                               |              |
|> |>                                                                  |              |
|> |>                                                                  |              |
|> |                                                                   |              |
|> |                                                                   |              |
|> |--                                                                 |              |
|> |                                                                   |              |
|> |Gary Scott"                                                        |              |
|> |-------------------------------------------------------------------|              |
|<snip>                                                                               |
|> ||                                                                                 |
|> ||                                                                                 |
|> ||I can understand one choosing Fortran over Ada, simply due to the inertia        |
|> ||                                                                                 |
|> ||that Fortran has in this domain, and the huge amount of existing Fortran         |
|> ||                                                                                 |
|> ||code out there."                                                                 |
|                                                                                     |
|Better reason is that it is vastly improved in recent standards and                  |
|continues to rapidly evolve."                                                        |
|-------------------------------------------------------------------------------------|

Could you please elaborate?

|-------------------------------------------------------------------------------------|
|"[..]                                                                                |
|                                                                                     |
|My company has extensive Ada experience and has found it quite error                 |
|prone, inefficient, and difficult to debug and maintain,"                            |
|-------------------------------------------------------------------------------------|

Could you please give examples?

|-------------------------------------------------------------------------------------|
|" and has                                                                            |
|switched almost entirely to C++."                                                    |
|-------------------------------------------------------------------------------------|

Why does Gary Scott's company use almost entirely C++ if Gary Scott recommended Fortran?

Does Gary Scott disagree with the following quotation from Matthew  B. Kennel
in news:slrnb19l3m.66u.mbkennelSPAMBEGONE@lyapunov.ucsd.edu
timestamped Fri, 3 Jan 2003 00:08:22 +0000 (UTC)?...
**************************************************************************
*"[..]                                                                   *
*                                                                        *
*And why is it "Fortran looking more like C++?"  If anything, it is much*
*more like Ada95 (certainly saner and cleaner than C++).                 *
*                                                                        *
*[..]"                                                                   *
**************************************************************************

Gary Scott posted on July 5th, 2008:
|-------------------------------------------------------------------------------------|
|"> Let us not forget that the standardization body took different                    |
|> directions in two of the latest attempts at an object-oriented Fortran             |
|> (though something similar could be said for Ada).                                  |
|                                                                                     |
|Yes, they thoughtfully surveyed dozens of other languages and cherry                 |
|picked the best features.  They picked some from Ada, some from                      |
|Modula...none from C/C++, but of course they added necessary                         |
|interoperability."                                                                   |
|-------------------------------------------------------------------------------------|

Gary Scott edited out all citations to newsgroup posts from circa 2007
which do not promote Fortran. Perhaps posters to
news:comp.lang.fortran would care to inform me as to whether or not
they are valid...

Dan Nagle posted with timestamp Fri, 29 Jun 2007 01:32:54 GMT:

$------------------------------------------------------------------$
$"[..]                                                             $
$                                                                  $
$The annex in the draft 08 standard detailing undefined behavior   $
$was added as a result of the activities of the OWG-V committee.   $
$The annex gets substantial additions with every meeting,          $
$it's harder than it appears to be to write.  The annex includes   $
$some entries that say "paragraph such-and-such lists a whole bunch$
$of stuff we don't try to describe" in addition to entries         $
$listing specific items."                                          $
$------------------------------------------------------------------$

Phillip Helbig posted with timestamp Tue, 10 Jul 2007 10:55:16 +0000 (UTC):

+----------------------------------------------------------------------------+
+"In article <469242ED.8FFA4...@earthlink.net>, Walter Spector               +
+                                                                            +
+                                                                            +
+<w6ws_xthiso...@earthlink.net> writes:                                      +
+> Phillip Helbig wrote:                                                     +
+> > I think I will put this function in a separate module and USE that in   +
+> > the main module (or only in the routine which needs it).  The name will +
+> > be hard-wired.  If desired, the user can edit this new module and       +
+> > recompile.                                                              +
+                                                                            +
+> You might consider simply placing an INTERFACE block in your              +
+> main module - which describes the function.  Then a user can easily       +
+> link in his own version.  In this case, his function does not need to     +
+> be in a module.  So you will not have a compilation dependency problem.   +
+                                                                            +
+                                                                            +
+                                                                            +
+True, but then there is no automatic check if the INTERFACE actually        +
+corresponds to the code.  With the routine in a module, the interface is    +
+automatically explicit and automatically correct."                          +
+----------------------------------------------------------------------------+

B. L. Massingill posted on 7 Jul 2007 07:22:33 GMT:

;---------------------------------------------------------------------------------;
;"In article <2007070314244816807-gsande@worldnetattnet>,                         ;
;Gordon Sande  <g.sa...@worldnet.att.net> wrote:                                  ;
;                                                                                 ;
;                                                                                 ;
;> On 2007-07-03 14:02:02 -0300, "Wade Ward" <inva...@invalid.nyet> said:         ;
;                                                                                 ;
;> > I'd love to see authentic fortran source for this.  One thing I don't get is ;
;> > what bounds-checking is unltimately going to do for you.  Without            ;
;> > bounds-checking, when you assign to array(-1) or array(11) in a              ;
;> > ten-dimensional array, you get a runtime error.                              ;
;                                                                                 ;
;                                                                                 ;
;> No! No! You typically get a program that continues on but is not doing what    ;
;> you intended. It may continue silently to produce nonsense. It may get into    ;
;> some other form of trouble elsewhere. It may even produce the result hoped     ;
;> for as the error turns out to be benign. But which will happen is a matter     ;
;> of luck, or ...                                                                ;
;                                                                                 ;
;                                                                                 ;
;> > With bounds-checking in the same situation you get ...?                      ;
;                                                                                 ;
;                                                                                 ;
;> You get told that your program is not behaving as intended and that some       ;
;> attention to some or other issue is called for. And the issue will have been   ;
;> raised early and in a relatively sensible form.                                ;
;                                                                                 ;
;                                                                                 ;
;> The plaintive query of "My program is crashing and when I put in a single      ;
;> write statement it crashes somewhere else. Can anyone help?" is raised         ;
;> here with a amazing regularity. Main cause is bad subscripting. Followed       ;
;> by argument mismatch.                                                          ;
;                                                                                 ;
;                                                                                 ;
;> So could you explain again why ignoring the possible results of subscript      ;
;> checking is a good thing.                                                      ;
;                                                                                 ;
;                                                                                 ;
;                                                                                 ;
;Because it makes for such interesting bugs?  Sort of a :-).                      ;
;                                                                                 ;
;(I speak as someone who spent several formative years tracking down              ;
;bugs in other people's Fortran 66 code, an amazing number of which               ;
;turned out to be caused by out-of-bounds array accesses that could               ;
;have been avoided by more-careful programming.  Everything you                   ;
;and Richard Main are saying in this thread brings back memories.                 ;
;And the experience left its mark -- it's beyond my understanding                 ;
;why "buffer overflow" is as common an explanation as it is for                   ;
;security holes.  <shrug>, maybe.) "                                              ;
;---------------------------------------------------------------------------------;

Ken Fairfield posted on Tue, 03 Jul 2007 13:08:20 -0700:

~---------------------------------------------------------------------------~
~"[..]                                                                      ~
~                                                                           ~
~> I'm thinking he's thinking the typical resulting "ACCVIO" is necessarily ~
~> the initial addressing error??? :)                                       ~
~                                                                           ~
~                                                                           ~
~                                                                           ~
~May be, may not be, depending on a bunch of things...                      ~
~                                                                           ~
~On VMS, I think you typically get an error that reads something            ~
~like "bounds error" (it's been so long since I've done one of              ~
~these, I don't know off the top of my head), although an ACCVIO is         ~
~certainly one possiblity.  An ACCVIO usually comes from passing the        ~
~wrong number of arguments to a function or subroutine, or an               ~
~otherwise "bad" address that "points off into space" as it were. ;-) "     ~
~---------------------------------------------------------------------------~


Henrik Holst posted on Fri, 13 Jul 2007 12:15:46 -0700:
^-----------------------------------------------------------------------------^
^"Hi fellow Fortran users (old and new)!                                      ^
^                                                                             ^
^I am new to Fortran but not to programming in general. I started to          ^
^program more seriously Fortran just a couple of months ago and now I         ^
^have come up to a cross section where I need some help to understand         ^
^the design of Fortran 90.                                                    ^
^                                                                             ^
^                                                                             ^
^I have seen some serious issues (yes, strong word) with Fortran 90           ^
^modules. The binary compatibility  between different compilers - even        ^
^on the same architecture - is zero. Also they create a terrible mess         ^
^in the Make scripts. I just cannot understand why Fortran 90 thought         ^
^there was a need to reinvent the wheel - and make a terrible work            ^
^while doing so?                                                              ^
^                                                                             ^
^                                                                             ^
^Let's look at the test module testmod.f90:                                   ^
^MODULE TESTMOD                                                               ^
^    INTEGER :: X                                                             ^
^CONTAINS                                                                     ^
^    SUBROUTINE COMPUTE                                                       ^
^    END SUBROUTINE                                                           ^
^END MODULE TESTMOD                                                           ^
^                                                                             ^
^                                                                             ^
^Between the three different compilers I have available I see the             ^
^following difference in the object files:                                    ^
^                                                                             ^
^                                                                             ^
^gfortran 4.2                                                                 ^
^00000000 T __testmod__compute                                                ^
^00000000 B __testmod__x                                                      ^
^                                                                             ^
^                                                                             ^
^Intel Fortran 9.1                                                            ^
^00000000 T testmod._                                                         ^
^00000002 T testmod_mp_compute_                                               ^
^00000004 C testmod_mp_x_                                                     ^
^                                                                             ^
^                                                                             ^
^Sun studio 12                                                                ^
^00000000 T testmod.compute_                                                  ^
^00000000 B testmod.x_                                                        ^
^00000000 D testmod_                                                          ^
^                                                                             ^
^                                                                             ^
^Also the .mod file is different. <sarcasm>The new Fortran 2003               ^
^standard talks about C integration. How about to start with Fortran <-       ^
^                                                                             ^
^                                                                             ^
^                                                                             ^
^> Fortran integration? </sarcasm>                                            ^
^                                                                             ^
^                                                                             ^
^This means that you cannot compile a library with say gfortran and use       ^
^it in any other compiler.                                                    ^
^                                                                             ^
^If you avoid using Fortran modules you can get something that is             ^
^binary compatible and usable between the three compilers I have              ^
^available and have also tested with. I have [1] a small example of how       ^
^to write "module code" without using modules. It boils down to using         ^
^INCLUDE instead. There are some negativisms with not using MODULES as        ^
^well but not as many.                                                        ^
^                                                                             ^
^                                                                             ^
^Leading researchers is using Fortran 95 [2] with modules I guess I           ^
^just have to bend over and recognize that this is broken but nobody          ^
^but me seems to care about it. Also, if you look at the BLAS95               ^
^proposal routines, you see lot's of dangerous code. You see unsafe           ^
^EXTERN keywords. I would though out modules and replace it with type         ^
^checking any day of the week (Do not confuse modules with                    ^
^interfaces.).                                                                ^
^                                                                             ^
^                                                                             ^
^I think Fortran 90 has lot's of nice features which I think is               ^
^essential to a modern programming language. I know I don't have to           ^
^follow everyone else and use MODULES. I don't even have to use Fortran       ^
^90. But since so many are choosing to use modules and seems fine with        ^
^that - where did you dispose of the bodies of those who questioned it?       ^
^                                                                             ^
^                                                                             ^
^Thanks for your comments. I would very very much like to hear what you       ^
^have to say about these things.                                              ^
^                                                                             ^
^                                                                             ^
^[1] http://na37.nada.kth.se/mediawiki/index.php/Fortran_90_goes_back_to_t... ^
^[2] http://www.cs.umd.edu/~stewart/matran/Matran.html                        ^
^                                                                             ^
^                                                                             ^
^Cheers,                                                                      ^
^--                                                                           ^
^Henrik Holst, Sweden                                                         ^
^http://www.csc.kth.se/~holst/contact.shtml "                                 ^
^-----------------------------------------------------------------------------^
Of course, linking issues between different compilers in Ada are not
always completely easy.



Craig Powers posted on Fri, 06 Jul 2007 17:03:59 -0400:
?----------------------------------------------------------------------------?
?"Gary Scott wrote:                                                          ?
?> Beliavsky wrote:                                                          ?
?                                                                            ?
?>> On Jun 28, 8:43 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:         ?
?                                                                            ?
?                                                                            ?
?>>> I probably don't have the syntax correct, but I read recently that you  ?
?>>> can force bounds checking on an array by expressing an access something ?
?>>> like:                                                                   ?
?                                                                            ?
?                                                                            ?
?>>> array.at[i]                                                             ?
?                                                                            ?
?                                                                            ?
?>>> whereas:                                                                ?
?                                                                            ?
?                                                                            ?
?>>> array[i]                                                                ?
?                                                                            ?
?                                                                            ?
?>>> would not cause bounds checking                                         ?
?                                                                            ?
?                                                                            ?
?>> I wonder if you are thinking of the vector container in the C++          ?
?>> standard library, which can be substituted for the array of C/C++ in     ?
?>> some cases.                                                              ?
?                                                                            ?
?                                                                            ?
?>>> Would something like that be useful in Fortran?  Seems sort of kludgy   ?
?>>> and partially redundant to me.                                          ?
?                                                                            ?
?                                                                            ?
?>> Good compilers have done checked for some time, and assumed shape        ?
?>> arrays "know their own size", so one can determine the dimensions of     ?
?>> array arguments of procedures. The C++ vector, unlike the C/C++ array,   ?
?>> has a similar feature.                                                   ?
?                                                                            ?
?                                                                            ?
?> The stated reason for the difference in the article I read was so that    ?
?> programmers could directly control in code whether automatic checking     ?
?> occurred or not.                                                          ?
?                                                                            ?
?                                                                            ?
?                                                                            ?
?Seems to me that only becomes an issue if you have a time-intensive         ?
?application where a bounds error happens a long way into the run, and       ?
?you can localize to a subset of your arrays.  Then, exercising per-array    ?
?control over what is and is not bounds-checked could be helpful.            ?
?                                                                            ?
?The other benefit of the .at method is that it gives you tight control      ?
?over the results of a bounds error -- you'll get a well-defined             ?
?exception thrown, which will allow you to do your own error processing      ?
?if you desire instead of tying you to whatever the compiler happens to      ?
?do.  This is obviously not applicable to Fortran until and unless           ?
?Fortran gets an exception mechanism."                                       ?
?----------------------------------------------------------------------------?


James Giles posted with timestamp Thu, 28 Jun 2007 01:03:12 GMT:

%--------------------------------------------------------------%
%"[..]                                                         %
%                                                              %
%To be sure, there are a number of things the Fortran standard %
%leaves unspecified that it should pin down. [..]"             %
%--------------------------------------------------------------%

Richard Maine posted with timestamp Thu, 21 Jun 2007 09:05:59 -0700:

&-------------------------------------------------------------------------&
&"Dick Hendrickson <dick.hendrick...@att.net> wrote:                      &
&> analys...@hotmail.com wrote:                                           &
&> > (1) There must have been some issues connected with introducing      &
&> > unsigned ints as a native data type into Fortran - would the experts &
&> > please spell out what they are ?                                     &
&                                                                         &
&> Since the experts seem to be busy, I'll take a swing at this.          &
&                                                                         &
&                                                                         &
&                                                                         &
&I'll throw in a few things, some of them partially overlapping with      &
&Dick's, but from a slightly different different viewpoint.               &
&                                                                         &
&I'll focus on the questions of why anyone would want such a thing.       &
&Answers I've seen are                                                    &
&                                                                         &
&[..]                                                                     &
&                                                                         &
&3. Points made previously in this thread about things that shouldn't be  &
&negative, so it might be nice to have the compiler catch them. These all &
&seem to me to be just special cases of subranges. I don't see that doing &
&unsigned is the "right" way to address that. If one wants subranges, one &
&should do subranges in general rather than one specific case and that    &
&case only. There are arguments for doing subranges; they have certainly  &
&been proposed. But that's a different proposal. If one is really after   &
&subranges, then unsigned does only one specific case and is not          &
&plausibly extendable to cover other cases. You'd have to throw it out    &
&and start over again to do the more general case. That's not a very good &
&selling point for unsigned if that is the objective."                    &
&-------------------------------------------------------------------------&

Glen Herrmannsfeldt posted with timestamp Wed, 20 Jun 2007 20:41:23 -0800:
\---------------------------------------------------------------\
\"[..]                                                          \
\                                                               \
\The primary need for unsigned in C is for known properties     \
\in the case of overflow.  C, like Fortran, makes no guarantee  \
\on the results for signed integer overflow, but C does require \
\that unsigned arithmetic give the modulo 2**N result for       \
\unsigned overflow."                                            \
\---------------------------------------------------------------\

Richard Maine posted with timestamp Mon, 25 Jun 2007 10:01:43 -0700:

&--------------------------------------------------------------------------&
&"Rich Townsend <r...@barVOIDtol.udel.edu> wrote:                          &
&> Richard Maine wrote:                                                    &
&> > As I have                                                             &
&> > said here before, allocatables cannot leak memory (except of course,  &
&> > through compiler bugs).                                               &
&                                                                          &
&> This is true in F95, but was it true in F90?                            &
&                                                                          &
&                                                                          &
&                                                                          &
&No. F90 allocatables were abysmal. They actually did worse than leak      &
&memory. The kinds of things that you might think of as potentially        &
&leaking memory instead left the allocatable in an undefined state. You    &
&could no longer validly do *ANYTHING* with such an allocatable. You       &
&couldn't allocate it, because it wasn't deallocated. You couldn't         &
&deallocate it becase it wasn't allocated. You couldn't even inquire       &
&about its status.                                                         &
&                                                                          &
&F95 fixed all that and got rid of the undefined allocation status. What   &
&f95 didn't fix was the severe limitations on where you could use          &
&allocatables at all. TR 15581 addressed most of that, with f2003 filling  &
&in some "corners" (such as allocatable scalars).                          &
&                                                                          &
&                                                                          &
&But since the code in question has an allocatable function result, f90    &
&seems pretty irrelevant. It requires at least f95+TR.                     &
&                                                                          &
&                                                                          &
&                                                                          &
&> Important caveat here: Lahey's implementation of TR 15581 is an         &
&> unsupported 'feature' of their compiler, and any bug reports concerning &
&> this implementation are viewed -- quaintly -- as 'feature requests'.    &
&                                                                          &
&                                                                          &
&Ok. Well, I can't address the question of how the vendor responds to bug  &
&reports. That doesn't change whether or not it is a bug. In this case,    &
&at least, the workaround is simple: just ignore the bogus message.        &
&However, the message does make me suspect that there is a more serious    &
&underlying bug. Perhaps the compiler does leak memory in this case;       &
&that's what the message seems to say. As I mentioned before, compiler     &
&bugs can, of course, leak memory."                                        &
&--------------------------------------------------------------------------&



Richard Maine posted at Sat, 7 Jul 2007 16:18:04 -0700:
&--------------------------------------------------------------------------&
&"Wade Ward <inva...@invalid.nyet> wrote:                                  &
&> If it's illegal, then why aren't compilers required to at least say so? &
&                                                                          &
&                                                                          &
&This is an absolutely critical point that gets repeated here many times.  &
&I suppose it has been a while. Time for the next repeat. :-)              &
&                                                                          &
&There is a specific list of things that compilers are required to         &
&detect. It is a tiny fraction of the requirements of the standard. The    &
&general philosophy is that the compiler is required to diagnose things    &
&that are always easily detectable at compile time. That's not the actual  &
&rule, but that's the flavor of the motivation. There turn out to be many  &
&rules where the simple cases are detectable at compile time, but          &
&complicated cases aren't. The standard doesn't tend to require detection  &
&of violation of those rules, but many compilers do detect the simple      &
&ones.                                                                     &
&                                                                          &
&[..]"                                                                     &
&--------------------------------------------------------------------------&
Of course, all languages which are not trivial are affected by this,
but how good are Fortran; C++; and Ada in relation to each other in
this regard?



Richard Maine posted on Wed, 11 Jul 2007 18:45:57 -0700:

&------------------------------------------------------------------------&
&"[..]                                                                   &
&                                                                        &
&[..] I'll note that I had exactly that kind                             &
&of problem once in Fortran using TRANSFER to copy the bits of a pointer &
&to temporary storage in an array of integers. The garbage collector     &
&trashed that program. Fortunately, I was able to turn the garbage       &
&collector off. Although I did not turn it in as a bug report, an        &
&acquaintance who worked for the vendor later suggested that if I had    &
&made my temporary storage a pointer (even though it would have been a   &
&pointer to the wrong type, and thus still needed the TRANSFER), the     &
&garbage collector would have left it alone.                             &
&                                                                        &
&[..]"                                                                   &
&------------------------------------------------------------------------&




Richard Maine posted on Wed, 13 Jun 2007 07:41:56 -0700:
&-------------------------------------------------------------------------&
&"Sebastian Gerecke <gere...@omni-vi.kicks-ass.net> wrote:                &
&> my program compiles cleanly but upon execution I get                   &
&> "Segmentation fault (core dumped)". If I change the "forall" statement &
&> with a simple "do" loop, everything works fine.                        &
&> Does anybody see the reason for that?                                  &
&                                                                         &
&                                                                         &
&Probably exceeding stack limits. Either increas the stack limit (which   &
&defaults to an unreasonably low size on many systems), or just use the   &
&plain DO.                                                                &
&                                                                         &
&As discussed here regularly, there are few benefits and many problems    &
&with FORALL. It tends to result in allocation of temporary arrays and    &
&more often hinders than helps performance."                              &
&-------------------------------------------------------------------------&
Of course, stack limits can also be exceeded with Ada. In principle
FORALL should be good, but Fortran implementations thereof seem to be
bad. Is this due to a flaw in the definition of Fortran itself or is
the concept of FORALL simply not simple as might be naively believed
at first sight?


Catherine Rees Lay posted on Wed, 06 Jun 2007 10:27:59 +0100:
!--------------------------------------------------------------------------------!
!"Richard Edgar wrote:                                                           !
!> Michael Metcalf wrote:                                                        !
!>> <li.sim...@gmail.com> wrote in message                                       !
!>> news:1180710342.819248.32200@j4g2000prf.googlegroups.com...                  !
!>>> why Fortran didn't assign parameters with initial value of zero?? I         !
!>>> think it may be convennient with a zero initial value at most case.         !
!                                                                                !
!>> Because zero is the average value of all representable numbers on a          !
!>> computer. If variables are set to this value inadvertently and used in       !
!>> calculations, the resulting wrong results will be closer to the true results !
!>> that if the values you quote are used, and thus the fault harder to detect.  !
!>> Default initialization to zero is A VERY BAD IDEA.                           !
!                                                                                !
!                                                                                !
!> Thinking on this.... are there any compilers which will do something          !
!> useful - like a default initialisation to NaN? IME (admittedly limited),      !
!> zero initialisation tends to be the default (and much cursed) unless you      !
!> turn on stack allocation of local variables (-stackvar or -automatic          !
!> being common options), which gives 'random' values. These are more            !
!> likely to cause a crash, but there isn't the nice guarantee which NaN         !
!> provides.                                                                     !
!                                                                                !
!                                                                                !
!> Richard                                                                       !
!                                                                                !
!                                                                                !
!                                                                                !
!This sounds like the Salford (now Silverfrost) /UNDEF feature. Though I         !
!don't think they use a specific NaN, just a very very unlikely value            !
!which their own system triggered on.                                            !
!                                                                                !
!In my experience, the majority of bugs in code are due to undefined             !
!variables, with almost all the remainder being either array indices out         !
!of bounds or mismatching subroutine argument lists.                             !
!                                                                                !
!                                                                                !
!Second (third, etc.) all the comments that initialisation to zero is a          !
!very bad idea. If you want a value to be zero, then set it that way.            !
!It's a few seconds of typing which will save you hours of debugging when        !
!you forget to set the next variable along which should have been 0.005... "     !
!--------------------------------------------------------------------------------!


Li Simula posted something which does not induce the impression of
object orientation support in Fortran on Fri, 29 Jun 2007 09:17:05 -0700 in
news:1183133825.857727.286560@m37g2000prh.googlegroups.com (this had
not been cited by Colin Paul Gloster on July 5th, 2008):
#########################################################################
#"I should use Fortran for some special reason (I have some old codes   #
#can be referenced) and I want to program my Fortran codes in           #
#oop(object#oriented program) strategy.                                 #
#                                                                       #
#In C++, you can use a base class pointer in main program to invoke the #
#fuctions in derived class. But in Fortran, the derived class is        #
#obtained by "use" base class(type or module containing the type), and  #
#we known that the "use" is only feasible in a one#direction way(i.e.   #
#if A is already use B, then B can't use A) .  So, you can't use base   #
#class in main program and then invoke functions in derived class in    #
#the main program. You can only directly use derived class in main      #
#program and then invoke functions in derived class. But I have too     #
#many many derived classes!                                             #
#                                                                       #
#                                                                       #
#How can fortran simulate the C++ 's this behavior (in C++, the         #
#behavior, I think, is in two#direction way)???                         #
#                                                                       #
#                                                                       #
#Note: I have read some literatures such as professor Akin etc., Decyk  #
#etc., but I think their method is not easy to use if the program is    #
#more  complex which has several levels of derived classes. [They were  #
#using a version of Fortran before the object-based FOrtran 95. -- Colin#
#Paul Gloster.]                                                         #
#                                                                       #
#                                                                       #
#Any  suggestion???"                                                    #
#########################################################################

Yours faithfully,
Colin Paul Gloster

Re: another way to shoot yourself in the foot?

[Richard Maine]

Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote:
[a very long post including quite a lot of quotations of me, among
others]

I'm afraid that this post was too long and rambling for me to follow it.
I could not detect any coherent message in it, other than perhaps a hint
of randomly assembling quotes that sounded negative about Fortran (often
out of context, at least for some of mine). In addition to preferring
coherent organization and readability in my coding, I prefer the same in
newsgroup postings.

If you have some actual message that you are hoping I might respond to,
you'll have to state it a bit more coherently and concisely. Decoding
that tome doesn't seem worth the work. If the message is just a general
language flame, which is perhaps the main flavor I hear, then you need
not bother, as I won't respond, coherent or not.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Re: another way to shoot yourself in the foot?

[Terence]

SNIP:-
>Why does Gary Scott's company use almost entirely C++ if Gary Scott recommended Fortran?

I have met this situation many times.
As an example, a very large Oil Company first wrote its accounting
software n 1961 in Fortran, using integer arithemetic and separate
tracking of cents or pennies, on an IBM 1401 (after using plugboard
hardware). This included payroll.

Later, following IBM advice they took the PL/1 route after first
deviating via Cobol (and RPG and Mark4 !).

Very much later, Cobol, PL/1 and Fortran programmers became hard to
find, so the C and C++ languages were adopted after a look at Ada and
much talk with Borland. Basic was considered and actually used for
quick "stuff". Meanwhile I kept on updating the Fortran compilers and
the BMD and BMDP mathematical packages (which are/were Fortran IV
source code).

The points to consider always are:-
a) what the programming gurus" on staff think are the best options,
b) what the personnel staff say are the long-range availability of
programming candidates and prices,
c) what the universities and technical colleges have decided to teach
for problem-solving, especially to electrical, engineering and
geophysical/geology and mining students.

What a company finally decides on, can differ, even when competing in
the same fields.
And so long-term computer expert staff may know one language is far
better for the company's future, through years of exposure and use of
alternatives, yet have to bow to instructives based on economic
forces.

One solution I was not able to implement, was to take any new
programmers willing and available, and re-teach them a reasoned,
chosen and company-wide imposed language, which would have been
Fortran IV (over PL/1 by a hair) and of course going to F90 as soon an
F95 became available, one sure step behind.

I DID manage to get the concept accepted of hard-disk computer
workstations instead of terminals and maninframes well before it
became glaringly obvious as cheaper and more flexible.
Intercommunication was via minicomputers as message and file-passing
nodes and central file back-up and archiving points.

Re: another way to shoot yourself in the foot?

[Gary Scott]

Terence wrote:
> SNIP:-
> 
>>Why does Gary Scott's company use almost entirely C++ if Gary Scott recommended Fortran?

Well, a main reason is that vendors don't typically provide 
cross-compilers for Fortran.  I use Fortran for my own data analysis and 
GUI tools development.  The actual company products are hosted in 
embedded processors and the customer dictates various aspects of the 
development process, tools, etc.  Another stated reason is that "it's 
easier to find C programmers than Ada programmers".  That applies to 
just about any other language suitable for real-time programming, 
although one vendor is pushing "real-time" Java.

> 
> 
> I have met this situation many times.
> As an example, a very large Oil Company first wrote its accounting
> software n 1961 in Fortran, using integer arithemetic and separate
> tracking of cents or pennies, on an IBM 1401 (after using plugboard
> hardware). This included payroll.
> 
> Later, following IBM advice they took the PL/1 route after first
> deviating via Cobol (and RPG and Mark4 !).
> 
> Very much later, Cobol, PL/1 and Fortran programmers became hard to
> find, so the C and C++ languages were adopted after a look at Ada and
> much talk with Borland. Basic was considered and actually used for
> quick "stuff". Meanwhile I kept on updating the Fortran compilers and
> the BMD and BMDP mathematical packages (which are/were Fortran IV
> source code).
> 
> The points to consider always are:-
> a) what the programming gurus" on staff think are the best options,
> b) what the personnel staff say are the long-range availability of
> programming candidates and prices,
> c) what the universities and technical colleges have decided to teach
> for problem-solving, especially to electrical, engineering and
> geophysical/geology and mining students.
> 
> What a company finally decides on, can differ, even when competing in
> the same fields.
> And so long-term computer expert staff may know one language is far
> better for the company's future, through years of exposure and use of
> alternatives, yet have to bow to instructives based on economic
> forces.
> 
> One solution I was not able to implement, was to take any new
> programmers willing and available, and re-teach them a reasoned,
> chosen and company-wide imposed language, which would have been
> Fortran IV (over PL/1 by a hair) and of course going to F90 as soon an
> F95 became available, one sure step behind.
> 
> I DID manage to get the concept accepted of hard-disk computer
> workstations instead of terminals and maninframes well before it
> became glaringly obvious as cheaper and more flexible.
> Intercommunication was via minicomputers as message and file-passing
> nodes and central file back-up and archiving points.


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: another way to shoot yourself in the foot?

[Colin Paul Gloster]

On Wed, 9 Jul 2008, Richard Maine wrote:
|------------------------------------------------------------------------|
|"Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote:                 |
|[a very long post including quite a lot of quotations of me, among      |
|others]                                                                 |
|                                                                        |
|I'm afraid that this post was too long and rambling for me to follow it.|
|I could not detect any coherent message in it, other than perhaps a hint|
|of randomly assembling quotes that sounded negative about Fortran (often|
|out of context, at least for some of mine)."                            |
|------------------------------------------------------------------------|

Dear Richard and everyone else,

I did not intentionally take quotes about Fortran out of
context. If you can spare the time, then please help me to learn
Fortran by explaining my misconceptions.

|------------------------------------------------------------------------|
|" In addition to preferring                                             |
|coherent organization and readability in my coding, I prefer the same in|
|newsgroup postings.                                                     |
|                                                                        |
|If you have some actual message that you are hoping I might respond to, |
|you'll have to state it a bit more coherently and concisely."           |
|------------------------------------------------------------------------|

Please find below a summary of most of that post posed as yes-or-no
questions. I have tried to rephrase
/-----------------------------------------------------------------------/
/"Gary Scott edited out all citations to newsgroup posts from circa 2007/
/which do not promote Fortran. Perhaps posters to                       /
/news:comp.lang.fortran would care to inform me as to whether or not    /
/they are valid..."                                                     /
/-----------------------------------------------------------------------/
"a bit more coherently and concisely."

|------------------------------------------------------------------------|
|" Decoding                                                              |
|that tome doesn't seem worth the work. If the message is just a general |
|language flame, which is perhaps the main flavor I hear, then you need  |
|not bother, as I won't respond, coherent or not."                       |
|------------------------------------------------------------------------|

I had looked at some Fortran newsgroup articles and webpages and code
in 2007, but I have only started in a Fortran project this year. I
have started to read a Fortran book for the first time this week. The
Fortran project which I have joined so far involves replacing Fortran
with C++. This had begun before I have joined. I do not approve of
replacing Fortran with C++. However, if Ada is better than Fortran,
then I approve of replacing Fortran and C++ with Ada. So, please
rectify any misconceptions which I may have. (Later, if Fortran
compilers produce much faster executables, then I may be motivated to
use some Fortran even if I shall still believe then that Ada is a
better language overall.)

I did point out in the long post that Ada is not perfect with respect
to all of these flaws.

If answers differ with respect to different versions of Fortran
(e.g. 77; 90; 95; 2003; 2008; and any others worth considering), then
please elaborate accordingly...

Does Fortran have undefined behavior?

Does Fortran always automatically check if the INTERFACE actually
corresponds to the code?

Does Fortran statically forbid out-of-bounds array accesses at
compilation time?

Does Fortran allow argument mismatch?

Are Fortran 90 modules compatible at the binary level on the same
architecture?

Does Fortran have an exception mechanism?

Are "there are a number of things the Fortran standard leaves
unspecified that it should pin down"?

Does Fortran allow one to declare a type such as
type
The_Resolution_For_Nanoteslas_Supported_By_My_Analog_To_Digital_Converter
is delta 1.0 / 2.0**5 range - 256.0 .. + 256.0 - 1 .0 / 2.0**5;
(that is in Ada syntax, but I am not worried about the syntax: the
feature is important, not how it is expressed)?

Does Fortran guarantee what happens during overflow for signed and
unsigned integers?

Could Fortran 90 allocatables be left in an undefined state?

Does Lahey's implementation of TR 15581 contain a bug which leaks
memory?

Do the Fortran standards require detection of only trivial errors?

Is an optional garbage collector buggy?

In principle FORALL should be good, but Fortran implementations
thereof seem to be bad. Is this due to a flaw in the definition of
Fortran itself?

Does Fortran allow one to use an undefined variable?

Does Fortran allow a default value at the declaration of a variable?

Yours sincerely,
Colin Paul Gloster

Re: another way to shoot yourself in the foot?

[fj]

On 10 juil, 16:10, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> On Wed, 9 Jul 2008, Richard Maine wrote:
>
> |------------------------------------------------------------------------|
> |"Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> wrote:                 |
> |[a very long post including quite a lot of quotations of me, among      |
> |others]                                                                 |
> |                                                                        |
> |I'm afraid that this post was too long and rambling for me to follow it.|
> |I could not detect any coherent message in it, other than perhaps a hint|
> |of randomly assembling quotes that sounded negative about Fortran (often|
> |out of context, at least for some of mine)."                            |
> |------------------------------------------------------------------------|
>
> Dear Richard and everyone else,
>
> I did not intentionally take quotes about Fortran out of
> context. If you can spare the time, then please help me to learn
> Fortran by explaining my misconceptions.
>
> |------------------------------------------------------------------------|
> |" In addition to preferring                                             |
> |coherent organization and readability in my coding, I prefer the same in|
> |newsgroup postings.                                                     |
> |                                                                        |
> |If you have some actual message that you are hoping I might respond to, |
> |you'll have to state it a bit more coherently and concisely."           |
> |------------------------------------------------------------------------|
>
> Please find below a summary of most of that post posed as yes-or-no
> questions. I have tried to rephrase
> /-----------------------------------------------------------------------/
> /"Gary Scott edited out all citations to newsgroup posts from circa 2007/
> /which do not promote Fortran. Perhaps posters to                       /
> /news:comp.lang.fortran would care to inform me as to whether or not    /
> /they are valid..."                                                     /
> /-----------------------------------------------------------------------/
> "a bit more coherently and concisely."
>
> |------------------------------------------------------------------------|
> |" Decoding                                                              |
> |that tome doesn't seem worth the work. If the message is just a general |
> |language flame, which is perhaps the main flavor I hear, then you need  |
> |not bother, as I won't respond, coherent or not."                       |
> |------------------------------------------------------------------------|
>
> I had looked at some Fortran newsgroup articles and webpages and code
> in 2007, but I have only started in a Fortran project this year. I
> have started to read a Fortran book for the first time this week. The
> Fortran project which I have joined so far involves replacing Fortran
> with C++. This had begun before I have joined. I do not approve of
> replacing Fortran with C++. However, if Ada is better than Fortran,
> then I approve of replacing Fortran and C++ with Ada. So, please
> rectify any misconceptions which I may have. (Later, if Fortran
> compilers produce much faster executables, then I may be motivated to
> use some Fortran even if I shall still believe then that Ada is a
> better language overall.)
>
> I did point out in the long post that Ada is not perfect with respect
> to all of these flaws.
>
> If answers differ with respect to different versions of Fortran
> (e.g. 77; 90; 95; 2003; 2008; and any others worth considering), then
> please elaborate accordingly...
>
> Does Fortran have undefined behavior?

Only with invalid (non conforming) programming

>
> Does Fortran always automatically check if the INTERFACE actually
> corresponds to the code?
>
> Does Fortran statically forbid out-of-bounds array accesses at
> compilation time?

No but nice Fortran compilers provide this feature.

>
> Does Fortran allow argument mismatch?

No if you use modules ( >= F90 ), put all sub-routines in modules and
adopt USE.
>
> Are Fortran 90 modules compatible at the binary level on the same
> architecture?

No

>
> Does Fortran have an exception mechanism?

Yes ... if alternate return capability is condidered (>= Fortran
2 ???)

Yes if you want to test IEEE exceptions (>= F2003) but the mechanism
is different than the one in JAVA for instance.

>
> Are "there are a number of things the Fortran standard leaves
> unspecified that it should pin down"?

?

>
> Does Fortran allow one to declare a type such as
> type
> The_Resolution_For_Nanoteslas_Supported_By_My_Analog_To_Digital_Converter
> is delta 1.0 / 2.0**5 range - 256.0 .. + 256.0 - 1 .0 / 2.0**5;
> (that is in Ada syntax, but I am not worried about the syntax: the
> feature is important, not how it is expressed)?

Not exactly but you can ask for the minimum precision you want with
selected_int_kind or selected_real_kind

>
> Does Fortran guarantee what happens during overflow for signed and
> unsigned integers?

No

>
> Could Fortran 90 allocatables be left in an undefined state?

No. Either an allocatable is allocated or not.

>
> Does Lahey's implementation of TR 15581 contain a bug which leaks
> memory?

Never seen

>
> Do the Fortran standards require detection of only trivial errors?

Yes/No depending of what you call a trivial error

>
> Is an optional garbage collector buggy?

No need of garbage collector in F2003 if you allocate only allocatable
arrays.
Deallocation is automatic when the array (or the derived type variable
containing that array) becomes out of scope.

>
> In principle FORALL should be good, but Fortran implementations
> thereof seem to be bad. Is this due to a flaw in the definition of
> Fortran itself?

No. Only the implementation is responsible ! Personally, I don't use
the FORALL statement.

>
> Does Fortran allow one to use an undefined variable?

yes but nice compilers try to detect that at compile time and often
propose to initialize undefined variable to NaN (for instance) to
improve the detection at run time.
>
> Does Fortran allow a default value at the declaration of a variable?

Not a default value. Just an initial value !

But if you think about optional arguments, then a missing optional
argument cannot have an explicit default value in F95. Of course, it
is easy to solve the problem in the routine itself in using the
PRESENT intrinsic function.
>
> Yours sincerely,
> Colin Paul Gloster

Re: another way to shoot yourself in the foot?

[Richard Maine]

fj <francois.jacq@irsn.fr> wrote:

> On 10 juil, 16:10, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
> wrote:

> > Could Fortran 90 allocatables be left in an undefined state?
> 
> No. Either an allocatable is allocated or not.

That is true now, but wasn't so in f90, which the question specifically
asked about. But then, this is one of the many things in the set of
questions (at least now I can read them) that strike me as being either
out of context or otherwise irrelevant to current programming. This was
true only of f90. Prior to f90, there were no allocatables. In f95, this
"feature" was fixed. You won't find any f90 compilers currently being
supported today. If you manage to find some old compiler that still has
this issue, and you are using that compiler, then I think that pretty
conclusive evidence that you don't care about "minor" issues like
reliability and support. All quality compilers with active support were
long ago upgraded.

My question in return is why anyone would be asking this other than as
flame material? It was quite explicit in the citation (which was mine,
by the way) that this was an f90 feature fixed in f95.

I'll not elaborate on details of several of the other questions. The
answers Francois gave are at least good enough, if they aren't quite the
way I would have answered. Several of them seem to fall in the
categories of either:

1. Does some random compiler have some random bug or misfeature
(including the lack of an important feature)? These have a lot the
flavor of scouring the newsgroup for negative things. I'll give the
general answer that, yes some compilers have some bugs and misfeatures.
I'll add that some compilers are worse about this than others. I'll also
add that this answer is completely non-Fortran specific. It applies
equally well, for example, to C, C++, Ada or any other language that is
more than trivial. I will ignore requests for examples or claims that it
isn't true of some language. That avenue of usenet discussion has no
constructive end - just flames. While it is no doubt the case that some
languages have a higher frequency of compiler bugs than others and that
there might be some lessons to be learned from that, frankly the odds of
such constructive data comming out of a usenet discussion like this are
zero. To be anything cloise to useful, such a thing would actually
require comprehensive study rather than just random samples of things
that people happened to post.

or

2. Does Fortran do the impossible? Things that apply to essentially all
languages, but with the question phrased as though it were a
Fortran-specific matter. This also has the look of just skimming the
newsgroup for things that sound negative. For one example, no Fortran
doesn't check all array bounds "at compile time". That is inherently
impossible in any language unless it is so limitted as to be useless.
Array index values can be a function of input data, which is not
available at compile time. If a language didn't allow such input data,
it would be in the category of so limitted as to be useless. Checking
some bounds at compile time is practical and is often done. Checking all
bounds at run-time is practical in many cases and is often done.
Checking all bounds at compile time is essentially nonsensical. Phrasing
this as a Fortran matter smacks of flaming and pulling things out of
context. (The context lost is that this is not Fortran-specific).

or

3. If you ignore advice about good programming practices, can you get in
trouble? The answer, of course, is yes. That's why they are good
programming practices. Several of the questions appear to be pulled from
explanations of why some programming practices are good, but the context
of the good practices was omitted, leaving just the negative part of
what can happen if you ignore all the good advice.

Quite a lot of the questions fall into those 3 categories. In fact,
skimming them, I'd say that most do. If these are the kinds of questions
being raised in your attempts to evaluate languages, then the effort is
doomed from the start. You won't get useful results starting from
questions like these. It is so much the wrong direction that I can't
even offer constructive criticism other than to throw everything out and
start from scratch with an open mind. I just can't imagine getting there
from this starting point.

This will be my last post in this thread. I see no constructive benefit
to posting further. I was pulled into posting this one by the factual
error in the answer about undefined allocatable state. (The answer is
correct for today, but was not correct specifically for f90). I've gone
on for far more than I really ought to have already. It would take quite
a bit longer to give detailed answers and elaborations to each question,
but I don't see the benefit of doing so.

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Re: another way to shoot yourself in the foot?

[Dick Hendrickson]

Colin Paul Gloster wrote:
> On Wed, 9 Jul 2008, Richard Maine wrote:
> |------------------------------------------------------------------------|
> |"Colin Paul Gloster <Colin_Paul_Gloster@ACM.org> wrote:                 |
> |[a very long post including quite a lot of quotations of me, among      |
> |others]                                                                 |
> |                                                                        |
> |I'm afraid that this post was too long and rambling for me to follow it.|
> |I could not detect any coherent message in it, other than perhaps a hint|
> |of randomly assembling quotes that sounded negative about Fortran (often|
> |out of context, at least for some of mine)."                            |
> |------------------------------------------------------------------------|
> 
> Dear Richard and everyone else,
> 
> I did not intentionally take quotes about Fortran out of
> context. If you can spare the time, then please help me to learn
> Fortran by explaining my misconceptions.
> 
> |------------------------------------------------------------------------|
> |" In addition to preferring                                             |
> |coherent organization and readability in my coding, I prefer the same in|
> |newsgroup postings.                                                     |
> |                                                                        |
> |If you have some actual message that you are hoping I might respond to, |
> |you'll have to state it a bit more coherently and concisely."           |
> |------------------------------------------------------------------------|
> 
> Please find below a summary of most of that post posed as yes-or-no
> questions. I have tried to rephrase
> /-----------------------------------------------------------------------/
> /"Gary Scott edited out all citations to newsgroup posts from circa 2007/
> /which do not promote Fortran. Perhaps posters to                       /
> /news:comp.lang.fortran would care to inform me as to whether or not    /
> /they are valid..."                                                     /
> /-----------------------------------------------------------------------/
> "a bit more coherently and concisely."
> 
> |------------------------------------------------------------------------|
> |" Decoding                                                              |
> |that tome doesn't seem worth the work. If the message is just a general |
> |language flame, which is perhaps the main flavor I hear, then you need  |
> |not bother, as I won't respond, coherent or not."                       |
> |------------------------------------------------------------------------|
> 
> I had looked at some Fortran newsgroup articles and webpages and code
> in 2007, but I have only started in a Fortran project this year. I
> have started to read a Fortran book for the first time this week. The
> Fortran project which I have joined so far involves replacing Fortran
> with C++. This had begun before I have joined. I do not approve of
> replacing Fortran with C++. However, if Ada is better than Fortran,
> then I approve of replacing Fortran and C++ with Ada. So, please
> rectify any misconceptions which I may have. (Later, if Fortran
> compilers produce much faster executables, then I may be motivated to
> use some Fortran even if I shall still believe then that Ada is a
> better language overall.)
> 
> I did point out in the long post that Ada is not perfect with respect
> to all of these flaws.
> 
> If answers differ with respect to different versions of Fortran
> (e.g. 77; 90; 95; 2003; 2008; and any others worth considering), then
> please elaborate accordingly...

There are really two answers to many of these questions.

The Fortran language prohibits many things, most of these
prohibitions are on the programmer.  Different compilers
check for different things; often there are compiler
switches to enable/disable particular checks.  For example,
run-time checks for out-of-bounds subscripts are often
expensive in time and disabled for production runs.

For the most part, the standard requires compiler checking
for syntax-like things and not run-time-value-related things.

> 
> Does Fortran have undefined behavior?
Sure, lots of it.  Many are for things that are purely
hardware related.  What should the standard say if the
heads fall off of a disk drive?  Others are a mixture
of hardware and software.  For example, integer overflow
is prohibited, but rarely detected by the hardware.  A
program which produces an integer overflow is non-standard;
but the standard does not specify a behavior.  Check the
list that Dan Nagle pointed to.  In general, there are
no size or complexity requirements that a compiler must
meet.

> 
> Does Fortran always automatically check if the INTERFACE actually
> corresponds to the code?
> 
Depends on the compiler, but in general NO.  I think all
compilers will detect an explicit assignment to a dummy
argument that has INTENT(IN) in the subroutine; I'm not sure
any will detect an assignment if the dummy is passed on
to another routine and that routine (illegally) assigns to
its argument.


> Does Fortran statically forbid out-of-bounds array accesses at
> compilation time?

It forbids them at all times.  The standard generally doesn't
distinguish between compile-time and run-time.  If a statement
is executed, the programmer must do the right thing.  In
     IF(A > B) C(I) = 1.0/D
if A is greater than B, I must be in bounds for the array
and D must be greater than or equal to zero (unless the
Fortran processor supports something like IEEE floating
point).

> 
> Does Fortran allow argument mismatch?
> 
NO.  Historically, with separate compilation, argument mismatches
were rarely detected by the compiler (some are not detectable
until run-time).  If you put things in modules, argument checking
is good at compile time.
> Are Fortran 90 modules compatible at the binary level on the same
> architecture?

Generally no.  Different compilers do things differently and the
standard does not specify module formats.  Nor does it specify
things like argument passing schemes, register save/restore,
stack management, etc.
> 
> Does Fortran have an exception mechanism?
> 
For some things.  I/O and memory management allow for error
detection and recovery by the program.  There is a set of
routines, etc., that allow Fortran to work with the IEEE
floating point exceptions.  There is no general user programmable
exception mechanism.

> Are "there are a number of things the Fortran standard leaves
> unspecified that it should pin down"?
> 
Sure, Maybe, No.  Take your pick.  Generally, I'd say no.
I think the balance between execution speed, compile time
checking, and user responsibility is pretty good.

> Does Fortran allow one to declare a type such as
> type
> The_Resolution_For_Nanoteslas_Supported_By_My_Analog_To_Digital_Converter
> is delta 1.0 / 2.0**5 range - 256.0 .. + 256.0 - 1 .0 / 2.0**5;
> (that is in Ada syntax, but I am not worried about the syntax: the
> feature is important, not how it is expressed)?

Yes, but not easily.  You can declare types.  If you do, then
you must provide functions that perform the operations and
optionally do assignments.  These routines can enforce value
checking.  There's no direct language support for ranges.

> 
> Does Fortran guarantee what happens during overflow for signed and
> unsigned integers?
There is no support for unsigned integers and no guarantee
about overflow for signed.  It's illegal to overflow, so there's
no need for the standard to specify what happens ;) .
> 
> Could Fortran 90 allocatables be left in an undefined state?
Yes.  That was fixed in F95.

> 
> Does Lahey's implementation of TR 15581 contain a bug which leaks
> memory?
> 
I believe all implementations of all languages contain bugs.  I
don't particularly know about Lahey's.  Historically, TR 15581
caused many compilers problems and it took them a while to get
it right.  It probably depends on the version of the compiler.

> Do the Fortran standards require detection of only trivial errors?
No.  The question is a little vague.

> 
> Is an optional garbage collector buggy?
> 
That's not really a compiler question.

> In principle FORALL should be good, but Fortran implementations
> thereof seem to be bad. Is this due to a flaw in the definition of
> Fortran itself?

Partly.  FORALL was essentially "cut and pasted" into Fortran
from HPF.  The intent was to allow compilers to easily
recognize things that could be spread out onto many processors.
Unfortunately, the restrictions on subscripts were a little
too loose and compilers have to perform a difficult analysis,
impossible at compile time for the interesting cases,
to avoid the need for temporary storage.  The Fortran 2008
DO CONCURRENT feature solves this problem, but there are no
compilers yet available ;) .
> 
> Does Fortran allow one to use an undefined variable?

In general NO.  Some intrinsics allow undefined arguments
and they can be passed on to a user subroutine, provided
the subroutine does the right thing.  The standard doesn't
require checking for undefined variables.  Given something
like
        DIMENSION  A(10000000000)
it's hard to imagine an efficient way to check for undefinedness.

If a value is required, the variable must be in a defined state,
but it's a programmer requirement.
> 
> Does Fortran allow a default value at the declaration of a variable?
Yes, however the way it is done often confuses people familiar
with other languages.

Dick Hendrickson
> 
> Yours sincerely,
> Colin Paul Gloster

Re: another way to shoot yourself in the foot?

[Craig Powers]

Dick Hendrickson wrote:
> Colin Paul Gloster wrote:
>>
>> Does Fortran always automatically check if the INTERFACE actually
>> corresponds to the code?
>>
> Depends on the compiler, but in general NO.  I think all
> compilers will detect an explicit assignment to a dummy
> argument that has INTENT(IN) in the subroutine; I'm not sure
> any will detect an assignment if the dummy is passed on
> to another routine and that routine (illegally) assigns to
> its argument.

Is that actually possible without lying about an interface?  i.e. Is it 
possible to pass an INTENT(IN) dummy as an actual argument to a more 
permissive dummy argument in another routine (no intent or intent OUT)

Re: another way to shoot yourself in the foot?

[James Giles]

Dick Hendrickson wrote:
> Colin Paul Gloster wrote:
...
>> Are "there are a number of things the Fortran standard leaves
>> unspecified that it should pin down"?
>>
> Sure, Maybe, No.  Take your pick.  Generally, I'd say no.
> I think the balance between execution speed, compile time
> checking, and user responsibility is pretty good.

The above is a direct quote from one of my articles and is *way*
out of context.  Yes, there are a number of things the Fortran
standard leaves unspecified that it should pin down.  For example
(and I think this is the original context), integer arithmetic should
be exact if it doesn't overflow.  No one would accept an implementation
that did otherwise, but the standard should actually require it.

Many other languages also don't explicitly require such things.
I'm not certain that Ada does.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Re: another way to shoot yourself in the foot?

[James Giles]

Craig Powers wrote:
> Dick Hendrickson wrote:
>> Colin Paul Gloster wrote:
>>>
>>> Does Fortran always automatically check if the INTERFACE actually
>>> corresponds to the code?
>>>
>> Depends on the compiler, but in general NO.  I think all
>> compilers will detect an explicit assignment to a dummy
>> argument that has INTENT(IN) in the subroutine; I'm not sure
>> any will detect an assignment if the dummy is passed on
>> to another routine and that routine (illegally) assigns to
>> its argument.
>
> Is that actually possible without lying about an interface?  i.e. Is
> it possible to pass an INTENT(IN) dummy as an actual argument to a
> more permissive dummy argument in another routine (no intent or
> intent OUT)

It's not permitted.  The standard doesn't require implementations to
verify that it's not done.  That is, it's not one of the kinds of error
that the standard requires implementations to detect and report.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare

"Simplicity is prerequisite for reliability"  -- E. W. Dijkstra 

Re: another way to shoot yourself in the foot?

[Dick Hendrickson]

James Giles wrote:
> Craig Powers wrote:
>> Dick Hendrickson wrote:
>>> Colin Paul Gloster wrote:
>>>> Does Fortran always automatically check if the INTERFACE actually
>>>> corresponds to the code?
>>>>
>>> Depends on the compiler, but in general NO.  I think all
>>> compilers will detect an explicit assignment to a dummy
>>> argument that has INTENT(IN) in the subroutine; I'm not sure
>>> any will detect an assignment if the dummy is passed on
>>> to another routine and that routine (illegally) assigns to
>>> its argument.
>> Is that actually possible without lying about an interface?  i.e. Is
>> it possible to pass an INTENT(IN) dummy as an actual argument to a
>> more permissive dummy argument in another routine (no intent or
>> intent OUT)
> 
> It's not permitted.  The standard doesn't require implementations to
> verify that it's not done.  That is, it's not one of the kinds of error
> that the standard requires implementations to detect and report.
> 
You're partially wrong, James.  It is permitted to pass a dummy
with INTENT(IN) to a subroutine that doesn't specify either
INTENT(INOUT) or INTENT(OUT).  You can pass them to a subroutine
that doesn't specify intent and even potentially modifies
its argument.  You can't lie in an interface, but you can
call routines that don't have an interface.  Those routines are
required to do the right thing; but the compiler isn't required
to detect violations.

Dick Hendrickson

Re: another way to shoot yourself in the foot?

[Craig Powers]

James Giles wrote:
> Craig Powers wrote:
>> Dick Hendrickson wrote:
>>> Colin Paul Gloster wrote:
>>>> Does Fortran always automatically check if the INTERFACE actually
>>>> corresponds to the code?
>>>>
>>> Depends on the compiler, but in general NO.  I think all
>>> compilers will detect an explicit assignment to a dummy
>>> argument that has INTENT(IN) in the subroutine; I'm not sure
>>> any will detect an assignment if the dummy is passed on
>>> to another routine and that routine (illegally) assigns to
>>> its argument.
>> Is that actually possible without lying about an interface?  i.e. Is
>> it possible to pass an INTENT(IN) dummy as an actual argument to a
>> more permissive dummy argument in another routine (no intent or
>> intent OUT)
> 
> It's not permitted.  The standard doesn't require implementations to
> verify that it's not done.  That is, it's not one of the kinds of error
> that the standard requires implementations to detect and report.

Actually, that's not exactly right.  It's not permitted to pass an 
INTENT(IN) to a dummy with intent OUT (i.e. INTENT(INOUT) or 
INTENT(OUT)), this is a constraint in 5.1.2.3 in the F95 draft as well 
as constraint C545 in the F03 draft, so I think it would require a 
diagnostic.

However, it IS permitted to pass an INTENT(IN) to an unspecified INTENT 
dummy, and in that case it would be possible to modify it (and I 
wouldn't expect a compiler to even realistically be able to detect that 
except in very specific circumstances).

Re: another way to shoot yourself in the foot?

[Richard Maine]

Dick Hendrickson <dick.hendrickson@att.net> wrote:

> James Giles wrote:
> > Craig Powers wrote:

> >> Is that actually possible without lying about an interface?  i.e. Is
> >> it possible to pass an INTENT(IN) dummy as an actual argument to a
> >> more permissive dummy argument in another routine (no intent or
> >> intent OUT)
> > 
> > It's not permitted.  The standard doesn't require implementations to
> > verify that it's not done.  That is, it's not one of the kinds of error
> > that the standard requires implementations to detect and report.
> > 
> You're partially wrong, James.  It is permitted to pass a dummy
> with INTENT(IN) to a subroutine that doesn't specify either
> INTENT(INOUT) or INTENT(OUT).  You can pass them to a subroutine
> that doesn't specify intent and even potentially modifies
> its argument.  You can't lie in an interface, but you can
> call routines that don't have an interface.  Those routines are
> required to do the right thing; but the compiler isn't required
> to detect violations.

I think you and James are saying the same thing. Your "those routines
are required to do the right thing" translates to James' "it is not
permitted [to do the wrong thing]". Both of you also say (correctly)
that the compiler isn't required to catch such an error.

And note that I think this is a diferent matter than the original
question. I read the original question as "can you lie about the
interface [presumably referring to separate compilation of an interface
body and an external procedure]?" Presumably Craig was reading it
differently because with my reading "can you do this without lying about
an interface?" becomes a tautalogical (if that's a word) question.

And I'll claim that this posting of mine doesn't count as replying to
the thread I said I wouldn't post in, as I'm just replying to you three
instead of to the pseudo-OP (pseudo because he wasn't literally the
original, but he resurrected it as pretty much a new topic).

-- 
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Re: another way to shoot yourself in the foot?

[Craig Powers]

Richard Maine wrote:
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
> 
>> James Giles wrote:
>>> Craig Powers wrote:
> 
>>>> Is that actually possible without lying about an interface?  i.e. Is
>>>> it possible to pass an INTENT(IN) dummy as an actual argument to a
>>>> more permissive dummy argument in another routine (no intent or
>>>> intent OUT)
>>> It's not permitted.  The standard doesn't require implementations to
>>> verify that it's not done.  That is, it's not one of the kinds of error
>>> that the standard requires implementations to detect and report.
>>>
>> You're partially wrong, James.  It is permitted to pass a dummy
>> with INTENT(IN) to a subroutine that doesn't specify either
>> INTENT(INOUT) or INTENT(OUT).  You can pass them to a subroutine
>> that doesn't specify intent and even potentially modifies
>> its argument.  You can't lie in an interface, but you can
>> call routines that don't have an interface.  Those routines are
>> required to do the right thing; but the compiler isn't required
>> to detect violations.
> 
> I think you and James are saying the same thing. Your "those routines
> are required to do the right thing" translates to James' "it is not
> permitted [to do the wrong thing]". Both of you also say (correctly)
> that the compiler isn't required to catch such an error.
> 
> And note that I think this is a diferent matter than the original
> question. I read the original question as "can you lie about the
> interface [presumably referring to separate compilation of an interface
> body and an external procedure]?" Presumably Craig was reading it
> differently because with my reading "can you do this without lying about
> an interface?" becomes a tautalogical (if that's a word) question.

My "lying about the interface" question was about how you would end up 
with an INTENT(IN) dummy getting passed along to a mutable dummy.  It 
had occurred to me that it might not be allowed to pass an INTENT(IN) 
into an unspecified intent, in which case lying about the interface 
(providing an interface block that didn't match the actual procedure) 
would be the only way to do it.

Re: another way to shoot yourself in the foot?

[Colin Paul Gloster]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 2454 bytes --]

On Thu, 10 Jul 2008, James Giles wrote:

|-----------------------------------------------------------------------|
|"[..]                                                                  |
|                                                                       |
|[..]  For example                                                      |
|(and I think this is the original context), integer arithmetic should  |
|be exact if it doesn't overflow.  No one would accept an implementation|
|that did otherwise, but the standard should actually require it."      |
|-----------------------------------------------------------------------|

I am not sure which of "an implementation of Fortran" and "an
implementation of any language" "an implementation" was an
abbreviation of above.

In 1999, the Java BigInteger class was not required to provide exact
arithmetic in the absence of overflow.

|-----------------------------------------------------------------------|
|"Many other languages also don't explicitly require such things.       |
|I'm not certain that Ada does."                                        |
|-----------------------------------------------------------------------|

This has been required of Ada for over twenty-five years. From
HTTP://archive.AdaIC.com/standards/83lrm/html/lrm-03-05.html#3.5.4
:"[..]

The same arithmetic operators are predefined for all integer types
(see 4.5). The exception NUMERIC_ERROR is raised by the execution of
an operation (in particular an implicit conversion) that cannot
deliver the correct result (that is, if the value corresponding to the
mathematical result is not a value of the integer type). [..]

[..]"

I am grateful to James Giles; Dick Hendrickson; François Jacq;
and Richard Maine for their helpful and clearly time-consuming
clarifications of Fortran semantics and tool issues. It is unfortunate
that Richard Maine ignored that every time I pointed out that Ada
suffers from some of these problems. It was clear from the reponses
however, that Ada is better overall. No language is perfect and a
number of theorems from computer science show that no language can be
perfect.

Just because I am convinced that Ada is better overall does not mean
that I shall never use Fortran, so I hope that news:comp.lang.fortran
participants will be helpful again when I need help with the language
again.

With best regards,
Nicholas Colin Paul Gloster