[J3] Comments on 23-146

[Van Snyder]

The first proposal in 23-146 is for a BITS intrinsic type that has a
KIND parameter to specify the number of bits in the object.

In many applications, a LEN parameter, especially a deferred or assumed
LEN parameter, as in a character object, is more useful.

A LEN parameter can always be turned into a KIND parameter by putting
the object inside a derived type. A KIND parameter cannot be turned
into a LEN parameter.

A competent processor can recognize a constant LEN parameter that is
convenient for it, for example 64 (or a multiple thereof), and optimize
for it.

I assume the desire for BITS extends beyond the bit intrinsics provided
for integers, but with a KIND parameter I don't see much difference. A
SET type might be more useful, with the type of object in the set being
part of the definition. Useful examples would include subranges of
integers, character(1), and enumeration types; these are essentially
subscripts

The third proposal is for double operators in which the second is
unary. That's already allowed for logical operators, as in .and. .not.,
so I assume this is for arithmetic operators. Fortran 66 allowed A**-B
(or maybe it was Fortran II that allowed it and Fortran 66 that
disallowed it). The reasons for removing it ought to be reviewed.

The eighth proposal is for asynchronous tasking. This was provided in
Ada 83. The Ada community eventually concluded the overhead was too
high, and provided "protected variables" as an alternative.These are
essentially coroutines.  If another community has discovered that
something is a bad idea, or maybe a decent but suboptimal idea, it
would be a good idea to study their experience instead of starting with
what they replaced.  "Concurrent and  Real-Time Programming in Ada" by
Alan Burns and Andy Wellings has a good description.

A less flexible alternative to asynchronous tasking is a
PARALLEL...FORK...END PARALLEL construct. Bill Long has pointed out
that this is just syntactic sugar for a DO CONCURRENT construct with a
SELECT CASE inside See 06-187, some of which already is included.

19-108 r1 proposed the PARALLEL construct again, along with the
ASYBCHRONIOUS construct. The Ada community has found security problems,
such as deadlocks and races, with ASYNCHRONOUS blocks, so they decided
not to implement them. The objection to these proposals (as described i
19-108r1) is that they specify a fixed number of parallel sequences,
whereas some applications might want to have a variable number of them.
Each fork does different things, so there would be a fixed number of
different things to do. But it might be desirable to do some of the
things more than one. One could put DO CONCURRENT within a fork, or
allow <loop-control> on each FORK statement within a PARALLEL construct
as syntactic sugar for an embedded DO CONCURRENT, with the default
being "launch only one."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230224/1935d822/attachment.htm>