**************************************************
                                        J3/03-272

Date:      November 11, 2003
To:        J3
From:      Aleksandar Donev (JOR)
Subject:   Proposals from J3/03-258
**************************************************

1.2 "Physical" and "Engineering" Units
Although a relatively large suggestion (in terms , this seems useful to real-life engineers
and other scientific programmers.

1.3.1 Enumerators and Integer Ranges
All of these require further consideration by Data and address a need for enumerated types.

1.3.2 Creating new types from existing ones.
This is a proposal to redo the old TYPEALIAS in a way that creates new types rather then aliases for existing types. We note that this also needs to
work with C interop.

1.4 Updater procedures for components
This is an interesting idea (please note that the latest language that has this is C# in the form of put/get) that merits further
investigation.

1.6 Making INCLUDE more portable and user friendly
JOR does not feel this is the solution to portability problems, but we do feel that the portability of INCLUDE is an important issue to pursue.

1.7 Internal procedures as dummy arguments
Careful consideration should be given to complications arising due to procedure pointers and recursivity.

1.8 Generic Programming Facility
See papers 03-264 and 03-260, which discuss this in detail. Also, a small subset of this is proposed in 2.2.4.

1.9 Exceptions
Further consideration should be given to this long-existing proposal.

2.1.1 Allow declarations inside some or all constructs
Making constructs scoping units may be one way to do this, but other options exist.

2.1.2 EXIT for any labeled construct
The EXIT would apply to the innermost enclosing construct and work for IF, CASE, etc.

2.1.4 Allow triplets in CASE selectors
This regularizes the syntax.

2.1.6 Make construct labels local to the construct

2.1.7 DO UNTIL construct

2.1.8 ON EXIT and ON RETURN sections of constructs
Executed upon an EXIT for a construct. Note that this is related to 2.1.2.

2.2.1 Allow TYPE(intrinsic-type) specification

2.2.2 PARAMETER declarations inside type declarations
Note that likely host association will be used between the type declaration and the enclosing scoping unit.

2.2.3 LIMITed types (no intrinsic assignment for a user-defined type)
NOTE: The following issue should also be considered by JOR and is an existing problem:
Allow intrinsic assignment when defining the body of a defined assignment.
Explanation: When writing the body of a defined assignment, one typically wants to invoke the intrinsic assignment along the way.

2.2.4 Types as (kind) type parameters
But 1.8 is preferred as a more comprehensive solution.

2.2.5 Add an easy way to reference and especially update the real and imaginary number of a complex number (such as x%real and x%imaginary)

2.2.6 Bit datatypes
This should be given careful consideration, and Van's suggestion is only one of many possible routes.

2.2.7 PROTECTED types (no modifications to components other then inside the module where they are defined)
This allows to generalize the PROTECTED attribute in a useful way.

2.3.1 Allow partially specified arguments in generic interfaces
This is related to 2.3.3 and should be considered together.

2.3.2 Use ALLOCATABLE and POINTER attribute in generic resolution
Generic resolution should be considered from a larger pespective and ways to simplify and/or improve it should be considered.

2.3.3 Allow additional OPTIONAL arguments for operators, defined assignment, FINALizers, etc.
Please note that this is in some sense related to 2.3.1 and may be considered together.

_______________________________

1.1 One-sided Coroutines
This requires too large of a change in the implementation and a better alternative is to
allow internal procedures to be passed as actuals (see 1.7)

1.3.3 Make character substrings more similar to array sections
Character strings are different from arrays and should not be confused. Dynamically allocatable strings solve most of the existing problems and the need to use strings as arrays.

1.5 PARALLEL construct
WG5 should make the proposal that parallelism should be pursued, if there is truly sufficient support for it

2.1.3 CASE blocks in SELECT CASE
This introduces a complicated syntax of little utility.

2.1.5 CASE.AND. construct
This also complicates the syntax, and is not really needed. Allowing EXIT and an ON EXIT block is a simpler alternative (see 2.1.8) that will
work just as well.

_______________________________