Advice on selling Ada to a C shop
in [ADA]
|
From: Randy Brukardt on 29 Jun 2010 16:30 "Adam Beneschan" <adam(a)irvine.com> wrote in message news:f8cf7493-96cf-4265-8e60-28a3945e1169(a)j8g2000yqd.googlegroups.com... .... >I don't think conditional expressions are officially part of Ada yet. >The changes haven't been approved. So if some compiler accepts them, >it's a compiler for some other language that isn't Ada. The ARG approved AI-147 on Sunday, June 20th by a 9-0-0 vote. Note that we had decided long ago to add conditional expressions; we have been hung up on the detailed wording of the resolution rules for them, and whether various obscure cases needed to work properly. For instance: In a function returning T'Class: return (if C then A else B); -- A and B have different types, both covered by T'Class. A conversion: T'Class (if C then A else B); -- A and B as above. The goal was to make them as natural as possible, so ultimately, both of the above were determined to be acceptable. Randy.
From: Adam Beneschan on 29 Jun 2010 16:35 On Jun 29, 1:30 pm, "Randy Brukardt" <ra...(a)rrsoftware.com> wrote: > "Adam Beneschan" <a...(a)irvine.com> wrote in message > > news:f8cf7493-96cf-4265-8e60-28a3945e1169(a)j8g2000yqd.googlegroups.com... > ... > > >I don't think conditional expressions are officially part of Ada yet. > >The changes haven't been approved. So if some compiler accepts them, > >it's a compiler for some other language that isn't Ada. > > The ARG approved AI-147 on Sunday, June 20th by a 9-0-0 vote. Good to know. Thanks for the information. -- Adam
From: Stephen Leake on 1 Jul 2010 07:32 Dennis Lee Bieber <wlfraed(a)ix.netcom.com> writes: > On Tue, 29 Jun 2010 15:30:12 -0500, "Randy Brukardt" > <randy(a)rrsoftware.com> declaimed the following in comp.lang.ada: > > >> In a function returning T'Class: >> return (if C then A else B); -- A and B have different types, both >> covered by T'Class. >> > Ah, at least the syntax reads naturally... I'd have preferred that > Python not have added conditional expressions, but I sure don't like > what they did add: > >>>> A = "It's me" >>>> B = "Not me" >>>> C = True >>>> A if C else B > "It's me" >>>> C = False >>>> A if C else B > 'Not me' >>>> > > I'd have preferred the condition first... That's because you have not been exposed to the Forth language. One of my favorite bumber stickers reads: 4th <heart> if honk -- -- Stephe
From: Per Sandberg on 1 Jul 2010 17:09 I could not more then agree on that on Stephen's comment, I did a major binding to a C-library using -fdump-ada-spec where the library interface contained aprox 150 header files. Never the less I had to write a higher level interface as well to get the API:s in a more reasonable shape from an Ada perspective (there was other requirements as well that mandated the look and feel of the Ada API:s), but that was fairly simple and it was most boring. But to get that amount of validated functionality in a high level language for such a cheap price -:) -:) Of course the amount of work to do this depends on the design and structure of the underlying C API. /P On 06/29/2010 10:42 AM, Stephen Leake wrote: > Warren<ve3wwg(a)gmail.com> writes: > >> ... in a given company, where many >> similar projects are done, you may have large bodies >> of existing library code. It's a tough sell to say >> "rewrite _everything_ in Ada". > > Yes, that's a non-starter. > > Be sure to mention GNAT's -fdump-ada-spec, which generates Ada package > specs from C code. That makes it _much_ easier to import C correctly. >
From: David Thompson on 6 Jul 2010 01:37
On Tue, 22 Jun 2010 22:39:51 -0700, Dennis Lee Bieber <wlfraed(a)ix.netcom.com> wrote: > On Tue, 22 Jun 2010 18:01:50 +0000 (UTC), anon(a)anon.org declaimed the > following in comp.lang.ada: > > > A second problem is until Ada 2012, C is the only common used language > > that allows functions to have "in out" type of parameters. If functions > > having the "in out" parameters, was a good idea, you would think then > > other older languages like Fortran, Pascal would have them. Or even > > Uhm... The last time I worked FORTRAN (about a decade ago), > functions COULD have side-effects. After all, the normal passing method > in FORTRAN is by-reference, and I never encountered a compiler that > would enforce read-only access to arguments inside a function. Now, > maybe post '90/'95 standard have implemented such -- but I'd bet most > shops are still running a compatibility option for older code... Indeed. Classic Fortran did, and F90+ still does by default (i.e. INTENT unspecified) or if you specify INTENT OUTor INOUT. Only if you explicitly make a subprogram PURE or ELEMENTAL then a function, but not a subroutine, is prohibited from having modifiable arguments. (Both a function and subroutine are prohibited from other 'global' side-effects, i.e. on module~package data or external files.) So did Pascal if you specify VAR, a68 with ref, and COBOL and PL/I always. anon may argue that some of those are not now 'common[ly] used', but Java certainly is and makes all nonprimitive arguments writable references; there's not even a syntax to make a reference readonly -- although you can write a target object, or a wrapper or adapter etc., to be readonly (always or controllably) and some important standard objects like java.lang.String are immutable. And C++ of course, but that's arguably covered under C. It does have added syntax for references (and OO 'this') but same semantics. |