(j3.2006) late comment

[Lionel, Steve]

Joe Krahn also posted at least some of this in our user forum and there
was some discussion. Part of this turned out to be Joe's
misunderstanding of the issue.  See
http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/302
61876.aspx

Steve

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On
> Behalf Of Van Snyder
> Sent: Tuesday, August 26, 2008 8:19 PM
> To: fortran standards email list for J3
> Subject: Re: (j3.2006) late comment
> 
> 
> On Tue, 2008-08-26 at 19:57 -0400, Dan Nagle wrote:
> > Hello,
> >
> > There appears to be one late comment.
> >
> > FWIW, I've attached it.
> >
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at j3-fortran.org
> > http://j3-fortran.org/mailman/listinfo/j3
> 
>         For intrinsic procedures that return string values, such as
>         ERRMSG, it would be quite useful to allow ERRMSG to refer to
an
>         unallocated
>         allocatable string, which the procedure can automatically
>         allocate to the right length. Alternatively, there should be a
>         way to query the maximum length to avoid truncation, or a
>         mechanism to access ERRMSG strings via an integer error value
>         for errors that have already occurred.
> 
> I proposed this at the Oxford J3 meeting, immediately before the
> Cadarache WG5 meeting in 2000.  The paper didn't get a second, even
> though it had been discussed extensively in pre-meeting
correspondence.
> 
>         Robert Corbett commented on difficulties of type equivalences
>         for
>         SEQUENCE derived types
> 
>         It may not be necessary for the F2008 standard to explicitly
>         define the algorithm needed to distinguish sequence derived
>         types, ...
> 
> A sketch of one is attached.  This is based on the algorithm described
> at http://www.cs.adelaide.edu.au/~idea/idea2/fred.htm (a graph-
> equivalence algorithm), or the one described in Aho, Sethi, and
Ullman,
> Compilers: Principles, Techniques and Tools, Addison Wesley,
> 1988 page 354 Fig 6.6.
> 
>         but it would be good to have an example implementation worked
>         out to ensure that there is a reasonable approach that still
>         fits into the type-matching rules.
> 
> Recursively-related sequence derived types have been around since
1990,
> so processors already know how to do this.  The problem Corbett had
was
> with the description.  The new wrinkle is parameters, which aren't
> discussed in 4.5.2.4p2 of the current draft.
>