* Where is the elusive jump command? @ 2000-03-21 0:00 dis90072 2000-03-21 0:00 ` Nicolas Brunot ` (3 more replies) 0 siblings, 4 replies; 96+ messages in thread From: dis90072 @ 2000-03-21 0:00 UTC (permalink / raw) Having learned ada for the past six months, I have found no reference to the 'jump' command. In MSDOS you can use the 'goto' command. Even in damn assembler you can jump. What is the equivalent in ada? I have had enough of endless 'IF' statements and everlasting case statements. I know it might make the program hard to follow, but I don't care! I must have it! Please......! Regards, Matt. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-21 0:00 Where is the elusive jump command? dis90072 @ 2000-03-21 0:00 ` Nicolas Brunot 2000-03-21 0:00 ` Stanley R. Allen ` (2 subsequent siblings) 3 siblings, 0 replies; 96+ messages in thread From: Nicolas Brunot @ 2000-03-21 0:00 UTC (permalink / raw) this is simply the goto statement, see language reference manual ADA95 sections 5.1(4) and 5.8(2) dis90072 a �crit: > Having learned ada for the past six months, I have found no reference to > the 'jump' command. In MSDOS you can use the 'goto' command. Even in > damn assembler you can jump. What is the equivalent in ada? I have had > enough of endless 'IF' statements and everlasting case statements. I > know it might make the program hard to follow, but I don't care! I must > have it! > Please......! > Regards, > Matt. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-21 0:00 Where is the elusive jump command? dis90072 2000-03-21 0:00 ` Nicolas Brunot @ 2000-03-21 0:00 ` Stanley R. Allen 2000-03-21 0:00 ` Nicolas Brunot 2000-03-27 0:00 ` Robert A Duff 3 siblings, 0 replies; 96+ messages in thread From: Stanley R. Allen @ 2000-03-21 0:00 UTC (permalink / raw) dis90072 wrote: > > Having learned ada for the past six months, I have found no reference to > the 'jump' command. In MSDOS you can use the 'goto' command. Even in > damn assembler you can jump. What is the equivalent in ada? I have had > enough of endless 'IF' statements and everlasting case statements. I > know it might make the program hard to follow, but I don't care! I must > have it! Please consider a career in retail shoe sales. -- Stanley Allen mailto:Stanley_R_Allen@raytheon.com ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-21 0:00 Where is the elusive jump command? dis90072 2000-03-21 0:00 ` Nicolas Brunot 2000-03-21 0:00 ` Stanley R. Allen @ 2000-03-21 0:00 ` Nicolas Brunot 2000-03-27 0:00 ` Robert A Duff 3 siblings, 0 replies; 96+ messages in thread From: Nicolas Brunot @ 2000-03-21 0:00 UTC (permalink / raw) this is simply the goto statement, see language reference manual ADA95 sections 5.1(4) and 5.8(2) dis90072 a �crit: > Having learned ada for the past six months, I have found no reference to > the 'jump' command. In MSDOS you can use the 'goto' command. Even in > damn assembler you can jump. What is the equivalent in ada? I have had > enough of endless 'IF' statements and everlasting case statements. I > know it might make the program hard to follow, but I don't care! I must > have it! > Please......! > Regards, > Matt. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-21 0:00 Where is the elusive jump command? dis90072 ` (2 preceding siblings ...) 2000-03-21 0:00 ` Nicolas Brunot @ 2000-03-27 0:00 ` Robert A Duff 2000-03-28 0:00 ` Dale Stanbrough 2000-03-28 0:00 ` Ken Garlington 3 siblings, 2 replies; 96+ messages in thread From: Robert A Duff @ 2000-03-27 0:00 UTC (permalink / raw) dis90072 <dis90072@port.ac.uk> writes: > Having learned ada for the past six months, I have found no reference to > the 'jump' command. In MSDOS you can use the 'goto' command. Even in > damn assembler you can jump. What is the equivalent in ada? I have had > enough of endless 'IF' statements and everlasting case statements. I > know it might make the program hard to follow, but I don't care! I must > have it! > Please......! > Regards, > Matt. The above caused a huge firestorm of "goto always makes the program less readable" versus "goto usually makes the program less readable, but sometimes has the opposite effect". But Matt clearly stated that he doesn't *care* whether the program is readable or not, but I didn't see much mention of that, which seems like the more important issue. How does one learn that readable=Good, other than from the School of Hard Knocks? - Bob ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-27 0:00 ` Robert A Duff @ 2000-03-28 0:00 ` Dale Stanbrough 2000-03-28 0:00 ` Ken Garlington 1 sibling, 0 replies; 96+ messages in thread From: Dale Stanbrough @ 2000-03-28 0:00 UTC (permalink / raw) Robert A Duff wrote: " But Matt clearly stated that he doesn't *care* whether the program is readable or not, but I didn't see much mention of that, which seems like the more important issue. How does one learn that readable=Good, other than from the School of Hard Knocks?" You can only learn it by teaching it (for most students, some can independently arrive at this conclusion). You can either let the individual learn it themselves in the workplace ("the School of Hard Knocks") or you can teach it at uni. The latter is preferable, and is what I do. I try to structure assignments so that students have to revise their own work. For example I currently have a project to program a Gantt chart - i've issued the requirements, and they a number of months to get it written up. -Then- they'll have to deal with the change of requirements which will be issued in August. I've done this in the past and found it quite succesfull (at least from conversations that I've had with students). Dale ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-27 0:00 ` Robert A Duff 2000-03-28 0:00 ` Dale Stanbrough @ 2000-03-28 0:00 ` Ken Garlington 2000-03-28 0:00 ` Robert Dewar 1 sibling, 1 reply; 96+ messages in thread From: Ken Garlington @ 2000-03-28 0:00 UTC (permalink / raw) There are acceptable reasons for not caring about readability; e.g. intentionally complex (or arbitrary) code sequences designed to try to break a compiler, or test its optimizations. Certain throw-away code (e.g. solely to learn a new language) would be another example. My guess was the latter... "Robert A Duff" <bobduff@world.std.com> wrote in message news:wcczorkm4tl.fsf@world.std.com... > dis90072 <dis90072@port.ac.uk> writes: > > > Having learned ada for the past six months, I have found no reference to > > the 'jump' command. In MSDOS you can use the 'goto' command. Even in > > damn assembler you can jump. What is the equivalent in ada? I have had > > enough of endless 'IF' statements and everlasting case statements. I > > know it might make the program hard to follow, but I don't care! I must > > have it! > > Please......! > > Regards, > > Matt. > > The above caused a huge firestorm of "goto always makes the program less > readable" versus "goto usually makes the program less readable, but > sometimes has the opposite effect". But Matt clearly stated that he > doesn't *care* whether the program is readable or not, but I didn't see > much mention of that, which seems like the more important issue. How > does one learn that readable=Good, other than from the School of Hard > Knocks? > > - Bob ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-28 0:00 ` Ken Garlington @ 2000-03-28 0:00 ` Robert Dewar 2000-03-28 0:00 ` Ken Garlington 0 siblings, 1 reply; 96+ messages in thread From: Robert Dewar @ 2000-03-28 0:00 UTC (permalink / raw) In article <wyVD4.17218$624.1463963@news.flash.net>, "Ken Garlington" <Ken.Garlington@computer.org> wrote: > There are acceptable reasons for not caring about readability; e.g. > intentionally complex (or arbitrary) code sequences designed to try to break > a compiler, or test its optimizations. Certain throw-away code (e.g. solely > to learn a new language) would be another example. My guess was the > latter... The compiler breaking code is of course a legitimate example. I am not nearly as sure about your second example. Part of learning a new language is precisely learning to write readable code in the style of that language. Indeed, for a good programmer it should be almost impossible to operate in any other mode than wanting to write well commented clear code :-) Learning just enough of language x to get problem y working is NOT necessarily very much related to learning language x (for any x or y). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-28 0:00 ` Robert Dewar @ 2000-03-28 0:00 ` Ken Garlington 2000-03-28 0:00 ` Marin D. Condic 0 siblings, 1 reply; 96+ messages in thread From: Ken Garlington @ 2000-03-28 0:00 UTC (permalink / raw) "Robert Dewar" <robert_dewar@my-deja.com> wrote in message news:8bq7ku$mc8$1@nnrp1.deja.com... > Learning just enough of language x to get problem y working is > NOT necessarily very much related to learning language x (for > any x or y). That's fair, but if you're just exploring how the syntax works, that's orthogonal to program design issues. When learning Java, I had to write tiny, uncommented, unreadable programs to test my understanding of how certain language features worked. I didn't worry about readability since I knew I was going to throw the thing away right after it started working. That doesn't mean I didn't also look at how Java classes, interfaces, etc. can be used to address program design issues. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-28 0:00 ` Ken Garlington @ 2000-03-28 0:00 ` Marin D. Condic 2000-03-28 0:00 ` Robert Dewar 0 siblings, 1 reply; 96+ messages in thread From: Marin D. Condic @ 2000-03-28 0:00 UTC (permalink / raw) Ken Garlington wrote: > That's fair, but if you're just exploring how the syntax works, that's > orthogonal to program design issues. When learning Java, I had to > write tiny, uncommented, unreadable programs to test my understanding > of how certain language features worked. I didn't worry about readability > since I knew I was going to throw the thing away right after it started > working. That doesn't mean I didn't also look at how Java classes, > interfaces, etc. can be used to address program design issues. Consider also that if we say to a newbie "Before you can use Ada, you have to change your entire way of thinking about programming" we will end up chasing them away. I think the message should be: "Go ahead. Ada will allow you to do what you've always done, but it will be much easier for you if you don't fight the language and learn to work with it the way it was intended." So let's be willing to show them how to write a goto, grab pointers to everything in sight, terminate strings with nulls, etc., all the while trying to convince them that there is a better, easier way. MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** Visit my web site at: http://www.mcondic.com/ "Because that's where they keep the money." -- Willie Sutton when asked why he robbed banks. ============================================================= ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-28 0:00 ` Marin D. Condic @ 2000-03-28 0:00 ` Robert Dewar 2000-03-29 0:00 ` Richard D Riehle 2000-03-29 0:00 ` Marin D. Condic 0 siblings, 2 replies; 96+ messages in thread From: Robert Dewar @ 2000-03-28 0:00 UTC (permalink / raw) In article <38E0E723.C39C392@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote: > So let's be willing to show them how to write a > goto, grab pointers to everything in sight, terminate strings with > nulls, etc., all the while trying to convince them that there is a > better, easier way. I disagree, noone teaches goto's in any beginning programming courses, for good reasons. Anyone desparately wanting to write gotos has a peculiar starting point. As for terminating strings with null, that really does not work in Ada for many reasons, the models of strings are very very different in C and Ada, and trying to gloss over this will be a disservice. As for pointers, I would NEVER tell people about *aliased* until they understood the language well. You just confuse people by introducing features that are unnecessary and will lead them in the wrong direction. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-28 0:00 ` Robert Dewar @ 2000-03-29 0:00 ` Richard D Riehle 2000-03-29 0:00 ` Robert Dewar 2000-03-29 0:00 ` Marin D. Condic 1 sibling, 1 reply; 96+ messages in thread From: Richard D Riehle @ 2000-03-29 0:00 UTC (permalink / raw) In article <8brfm4$4uc$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: >As for pointers, I would NEVER tell people about *aliased* until >they understood the language well. A little problem with this. We do need to get students to a point where they do understand how to use access types, including general access types. However, I do believe introducing things such as _aliased_ needs to be done in some understandable context. I usually say that certain reserved words, such as the _is_ before a set of declarations, the _aliased_ and certain other seemingly extra words are in keeping with Ada's underlying goal: a language for which a compiler can be developed that will maximize the amount of error checking as early in the software development process as possible. To write such a compiler, it is necessary to include certain reserved words and syntactic constructs that "tip off" the compiler to possible problems. The word _aliased_ seems to me to be one of those "tip-off the compiler" words. This can later be augmented with a more technical explanation, but it works well for most early students when explained within the framework of the above stated goals. Richard Riehle ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Richard D Riehle @ 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Alfred Hilscher 2000-03-30 0:00 ` Where is the elusive jump command? Richard D Riehle 0 siblings, 2 replies; 96+ messages in thread From: Robert Dewar @ 2000-03-29 0:00 UTC (permalink / raw) In article <8brn4k$p6i$1@slb0.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > > To write such a compiler, it is necessary to include certain > reserved words and syntactic constructs that "tip off" the > compiler to possible problems. The word _aliased_ seems to me > to be one of those "tip-off the compiler" words. This can > later be augmented with a more technical explanation, but it > works well for most early students when explained within the > framework of the above stated goals. I find this a very odd view of the ALIASED keyword. The reason for this has nothing to do with the compiler. As in the case of most C compilers, the compiler could look at your code to see whether or not you take the address of something. That's not at all the intention. The point is that aliasing is generally speaking very bad practice. The facility for pointing to variables was introduced in Ada 95 with reluctance when certain convincing examples were given, including in particular the construction of static structures involving pointers. It should be VERY sparingly used, really it should be regarded like Unchecked_Conversion, a noisy declaration that you intend to do something rather undesirable, namely in this case the creation of possibly confusing aliases for the variable. Note by the way that 'Address can be applied freely to variables in any case without the ALIASED keyword, so Ada 95 compilers in any case have to have the circuitry for automatic detection of which variables have their addresses taken and which do not (GNAT most certainly has this circuit). Thus ALIASED is not of the slightest utility to the compiler (in GNAT it is essentially ignored except for providing the essential semantic checking associated with this facility). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Robert Dewar @ 2000-03-30 0:00 ` Alfred Hilscher 2000-04-01 0:00 ` Robert Dewar 2000-03-30 0:00 ` Where is the elusive jump command? Richard D Riehle 1 sibling, 1 reply; 96+ messages in thread From: Alfred Hilscher @ 2000-03-30 0:00 UTC (permalink / raw) unfortunately, ALIASED is neccessary in most bindings to C-written APIs. Robert Dewar wrote: > The point is that aliasing is generally speaking very bad > practice. The facility for pointing to variables was introduced > in Ada 95 with reluctance when certain convincing examples > were given, including in particular the construction of > static structures involving pointers. > > It should be VERY sparingly used, really it should be regarded > like Unchecked_Conversion, a noisy declaration that you intend > to do something rather undesirable, namely in this case the > creation of possibly confusing aliases for the variable. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Alfred Hilscher @ 2000-04-01 0:00 ` Robert Dewar 2000-04-04 0:00 ` Alfred Hilscher 2000-04-05 0:00 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-01 0:00 UTC (permalink / raw) In article <38E312F8.78883ACB@icn.siemens.de>, Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > unfortunately, ALIASED is neccessary in most bindings to > C-written APIs. Much less than may programmers think. For example it is usually much more appropriate if the C parameter is *int to define it as in out INT on the Ada side, so that the call looks like p (x); -- x need not be aliased p (x'access); -- x must be aliased I perfectly well agree that this does not cover all cases, but in my experience of looking at a LOT of code, I often see the wrong approach here. But in any case, binding to C is hardly a topic that is appropriate to people first learning the language! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-01 0:00 ` Robert Dewar @ 2000-04-04 0:00 ` Alfred Hilscher 2000-04-05 0:00 ` Ole-Hjalmar Kristensen 1 sibling, 0 replies; 96+ messages in thread From: Alfred Hilscher @ 2000-04-04 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <38E312F8.78883ACB@icn.siemens.de>, > Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > > > unfortunately, ALIASED is neccessary in most bindings to > > C-written APIs. > > Much less than may programmers think. For example it is usually > much more appropriate if the C parameter is *int to define > it as in out INT on the Ada side, so that the call looks like > > p (x); -- x need not be aliased > p (x'access); -- x must be aliased > > I perfectly well agree that this does not cover all cases, but > in my experience of looking at a LOT of code, I often see the > wrong approach here. I totally agree that this would be the better way, but at least the Win32 bindings that I have are written in the "C-Style". > But in any case, binding to C is hardly a topic that is > appropriate to people first learning the language! Ok, that's true. But using C bindings (for GUI or database purposes) can also be a topic for non-(Ada)-experts. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-01 0:00 ` Robert Dewar 2000-04-04 0:00 ` Alfred Hilscher @ 2000-04-05 0:00 ` Ole-Hjalmar Kristensen 2000-04-05 0:00 ` Larry Kilgallen 1 sibling, 1 reply; 96+ messages in thread From: Ole-Hjalmar Kristensen @ 2000-04-05 0:00 UTC (permalink / raw) Robert Dewar <dewar@gnat.com> writes: > In article <38E312F8.78883ACB@icn.siemens.de>, > Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> wrote: > > > unfortunately, ALIASED is neccessary in most bindings to > > C-written APIs. > > Much less than may programmers think. For example it is usually > much more appropriate if the C parameter is *int to define > it as in out INT on the Ada side, so that the call looks like > > p (x); -- x need not be aliased > p (x'access); -- x must be aliased > > I perfectly well agree that this does not cover all cases, but > in my experience of looking at a LOT of code, I often see the > wrong approach here. > > But in any case, binding to C is hardly a topic that is > appropriate to people first learning the language! > Certainly, but writing bindings to C is one of the first things you have to do if you start using Ada for systems programming on Unix, unfortunately. > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- E pluribus Unix ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-05 0:00 ` Ole-Hjalmar Kristensen @ 2000-04-05 0:00 ` Larry Kilgallen 2000-04-06 0:00 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 96+ messages in thread From: Larry Kilgallen @ 2000-04-05 0:00 UTC (permalink / raw) In article <umqvh1wnaad.fsf@gong2.clustra.com>, Ole-Hjalmar Kristensen <ohk@clustra.com> writes: > Robert Dewar <dewar@gnat.com> writes: >> But in any case, binding to C is hardly a topic that is >> appropriate to people first learning the language! >> > > Certainly, but writing bindings to C is one of the first things you > have to do if you start using Ada for systems programming on Unix, > unfortunately. I am not sure what you mean by "systems programming" in this case. I would presume that writing device drivers requires knowledge of internal data structures, but don't vendors like Rational supply bindings to Unix entrypoints that might be called by user-mode programs ? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-05 0:00 ` Larry Kilgallen @ 2000-04-06 0:00 ` Ole-Hjalmar Kristensen 2000-04-06 0:00 ` OS Bindings (was: Where is the elusive jump command?) Larry Kilgallen 0 siblings, 1 reply; 96+ messages in thread From: Ole-Hjalmar Kristensen @ 2000-04-06 0:00 UTC (permalink / raw) kilgallen@eisner.decus.org (Larry Kilgallen) writes: > In article <umqvh1wnaad.fsf@gong2.clustra.com>, Ole-Hjalmar Kristensen <ohk@clustra.com> writes: > > Robert Dewar <dewar@gnat.com> writes: > > >> But in any case, binding to C is hardly a topic that is > >> appropriate to people first learning the language! > >> > > > > Certainly, but writing bindings to C is one of the first things you > > have to do if you start using Ada for systems programming on Unix, > > unfortunately. > > I am not sure what you mean by "systems programming" in this case. > I would presume that writing device drivers requires knowledge of > internal data structures, but don't vendors like Rational supply > bindings to Unix entrypoints that might be called by user-mode > programs ? I was not thinking device drivers, but systems like communications systems or DBMS's, which typically will need access to Unix entrypoints or system calls. A thick binding designed by someone who is unaware of the specific needs of the system may not be suitable. An example of the the need for system calls: A couple of months ago I wanted to test various implementations of asynchronous IO (Sun asynchronous IO, POSIX asynchronous IO, and Ada). However, to do a meaningful test, I need to ensure that I/O operations on the file descriptor complete as defined by synchronized I/O data integrity rules. This means either using the fcntl or fsync system calls, or setting the O_SYNC flag in the call to open. In this case, needing only a few system calls, it may be more cost effective to write your own binding, as it's usually not difficult. Yes, it may be possible to buy such a binding, although I have not seen any reference to it, either on Rational's web pages, nor on Adahome's list of bindings. There is a reference to a POSIX binding, but that seems very much to be a work in progress. Ole-Hj. Kristensen -- E pluribus Unix ^ permalink raw reply [flat|nested] 96+ messages in thread
* OS Bindings (was: Where is the elusive jump command?) 2000-04-06 0:00 ` Ole-Hjalmar Kristensen @ 2000-04-06 0:00 ` Larry Kilgallen 2000-04-06 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 96+ messages in thread From: Larry Kilgallen @ 2000-04-06 0:00 UTC (permalink / raw) In article <umq8zyrmzgp.fsf@gong2.clustra.com>, Ole-Hjalmar Kristensen <ohk@clustra.com> writes: > kilgallen@eisner.decus.org (Larry Kilgallen) writes: > >> In article <umqvh1wnaad.fsf@gong2.clustra.com>, Ole-Hjalmar Kristensen <ohk@clustra.com> writes: >> > Robert Dewar <dewar@gnat.com> writes: >> >> >> But in any case, binding to C is hardly a topic that is >> >> appropriate to people first learning the language! >> >> >> > >> > Certainly, but writing bindings to C is one of the first things you >> > have to do if you start using Ada for systems programming on Unix, >> > unfortunately. >> >> I am not sure what you mean by "systems programming" in this case. >> I would presume that writing device drivers requires knowledge of >> internal data structures, but don't vendors like Rational supply >> bindings to Unix entrypoints that might be called by user-mode >> programs ? > > I was not thinking device drivers, but systems like communications > systems or DBMS's, which typically will need access to Unix > entrypoints or system calls. A thick binding designed by someone who > is unaware of the specific needs of the system may not be suitable. > > An example of the the need for system calls: A couple of months ago I > wanted to test various implementations of asynchronous IO (Sun > asynchronous IO, POSIX asynchronous IO, and Ada). However, to do a > meaningful test, I need to ensure that I/O operations on the file > descriptor complete as defined by synchronized I/O data integrity > rules. This means either using the fcntl or fsync system calls, or > setting the O_SYNC flag in the call to open. > > In this case, needing only a few system calls, it may be more cost > effective to write your own binding, as it's usually not difficult. > > Yes, it may be possible to buy such a binding, although I have not > seen any reference to it, either on Rational's web pages, nor on > Adahome's list of bindings. On VMS, using either DEC Ada (83) or GNAT, one gets these bindings in the package STARLET. If a competitor were to develop a compiler for VMS without the assistance of Compaq they could achieve the same effect with the public domain SDL program to extract the binding data from the operating system. On Windows NT, Aonix ships two competing sets of bindings to the operating system calls and matching data structures. Are you saying that no Ada vendors for Unix provide bindings ? That seems incredible in the face of all the hype about how Unix is ideal for programming. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-06 0:00 ` OS Bindings (was: Where is the elusive jump command?) Larry Kilgallen @ 2000-04-06 0:00 ` Robert Dewar 2000-04-07 0:00 ` Tarjei T. Jensen [not found] ` <eisner comp.lang.ada:53670> 2000-04-06 0:00 ` Ole-Hjalmar Kristensen 2 siblings, 1 reply; 96+ messages in thread From: Robert Dewar @ 2000-04-06 0:00 UTC (permalink / raw) In article <2000Apr6.081305.1@eisner>, Kilgallen@eisner.decus.org.nospam wrote: > Are you saying that no Ada vendors for Unix provide bindings ? > That seems incredible in the face of all the hype about how > Unix is ideal for programming. A little bit of an odd statement, but understandable from a VMS enthusiast :-) Unix is a collection of operating systems, so providing a binding to Unix is not a very well defined concept. Certainly all Ada compilers come with various ways of interfacing to operating systems functions. Many functions can be done using the portable POSIX interface. This is desirable where possible, since it avoids the nasty trap that particularly VMS programmers get stuck in of doing everything with Starlet and building completely non-portable programs. Many of these Starlet functions could perfectly well be performed using a good posix interface. Other bindings to well established interface sets are also generally available, and these are largely portable. In addition every compiler comes with various operating system interfaces that are not necessarily portable to other Ada compilers. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-06 0:00 ` Robert Dewar @ 2000-04-07 0:00 ` Tarjei T. Jensen 2000-04-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-07 0:00 UTC (permalink / raw) Robert Dewar wrote >Many functions can be done using the portable POSIX interface. >This is desirable where possible, since it avoids the nasty >trap that particularly VMS programmers get stuck in of doing >everything with Starlet and building completely non-portable >programs. Many of these Starlet functions could perfectly >well be performed using a good posix interface. > >Other bindings to well established interface sets are also >generally available, and these are largely portable. In addition >every compiler comes with various operating system interfaces >that are not necessarily portable to other Ada compilers. They may be portable, but the bindings I have seen tend to do certain things the wrong way around. Every time there is an unsigned type like size_t it is translated to a modular type. This is just plain wrong. One have to differentiate between an unsigned type which contains a set of flags and legitimate unsigned types which may be used in arithmetic expressions. A good example of this is the definitions in the interfaces.C. The unsigned types are really useless and undermines the type safety we should expect from Ada. These definitions fails completely to capture the spirit of the usage in C. The modular types should have been named something like unsigned_<type>_flags or something to that effect. Then the purpose and meaning would be clear and we would avoid the bungle which is the present standard. It anoys me no end that I did not catch this during the review process. I really should have noticed. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-07 0:00 ` Tarjei T. Jensen @ 2000-04-09 0:00 ` Robert Dewar 2000-04-10 0:00 ` Tarjei T. Jensen 0 siblings, 1 reply; 96+ messages in thread From: Robert Dewar @ 2000-04-09 0:00 UTC (permalink / raw) In article <8ck638$krs3@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > A good example of this is the definitions in the interfaces.C. > The unsigned types are really useless and undermines the type > safety we should expect from Ada. These definitions fails > completely to capture the spirit of the usage in C. I am completely mystefied by the above, it includes a number of very curious assertions, with absolutely no indication of the strange theory that must underlie these assertions. From where I see things, there is no undermining of type safety in these declarations, and they capture the semantics of C unsigned types perfectly. > The modular types should have been named something like > unsigned_<type>_flags or something to that effect. Then the > purpose and meaning would be clear and w would avoid the > bungle which is the present standard. Saying something is a bungle without giving us the slightest idea of why you think that is not constructive. Modular types are called modular types simply because they have modular arithmetic semantics, like the unsigned types in C, but more general, and the name captures this perfectly. Yes, one possible use is to use them for flags, but this is actually by NO means the main or even a very common use of modular types. > It anoys me no end that I did not catch this during the review > process. I really should have noticed. I have no idea what you think you failed to notice and did not catch, please explain. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-09 0:00 ` Robert Dewar @ 2000-04-10 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert Dewar 0 siblings, 1 reply; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-10 0:00 UTC (permalink / raw) Robert Dewar wrote in message <8cp23c$4gp$1@nnrp1.deja.com>... >In article <8ck638$krs3@ftp.kvaerner.com>, > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: >> A good example of this is the definitions in the interfaces.C. >> The unsigned types are really useless and undermines the type >> safety we should expect from Ada. These definitions fails >> completely to capture the spirit of the usage in C. > >I am completely mystefied by the above, it includes a number >of very curious assertions, with absolutely no indication of >the strange theory that must underlie these assertions. From >where I see things, there is no undermining of type safety in >these declarations, and they capture the semantics of C >unsigned types perfectly. Unsigned in C might have similar semantics to modular types in that there is no range checking. In C, unsigned types are used for types like size_t NOT because there is no range checking, but because of the range. max(unsigned) > max(int). An unsigned type allows for bigger files or whatever than a similar sized signed value. In most cases where an unsigned type like size_t is used it is apropriate to translate it to an unsigned integer of some sort and not a modular type. Arithmetic operations which causes wraparound are most likely errors and should be caught. Now I have to remember to check interface.C when I get home, to check verify that the definition of int, short and long in gnat has C semantics. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-10 0:00 ` Tarjei T. Jensen @ 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Tarjei T. Jensen 0 siblings, 2 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-12 0:00 UTC (permalink / raw) In article <8csjs8$o2p3@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > In most cases where an unsigned type like size_t is used it is > apropriate to translate it to an unsigned integer of some sort > and not a modular type. Maybe so, C unlike Ada does not have this possibility, so it is indeed possible that the above is right. For example if we see in C unsigned char q; it maybe that the best Ada translation is type q is range 0 .. 255; for q'size use 8; but I still don't see the complaint, wrapping types like unsigned in C are useful in Ada and in C, and we have always have unsigned types in the sense of the above declaration of q in Ada. But I see the point you are making now. I still don't really see why you don't like the modular types, they seem useful and clear to me. After all Java decided it was all they needed :-) > Arithmetic operations which causes wraparound are most likely > errors and should be caught. OK, but this really has nothing to do with type checking, which is why I was confused by your original post. But if you want this kind of range checking, then of course do NOT use a modular type to model the C type. > Now I have to remember to check interface.C when I get home, > to check verify that the definition of int, short and long in > gnat has C semantics. Not sure what you mean here. In C, overflow for such types makes the program execution undefined, in Ada, the semantics is the same as C except in this undefined case, where Ada defines that CE must be raised. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert Dewar @ 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Tarjei T. Jensen 1 sibling, 1 reply; 96+ messages in thread From: Robert A Duff @ 2000-04-12 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > OK, but this really has nothing to do with type checking, which > is why I was confused by your original post. But if you want > this kind of range checking, then of course do NOT use a modular > type to model the C type. One problem is that I can't follow that advice in the case of the largest supported integer. That is, I can't say: type T is range 0..2**64-1; so I have to use a modular type. Unsigned types are often used in C when modular arithmetic is *not* desired -- the desire is for non-negative numbers, and unsigned gives a wider range of them (avoids wasting a bit). - Bob ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert A Duff @ 2000-04-12 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-12 0:00 UTC (permalink / raw) Robert A Duff wrote in message ... >Robert Dewar <robert_dewar@my-deja.com> writes: > >> OK, but this really has nothing to do with type checking, which >> is why I was confused by your original post. But if you want >> this kind of range checking, then of course do NOT use a modular >> type to model the C type. > >One problem is that I can't follow that advice in the case of the >largest supported integer. That is, I can't say: > > type T is range 0..2**64-1; > >so I have to use a modular type. Why would it be illegal to write type T is range 0 .. #16#ffff_ffff_ffff_ffff#; Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Tarjei T. Jensen @ 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff 2 siblings, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-12 0:00 UTC (permalink / raw) In article <8d20bq$o2p4@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > Why would it be illegal to write > > type T is range 0 .. #16#ffff_ffff_ffff_ffff#; Because no Ada compiler I know of would accept this declaration, and compilers are required to consider declarations they do not accept as illegal! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert Dewar @ 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff 2 siblings, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-12 0:00 UTC (permalink / raw) In article <8d20bq$o2p4@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > Why would it be illegal to write > > type T is range 0 .. #16#ffff_ffff_ffff_ffff#; Because no Ada compiler I know of would accept this declaration, and compilers are required to consider declarations they do not accept as illegal! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert Dewar @ 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Robert Dewar ` (2 more replies) 2 siblings, 3 replies; 96+ messages in thread From: Robert A Duff @ 2000-04-12 0:00 UTC (permalink / raw) "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > >One problem is that I can't follow that advice in the case of the > >largest supported integer. That is, I can't say: > > > > type T is range 0..2**64-1; > > > >so I have to use a modular type. > > Why would it be illegal to write > > type T is range 0 .. #16#ffff_ffff_ffff_ffff#; Because you have a syntax error -- an extra #. ;-) Also because System.Max_Int is 2**63-1 or 2**31-1 on most implementations, and there's a rule saying that the bounds have to be less than or equal to System.Max_Int. If I made the rules, there would be no Max_Int. - Bob ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert A Duff @ 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff 2000-04-13 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Florian Weimer 2000-04-13 0:00 ` Tarjei T. Jensen 2 siblings, 2 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-12 0:00 UTC (permalink / raw) In article <wccg0srbbc4.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > If I made the rules, there would be no Max_Int. That may be OK, multiple precision integers can be useful, so long as you do not go berserk and require that I be able to use them for case indexes, subscripts, entryu family indexes, loop variables, etc. It is this kind of silly requirement that caused many Ada compilers not to even support 64-bit integers when they could have done so easily. The Ada 83 attitude was "if you implement 64-bit integer arithmetic, you MUST allow all the above silly things, but it is absolutely FINE to not implement 64-bit integer arithmetic at all." I am not sure whether we fixed this properly in Ada 95. In the case of GNAT, we allow 64-bit integer arithmetic everywhere, and it would be very easy to allow larger arithmetic, provided it is clear we do not have to allow it in silly contexts. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert Dewar @ 2000-04-12 0:00 ` Robert A Duff 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Robert Dewar 2000-04-13 0:00 ` Tarjei T. Jensen 1 sibling, 2 replies; 96+ messages in thread From: Robert A Duff @ 2000-04-12 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <wccg0srbbc4.fsf@world.std.com>, > Robert A Duff <bobduff@world.std.com> wrote: > > If I made the rules, there would be no Max_Int. > > That may be OK, multiple precision integers can be useful, > so long as you do not go berserk and require that I be > able to use them for case indexes, subscripts, entryu > family indexes, loop variables, etc. > > It is this kind of silly requirement that caused many Ada > compilers not to even support 64-bit integers when they > could have done so easily. I agree about subscripts and entry families, but I don't see the problem with case statements. Loops? I dunno. I make the distinction because arrays are limited by address space; there's not much point in an array (2**99..2**99+1). But there could well be a point in calculating numbers like 2**99 or 2**999. And there's nothing wrong with a case statement on such a type. > The Ada 83 attitude was > > "if you implement 64-bit integer arithmetic, you MUST allow > all the above silly things, but it is absolutely FINE to not > implement 64-bit integer arithmetic at all." > > I am not sure whether we fixed this properly in Ada 95. Well, the RM allows some sort of non-standard integer types, which the implementation can arbitrarily restrict. Eg, you could have a 128-bit integer type that allows "+" and "-" but not "*" and "/". You can't pass these weird types, if they exist, as generic parameters. > In the case of GNAT, we allow 64-bit integer arithmetic > everywhere, and it would be very easy to allow larger > arithmetic, provided it is clear we do not have to allow > it in silly contexts. I think that is clear. I'm too lazy to look up the RM reference. I do remember that William Whitaker griped about this allowance rather strongly, which surprised me, because it seemed to me silly to say (to a compiler writer) you don't have to support X, but if you do support X, you have to *fully* support it. That's a bit different than saying, "if you support X, you have to support it in a standard way", which is something I have sometimes argued *for*. I admit that I can't formally define the difference between "incomplete support" and "different support" -- but I know it when I see it ;-). - Bob ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert A Duff @ 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Gisle S�lensminde 2000-04-15 0:00 ` Robert Dewar 1 sibling, 1 reply; 96+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <wccbt3fayqe.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > I agree about subscripts and entry families, but I don't see > the problem > with case statements. Because it is not significantly useful to have case statements operating with 256-bit integer values, and it is likely that standard optimizers etc do not deal with this special case, meaning that it has to be special cased by the compiler, creating special cases that require lots of extra testing work etc. > Loops? I dunno. Same thing. It is really surprising to many people that Ada compilers often do not support 64-bit arithmetic. In GNAT, we do guarantee 64-bit integer arithmetic on all targets (Long_Long_Integer is at least 64-bits), but it does take extra work, and I suspect that a significant part of the reason that it is not done on all targets is that it is too much work to deal with loops, case statements, subscripts etc, and if you are allowed to simply avoid these issues by refusing to support it at all then that's the easier choice. > I think that is clear. I'm too lazy to look up the RM reference. I do > remember that William Whitaker griped about this allowance rather > strongly, which surprised me, because it seemed to me silly to say (to a > compiler writer) you don't have to support X, but if you do support X, > you have to *fully* support it. Indeed, and that is my point, I think we are in basic agreement here. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-15 0:00 ` Robert Dewar @ 2000-04-15 0:00 ` Gisle S�lensminde 0 siblings, 0 replies; 96+ messages in thread From: Gisle S�lensminde @ 2000-04-15 0:00 UTC (permalink / raw) In article <8d9pu3$2u0$1@nnrp1.deja.com>, Robert Dewar wrote: > >It is really surprising to many people that Ada compilers often >do not support 64-bit arithmetic. In GNAT, we do guarantee >64-bit integer arithmetic on all targets (Long_Long_Integer >is at least 64-bits), but it does take extra work, and I >suspect that a significant part of the reason that it is not >done on all targets is that it is too much work to deal with >loops, case statements, subscripts etc, and if you are allowed >to simply avoid these issues by refusing to support it at all >then that's the easier choice. Which compilers (for PCs and workstations) supports 64-bit aritmetrics and which ones do not. -- Gisle S�lensminde ( gisle@ii.uib.no ) ln -s /dev/null ~/.netscape/cookies ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert A Duff 2000-04-15 0:00 ` Robert Dewar @ 2000-04-15 0:00 ` Robert Dewar 1 sibling, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <wccbt3fayqe.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > I agree about subscripts and entry families, but I don't see > the problem > with case statements. Because it is not significantly useful to have case statements operating with 256-bit integer values, and it is likely that standard optimizers etc do not deal with this special case, meaning that it has to be special cased by the compiler, creating special cases that require lots of extra testing work etc. > Loops? I dunno. Same thing. It is really surprising to many people that Ada compilers often do not support 64-bit arithmetic. In GNAT, we do guarantee 64-bit integer arithmetic on all targets (Long_Long_Integer is at least 64-bits), but it does take extra work, and I suspect that a significant part of the reason that it is not done on all targets is that it is too much work to deal with loops, case statements, subscripts etc, and if you are allowed to simply avoid these issues by refusing to support it at all then that's the easier choice. > I think that is clear. I'm too lazy to look up the RM reference. I do > remember that William Whitaker griped about this allowance rather > strongly, which surprised me, because it seemed to me silly to say (to a > compiler writer) you don't have to support X, but if you do support X, > you have to *fully* support it. Indeed, and that is my point, I think we are in basic agreement here. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff @ 2000-04-13 0:00 ` Tarjei T. Jensen 2000-04-13 0:00 ` Gisle S�lensminde 1 sibling, 1 reply; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-13 0:00 UTC (permalink / raw) Robert Dewar wrote >That may be OK, multiple precision integers can be useful, >so long as you do not go berserk and require that I be >able to use them for case indexes, subscripts, entryu >family indexes, loop variables, etc. Agree. I think Ada could do well in encryption applications if there were general support for this. E.g. arithmetic, and, or, xor, conversion to integer, simple math functions. Most other uses could be done by converting to integer. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-13 0:00 ` Tarjei T. Jensen @ 2000-04-13 0:00 ` Gisle S�lensminde 0 siblings, 0 replies; 96+ messages in thread From: Gisle S�lensminde @ 2000-04-13 0:00 UTC (permalink / raw) In article <8d3s9o$6621@ftp.kvaerner.com>, Tarjei T. Jensen wrote: > >Robert Dewar wrote >>That may be OK, multiple precision integers can be useful, >>so long as you do not go berserk and require that I be >>able to use them for case indexes, subscripts, entryu >>family indexes, loop variables, etc. > > >Agree. I think Ada could do well in encryption applications if there were >general support for this. E.g. arithmetic, and, or, xor, conversion to >integer, simple math functions. Most other uses could be done by converting to >integer. Ada is in fact quite good for implementing at least symetric crypto algorithms. For these algorithms the important is the availability of operation like bitwise and, or, xor, not, shift and rotate, which these algorithms use. Ada have all these operations, which is more than even C has. (C miss rotate, but it is often implemened through a idiom). The only problem is that you can't use userdefined types, but must use unsigned_X from interfaces if you want to use shift or rotate. For public key cryptography, Ada miss multiprecision numbers, but so do C/C++ which is the commonly used language in the area. -- Gisle S�lensminde ( gisle@ii.uib.no ) ln -s /dev/null ~/.netscape/cookies ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Robert Dewar @ 2000-04-12 0:00 ` Florian Weimer 2000-04-13 0:00 ` Tarjei T. Jensen 2 siblings, 0 replies; 96+ messages in thread From: Florian Weimer @ 2000-04-12 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > > type T is range 0 .. #16#ffff_ffff_ffff_ffff#; > Also because System.Max_Int is 2**63-1 or 2**31-1 on most > implementations, and there's a rule saying that the bounds have to be > less than or equal to System.Max_Int. In addition, the base type of T is (almost) symmetric around zero, which means that it occupies at least T'Size + 1 bits, which is problematic if T'Size is already the (double) word size. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Florian Weimer @ 2000-04-13 0:00 ` Tarjei T. Jensen 2000-04-13 0:00 ` Robert A Duff 2000-04-15 0:00 ` Robert Dewar 2 siblings, 2 replies; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-13 0:00 UTC (permalink / raw) Robert A Duff wrote >Also because System.Max_Int is 2**63-1 or 2**31-1 on most >implementations, and there's a rule saying that the bounds have to be >less than or equal to System.Max_Int. > >If I made the rules, there would be no Max_Int. Then I change the declaration to type T is range 0 .. #16#ffff_ffff_ffff_ffff; If the compiler complains because the number is out of range for an integer if it otherwise supports 64 bit numbers I think the compiler has been poorly constructed. As long as the lower bound is 0 or positive then it is quite clear that it is a unsigned type. It seems pointless to involve max_int in this unless we are talking about a signed number. I don't care about the T base type. I think that the above definition is perfectly reasonable even though it may be contrary to the letter of the standard. I think it is a glaring oversight in the standard if it not only allows, but requires compilers to honour a definition like the one above. I don't have the final version of the RM here, only the June 94 version. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-13 0:00 ` Tarjei T. Jensen @ 2000-04-13 0:00 ` Robert A Duff 2000-04-18 0:00 ` Tarjei T. Jensen 2000-04-15 0:00 ` Robert Dewar 1 sibling, 1 reply; 96+ messages in thread From: Robert A Duff @ 2000-04-13 0:00 UTC (permalink / raw) "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > Robert A Duff wrote > >Also because System.Max_Int is 2**63-1 or 2**31-1 on most > >implementations, and there's a rule saying that the bounds have to be > >less than or equal to System.Max_Int. > > > >If I made the rules, there would be no Max_Int. > > Then I change the declaration to > > type T is range 0 .. #16#ffff_ffff_ffff_ffff; How about: type T is range 0 .. 16#ffff_ffff_ffff_ffff#; ? ;-) Or, equivalently, ".. 2**64-1". > If the compiler complains because the number is out of range for an integer if > it otherwise supports 64 bit numbers I think the compiler has been poorly > constructed. Then *all* Ada compilers are poorly constructed. ;-) At least, all of the Ada compilers I have seen have Max_Binary_Modulus = 2**N, and Max_Int = 2**(N-1)-1, for some N (generally the word size, or twice the word size, of the hardware). That's what the language designers intended, too. So, if N = 32, then: type Signed is range 0..2**32-1; -- Illegal! type Modular is mod 2**32; -- Legal. Type Signed is illegal on that implementation. This means that you're *forced* to use modular when you want to count up to 2**N-1, even though you don't want wrap-around arithmetic. It also means that you're out of luck if you want to count up to 2**N or more. And, unfortunately, N is not portable. >... As long as the lower bound is 0 or positive then it is quite clear > that it is a unsigned type. It seems pointless to involve max_int in this > unless we are talking about a signed number. But Max_Int is the *definition* of the largest (fully) supported integer! It's fine to complain that Max_Int is too small, but I don't think it makes sense to say Max_Int should be wrong. > I don't care about the T base type. I think that the above definition is > perfectly reasonable even though it may be contrary to the letter of the > standard. You *have* to care about the base subtype, because that determines the range of intermediate expression results. > I think it is a glaring oversight in the standard if it not only allows, but > requires compilers to honour a definition like the one above. I tend to agree. As I said in another note, I think there should be no Max_Int. I think all Ada compilers should be required to support things like: type Huge is range -2**100..2**1000; although, as Robert Dewar pointed out, I might not want to insist that Huge be allowed as an array index type, for example. An Ada implementation that restricted arrays to one or two words would be a joke. I think that integers also should not be restricted to one or two words. >...I don't have the > final version of the RM here, only the June 94 version. This Max_Int stuff hasn't changed since Ada 83. Modular types are of course new in Ada 95, and they changed a lot during the Ada 9X project. There was a version where there was no new syntax for them; there was just a package Unsigned (in the SP annex, I think), which declared a bunch of magical integer types that behaved differently from other integer types. I kind of liked that design, because it makes it clear that the semantics of these types is a low-level machine-oriented hack. You can get the real Ada 95 RM from somewhere in: http://www.adaic.org/ and print out the postscript file. - Bob ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-13 0:00 ` Robert A Duff @ 2000-04-18 0:00 ` Tarjei T. Jensen 0 siblings, 0 replies; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-18 0:00 UTC (permalink / raw) Robert A Duff wrote >You *have* to care about the base subtype, because that determines the >range of intermediate expression results. I would expect that I would have to be pretty careful about how things are written when handling unsigned integers > signed max_int. I would not want to do the arithmetic as signed integers and only store an unsigned integer. For the time being most problems with these numbers will be limited to those who have Ada compilers which have 32 bit integers as their largest integers. Most disks bought these days are currently larger (in bytes) than the largest integer available on these systems. Some of our systems generates files which are larger than can be expressed with a signed 32bit integer. For the curious: these are Oracle export files. I am relieved that gnat allows 64 bit integers. That will keep my use of unsigned integers out of trouble for the time being (I'm currently mainly 32 bit). Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-13 0:00 ` Tarjei T. Jensen 2000-04-13 0:00 ` Robert A Duff @ 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Tarjei T. Jensen 1 sibling, 1 reply; 96+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <8d457u$5n33@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > I think it is a glaring oversight in the standard if it not > only allows, but > requires compilers to honour a definition like the one above. > I don't have the > final version of the RM here, only the June 94 version. Great, so here we go again. Obviously we can't mandate 64-bit integer support, since the burden would be too great on small processors. And if you disagree, just change 64 to a larger power of 2. Tarjei says "if you implement n-bit arithmetic, then you must implement full range unsigned n-bit arithmetic with overflow checking." AARGH! the Ada 83 mentality at work again. The mentality that says, you don't need to implement X, but if you implement X you must implement Y. I trust that Tarjei understands that it would be a lot of extra work to implement this new form of checked arithmetic. The consequence of Tarjei's suggested change might well be that compilers decide, "oh well, 64-bit integer arithmetic is too much of a pain anyway", and simply don't do it at all. Suppose this "glaring defect" were fixed in the RM. Then GNAT would have a lot of extra work to do, maybe we would do it, but maybe we would simply remove 64-bit arithmetic completely (actually put it under an extension switch) so it was not considered part of the core. Never encourage implementors to do less by making it harder than necessary for them to do more! We have unsigned 64-bit arithmetic similar to the capabilities of C (well at least GNU-C) and Java in Ada. Yes, that's not ideal, and for many applications a range checked 64-bit range would be better. But please don't let best be the enemy of good. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-15 0:00 ` Robert Dewar @ 2000-04-15 0:00 ` Tarjei T. Jensen 0 siblings, 0 replies; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-15 0:00 UTC (permalink / raw) Robert Dewar wrote >Tarjei says > >"if you implement n-bit arithmetic, then you must implement >full range unsigned n-bit arithmetic with overflow checking." > >AARGH! the Ada 83 mentality at work again. The mentality that >says, you don't need to implement X, but if you implement X >you must implement Y. Not really. In a general modern computing environment these days it is a perfectly reasonable requirement to be able to handle 64 bit unsigned arithmetic with runtime checking if the compiler supports 64 bits integers. If it only supports 32bit integers, then the requirement stands for 32bit unsigned integers. >I trust that Tarjei understands that it would be a lot of >extra work to implement this new form of checked arithmetic. >The consequence of Tarjei's suggested change might well be >that compilers decide, "oh well, 64-bit integer arithmetic >is too much of a pain anyway", and simply don't do it at all. The problem does not go away. All you have done is scaled it down to 32bit. The general problem persists. And you will have to explain why it would be a lot of extra work if I'm to believe you. And I expect that you should prepare yourself for a similar problem when gnat supports 128 bit integers. >Suppose this "glaring defect" were fixed in the RM. > >Then GNAT would have a lot of extra work to do, maybe we would >do it, but maybe we would simply remove 64-bit arithmetic >completely (actually put it under an extension switch) so it >was not considered part of the core. That would be excellent marketing :-) >We have unsigned 64-bit arithmetic similar to the capabilities >of C (well at least GNU-C) and Java in Ada. Yes, that's not >ideal, and for many applications a range checked 64-bit range >would be better. But please don't let best be the enemy of good. Perhaps it should be possible to do it in stages and still conform. E.g. first be able to specify it, manipulate it and use it in arithmetic expressions. I believe that the requirement is there regardless of how much work it is. As times passes the more it becomes neccessary: Computers do not shrink and files and disks become larger. BTW Where I work we have trouble with 32 bit limits. Our Oracle exports have to go through a compression filter (gzip) because otherwise the file becomes too large for the file system and the export fails. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff @ 2000-04-12 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert Dewar 1 sibling, 1 reply; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-12 0:00 UTC (permalink / raw) Robert Dewar wrote : >but I still don't see the complaint, wrapping types like >unsigned in C are useful in Ada and in C, and we have always >have unsigned types in the sense of the above declaration of >q in Ada. My point is not that the modular types are not useful, but that they are inapropriately used. The definitions of the various unsigned types in interfaces and interfaces.C are not apropriate. >But I see the point you are making now. I still don't really >see why you don't like the modular types, they seem useful >and clear to me. After all Java decided it was all they needed >:-) Of course they are useful. If I needed a circular buffer a modular type would be very useful as an index. I'm sure they are wonderful if I want to create a CRC checking routine. A side note: I wish we had a standardized set of C compatible datatypes which contains all datatypes in common use with the common libraries (size_t, socket, various time types etc). The main point is not neccessarily that the semantics are 100 % corret, but that the size is right, so that the size attribute is useful. Every now and then I am working on such a thing (a C program which generates the correct definitions), but as I have a life outside computing, progress is slow. Helsingar, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Tarjei T. Jensen @ 2000-04-12 0:00 ` Robert Dewar 2000-04-13 0:00 ` Tarjei T. Jensen 0 siblings, 1 reply; 96+ messages in thread From: Robert Dewar @ 2000-04-12 0:00 UTC (permalink / raw) In article <8d1ocu$5n31@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > My point is not that the modular types are not useful, but > that they are inapropriately used. The definitions of the > various unsigned types in interfaces and interfaces.C are not > apropriate. I disagree, unsigned in C *is* a modular type, you are saying that it is often used in ways that do not take advantage of the modular semantics, but for sure the modular type of Ada is the right mapping, since it has identical semantics to the C type. It would be quite wrong to map this into a non-modular type, since in the general case, the wrapping semantics of unsigned in C may be critical in a particular interface situation. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-12 0:00 ` Robert Dewar @ 2000-04-13 0:00 ` Tarjei T. Jensen 2000-04-15 0:00 ` Robert Dewar 0 siblings, 1 reply; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-13 0:00 UTC (permalink / raw) Robert Dewar wrote > >I disagree, unsigned in C *is* a modular type, you are saying >that it is often used in ways that do not take advantage of >the modular semantics, but for sure the modular type of Ada >is the right mapping, since it has identical semantics to the >C type. It would be quite wrong to map this into a non-modular >type, since in the general case, the wrapping semantics of >unsigned in C may be critical in a particular interface >situation. The modular semantics of a type like size_t in C is a side effect. It is wrong to blindly translate any unsinged type to a modular type in Ada. The C designers used the unsigned type because it was available and had the required range and not because of its modular semantics. Only a language lawyer would think that it would be sensible for size_t to be a modular type in Ada. And the person whould have to disregard the context and the intention of the designers. I think you will find it difficult to find many places in the standard C libraries where the modular semantics of any unsigned type is of importance or where anything would fail if the type was not modular. The situation is most likely to be quite the oposite; that errors or potential errors will be found which could have cause programs to fail in mysterious ways. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-13 0:00 ` Tarjei T. Jensen @ 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Tarjei T. Jensen 0 siblings, 1 reply; 96+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <8d41rd$6622@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > The modular semantics of a type like size_t in C is a side > effect. It is wron to blindly translate any unsinged type to a > modular type in Ada. The C designers used the unsigned type > because it was available and had the require range and not > because of its modular semantics. Actually I have seen quite a bit of C code that uses the type size_t for addressing computations (a not unreasonable choice) where wrap around semantics is just what you want. > Only a language lawyer would think that it would be sensible > for size_t to be modular type in Ada. Or someone who thinks it is a good idea to be completely interoperable with C :-) Actually it is you who are operating in language lawyer mode, and presuming to know the intent of the designers, and restrict programmers accordingly :-) > I think you will find it difficult to find many places in the > standard C libraries where the modular semantics of any > unsigned type is of importance or > where anything would fail if the type was not modular. Address computations using size_t are one of many examples. > The situation is most likely to be quite the oposite; that > errors or potential errors will be found which could have > cause programs to fail in mysterious > ways. I think that's EXACTLY wrong, what could cause mysterious failures is if the semantics of the Ada types that supposedly mirror the C types are subtly different, and the differences only show up in unusual cases. The point you make is a valid one with respect to the original design in C, it would have been nice in C to have unsigned types with underfined overflow conditions, rather than defined wrap around semantics. But given the choice that C designers made, I think it is really far more appropriate for Ada to copy these choices in providing analogous types in Ada than to decide to "improve" on the C design. When you are in the business of interfacing to a foreign language, you do not want to intefere with the interoperability of the interface by getting into the "that's terrible, we refuse to do things that way in Ada" mode. Indeed as I said above, it is language lawyers who make this mistake, not pragmatic folks :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-15 0:00 ` Robert Dewar @ 2000-04-15 0:00 ` Tarjei T. Jensen 0 siblings, 0 replies; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-15 0:00 UTC (permalink / raw) Robert Dewar wrote >Actually I have seen quite a bit of C code that uses the >type size_t for addressing computations (a not unreasonable >choice) where wrap around semantics is just what you want. I'm quite certain that the only situation which would require modular semantics for a size_t would be if it were used in a hash function or encryption function. [This may not apply for someone who is writing a compiler or a loader.] There are two big probems with wraparound for size_t. One is that there may be a lot of strange stuff high up (perhaps above the stack). Not to mention the stack and the other is that around zero there may be problems as well. Both these things make wraparound semantics for size_t dangerous. I know the offsetof function which uses offsets from address zero to compute offsets in C. But that use does not require modular semantics for size_t. In the book that I have available offsetof is a macro defined as "#define offsetof(type, memb) ((size_t) &((type *)0)->memb)" There is no doubt that there is a lot of work done manipulating size_t, but I don't remember a seeing a single use which involved modular semantics. There might be the occational &, but that's it. I'm not convinced that these things would be something that an Ada programmer would find neccessary to do. In C these tricks may be neccessary, but in Ada much less so. That is after all why we have all the various attributes. >Address computations using size_t are one of many examples. If you are programming in C, you may have need to abuse the type, but in Ada??? Most of the information we would use size_t for are available as attributes. We might need to convert from bits to bytes, but that's it. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
[parent not found: <eisner comp.lang.ada:53670>]
* Re: OS Bindings (was: Where is the elusive jump command?) [not found] ` <eisner comp.lang.ada:53670> @ 2000-04-06 0:00 ` Larry Kilgallen 2000-04-06 0:00 ` Robert Dewar 0 siblings, 1 reply; 96+ messages in thread From: Larry Kilgallen @ 2000-04-06 0:00 UTC (permalink / raw) Reply-To: Kilgallen@eisner.decus.org.nospam Organization: LJK Software Lines: 22 In article <eisner comp.lang.ada:53670>, Ole-Hjalmar Kristensen <ohk@clustra.com> writes: > kilgallen@eisner.decus.org (Larry Kilgallen) writes: >> Are you saying that no Ada vendors for Unix provide bindings ? >> >> That seems incredible in the face of all the hype about how Unix >> is ideal for programming. > > Actually, I was only saying that I could tell you which vendors do > supply one. During the last years, I've only used GNAT for Unix, which > provides an interface to some of the system calls. > Btw., I've now checked Aonix, and they do provide a Posix > interface. Don't know how complete it is. > > I still think Unix is pretty good for programming. You cannot blame > the OS for poor support from Ada vendors :-) Certainly not, but I would expect vendors of any software product on an operating system would have to conform to expectations of those who use the operating system in order to have any success. In the case of compilers, this means bindings. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-06 0:00 ` Larry Kilgallen @ 2000-04-06 0:00 ` Robert Dewar 2000-04-08 0:00 ` nickerson 0 siblings, 1 reply; 96+ messages in thread From: Robert Dewar @ 2000-04-06 0:00 UTC (permalink / raw) In article <2000Apr6.101035.1@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen) wrote: > Certainly not, but I would expect vendors of any software > product on an operating system would have to conform to > expectations of those who use the operating system in order to > have any success. In the case of compilers, this means > bindings. I certainly see why you might think this, coming from a DEC Ada environment on VMS, where people have always been happy to heavily contaminate (from a portability point of view) their programs with starlet stuff. But in our experience, most people want to *minimize* direct operating system connections that tie their programs to a particular operating system. For example, they would rather use the Posix interface than make direct calls to unix service routines, or use GtkAda rather than make direct calls to Win32 services on NT. I am not saying that all customers are in this mode (which is why we for example ship a Win32 binding with the NT version of GNAT, as well as lots of other OS bindings at various levels), but it is definitely the most common mode of operation among our customers. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-06 0:00 ` Robert Dewar @ 2000-04-08 0:00 ` nickerson 2000-04-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 96+ messages in thread From: nickerson @ 2000-04-08 0:00 UTC (permalink / raw) In article <8cilej$bfc$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes: |>In article <2000Apr6.101035.1@eisner>, |> kilgallen@eisner.decus.org (Larry Kilgallen) wrote: |>> Certainly not, but I would expect vendors of any software |>> product on an operating system would have to conform to |>> expectations of those who use the operating system in order to |>> have any success. In the case of compilers, this means |>> bindings. |> |>I certainly see why you might think this, coming from a DEC Ada |>environment on VMS, where people have always been happy to |>heavily contaminate (from a portability point of view) their |>programs with starlet stuff. ??? contaminate - that's provocative; in my area we usuallly chose isolation of OS calls rather than purported "portable" things like POSIX; historically for us that even included the ubiquitous C RTL; this gives rise to a system that has but 1 malloc/calloc, 1 fopen, 1 strcpy, etc etc etc ...; this (arguable) philosophy gives a solid path to portablity; |>But in our experience, most people want to *minimize* direct |>operating system connections that tie their programs to a |>particular operating system. For example, they would rather |>use the Posix interface than make direct calls to unix service |>routines, or use GtkAda rather than make direct calls to |>Win32 services on NT. obviously agree on "minimize direct operating system" calls; am not familiar with GtkAda but believe it's not part of GNAT; does GtkAda support VMS and how long has it been around; --bn (Bart Nickerson) nickerson@pundit.ds.boeing.com (206) 662-0183 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-08 0:00 ` nickerson @ 2000-04-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-09 0:00 UTC (permalink / raw) In article <FsprE4.H0K@news.boeing.com>, nickerson@pundit.ds.boeing.com () wrote: > > In article <8cilej$bfc$1@nnrp1.deja.com>, > Robert Dewar <robert_dewar@my-deja.com> writes: > am not familiar with GtkAda but believe it's not part of GNAT; Ada Core Technologies provides support for GtkAda (and in fact two of the three authors of this package are full time employees of ACT/Europe). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: OS Bindings (was: Where is the elusive jump command?) 2000-04-06 0:00 ` OS Bindings (was: Where is the elusive jump command?) Larry Kilgallen 2000-04-06 0:00 ` Robert Dewar [not found] ` <eisner comp.lang.ada:53670> @ 2000-04-06 0:00 ` Ole-Hjalmar Kristensen 2 siblings, 0 replies; 96+ messages in thread From: Ole-Hjalmar Kristensen @ 2000-04-06 0:00 UTC (permalink / raw) kilgallen@eisner.decus.org (Larry Kilgallen) writes: > In article <umq8zyrmzgp.fsf@gong2.clustra.com>, Ole-Hjalmar Kristensen <ohk@clustra.com> writes: > > kilgallen@eisner.decus.org (Larry Kilgallen) writes: > > > >> In article <umqvh1wnaad.fsf@gong2.clustra.com>, Ole-Hjalmar Kristensen <ohk@clustra.com> writes: > >> > Robert Dewar <dewar@gnat.com> writes: > >> > >> >> But in any case, binding to C is hardly a topic that is > >> >> appropriate to people first learning the language! > >> >> > >> > > >> > Certainly, but writing bindings to C is one of the first things you > >> > have to do if you start using Ada for systems programming on Unix, > >> > unfortunately. > >> > >> I am not sure what you mean by "systems programming" in this case. > >> I would presume that writing device drivers requires knowledge of > >> internal data structures, but don't vendors like Rational supply > >> bindings to Unix entrypoints that might be called by user-mode > >> programs ? > > > > I was not thinking device drivers, but systems like communications > > systems or DBMS's, which typically will need access to Unix > > entrypoints or system calls. A thick binding designed by someone who > > is unaware of the specific needs of the system may not be suitable. > > > > An example of the the need for system calls: A couple of months ago I > > wanted to test various implementations of asynchronous IO (Sun > > asynchronous IO, POSIX asynchronous IO, and Ada). However, to do a > > meaningful test, I need to ensure that I/O operations on the file > > descriptor complete as defined by synchronized I/O data integrity > > rules. This means either using the fcntl or fsync system calls, or > > setting the O_SYNC flag in the call to open. > > > > In this case, needing only a few system calls, it may be more cost > > effective to write your own binding, as it's usually not difficult. > > > > Yes, it may be possible to buy such a binding, although I have not > > seen any reference to it, either on Rational's web pages, nor on > > Adahome's list of bindings. > > On VMS, using either DEC Ada (83) or GNAT, one gets these bindings > in the package STARLET. If a competitor were to develop a compiler > for VMS without the assistance of Compaq they could achieve the same > effect with the public domain SDL program to extract the binding data > from the operating system. > Yes, I know. I used DEC's Ada 83 years ago, and was very pleased. > On Windows NT, Aonix ships two competing sets of bindings to the > operating system calls and matching data structures. > > Are you saying that no Ada vendors for Unix provide bindings ? > > That seems incredible in the face of all the hype about how Unix > is ideal for programming. Actually, I was only saying that I could tell you which vendors do supply one. During the last years, I've only used GNAT for Unix, which provides an interface to some of the system calls. Btw., I've now checked Aonix, and they do provide a Posix interface. Don't know how complete it is. I still think Unix is pretty good for programming. You cannot blame the OS for poor support from Ada vendors :-) Ole-Hj. Kristensen -- E pluribus Unix ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Alfred Hilscher @ 2000-03-30 0:00 ` Richard D Riehle 2000-04-01 0:00 ` Robert A Duff 1 sibling, 1 reply; 96+ messages in thread From: Richard D Riehle @ 2000-03-30 0:00 UTC (permalink / raw) In article <8brrpj$i04$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: >In article <8brn4k$p6i$1@slb0.atl.mindspring.net>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: >> >> To write such a compiler, it is necessary to include certain >> reserved words and syntactic constructs that "tip off" the >> compiler to possible problems. The word _aliased_ seems to me >> to be one of those "tip-off the compiler" words. This can >> later be augmented with a more technical explanation, but it >> works well for most early students when explained within the >> framework of the above stated goals. > >I find this a very odd view of the ALIASED keyword. The reason >for this has nothing to do with the compiler. As in the case >of most C compilers, the compiler could look at your code to >see whether or not you take the address of something. That's >not at all the intention. This could have been accomplished without the word _aliased_ keyword. Could it have been as easily checked by the compiler? It seems to me that _aliased_ helps prevent the very kind of errors one encounters in C. If the reserved word is not intended to provide special information to the compiler, why not just do this the same way we do it in C? The fact is that I cannot use 'Access on a value that is not aliased. The compiler prevents it. Hence, I see this is as a signal to the compiler that I am trying to do something illegal. It is also a tip-off to the compiler that accessibility rules need to be enforced. Whatever the original intent of _aliased_ , it has the effect of letting the programmer know about the legality or illegality of a syntactic construct, ensuring that certain practices are avoided, and making it clear what one's intentions are in the source code. >The point is that aliasing is generally speaking very bad >practice. The facility for pointing to variables was introduced >in Ada 95 with reluctance when certain convincing examples >were given, including in particular the construction of >static structures involving pointers. I am one of those people who understands the reluctance to introduce this construct into Ada. It turns out to be a valuable feature of the language and the accessibility rules do make it a little bit safer than the corresponding code in C. Of course, Unchecked_Access does allow unruly behavior from some programmers. >It should be VERY sparingly used, really it should be regarded >like Unchecked_Conversion, a noisy declaration that you intend >to do something rather undesirable, namely in this case the >creation of possibly confusing aliases for the variable. Lots of things should be sparingly used. One might say the same about tagged types and inheritance. Certainly most agree that _goto_ should be sparingly used. Indeed, you wrote a thoughtful contribution last year asserting that assignment should be sparingly used. Perhaps requiring the reserved word _aliased_ encourages the sparing use of it in source code. There are situations, particulary interfacing with some of the operating system facilities, where a general access type, and the word _aliased_ makes good sense. Also, many of the programmers I deal with in my daily work are former C/C++ programmers who are accustomed to working without a safety-net. For them, the accessibility rules associated with _aliased_ values, make sense, even though they are sometimes a bit annoying. >Note by the way that 'Address can be applied freely to variables >in any case without the ALIASED keyword, so Ada 95 compilers in >any case have to have the circuitry for automatic detection of >which variables have their addresses taken and which do not >(GNAT most certainly has this circuit). Thus ALIASED is not of >the slightest utility to the compiler (in GNAT it is essentially >ignored except for providing the essential semantic checking >associated with this facility). OK. Semantic checking seems somewhat important. The compiler does check this. Why bother with it? It seems to me that this is because there are some associated rules, and these are checked at compile time. To my mind, this illustrates one of the most important aspects of Ada: maximizing detection of programmer stupidity at compile time. Perhaps _aliased_ is of no importance to the compiler from the point-of-view of creating an operational compiler. That would be true, I suspect, of many other Ada features. Donald Knuth is fond of reminding us that we are not writing programs for compilers but for ourselves and other people. We make mistakes. Well, I do anyway, lots of them, it would seem. The Ada language helps us minimize those mistakes by enabling a compiler technology that notices those mistakes. The keyword, _aliased_ , may be of no intrinsic value to the compiler, but it does "tip off" the compiler to the reality that we may have made some silly error in our coding. When the compiler informs of us of this fact, we have the option of correcting our code. Is this a superfluous notification? I don't think so. As to 'Address, this is really fraught with potential dangers. Now there is a language construct that needs to be used sparingly. Richard Riehle ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Where is the elusive jump command? Richard D Riehle @ 2000-04-01 0:00 ` Robert A Duff 2000-04-02 0:00 ` Robert Dewar 2000-04-02 0:00 ` Richard D Riehle 0 siblings, 2 replies; 96+ messages in thread From: Robert A Duff @ 2000-04-01 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > This could have been accomplished without the word _aliased_ > keyword. Could it have been as easily checked by the compiler? Yes, because as Robert pointed out, the same analysis has to be done for 'Address, anyway. > It seems to me that _aliased_ helps prevent the very kind of > errors one encounters in C. If the reserved word is not intended > to provide special information to the compiler, why not just do > this the same way we do it in C? Umm. Because the compiler isn't the one putting errors in the code -- it's you and me. "Aliased" is there for the human reader. It doesn't make the compiler any simpler. In fact the compiler has to go to extra trouble to check the rules. >...The fact is that I cannot use > 'Access on a value that is not aliased. The compiler prevents it. > Hence, I see this is as a signal to the compiler that I am trying > to do something illegal. It is also a tip-off to the compiler that > accessibility rules need to be enforced. Not really -- the accessibility rules are triggered by 'Access and type conversions and so forth; the compiler doesn't need any "tipping off" in this sense. > Whatever the original intent of _aliased_ , it has the effect of > letting the programmer know about the legality or illegality of a > syntactic construct, ensuring that certain practices are avoided, > and making it clear what one's intentions are in the source code. Right. >...Perhaps requiring the reserved word _aliased_ encourages the > sparing use of it in source code. I've heard that sort of thing many times. I don't agree. A competent programmer will use '[Unchecked_]Access on local variables exactly when appropriate -- no more, no less. That's true whether or not you have to mark things as "aliased". The point (IMHO) is not to encourage or discourage things, but to make sure the *reader* of the code can easily see what's going on. - Bob ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-01 0:00 ` Robert A Duff @ 2000-04-02 0:00 ` Robert Dewar 2000-04-02 0:00 ` Richard D Riehle 1 sibling, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-02 0:00 UTC (permalink / raw) In article <wcc66u1g5ej.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > I've heard that sort of thing many times. I don't agree. A > competent programmer will use '[Unchecked_]Access on local > variables exactly when > appropriate -- no more, no less. That's true whether or not > you have to > mark things as "aliased". Well the competent programmer argument is always suspect, but in this particular case you are missing something very specific. In many Ada environments, specs are controlled much more fiercely than bodies. The aliased keyword in the case of package spec variables has to go in the spec which is carefuly controlled, and the less controlled programmer in the body cannot use 'Access in the absence of the aliased keyword. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-01 0:00 ` Robert A Duff 2000-04-02 0:00 ` Robert Dewar @ 2000-04-02 0:00 ` Richard D Riehle 2000-04-02 0:00 ` Robert Dewar 2000-04-02 0:00 ` Robert Dewar 1 sibling, 2 replies; 96+ messages in thread From: Richard D Riehle @ 2000-04-02 0:00 UTC (permalink / raw) In article <wcc66u1g5ej.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: >Richard D Riehle <laoXhai@ix.netcom.com> writes: > >> This could have been accomplished without the word _aliased_ >> keyword. Could it have been as easily checked by the compiler? > >Yes, because as Robert pointed out, the same analysis has to be done for >'Address, anyway. OK. So the same analysis must be done. That does not change the value of _aliased_ for the programmer writing the code. Knuth, as mentioned earlier, suggests that programming languages are designer for humans not for compilers. Ada is somewhere in between, I guess because many of the rules in the language are intended to enable the construction of more robust compilers. Also, I recall reading somewhere, perhaps the Rationale, that aliased was intended to be useful for the compiler writer so code optimizations could be anticipated. Perhaps this usage is now superseded by more clever compiler designs. >> It seems to me that _aliased_ helps prevent the very kind of >> errors one encounters in C. If the reserved word is not intended >> to provide special information to the compiler, why not just do >> this the same way we do it in C? > >Umm. Because the compiler isn't the one putting errors in the code -- >it's you and me. Exactly my point. And _aliased_ helps the compiler notice the errors we so generously contribute to the code. >"Aliased" is there for the human reader. It doesn't make the compiler >any simpler. In fact the compiler has to go to extra trouble to check >the rules. Bingo. Once again, right to the original point. That is what Ada is about, checking to ensure we have not violated some little rule. The question then, "Is this an unnecessary rule?" Should we simply let the compiler assume we are doing what we intended? >>...The fact is that I cannot use >> 'Access on a value that is not aliased. The compiler prevents it. >> Hence, I see this is as a signal to the compiler that I am trying >> to do something illegal. It is also a tip-off to the compiler that >> accessibility rules need to be enforced. > >Not really -- the accessibility rules are triggered by 'Access and type >conversions and so forth; the compiler doesn't need any "tipping off" in >this sense. OK. Granted that the accessibility rules are larger than the _aliased_ keyword. From the viewpoint of an applications developer, it seems that the _aliased_ keyword is essential. Very few of us, thankfully, are still writing compilers, so most of us look at this from the viewpoint of human beings trying to make code work. In fact, most of us don't care a whit about what it takes for the compiler to do its work. We simply want the rules applied correctly and consistently. >> Whatever the original intent of _aliased_ , it has the effect of >> letting the programmer know about the legality or illegality of a >> syntactic construct, ensuring that certain practices are avoided, >> and making it clear what one's intentions are in the source code. > >Right. Glad we can agree on this. From my perspective, this is an essential idea. My sentence, with which you seem to agree, probably applies to lots of other syntactic constructs in the language. Question: would the Ada language be just as effective without the _aliased_ keyword? Are there other keywords we could jettison in favor of simplicity? >>...Perhaps requiring the reserved word _aliased_ encourages the >> sparing use of it in source code. > >I've heard that sort of thing many times. I don't agree. A competent >programmer will use '[Unchecked_]Access on local variables exactly when >appropriate -- no more, no less. That's true whether or not you have to >mark things as "aliased". The point (IMHO) is not to encourage or >discourage things, but to make sure the *reader* of the code can easily >see what's going on. That makes very good sense. It takes us back to the issue of interaction between programmer and compiler, where the language is designed to improve clarity for the human reader of source code, not just for the compiler. This is in keeping with the spirit of Don Knuth's "Literate Programming," admonitions. It is also in compliance with what many of us see as the underlying goal of Ada: maximize the amount of checking a compiler can do as early in the development process as possible. That checking includes pummeling the programmer about the head and shoulders soundly for forgetting to include the _aliased_ keyword. Richard Riehle ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-02 0:00 ` Richard D Riehle @ 2000-04-02 0:00 ` Robert Dewar 2000-04-02 0:00 ` Robert Dewar 1 sibling, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-02 0:00 UTC (permalink / raw) In article <8c668j$hv0$1@slb1.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > Also, I recall reading somewhere, perhaps the Rationale By the way, it is useful to point out that the Rationale has no official status with respect to the standard. It is a separate informal document written by a small number of people, and not reviewed with anything like the care of the RM itself. There are quite a few statements in the Rationale that are plain wrong, and there are many more cases where opinions are expressed that not everyone would agree with :-) That does not mean that it is not a useful reference, just that it does not have any special status when compared to other Ada text books. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-02 0:00 ` Richard D Riehle 2000-04-02 0:00 ` Robert Dewar @ 2000-04-02 0:00 ` Robert Dewar 1 sibling, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-02 0:00 UTC (permalink / raw) In article <8c668j$hv0$1@slb1.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > Also, I recall reading somewhere, perhaps the Rationale, that > aliased was intended to be useful for the compiler writer so > code optimizations could be anticipated. Perhaps this usage > is now superseded by more clever compiler designs. Something you read somewhere but cannot remember where is not a very convincing reference :-) In any case, no compiler writer would have agreed to such a statement at any point during the design, since it is obviously wrong. All Ada 83 compilers had to deal with 'Address, so even if you restrict the experience to the Ada world, the idea that aliased is helpful to the compiler does not fly! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-28 0:00 ` Robert Dewar 2000-03-29 0:00 ` Richard D Riehle @ 2000-03-29 0:00 ` Marin D. Condic 2000-03-29 0:00 ` Gary Scott 2000-03-30 0:00 ` Alfred Hilscher 1 sibling, 2 replies; 96+ messages in thread From: Marin D. Condic @ 2000-03-29 0:00 UTC (permalink / raw) Robert Dewar wrote: > I disagree, noone teaches goto's in any beginning programming > courses, for good reasons. Anyone desparately wanting to write > gotos has a peculiar starting point. > I agree. However, I rather got the impression that the original poster was an experienced programmer who was used to doing things a particular way based on what other languages normally do. I wouldn't teach gotos as an introductory style, but if a Fortran weenie wanted to know how it was done in Ada, I'd show him and advise him that there were better ways. > As for terminating strings with null, that really does not work > in Ada for many reasons, the models of strings are very very > different in C and Ada, and trying to gloss over this will be > a disservice. > Again, I agree wholeheartedly. I've seen too many C programmers come over to Ada and try terminating strings with null, pass parameters with addresses, etc. Essentially they are fighting the language and making their lives harder. However, I would at least point out to them that what they are used to doing can be done with Ada, but that again they are fighting the language and making their lives harder. I just think that Ada gets a bad rap and gets ignored because someone used to C programming starts going "Well, I can't do in Ada the kinds of things I usually do, so Ada is useless." > As for pointers, I would NEVER tell people about *aliased* until > they understood the language well. > Certainly *aliased* anything is a concept best left for the experienced programmer and should not be an intro-level topic. It depends on the audience though. If you've got an experienced C programmer who wants to learn to use Ada to interface to the Win32api, you need to discuss this topic. All the while emphasizing that it should be used judiciously, hidden at low levels in the case of bindings and that generally Ada programs don't do this kind of thing because it has better ways. > You just confuse people by introducing features that are > unnecessary and will lead them in the wrong direction. > We do have to be careful not to confuse the newbies. We should try to emphasize The Ada Way of programming. I just think we'll win a few more converts by being willing to say "Yeah, you can do exactly what you usually do in language X and here's how. But there is a *better* way to consider that will make your life easier." I know we have the same objective. The tricky part is how best to get there. MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** Visit my web site at: http://www.mcondic.com/ "Because that's where they keep the money." -- Willie Sutton when asked why he robbed banks. ============================================================= ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Marin D. Condic @ 2000-03-29 0:00 ` Gary Scott 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Alfred Hilscher 1 sibling, 1 reply; 96+ messages in thread From: Gary Scott @ 2000-03-29 0:00 UTC (permalink / raw) "Marin D. Condic" wrote: > > Robert Dewar wrote: > > I disagree, noone teaches goto's in any beginning programming > > courses, for good reasons. Anyone desparately wanting to write > > gotos has a peculiar starting point. > > > I agree. However, I rather got the impression that the original poster > was an experienced programmer who was used to doing things a particular > way based on what other languages normally do. I wouldn't teach gotos as > an introductory style, but if a Fortran weenie wanted to know how it was > done in Ada, I'd show him and advise him that there were better ways. > This Fortran jab sounds like someone unfamiliar with Fortran 95. Fortran is now a general purpose language with most of the modern constructs that you might require. Many current Fortran users write quite high quality code, even non-CS engineers and scientists. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Gary Scott @ 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Gary Scott ` (2 more replies) 0 siblings, 3 replies; 96+ messages in thread From: Robert Dewar @ 2000-03-29 0:00 UTC (permalink / raw) In article <38E2333B.2109F2BB@lmtas.lmco.com>, Gary Scott <Gary.L.Scott@lmtas.lmco.com> wrote: > This Fortran jab sounds like someone unfamiliar with Fortran 95. > Fortran is now a general purpose language with most of the modern > constructs that you might require. Many current Fortran users write > quite high quality code, even non-CS engineers and scientists. The percentage of Fortran code currently written using Fortran 95 is small. Furthermore, I have seen a lot of Fortran 95 code which is still very much in old style. Old habits die hard, and fewer people learn Fortran these days :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Robert Dewar @ 2000-03-30 0:00 ` Gary Scott 2000-03-30 0:00 ` Gautier 2000-03-30 0:00 ` David Starner 2 siblings, 0 replies; 96+ messages in thread From: Gary Scott @ 2000-03-30 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <38E2333B.2109F2BB@lmtas.lmco.com>, > Gary Scott <Gary.L.Scott@lmtas.lmco.com> wrote: > > This Fortran jab sounds like someone unfamiliar with Fortran > 95. > > Fortran is now a general purpose language with most of the > modern > > constructs that you might require. Many current Fortran users > write > > quite high quality code, even non-CS engineers and scientists. > > The percentage of Fortran code currently written using Fortran > 95 is small. Furthermore, I have seen a lot of Fortran 95 code > which is still very much in old style. Old habits die hard, and > fewer people learn Fortran these days :-) Actually, there are about 10 Fortran 90/95 compiler companies in business at the moment. Fortran simply gets left out of market surveys (of "programmers") because of its user base being scientists/engineers primarily. It is estimated that Fortran's user base is presently the highest it has ever been and still growing according to sales figures, it simply isn't growing anywhere as fast as some other notable languages. Part of the reason has been delays in standard development activities (infighting by featurists wanting to make it general purpose vs "traditionalists" wanting to limit it to number crunching and believing that it's getting "too big"). > > Sent via Deja.com http://www.deja.com/ > Before you buy. -- Gary Scott mailto:scottg@flash.net ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Gary Scott @ 2000-03-30 0:00 ` Gautier 2000-03-30 0:00 ` Gary Scott 2000-03-30 0:00 ` David Starner 2 siblings, 1 reply; 96+ messages in thread From: Gautier @ 2000-03-30 0:00 UTC (permalink / raw) Robert Dewar wrote: > The percentage of Fortran code currently written using Fortran > 95 is small. Furthermore, I have seen a lot of Fortran 95 code > which is still very much in old style. A reason is the huge mass of <= 77 Fortran code in place. An engineer will have to re-work, expand an exisiting Fortran 77 code and often will (re-)learn programming in that activity by imitation of the existing code. Another reason is that the "modern" features (90+) are not very intuitive to the eye - a sort of over-verbose C syntax with contorsions to keep compatibility with Fortran 77. Would I have to program in Fortran, I would stick to the 77 syntax which is relatively simple and readable with many modern structures. It is already somewhat difficult to keep a minimal security with 77 (E.g. forgetting "implicit none", headaches with the variable visibility, "common"s & Co). For bigger or new programs, or more complex data structures the best to do is to acquire/download an Ada95 compiler and use f2a.pl to translate parts. ______________________________________________________ Gautier -- http://members.xoom.com/gdemont/gsoft.htm ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Gautier @ 2000-03-30 0:00 ` Gary Scott 2000-03-30 0:00 ` David Starner 2000-03-30 0:00 ` Gautier 0 siblings, 2 replies; 96+ messages in thread From: Gary Scott @ 2000-03-30 0:00 UTC (permalink / raw) Gautier wrote: > > Robert Dewar wrote: > > > The percentage of Fortran code currently written using Fortran > > 95 is small. Furthermore, I have seen a lot of Fortran 95 code > > which is still very much in old style. > > A reason is the huge mass of <= 77 Fortran code in place. > An engineer will have to re-work, expand an exisiting Fortran 77 > code and often will (re-)learn programming in that activity > by imitation of the existing code. > Another reason is that the "modern" features (90+) are not > very intuitive to the eye - a sort of over-verbose C syntax > with contorsions to keep compatibility with Fortran 77. More bunk. Most of the "modern" features of Fortran 90/95 were borrowed from Ada and Modula. And many areas are less-verbose than Ada, but certainly less cryptic than C. > Would I have to program in Fortran, I would stick to the > 77 syntax which is relatively simple and readable with > many modern structures. It is already somewhat difficult > to keep a minimal security with 77 (E.g. forgetting "implicit none", > headaches with the variable visibility, "common"s & Co). > For bigger or new programs, or more complex data structures the best > to do is to acquire/download an Ada95 compiler and use f2a.pl to > translate parts. > ______________________________________________________ > Gautier -- http://members.xoom.com/gdemont/gsoft.htm ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Gary Scott @ 2000-03-30 0:00 ` David Starner 2000-03-30 0:00 ` William B. Clodius 2000-03-30 0:00 ` Gautier 1 sibling, 1 reply; 96+ messages in thread From: David Starner @ 2000-03-30 0:00 UTC (permalink / raw) On Thu, 30 Mar 2000 08:36:35 -0600, Gary Scott <Gary.L.Scott@lmtas.lmco.com> wrote: >> A reason is the huge mass of <= 77 Fortran code in place. >> An engineer will have to re-work, expand an exisiting Fortran 77 >> code and often will (re-)learn programming in that activity >> by imitation of the existing code. >> Another reason is that the "modern" features (90+) are not >> very intuitive to the eye - a sort of over-verbose C syntax >> with contorsions to keep compatibility with Fortran 77. > >More bunk. Most of the "modern" features of Fortran 90/95 were borrowed >from Ada and Modula. And many areas are less-verbose than Ada, but >certainly less cryptic than C. Overloading. Some form of Fortran's overloading is on my list for my high-level Intercal. The type/kind system. Using integer constants for types is very cryptic. >> many modern structures. It is already somewhat difficult >> to keep a minimal security with 77 (E.g. forgetting "implicit none", >> headaches with the variable visibility, Implicit none is illegal in standard Fortran 77, though it's a common extension. -- David Starner - dstarner98@aasaa.ofe.org Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` David Starner @ 2000-03-30 0:00 ` William B. Clodius 0 siblings, 0 replies; 96+ messages in thread From: William B. Clodius @ 2000-03-30 0:00 UTC (permalink / raw) David Starner wrote: > <snip> > Implicit none is illegal in standard Fortran 77, though it's a common > extension. > <snip> While not part of the Fortran 77 standard it was part of MIL-STD 1753 (I hope I have the number right), which was issued shortly after the Fortran 77 standard. It is therefore a "standard" extension in the US, that anyone writing Fortran for the US military could and should consider as supported. Because of the importance of the military market, I don't know of any compilers in the US that didn't support it by the mid-80's. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Gary Scott 2000-03-30 0:00 ` David Starner @ 2000-03-30 0:00 ` Gautier 1 sibling, 0 replies; 96+ messages in thread From: Gautier @ 2000-03-30 0:00 UTC (permalink / raw) > More bunk. Most of the "modern" features of Fortran 90/95 were borrowed > from Ada and Modula. Really modern and useful features would be to have strong typing and have simple visibility rules in addition to "modernist" formalism. Are these really in F90/95 ? It would mean to sacrify some compatibility with F77. Frankly at some point it becomes fruitless to relift an old language by borrowing features from others and try to glue them. > And many areas are less-verbose than Ada, Can you cite one area, one example ? I am really curious, since all examples that lay on the Web tend to prove the reverse! > but certainly less cryptic than C. For the F77 subset I agree, for the F90+ I don't... A question of taste surely... _____________________________________________ Gautier -- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Gary Scott 2000-03-30 0:00 ` Gautier @ 2000-03-30 0:00 ` David Starner 2000-03-30 0:00 ` Marin D. Condic 2 siblings, 1 reply; 96+ messages in thread From: David Starner @ 2000-03-30 0:00 UTC (permalink / raw) On Wed, 29 Mar 2000 23:43:20 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote: >which is still very much in old style. Old habits die hard, and >fewer people learn Fortran these days :-) You might be surprised, though. The Comp Sci department still offers Fortran 77 (taught by the prof who was a graduate student when Fortran first appeared), and the Engineering Department forces all engineering students to take Fortran 90 (Intro to Engineering Programming). That CS Fortran class has more enrollment than the Ada class, too. -- David Starner - dstarner98@aasaa.ofe.org Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` David Starner @ 2000-03-30 0:00 ` Marin D. Condic 2000-03-30 0:00 ` Samuel T. Harris ` (6 more replies) 0 siblings, 7 replies; 96+ messages in thread From: Marin D. Condic @ 2000-03-30 0:00 UTC (permalink / raw) David Starner wrote: > You might be surprised, though. The Comp Sci department still offers > Fortran 77 (taught by the prof who was a graduate student when Fortran > first appeared), and the Engineering Department forces all engineering > students to take Fortran 90 (Intro to Engineering Programming). That CS > Fortran class has more enrollment than the Ada class, too. > Aside from the fact that there is tons of Fortran code lying around already, is there any reason why "number crunching" or "scientific/engineering software" couldn't be taught/done in Ada? My Fortran experience was back in the Fortran 77 days and I don't recall anything being in the language that couldn't be done just as well - if not better - in Ada95. (Especially given Ada's type capabilities and precise definitions for math ops, numeric attributes, etc.) And if the only argument against it is the tons of existing math libraries, then theres Ada's interface capability to argue in its favor. Its a market that could be tapped - and maybe one that isn't already anti-Ada biased. Hmmmmmmmmm........ MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** Visit my web site at: http://www.mcondic.com/ "Because that's where they keep the money." -- Willie Sutton when asked why he robbed banks. ============================================================= ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Marin D. Condic @ 2000-03-30 0:00 ` Samuel T. Harris 2000-03-30 0:00 ` Gary Scott ` (5 subsequent siblings) 6 siblings, 0 replies; 96+ messages in thread From: Samuel T. Harris @ 2000-03-30 0:00 UTC (permalink / raw) "Marin D. Condic" wrote: > > David Starner wrote: > Aside from the fact that there is tons of Fortran code lying around > already, is there any reason why "number crunching" or > "scientific/engineering software" couldn't be taught/done in Ada? My > Fortran experience was back in the Fortran 77 days and I don't recall > anything being in the language that couldn't be done just as well - if > not better - in Ada95. (Especially given Ada's type capabilities and > precise definitions for math ops, numeric attributes, etc.) > > And if the only argument against it is the tons of existing math > libraries, then theres Ada's interface capability to argue in its favor. > I remember years ago when Honeywell came out with the DPS-90 computer. I as an Air Force officer which reviewed Ada waivers for MAC. One development group wanted to use the Fortran compiler on the DPS-90 because it supported the vector/matrix processor incorporated in that architecture. They claimed the Ada compiler did not. This claim remain a valid waiver excuse for just about 2 hours. That was the time it took me to write and test an Ada binding to Fortran code thus provided Ada with access to the very same vector/matrix processor. Waiver denied! This is one of my favorite examples of the powerful interface features of Ada. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Marin D. Condic 2000-03-30 0:00 ` Samuel T. Harris @ 2000-03-30 0:00 ` Gary Scott 2000-03-31 0:00 ` Tarjei T. Jensen 2000-03-30 0:00 ` Larry Kilgallen ` (4 subsequent siblings) 6 siblings, 1 reply; 96+ messages in thread From: Gary Scott @ 2000-03-30 0:00 UTC (permalink / raw) "Marin D. Condic" wrote: > > David Starner wrote: > > You might be surprised, though. The Comp Sci department still offers > > Fortran 77 (taught by the prof who was a graduate student when Fortran > > first appeared), and the Engineering Department forces all engineering > > students to take Fortran 90 (Intro to Engineering Programming). That CS > > Fortran class has more enrollment than the Ada class, too. > > > Aside from the fact that there is tons of Fortran code lying around > already, is there any reason why "number crunching" or > "scientific/engineering software" couldn't be taught/done in Ada? My > Fortran experience was back in the Fortran 77 days and I don't recall > anything being in the language that couldn't be done just as well - if > not better - in Ada95. (Especially given Ada's type capabilities and > precise definitions for math ops, numeric attributes, etc.) > > And if the only argument against it is the tons of existing math > libraries, then theres Ada's interface capability to argue in its favor. > > Its a market that could be tapped - and maybe one that isn't already > anti-Ada biased. Hmmmmmmmmm........ The C++ (templates) guys are saying the exact same thing. Meanwhile, most of us "number crunchers" (I'm also a GUI tool builder) are busy updating to Fortran 95 module-based solutions, and the Fortran standard committee is busy designing "Object Oriented Fortran" (and given the constraints, doing a pretty good job of it). Of course the oldest successful high-level language is going to have baggage. The standard officially identifies "deprecated" features and programmers are encouraged not to use them (and most don't). My company probably writes as much or more Ada code as any other. We also write a lot of stuff with Visual Fortran (95). But I can tell you that Ada is losing the battle to C++ (in those embedded processor domains) while Fortran plods along at about the same level. The reason? Getting huge quantities of "experienced" C<++> newhires is easier than with Ada. P.S. My opinions, not speaking for my employer, of course. > > MDC > -- > ============================================================= > Marin David Condic - Quadrus Corporation - 1.800.555.3393 > 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 > http://www.quadruscorp.com/ > m c o n d i c @ q u a d r u s c o r p . c o m > > ***PLEASE REMOVE THE "-NOSPAM" PART OF MY RETURN ADDRESS*** > > Visit my web site at: http://www.mcondic.com/ > > "Because that's where they keep the money." > -- Willie Sutton when asked why he robbed banks. > ============================================================= ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Gary Scott @ 2000-03-31 0:00 ` Tarjei T. Jensen 2000-03-31 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 96+ messages in thread From: Tarjei T. Jensen @ 2000-03-31 0:00 UTC (permalink / raw) Gary Scott wrote: >My company probably writes as much or more Ada code as any other. We >also write a lot of stuff with Visual Fortran (95). But I can tell you >that Ada is losing the battle to C++ (in those embedded processor >domains) while Fortran plods along at about the same level. The >reason? Getting huge quantities of "experienced" C<++> newhires is >easier than with Ada. That may change within a few years. There is a number of universities that have started to use Ada. There is a steady increase in the number of people which nows and loves the language. If a company wants Ada productivity, all it needs to do is to find which universities which uses ada and recruit there. Simple! Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-31 0:00 ` Tarjei T. Jensen @ 2000-03-31 0:00 ` Larry Kilgallen 2000-03-31 0:00 ` Gary Scott 0 siblings, 1 reply; 96+ messages in thread From: Larry Kilgallen @ 2000-03-31 0:00 UTC (permalink / raw) In article <8c1t3l$dkp1@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > If a company wants Ada productivity, all it needs to do is to find which > universities which uses ada and recruit there. Simple! That does presume, of course, a company is willing to hire people straight out of school. If I were going to hire someone from a school, I would want a _lot_ of details regarding what coursework had taught them about writing maintainable code and testable code, and how many courses had them actually making changes to programs written by others. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-31 0:00 ` Larry Kilgallen @ 2000-03-31 0:00 ` Gary Scott 0 siblings, 0 replies; 96+ messages in thread From: Gary Scott @ 2000-03-31 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > > In article <8c1t3l$dkp1@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > > > If a company wants Ada productivity, all it needs to do is to find which > > universities which uses ada and recruit there. Simple! > > That does presume, of course, a company is willing to hire people > straight out of school. If I were going to hire someone from a > school, I would want a _lot_ of details regarding what coursework > had taught them about writing maintainable code and testable code, > and how many courses had them actually making changes to programs > written by others. In my case, there is presently a decree (so I'm told) that newhires will be 40% new college grads. Of course this value fluctuates up and down over the course of the year. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Marin D. Condic 2000-03-30 0:00 ` Samuel T. Harris 2000-03-30 0:00 ` Gary Scott @ 2000-03-30 0:00 ` Larry Kilgallen 2000-03-30 0:00 ` Dan Nagle ` (3 subsequent siblings) 6 siblings, 0 replies; 96+ messages in thread From: Larry Kilgallen @ 2000-03-30 0:00 UTC (permalink / raw) In article <38E396E7.45941282@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> writes: > David Starner wrote: >> You might be surprised, though. The Comp Sci department still offers >> Fortran 77 (taught by the prof who was a graduate student when Fortran >> first appeared), and the Engineering Department forces all engineering >> students to take Fortran 90 (Intro to Engineering Programming). That CS >> Fortran class has more enrollment than the Ada class, too. >> > Aside from the fact that there is tons of Fortran code lying around > already, is there any reason why "number crunching" or > "scientific/engineering software" couldn't be taught/done in Ada? There also tons of fellow number-crunchers around who are using Fortran. Finding a scientist in your lab who both understands your problem domain and understands Fortran is easier than one who understands your problem domain and understands Ada. This is simple statistics, unrelated to issues of what language is better for any purpose. A similar situation exists in the Medical industry with the programming language MUMPS (since renamed to just "M"). That language is preferred in that problem domain, making it hard to introduce new paradigms to that industry, like privacy of patient records and the individual authentication of users such a bold move would entail. It could be argued that Ada is preferred in the missiles and aircraft market. It seems to be gaining in the railroad market. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Marin D. Condic ` (2 preceding siblings ...) 2000-03-30 0:00 ` Larry Kilgallen @ 2000-03-30 0:00 ` Dan Nagle 2000-03-30 0:00 ` David Starner 2000-03-30 0:00 ` Samuel T. Harris 2000-03-31 0:00 ` Gisle S�lensminde ` (2 subsequent siblings) 6 siblings, 2 replies; 96+ messages in thread From: Dan Nagle @ 2000-03-30 0:00 UTC (permalink / raw) Hello, >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 3/30/00, 1:03:19 PM, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote regarding Re: Where is the elusive jump command?: <snip requoted discussion> > Aside from the fact that there is tons of Fortran code lying around > already, is there any reason why "number crunching" or > "scientific/engineering software" couldn't be taught/done in Ada? My > Fortran experience was back in the Fortran 77 days and I don't recall > anything being in the language that couldn't be done just as well - if > not better - in Ada95. (Especially given Ada's type capabilities and > precise definitions for math ops, numeric attributes, etc.) I'm learning Ada, so I won't comment on "type capabilities etc.", but I think any language I ever saw has a long way to go to catch up with Fortran's kind mechanism. Which numeric attributes do you think are present in Ada and not Fortran? This discussion appeared in c.l.a, what? A year ago? Fortran has many features which allow extremely aggressive optimization by the compiler. I know of many Fortran applications where a single run is thousands of hours of Cray cpu time, so a percent or two is important. Does Ada have any loop, branch or assignment statements, which, by definition, may be executed in parallel? My reading and exercises haven't shown them to me yet. Maybe I just haven't gotten to the right chapter... > And if the only argument against it is the tons of existing math > libraries, then theres Ada's interface capability to argue in its favor. If I can learn enough Ada, and find the time, and can persuade J3, then I'm willing to write an Ada interface for Fortran. Fortran 2000 will have a C interface. > Its a market that could be tapped - and maybe one that isn't already > anti-Ada biased. Hmmmmmmmmm........ Of course, it could become anti-Ada if there's too much Fortran bashing. Lately, this newsgroup has sounded a bit like some of the C++ guys who "drop in" over in comp.lang.fortran for a little flame fest. (bring your own wienies ;-) <snip sig> I think I've posted this before, but... I'd like to fly in an airplane designed in Fortran (not C++), where the fly-by-wire is Ada (not Java). -- Cheers! Dan Nagle, eMail: dnagle@erols.com Purple Sage Computing Solutions, Inc., 12142 Purple Sage Ct., Reston VA 20194 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Dan Nagle @ 2000-03-30 0:00 ` David Starner 2000-03-30 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 96+ messages in thread From: David Starner @ 2000-03-30 0:00 UTC (permalink / raw) On Thu, 30 Mar 2000 16:28:48 GMT, Dan Nagle <dnagle@erols.com> wrote: >I'm learning Ada, so I won't comment on "type capabilities etc.", but >I think any language I ever saw has a long way to go to catch up with >Fortran's kind mechanism. Which numeric attributes do you think are >present in Ada and not Fortran? Ack. I don't know enough about numerics to argue capabilities, but Fortran's kind mechanism is ugly. Types should not be stored in integers, and REAL(kind=4) is strictly evil. Fortran's arbitrary use of integer constants for types and structures (file IO) is evil. >Does Ada have any loop, branch or assignment statements, which, by >definition, >may be executed in parallel? My reading and exercises haven't shown >them to me yet. Maybe I just haven't gotten to the right chapter... How much hardware is in use where that would make a difference? If I understand how most cheap OS's (Solaris, BeOS, Linux) use the hardware, that low level of parallelization is not possible; you've got to go multitasking to go multiprocessor. -- David Starner - dstarner98@aasaa.ofe.org Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Dan Nagle 2000-03-30 0:00 ` David Starner @ 2000-03-30 0:00 ` Samuel T. Harris 2000-03-31 0:00 ` Gisle S�lensminde 1 sibling, 1 reply; 96+ messages in thread From: Samuel T. Harris @ 2000-03-30 0:00 UTC (permalink / raw) Dan Nagle wrote: > > Hello, > > >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< > > On 3/30/00, 1:03:19 PM, "Marin D. Condic" > <mcondic-nospam@quadruscorp.com> wrote regarding Re: Where is the > elusive jump command?: > > > Does Ada have any loop, branch or assignment statements, which, by > definition, > may be executed in parallel? My reading and exercises haven't shown > them to me yet. Maybe I just haven't gotten to the right chapter... Parallelization of language constructs is a function of the compiler. If a compiler is written for a high end parallel machine, then I expect it to produce parallel code for the basic stuff. Such a question might become a compiler requirement in the selection process. In any event, Ada provides parallel constructs both in the forms of tasks as well as the distributed systems annex. Both are powerful forms with standardized semantics upon which you can rely. I can produce parallel algorithms using tasks. If my compiler does not parallelize record assignments, then I can use tasks to parallelize the operation (at least logically). Of course, the degree to which a compiler takes advantage of multiple processors is also an implementation dependent issue, but you are more likely to score positive results across vendors on this question than with basic operations such as assignment. Since Ada already incorporates parallel constructs in the form of tasks and partitions, perhaps a later generation Ada will include keywords or pragmas which enable parallel operations on more basic syntactic structures like assignment. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Samuel T. Harris @ 2000-03-31 0:00 ` Gisle S�lensminde 0 siblings, 0 replies; 96+ messages in thread From: Gisle S�lensminde @ 2000-03-31 0:00 UTC (permalink / raw) In article <38E3CDF4.CF5450E2@Raytheon.com>, Samuel T. Harris wrote: >Dan Nagle wrote: >> >> Hello, >> >> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< >> >> On 3/30/00, 1:03:19 PM, "Marin D. Condic" >> <mcondic-nospam@quadruscorp.com> wrote regarding Re: Where is the >> elusive jump command?: >> >> >> Does Ada have any loop, branch or assignment statements, which, by >> definition, >> may be executed in parallel? My reading and exercises haven't shown >> them to me yet. Maybe I just haven't gotten to the right chapter... > >Parallelization of language constructs is a function of the compiler. >If a compiler is written for a high end parallel machine, then I >expect it to produce parallel code for the basic stuff. Such a question >might become a compiler requirement in the selection process. And typically the available parallelizing compilers have been fortran compilers, due to demand from those using these parallel machines. > >In any event, Ada provides parallel constructs both in the forms >of tasks as well as the distributed systems annex. Both are powerful >forms with standardized semantics upon which you can rely. >I can produce parallel algorithms using tasks. If my compiler does >not parallelize record assignments, then I can use tasks to >parallelize the operation (at least logically). Of course, the >degree to which a compiler takes advantage of multiple processors >is also an implementation dependent issue, but you are more likely >to score positive results across vendors on this question >than with basic operations such as assignment. > >Since Ada already incorporates parallel constructs in the form >of tasks and partitions, perhaps a later generation Ada will >include keywords or pragmas which enable parallel operations >on more basic syntactic structures like assignment. Much of the parallel code written in fortran and C uses libraries like MPI. These can be interfaced from Ada. Some machines can also use tasking/multithreading for parallel programs, and in this case Ada may be more easy to use than fortran/C. One of the good things with F90 is the array semantics where you can do arithmetric operations on 2-dimensional arrays, and the SIMD constructs. The array-syntax can be implemeted through operator overloading, but I have not seen any widely used libraries in Ada doing this, but I have not looked too hard, since I no longer do numeric programming. -- -- Gisle S�lensminde ( gisle@ii.uib.no ) ln -s /dev/null ~/.netscape/cookies ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Marin D. Condic ` (3 preceding siblings ...) 2000-03-30 0:00 ` Dan Nagle @ 2000-03-31 0:00 ` Gisle S�lensminde 2000-03-31 0:00 ` Tarjei T. Jensen 2000-03-31 0:00 ` Gautier 6 siblings, 0 replies; 96+ messages in thread From: Gisle S�lensminde @ 2000-03-31 0:00 UTC (permalink / raw) In article <38E396E7.45941282@quadruscorp.com>, Marin D. Condic wrote: >David Starner wrote: >> You might be surprised, though. The Comp Sci department still offers >> Fortran 77 (taught by the prof who was a graduate student when Fortran >> first appeared), and the Engineering Department forces all engineering >> students to take Fortran 90 (Intro to Engineering Programming). That CS >> Fortran class has more enrollment than the Ada class, too. >> >Aside from the fact that there is tons of Fortran code lying around >already, is there any reason why "number crunching" or >"scientific/engineering software" couldn't be taught/done in Ada? My >Fortran experience was back in the Fortran 77 days and I don't recall >anything being in the language that couldn't be done just as well - if >not better - in Ada95. (Especially given Ada's type capabilities and >precise definitions for math ops, numeric attributes, etc.) > >And if the only argument against it is the tons of existing math >libraries, then theres Ada's interface capability to argue in its favor. > >Its a market that could be tapped - and maybe one that isn't already >anti-Ada biased. Hmmmmmmmmm........ > The numerical capacities of f77 is no way better than those of Ada, but there are some realy agressive optimizing compilers producing very effective code. An example of this is the fortran compiler at HP/UX. There is no Ada frontend to this technology, and HP/UX is frequently used in engineering/numeric environments. Since many of the new f90 features was inefficient in the start, there where(is) evan a strong scepticism against f90. I have in fact worked with maintaining numeric code in f77, and my impression is that it's very hard to convince them to learn any new programming language, including f90, but there are some move towards C++, and I'm not sure that C++ is any better than f90 for numeric code. -- Gisle S�lensminde ( gisle@ii.uib.no ) ln -s /dev/null ~/.netscape/cookies ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Marin D. Condic ` (4 preceding siblings ...) 2000-03-31 0:00 ` Gisle S�lensminde @ 2000-03-31 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert A Duff 2000-03-31 0:00 ` Gautier 6 siblings, 1 reply; 96+ messages in thread From: Tarjei T. Jensen @ 2000-03-31 0:00 UTC (permalink / raw) Marin D. Condic wrote >And if the only argument against it is the tons of existing math >libraries, then theres Ada's interface capability to argue in its favor. > >Its a market that could be tapped - and maybe one that isn't already >anti-Ada biased. Hmmmmmmmmm........ The modula-2 compiler moca comes with a "compiler" which rewrites the source to readable C (the author claims). The kit used for this is cocktail. It should be possible to do the same for an fortran to Ada translator. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-31 0:00 ` Tarjei T. Jensen @ 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Stanley R. Allen 2000-04-13 0:00 ` Tarjei T. Jensen 0 siblings, 2 replies; 96+ messages in thread From: Robert A Duff @ 2000-04-12 0:00 UTC (permalink / raw) "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > Marin D. Condic wrote > >And if the only argument against it is the tons of existing math > >libraries, then theres Ada's interface capability to argue in its favor. > > > >Its a market that could be tapped - and maybe one that isn't already > >anti-Ada biased. Hmmmmmmmmm........ > > The modula-2 compiler moca comes with a "compiler" which rewrites the > source to readable C (the author claims). The kit used for this is > cocktail. > It should be possible to do the same for an fortran to Ada translator. But it's easier to translate a higher-level language into a lower-level language, than the other way around. - Bob ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-12 0:00 ` Robert A Duff @ 2000-04-12 0:00 ` Stanley R. Allen 2000-04-12 0:00 ` Samuel T. Harris 2000-04-15 0:00 ` Robert Dewar 2000-04-13 0:00 ` Tarjei T. Jensen 1 sibling, 2 replies; 96+ messages in thread From: Stanley R. Allen @ 2000-04-12 0:00 UTC (permalink / raw) Robert A Duff wrote: > > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > > > It should be possible to do the same for an fortran to Ada translator. > > But it's easier to translate a higher-level language into a lower-level > language, than the other way around. Not necessarily. Fortran->Ada is probably simpler than Ada->Fortran. -- Stanley Allen mailto:Stanley_R_Allen-NR@raytheon.com ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-12 0:00 ` Stanley R. Allen @ 2000-04-12 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Stanley R. Allen 2000-04-15 0:00 ` Robert Dewar 1 sibling, 1 reply; 96+ messages in thread From: Samuel T. Harris @ 2000-04-12 0:00 UTC (permalink / raw) "Stanley R. Allen" wrote: > > Robert A Duff wrote: > > > > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > > > > > It should be possible to do the same for an fortran to Ada translator. > > > > But it's easier to translate a higher-level language into a lower-level > > language, than the other way around. > > Not necessarily. Fortran->Ada is probably simpler than Ada->Fortran. > Well, having done this myself I have to say that Fortran -> Ada (at least Fortran 77 to Ada 83) was a substantial undertaking :) -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-12 0:00 ` Samuel T. Harris @ 2000-04-13 0:00 ` Stanley R. Allen 2000-04-14 0:00 ` Samuel T. Harris 2000-04-15 0:00 ` Robert Dewar 0 siblings, 2 replies; 96+ messages in thread From: Stanley R. Allen @ 2000-04-13 0:00 UTC (permalink / raw) "Samuel T. Harris" wrote: > > "Stanley R. Allen" wrote: > > > > > > Not necessarily. Fortran->Ada is probably simpler than Ada->Fortran. > > > > Well, having done this myself I have to say that Fortran -> Ada > (at least Fortran 77 to Ada 83) was a substantial undertaking :) > How much more substantial would it be to convert to Fortran an Ada program with tasking, dynamic memory allocation, exception handling, functions returning unconstrained arrays ... and that's just Ada 83. -- Stanley Allen mailto:Stanley_R_Allen-NR@raytheon.com ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-13 0:00 ` Stanley R. Allen @ 2000-04-14 0:00 ` Samuel T. Harris 2000-04-14 0:00 ` BASIC->Ada, was " tmoran 2000-04-15 0:00 ` Robert Dewar 1 sibling, 1 reply; 96+ messages in thread From: Samuel T. Harris @ 2000-04-14 0:00 UTC (permalink / raw) "Stanley R. Allen" wrote: > > "Samuel T. Harris" wrote: > > > > "Stanley R. Allen" wrote: > > > > > > > > > Not necessarily. Fortran->Ada is probably simpler than Ada->Fortran. > > > > > > > Well, having done this myself I have to say that Fortran -> Ada > > (at least Fortran 77 to Ada 83) was a substantial undertaking :) > > > > How much more substantial would it be to convert to Fortran an Ada > program with tasking, dynamic memory allocation, exception handling, > functions returning unconstrained arrays ... and that's just Ada 83. > I wasn't saying Fortran -> Ada was easier than Ada -> Fortran. I was saying Fortran -> Ada was hard enough. Since Intermetrics already does Ada -> C, then all you need is C -> Fortran to complete the circuit. That does seem to be much easier to me and Fortran -> Ada. -- Samuel T. Harris, Principal Engineer Raytheon, Aerospace Engineering Services "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 96+ messages in thread
* BASIC->Ada, was Re: Where is the elusive jump command? 2000-04-14 0:00 ` Samuel T. Harris @ 2000-04-14 0:00 ` tmoran 0 siblings, 0 replies; 96+ messages in thread From: tmoran @ 2000-04-14 0:00 UTC (permalink / raw) > How much more substantial would it be to convert to Fortran an Ada I'd like to convert a kid's BASIC programs to Ada, as part of converting him to Ada ;) Any conversion programs around? TI Calculator -> Ada would also be good. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-13 0:00 ` Stanley R. Allen 2000-04-14 0:00 ` Samuel T. Harris @ 2000-04-15 0:00 ` Robert Dewar 1 sibling, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <38F60987.B2D9702A@raytheon.com>, "Stanley R. Allen" <Stanley_R_Allen-NR@raytheon.com> wrote: > How much more substantial would it be to convert to Fortran an > Ada program with tasking, dynamic memory allocation, exception > handling, functions returning unconstrained arrays ... and > that's just Ada 83. Depends at what level. Have a look at the -gnatG output of GNAT, or for that matter the C output of the Averstar compiler. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-12 0:00 ` Stanley R. Allen 2000-04-12 0:00 ` Samuel T. Harris @ 2000-04-15 0:00 ` Robert Dewar 1 sibling, 0 replies; 96+ messages in thread From: Robert Dewar @ 2000-04-15 0:00 UTC (permalink / raw) In article <38F4F1FF.568BB924@raytheon.com>, "Stanley R. Allen" <Stanley_R_Allen-NR@raytheon.com> wrote: > Not necessarily. Fortran->Ada is probably simpler than > Ada->Fortran. Hard to say, the Fortran semantics of array passing, that specify the layout of arrays, and essentially require arrays to be passed as an address with no further typing information would be VERY hard to map to Ada without going to a horrible low level. For example, a Fortran routine that inverts a 2-d matrix can be called passing it a 1-d or 3-d matrix, or some peculiar contiguous section thereof. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Stanley R. Allen @ 2000-04-13 0:00 ` Tarjei T. Jensen 1 sibling, 0 replies; 96+ messages in thread From: Tarjei T. Jensen @ 2000-04-13 0:00 UTC (permalink / raw) Robert A Duff >> The modula-2 compiler moca comes with a "compiler" which rewrites the >> source to readable C (the author claims). The kit used for this is >> cocktail. >> It should be possible to do the same for an fortran to Ada translator. > >But it's easier to translate a higher-level language into a lower-level >language, than the other way around. The point with moca and the reason for the pride of the author was that the program was re-written in another language without loosing readability. It was a matter of translation instead of compilation if I should put a name on the process. This means that there is prior art with regards to translating from a language to another and keeping the result readable. I suspect that it is easier to do this for fortran to ada than from c/c++ to ada. Anybody interested should inspect the moca compiler and the cocktail kit to decide for themselves whether the author is right about his claim. Greetings, ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-30 0:00 ` Marin D. Condic ` (5 preceding siblings ...) 2000-03-31 0:00 ` Tarjei T. Jensen @ 2000-03-31 0:00 ` Gautier 6 siblings, 0 replies; 96+ messages in thread From: Gautier @ 2000-03-31 0:00 UTC (permalink / raw) "Marin D. Condic" wrote: > Aside from the fact that there is tons of Fortran code lying around > already, is there any reason why "number crunching" or > "scientific/engineering software" couldn't be taught/done in Ada? My > Fortran experience was back in the Fortran 77 days and I don't recall > anything being in the language that couldn't be done just as well - if > not better - in Ada95. (Especially given Ada's type capabilities and > precise definitions for math ops, numeric attributes, etc.) Even Ada 83 is a better choice than Fortran for scientific software (experience using DEC Ada). The interfacing with LAPACK is easy, the time spared due to strong typing is unvaluable (~1 year in my thesis project so far). A "small" separate program for solving a nonlinear equation with a special finite element method took less than 3 hours last week to write from A to Z and pass the compilation phase that cleared tens of bugs only an Ada compiler can catch. Once passed, the program worked (the right results!). This is an almost miraculous case but would I have programmed the same in Fortran, I would be still searching bugs now (which number, which coefficient, where, error in the calculations to prepare the method ? etc. etc.). About the numeric attributes: they are effectively a plus e.g. for portable iterative methods. (float'epsilon etc.) _____________________________________________ Gautier -- http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-29 0:00 ` Marin D. Condic 2000-03-29 0:00 ` Gary Scott @ 2000-03-30 0:00 ` Alfred Hilscher 1 sibling, 0 replies; 96+ messages in thread From: Alfred Hilscher @ 2000-03-30 0:00 UTC (permalink / raw) "Marin D. Condic" wrote: > We do have to be careful not to confuse the newbies. We should try to > emphasize The Ada Way of programming. I just think we'll win a few more > converts by being willing to say "Yeah, you can do exactly what you > usually do in language X and here's how. But there is a *better* way to > consider that will make your life easier." I totally agree. I'm often told by coleaques "Uuuuhhh, in C/C++/Fortran/Basic... I can do ... When I can't do it in Ada I will not change". Tell them what they want hear, but always show the (better) alternative. Manipulate them until they do it the right way and then let they think that it was their own idea to make it the better way. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Where is the elusive jump command? @ 2000-03-21 0:00 dis90072 2000-03-21 0:00 ` Preben Randhol 0 siblings, 1 reply; 96+ messages in thread From: dis90072 @ 2000-03-21 0:00 UTC (permalink / raw) Having learned ada for the past six months, I have found no reference to the 'jump' command. In MSDOS you can use the 'goto' command. Even in damn assembler you can jump. What is the equivalent in ada? I have had enough of endless 'IF' statements and everlasting case statements. I know it might make the program hard to follow, but I don't care! I must have it! Please......! Regards, Matt. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-21 0:00 dis90072 @ 2000-03-21 0:00 ` Preben Randhol 2000-03-30 0:00 ` Alfred Hilscher 0 siblings, 1 reply; 96+ messages in thread From: Preben Randhol @ 2000-03-21 0:00 UTC (permalink / raw) On Tue, 21 Mar 2000 12:57:13 +0000, dis90072 wrote: >damn assembler you can jump. What is the equivalent in ada? I have had >enough of endless 'IF' statements and everlasting case statements. I >know it might make the program hard to follow, but I don't care! I must In stead of the goto (or jump) command you should redesign your program and use more procedures/functions/pacakges. -- Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/> "Det eneste trygge stedet i verden er inne i en fortelling." -- Athol Fugard ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Where is the elusive jump command? 2000-03-21 0:00 ` Preben Randhol @ 2000-03-30 0:00 ` Alfred Hilscher 0 siblings, 0 replies; 96+ messages in thread From: Alfred Hilscher @ 2000-03-30 0:00 UTC (permalink / raw) (Take it not serious) Use EXCEPTIONS for this purpose. Define a standard exception called "SPAGETTI_CODE" and raise it every time you want go to ;-)) Preben Randhol wrote: > > On Tue, 21 Mar 2000 12:57:13 +0000, dis90072 wrote: > >damn assembler you can jump. What is the equivalent in ada? I have had > >enough of endless 'IF' statements and everlasting case statements. I > >know it might make the program hard to follow, but I don't care! I must > > In stead of the goto (or jump) command you should redesign your program > and use more procedures/functions/pacakges. > > -- > Preben Randhol -- [randhol@pvv.org] -- <http://www.pvv.org/~randhol/> > "Det eneste trygge stedet i verden er inne i en fortelling." > -- Athol Fugard ^ permalink raw reply [flat|nested] 96+ messages in thread
end of thread, other threads:[~2000-04-18 0:00 UTC | newest] Thread overview: 96+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-21 0:00 Where is the elusive jump command? dis90072 2000-03-21 0:00 ` Nicolas Brunot 2000-03-21 0:00 ` Stanley R. Allen 2000-03-21 0:00 ` Nicolas Brunot 2000-03-27 0:00 ` Robert A Duff 2000-03-28 0:00 ` Dale Stanbrough 2000-03-28 0:00 ` Ken Garlington 2000-03-28 0:00 ` Robert Dewar 2000-03-28 0:00 ` Ken Garlington 2000-03-28 0:00 ` Marin D. Condic 2000-03-28 0:00 ` Robert Dewar 2000-03-29 0:00 ` Richard D Riehle 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Alfred Hilscher 2000-04-01 0:00 ` Robert Dewar 2000-04-04 0:00 ` Alfred Hilscher 2000-04-05 0:00 ` Ole-Hjalmar Kristensen 2000-04-05 0:00 ` Larry Kilgallen 2000-04-06 0:00 ` Ole-Hjalmar Kristensen 2000-04-06 0:00 ` OS Bindings (was: Where is the elusive jump command?) Larry Kilgallen 2000-04-06 0:00 ` Robert Dewar 2000-04-07 0:00 ` Tarjei T. Jensen 2000-04-09 0:00 ` Robert Dewar 2000-04-10 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Robert Dewar 2000-04-12 0:00 ` Robert A Duff 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Gisle S�lensminde 2000-04-15 0:00 ` Robert Dewar 2000-04-13 0:00 ` Tarjei T. Jensen 2000-04-13 0:00 ` Gisle S�lensminde 2000-04-12 0:00 ` Florian Weimer 2000-04-13 0:00 ` Tarjei T. Jensen 2000-04-13 0:00 ` Robert A Duff 2000-04-18 0:00 ` Tarjei T. Jensen 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert Dewar 2000-04-13 0:00 ` Tarjei T. Jensen 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Tarjei T. Jensen [not found] ` <eisner comp.lang.ada:53670> 2000-04-06 0:00 ` Larry Kilgallen 2000-04-06 0:00 ` Robert Dewar 2000-04-08 0:00 ` nickerson 2000-04-09 0:00 ` Robert Dewar 2000-04-06 0:00 ` Ole-Hjalmar Kristensen 2000-03-30 0:00 ` Where is the elusive jump command? Richard D Riehle 2000-04-01 0:00 ` Robert A Duff 2000-04-02 0:00 ` Robert Dewar 2000-04-02 0:00 ` Richard D Riehle 2000-04-02 0:00 ` Robert Dewar 2000-04-02 0:00 ` Robert Dewar 2000-03-29 0:00 ` Marin D. Condic 2000-03-29 0:00 ` Gary Scott 2000-03-29 0:00 ` Robert Dewar 2000-03-30 0:00 ` Gary Scott 2000-03-30 0:00 ` Gautier 2000-03-30 0:00 ` Gary Scott 2000-03-30 0:00 ` David Starner 2000-03-30 0:00 ` William B. Clodius 2000-03-30 0:00 ` Gautier 2000-03-30 0:00 ` David Starner 2000-03-30 0:00 ` Marin D. Condic 2000-03-30 0:00 ` Samuel T. Harris 2000-03-30 0:00 ` Gary Scott 2000-03-31 0:00 ` Tarjei T. Jensen 2000-03-31 0:00 ` Larry Kilgallen 2000-03-31 0:00 ` Gary Scott 2000-03-30 0:00 ` Larry Kilgallen 2000-03-30 0:00 ` Dan Nagle 2000-03-30 0:00 ` David Starner 2000-03-30 0:00 ` Samuel T. Harris 2000-03-31 0:00 ` Gisle S�lensminde 2000-03-31 0:00 ` Gisle S�lensminde 2000-03-31 0:00 ` Tarjei T. Jensen 2000-04-12 0:00 ` Robert A Duff 2000-04-12 0:00 ` Stanley R. Allen 2000-04-12 0:00 ` Samuel T. Harris 2000-04-13 0:00 ` Stanley R. Allen 2000-04-14 0:00 ` Samuel T. Harris 2000-04-14 0:00 ` BASIC->Ada, was " tmoran 2000-04-15 0:00 ` Robert Dewar 2000-04-15 0:00 ` Robert Dewar 2000-04-13 0:00 ` Tarjei T. Jensen 2000-03-31 0:00 ` Gautier 2000-03-30 0:00 ` Alfred Hilscher -- strict thread matches above, loose matches on Subject: below -- 2000-03-21 0:00 dis90072 2000-03-21 0:00 ` Preben Randhol 2000-03-30 0:00 ` Alfred Hilscher
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox