Where is the elusive jump command?

Where is the elusive jump command?

[dis90072]

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.

Re: Where is the elusive jump command?

[Nicolas Brunot]

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.

Re: Where is the elusive jump command?

[Stanley R. Allen]

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

Re: Where is the elusive jump command?

[Nicolas Brunot]

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.

Re: Where is the elusive jump command?

[Robert A Duff]

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

Re: Where is the elusive jump command?

[Dale Stanbrough]

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

Re: Where is the elusive jump command?

[Ken Garlington]

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

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Ken Garlington]

"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.

Re: Where is the elusive jump command?

[Marin D. Condic]

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. 
=============================================================

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Richard D Riehle]

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
 

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Richard D Riehle]

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

Re: Where is the elusive jump command?

[Robert A Duff]

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

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Richard D Riehle]

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


 

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Alfred Hilscher]

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.

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Alfred Hilscher]

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.

Re: Where is the elusive jump command?

[Ole-Hjalmar Kristensen]

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

Re: Where is the elusive jump command?

[Larry Kilgallen]

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 ?

Re: Where is the elusive jump command?

[Ole-Hjalmar Kristensen]

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

OS Bindings (was: Where is the elusive jump command?)

[Larry Kilgallen]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert A Duff]

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

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert A Duff]

"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

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert A Duff]

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

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Gisle S�lensminde]

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

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Gisle S�lensminde]

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

Re: OS Bindings (was: Where is the elusive jump command?)

[Florian Weimer]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert A Duff]

"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

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Tarjei T. Jensen]

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,

Re: OS Bindings (was: Where is the elusive jump command?)

[Larry Kilgallen]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[nickerson]

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

Re: OS Bindings (was: Where is the elusive jump command?)

[Robert Dewar]

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.

Re: OS Bindings (was: Where is the elusive jump command?)

[Ole-Hjalmar Kristensen]

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

Re: Where is the elusive jump command?

[Marin D. Condic]

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. 
=============================================================

Re: Where is the elusive jump command?

[Gary Scott]

"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.

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Gautier]

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

Re: Where is the elusive jump command?

[Gary Scott]

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

Re: Where is the elusive jump command?

[Gautier]

> 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/

Re: Where is the elusive jump command?

[David Starner]

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

Re: Where is the elusive jump command?

[William B. Clodius]

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.

Re: Where is the elusive jump command?

[David Starner]

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

Re: Where is the elusive jump command?

[Marin D. Condic]

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. 
=============================================================

Re: Where is the elusive jump command?

[Larry Kilgallen]

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.

Re: Where is the elusive jump command?

[Dan Nagle]

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

Re: Where is the elusive jump command?

[David Starner]

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

Re: Where is the elusive jump command?

[Samuel T. Harris]

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!"

Re: Where is the elusive jump command?

[Gisle S�lensminde]

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

Re: Where is the elusive jump command?

[Samuel T. Harris]

"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!"

Re: Where is the elusive jump command?

[Gary Scott]

"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.
> =============================================================

Re: Where is the elusive jump command?

[Tarjei T. Jensen]

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,

Re: Where is the elusive jump command?

[Larry Kilgallen]

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.

Re: Where is the elusive jump command?

[Gary Scott]

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.

Re: Where is the elusive jump command?

[Gautier]

"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/

Re: Where is the elusive jump command?

[Gisle S�lensminde]

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

Re: Where is the elusive jump command?

[Tarjei T. Jensen]

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,

Re: Where is the elusive jump command?

[Robert A Duff]

"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

Re: Where is the elusive jump command?

[Stanley R. Allen]

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

Re: Where is the elusive jump command?

[Samuel T. Harris]

"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!"

Re: Where is the elusive jump command?

[Stanley R. Allen]

"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

Re: Where is the elusive jump command?

[Samuel T. Harris]

"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!"

BASIC->Ada, was Re: Where is the elusive jump command?

[tmoran]

> 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.

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Robert Dewar]

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.

Re: Where is the elusive jump command?

[Tarjei T. Jensen]

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,

Re: Where is the elusive jump command?

[Gary Scott]

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

Re: Where is the elusive jump command?

[Alfred Hilscher]

"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.

Where is the elusive jump command?

[dis90072]

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.

Re: Where is the elusive jump command?

[Preben Randhol]

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

Re: Where is the elusive jump command?

[Alfred Hilscher]

(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