Received: by 10.68.129.169 with SMTP id nx9mr11146010pbb.2.1330472533735;
        Tue, 28 Feb 2012 15:42:13 -0800 (PST)
Path: h9ni20729pbe.0!nntp.google.com!news2.google.com!postnews.google.com!b18g2000vbz.googlegroups.com!not-for-mail
From: Robin Vowels <robin.vow...@gmail.com>
Newsgroups: comp.lang.fortran,comp.lang.pl1
Subject: Re: Array constructors and kinds
Date: Tue, 28 Feb 2012 15:42:13 -0800 (PST)
Organization: http://groups.google.com
Lines: 118
Message-ID: <be72b182-e015-4e44-b280-59a3f22d3210@b18g2000vbz.googlegroups.com>
References: <1330137388.326978@athprx03> <9qr2b6F17uU1@mid.individual.net>
 <1kfzhvb.qqvjj91hb5j2aN%nospam@see.signature> <c5ab7192-eeed-4d8f-9a66-8cfeee6fb7a3@z31g2000vbt.googlegroups.com>
 <4F4C7E49.9010701@net-b.de> <7eaa5522-4633-4ca4-a51b-0f9424c7265d@k4g2000yqa.googlegroups.com>
 <4F4CB46F.2090905@net-b.de> <7e5a1d7c-7342-44d4-a666-818903e37f68@p12g2000yqe.googlegroups.com>
 <4F4CF269.7010303@net-b.de>
NNTP-Posting-Host: 123.2.70.40
Mime-Version: 1.0
X-Trace: posting.google.com 1330472533 14908 127.0.0.1 (28 Feb 2012 23:42:13 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 28 Feb 2012 23:42:13 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: b18g2000vbz.googlegroups.com; posting-host=123.2.70.40; posting-account=S_MdrwoAAAD7T2pxG2e393dk6y0tc0Le
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729),gzip(gfe)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Feb 29, 2:27=A0am, Tobias Burnus <bur...@net-b.de> wrote:
> On 02/28/2012 03:08 PM, Robin Vowels wrote:
>
> > On Feb 28, 10:03 pm, Tobias Burnus<bur...@net-b.de> =A0wrote:
> >> However, I found a better example:
>
> >> =A0 =A0 =A0real(selected_real_kind(radix=3D2)) :: b
> >> =A0 =A0 =A0real(selected_real_kind(radix=3D10)) :: d
>
> >> =A0 =A0 =A0call proc([b, d])
>
> >> where "b" is a binary floating-point number (radix=3D2) and "d" is a
> >> decimal floating-point number (radix=3D10). And to make it complete,
> >> "proc" is a generic name for two specific subroutines, one taking a
> >> binary and one taking a decimal floating point number as argument.
> >> However, the same issue occurred for the program as is - with an
> >> implicit interface of "proc".
>
> >> I do not see how this can be solved without a type spec. And, thus, I
> >> don't think that PL/I has solved this 45+ years ago.
>
> > No typespec is required. =A0See my earlier Fortran example.
>
> I disagree:

Did you forget my previous example?

   "Alternatively, it can be written as

   "v =3D (/ v, real( (/ 1, 2, 3, 4, 5 /) ) /)"

which, as I pointed out previously, can be used with pre-F2003
compilers (and subsequent compilers, of course).

> First, will [b, d] be an array of binary or of decimal floating-point
> numbers? At least Fortran does not allow one to mix different
> types/kinds in a single array.

We know this. My example shows how it would be written.

> There is also no obvious solution like
> promoting [1, 1.0, 2.0d0] to an array with double-precision elements.

Use the REAL function, as in my earlier example, with kind.

> And in this example, you cannot even make use of the left-hand side as
> there is none.

No need to, as that's irrelevant anyway.
The LHS (if any) cannot influence what is inside an array constructor
on the RHS -- or any kind of RHS, for that matter.

> Secondly, the Fortran standard mandates:
>
> C4103 (R469) If type-spec is omitted, each ac-value expression in the
> array-constructor shall have the same declared type and kind type
> parameters.

So?  And my example doesn't?

> And:
>
> "If type-spec is omitted, each ac-value expression in the array
> constructor shall have the same length type parameters; in this case,
> the declared type and type parameters of the array constructor are those
> of the ac-value expressions."

That's not relevant.  It's a requirement in Fortran, but not in PL/I,
fortunately.

> Thus, I maintain: One needs a type-spec because the standard mandates
> one and because the there is no obvious choice to which one
> promotes/converts elements in case of mixing binary/decimal values.

See my example.

> In case of mixing integers with reals or single with double precision
> reals, but also in case of character strings, I concur that one could
> implemented a version where different values are automatically promoted
> - be it from integer to real, from single to double precision or to the
> longest string.

Indeed it could have been, and should have been.

> > BTW, a type-spec isn't required in Fortran; it's an option.
>
> But only if all types are the same (cf. Fortran 2008's C4103).

See my example.

> > (Earlier, I gave an example of mixed types, without using a typespec,
> > which can be used with compilers earlier than F2003.)
>
> Well, compilers assume lazy users and allow with default options more
> than the standard mandates. One can argue whether that's good or not. In
> any case, if your compiler allows it with standard checking enabled, it
> is broken.

It's not broken.  Did you try my example?

>
> Additionally, I am sure that for the character example, several (most?
> all?) compilers won't create an array using the longest string, but
> choose, e.g., the length of the first element or of the last argument,
> or of an element where the length is known at compile time or ...

They won't -- nut under the current rules.
I pointed out that it _could_ have been implemented by
choosing the length of the longest string.

> Searching - at run time! - for the element with the longest string
> length is a waste of CPU cycles as it is known that the length of all
> strings is the same. The user has promised that.

Only because those who designed the standard insisted that all the
lengths be the same.  That, however, is a pain in the neck,
as typically the lengths are going to be different. (consider a table
of English words.)