Re: F9X twister & ADA (was: n-dim'l vectors)

Re: F9X twister & ADA (was: n-dim'l vectors)

[Richard Maine]

bv <bvoh@sdynamix.com> writes:

> What a slaughter of Fortran, showing every symptom of design by ignorant
> and incompetent committee. What happened, where they too busy with
> themselves to bother and learn from ADA??

Perhaps the committee was full of people who were too busy insulting each
other instead of getting constructive work done?  If so, it would seem
that we have a new candidate who would fit right in.  :-(

In seriousness, those who can't learn to work well with others (including
some with opposing viewpoints), do not tend to help progress on such
things - no matter how brilliant they may be.  Offering gratuituous insults
is not generally a good way to start.  Do you make comments like that to
the people you work with regularly?  If so, does this help them get their
jobs done?

Yes, by the way, the committee certainly looked at ADA.  And it shows in
quite a few places.

The elided sample is not, of course, the only way to write the code in
question.  Nor is it particularly close to the way I'd suggest writing
it.  I rarely write out interface bodies - that's what modules are for.

If you hadn't just insulted several people that I respect, I might
offer an illustration of how I'd write the code in question...but you
haven't left me feeling in a mood to be helpful....

-- 
Richard Maine
maine@qnet.com

F9X twister & ADA (was: n-dim'l vectors)

[bv]

Paul van Delst wrote:
> 
> nsavvinv2@my-deja.com wrote:
> > Can a function return an n-dimensional vector?
> 
> Sure - in f90 at least....dunno about f77. I got it to work for vectors
> by using INTERFACE blocks in the code that calls the function, e.g.
> 
> FUNCTION my_func ( x, y ) RESULT ( z )
> 
>   IMPLICIT NONE
>   INTEGER, INTENT( IN ), DIMENSION( : )         :: x, y
>   INTEGER,               DIMENSION( SIZE( x ) ) :: z
> 
>   z(:) = x(:) + y(:)   ! Assumes x and y are the same size
> 
>   RETURN
> 
> END FUNCTION my_func
> 
> and then in the calling program:
> 
> PROGRAM blah
> 
>   IMPLICIT NONE
> 
>   INTERFACE
> !   Interface body for my_func
>     FUNCTION my_func ( x, y ) RESULT ( z )
>       IMPLICIT NONE
>       INTEGER, INTENT( IN ), DIMENSION( : )         :: x, y
>       INTEGER,               DIMENSION( SIZE( x ) ) :: z
>     END FUNCTION my_func
>   END INTERFACE
> 
>   INTEGER, DIMENSION( 5 ) :: x = (/ -1,  1, -1,  1 /), &
>                              y = (/  1, -1,  1, -1 /)
> 
>   WRITE( *, '( 5i5 )' ) my_func( x, y )
> 
> END PROGRAM blah


What a slaughter of Fortran, showing every symptom of design by ignorant
and incompetent committee. What happened, where they too busy with
themselves to bother and learn from ADA?? If they did, they'd see
something along these lines:

	function normalize(v: in vector) return vector is
	vni: float;
	begin
	  vni := 1./norm(v)
	  return (v(x)*vni, v(y)*vni, v(z)*vni);
	end normalize;

--	somewhere in your code   
	u,v: vector;
		.
		.
		.
	u := normalize(v);

The difference speaks for itself!! My advise to Fortran committee is to
head F9X for the nearest trash bin and start raising funds to compensate
the vendors for costs incurred to implement their vision of language
abuse.

btw, note a duality of the ADA & F77 fcn. A similar extension for
returning user types couldn't be crafted? But one would have to be aware
of the prior art of course...

--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.sdynamix.com
-----------------------------------------------

Re: F9X twister & ADA (was: n-dim'l vectors)

[Paul van Delst]

bv wrote:
> 
> Paul van Delst wrote:
> >
> > nsavvinv2@my-deja.com wrote:
> > > Can a function return an n-dimensional vector?
> >
> > Sure - in f90 at least....dunno about f77. I got it to work for vectors
> > by using INTERFACE blocks in the code that calls the function, e.g.
> >
> > FUNCTION my_func ( x, y ) RESULT ( z )
> >
> >   IMPLICIT NONE
> >   INTEGER, INTENT( IN ), DIMENSION( : )         :: x, y
> >   INTEGER,               DIMENSION( SIZE( x ) ) :: z
> >
> >   z(:) = x(:) + y(:)   ! Assumes x and y are the same size
> >
> >   RETURN
> >
> > END FUNCTION my_func
> >
> > and then in the calling program:
> >
> > PROGRAM blah
> >
> >   IMPLICIT NONE
> >
> >   INTERFACE
> > !   Interface body for my_func
> >     FUNCTION my_func ( x, y ) RESULT ( z )
> >       IMPLICIT NONE
> >       INTEGER, INTENT( IN ), DIMENSION( : )         :: x, y
> >       INTEGER,               DIMENSION( SIZE( x ) ) :: z
> >     END FUNCTION my_func
> >   END INTERFACE
> >
> >   INTEGER, DIMENSION( 5 ) :: x = (/ -1,  1, -1,  1, -1 /), &
> >                              y = (/  1, -1,  1, -1,  1 /)
> >
> >   WRITE( *, '( 5i5 )' ) my_func( x, y )
> >
> > END PROGRAM blah
> 
> What a slaughter of Fortran,

If you're basing this opinion on the code snippet I wrote above - I
defer to your expertise. I don't claim to be a Fortran 'spert or even a
programmer for that matter. (But everyone must aspire to something,
right?) As Dr. Maine pointed out in his reply, this is not the only way
to write the code (I wish you hadn't been as vitriolic as you were in
your response coz I would have liked to have seen his example - I get my
tips where I can, ya know.)

> showing every symptom of design by ignorant
> and incompetent committee. What happened, where they too busy with
> themselves to bother and learn from ADA?? If they did, they'd see
> something along these lines:
> 
>         function normalize(v: in vector) return vector is
>         vni: float;
>         begin
>           vni := 1./norm(v)
>           return (v(x)*vni, v(y)*vni, v(z)*vni);
>         end normalize;
> 
> --      somewhere in your code
>         u,v: vector;
>                 .
>                 .
>                 .
>         u := normalize(v);
> 
> The difference speaks for itself!!

Wow. You're right. I can understand my code. :o)

Sorry for sucking up the bandwidth with this reply, but, jeez, it's
fridy! Strawberry margeritas all round....my shout. 

cheers and avagoodweegend,

paulv
-- 
Paul van Delst           Ph:  (301) 763-8000 x7274 
CIMSS @ NOAA/NCEP        Fax: (301) 763-8545
Rm.202, 5200 Auth Rd.    Email: pvandelst@ncep.noaa.gov
Camp Springs MD 20746

Re: F9X twister & ADA (was: n-dim'l vectors)

[Brian Rogoff]

On 6 Apr 2000, Richard Maine wrote:
> In seriousness, those who can't learn to work well with others (including
> some with opposing viewpoints), do not tend to help progress on such
> things - no matter how brilliant they may be.  Offering gratuituous insults
> is not generally a good way to start.  Do you make comments like that to
> the people you work with regularly?  If so, does this help them get their
> jobs done?

I agree that bvoh's comments were very rude. This kind of behavior makes
it difficult to conduct a discussion across newsgroups and to compare 
language features in a way that we can all learn from.

(PS: Yes, I know that a preposition is not something that you are supposed
to end a sentence with. :-)

> Yes, by the way, the committee certainly looked at ADA.  And it shows in
> quite a few places.

That's great. I think Ada and Fortran have some overlap in problem domains 
they are addressing so it is wise to have some idea of how each language 
addresses similar problems so that we can compare solutions. I find such 
language comparisons helpful.

> The elided sample is not, of course, the only way to write the code in
> question.  Nor is it particularly close to the way I'd suggest writing
> it.  I rarely write out interface bodies - that's what modules are for.

I'd be interested in seeing the snippet rewritten in a more elegant
feature using the F9X features. I haven't used any Fortran since F77, 
with a little bit of Connection Machine Fortran while in grad school, 
so explanations of any subtleties would be appreciated. 

If you think that communication between the two newsgroups has
deteriorated just sending email would also be fine. 

Best regards

-- Brian

Re: F9X twister & ADA (was: n-dim'l vectors)

[Robert Dewar]

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

In article <slrn8eqva9.8gf.eedelman@tekno.helsinki.fi>,
  eedelman@rock.helsinki.no-sp�mm.fi (Erik Edelmann) wrote:
> Perhaps I'm just as stoopid as the Fortran comittee, but I
> really don't
> see what is so great about that code.  What if you want to
> normalize a
> vector with 10 elements instead of 3, for example?


It is trivial in Ada to handle variable sized arrays, the
example given (i.e. the code you quote) would be expected
to handle variable sized arrays in normal usage (i.e. it
is possible, but unusual, to write the type declarations
so that it was restricted to one particular size).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: F9X twister & ADA (was: n-dim'l vectors)

[Erik Edelmann]

On Thu, 06 Apr 2000 19:58:18 -0700, bv wrote:
>What a slaughter of Fortran, showing every symptom of design by ignorant
>and incompetent committee. What happened, where they too busy with
>themselves to bother and learn from ADA?? If they did, they'd see
>something along these lines:
>
>	function normalize(v: in vector) return vector is
>	vni: float;
>	begin
>	  vni := 1./norm(v)
>	  return (v(x)*vni, v(y)*vni, v(z)*vni);
>	end normalize;
>
>--	somewhere in your code   
>	u,v: vector;
>		.
>		.
>		.
>	u := normalize(v);

Perhaps I'm just as stoopid as the Fortran comittee, but I really don't
see what is so great about that code.  What if you want to normalize a
vector with 10 elements instead of 3, for example?


	Erik

Re: F9X twister & ADA (was: n-dim'l vectors)

[Erik Edelmann]

On Fri, 07 Apr 2000 14:19:40 GMT, Robert Dewar wrote:
>It is trivial in Ada to handle variable sized arrays, the
>example given (i.e. the code you quote) would be expected
>to handle variable sized arrays in normal usage (i.e. it
>is possible, but unusual, to write the type declarations
>so that it was restricted to one particular size).

Ok, but I still don't see how the Ada code in question is better than the
the Fortran code one could write to solve the problem.  The most natural
Fortran version of the code would IMHO even be slightly more elegant.


	Erik

Re: F9X twister & ADA (was: n-dim'l vectors)

[Dick Hendrickson]

Brian Rogoff wrote:
> 
> On 6 Apr 2000, Richard Maine wrote:
[snip]
> 
> > The elided sample is not, of course, the only way to write the code in
> > question.  Nor is it particularly close to the way I'd suggest writing
> > it.  I rarely write out interface bodies - that's what modules are for.
> 
> I'd be interested in seeing the snippet rewritten in a more elegant
> feature using the F9X features. I haven't used any Fortran since F77,
> with a little bit of Connection Machine Fortran while in grad school,
> so explanations of any subtleties would be appreciated.
> 
Here's what I'd try to do to modify the original F90 sample

    module  some_functions      ! put the function in a module
                                ! and it's characteristics are
                                ! available by magic to users.
    contains                    ! we could declare global variables
                                ! and data types above the "contains"
                                ! but we don't have any in this simple
                                ! case.  Also, we could put any related
                                ! functions or subroutines here.
                                ! We could also declare things PUBLIC
                                ! or PRIVATE to control access.
                                ! Also, I prefer lower case keywords
> > FUNCTION my_func ( x, y ) RESULT ( z )
> >
> >   IMPLICIT NONE
> >   INTEGER, INTENT( IN ), DIMENSION( : )         :: x, y
> >   INTEGER,               DIMENSION( SIZE( x ) ) :: z
> >
> >   z(:) = x(:) + y(:)   ! Assumes x and y are the same size
! I prefer  z = x + y
! The (:) makes it explicit that x, y, and z are arrays, some people
! like to know for sure what is going on, others like a little mystery 
! in their life.
> >
> >   RETURN       ! this isn't needed, but again adds clarity
> >
> > END FUNCTION my_func    !this implies return
    end module some_functions
> >
> > and then in the calling program:
> >
> > PROGRAM blah
> >
> >   IMPLICIT NONE
> >
      use some_functions   !this brings in the stuff from the module

!     we could have done  use some_functions, only ::  my_func
> >
> >   INTEGER, DIMENSION( 5 ) :: x = (/ -1,  1, -1,  1, -1 /), &
> >                              y = (/  1, -1,  1, -1,  1 /)
> >
> >   WRITE( *, '( 5i5 )' ) my_func( x, y )
> >
> > END PROGRAM blah

The rest of it looks OK to my style tastes.  I think the key fact
is that using a module allows the compiler to know about procedure
interfaces by magic; no need for explicit declarations.

If you want to see some simple examples of "modern" fortran try
looking at the F subset language.  Basically, F requires use of
the new Fortran 90 features and forbids use of the old FORTRAN 77
features.  We probably should have called it F13, ;-).

The Imagine1 web page
www.imagine1.com/imagine1
has some example code.

Dick Hendrickson
dick@imagine1.com

Re: F9X twister & ADA (was: n-dim'l vectors)

[Richard Maine]

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

> Here's what I'd try to do to modify the original F90 sample

[elided]

Not too different from what I'd have done.  Dick did the most
important thing, which was to put it in a module.

There are a few other things I'd probably do differently, but they are
smaller and are also definitely matters of personal style preferences.
I wouldn't say my style choice is better or worse - just different.
In particular...

I avoid the DIMENSION keyword, choosing a slightly more compact style.

I'd also have the "implicit none" at the module scope instead of in
the function (it gets inherited into the function).

And I don't usually use a result clause for a function, so take it off and
replace all instances of z by my_func.

Add appropriate comments and you'd then have pretty much the way I'd
have probably written this myself.  That ends up with (except for
the comments, which I won't bother with here)

    module  some_functions
      implicit none
    contains
      function my_func (x,y)
        integer, intent(in) :: x(:), y(:)
        integer :: my_func(size(x))
        z = x + y
        return
      end function my_func
    end module some_functions

The calling stuff is the same.

-- 
Richard Maine
maine@qnet.com

Re: F9X twister & ADA (was: n-dim'l vectors)

[Geoff Bull]

Dick Hendrickson wrote:

> If you want to see some simple examples of "modern" fortran try
> looking at the F subset language.  Basically, F requires use of
> the new Fortran 90 features and forbids use of the old FORTRAN 77
> features.  We probably should have called it F13, ;-).
> 

Shouldn't that be Fubar? :-)

Re: F9X twister & ADA (was: n-dim'l vectors)

[Gary Scott]

Richard Maine wrote:
> 
> Dick Hendrickson <dick.hendrickson@att.net> writes:
> 
> > Here's what I'd try to do to modify the original F90 sample
> 
> [elided]
> 
> Not too different from what I'd have done.  Dick did the most
> important thing, which was to put it in a module.
> 
> There are a few other things I'd probably do differently, but they are
> smaller and are also definitely matters of personal style preferences.
> I wouldn't say my style choice is better or worse - just different.
> In particular...
> 
> I avoid the DIMENSION keyword, choosing a slightly more compact style.
> 
> I'd also have the "implicit none" at the module scope instead of in
> the function (it gets inherited into the function).
> 
> And I don't usually use a result clause for a function, so take it off and
> replace all instances of z by my_func.
> 
> Add appropriate comments and you'd then have pretty much the way I'd
> have probably written this myself.  That ends up with (except for
> the comments, which I won't bother with here)

Do we need the following mod?

> 
>     module  some_functions
>       implicit none
>     contains
>       function my_func (x,y)
>         integer, intent(in) :: x(:), y(:)
>         integer :: my_func(size(x))
>  ==>    z = x + y
   ==>    my_func = x + y
>         return
>       end function my_func
>     end module some_functions
> 
> The calling stuff is the same.
> 
> --
> Richard Maine
> maine@qnet.com


-- 

Gary Scott
mailto:scottg@flash.net

mailto:webmaster@fortranlib.com
http://www.fortranlib.com

Support the GNU Fortran G95 Project:  http://xena.eas.asu.edu/~andy/

Re: F9X twister & ADA (was: n-dim'l vectors)

[Richard Maine]

Gary Scott <scottg@flash.net> writes:

> Richard Maine wrote:
> > And I don't usually use a result clause for a function, so take it off and
> > replace all instances of z by my_func.
..
> Do we need the following mod?
..
> >  ==>    z = x + y
>    ==>    my_func = x + y

Oops.  Yes.  I forgot to apply the above-mentioned change there.

-- 
Richard Maine
maine@qnet.com

Re: F9X twister & ADA (was: n-dim'l vectors)

[Dick Hendrickson]

Geoff Bull wrote:
> 
> Dick Hendrickson wrote:
> 
> > If you want to see some simple examples of "modern" fortran try
> > looking at the F subset language.  Basically, F requires use of
> > the new Fortran 90 features and forbids use of the old FORTRAN 77
> > features.  We probably should have called it F13, ;-).
> >
> 
> Shouldn't that be Fubar? :-)

I thought Fubar was a C term ;-)

Dick

Re: F9X twister & ADA (was: n-dim'l vectors)

[Robert Dewar]

In article <38F0D0B0.A5F9425@att.net>,
  Dick Hendrickson <dick.hendrickson@att.net> wrote:

> I thought Fubar was a C term ;-)


No, like bug it is MUCH MUCH older than people think, I know
it was used (usually spelled Foobar) in the Algol-60 world,
anyone know anything definitive on first use here?

P.S. bug was first used by Edison, the answer to the
million dollar question was an example of the show substituting
urban legend for fact (the moth was indeed found, but did NOT
give rise to the use of the word bug :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: F9X twister & ADA (was: n-dim'l vectors)

[Gordon Sande]

On Sun, 09 Apr 2000 19:25:09 GMT, Robert Dewar
<robert_dewar@my-deja.com> wrote:

>In article <38F0D0B0.A5F9425@att.net>,
>  Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
>> I thought Fubar was a C term ;-)
>
>
>No, like bug it is MUCH MUCH older than people think, I know
>it was used (usually spelled Foobar) in the Algol-60 world,
>anyone know anything definitive on first use here?
>
>P.S. bug was first used by Edison, the answer to the
>million dollar question was an example of the show substituting
>urban legend for fact (the moth was indeed found, but did NOT
>give rise to the use of the word bug :-)
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.

Supposed Army/etc acronyms. Certainly WWII or earlier.

FUBAR - Fouled Up Beyond All Recognition 
        (use your own favorite F*** word! 
         This is a family oriented newsgroup. ;-) )

It's FUBAR! A general description of disorder, etc.

FIGMO - Forget it, I Got My Orders
        (usually accompanied by a glassy look in the eyes
         and a general disinterest in the immediate situation)

Don't bother asking him, he's FIGMO! (Modern equiv - He just got
an offer to be CEO of a dot-com etc.)

"Raising Hell" is an alternaive to "Moving Heaven and Earth" when
strong concerted efforts are required. A fine example of getting
to the same end by differing paths.

etc

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Gordon Sande wrote in message <38f0e21a.3471088671@netnews.worldnet.att.net>...
...
>Supposed Army/etc acronyms. Certainly WWII or earlier.
>
>FUBAR - Fouled Up Beyond All Recognition
>        (use your own favorite F*** word!
>         This is a family oriented newsgroup. ;-) )
>
>It's FUBAR! A general description of disorder, etc.
>
>FIGMO - Forget it, I Got My Orders
>        (usually accompanied by a glassy look in the eyes
>         and a general disinterest in the immediate situation)
>
>Don't bother asking him, he's FIGMO! (Modern equiv - He just got
>an offer to be CEO of a dot-com etc.)

Similarly, SNAFU - Situation Normal: All Fouled Up.
        (use your own favorite F*** word!
         This is a family oriented newsgroup. ;-) )

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[tmoran]

> > I thought Fubar was a C term ;-)
> No, like bug it is MUCH MUCH older than people think, I know
> it was used (usually spelled Foobar) in the Algol-60 world,
  I'd always understood it was a variant ofSNAFU, and from WWII.
But I wasn't around at the time...

Re: F9X twister & ADA (was: n-dim'l vectors)

[bv]

Richard Maine wrote:
> 
> Yes, by the way, the committee certainly looked at ADA.  And it shows in
> quite a few places.

Surely, you're joking Mr."Feinman"? It takes a lot more than just
*looking* at ADA! Anyhow, in case the counter example in ADA baffled you
here's how the same fcn might look in the F9X that could have been:

	vector function normalize(v)
	external vector
	vector u,v
        real norm

        vni = 1/norm(v)
	do i=1,len(v)
	   u(i) = v(i)*vni
	enddo
        return u
        end

**      somewhere in your code  (sans interfaces & modules) 
        vector u,v, normalize
                .
                .
                .
        u = normalize(v)


Too bad for the missed chance when so much could have been done with but
a little extra tasking on the solitary assignments of the "return" and
"external".

--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.sdynamix.com
-----------------------------------------------

Re: F9X twister & ADA (was: n-dim'l vectors)

[bv]

Paul van Delst wrote:
> 
> If you're basing this opinion on the code snippet I wrote above ...


Nothing personal, I only used it to extend my compliments to the Fortran
Committee's design excellence -- you just followed a sickly standard,
that's all.

--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.sdynamix.com
-----------------------------------------------

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Van Buskirk]

bv wrote in message <38F28A85.53809F39@sdynamix.com>...

> vector function normalize(v)
> external vector
> vector u,v
>        real norm


>        vni = 1/norm(v)
> do i=1,len(v)
>    u(i) = v(i)*vni
> enddo
>        return u
>        end


>**      somewhere in your code  (sans interfaces & modules)
>        vector u,v, normalize
>                .
>                .
>                .
>        u = normalize(v)

module simple_1d_vector_stuff
   contains
      function normalize(v)
         real, intent(in) :: v(:)
         real normalize(size(v))
         real norm

         if(size(v) == 0) stop 'Can''t normalize zero length vector'
         norm = sqrt(dot_product(v,v)) ! OK for complex version, too
         if(norm == 0) stop 'Can''t normalize the zero vector'
         normalize = v/norm

      end function normalize
end module simple_1d_vector_stuff

**      somewhere in your code
        use simple_1d_vector_stuff
        integer, parameter :: vector_length = 3
        real u(vector_length),v(vector_length)
                .
                .
                .
        u = normalize(v)

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Dale Stanbrough wrote in message ...
>James Gilesm wrote:
>
>> It's very BAD language design to use the same keywords for
>> several distinct language features.
>
>I'm sorry but i would have to strongly disagree here. People
>are masters at contextual interpretation of the semantics of
>words. There are so many words in English that are decoded
>based on context (even pronunciation!) that I doubt this is
>really an issue.

You are welcome to disagree.  But, conclusions drawn from how
people use natural languages are not necessarily even applicable
to programming languages.  The reason that people get by
with multiple meanings, and manage to extract the meaning anyway,
is that natural languages are quite verbose and contain lots of
redundancies (which give extra clues) and people can ask for
something to be restated if it's not clear.

In programming languages, syntax with multiple different meanings
often leads to long learning curves for the language.  And (at least
in the case of C, with which I'm more familiar) it can lead to subtle
bugs that are hard to find and correct.  Most language designers
will avoid such whenever possible.  Since programming languages
are much smaller than natural languages, it's nearly *always* possible
to avoid lots of distinct uses for any given syntax.  There's no need
to ever introduce an opportunity for confusion.

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Geoff Bull wrote in message <38F2C1DC.5538F9F0@research.canon.com.au>...
>James Giles wrote:
>> Not that Ada is inherently superior.  They
>> did a lot of things badly too (their exception handling, for example).
>
>What don't you like about Ada exceptions?

They may have fixed it by now (I haven't used Ada since the '80s).
But, I haven't heard anything to suggest that exception handling
was changed in the more recent standards.

In Ada you can't tell what exceptions a procedure might generate
from it's use or declaration.  So your handler for a given block
can't assume that the condition that arises is from the local
code - if the block contains a procedure call.  Exceptions arising
from within procedures should be easily distinguishable from locally
generated exceptions.

A given exception might be actually handled by a remote ancestor
in the call tree: which couldn't possibly have any specific knowledge
about how to recover from an error so remote.  At some point you
should just turn such an exception into a non-specific "halt program"
signal.  Better: each procedure in the call tree should either explicitly handle
exceptions or *explicitly* pass them to its (immediate) caller.  If neither,
the program should halt right there.  Mystically skipping over several
levels of the call tree is messy.

Exception handling can be used as a form of Zahn's construct for
*normal* flow control (not involving any error conditions at all).
It is not very good programming practice, perhaps, but it can
easily be done.

If you intend to recover from them, handling hardware traps and faults
(like float exceptions, or  memory range errors) requires finer control
than block-level structures.  A single expression may have several
operations that might cause such faults.  If your exception handler
is at the block-level, it needs to have an elaborate bit of code just
to discover *which* possible cause actually triggered the exception.
(I don't know an easy solution for this.  But finer control is desirable
for such cases.)

Ada exception handling does too many things in one feature.  Multilevel
message passing (like C's setjump/longjump), one level error reporting
(like Fortran's alternate return), local error recovery, and ordinary
Zahn's-construct flow control. It would be better to have explicit
control over each of these different uses.

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[Larry Kilgallen]

In article <5jJI4.297$PV.9915@bgtnsc06-news.ops.worldnet.att.net>, "James Giles" <jamesgiles@worldnet.att.net> writes:

> A given exception might be actually handled by a remote ancestor
> in the call tree: which couldn't possibly have any specific knowledge
> about how to recover from an error so remote.

It depends upon error.  "disk space exhausted" would seem susceptible
to a general (though gross) cleanup approach, possibly quite short of
stopping the program.

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Larry Kilgallen wrote in message <2000Apr11.135942.1@eisner>...
>In article <5jJI4.297$PV.9915@bgtnsc06-news.ops.worldnet.att.net>, "James Giles"
<jamesgiles@worldnet.att.net> writes:
>
>> A given exception might be actually handled by a remote ancestor
>> in the call tree: which couldn't possibly have any specific knowledge
>> about how to recover from an error so remote.
>
>It depends upon error.  "disk space exhausted" would seem susceptible
>to a general (though gross) cleanup approach, possibly quite short of
>stopping the program.

If you unabiguously know where the problem arose, maybe (but only
maybe).  It may be possible to find a counterexample in the case of any
particular error.  But the contortions required to continue a computation
after an error get more elaborate the further the handler is from the
site of the error.  It seems to me a better structured approach is to
always handle errors (that you intend to recover from) as locally
as possible.  Non-specific "halt the program" messages can easily be
remotely handled.

Another issue is that the meaning of a given exception is different
depending on the context where it occurs.  At the lowest level
procedure, a "divide by zero" fault is just a arithmetical problem.
At the  next higher level, it may mean "second arg to function X
should not exceed the first".  At a the next higher level, it may mean
"structure ABC is discontinuous".  And so on.  If you intend to
recover from the fault, the identity of the error needs to be changed
at each level.  For the third procedure from the bottom to just get
"divide by zero" is probably meaningless in terms of the arguments
and functionality that it's aware of.

That's one of the things I meant when I said the Ada exception
mechanism tries to do to many different things.  Errors that you're
going to attempt to recover from are significantly different, conceptually,
from non-specific termination signals.

In any case, I don't intend to get into a long drawn out argument with
Ada supporters about their favorite language.  My interest is in what
exception handling might eventually be added to Fortran.  It is often
recommended to model the feature on Ada.  I think the committee
should consider addressing the shortcomings of Ada as well as its
advantages before just blanket adoption of the feature.

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[Larry Kilgallen]

In article <cEKI4.1694$fV.133027@bgtnsc05-news.ops.worldnet.att.net>, "James Giles" <jamesgiles@worldnet.att.net> writes:

> In any case, I don't intend to get into a long drawn out argument with
> Ada supporters about their favorite language.  My interest is in what
> exception handling might eventually be added to Fortran.  It is often
> recommended to model the feature on Ada.  I think the committee
> should consider addressing the shortcomings of Ada as well as its
> advantages before just blanket adoption of the feature.

Actually, I prefer the VMS exception model, which is a superset of
the Ada model.  Look at the VMS model if you are considering the
breadth of possibilities.  Interesting little nuances include the
question of what happens when you get an exception while handling
an exception (which of the stack-based handlers are eligible to
take charge) along with the whole issue of whether you can "continue"
right where you encountered the exception (after fixing up the source
of the problem).

Steve Lionel of Compaq can probably speak to how well this fits
into Fortran.

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

bv wrote in message <38F28A85.53809F39@sdynamix.com>...

>Surely, you're joking Mr."Feinman"?  [...]

You can't even competently get Feynman's name right?  And you still
insist that your program that normalizes a vector is a substitute for
one that sums two of them (that's what the example you responded to
actually did)?  And you expect to be taken seriously?

> ...  Anyhow, in case the counter example in ADA baffled you
>here's how the same fcn might look in the F9X that could have been:
>
> vector function normalize(v)
> external vector
> vector u,v
>        real norm
>
>        vni = 1/norm(v)
> do i=1,len(v)
>    u(i) = v(i)*vni
> enddo
>        return u
>        end
>
>**      somewhere in your code  (sans interfaces & modules)
>        vector u,v, normalize
>                .
>                .
>                .
>        u = normalize(v)


Looks awful.

Aside from the fact that it's 'outdented' (as opposed to indented),
there should be no loop.  Whole array syntax is preferable.  Though
I prefer (like some others) the form u(:) = v(:)*vni rather than use
the variables subscriptless.  Unfortunately, this form may be less
efficient on some implementations.

If NORM is known to be a function, its type should also be known
(otherwise you should have an interface), so the REAL declaration
should either be unnecessary or extended.

You've introduced a local variable name to take the place of the
function name - for no reason I can discern.  Accumulating the
result in the function name is perfectly clear.

I agree that typenames should be usable directly in declarations
(rather than as modifiers to the TYPE keyword).  This anomaly
exists because they decided to allow the :: (double colon) syntax
on all declarations, not just type declarations.  If it were required
on declarations of objects of a derived type and were prohibited
on non-type attribute specification statements, then you'd know that
any statement containing a :: *must* begin with a typename.  So,
you'd not need the TYPE keyword there. (Oh well.)

I don't know why EXTERNAL <typename> is in any way to be
considered superior to USE <module> where the type is defined.
With the USE form, you also get any additional functionality (like
the operator overloads appropriate to the type).

And so on....

>Too bad for the missed chance when so much could have been done with but
>a little extra tasking on the solitary assignments of the "return" and
>"external".

It's very BAD language design to use the same keywords for
several distinct language features.  And, there's no need in this
case not to use the Fortran features exactly as they are.  The
only place where the above form of RETURN would be superior
would be to eliminate the need for the RESULT variable on array
valued recursive functions.  This example doesn't contain such a function.
And USE is not less legible than your misuse of EXTERNAL. (Assuming
your proposed meaning was that the external statement would import
all the relevant definitions of the type 'vector', like overloaded operator
definitions and such, then the two forms are about the same.  Presumably
NORM would be among the primitives defined for the type - so the
REAL statement is really redundant even in your version.)

There are a *LOT* of things that the committee could have done
better in their design of Fortran 90.  You've identified only one of them
(the TYPE keyword).  Your other complaints are misplaced or just
wrong.  Yes, it's too bad the committee missed the chance to do
those other things....  Not that Ada is inherently superior.  They
did a lot of things badly too (their exception handling, for example).

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[Dale Stanbrough]

James Gilesm wrote:

> It's very BAD language design to use the same keywords for
> several distinct language features.

I'm sorry but i would have to strongly disagree here. People
are masters at contextual interpretation of the semantics of
words. There are so many words in English that are decoded
based on context (even pronunciation!) that I doubt this is
really an issue.

For example in Ada the word "new" is used for many uses...

   type X is new Integer; -- type derivation

   package X is new Blah (Integer); -- package instantiation

   fred := new Integer; -- heap allocation


Dale

Re: F9X twister & ADA (was: n-dim'l vectors)

[Geoff Bull]

James Giles wrote:
> Not that Ada is inherently superior.  They
> did a lot of things badly too (their exception handling, for example).

What don't you like about Ada exceptions?

Cheers
Geoff

Re: F9X twister & ADA (was: n-dim'l vectors)

[Robert A Duff]

"James Giles" <jamesgiles@worldnet.att.net> writes:

> In any case, I don't intend to get into a long drawn out argument with
> Ada supporters about their favorite language.

Well, I'm an Ada supporter who happens to agree with a lot of what you
said about exceptions.

>...  My interest is in what
> exception handling might eventually be added to Fortran.  It is often
> recommended to model the feature on Ada.  I think the committee
> should consider addressing the shortcomings of Ada as well as its
> advantages before just blanket adoption of the feature.

Yes.  Also look at Java, Eiffel, CLOS, Clu.

- Bob

Re: F9X twister & ADA (was: n-dim'l vectors)

[Robert A Duff]

"James Giles" <jamesgiles@worldnet.att.net> writes:

> You are welcome to disagree.  But, conclusions drawn from how
> people use natural languages are not necessarily even applicable
> to programming languages.

I know only one natural language well, and it is very poorly designed
indeed.  ;-)

- Bob

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Geoff Bull wrote in message <38F3D1D3.416B3493@research.canon.com.au>...
...
> Handling may be as simple as:
> when others => Put_line ("Internal error: contact vendor);
>
>which to me is a lot better than the program simply halting in the
>middle of nowhere. I can't see the advantage of halting immediately,
>if you want to halt just don't provided exception handlers.

If you can control that.  The procedures in Ada neither declare
which exceptions they might raise, nor have any other indications
that an exception might arise.  How do you *not* provide a
handler when you don't even know what it is that you're trying
not to handle?

In any case, for most of my own code I much prefer halting
immediately.  Most "graceful" termination involves doing
things that cover up evidence that might be needed to discover
the cause of the fault (closing files, deleting temporaries, leaving
the program counter and/or the registers in different states than
the context in which the error arose, etc.).  It's only for code
written for naive public consumption that "graceful" termination
is appropriate.  And yes, in this case a clear message is
important.

>>  Mystically skipping over several
>> levels of the call tree is messy.
>
>I don't understand what you mean here.

I can't see any opportunity for confusion here.  A procedure
raises an exception and some remote ancestor process catches
it.  Say, A calls B, B calls C (which is in a separately designed
library), C calls D, etc. through the whole alphabet and several
distinct, separately designed libraries.  When Z raises an
exception, A may have a handler active for it.  The programmer
who wrote A probably isn't even aware that procedure Z exists,
much less is (s)he prepared to handle an error that arose there.

Now, a signal (as distinct from an exception) might be proper
here.  But signals are generally for external things (like: your
asynch I/O is done) or for non-specific, but fatal things (like KILL).
If Z wants to send a KILL signal and procedure A has set up
a handler for that signal (to do "graceful" termination, for
example), that's fine.  You're not pretending to be able to
handle a given specific error.  And you'll respond identically
whether the signal was internally generated or sent from the
system or the program's user.

The whole idea of libraries (and most modular programming)
is for different programmers and teams *not* to have to
know the internals of the work of others.  Yet, raised exceptions
propagate across such boundaries in an undeclared and, usually
undocumented way.

At the very least, the programmer should never allow an exception
to leave the confines of the package in which it is raised (which may
consist of many levels of procedures to be sure) without explicitly
declaring to the users of the package which public procedures
may raise an exception that the package itself doesn't handle.
What exceptions each of these may raise should also be explicitly
declared.  Yes, this means that when you add code which may
raise exceptions to a procedure, you have to recompile (and maybe
even rewrite) code which uses that procedure.  This is no different
than any other case in which you changed a procedure in a way
in which its public (interface) properties have changed.  Or, are
you claiming that an exception is not a public property of the
procedure which raises it?

Ideally, the language design itself should enforce this rule.  It's
certainly the kind of thing that should be considered when designing
an exception handling mechanism for a language which doesn't yet
possess one.

One of the nice things about discussions of this type is that
it forces the re-evaluation of previous ideas in new light.  About
three years ago I posted a suggestion for Fortran exception
handling (which was criticized and/or ignored).  Already, from
this thread I see several things I'd now suggest be done
differently.  But I still wouldn't recommend Ada as an ideal
model.
--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Geoff Bull wrote in message <38F3F803.A4A56259@research.canon.com.au>...
...
>Actually, in my case the point of flushing files is to *not* throw away
>the evidence of where the program was up to when it crashed.

There's a difference between flushing files (which I didn't even
mention) and closing them (which loses file position information
and, on UNIX, may actually destroy temporary files).  And,
branching to a handler probably loses all of the register contents
that were present when the error arose.  I still prefer to quit
*immediately*.

The buffers are inside the system and not part of my process
image anyway.  There should be no way to quit, suspend, or
even pause a process which doesn't flush them (the system will
need the space for other processes anyway).  Systems which
throw away I/O buffer information when a process terminates
are seriously broken.

...
>Going back to your earlier example, if you decided to raise
>an exception in Z and you really did want to handle it in A
>(because of requirement of graceful operation for naive users),
>you would have to go back and modify procedures B .. Y to
>either handle or pass on the exception.

Or, you'd have to express the desire to "gracefully" terminate
in a way that doesn't involve exceptions.  Like the possibility
of sending yourself a KILL signal.  Now, you're not pretending
to be *handling* an error (which implies the possibility of
recovery), you're just quitting.

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Geoff Bull wrote in message <38F41313.DAF90E74@research.canon.com.au>...
...
>>   And,
>> branching to a handler probably loses all of the register contents
>> that were present when the error arose.
>I'm missing something.
>By my definition of quit immediately you lose the contents of registers too.

Those are (should be) in the drop-file, core file, or whatever is
generated on your system that the debugger gets to look at when
a program abnormally terminates.  If the program continues to run
*after* the error is detected, this information reflects the state
the program is in when it *does* finally terminate (ie. after
"graceful" termination).

>> The buffers are inside the system and not part of my process
>> image anyway.  Systems which
>> throw away I/O buffer information when a process terminates
>> are seriously broken.
>
>What about buffered io and user defined buffering?

Like all parts of the program's state, those are all still present
*in* the debugging file.  You can inspect them there.

>>  Like the possibility
>> of sending yourself a KILL signal.
>
>Well, I'll admit to once doing this in a C program.
>But it seems amazingly ugly compared to simply raising an exception,
>to get precisely the same outcome.

I think undocumented exceptions are clearly the ugliest way to
accomplish this. Any public property of a procedure which isn't
explicitly declared - by direct requirement of the language
definition - is probably a bad idea.

> And sending signals is not portable (especially to bare hw with no OS).

And, sending signals would be perfectly portable if the language
standard required them.  How bare is the hardware?  If it's all
*that* bare, it won't support I/O or exceptions either.

>Of course you have no more way of knowing which library routines might
>send signals than you do of knowing which might raise exceptions.

Why not?  The fact that a routine sends a signal can be explicitly
declared (by requirement of the language, even).  But, since the
semantics of signals isn't attached to the procedure-call chain,
there's no need to declare this fact for each procedure that calls
the one that sends the signal.  Signals are, explicitly, messages to
the process as a whole.  They are not messages to the nearest
active caller that has a handler defined.

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Marin D. Condic wrote in message <38F492A7.997140CF@quadruscorp.com>...
>Geoff Bull wrote:
>> >  I still prefer to quit *immediately*.
>> You missed my point.
>> Depending on the situation different users will have different needs.
>> Quit immediately simply isn't appropriate in may situations,
>> even if it happens to be perfect for you.
>>
>I'm with you. Core dumps and such are interesting when you are in
>program development mode and you need information about where something
>terminated, etc. But in production mode, core dumps are at minimum
>impolite. [...]


Gee, I guess you missed earlier in this thread when I said:

>In any case, for most of my own code I much prefer halting
>immediately.  Most "graceful" termination involves doing
>things that cover up evidence that might be needed to discover
>the cause of the fault (closing files, deleting temporaries, leaving
>the program counter and/or the registers in different states than
>the context in which the error arose, etc.).  It's only for code
>written for naive public consumption that "graceful" termination
>is appropriate.  And yes, in this case a clear message is
>important.

Any code I write myself (or any "in-house" code) is in the
presence of the developer(s).  If there's an error, the proper
course of action to take depends on who's running the program.
If it's my own code, the proper action is to preserve as much
information about the failure as possible - in order that I can
fix it.

I'm sorry if you missed the fact that there are two aspects of
this thread.  First, there is the claim that it's *never* desirable
to halt immediately, that I disagree with.  Second, there is the
claim that, when you *are* going to catch the error and "gracefully"
terminate, having the raised exception be handled by a non-specified
(and often completely surprised) exception handler is desirable.

"Completely surprised" did I say?  Yes.  In the earlier example,
suppose procedure Z raises an exception that A has an active
handler for.  The author of A as I specified, is a different person
than the author of Z.  In fact the author of A is using a library written
by some third party who wrote neither A nor Z.  Z is only present at
the end of a long dependency chain through several libraries written
by different people.  If the author of A wrote a handler for a given
exception, it was almost certainly to handle a problem that he knew
might arise *in* A.  The message written by the handler (or other
remedial action) will be written under the assumption that the
cause of the exception was the expected possibility within A.
Later, when debugging the problem, the author of A will be
completely surprised that the exception came, in this case, from
Z (a procedure which the author of A had no prior knowledge
of at all).

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Marin D. Condic wrote in message <38F492A7.997140CF@quadruscorp.com>...
>Geoff Bull wrote:
>> >  I still prefer to quit *immediately*.
>> You missed my point.
>> Depending on the situation different users will have different needs.
>> Quit immediately simply isn't appropriate in may situations,
>> even if it happens to be perfect for you.
>>
>I'm with you. Core dumps and such are interesting when you are in
>program development mode and you need information about where something
>terminated, etc. But in production mode, core dumps are at minimum
>impolite. [...]


Gee, I guess you missed earlier in this thread when I said:

>In any case, for most of my own code I much prefer halting
>immediately.  Most "graceful" termination involves doing
>things that cover up evidence that might be needed to discover
>the cause of the fault (closing files, deleting temporaries, leaving
>the program counter and/or the registers in different states than
>the context in which the error arose, etc.).  It's only for code
>written for naive public consumption that "graceful" termination
>is appropriate.  And yes, in this case a clear message is
>important.

Any code I write myself (or any "in-house" code) is in the
presence of the developer(s).  If there's an error, the proper
course of action to take depends on who's running the program.
If it's my own code, the proper action is to preserve as much
information about the failure as possible - in order that I can
fix it.

I'm sorry if you missed the fact that there are two aspects of
this thread.  First, there is the claim that it's *never* desirable
to halt immediately, that I disagree with.  Second, there is the
claim that, when you *are* going to catch the error and "gracefully"
terminate, having the raised exception be handled by a non-specified
(and often completely surprised) exception handler is desirable.

"Completely surprised" did I say?  Yes.  In the earlier example,
suppose procedure Z raises an exception that A has an active
handler for.  The author of A as I specified, is a different person
than the author of Z.  In fact the author of A is using a library written
by some third party who wrote neither A nor Z.  Z is only present at
the end of a long dependency chain through several libraries written
by different people.  If the author of A wrote a handler for a given
exception, it was almost certainly to handle a problem that he knew
might arise *in* A.  The message written by the handler (or other
remedial action) will be written under the assumption that the
cause of the exception was the expected possibility within A.
Later, when debugging the problem, the author of A will be
completely surprised that the exception came, in this case, from
Z (a procedure which the author of A had no prior knowledge
of at all).

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[Robert I. Eachus]

Dick Hendrickson wrote:
  
> I thought Fubar was a C term ;-)

    Actually, fubar was orriginally a military term, an acronym for
fouled up beyond all recognition--i.e. what normally happens to a battle
plan upon contact with the enemy. I know it goes back to WWII, I don't
know if it goes back further.  Incidently, the current equivalent is a
"goat rope."

Re: F9X twister & ADA (was: n-dim'l vectors)

[Geoff Bull]

James Giles wrote:
> Better: each procedure in the call tree should either explicitly handle
> exceptions or *explicitly* pass them to its (immediate) caller.  If neither,
> the program should halt right there.

This is essentially the Java approach, except for the halt feature
(Java doesn't allow the situation to occur where halt would occur).
The problem with this is it makes code maintenace a disaster.
Say you modify a routine and decide it should be changed so it now raises
an exception. You then need to to go fix every place that routine is used
to propagate the exception up to some upper level where you want to handle it.
Handling may be as simple as:
	when others => Put_line ("Internal error: contact vendor);

which to me is a lot better than the program simply halting in the
middle of nowhere. I can't see the advantage of halting immediately,
if you want to halt just don't provided exception handlers.

Apart from its Exception, Java includes a throwable Error, which is
analagous to Ada's exception in that you are not forced to explicitly
deal with it. I find Java's exceptions a pain, often when I catch
them I just raise an Error - I can't halt by calling System.exit()
because I need to catch the Error at the top level and do an
orderly cleanup (e.g. flush files).


>  Mystically skipping over several
> levels of the call tree is messy.

I don't understand what you mean here.

Cheers
Geoff

Re: F9X twister & ADA (was: n-dim'l vectors)

[Geoff Bull]

James Giles wrote:
>  How do you *not* provide a
> handler when you don't even know what it is that you're trying
> not to handle?

Documentation, tools and testing.

> 
> In any case, for most of my own code I much prefer halting
> immediately. 
You might prefer it, but I don't. Forced halting would suck
from my point of view.

> Most "graceful" termination involves doing
> things that cover up evidence that might be needed to discover
> the cause of the fault (closing files, deleting temporaries, leaving
> the program counter and/or the registers in different states than
> the context in which the error arose, etc.).  It's only for code
> written for naive public consumption that "graceful" termination
> is appropriate.

Actually, in my case the point of flushing files is to *not* throw away 
the evidence of where the program was up to when it crashed.
Also graceful termination might be disabling of an impending missile
launch, or doing a retry using a backup system,
or sending a failure notice to a remote system.

> >>  Mystically skipping over several
> >> levels of the call tree is messy.
> >
> >I don't understand what you mean here.
> 
> I can't see any opportunity for confusion here.  

Ada exceptions are neither mystical nor messy, so I thought
you must be talking about something else.


>  Yes, this means that when you add code which may
> raise exceptions to a procedure, you have to recompile (and maybe
> even rewrite) code which uses that procedure.  This is no different
> than any other case in which you changed a procedure in a way
> in which its public (interface) properties have changed.

Going back to your earlier example, if you decided to raise 
an exception in Z and you really did want to handle it in A 
(because of requirement of graceful operation for naive users),
you would have to go back and modify procedures B .. Y to
either handle or pass on the exception.


>  Or, are
> you claiming that an exception is not a public property of the
> procedure which raises it?
No.
I agree with your sentiments.
But I can't think of a workable implemetation.
Certainly the way Java does it can be a headache.
Other difficulties with Java style exceptions
in Ada have been previously discussed in comp.lang.ada.

Cheers
Geoff

Re: F9X twister & ADA (was: n-dim'l vectors)

[Geoff Bull]

James Giles wrote:
> 
> Geoff Bull wrote in message <38F3F803.A4A56259@research.canon.com.au>...
> ...
> >Actually, in my case the point of flushing files is to *not* throw away
> >the evidence of where the program was up to when it crashed.
> 
> There's a difference between flushing files (which I didn't even
> mention) and closing them
They not much point going to a whole lot of trouble to explicitly
close them if you're not going to bother flushinf unwritten buffers

>   And,
> branching to a handler probably loses all of the register contents
> that were present when the error arose.
I'm missing something.
By my definition of quit immediately you lose the contents of registers too.


>  I still prefer to quit *immediately*.
You missed my point.
Depending on the situation different users will have different needs.
Quit immediately simply isn't appropriate in may situations,
even if it happens to be perfect for you.

> 
> The buffers are inside the system and not part of my process
> image anyway.  Systems which
> throw away I/O buffer information when a process terminates
> are seriously broken.

What about buffered io and user defined buffering?


>  Like the possibility
> of sending yourself a KILL signal.  

Well, I'll admit to once doing this in a C program.
But it seems amazingly ugly compared to simply raising an exception,
to get precisely the same outcome.
And sending signals is not portable (especially to bare hw with no OS).

Of course you have no more way of knowing which library routines might
send signals than you do of knowing which might raise exceptions.

Re: F9X twister & ADA (was: n-dim'l vectors)

[Marin D. Condic]

Geoff Bull wrote:
> >  I still prefer to quit *immediately*.
> You missed my point.
> Depending on the situation different users will have different needs.
> Quit immediately simply isn't appropriate in may situations,
> even if it happens to be perfect for you.
> 
I'm with you. Core dumps and such are interesting when you are in
program development mode and you need information about where something
terminated, etc. But in production mode, core dumps are at minimum
impolite. (You shouldn't have any deadly errors at this point, but I
guess we've all been conditioned to accept it as a way of life by
Micro$oft and all those C apps that misreference memory all the time.)

In mission critical systems (and by extension, any application where you
think a core dump would be rude.) it is not acceptable to simply halt in
your tracks because somewhere a divide by zero or illegal memory
reference happened. If Micro$oft Word were to suddenly blow a gasket in
the middle of an editing session and not save my work, I'm going to be
upset. (Hey, wait a minute.....! :-) Even if the requirements are "fail
fixed" there is probably some point in detecting the error and doing an
orderly shutdown.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: F9X twister & ADA (was: n-dim'l vectors)

[James Giles]

Geoff Bull wrote in message <38F53816.3D1F28A6@research.canon.com.au>...
...
>> I think undocumented exceptions are clearly the ugliest way to
>> accomplish this.
>
>But there is nothing wrong with clearly documented exceptions?

If all the public properties of a procedure are required to be
explicitly declared, then that's sufficient "documentation".  However,
that is exactly the property that you seem to object to.  My
suggestion of using signals instead is in response to your
objections to explicit declarations of all exceptions.  But,
you don't approve of that either.  Is it just the case that you
don't like anything that's different than what you used to?

>> How bare is the hardware?  If it's all
>> *that* bare, it won't support I/O or exceptions either.
>
>Bare = no OS.
>Just the the language defined runtime + your program.

So, signals would still be there if required by the language definition.
They would be in the runtime library for any implementation
written for bare hardware.

--

By the way, I'm surprised you actually saw and read the article you
just responded to.  I never did.  As far as I could tell it was just
swallowed up by the usenet goblins.  I cancelled it before sending
a replacement (which consisted only of the first half).  If anyone
saw several copies or none, sorry.  Who knows.

--
J. Giles

Debugging (was: F9X twister & ADA)

[James Giles]

Geoff Bull wrote in message <38F53816.3D1F28A6@research.canon.com.au>...
>James Giles wrote:
>
>> >What about buffered io and user defined buffering?
>>
>> Like all parts of the program's state, those are all still present
>> *in* the debugging file.  You can inspect them there.
>
>But I'd prefer it in a place defined by me!
>I hate looking at core dumps and, thankfully, since using
>Ada I *never* have to - same for Java. (when I was a C/Fortran I
>lived in the debugger, I get the impression you are still stuck there )

That sounds very inconvenient to me.  If I had to design a replacement
for what the system produces as a 'dropfile' or 'core file' (or whatever
it's called in your system) it would have to be about the same.  It would
contain all the data that such things usually contain or it would be
inadequate (leaving out important parts of the context of the failure).
This apparently happens to you: since you've made it clear that
a halted program, in whatever environment you're using, loses the
register contents present at the point of failure.  What else are you
losing?

And, if I were forced to invent a browser for going through the
corpse of a failed program, it would be very much like a debugger
(usually displaying data in terms of the program's source, etc.).
The only difference from usual debuggers would be that I would make
the core image editable and restartable.  That way I could often
correct and restart a long running program rather than have to
rerun it from scratch after finding the problem.  I've done this often
on systems that implemented editable and restartable program
images.

Since most of what is necessary to do would be very similar to what
the systems people have already done for core images and debuggers,
it would be very inconvenient to have to reinvent it myself.  Do you
have to do this on a program by program basis?

>In any embedded / real time context your proposal is just plain wrong.

Not during program development.  That's the context I have
very clearly been discussing.  I have clearly stated that for
released code for general naive users, some form of graceful
termination is important.  For embedded/real-time code (which
we haven't discussed before), no form of termination is appropriate:
the code has to continue to run (though maybe in an impaired way).

You can always invalidate someone's position by changing the
context of the  discussion, but how does that further any objective
analysis of the problem at hand?

>Stop dead on exception would be difficult to implement if the
>program is multithreaded or distributed across multiple machines?

Nope.  The thread that fails stops immediately.  All others stop at
the next rendezvous.  Why would that be difficult?

What I want is that combination of features which most increases the
likelyhood of finding the error quickly and allowing me to continue
working (either developing code, or working with my in-house
production code).

--
J. Giles

Re: F9X twister & ADA (was: n-dim'l vectors)

[Geoff Bull]

James Giles wrote:

> >What about buffered io and user defined buffering?
> 
> Like all parts of the program's state, those are all still present
> *in* the debugging file.  You can inspect them there.

But I'd prefer it in a place defined by me!
I hate looking at core dumps and, thankfully, since using
Ada I *never* have to - same for Java. (when I was a C/Fortran I
lived in the debugger, I get the impression you are still stuck there )

In any embedded / real time context your proposal is just plain wrong.

Stop dead on exception would be difficult to implement if the
program is multithreaded or distributed across multiple machines?

> I think undocumented exceptions are clearly the ugliest way to
> accomplish this.

But there is nothing wrong with clearly documented exceptions?

> Any public property of a procedure which isn't
> explicitly declared - by direct requirement of the language
> definition - is probably a bad idea.

Are you saying this is ok:
(yes I know Start should return a boolean,
instead of raising an exception)

package Rocket_Motor is

   procedure Start;
   --  may raise Primary_Ignition_Failed

   Primary_Ignition_Failed : exception;

end Rocket_Motor;

package body Rocket_Motor is

   procedure Start is
   begin
      ...
   exception
      when Constraint_Error =>
         raise Primary_Ignition_Failed;
   end Start;

end Rocket_Motor;

with Rocket_Motor;
procedure Launch is
begin
   ...
   Rocket_Motor.Start;
   ...
exception
   when Primary_Ignition_Failed =>
      Fail_Safe; 
 
end Launch;

?
Are you just objecting to raising (e.g.) Constraint_Error?
If so, it would be reasonably easy to write an asis tool
to enforce this policy.


> How bare is the hardware?  If it's all
> *that* bare, it won't support I/O or exceptions either.

Bare = no OS.
Just the the language defined runtime + your program.

Re: F9X twister & ADA (was: n-dim'l vectors)

[Geoff Bull]

James Giles wrote:
> your
> objections to explicit declarations of all exceptions. 

As I said, Java requires this and it can make modifying code difficult.

In addition almost every Ada subroutine
would have to explictly declared as raisng constraint_error.
This seems just plain silly.

If you look up deja, you will find a previosu discussion
of this topic.

I certainly have nothing further to add.

Re: F9X twister & ADA (was: n-dim'l vectors)

[bv]

James Giles wrote:
>
> Looks awful.
> 
> Aside from the fact that it's 'outdented' (as opposed to indented),
> there should be no loop.  Whole array syntax is preferable. Though

clf's windmilling Don Quixote assails his own outdenting editor and then
deliriously points his finger. Just how *silly* can you get...

btw, "Can a function return an n-dimensional vector?" was the subject.
Couldn't hurt  if you'd remember details like that in the future.

--
bv

Re: F9X twister & ADA (was: n-dim'l vectors)

[Aidan Skinner]

Robert Dewar <robert_dewar@my-deja.com> writes:

> No, like bug it is MUCH MUCH older than people think, I know
> it was used (usually spelled Foobar) in the Algol-60 world,
> anyone know anything definitive on first use here?

Foldoc claims it was used in at the TMRC, which is where the MIT AI
Lab probably picked it up, possibly from a "Smokey Stover" comic by
Bill Holman.

Unfortunately I just lost an hour in there...

- Aidan
-- 
http://www.reality.co.uk/
http://www.skinner.demon.co.uk/aidan/
"I could always suspend a few hundred accounts and watch what happens"

Re: F9X twister & ADA (was: n-dim'l vectors)

[Ken Garlington]

Of course, FUBAR was used during World War II, as anyone who has seen
"Saving Private Ryan" can attest.

The Jargon File notes that "Fubar" and "Foobar" mean two different things,
with both being a variation of "foo". See
http://www.tuxedo.org/~esr/jargon/html/entry/foo.html


"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:8cqle7$p36$1@nnrp1.deja.com...
> In article <38F0D0B0.A5F9425@att.net>,
>   Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
> > I thought Fubar was a C term ;-)
>
>
> No, like bug it is MUCH MUCH older than people think, I know
> it was used (usually spelled Foobar) in the Algol-60 world,
> anyone know anything definitive on first use here?
>
> P.S. bug was first used by Edison, the answer to the
> million dollar question was an example of the show substituting
> urban legend for fact (the moth was indeed found, but did NOT
> give rise to the use of the word bug :-)
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: F9X twister & ADA (was: n-dim'l vectors)

[Robert I. Eachus]

Aidan Skinner wrote:
> 
> Robert Dewar <robert_dewar@my-deja.com> writes:
> 
> > No, like bug it is MUCH MUCH older than people think, I know
> > it was used (usually spelled Foobar) in the Algol-60 world,
> > anyone know anything definitive on first use here?
> 
> Foldoc claims it was used in at the TMRC, which is where the MIT AI
> Lab probably picked it up, possibly from a "Smokey Stover" comic by
> Bill Holman.

    This is just to confirm the use of FOO (actually F00) at TMRC. 
(Tech Model Railroad Club).
When I was a freshman in 1964, the HO layout was controlled using dozens
of telephone stepping switches mounted under the platform.  (It was
later converted to use a set of 3? crossbar switches.)  This allowed
users to dial the block containing the train they wanted to control from
one of several control stations, and the switching network would
automagically follow the train from block to block.  (Switches could
also be changed by dialing them up.)  Of course with several users
running trains, and in some cases trying to set up collisions and ner
collisions, the system would often get in a situation where it had to
"drop" a user.  That user could then dial back in and pick up where he
left off.  There was a status board on the wall to show when this
happened, which could display one alphanumeric character and two
digits.  So the alpha was used to indicate the failure condition, and
the two digits the block or switch number.  F00, of course, was a
general system failure.

    I have no idea if this is the original use of foo in this context. 
But it is certainly the reason that the first and third metavariables
were spelled foo and foobar at Project MAC and in the AI Lab.