* F9X twister & ADA (was: n-dim'l vectors) [not found] ` <38EA0440.1ECBC158@ncep.noaa.gov> @ 2000-04-06 0:00 ` bv 2000-04-06 0:00 ` Richard Maine ` (2 more replies) 0 siblings, 3 replies; 48+ messages in thread From: bv @ 2000-04-06 0:00 UTC (permalink / raw) 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 ----------------------------------------------- ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-06 0:00 ` F9X twister & ADA (was: n-dim'l vectors) bv @ 2000-04-06 0:00 ` Richard Maine 2000-04-07 0:00 ` Brian Rogoff 2000-04-10 0:00 ` bv 2000-04-07 0:00 ` Erik Edelmann 2000-04-07 0:00 ` Paul van Delst 2 siblings, 2 replies; 48+ messages in thread From: Richard Maine @ 2000-04-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-06 0:00 ` Richard Maine @ 2000-04-07 0:00 ` Brian Rogoff 2000-04-08 0:00 ` Dick Hendrickson 2000-04-10 0:00 ` bv 1 sibling, 1 reply; 48+ messages in thread From: Brian Rogoff @ 2000-04-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-07 0:00 ` Brian Rogoff @ 2000-04-08 0:00 ` Dick Hendrickson 2000-04-08 0:00 ` Richard Maine 2000-04-09 0:00 ` Geoff Bull 0 siblings, 2 replies; 48+ messages in thread From: Dick Hendrickson @ 2000-04-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-08 0:00 ` Dick Hendrickson @ 2000-04-08 0:00 ` Richard Maine 2000-04-09 0:00 ` Gary Scott 2000-04-09 0:00 ` Geoff Bull 1 sibling, 1 reply; 48+ messages in thread From: Richard Maine @ 2000-04-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-08 0:00 ` Richard Maine @ 2000-04-09 0:00 ` Gary Scott 2000-04-09 0:00 ` Richard Maine 0 siblings, 1 reply; 48+ messages in thread From: Gary Scott @ 2000-04-09 0:00 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Gary Scott @ 2000-04-09 0:00 ` Richard Maine 0 siblings, 0 replies; 48+ messages in thread From: Richard Maine @ 2000-04-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-08 0:00 ` Dick Hendrickson 2000-04-08 0:00 ` Richard Maine @ 2000-04-09 0:00 ` Geoff Bull 2000-04-09 0:00 ` Dick Hendrickson 1 sibling, 1 reply; 48+ messages in thread From: Geoff Bull @ 2000-04-09 0:00 UTC (permalink / raw) 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? :-) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Geoff Bull @ 2000-04-09 0:00 ` Dick Hendrickson 2000-04-09 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 48+ messages in thread From: Dick Hendrickson @ 2000-04-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Dick Hendrickson @ 2000-04-09 0:00 ` Robert Dewar 2000-04-09 0:00 ` Gordon Sande ` (3 more replies) 2000-04-12 0:00 ` Robert I. Eachus 1 sibling, 4 replies; 48+ messages in thread From: Robert Dewar @ 2000-04-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Robert Dewar @ 2000-04-09 0:00 ` Gordon Sande 2000-04-09 0:00 ` James Giles 2000-04-10 0:00 ` tmoran ` (2 subsequent siblings) 3 siblings, 1 reply; 48+ messages in thread From: Gordon Sande @ 2000-04-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Gordon Sande @ 2000-04-09 0:00 ` James Giles 0 siblings, 0 replies; 48+ messages in thread From: James Giles @ 2000-04-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Robert Dewar 2000-04-09 0:00 ` Gordon Sande @ 2000-04-10 0:00 ` tmoran 2000-04-15 0:00 ` Aidan Skinner 2000-04-16 0:00 ` Ken Garlington 3 siblings, 0 replies; 48+ messages in thread From: tmoran @ 2000-04-10 0:00 UTC (permalink / raw) > > 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... ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Robert Dewar 2000-04-09 0:00 ` Gordon Sande 2000-04-10 0:00 ` tmoran @ 2000-04-15 0:00 ` Aidan Skinner 2000-04-17 0:00 ` Robert I. Eachus 2000-04-16 0:00 ` Ken Garlington 3 siblings, 1 reply; 48+ messages in thread From: Aidan Skinner @ 2000-04-15 0:00 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-15 0:00 ` Aidan Skinner @ 2000-04-17 0:00 ` Robert I. Eachus 0 siblings, 0 replies; 48+ messages in thread From: Robert I. Eachus @ 2000-04-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Robert Dewar ` (2 preceding siblings ...) 2000-04-15 0:00 ` Aidan Skinner @ 2000-04-16 0:00 ` Ken Garlington 3 siblings, 0 replies; 48+ messages in thread From: Ken Garlington @ 2000-04-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-09 0:00 ` Dick Hendrickson 2000-04-09 0:00 ` Robert Dewar @ 2000-04-12 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 48+ messages in thread From: Robert I. Eachus @ 2000-04-12 0:00 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-06 0:00 ` Richard Maine 2000-04-07 0:00 ` Brian Rogoff @ 2000-04-10 0:00 ` bv 2000-04-10 0:00 ` James Van Buskirk 2000-04-11 0:00 ` James Giles 1 sibling, 2 replies; 48+ messages in thread From: bv @ 2000-04-10 0:00 UTC (permalink / raw) 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 ----------------------------------------------- ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-10 0:00 ` bv @ 2000-04-10 0:00 ` James Van Buskirk 2000-04-11 0:00 ` James Giles 1 sibling, 0 replies; 48+ messages in thread From: James Van Buskirk @ 2000-04-10 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-10 0:00 ` bv 2000-04-10 0:00 ` James Van Buskirk @ 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Geoff Bull ` (2 more replies) 1 sibling, 3 replies; 48+ messages in thread From: James Giles @ 2000-04-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` James Giles @ 2000-04-11 0:00 ` Geoff Bull 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Dale Stanbrough 2000-04-14 0:00 ` bv 2 siblings, 1 reply; 48+ messages in thread From: Geoff Bull @ 2000-04-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` Geoff Bull @ 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Larry Kilgallen 2000-04-12 0:00 ` Geoff Bull 0 siblings, 2 replies; 48+ messages in thread From: James Giles @ 2000-04-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` James Giles @ 2000-04-11 0:00 ` Larry Kilgallen 2000-04-11 0:00 ` James Giles 2000-04-12 0:00 ` Geoff Bull 1 sibling, 1 reply; 48+ messages in thread From: Larry Kilgallen @ 2000-04-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` Larry Kilgallen @ 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Larry Kilgallen 2000-04-12 0:00 ` Robert A Duff 0 siblings, 2 replies; 48+ messages in thread From: James Giles @ 2000-04-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` James Giles @ 2000-04-11 0:00 ` Larry Kilgallen 2000-04-12 0:00 ` Robert A Duff 1 sibling, 0 replies; 48+ messages in thread From: Larry Kilgallen @ 2000-04-11 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Larry Kilgallen @ 2000-04-12 0:00 ` Robert A Duff 1 sibling, 0 replies; 48+ messages in thread From: Robert A Duff @ 2000-04-12 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Larry Kilgallen @ 2000-04-12 0:00 ` Geoff Bull 2000-04-12 0:00 ` James Giles 1 sibling, 1 reply; 48+ messages in thread From: Geoff Bull @ 2000-04-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` Geoff Bull @ 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` Geoff Bull 0 siblings, 1 reply; 48+ messages in thread From: James Giles @ 2000-04-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` James Giles @ 2000-04-12 0:00 ` Geoff Bull 2000-04-12 0:00 ` James Giles 0 siblings, 1 reply; 48+ messages in thread From: Geoff Bull @ 2000-04-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` Geoff Bull @ 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` Geoff Bull 0 siblings, 1 reply; 48+ messages in thread From: James Giles @ 2000-04-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` James Giles @ 2000-04-12 0:00 ` Geoff Bull 2000-04-12 0:00 ` Marin D. Condic 2000-04-12 0:00 ` James Giles 0 siblings, 2 replies; 48+ messages in thread From: Geoff Bull @ 2000-04-12 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` Geoff Bull @ 2000-04-12 0:00 ` Marin D. Condic 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` James Giles 1 sibling, 2 replies; 48+ messages in thread From: Marin D. Condic @ 2000-04-12 0:00 UTC (permalink / raw) 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] ====================================================================== ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` Marin D. Condic @ 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` James Giles 1 sibling, 0 replies; 48+ messages in thread From: James Giles @ 2000-04-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` Marin D. Condic 2000-04-12 0:00 ` James Giles @ 2000-04-12 0:00 ` James Giles 1 sibling, 0 replies; 48+ messages in thread From: James Giles @ 2000-04-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` Geoff Bull 2000-04-12 0:00 ` Marin D. Condic @ 2000-04-12 0:00 ` James Giles 2000-04-13 0:00 ` Geoff Bull 1 sibling, 1 reply; 48+ messages in thread From: James Giles @ 2000-04-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-12 0:00 ` James Giles @ 2000-04-13 0:00 ` Geoff Bull 2000-04-13 0:00 ` Debugging (was: F9X twister & ADA) James Giles 2000-04-13 0:00 ` F9X twister & ADA (was: n-dim'l vectors) James Giles 0 siblings, 2 replies; 48+ messages in thread From: Geoff Bull @ 2000-04-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Debugging (was: F9X twister & ADA) 2000-04-13 0:00 ` Geoff Bull @ 2000-04-13 0:00 ` James Giles 2000-04-13 0:00 ` F9X twister & ADA (was: n-dim'l vectors) James Giles 1 sibling, 0 replies; 48+ messages in thread From: James Giles @ 2000-04-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-13 0:00 ` Geoff Bull 2000-04-13 0:00 ` Debugging (was: F9X twister & ADA) James Giles @ 2000-04-13 0:00 ` James Giles 2000-04-14 0:00 ` Geoff Bull 1 sibling, 1 reply; 48+ messages in thread From: James Giles @ 2000-04-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-13 0:00 ` F9X twister & ADA (was: n-dim'l vectors) James Giles @ 2000-04-14 0:00 ` Geoff Bull 0 siblings, 0 replies; 48+ messages in thread From: Geoff Bull @ 2000-04-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Geoff Bull @ 2000-04-11 0:00 ` Dale Stanbrough 2000-04-11 0:00 ` James Giles 2000-04-14 0:00 ` bv 2 siblings, 1 reply; 48+ messages in thread From: Dale Stanbrough @ 2000-04-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` Dale Stanbrough @ 2000-04-11 0:00 ` James Giles 2000-04-12 0:00 ` Robert A Duff 0 siblings, 1 reply; 48+ messages in thread From: James Giles @ 2000-04-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` James Giles @ 2000-04-12 0:00 ` Robert A Duff 0 siblings, 0 replies; 48+ messages in thread From: Robert A Duff @ 2000-04-12 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Geoff Bull 2000-04-11 0:00 ` Dale Stanbrough @ 2000-04-14 0:00 ` bv 2 siblings, 0 replies; 48+ messages in thread From: bv @ 2000-04-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-06 0:00 ` F9X twister & ADA (was: n-dim'l vectors) bv 2000-04-06 0:00 ` Richard Maine @ 2000-04-07 0:00 ` Erik Edelmann 2000-04-07 0:00 ` Robert Dewar 2000-04-07 0:00 ` Paul van Delst 2 siblings, 1 reply; 48+ messages in thread From: Erik Edelmann @ 2000-04-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-07 0:00 ` Erik Edelmann @ 2000-04-07 0:00 ` Robert Dewar 2000-04-07 0:00 ` Erik Edelmann 0 siblings, 1 reply; 48+ messages in thread From: Robert Dewar @ 2000-04-07 0:00 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-07 0:00 ` Robert Dewar @ 2000-04-07 0:00 ` Erik Edelmann 0 siblings, 0 replies; 48+ messages in thread From: Erik Edelmann @ 2000-04-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-06 0:00 ` F9X twister & ADA (was: n-dim'l vectors) bv 2000-04-06 0:00 ` Richard Maine 2000-04-07 0:00 ` Erik Edelmann @ 2000-04-07 0:00 ` Paul van Delst 2000-04-10 0:00 ` bv 2 siblings, 1 reply; 48+ messages in thread From: Paul van Delst @ 2000-04-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: F9X twister & ADA (was: n-dim'l vectors) 2000-04-07 0:00 ` Paul van Delst @ 2000-04-10 0:00 ` bv 0 siblings, 0 replies; 48+ messages in thread From: bv @ 2000-04-10 0:00 UTC (permalink / raw) To: Paul van Delst 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 ----------------------------------------------- ^ permalink raw reply [flat|nested] 48+ messages in thread
end of thread, other threads:[~2000-04-17 0:00 UTC | newest] Thread overview: 48+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <8cctts$ujr$1@nnrp1.deja.com> [not found] ` <38EA0440.1ECBC158@ncep.noaa.gov> 2000-04-06 0:00 ` F9X twister & ADA (was: n-dim'l vectors) bv 2000-04-06 0:00 ` Richard Maine 2000-04-07 0:00 ` Brian Rogoff 2000-04-08 0:00 ` Dick Hendrickson 2000-04-08 0:00 ` Richard Maine 2000-04-09 0:00 ` Gary Scott 2000-04-09 0:00 ` Richard Maine 2000-04-09 0:00 ` Geoff Bull 2000-04-09 0:00 ` Dick Hendrickson 2000-04-09 0:00 ` Robert Dewar 2000-04-09 0:00 ` Gordon Sande 2000-04-09 0:00 ` James Giles 2000-04-10 0:00 ` tmoran 2000-04-15 0:00 ` Aidan Skinner 2000-04-17 0:00 ` Robert I. Eachus 2000-04-16 0:00 ` Ken Garlington 2000-04-12 0:00 ` Robert I. Eachus 2000-04-10 0:00 ` bv 2000-04-10 0:00 ` James Van Buskirk 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Geoff Bull 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Larry Kilgallen 2000-04-11 0:00 ` James Giles 2000-04-11 0:00 ` Larry Kilgallen 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Geoff Bull 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` Geoff Bull 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` Geoff Bull 2000-04-12 0:00 ` Marin D. Condic 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` James Giles 2000-04-12 0:00 ` James Giles 2000-04-13 0:00 ` Geoff Bull 2000-04-13 0:00 ` Debugging (was: F9X twister & ADA) James Giles 2000-04-13 0:00 ` F9X twister & ADA (was: n-dim'l vectors) James Giles 2000-04-14 0:00 ` Geoff Bull 2000-04-11 0:00 ` Dale Stanbrough 2000-04-11 0:00 ` James Giles 2000-04-12 0:00 ` Robert A Duff 2000-04-14 0:00 ` bv 2000-04-07 0:00 ` Erik Edelmann 2000-04-07 0:00 ` Robert Dewar 2000-04-07 0:00 ` Erik Edelmann 2000-04-07 0:00 ` Paul van Delst 2000-04-10 0:00 ` bv
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox