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?

[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

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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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 <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?

[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?

[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

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?

[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?

[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?

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

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?

[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?

[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?

[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 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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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

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?

[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?

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

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?

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