[J3] Letter ballot #38 is overdue, please vote ASAP

[Daniel C Chen]

Yes  No   Number    Title

-N-  ---  F18/025  Is component initialization an attribute?
-Y-  ---  F18/033  E/EN/ES/D output exponent when w=0
-Y-  ---  F18/034  Purity of IEEE_GET_FLAG and IEEE_GET_HALTING_MODEz

I share the same concern about adding component initialization as an
attribute and be involved in type determination.

Daniel Chen

XL Fortran Development, Fortran Standard Representative
IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com



From:	"Malcolm Cohen via J3" <j3 at mailman.j3-fortran.org>
To:	"'fortran standards email list for J3'" <j3 at j3-fortran.org>
Cc:	"Malcolm Cohen" <malcolm at nag-j.co.jp>
Date:	2022-01-28 03:44 AM
Subject:	[EXTERNAL] [J3] Letter ballot #38 is overdue, please vote ASAP
Sent by:	"J3" <j3-bounces at mailman.j3-fortran.org>



Hi folks, Sorry I’ve been busy and not chased this up. Any votes that
arrive before I next have a chance to work on it (early next week) will be
counted. Please vote now! Steve has already voted for me.
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
Hi folks,

Sorry I’ve been busy and not chased this up. Any votes that arrive before I
next have a chance to work on it (early next week) will be counted.

Please vote now!

Steve has already voted for me.

On F18/025, I do have some comments.
      Robert argued that the restriction was undesirable because some
      checks were not possible at compile time, because users can provide
      incorrect interface blocks. Well, if we’re letting people have
      incorrect interface blocks (i.e. they are lying to the compiler) to
      evade the restriction, they can just describe an impure procedure as
      PURE, and thus escape *all* the purity requirements. The fact that
      interface blocks cannot be checked at compile time does not make the
      purity requirements less useful, and is just completely immaterial to
      the question at hand.
      The question boils down to whether two types that behave differently
      are “the same type”. In computer science, types that behave
      differently are not the same type. Did we intend to make a “type
      equality” rule that violates both computer science and common sense?
      The evidence available, including the ambiguity of the current
      wording, would suggest not.

Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220131/925daed1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220131/925daed1/attachment.gif>