* Re: Least Dangerous Way to Do This ?
2018-10-17 0:09 7% ` patrick
@ 2018-10-17 20:49 7% ` Shark8
0 siblings, 0 replies; 35+ results
From: Shark8 @ 2018-10-17 20:49 UTC (permalink / raw)
On Tuesday, October 16, 2018 at 6:09:49 PM UTC-6, pat...@spellingbeewinnars.org wrote:
> Hi Shark8
>
> I am actually pretty familiar with the interface to cobol package. I actually don't trust it. I am thinking about trying to improve it but in it's current condition, it could be a liability.
>
> So Ada83 was pretty cool already but if we had Ada68 or Ada78 they would have sucked large. COBOL68 and COBOL73 suck and the language is still haunted by criticism from this time.
>
> When I first started with GnuCOBOL(called Open-Cobol at the time) I thought it was awesome and that the critics must all be insane and then I saw code from 68 and 73 revisions. One program(like a procedure) was almost 10000 lines long. All identifiers were limited to 8 characters. There was not a single comment in it. So yes old COBOL is terrible. The thing is that the interfaces cobol package appears to be for this old code and not the current stuff.
Interesting.
>
> In COBOL we have pointers, procedures(called programs) and functions. The spec file in the interfaces cobol package makes all kinds of false statements.
I'm rather looking forward to seeing your improved COBOL interface.
(We might even be able to replace Interfaces.COBOL, or perhaps add a new child-package like Interfaces.COBOL.ISO_1989_2014.)
>
> GnuCOBOL generates intermediate C, so I can inspect it and see what is happening. At the moment I am better off with the interfaces C package.
Hm, are you going to use that as a bit of a feedback-loop in your design of a [new] COBOL interfacing package?
> I have wondered the same thing. People can write very reliable COBOL code but there are some topics related to calling other procedures(programs) that could be a concern for the most critical portions, this is where Ada would really shine in banking, yet it doesn't.
>
>
> Ada has much better facilities for organizing huge amounts of code yet COBOL likely has far larger code bases. I think one bank has something like 130 million lines of COBOL, I could borrow the library book I read this in, to get the exact amount if your interested but the point is that organizing this much code in COBOL is very hard.
Indeed, and code-organization is one area that Ada really shines [IMO].
>
> I hope you don't mind a bit of a rant but I think Ada has serious-serious advocacy issues. Adacore has done a horrible job and we could improve more as a community too. Catering to existing Adacore customers does not move the language forward. Adacore did not move to microcontrollers for the longest time and it has staff that go around telling people not to use Ada for webservers or telephony systems when this would actually be good things to do and so on.
I'm not bothered by your rant -- it actually mirrors a lot of the criticisms the Ada-community as-a-whole has. While I'm glad that AdaCore has interests in Ada, and does some good work, there are some big problems that "only one [viable, opensource] implementation" entails which isn't good for the language as-a-whole.
>
> Books are terrible. You can read hundreds and hundreds of pages were all that is being demonstrated is some language feature you are never going to use and text_io displaying something. I have 53lbs of Ada books(and counting) and in all this I think I have 2 or 3 pages that deal with interfacing with real hardware and there is next to no information about interfacing with other languages. How many new application these days are going to be in pure Ada, it's crazy to cover features from Ada2005 and Ada2012 and not providing any examples of interfacing with other languages. What are you actually going to do with interfaces in a new code base that has no contact with other languages ? isn't it more important to understand procedures, function and packages and how to use Ada with other languages?
Interesting critique.
I've heard it said that the problem is that there's no "entry/introductory level" books, rather than books as-a-whole.
>
> Today is a special day for me. I realized something super-awesome about Ada that no one told me about and that I did not read about and this really should not have happened. It's so simple in hindsight but I didn't realize that you could use Ada packages with other languages without "with"ing them into an Ada program. I patched byteswap with pragma export and called it from COBOL. I can now use an Ada library directly from COBOL without writing any Ada code. Fortran and C people could do the same, with some simple patching.
Hm?
Are you referring to simply compiling a package and linking to the resultant OBJ file? Or am I misunderstanding you?
> Please see this site(it is a lot of material on one page and can be slow to load):
> https://open-cobol.sourceforge.io/faq/index.html
>
> This will give a good overview of the language. There is a small part that touches on Ada. However look at this code, it's almost all using C libraries. GnuCOBOL has lots of facilities for interfacing with C, especially matching types but we still have to jump though some hoops such as appending nul bytes and so on.
Interesting, I'll take a look.
>
> I am planning on patching as many Ada libraries as I can so that they can be used from GnuCOBOL. There is so much functionality that we don't have in our community. Imagine if this ends up being used by existing COBOL code bases... Maybe even banks will see the value if I can do this, I write up lots of documentation and I can actually try to promote these concepts.
>
I, for one, would love to see this.
There's a lot of value to be had here: keeping your main-system organized, proven (where possible), and ensuring that your main reporting/processing isn't being handed garbage is a big win.
> If one company is entrusted to promote Ada and all they want to do is service existing customers, the language will die out when there old customers finally switch to C++/Java etc..
Yep.
This is a big problem, in part because existing customers develop work-arounds for flaws and issues that they never voice (that's just how things are), whereas new customers will have different needs and ideas [and expectations] which often at least shed some light on issues.
>
> There is so much to promote and so much value to be had but Ada instruction books and Adacore are not going to get the word out, we need to !
I try.
^ permalink raw reply [relevance 7%]
* Re: Least Dangerous Way to Do This ?
2018-10-16 16:07 7% ` Shark8
@ 2018-10-17 0:09 7% ` patrick
2018-10-17 20:49 7% ` Shark8
0 siblings, 1 reply; 35+ results
From: patrick @ 2018-10-17 0:09 UTC (permalink / raw)
Hi Shark8
I am actually pretty familiar with the interface to cobol package. I actually don't trust it. I am thinking about trying to improve it but in it's current condition, it could be a liability.
So Ada83 was pretty cool already but if we had Ada68 or Ada78 they would have sucked large. COBOL68 and COBOL73 suck and the language is still haunted by criticism from this time.
When I first started with GnuCOBOL(called Open-Cobol at the time) I thought it was awesome and that the critics must all be insane and then I saw code from 68 and 73 revisions. One program(like a procedure) was almost 10000 lines long. All identifiers were limited to 8 characters. There was not a single comment in it. So yes old COBOL is terrible. The thing is that the interfaces cobol package appears to be for this old code and not the current stuff.
In COBOL we have pointers, procedures(called programs) and functions. The spec file in the interfaces cobol package makes all kinds of false statements.
GnuCOBOL generates intermediate C, so I can inspect it and see what is happening. At the moment I am better off with the interfaces C package.
I have wondered the same thing. People can write very reliable COBOL code but there are some topics related to calling other procedures(programs) that could be a concern for the most critical portions, this is where Ada would really shine in banking, yet it doesn't.
Ada has much better facilities for organizing huge amounts of code yet COBOL likely has far larger code bases. I think one bank has something like 130 million lines of COBOL, I could borrow the library book I read this in, to get the exact amount if your interested but the point is that organizing this much code in COBOL is very hard.
I hope you don't mind a bit of a rant but I think Ada has serious-serious advocacy issues. Adacore has done a horrible job and we could improve more as a community too. Catering to existing Adacore customers does not move the language forward. Adacore did not move to microcontrollers for the longest time and it has staff that go around telling people not to use Ada for webservers or telephony systems when this would actually be good things to do and so on.
People using Ada for fun like on AVRs and on the Raspberry Pi are doing good work. We really need to show people what can be done with it and done with it for fun.
Books are terrible. You can read hundreds and hundreds of pages were all that is being demonstrated is some language feature you are never going to use and text_io displaying something. I have 53lbs of Ada books(and counting) and in all this I think I have 2 or 3 pages that deal with interfacing with real hardware and there is next to no information about interfacing with other languages. How many new application these days are going to be in pure Ada, it's crazy to cover features from Ada2005 and Ada2012 and not providing any examples of interfacing with other languages. What are you actually going to do with interfaces in a new code base that has no contact with other languages ? isn't it more important to understand procedures, function and packages and how to use Ada with other languages?
Today is a special day for me. I realized something super-awesome about Ada that no one told me about and that I did not read about and this really should not have happened. It's so simple in hindsight but I didn't realize that you could use Ada packages with other languages without "with"ing them into an Ada program. I patched byteswap with pragma export and called it from COBOL. I can now use an Ada library directly from COBOL without writing any Ada code. Fortran and C people could do the same, with some simple patching.
So I can't verify that any of this is true but according to MicroFocus, a company with a vested interest in COBOL(and that sued a city here in Canada for having too many copies of their software) the cost to replace COBOL in the USA would be over 1 trillion. They say that there is hundreds of billions of lines of code in use. Others have said that there is more COBOL code than all other languages combined. Again, I am not saying that all of this is true, it could be fanboy propaganda but certainly there is mountains of it.
Please see this site(it is a lot of material on one page and can be slow to load):
https://open-cobol.sourceforge.io/faq/index.html
This will give a good overview of the language. There is a small part that touches on Ada. However look at this code, it's almost all using C libraries. GnuCOBOL has lots of facilities for interfacing with C, especially matching types but we still have to jump though some hoops such as appending nul bytes and so on.
Ada and COBOL are much closer then COBOL and C and Ada has tons of facilities for working with other languages, such as it's type system and strings.fixed to match COBOL's and so on, they are just poorly documented.
I am planning on patching as many Ada libraries as I can so that they can be used from GnuCOBOL. There is so much functionality that we don't have in our community. Imagine if this ends up being used by existing COBOL code bases... Maybe even banks will see the value if I can do this, I write up lots of documentation and I can actually try to promote these concepts.
If one company is entrusted to promote Ada and all they want to do is service existing customers, the language will die out when there old customers finally switch to C++/Java etc..
There is so much to promote and so much value to be had but Ada instruction books and Adacore are not going to get the word out, we need to !
^ permalink raw reply [relevance 7%]
* Re: Least Dangerous Way to Do This ?
@ 2018-10-16 16:07 7% ` Shark8
2018-10-17 0:09 7% ` patrick
0 siblings, 1 reply; 35+ results
From: Shark8 @ 2018-10-16 16:07 UTC (permalink / raw)
On Monday, October 15, 2018 at 1:36:09 PM UTC-6, pat...@spellingbeewinnars.org wrote:
> Okay, I worked through the last piece. You know what I am doing.....
>
> I am thinking about using the Ada.XXX and Gnat.XXX libraries from GnuCOBOL !
>
> Hee-hee, I know COBOL isn't going to have a lot of fans here but it is actually a lot of fun.
Ada has a whole section in Annex B for interfacing to COBOL -- "B.4 Interfacing with COBOL" -- online here: http://www.ada-auth.org/standards/2xrm/html/RM-B-4.html
Exporting to COBOL will be as easy as saying:
Function J return Integer
with Export, Convention => COBOL;
And Importing is similar:
Function K return Interfaces.COBOL.Floating
with Import, Convention => COBOL;
Actually given Ada's ease with interfacing like this, and the SPARK provers, I'm surprised that the banking industry hasn't leveraged Ada into its infrastructure, using Ada to prove the correctness of the system and COBOL for the fast reporting/record-processing as-needed.
>
> I will post back with some examples just in case someone cares :)
I think that would be pretty cool.
^ permalink raw reply [relevance 7%]
* Re: Is this Forum Moderated?
@ 2018-05-20 15:18 6% ` patrick
0 siblings, 0 replies; 35+ results
From: patrick @ 2018-05-20 15:18 UTC (permalink / raw)
Hi Shark8 !
"I have had the idea, for a while, that banks & insurance companies & other financial institutions could see a lot of improvement WRT modernization with mixed Ada/COBOL programs; in particular doing the report-generation in COBOL and the main "business logic" in Ada (with heavy usage of types to ensure correctness) instead of the [seemingly] more popular "PORT IT TO JAVA" that I've seen some people advocate.
What are your thoughts? "
I think whenever we bring up another language besides Ada we are going to get negative posts but I am putting on my helmet and body armor now.....
It took me many years to build up the confidence to look at languages with my own eyes and to ignore the hype. It brought me to Ada and to COBOL as well.
There is actually a great deal of overlap between two in terms of functionality.
IMHO Ada is best suited as the "main" with COBOL as library code. GnuCOBOL is not thread safe and should be in it's own task. If you can manage with an ncurses interface, the screen section in COBOL is great.
I would recommend to leave whatever business logic you can in COBOL and to use Ada's strengths of programming in the large, exceptions and tasking.
GnuCOBOL has a small runtime that is much easier to alter than GNAT's. I have made modifications to the screen section to allow for idle calls backs, 256 colour support and mouse support.
The GnuCOBOL list is very approachable and tightly moderated. You won't get any RTFM like posts. It's a second home to me now.
I have test code to interface the two and I would love to help you. I don't use interfaces.cobol. COBOL already has lots of types ready for use with C and they are compatible with Ada too. strings.fixed and the built-in strings work great. GnuCOBOL just added report writer support this January and I am pretty familiar with it too.
COBOL is haunted with criticism from the past. I have seen COBOL 1968 and 1974 vintage code and it sucks large. The COBOL 85 revision made it an awesome language. I am not crazy about the 2002 revisions but just so you know, you don't have to obey a rigid layout with the 2002 revision. You can pass the -free flag to the compiler and whitespace becomes insensitive, you can use uppercase or lowercase and identifers can be 30 characters long or even longer if you wish.
GnuCOBOL compiles to intermediate C and the generated code is easy to read once you get the hang of it. The project uses pretty standard libraries like GMP, libtool and ncurses. The compiler is Bison/Flex.The licensing arrangement is also a bit complicated like the GNAT situation but basically you can use the default settings which will link in libdb and force AGPL code or you can use an older libdb version for GPL code or you can use an external library called libvbism and you can have a LGPL runtime suitable for linking to you preferred license.
Where is Byron? I would like to check it out.
Thanks-Pat
^ permalink raw reply [relevance 6%]
* Re: Please evaluate tiny binding that does not use Interfaces.C
@ 2017-08-18 13:05 6% ` patrick
0 siblings, 0 replies; 35+ results
From: patrick @ 2017-08-18 13:05 UTC (permalink / raw)
Hi Per
Thanks for answering my post!
Do you like friendly debates? If we were in the same room you would see that I have a smile on my face and I am not trying to be argumentative or hostile in any way, it's just that I seem to be thinking differently then most Ada people right now and I would love to have my sanity checked. Please don't be offended by this, please help me test my logic......
Here is some background.
I bought/printed 53 lbs of Ada books in 2012. I studied every night. I basically failed. I wanted to use Ada instead of C but every where i turned I needed a binding to C. GTK-Ada was very confusing and I struggled badly with it and eventually gave up on Ada.
I actually went to GnuCOBOL(call open-cobol as the time). I loved it and still do. I learned a lot more about C and I have had a great time mixing GnuCOBOL and C.
I have come back to Ada a few times. I used Interfaces.COBOL. I can use it well but the code required to blend COBOL and Ada is IMHO as gross as the code to mix C and Ada, when using Intefaces.C.
I have read extensively about Interfaces.C and Interfaces.C. Most examples will use some simple C target. In reality people will often want to interface with massive C/C++ libraries.
I know it would be nice if all Ada bindings were thick but is it not in fact fair to say that most are thin, we don't have large communities to support them and to look for bugs, we don't have many bindings relative to let's say Python and writing good Ada bindings is non-trivial to begin with.
My feeling right now is that the expertise needed to use bindings like GTK-Ada is of such a high degree that the programmer might just be better off studying C and writing shim code to that C and binding to it or directly to the C library on an as-needed basis rather then trying to write a whole binding to share with the community.
I am really sorry for writing the above, I know how hard it is to write a binding and I don't want to discourage people but I think it's also important to speak honestly about the language, I think lots of people stop by to see what it's about but move on. I think if it was easier to interface with other languages, Ada could start off as library code to support other languages at first and then could win over people's hearts and become more central or in fact "the" central language of the given application.
With the approach taken above, I am sure I can interface with COBOL without having actually tried this but what about other ELF compatible languages from GCC or elsewhere, this would open the door to interfacing with Java and Objective-C. Lots of languages have C interfaces or compile to intermediate C. Ada could be mixed with Haskell, Vala or dozens more.
I remember back in 2012 being to desperate to have -fdump-ada-spec that I switched distros. I remember using it inn stupid ways, like running it on the whole C library not just the header and trying to bind to internal functions and such.
In almost all cases Interfaces.C isn't doing anything but to someone that was struggling like I was, it adds a layer of magic that hides a much simpler truth.
I also question -fdump's decisions. As per the first post, why recreate a C struct and all of it's nested structs only to create a pointer of the correct type? Yes void pointers are dangerous but mountains of code that do not need to be there is also dangerous.
Simple short code is easier to debug and maintain and a lack of maintenance or worse yet, a poor understanding of code is IMHO worse than the danger of a void pointer.
Why use Interfaces.X if Ada already has the built in types to interface. Having to cast back and forth only makes for more code and less code clarity and at the end of the day, we are still calling into C and more code to check for actual C dangers seems like a better idea to me than using Interfaces.X which offers no protection anyways.
Thanks for reading
^ permalink raw reply [relevance 6%]
* Re: Advice, tasking and hardware
2016-05-25 21:24 5% Advice, tasking and hardware patrick
@ 2016-05-26 1:09 0% ` Jeffrey R. Carter
0 siblings, 0 replies; 35+ results
From: Jeffrey R. Carter @ 2016-05-26 1:09 UTC (permalink / raw)
On 05/25/2016 02:24 PM, patrick@spellingbeewinnars.org wrote:
>
> I struggled to find a GUI binding I liked and I struggled to work with C. I
> wanted to use Ada to avoid using C and I didn't understand C well.
>
> For the past few years I have been using GnuCOBOL. I absolutely love it. It
> is much easier to interface to C with and it compiles to intermediate C so
> it's easier to see what is happening rather then going from Ada to Assembly.
> While the interfaces.COBOL package is quite outdated and does not have
> knowledge of modern COBOL it does work well and I can mix the two languages.
I'm not sure what you're getting at here. A compiler's intermediate code is
usually of no interest to a developer. I've done more interfacing to C from Ada
than I'd like, and it's usually straightforward.
> I don't have any experience with tasking though and while I have many
> examples of tasking in my books, none of them seem to call low level
> functions such as drivers or driver-like functions. I am planning on using
> the Linux-GPIB library.
Every call to a subprogram in Ada, be it high-level or low-level, is made by a
task. The elaboration and the the main-program subprogram are executed by the
environment task. Any subprogram calls made, directly or indirectly, by the main
program are made by the environment task. I see no reason why you should expect
calls from user-defined tasks to be any different.
> Spark doesn't use tasking, are there many dangers in using tasking with
> hardware?
SPARK 2014 includes Ravenscar tasking.
(http://docs.adacore.com/spark2014-docs/html/lrm/tasks-and-synchronization.html)
I don't know how you'd use tasking without hardware. Concurrent development is a
superset of sequential development, and some who are competent at the latter
have difficulty with the former, even after extensive experience. Deadlock and
race conditions are common dangers if you don't understand concurrency (and
sometimes if you do).
> Would it be wise to wrap C driver calls in a protected object or are most
> drivers in Linux thread safe and suitable for being called from different
> threads?
That will depend on the library you're binding to, and you should refer to its
documentation. If in doubt, wrapping the calls in a PO will ensure they are made
sequentially.
--
Jeff Carter
"He didn't get that nose from playing ping-pong."
Never Give a Sucker an Even Break
110
^ permalink raw reply [relevance 0%]
* Advice, tasking and hardware
@ 2016-05-25 21:24 5% patrick
2016-05-26 1:09 0% ` Jeffrey R. Carter
0 siblings, 1 reply; 35+ results
From: patrick @ 2016-05-25 21:24 UTC (permalink / raw)
Hi Everyone
I don't want to troll the list, I need some honest advice and I need to be honest about my goals, I hope I don't offend anyone.
I spent almost every night in 2012 studying Ada. I bought/printed 53 lbs of Ada books.
I struggled to find a GUI binding I liked and I struggled to work with C. I wanted to use Ada to avoid using C and I didn't understand C well.
For the past few years I have been using GnuCOBOL. I absolutely love it. It is much easier to interface to C with and it compiles to intermediate C so it's easier to see what is happening rather then going from Ada to Assembly. While the interfaces.COBOL package is quite outdated and does not have knowledge of modern COBOL it does work well and I can mix the two languages.
I am thinking about writing a backend in Ada again. I could do it in COBOL but tasking and exceptions sound like a wise idea. I feel I am going to have an easier time with C this time around.
I don't have any experience with tasking though and while I have many examples of tasking in my books, none of them seem to call low level functions such as drivers or driver-like functions. I am planning on using the Linux-GPIB library.
Sorry for the long introduction, to the point...
Do you have any examples of tasking calling low level functions?
Spark doesn't use tasking, are there many dangers in using tasking with hardware?
Would it be wise to wrap C driver calls in a protected object or are most drivers in Linux thread safe and suitable for being called from different threads?
Could anyone give me some general guidelines? any pitfalls to avoid before I set out to attempt this?
Thanks for reading-Patrick
^ permalink raw reply [relevance 5%]
* Re: Ada noob here! Is Ada widely used?
2010-06-05 7:47 6% ` Georg Bauhaus
@ 2010-06-05 22:43 0% ` starwars
0 siblings, 0 replies; 35+ results
From: starwars @ 2010-06-05 22:43 UTC (permalink / raw)
> How do Interfaces.COBOL and Ada.Text_IO.Editing fit in here?
The support is there to do the work, it's just much harder and uglier to do
in Ada than COBOL. COBOL has built-in types for money and editing (COMP-3)
but in Ada you have to have the Data Processing Annex and unfortunately
many toolchains don't offer it. Even with the support, it's painful to do
financial reporting on a large scale in Ada. COBOL wins here. It should, it
was designed specifically for this above all else.
^ permalink raw reply [relevance 0%]
* Re: Ada noob here! Is Ada widely used?
@ 2010-06-05 7:47 6% ` Georg Bauhaus
2010-06-05 22:43 0% ` starwars
0 siblings, 1 reply; 35+ results
From: Georg Bauhaus @ 2010-06-05 7:47 UTC (permalink / raw)
On 6/4/10 9:23 PM, Fritz Wuehler wrote:
> Ada is better than COBOL except in one way. It is easier to write reports
> (the bulk of financial processing) and define decimal (money) fields in
> COBOL than Ada. It *could* have been used in financial processing, but
> COBOL had two decades and a half of a head start.
How do Interfaces.COBOL and Ada.Text_IO.Editing fit in here?
^ permalink raw reply [relevance 6%]
* Re: Learning Ada (Was: unsigned type)
@ 2009-07-06 0:05 7% ` Ludovic Brenta
0 siblings, 0 replies; 35+ results
From: Ludovic Brenta @ 2009-07-06 0:05 UTC (permalink / raw)
anon top-posted on comp.lang.ada:
> Wrong!
> I was not talking about the Ada Statements "Type" or "Subtype" but
> true Standards that go beyond Ada.
Please define a "true standard" (as opposed to a "standard") and what
it means for a "true standard" to "go beyond" Ada. "go beyond" is a
non-standard phrase, it does not appear anywhere in the ARM.
[use the language-defined Integer and Float]
> But some people like "Ludovic Brenta, state that most Ada programmers
> would prefer to create their own types.
I did not state that; I don't know what "most Ada programmers" do or
where they are, and I don't use the "lemming argument" because I
honestly don't care what "most people" do in general. If I wanted to
do what "most people" do, I would not program in Ada. What I said is
that it is generally *better* to use application-defined types than
language-defined types; this is the proper and intended way to use
Ada.
> In some case, that goes against the RM
> because it can create a non-standardize form of an Ada programs, that violate
> other RM rules.
If a program violates other RM rules and the compiler properly
enforces the rules, then the program won't compile. What was your
point?
> Plus, the RM states that a number of numeric types are
> predefined, such as "Integer", and it subtypes "Natural" and "Positive" as
> well the type "Float" and its subtypes. Redefining those predefines types are
> legal in Ada, by simply re-defining the type. Like for example, using 24 bit
> integer:
>
> type Integer is range -2 ** 24 .. +2 ** ( 24 - 1 ) ;
Wrong; your declaration is legal but it does not "redefine"
Standard.Integer; it defines a new type with the same name.
> To use this new definition of "Integer", globally it needs to be define in the
> standard package, but for a single package or routine it better to create a new
> type or subtype and for the routine or package.
No; it is better to define an application-specific type instead. By
declaring a type Integer in your own package, you create a new problem
(global visibility of your new type) without solving any existing
problem, so this is not only useless but harmful. I've seen it done
in several places before and the reasons given to me for doing that
were always wrong. At least they avoided using the name Integer but
used Integer_Type or something similarly stupid instead. By the same
token, changing the definition of Standard.Integer achieves nothing
useful and is a lot of trouble, so don't do that.
> But in most programming this
> is not necessary. That is, since Ada creation and the DOD dropping it full
> support of Ada, the usage for redefining the numeric data types is almost nil,
> not the norm any more. Plus, the DOD require full documentation on all new
> define types. And no matter what type is defined the compiler will fall back to the
> basic standards of the universal-integer and universal-real aka CPU integer
> and FPU float and their operations. If you study most of the implementations of
> Ada, one can see that the types "Integer" and "Float" that are defined in the
> "Standard" package are basically equivalent to the Ada's universal-integer and
> universal-real.
So what? If you don't want compile-time type checks and only care
about the hardware-defined types, then go program in assembly
language.
> Now, "Rob Solomon" stated that he think "it would be beneficial, if
> the types Float and Integer were removed from the language".
No, that was Jacob Sparre Andersen.
> First, if this could happen the RM would need a MAJOR overhaul.
> It would be easier to create a new language. Because both types are used
> throughout the RM defined packages.
>
> Second, the predefined types allow for the program to be more portable,
> because a users type might not be accepted on the new system.
I'm sure Jacob is well aware of that. For your second objection, it
is a *Good* *Thing* if the compiler says up-front, at compile time,
whether it supports the application-defined types or not. It is a
*Bad* *Thing* if the compiler is silent and the application later
misbehaves because the hardware doesn't support the application
constraints.
[...]
> Then third, is without standards types like "Integer" and "Float" how
> would the system work. Using Ada, define a "=" or "*" without using the
> universal-integer and universal-real types or there operations. You can not!
You seem to be confusing the unioversal_integer and universal_real
types (which are anonymous) with Standard.Integer and Standard.Float,
respectively. They are *not* the same things. Even if
Standard.Integer and Standard.Float disappeared, unioversal_integer
and universal_real would still exist and allow the arithmetic
operations you describe.
[...]
> Fourth, is to interface with other languages. which also use standards.
> Some Ada programmer prefer pure Ada code. Like using the "Interface"
> package to only define the standard unsigned types and to use the low-level
> shift and rotate routines for those unsigned types. But there are times when
> interfacing is required.
For interfacing to C, you use Interfaces.C.int, not Standard.Integer,
and Interfaces.C.C_float, not Standard.Float. For COBOL you use
Interfaces.COBOL.Binary and Interfaces.COBOL.Floating. For Fortran,
you use Interfaces.Fortran.Fortran_Integer and
Interfaces.Fortran.Real. If "some Ada programmers" prefer
Standard.Integer and Standard.Float against the ARM, then they are
wrong. Nowhere does the ARM state what Standard.Integer or
Standard.Float correspond to in C, COBOL or Fortran.
--
Ludovic Brenta.
^ permalink raw reply [relevance 7%]
* Re: Just a thought!
2007-07-25 12:43 4% ` anon
@ 2007-07-26 23:37 0% ` Xianzheng Zhou
0 siblings, 0 replies; 35+ results
From: Xianzheng Zhou @ 2007-07-26 23:37 UTC (permalink / raw)
This is a rather long-term approach. I haven't seen that far yet:) I'm
planning to do a nanokernel, it's basically an abstraction of the cpu
layer and do nothing more than that.
The idea is to build more complex kernel on top of that which makes it
flexible, so that it's flexible to be re-planted to other hardware
platform and even embedded system without modifying the complex upper
part of the kernel. And it can be built as small as possible, rather
than heavy-weight, super advanced operating system.:)
Just my thought. Feel free to comments:)
thanks,
xianzheng
anon wrote:
> It is feasible if you have the time! I have written the "True Ada OS"
> kernel. The kernel is a non-Posix system which uses all three Intel
> protective rings as a security design. Except for the ASM instructions
> that are embedded in the Ada source code there are no assembly
> routines, the bios boot the kernel by jumping to the Ada code startup
> procedure. Also, the kernel runs in a 100% preemptive design which
> means after kernel is active the use of the "cli" and "sti" instruction
> are not allowed because they could allow non-preemptive coding.
>
> The kernel does test memory and calculate page sizes and tables as
> well as testing for devices but does limits the graphics card to the
> standard VGA mode only. Just too many cards and no standardized
> for SVGA mode, plus Ada has only limited graphics capabilities. Works
> with Linksys network cards as well as having a few file systems
> including it own version. So no need for GRUB or use of multiboot which
> could allow virus, due to the fact that GRUB is written in real (DOS)
> mode. Also, once loaded into memory and control is passed to kernel
> there are no BIOS calls, device drivers built-in. The prototype is
> native CD/DVD Bootable, with swapper partition optional. After
> booting it loads from the CD a controller shell.
>
> Using the initial kernel I have three extra projects. One is to write a
> compiler/binder/linker for the kernel (in the processes now). Gnat
> compiler has some designs fault that makes partition building difficult
> for this system, plus modifying the code would take more time then
> starting from scratch. Also, Gnat allows language interfaces and some
> non standard Ada features which this compiler and system will not.
> Only Pure Standard Ada code will compile and run in this system.
>
> And the second project is to replace the "BIOS ROM" with the kernel and
> a system configurator written in Ada. Initial test used an old ethernet
> card with a rom boot slot to test booting the system. Later after the
> compiler project if finished I will take an older PII and flash the bios
> prom with the kernel and configurator. So the whole system will then run
> pure Ada code.
>
> The third is to install the kernel in a "Core 2 Quad", later this year or
> maybe if Intel create the "Core 2 Octal", next year. This will give Ada
> a true parallel and multi-task design.
>
> With the PII test system and the "Core 2 Quad" Ada bios the computer
> system could be called a "True Ada Machine". Something like the old
> "Lisp Machines" except that this system will allow growth so long as
> the code is written in Ada. After that I have number of projects lined
> up to use the either the CD-Bootable Ada OS version or the
> "True Ada Machine".
>
> Note: The Interface package is limited to the parent package only. Which
> means not foreign languages or sub packages will exist. Such as
> Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Also, the
> Ada.Machine_Code package will not all the ASM instruction only special
> calls to selected number of assembly instructions. So the Ada will be
> called a limited subset of Ada because of the specification RM B.2 ( 1 ).
>
>
>
> Now, what do you need to know! First, the complete features of Ada,
> the computer system, the processor assembly language as well as the
> hardware that is installed. And you will need a lot of time for research
> and writing code. It is not someone thinks about playing with. I
> know a couple of programmers that are using an Ada OS as their doctoral
> thesis, their prof thinks the task is too great for them but they have 7
> years to finish it. Of course, they should think what types of computer
> system will exist in 7 years from now. And will their code still work.
>
>
> In <f86rrl$6qf$1@aioe.org>, Xianzheng Zhou <joe@lgsolutions.com.au> writes:
>> Hello everyone,
>>
>> I'm just thinking about writing a nanokernel using Ada. I don't know
>> whether this idea is feasible or not, just wanna have a play around with it.
>> Any suggestions please?:)
>>
>> Thanks,
>>
>> Xianzheng
>
^ permalink raw reply [relevance 0%]
* Re: Just a thought!
@ 2007-07-25 12:43 4% ` anon
2007-07-26 23:37 0% ` Xianzheng Zhou
0 siblings, 1 reply; 35+ results
From: anon @ 2007-07-25 12:43 UTC (permalink / raw)
It is feasible if you have the time! I have written the "True Ada OS"
kernel. The kernel is a non-Posix system which uses all three Intel
protective rings as a security design. Except for the ASM instructions
that are embedded in the Ada source code there are no assembly
routines, the bios boot the kernel by jumping to the Ada code startup
procedure. Also, the kernel runs in a 100% preemptive design which
means after kernel is active the use of the "cli" and "sti" instruction
are not allowed because they could allow non-preemptive coding.
The kernel does test memory and calculate page sizes and tables as
well as testing for devices but does limits the graphics card to the
standard VGA mode only. Just too many cards and no standardized
for SVGA mode, plus Ada has only limited graphics capabilities. Works
with Linksys network cards as well as having a few file systems
including it own version. So no need for GRUB or use of multiboot which
could allow virus, due to the fact that GRUB is written in real (DOS)
mode. Also, once loaded into memory and control is passed to kernel
there are no BIOS calls, device drivers built-in. The prototype is
native CD/DVD Bootable, with swapper partition optional. After
booting it loads from the CD a controller shell.
Using the initial kernel I have three extra projects. One is to write a
compiler/binder/linker for the kernel (in the processes now). Gnat
compiler has some designs fault that makes partition building difficult
for this system, plus modifying the code would take more time then
starting from scratch. Also, Gnat allows language interfaces and some
non standard Ada features which this compiler and system will not.
Only Pure Standard Ada code will compile and run in this system.
And the second project is to replace the "BIOS ROM" with the kernel and
a system configurator written in Ada. Initial test used an old ethernet
card with a rom boot slot to test booting the system. Later after the
compiler project if finished I will take an older PII and flash the bios
prom with the kernel and configurator. So the whole system will then run
pure Ada code.
The third is to install the kernel in a "Core 2 Quad", later this year or
maybe if Intel create the "Core 2 Octal", next year. This will give Ada
a true parallel and multi-task design.
With the PII test system and the "Core 2 Quad" Ada bios the computer
system could be called a "True Ada Machine". Something like the old
"Lisp Machines" except that this system will allow growth so long as
the code is written in Ada. After that I have number of projects lined
up to use the either the CD-Bootable Ada OS version or the
"True Ada Machine".
Note: The Interface package is limited to the parent package only. Which
means not foreign languages or sub packages will exist. Such as
Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Also, the
Ada.Machine_Code package will not all the ASM instruction only special
calls to selected number of assembly instructions. So the Ada will be
called a limited subset of Ada because of the specification RM B.2 ( 1 ).
Now, what do you need to know! First, the complete features of Ada,
the computer system, the processor assembly language as well as the
hardware that is installed. And you will need a lot of time for research
and writing code. It is not someone thinks about playing with. I
know a couple of programmers that are using an Ada OS as their doctoral
thesis, their prof thinks the task is too great for them but they have 7
years to finish it. Of course, they should think what types of computer
system will exist in 7 years from now. And will their code still work.
In <f86rrl$6qf$1@aioe.org>, Xianzheng Zhou <joe@lgsolutions.com.au> writes:
>Hello everyone,
>
>I'm just thinking about writing a nanokernel using Ada. I don't know
>whether this idea is feasible or not, just wanna have a play around with it.
>Any suggestions please?:)
>
>Thanks,
>
>Xianzheng
^ permalink raw reply [relevance 4%]
* Re: Float to String
2004-11-09 0:40 5% ` John B. Matthews
@ 2004-11-09 5:24 0% ` David C. Hoos, Sr.
0 siblings, 0 replies; 35+ results
From: David C. Hoos, Sr. @ 2004-11-09 5:24 UTC (permalink / raw)
To: John B. Matthews; +Cc: comp.lang.ada
To the contrary, my friend.
One still must convert the floating-point binary number to decimal.
Binary-coded-decimal simply means that the decimal digits are
encoded with four bits each, but the decimal digits must be
computed just the same.
Furthermore, if the binary value is not converted to decimal with
the number of digits I specified earlier, precision is lost when
converting the decimal value back to binary for use in computation.
----- Original Message -----
From: "John B. Matthews" <nospam@nospam.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada-france.org>
Sent: November 08, 2004 6:40 PM
Subject: Re: Float to String
> In article
> <mailman.85.1099945145.10401.comp.lang.ada@ada-france.org>,
> "David C. Hoos" <david.c.hoos.sr@ada95.com> wrote:
>
> [...]
>> The problem in that case was that values stored in an Oracle database
>> when later extracted sometimes differed in the lsb.
>>
>> What makes the problem similar is that Oracle required the data to be
>> stored in decimal format. The problem with that is that decimal numbers
>> are not, in general, exactly representable in binary. E.g. the decimal
>> number 0.1 is a non-terminating binary number.
>
> Indeed. To guarantee portability among the 90-odd Oracle platforms,
> they typically store numeric data using binary coded decimal (BCD)
> with exponent. This neatly avoids the problem of binary-decimal
> conversion.
>
> Might the data type Interfaces.COBOL.Packed_Decimal (or something
> similar) be a useful intermediate storage format?
>
> --
> John
> ----
> jmatthews at wright dot edu
> www dot wright dot edu/~john.matthews/
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>
>
^ permalink raw reply [relevance 0%]
* Re: Float to String
@ 2004-11-09 0:40 5% ` John B. Matthews
2004-11-09 5:24 0% ` David C. Hoos, Sr.
0 siblings, 1 reply; 35+ results
From: John B. Matthews @ 2004-11-09 0:40 UTC (permalink / raw)
In article
<mailman.85.1099945145.10401.comp.lang.ada@ada-france.org>,
"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote:
[...]
> The problem in that case was that values stored in an Oracle database
> when later extracted sometimes differed in the lsb.
>
> What makes the problem similar is that Oracle required the data to be
> stored in decimal format. The problem with that is that decimal numbers
> are not, in general, exactly representable in binary. E.g. the decimal
> number 0.1 is a non-terminating binary number.
Indeed. To guarantee portability among the 90-odd Oracle platforms,
they typically store numeric data using binary coded decimal (BCD)
with exponent. This neatly avoids the problem of binary-decimal
conversion.
Might the data type Interfaces.COBOL.Packed_Decimal (or something
similar) be a useful intermediate storage format?
--
John
----
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
^ permalink raw reply [relevance 5%]
* Re: float with 24-bit resolution
@ 2003-08-21 14:35 5% ` Ludovic Brenta
0 siblings, 0 replies; 35+ results
From: Ludovic Brenta @ 2003-08-21 14:35 UTC (permalink / raw)
Mark Johnson <mark_h_johnson@raytheon.com> writes:
> Actually, if you look at it carefully, binary can be an acceptable
> alternative - but you must use it in a different manner. For example,
> representing a number with two decimal digits of precision as an integer
> can be done where
> 042 (a value in memory / register)
> is interpreted as
> 0.42
> in calculations and for display to the user. We generated data of that
> type (ages ago) on a machine that had no packed decimal types (nor
> floating point). That machine then sent the data to a "display computer"
> where a software divide by 10 routine (no hardware divide) was used to
> generate the values to display to the user. That method did a few more
> calculations to conserve scarce I/O resources.
>
> For machines where packed decimal is supported, what you say is true,
> but it is not the only alternative. This other way of looking at fixed
> types in general is simply to treat like integers - with a specified
> value as the LSB (not one). In the example above, the LSB is 0.01. The
> compiler still has to work out all the arithmetic operations and side
> effects, but it is feasible.
What you describe is a second-best solution, and by your own accord
you only used it because the target hardware did not support
packed-decimal representations. Your divide-by-10 routine was the
weak point; 10 happens not to be a power of two, and therefore any
division of a binary number by 10 is bound to introduce rounding and
imprecision. You may minimise the impact of that by doing the
division as late as possible, e.g. for display purposes; this is
probably what made the solution acceptable to you. However, if your
program must write to a text file that serves as input to another
program (and then another, etc.), then the loss of precision quickly
becomes unacceptable.
Well, all of this is off-topic; here's a nice way to come back to Ada:
ARM B.4(13), package Interfaces.COBOL:
type Decimal_Element is mod implementation-defined;
type Packed_Decimal is
array (Positive range <>) of Decimal_Element;
pragma Pack(Packed_Decimal);
:)
--
Ludovic Brenta.
^ permalink raw reply [relevance 5%]
* Re: an interested business-oriented programmer
2001-06-07 4:58 6% ` Al Christians
2001-06-07 5:30 0% ` James Rogers
@ 2001-06-07 13:52 0% ` Marin David Condic
1 sibling, 0 replies; 35+ results
From: Marin David Condic @ 2001-06-07 13:52 UTC (permalink / raw)
Annex F is "normative" which, if I understand correctly, means its basically
a requirement for validation. (I'll probably get hit over the head for
that!) I'd suspect that all conforming implementations would have it if they
are targeted to a general-purpose computer. You wouldn't much need it if you
were running on an embedded machine - unless maybe it was a
bank-teller-machine?
As for interfacing to Cobol - I doubt that would be a major concern for
someone who is looking to develop new systems for workstation/PC level
products. There isn't exactly tons of need to interface to Cobol code in
such an environment. If you were using Ada on a mainframe (is there an Ada
implementation for a mainframe that is still in use?) with all sorts of
legacy Cobol code, you might want that - but I don't see thousands of posts
here asking those kinds of questions, so I suspect most vendors wouldn't
support it. I wouldn't consider that a drawback for most business software
development.
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
Web: http://www.mcondic.com/
"Al Christians" <alc@PublicPropertySoftware.com> wrote in message
news:3B1F09F8.A6521EEF@PublicPropertySoftware.com...
> But, if we are talking about business-oriented programming,
> does Aonix implement interfaces.COBOL and Annex F ("information
> systems", which includes decimal data)?
>
> The competition is COBOL and/or either Java or C++ with a decimal
> numbers class library.
>
> Al
>
> James Rogers wrote:
> >
> > "Beard, Frank" wrote:
> > >
> > > -----Original Message-----
> > > From: Gary Scott [mailto:Gary.L.Scott@lmtas.lmco.com]
> > >
> > > > Hi,
> > > > So why doesn't someone put together a "Visual Ada" product
integrated
> > > > with Visual Studio and mass market it? They did it for Fortran...
> > >
> > > That's what Aonix ObjectAda is, but I think for the past year or more
> > > the marketing has become somewhat deficient.
> >
> > About two years ago I was helping an experienced Visual C++
> > developer use the Aonix ObjectAda tools. He recognized the Aonix
> > interface as being a rather old version of Visual Studio. He really
> > liked using Visual Studio. His answer was to make a few
> > customizations of the Visual Studio configuration files, allowing
> > the current version to fully support development using ObjectAda.
> >
> > To his amazement, the standard Visual Studio debugger worked better
> > on ObjectAda than it did on Visual C++. He saw more detailed
> > information about arrays, collections (records in Ada, classes in C++),
> > and better dereferencing of Ada access types than C++ pointers and
> > references.
> >
> > He immediately appreciated Ada. He also liked the matrix manipulation
> > packages he found and downloaded to help him produce Kalman filters.
> >
> > Jim Rogers
> > Colorado Springs, Colorado USA
^ permalink raw reply [relevance 0%]
* Re: an interested business-oriented programmer
2001-06-07 4:58 6% ` Al Christians
@ 2001-06-07 5:30 0% ` James Rogers
2001-06-07 13:52 0% ` Marin David Condic
1 sibling, 0 replies; 35+ results
From: James Rogers @ 2001-06-07 5:30 UTC (permalink / raw)
Al Christians wrote:
>
> But, if we are talking about business-oriented programming,
> does Aonix implement interfaces.COBOL and Annex F ("information
> systems", which includes decimal data)?
>
> The competition is COBOL and/or either Java or C++ with a decimal
> numbers class library.
>
I do not have the answer to that. I was using ObjectAda on the
PharLap ETS operating system for robotic controls.
How much of an interface to COBOL will you get with Java or
C++? The only language interface defined for either of those
languages is C. Even without some Annex F, Ada supports business
applications better than C++ or Java. What kind of fixed point
numbers are defined as part of either language? (Does the answer
"none" come to mind?)
Let's talk a little about execution efficiency too. C++ and Ada
implementations exhibit similar execution efficienies, but both
still dramatically beat Java. I know a lot of effort has been
spent to improve the efficiency of Java Virtual Machines.
Improvements have been made. Parity has not been achieved. Even
more important is the fact that most common Java programming
idioms are terribly inefficient. For instance, editing each character
in a 1024 character Java string will require 2 Megabytes of
memory, and involve the creation and garbage collection of 1024
strings. The way around this is to convert the Java String object
to a Java StringBuffer object, perform all the edits, then convert
the StringBuffer object to another String object, requiring only
about 6 Kilobytes of memory and the creation ( and garbage
collection ) of three objects. This is clearly faster than the
use of only Java Strings, but also slower than editing an Ada
string.
I do not see how C++ and Java can be considered close to Ada's
capabilities in the Business arena. C++ lacks Ada's numeric types
as well as any ability to interface with COBOL. Java mirrors
C++'s deficiencies topped off with a nasty dose of inefficiency.
COBOL is still a highly respectable language for business systems.
COBOL is optimized for large scale transaction processing
applications. The biggest problem facing COBOL is its aging
workforce. Few people are learning COBOL. Some companies are feeling
forced to develop solutions in other languages just so that they
can easily hire developers and maintainers for their code. With
that attitude, those employers are often going to choose the current
fad language rather than make a strict technical decision.
Another sad fact is that most employers looking to replace
COBOL have never heard of Ada.
Jim Rogers
Colorado Springs, Colorado USA
^ permalink raw reply [relevance 0%]
* Re: an interested business-oriented programmer
@ 2001-06-07 4:58 6% ` Al Christians
2001-06-07 5:30 0% ` James Rogers
2001-06-07 13:52 0% ` Marin David Condic
0 siblings, 2 replies; 35+ results
From: Al Christians @ 2001-06-07 4:58 UTC (permalink / raw)
But, if we are talking about business-oriented programming,
does Aonix implement interfaces.COBOL and Annex F ("information
systems", which includes decimal data)?
The competition is COBOL and/or either Java or C++ with a decimal
numbers class library.
Al
James Rogers wrote:
>
> "Beard, Frank" wrote:
> >
> > -----Original Message-----
> > From: Gary Scott [mailto:Gary.L.Scott@lmtas.lmco.com]
> >
> > > Hi,
> > > So why doesn't someone put together a "Visual Ada" product integrated
> > > with Visual Studio and mass market it? They did it for Fortran...
> >
> > That's what Aonix ObjectAda is, but I think for the past year or more
> > the marketing has become somewhat deficient.
>
> About two years ago I was helping an experienced Visual C++
> developer use the Aonix ObjectAda tools. He recognized the Aonix
> interface as being a rather old version of Visual Studio. He really
> liked using Visual Studio. His answer was to make a few
> customizations of the Visual Studio configuration files, allowing
> the current version to fully support development using ObjectAda.
>
> To his amazement, the standard Visual Studio debugger worked better
> on ObjectAda than it did on Visual C++. He saw more detailed
> information about arrays, collections (records in Ada, classes in C++),
> and better dereferencing of Ada access types than C++ pointers and
> references.
>
> He immediately appreciated Ada. He also liked the matrix manipulation
> packages he found and downloaded to help him produce Kalman filters.
>
> Jim Rogers
> Colorado Springs, Colorado USA
^ permalink raw reply [relevance 6%]
* fyi: Ada package hierarchy tree
@ 1999-03-02 0:00 4% nabbasi
0 siblings, 0 replies; 35+ results
From: nabbasi @ 1999-03-02 0:00 UTC (permalink / raw)
Ada package hierarchy tree (based on GNAT 3.11p ACT distribution sources)
date 3/2/99. by Nasser Abbasi.
Free to copy, distribute in any way. Not responsible for errors.
(updated copies can be found at http://home.pacbell.net/nma123
===============================================================
Number of packages:
-- Ada tree contains 111 packages.
-- Interfaces tree contains 13 packages.
-- GNAT tree contains 20 nodes packages.
-- System tree 190 packages. (almost flat tree)
A D A Package
-------------------------
+- Asynchronous_Task_Control
|
+- Calender -+- Delay_Objects
| |
| +- Delays
|
| +- Handling
| |
+- Characters -+- Latin_1
| |
| +- Wide_Latin_1
|
+- Command_Line -+- Environment
|
+- Decimal
|
+- Direct_IO -+- C_Streams
|
+- Dynamic_Priorities
|
+- Exceptions
|
+- Finalization -+- List_Controller
|
+- Float_Text_IO
|
+- Float_Wide_Text_IO
|
+- Integer_Text_IO
|
+- Interrupts -+- Names
|
+- Integer_Wide_Text_IO
|
+- Long_Float_Text_IO
|
+- Long_Float_Wide_Text_IO
|
+- Long_Integer_Text_IO
|
+- Long_Integer_Wide_Text_IO
|
+- Long_Long_Float_Text_IO
|
+- Long_Long_Float_Wide_Text_IO
|
+- Long_Long_Integer_Text_IO
|
+- Long_Long_Integer_Wide_Text_IO
|
+- IO_Exceptions
|
| +- Aux (Private?)
| |
| +- Complex_Elementry_Functions
| |
| +- Complex_Types
| |
| +- Discrete_Random
| |
| +- Elementary_Functions
| |
| +- Float_Random
| |
| +- Generic_Complex_Elementry_Functions
| |
| +- Generic_Complex_Types
Ada -+- Numerics -+
| +- Generic_Elementary_Functions
| |
| +- Long_Complex_Types
| |
| +- Long_Elementary_Functions
| |
| +- Long_Complex_Elementary_Functions
| |
| +- Long_Long_Complex_Elementary_Functions
| |
| +- Long_Long_Complex_Types
| |
| +- Long_Long_Elementary_Functions
| |
| +- Short_Complex_Elementary_Functions
| |
| +- Short_Complex_Types
| |
| +- Short_Elementary_Functions
|
|
+- Real_Time -+- Delays
|
+- Sequential_IO -+- C_Streams
|
+- Short_Float_Text_IO
|
+- Short_Float_Wide_Text_IO
|
+- Short_Integer_Text_IO
|
+- Short_Integer_Wide_Text_IO
|
+- Storage_IO
|
+- Streams -+- Stream_IO -+- C_Streams
|
| +- Bounded
| |
| +- Fixed
| |
| +- Maps -+- Constants
| |
+- Strings -+- Unbounded -+- Aux (Private?)
| | |
| | +- Text_IO
| |
| +- Wide_bounded
| |
| +- Wide_Fixed
| |
| +- Wide_Maps -+- Wide_Constants
| |
| +- Wide_Unbounded
|
|
+- Short_Short_Integer_Text_IO
|
+- Short_Short_Integer_Wide_Text_IO
|
+- Synchronous_Task_Control
|
+- Tags
|
+- Task_Attributes
|
+- Task_Identification
|
| +- Complex_IO
| |
| +- Editing
| |
| +- Text_Streams
| |
| +- Complex_Aux (Private?)
| |
| +- Decimal_IO
| |
+- Text_IO -+- Fixed_IO
| |
| +- Float_IO
| |
| +- Enumeration_IO
| |
| +- Integer_IO
| |
| +- Modular_IO
| |
| +- C_Streams
| |
| +- Text_Streams
|
|
+- Unchecked_Conversion
|
+- Unchecked_Deallocation
|
| +- Complex_IO
| |
| +- Editing
| |
| +- Text_Streams
| |
| +- Complex_Aux (Private?)
| |
| +- Decimal_IO
| |
+- Wide_Text_IO -+- Fixed_IO
|
+- Float_IO
|
+- Enumeration_IO
|
+- Integer_IO
|
+- Modular_IO
|
+- C_Streams
|
+- Text_Streams
|
+- Generic_Aux (Private?)
I N T E R F A C E S Package
------------------------------------------
+- Pointers
|
+- C -+- Strings
| |
| +- Extensions
| |
| +- Sthreads
|
Interfaces -+- COBOL
|
+- Fortran
|
+- CPP
|
+- OS2Lib -+- Errors
| |
| +- Synchronization
| |
| +- Threads
|
+- Packed_Decimal
G N A T package
-----------------------------------
+- Bubble_Sort_A
|
+- Bubble_Sort_G
|
+- Case_Util
|
+- Command_Line
|
+- Debug_Utilities
|
+- Directory_Operations
|
+- Heap_Sort_A
|
GNAT -+- Heap_Sort_G
|
+- HTable
|
+- IO -+- IO_Aux
|
+- OS_Lib
|
+- Regexp
|
| +- Patterns
| |
| +- Table_Boolean
| |
+- Spitbol -+- Table_Integer
| |
| +- Table_VString
|
+- Table
|
+- Task_Lock
S Y S T E M package (big!)
----------------------------------------------
+- Address_To_Access_Conversion
|
+- Machine_Code
|
+- RPC
|
+- OS_Interface
|
+- Program_Info
|
+- Parameters
|
+- Arith_64
|
+- Assertions
|
+- AST_Handling
|
+- Aux_DEC
|
+- Bit_Ops
|
+- Checked_Pools
|
+- Debug_Pools
|
+- Direct_IO
|
+- Error_Reporting
|
+- Exceptions
|
+- Exception_Table
|
+- Exn_Flt
|
+- Exn_Gen
|
+- Exn_Int
|
+- Exn_LFlt
|
+- Exn_LInt
|
+- Exn_LLF
|
+- Exn_LLI
|
+- Exn_SFlt
|
+- Exn_SInt
|
+- Exn_SSI
|
+- Exp_Flt
|
+- Exp_Gen
|
+- Exp_Int
|
+- Exp_LFlt
|
+- Exp_LInt
|
+- Exp_LLF
|
+- Exp_LLI
|
+- Exp_LLU
|
+- Exp_Mod
|
+- Exp_SFlt
|
+- Exp_SIn
|
+- Exp_SSI
|
+- Exp_Uns
|
+- Fat_Flt
|
+- Fat_Gen
|
+- Fat_LFlt
|
+- Fat_LLF
|
+- Fat_SFlt
|
+- File_Control_Block
|
+- File_IO
|
+- Finalization_Implementation
|
+- Finalization_Root
|
+- Fore
|
+- Img_BIU
|
+- Img_Bool
|
+- Img_Char
|
+- Img_Dec
|
+- Img_Int
|
+- Img_LLB
|
+- Img_LLD
|
+- Img_LLI
|
+- Img_LLU
|
+- Img_LLW
|
+- Img_Real
|
+- Img_Uns
|
+- Img_WChar
|
+- Img_WIU
|
+- Interrupt_Management -+- Operations
|
+- Interrupts
|
+- IO
|
+- Mantissa
|
+- OS_Primitives
|
+- Pack_03
.
.
+- Pack_63
|
+- Parameters
|
+- Partition_Interface
|
+- Pool_Global
|
+- Pool_Local
|
+- Pool_Size
|
+- Powten_Table
|
+- Secondary_Stack
|
+- Sequential_IO
|
+- String_Ops_Concat_3
|
+- String_Ops_Concat_4
|
+- String_Ops_Concat_5
|
+- Standard_Library
|
+- Storage_Elements
|
+- Storage_Pools
|
+- Stream_Attributes
|
+- String_Ops
|
|
| +- Task_Attributes
| |
| +- Utilities
| |
| +- Initialization
| |
| +- Entry_Calls
| |
System -+- Tasking -+- Protected_Objects
| |
| +- Abortion
| |
| +- Debug
| |
| +- Queuing
| |
| +- Rendezvous
| |
| +- Stages
|
|
+- Task_Primitives -+- Operations
|
+- Task_Info
|
+- Tasking_Soft_Links
|
+- Task_Specific_Data
|
+- Task_Timer
|
+- Unsigned_Types
|
+- Vax_Float_Operations
|
+- Val_Bool
|
+- Val_Char
|
+- Val_Dec
|
+- Val_Enum
|
+- Val_Int
|
+- Val_LLD
|
+- Val_LLI
|
+- Val_LLU
|
+- Val_Real
|
+- Val_Uns
|
+- Val_Util
|
+- Val_WChar
|
+- Version_Control
|
+- VMS_Exception_Table
|
+- WCh_Cnv
|
+- WCh_Con
|
+- WCh_JIS
|
+- WCh_StW
|
+- WCh_WtS
|
+- Wid_Bool
|
+- Wid_Char
|
+- Wid_Enum
|
+- Wid_LLI
|
+- Wid_LLU
|
+- Wid_WChar
|
+- WWd_Char
|
+- WWd_Enum
|
+- Wwd_WChar
^ permalink raw reply [relevance 4%]
* Re: Types (was Ada 95 LRM Error?)
@ 1999-02-01 0:00 4% ` Richard D Riehle
0 siblings, 0 replies; 35+ results
From: Richard D Riehle @ 1999-02-01 0:00 UTC (permalink / raw)
In article <yecu2x715hb.fsf@king.cts.com>,
Keith Thompson <kst@cts.com> wrote:
>The general point is correct, but the specific point is not; int and
>char are definitely distinct types in C.
Semantics, again. Yes, they seem to be "distinct types" (i.e.,
have distinct names) but the next paragraph makes one wonder.
>Note that there are several possible sources of confusion here. The
>types char and int are assignment compatible, character literals are
>of type int, char objects are usually promoted to int in arithmetic
>expressions, and char function arguments are promoted to int in the
>absence of a prototype.
This reminds me of a card trick expert at some obligatory social
function.
No matter what card I select, the card trickster will be able to find
it through some illusory sleight of hand.
My understanding of type, in part, is that a type has,
1) a name, in scope within some declarative region
2) a defined set of operations for objects of the name
3) a defined set of values for objects of the name
4) a "wall" between objects of the named type and
objects with some other type name.
The last characteristic, a wall, is important for type to have any
real meaning. Ada allows us to get beyond the "wall" through type
conversion, view conversion, and even unchecked conversion, but the
wall is always there. In C, there is no wall. When considered this
way, int and char are not really distinct. C allows the dangerous
illusion of distinct types, a source of many interesting defects
in C and C++ software.
The example of Integer, Natural, and Positive does not meet this test
because subtypes, in the reserved word sense, have no wall between them.
Perhaps int and char are more analogous to Ada entities we define using
the subtype reserved word.
This thread began with a consideration of the type definitions in the
Interfaces.COBOL examples in the Annex B. Robert Dewar has pointed
out that COBOL does, in fact, have types, abeit somewhat more flexible
types than we find in Ada. Any attempt to interface between a strongly
typed language and one that is weakly-type, requires some concession
to the characteristics of the weakly-typed language.
The ability to implicitly promote one type to another does not seem to
me to meet the standards I would expect for "distinct types."
It is interesting that one can start with a strongly-type language, one
where the default is strong typing, and selectively relax the type model
for some targeted environment. It is harder to start with a weakly-typed
language and make it strongly-typed. This is one of the key problems
with C++. The language starts with the weak typing of C and tries to
overlay a model for strong typing. The result is a language that, like
the card trickster at the party, seduces the naive programmer into
believing in magic.
Richard Riehle
http://www.adaworks.com
^ permalink raw reply [relevance 4%]
* Interfaces.Cobol (Was LRM Error?)
1999-01-28 0:00 6% ` Richard D Riehle
@ 1999-01-28 0:00 14% ` Al Christians
1 sibling, 0 replies; 35+ results
From: Al Christians @ 1999-01-28 0:00 UTC (permalink / raw)
Richard D Riehle wrote:
> 05 Some-Number PICTURE S99V99 USAGE DISPLAY.
> 05 Some-String PICTURE 9(6).
>
> We may freely MOVE (actually MOVE means "copy") the numeric data
> to the string data without regard to the typing. On the other hand,
> we will get a compile time error if we try to do arithmetic on the
> string.
A field that contains 9's only is numeric and can be used for arithmetic
even if it is named Some-String. And USAGE DISPLAY just tells how the
data is to be stored, not how it is to be used. So, you can do math on
either of the two fields above.
>
> The people who worked on this package had their work cut out for them.
I agree 100%.
> They seem to have done it well, given the huge differences between the
> COBOL language and Ada.
Anybody know how much use this package gets? I'd be interested to
know how well it works in practice. How many Ada compilers other than
GNAT come with it? Do vendors of compilers that don't provide it get
any requests for it?
Looking at the example in the LRM, I doubt that it gets heavy use as
illustrated there. The example shows creating instances of the generic
conversion routines for each field to convert. If generics eat up
memory, this will be quite a pig to interface to a big Cobol system (say
100's of files, many thousands of fields) -- I think we'd find another
way to do it.
One alternative is to use Cobol copybooks to generate a wrapper to
Interfaces.Cobol for each Cobol copybook, but to only create one
instance of the generic converter for each distinct set of Cobol
attributes. This would be pretty good, but for a system with many
copybooks, you would also want have to avoid duplication between
files. But I'd guess that the number of distinct Cobol formats
wouldn't go too far up into the hundreds often.
I think I'm going to just write a wrapper for Interfaces.Cobol that
uses one instance of each of three generics -- for numeric, binary,
and packed data, and machine generate the get and set functions that
invoke the wrapper. Anyone else already cracked this nut or otherwise
interested?
Al
^ permalink raw reply [relevance 14%]
* Re: Ada 95 LRM Error?
@ 1999-01-28 0:00 7% ` Al Christians
0 siblings, 0 replies; 35+ results
From: Al Christians @ 1999-01-28 0:00 UTC (permalink / raw)
robert_dewar@my-dejanews.com wrote:
>
>
> I don't see anyway the interface can be compatible with
> odd non-standard COBOL stuff like this!
>
There's also the issue of minimum and maximums within the
binary data types. A cobol pic S9(9) comp will generally be
represented as 32-bit integer, and the corresponding Ada type
will have digits 9. But the 32-bit integer can hold some 10-digit
values. IDK which Cobol compilers do how much to prevent these
from actually existing -- I suppose it depends on how much run-time
type checking is turned on in the programs. I assume that these
values, if they exist, should cause an error of some kind if
Interfaces.Cobol comes across them.
Al
^ permalink raw reply [relevance 7%]
* Re: Ada 95 LRM Error?
1999-01-27 0:00 7% ` Al Christians
@ 1999-01-28 0:00 6% ` Richard D Riehle
1999-01-28 0:00 14% ` Interfaces.Cobol (Was LRM Error?) Al Christians
1 sibling, 2 replies; 35+ results
From: Richard D Riehle @ 1999-01-28 0:00 UTC (permalink / raw)
In article <36AFC42A.57696F4D@easystreet.com>,
Al Christians <achrist@easystreet.com> wrote:
>Richard D Riehle wrote about Interfaces.Cobol:
>>
>> As it is, the package is defined so it conforms to the conventions of
>> typical COBOL programming.
>>
>
>But if I put non-numeric data into a Numeric, it will flunk the
>Valid() test, right?
>
>Since you speak of 'typical COBOL programming', can you enlighten me a
>little about why this interface looks the way it does?
>
"Well, now, then, there ..."
COBOL is not a strongly-typed language. There are, of course, data
types in the form of PICTURE characters, but a COBOL programmer has
great latitude in performing operations that mix alphanumeric numbers
and ordinary alphanumeric characters.
05 Some-Number PICTURE S99V99 USAGE DISPLAY.
05 Some-String PICTURE 9(6).
We may freely MOVE (actually MOVE means "copy") the numeric data
to the string data without regard to the typing. On the other hand,
we will get a compile time error if we try to do arithmetic on the
string. The rules for this kind of thing in COBOL are actually rather
complex; what is truncated, what is left justified or right justified,
all kinds of interesting permutations.
If the data type corresponds to COBOL, USAGE DISPLAY, the example shown
in the example will work. This does not mean it is good style. It
isn't good Ada style, but this package is intended to assist in the
interface between Ada and COBOL so a certain amount of flexibility
is necessary.
As for the function, Interfaces.Cobol.Decimal_Conversions.Valid,
invocation depends on the decimal type used for instantiation as
well as the actual implementation of type Display_Format. One
reason why this is unusual is COBOL's flexibility in where the
sign is located in USAGE DISPLAY format. It could be a trailing or
leading sign.
The people who worked on this package had their work cut out for them.
They seem to have done it well, given the huge differences between the
COBOL language and Ada.
On the positive side, COBOL was designed quite well in the time it was
conceived. Consider that it has been one of the most successful
programming languages ever used. It would be wonderful if Ada could
be even a tenth as successful as COBOL.
Richard Riehle
richard@adaworks.com
http://www.adaworks.com
^ permalink raw reply [relevance 6%]
* Re: Ada 95 LRM Error?
@ 1999-01-28 0:00 6% ` Richard D Riehle
1999-01-27 0:00 7% ` Al Christians
0 siblings, 1 reply; 35+ results
From: Richard D Riehle @ 1999-01-28 0:00 UTC (permalink / raw)
In article <36AF6C22.896FC5B8@easystreet.com>,
Al Christians <achrist@easystreet.com> wrote:
>I'm looking at the Ada 95 Reference Manual, B.4.106. It shows
>a field:
>
> Name : COBOL.Numeric(1..20);
>
>Later on, in B.4.109, this gets assigned:
>
> Name => "Johnson, John ",
>
>This looks pretty obviously like an error, and I think it probably
>should be Alphanumeric instead of Numeric. However, Numeric is what
>it is, both in my printed version of the LRM and the online LRM
>that comes with the brand-new edition of AdaGide.
>
>Is 20 even going to work for a Numeric size on typical platforms? That's
>more than 64 bits.
>
>Am I wrong or is this in need of fixing? How would that happen?
A look at the data types involved might be helpful.
In the package Interfaces.COBOL there are several data types that
seem to have the same set of values.
Line 13: type COBOL_Character is implementation-defined character type;
Line 16: type Alphanumeric is array
(Positive range <>) of COBOL_Character := implementation-defined;
Line 20: type Numeric is array
(Positive range <>) of COBOL_Character := implementation-defined;
Line 56: type Alphanumeric corresponds to COBOL's alphanumeric
data category.
Line 59: type Numeric corresponds to COBOL's numeric data category
with display usage.
The key words in line 59 are "display usage" which imply that the
underlying representation will be one byte per number. Therefore,
it is possible that the indicated statements will work in some
environments, even though it would have been more appropriate to
use alphanumeric. An alphanumeric COBOL number, such as '6',
05 X PICTURE 9.
can be assigned directly to a numeric data item,
05 Y PICTURE X.
in COBOL if both are USAGE DISPLAY.
The Corresponding Ada types would also allow this if the assignment
were between slices of the same component type. If there is an
error, it may be that the Numeric data type was not more
strictly defined to ensure that such assignments require a function
call such as,
function To_Alphanumeric(N : Numeric) return Alphanumeric;
function To_Numeric (A : Alphanumeric) return Numeric;
As it is, the package is defined so it conforms to the conventions of
typical COBOL programming.
Richard Riehle
richard@adaworks.com
http://www.adaworks.com
^ permalink raw reply [relevance 6%]
* Re: Ada 95 LRM Error?
1999-01-28 0:00 6% ` Richard D Riehle
@ 1999-01-27 0:00 7% ` Al Christians
1999-01-28 0:00 6% ` Richard D Riehle
0 siblings, 2 replies; 35+ results
From: Al Christians @ 1999-01-27 0:00 UTC (permalink / raw)
Richard D Riehle wrote about Interfaces.Cobol:
>
> As it is, the package is defined so it conforms to the conventions of
> typical COBOL programming.
>
But if I put non-numeric data into a Numeric, it will flunk the
Valid() test, right?
Since you speak of 'typical COBOL programming', can you enlighten me a
little about why this interface looks the way it does?
For example, the To_Binary(Num, Binary_Format) function returns a
Byte_Array and not a Binary, and there is no corresponding
To_Long_Binary. It looks like To_Binary decides what length of
Byte_Array to give back based on the digits of Num. I suppose that
the compiler can figure this all out at compile time, since digits
is static, but it seems a little odd that the size of a Byte_Array is
never really set anywhere in the visible code, but the subtype returned
from To_Binary depends on Num's digits. It's also a little confusing
that there are 2 binary types, ie Binary and Long_Binary, but that in
GNAT, for example, the return values from To_Binary, come in four
different sizes (I think).
That the Binary_Format doesn't specify the field size also makes it a
little hard to be consistent with the Cobol code I know about, which
allows a compile time switch to indicate whether or not a number with
fewer than 3 digits uses one or two bytes. Here Interfaces.Cobol decides
that for me behind the scenes.
Thanks for your assistance, Richard.
Al
^ permalink raw reply [relevance 7%]
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP
1998-04-30 0:00 7% ` Robert I. Eachus
@ 1998-05-01 0:00 0% ` Fergus Henderson
1 sibling, 0 replies; 35+ results
From: Fergus Henderson @ 1998-05-01 0:00 UTC (permalink / raw)
eachus@spectre.mitre.org (Robert I. Eachus) writes:
>In article <6hvm8k$t3l$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes:
>
> > How does the Ada compiler implemetor know what C compiler is used in
> > that "particular environment in which the compiler operates"?
> > Telepathy?
>
> No, by the name used in the pragma. The conventions Ada, Intrinsic,
>Fortran, C, and COBOL are defined in the RM, as are the packages
>Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
>allowed to add support for other languages, and in the particular case
>mentioned above, they would choose one C compiler to correspond to the
>convention C, and others could be named Gcc, VisualC, etc. In practice,
>the compiler that corresponds to C is the one used to compile the OS.
It would also be easy to implement a command-line option or configuration
pragma to override the default meaning for the "C" convention
(e.g. by default "C" might mean "VisualC", but the user could
override it so that "C" would mean "gcc").
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [relevance 0%]
* Re: Urgent question: malloc and ada...READ/NEW/FOLLOWUP
@ 1998-04-30 0:00 7% ` Robert I. Eachus
1998-04-30 0:00 0% ` Urgent question: malloc and ada Larry Kilgallen
1998-05-01 0:00 0% ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Fergus Henderson
1 sibling, 1 reply; 35+ results
From: Robert I. Eachus @ 1998-04-30 0:00 UTC (permalink / raw)
In article <6hvm8k$t3l$1@news.hal-pc.org> Jonathan Guthrie <jguthrie@brokersys.com> writes:
> How does the Ada compiler implemetor know what C compiler is used in
> that "particular environment in which the compiler operates"?
> Telepathy?
No, by the name used in the pragma. The conventions Ada, Intrinsic,
Fortran, C, and COBOL are defined in the RM, as are the packages
Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
allowed to add support for other languages, and in the particular case
mentioned above, they would choose one C compiler to correspond to the
convention C, and others could be named Gcc, VisualC, etc. In practice,
the compiler that corresponds to C is the one used to compile the OS.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [relevance 7%]
* Re: Urgent question: malloc and ada...
1998-04-30 0:00 7% ` Robert I. Eachus
@ 1998-04-30 0:00 0% ` Larry Kilgallen
0 siblings, 0 replies; 35+ results
From: Larry Kilgallen @ 1998-04-30 0:00 UTC (permalink / raw)
In article <EACHUS.98Apr30171942@spectre.mitre.org>, eachus@spectre.mitre.org (Robert I. Eachus) writes:
> No, by the name used in the pragma. The conventions Ada, Intrinsic,
> Fortran, C, and COBOL are defined in the RM, as are the packages
> Interfaces.C, Interfaces.COBOL, and Interfaces.Fortran. Compilers are
> allowed to add support for other languages, and in the particular case
> mentioned above, they would choose one C compiler to correspond to the
> convention C, and others could be named Gcc, VisualC, etc. In practice,
> the compiler that corresponds to C is the one used to compile the OS.
I find it strange that even in comp.lang.ada a distinguished contributor
would express the assumption that the operating system was written in C.
Larry Kilgallen
^ permalink raw reply [relevance 0%]
* Re: SI Units Solicitation - Upgrade from comments
@ 1997-08-22 0:00 5% ` Robert Dewar
0 siblings, 0 replies; 35+ results
From: Robert Dewar @ 1997-08-22 0:00 UTC (permalink / raw)
Bill wrote
<<Give me a better name. Float is out since it is pre-empted by Ada. We
are simulating ATLAS whlch uses the term "DECIMAL", which I believe is
also pre-empted, and further is a poor discription for a binary floating
point number.>>
No, the type name Decimal is nowhere used in the Ada 95 RM, not even in
Interfaces.COBOL, so it is certainly not "preempted". I agree however,
that it is a truly horrible choice of names for binary floating-point.
^ permalink raw reply [relevance 5%]
* Re: Leading zeros with Int_IO.Put()? Or another package?
@ 1996-11-05 0:00 6% ` Samuel Tardieu
0 siblings, 0 replies; 35+ results
From: Samuel Tardieu @ 1996-11-05 0:00 UTC (permalink / raw)
To: J.D. Baldwin
I've never tried it myself, but the Interfaces.Cobol package may be of
some help.
Sam
--
Samuel Tardieu -- sam@ada.eu.org
^ permalink raw reply [relevance 6%]
* Re: C/C++ knocks the crap out of Ada
1996-02-20 0:00 7% ` Robert Dewar
@ 1996-02-22 0:00 0% ` Richard A. O'Keefe
0 siblings, 0 replies; 35+ results
From: Richard A. O'Keefe @ 1996-02-22 0:00 UTC (permalink / raw)
I wrote:
>Ada does not support Fortran-style formatted I/O, nor PL/I style
>formatted or pictured I/O (but see Interfaces.COBOL).
dewar@cs.nyu.edu (Robert Dewar) writes:
>Wrong advice, Ada 95 DOES spport COBOL-style pictures, see the information
>systems annex. I am not sure what "pictured I/O" is (COBOL certainly does
>not have it! But both COBOL and Ada 95 provide facilities for the use of
>pictures to edit alphanumeric data (this data can certainly be output
>after it is edited :-)
"Wrong advice"? But I never said Ada 95 doesn't support COBOL-style
pictures! I avoided mention of the Information Systems annex because
it is one of the "Specialised Needs" annexes, which are optional, but
annex B isn't (though if I understand correctly the child packages are).
What I wrote was
Ada does not support ... PL/I style formatted or pictured I/O
^^^^
It remains true that Ada 95 does not support PL/I style pictures, neither
in the core nor in any specialised needs annex, nor does it support PL/I
*style* I/O. I am actually _happy_ that this is so.
PL/I-style "record" I/O is also not supported by Ada 95.
It might actually be worth discussing this at some time; what did DEC Ada
do about RMS?
--
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
^ permalink raw reply [relevance 0%]
* Re: C/C++ knocks the crap out of Ada
1996-02-19 0:00 4% ` Richard A. O'Keefe
@ 1996-02-20 0:00 7% ` Robert Dewar
1996-02-22 0:00 0% ` Richard A. O'Keefe
0 siblings, 1 reply; 35+ results
From: Robert Dewar @ 1996-02-20 0:00 UTC (permalink / raw)
Richard said
Ada does not support Fortran-style formatted I/O, nor PL/I style
formatted or pictured I/O (but see Interfaces.COBOL).
Wrong advice, Ada 95 DOES spport COBOL-style pictures, see the information
systems annex. I am not sure what "pictured I/O" is (COBOL certainly does
not have it! But both COBOL and Ada 95 provide facilities for the use of
pictures to edit alphanumeric data (this data can certainly be output
after it is edited :-)
^ permalink raw reply [relevance 7%]
* Re: C/C++ knocks the crap out of Ada
[not found] ` <4etcmm$lpd@nova.dimensional.com>
[not found] ` <3114d8fb.5a455349@zesi.ruhr.de>
@ 1996-02-20 0:00 0% ` Jon S Anthony
1 sibling, 0 replies; 35+ results
From: Jon S Anthony @ 1996-02-20 0:00 UTC (permalink / raw)
In article <4g966j$cr8@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe) writes:
> Simple I/O:
>
> Step 1
> Look it up in the manual
> Step 2
> Do what the Fine Manual says.
>
> *SIMPLE* I/O involves withing and using a couple of standard packages,
> and then using Put, New_Line, Get, and Skip_Line. Pretty darned simple.
> It has not been a problem for first-year students at this university.
>
> Ada does not support Fortran-style formatted I/O, nor PL/I style
> formatted or pictured I/O (but see Interfaces.COBOL).
For most naive (first time users) needs it is even simpler than this.
Here, again, is a version in C and Ada of a simple first program:
First, the Ada (14 lines):
with Ada.Command_Line; use Ada.Command_Line;
with Text_Io; use Text_Io;
procedure X is
begin
Put_Line(
"My name is " & Command_Name & ", I have" &
Integer'Image(Argument_Count) & " arguments.");
Put_Line("They are: ");
for I in 1..Argument_Count loop
Put_Line(" " & Argument(I));
end loop;
end;
$ gnatmake $tests_wrk/x.adb
$ x 1 2 3
My name is x, I have 3 arguments.
They are:
1
2
3
Now the C (14 lines):
#include <stdio.h>
main (argc, argv)
int argc;
char *argv[];
{
int i;
printf ("My name is %s, I have %d arguments \n", argv[0], argc-1);
printf ("They are: \n");
for (i = 1; i < argc; i++)
printf(" %s\n", argv[i]);
}
$ gcc -o cx cx.c
$ cx 1 2 3
My name is cx, I have 3 arguments
They are:
1
2
3
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
617.484.3383
jsa@organon.com
^ permalink raw reply [relevance 0%]
* Re: C/C++ knocks the crap out of Ada
@ 1996-02-19 0:00 4% ` Richard A. O'Keefe
1996-02-20 0:00 7% ` Robert Dewar
0 siblings, 1 reply; 35+ results
From: Richard A. O'Keefe @ 1996-02-19 0:00 UTC (permalink / raw)
rav@goanna.cs.rmit.EDU.AU (++ robin) writes:
>---It's other things besides -- like, how to find a square root, how to do
>simple I/O.
How to do a square root:
Step 1 (applies to all programming languages)
Look up square root in the manual.
Step 2 (applies to all programming languages)
Do what the Fine Manual says.
In Ada, use the index, which points you to A.5.1, and do
with Ada.Numeric_Elementary_Functions;
use Ada.Numeric_Elementary_Functions;
...
sqrt(X)
...
Section G.2.4 even gives you error bounds on the result, which no other
language standard I've checked does. Just because of that, I'd rather
do a square root in Ada than anything else.
Simple I/O:
Step 1
Look it up in the manual
Step 2
Do what the Fine Manual says.
*SIMPLE* I/O involves withing and using a couple of standard packages,
and then using Put, New_Line, Get, and Skip_Line. Pretty darned simple.
It has not been a problem for first-year students at this university.
Ada does not support Fortran-style formatted I/O, nor PL/I style
formatted or pictured I/O (but see Interfaces.COBOL).
--
Election time; but how to get Labour _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
^ permalink raw reply [relevance 4%]
* Re: Is C/C++ the future?
@ 1994-10-26 2:09 6% ` Michael Feldman
0 siblings, 0 replies; 35+ results
From: Michael Feldman @ 1994-10-26 2:09 UTC (permalink / raw)
In article <38k5dg$kko@source.asset.com>,
Michael M. Bishop <bishopm@source.asset.com> wrote:
>It may certainly be true that most Ada projects (certainly large ones)
>require interfaces to external code written in other languages. You're
>also correct in saying that this condition does not make Ada an
>incomplete language. In fact, I believe that the ability to easily
>integrate code written in other languages with Ada code is one of the
>big strengths of Ada. It's vitally important to me because I'm
>developing a Motif application in Ada.
That you are interfacing to Motif code written in C is not due to Ada's
being an incomplete _language_, only due to the fact that not every
library in the world has been (re-)written in Ada.
Indeed, it would be quite foolish to rewrite every bit of existing
library code in Ada - why re-invent the wheel? I'm at a loss to
understand why anyone would trash Ada because the Motif people
chose to write their stuff in C? Ada 83 compilers provide pretty good,
pretty standard, interfaces to other languages, and Ada 9X is improving
that substantially.
Take a look at the niceties in Interfaces.C, Interfaces.Cobol, and
Interfaces.Fortran.
It has always baffled me why anyone would consider the desire (or
need) to link to existing libraries, whatever their language of origin,
as a _disadvantage_ of Ada. Bizarre.
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman - chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University - Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
------------------------------------------------------------------------
Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/
------------------------------------------------------------------------
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------
^ permalink raw reply [relevance 6%]
Results 1-35 of 35 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1994-10-15 17:01 Is C/C++ the future? R. William Beckwith
1994-10-21 11:56 ` James Hopper
1994-10-25 19:36 ` Brad Brahms
1994-10-25 23:46 ` Michael M. Bishop
1994-10-26 2:09 6% ` Michael Feldman
[not found] <00001a73+00002504@msn.com>
[not found] ` <4etcmm$lpd@nova.dimensional.com>
[not found] ` <3114d8fb.5a455349@zesi.ruhr.de>
[not found] ` <4f5h5t$f13@vixen.cso.uiuc.edu>
[not found] ` <4g1bgf$l5@mailhub.scitec.com.au>
[not found] ` <312515DF.7D3B@cmlj.demon.co.uk>
1996-02-18 0:00 ` C/C++ knocks the crap out of Ada ++ robin
1996-02-19 0:00 4% ` Richard A. O'Keefe
1996-02-20 0:00 7% ` Robert Dewar
1996-02-22 0:00 0% ` Richard A. O'Keefe
1996-02-20 0:00 0% ` Jon S Anthony
1996-11-05 0:00 Leading zeros with Int_IO.Put()? Or another package? J.D. Baldwin
1996-11-05 0:00 6% ` Samuel Tardieu
1997-08-21 0:00 SI Units Solicitation - Upgrade from comments William A Whitaker
1997-08-21 0:00 ` Robert Dewar
1997-08-21 0:00 ` Brian Rogoff
1997-08-22 0:00 ` William A Whitaker
1997-08-22 0:00 5% ` Robert Dewar
1998-04-07 0:00 Urgent question: malloc and ada Guido Tesch
1998-04-09 0:00 ` Joe Gwinn
1998-04-10 0:00 ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Larry Kilgallen
1998-04-12 0:00 ` Joe Gwinn
1998-04-14 0:00 ` Robert Dewar
1998-04-16 0:00 ` Joe Gwinn
1998-04-17 0:00 ` Robert Dewar
1998-04-18 0:00 ` Joe Gwinn
1998-04-18 0:00 ` Robert Dewar
1998-04-25 0:00 ` Joe Gwinn
1998-04-26 0:00 ` Robert Dewar
1998-04-26 0:00 ` Jonathan Guthrie
1998-04-30 0:00 7% ` Robert I. Eachus
1998-04-30 0:00 0% ` Urgent question: malloc and ada Larry Kilgallen
1998-05-01 0:00 0% ` Urgent question: malloc and ada...READ/NEW/FOLLOWUP Fergus Henderson
1999-01-27 0:00 Ada 95 LRM Error? Al Christians
1999-01-28 0:00 6% ` Richard D Riehle
1999-01-27 0:00 7% ` Al Christians
1999-01-28 0:00 6% ` Richard D Riehle
1999-01-28 0:00 14% ` Interfaces.Cobol (Was LRM Error?) Al Christians
1999-01-29 0:00 ` Ada 95 LRM Error? robert_dewar
1999-01-31 0:00 ` Keith Thompson
1999-02-01 0:00 4% ` Types (was Ada 95 LRM Error?) Richard D Riehle
1999-01-28 0:00 ` Ada 95 LRM Error? robert_dewar
1999-01-28 0:00 7% ` Al Christians
1999-03-02 0:00 4% fyi: Ada package hierarchy tree nabbasi
2001-06-06 22:06 an interested business-oriented programmer Beard, Frank
2001-06-07 2:52 ` James Rogers
2001-06-07 4:58 6% ` Al Christians
2001-06-07 5:30 0% ` James Rogers
2001-06-07 13:52 0% ` Marin David Condic
2003-08-15 11:59 float with 24-bit resolution mailbox
2003-08-16 15:22 ` Matthew Heaney
2003-08-17 11:46 ` Simon Wright
2003-08-18 10:04 ` Martin Dowie
2003-08-20 19:53 ` Robert I. Eachus
2003-08-20 23:36 ` Ludovic Brenta
2003-08-21 13:54 ` Mark Johnson
2003-08-21 14:35 5% ` Ludovic Brenta
2004-11-08 17:06 Float to String Pascal Obry
2004-11-08 20:18 ` David C. Hoos
2004-11-09 0:40 5% ` John B. Matthews
2004-11-09 5:24 0% ` David C. Hoos, Sr.
2007-07-25 6:50 Just a thought! Xianzheng Zhou
2007-07-25 12:43 4% ` anon
2007-07-26 23:37 0% ` Xianzheng Zhou
2009-06-28 17:56 unsigned type anon
2009-06-28 19:54 ` tmoran
2009-06-29 13:36 ` Rob Solomon
2009-06-29 14:18 ` Ludovic Brenta
2009-07-03 1:41 ` Rob Solomon
2009-07-03 7:12 ` Learning Ada (Was: unsigned type) Jacob Sparre Andersen
2009-07-03 22:20 ` anon
2009-07-04 14:53 ` Georg Bauhaus
2009-07-05 23:21 ` anon
2009-07-06 0:05 7% ` Ludovic Brenta
2010-06-03 2:59 Ada noob here! Is Ada widely used? Yannick Duchêne (Hibou57)
2010-06-04 19:23 ` Fritz Wuehler
2010-06-05 7:47 6% ` Georg Bauhaus
2010-06-05 22:43 0% ` starwars
2016-05-25 21:24 5% Advice, tasking and hardware patrick
2016-05-26 1:09 0% ` Jeffrey R. Carter
2017-08-18 2:23 Please evaluate tiny binding that does not use Interfaces.C patrick
2017-08-18 5:18 ` Per Sandberg
2017-08-18 13:05 6% ` patrick
2018-05-20 11:46 Is this Forum Moderated? patrick
2018-05-20 14:42 ` Simon Wright
2018-05-20 15:18 6% ` patrick
2018-10-15 13:42 Least Dangerous Way to Do This ? patrick
2018-10-15 16:05 ` Simon Wright
2018-10-15 19:28 ` patrick
2018-10-15 19:36 ` patrick
2018-10-16 16:07 7% ` Shark8
2018-10-17 0:09 7% ` patrick
2018-10-17 20:49 7% ` Shark8
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox