Path: g2news2.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!nwrddc02.gnilink.net.POSTED!7c706d3b!not-for-mail
From: David Thompson <dave.thomps...@verizon.net>
Newsgroups: comp.lang.fortran
Subject: Re: example of KIND to replace DOUBLE PRECISION
Organization: Poor
Message-ID: <mg7k159kibfdcpfe91vi8av06u34jacd68@4ax.com>
References: <puk80557jmsa4kmd2heorr73jiooavdvts@4ax.com> <QkZMl.2093$_i2.438@bgtnsc04-news.ops.worldnet.att.net> <1ize6mm.18rjon1fbtd8N%nospam@see.signature> <7so905degn0pakttlcpc2rdb1blgo7h86s@4ax.com> <1izf3xf.qwr2a914bzbreN%nospam@see.signature>
X-Newsreader: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 26
Date: Mon, 25 May 2009 05:58:15 GMT
NNTP-Posting-Host: 70.17.60.229
X-Complaints-To: abuse@verizon.net
X-Trace: nwrddc02.gnilink.net 1243231095 70.17.60.229 (Mon, 25 May 2009 01:58:15 EDT)
NNTP-Posting-Date: Mon, 25 May 2009 01:58:15 EDT

On Fri, 8 May 2009 22:33:50 -0700, nos...@see.signature (Richard
Maine) wrote:
<snip: kind numbers>
> No, they wouldn't be reals. That would be just as bad (and probably
> worse). The problem with them being integers (or any numeric type) is
> that it provides no error protection. You can do completely
> inappropriate things with them and the compiler likely won't catch ...
<snip: (distinct) derived types instead>
> In fact, apparently one of the compilers tested tried to do
> something like that and throw an error for the inappropriate usage.
> Unfortunately, with Fortran defined as it is today, that bit of compiler
> help counts as a compiler bug.
> 
Even with integers, I think an implementor could use disjoint ranges.
(Actually, disjoint values is enough, but ranges is easier to explain
and keep straight.) E.g. use 100,101,... for integer kinds,
200,201,... for real (&cplx), 300,301,... for chars, etc. 

> Another advantage is that you wouldn't have to continually caution
> people about how the standard doesn't specify particular numeric values
> for kind parameters. The question just wouldn't come up at all.
> [and...] It generally doesn't make any sense to be doing addition, multiplication,
> exponentiation, and Lord knows what else with kind parameter values.
> 
Doesn't help with those, however.