From: Randy Brukardt on 29 Jun 2010 16:30
"Adam Beneschan" <adam(a)irvine.com> wrote in message
>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.
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.
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
> >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.
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
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.
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
> 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.