On Feb 29, 2:27 am, 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> wrote:
> >> However, I found a better example:
>
> >> real(selected_real_kind(radix=2)) :: b
> >> real(selected_real_kind(radix=10)) :: d
>
> >> call proc([b, d])
>
> >> where "b" is a binary floating-point number (radix=2) and "d" is a
> >> decimal floating-point number (radix=10). 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. See my earlier Fortran example.
>
> I disagree:
Did you forget my previous example?
"Alternatively, it can be written as
"v = (/ 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.)