From J.L.Schonfelder@liverpool.ac.uk Mon Feb 14 13:30:34 1994 Received: from ns.dknet.dk by dkuug.dk with SMTP id AA17014 (5.65c8/IDA-1.4.4j for ); Mon, 14 Feb 1994 15:01:06 +0100 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by ns.dknet.dk with SMTP id AA09991 (5.65c8/IDA-1.4.4j for ); Mon, 14 Feb 1994 14:38:08 +0100 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <25533-0@mailhub.liverpool.ac.uk>; Mon, 14 Feb 1994 13:30:35 +0000 From: "Dr.J.L.Schonfelder" Message-Id: <9402141330.AA18018@uxf.liv.ac.uk> Subject: derived types (fwd) To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Mon, 14 Feb 1994 13:30:34 +0000 (GMT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1667 X-Charset: ASCII X-Char-Esc: 29 Prof L.M. Delves wrote From delves@liverpool.ac.uk Thu Feb 10 13:48:50 1994 From: "Prof L.M. Delves" Message-Id: <9402101348.AA26593@uxb.liv.ac.uk> Subject: derived types To: J.L.Schonfelder@liverpool.ac.uk (Lawrie Schonfelder) Date: Thu, 10 Feb 1994 13:48:28 +0000 (GMT) Cc: peterc@algol.aleph1.co.uk (peter craven), orthog@aleph-one-ltd.co.uk (Dave Lloyd Oxford) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 963 Lawrie Let me make a suggestion for recovering parameter values of derived types: use a notation which is syntactically distinct from either intrinsic functions or field selection. The operation involved is indeed logically distinct, so such a separation is perfectly sensible at the least, and indeed desirable. Obvious suggestion: TYPE parametrised_type(A,N) KIND::A INTEGER(KIND=A)::N : : END TYPE TYPE(parametrised_type)::B : : INTEGER(KIND=b%%A)::c = b%%N : : Note that the example also shows why it is sensible to: 1) Declare all type parameters 2) Treat KIND as a type 3) Allow arrays with non-default-integer dimensions For the primitive types, the syntx should also be allowed: REAL(KIND=kk)::A b = KIND(A) ! as now; or b = A%%KIND Actually, KIND(A) was shortsighted, and illustrates the need to think ahead in designing new features, even if only a limited new facility is to be introduced. Please forward this to WG5/X3J3/anywhere else Mike -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk