J3 Responses to Public Comments

Hello,

J3's response to the public comments
has been posted to J3's web site at

http://www.j3-fortran.org/doc/year/08/08-272.html

html format is used to enable access
to the primary documents as links.

I'm very proud of J3's efforts last week at 185.
9 people in 4.5 days processed about 75 documents.
For each paper, we had to read it, understand it,
analyze it, reckon a response, and then get the words
right to make it happen.

We weren't able to include "large" changes,
but we did include "small" changes where we could.
Where an issue was too difficult, we submitted
an interpretation request to document the issue
for future processing.

--
Cheers!

Dan Nagle

On Wed, 20 Aug 2008 00:02:27 GMT, Dan Nagle posted:

> J3's response to the public comments
> has been posted to J3's web site at
>
> http://www.j3-fortran.org/doc/year/08/08-272.html

Wow, Dan, that looks like a mountain of work.

I noticed in J3's reply to FX a misspelling:

Unfortunately, the premise that intrinsic assignement between character
variables of different kind is allowed is wrong. See table 7.10 on page 152
of the draft: "Type conformance for the intrinsic assignment". Character
assignments are only allowed for "the same kind type parameter". J3
believes the mapping between characters of different kind is difficult to
define. Consequently, J3 declines to make this addition.

Maybe this thread could consider corrections, in particular typos.
--
We must respect the other fellow's religion, but only in the sense and to
the extent that we respect his theory that his wife is beautiful and his
children smart. 5
H. L. Mencken

Hello,

On 2008-08-19 20:23:45 -0400, Ron Ford <ron@example.invalid> said:

> I noticed in J3's reply to FX a misspelling:
>
> Unfortunately, the premise that intrinsic assignement between character
> variables of different kind is allowed is wrong.

Sorry, no one caught it. :-(

--
Cheers!

Dan Nagle

On Wed, 20 Aug 2008 00:42:35 GMT, Dan Nagle posted:

> Hello,
>
> On 2008-08-19 20:23:45 -0400, Ron Ford <ron@example.invalid> said:
>
>> I noticed in J3's reply to FX a misspelling:
>>
>> Unfortunately, the premise that intrinsic assignement between character
>> variables of different kind is allowed is wrong.
>
> Sorry, no one caught it. :-(

There's others, but no big deal: it's way to much pressure to have to think
and spell at the same time. That's why God created peer review.

The response that *really* caught my eye was to Richard, who shares my
opinion regarding f08. (He didn't even ask to borrow it.)

It sounded like something Condoleeza would say.:-(
--
We are here and it is now. Further than that, all human knowledge is
moonshine. 3
H. L. Mencken

Dan Nagle <dannagle@verizon.net> wrote:

> J3's response to the public comments
> has been posted to J3's web site at
>
> http://www.j3-fortran.org/doc/year/08/08-272.html
....
> I'm very proud of J3's efforts last week at 185.

Indeed. Obviously a lot of work there (and handily presented, too; kudos
to whoever did that). On skimming, I find that I disagree with a few
things, to no great surprise, though mostly not major stuff.

I didn't really expect acceptance of my comment, though I felt I should
make it anyway. Probably the one other big thing is about the biggest
single new feature in the draft. I share Bob Corbett's concern about
co-arrays. (Hmm. I haven't studied it, but I wonder if an implementation
might be able to squeek by with allowing only a single image and then
making most of the co-array stuff pretty much collapse into extra rank
of ordinary arrays.)

One somewhat trivial point I noticed. I also disagree with the reply to
Corbett's comment about the multiple models for generic intrinsics
(J32024). The descriptive model for generic intrinsics changed a while
back. I think it was between f90 and f95, but I'd have to go look to
check. It used to be the model of the generic intrinsics being described
as though they were collections of specifics just like user generics.
But that model fell apart, largely for reasons like those mentioned in
the reply. The "new" model (as of f95 or so) is that the intrinsic
generics are described without reference to specifics. I think that new
model should be consistently used everywhere. I thought that it was. It
appears to me that C542 is an erroneous remnant of the older model. I
think Bob has just plain found in this remnant an error that should be
fixed. C542 doesn't even make sense as is; there are no such things as
the specific intrinsic procedures that it talks about (with the very few
exceptions that are holdovers from f66). In some cases, for the reasons
mentioned in the reply, there can't be. Yes, this error isn't new to
f2008; I see the same thing in f2003. But it still ought to be fixed,
probably just by removing that part of the constraint. After all, we do
allow a user to override an intrinsic, and we provide a long and
complicated (largely for historical reasons, I think) algorithm to
define exactly how such overrides work. So I don't see why declaring the
intrinsic attribute explicitly has to suddenly make that a no-no,
particularly when it is as ill-defined as this. I think this one should
be an interp.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Ron Ford wrote:

> On Wed, 20 Aug 2008 00:02:27 GMT, Dan Nagle posted:
>
>
>>J3's response to the public comments
>>has been posted to J3's web site at
>>
>>http://www.j3-fortran.org/doc/year/08/08-272.html
>
>
> Wow, Dan, that looks like a mountain of work.
>
> I noticed in J3's reply to FX a misspelling:
>
> Unfortunately, the premise that intrinsic assignement between character
> variables of different kind is allowed is wrong. See table 7.10 on page 152
> of the draft: "Type conformance for the intrinsic assignment". Character
> assignments are only allowed for "the same kind type parameter". J3
> believes the mapping between characters of different kind is difficult to
> define. Consequently, J3 declines to make this addition.

Would that mapping just constitute the concept of a code page (point)
translation table? That doesn't seem very hard. It could say something
generic like the mapping will achieve to the maximum extent possible the
same character glyph possibly of a different style or typeface. I don't
think anyone would expect a perfect translation since the same glyph
might not even exist in the other character set.

>
> Maybe this thread could consider corrections, in particular typos.


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary Scott <garylscott@sbcglobal.net> wrote:

> Ron Ford wrote:

> > I noticed in J3's reply to FX a misspelling:
> >
> > Unfortunately, the premise that intrinsic assignement between character
> > variables of different kind is allowed is wrong. See table 7.10 on page 152
> > of the draft: "Type conformance for the intrinsic assignment". Character
> > assignments are only allowed for "the same kind type parameter". J3
> > believes the mapping between characters of different kind is difficult to
> > define. Consequently, J3 declines to make this addition.
>
> Would that mapping just constitute the concept of a code page (point)
> translation table? That doesn't seem very hard. It could say something
> generic like the mapping will achieve to the maximum extent possible the
> same character glyph possibly of a different style or typeface. I don't
> think anyone would expect a perfect translation since the same glyph
> might not even exist in the other character set.

Um, you start out by saying it wouldn't be hard. Then you follow on by
waving your arms and saying that the definition would just be to do as
well as possible? Sounds like you pretty much demonstrated the point
that it is hard to define precisely and portably. And if it isn't
precise and portable, then the benefits of "standardizing" it seem
questionable. You'll get different implementations doing it differently,
followed by complaints that the standard didn't actually standardize it
usefully.

It isn't as though it is difficult for the user to do such translation
tables. The main benefit of standardizing it would be the portability...
which you don't get with the arn-waving approach.

Ah. Dinner call. Gotta go. That will have to do, though I don't think I
said some parts very wel.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Richard Maine wrote:

> Gary Scott <garylscott@sbcglobal.net> wrote:
>
>
>>Ron Ford wrote:
>
>
>>>I noticed in J3's reply to FX a misspelling:
>>>
>>>Unfortunately, the premise that intrinsic assignement between character
>>>variables of different kind is allowed is wrong. See table 7.10 on page 152
>>>of the draft: "Type conformance for the intrinsic assignment". Character
>>>assignments are only allowed for "the same kind type parameter". J3
>>>believes the mapping between characters of different kind is difficult to
>>>define. Consequently, J3 declines to make this addition.
>>
>>Would that mapping just constitute the concept of a code page (point)
>>translation table? That doesn't seem very hard. It could say something
>>generic like the mapping will achieve to the maximum extent possible the
>>same character glyph possibly of a different style or typeface. I don't
>>think anyone would expect a perfect translation since the same glyph
>>might not even exist in the other character set.
>
>
> Um, you start out by saying it wouldn't be hard. Then you follow on by
> waving your arms and saying that the definition would just be to do as
> well as possible? Sounds like you pretty much demonstrated the point
> that it is hard to define precisely and portably. And if it isn't
> precise and portable, then the benefits of "standardizing" it seem
> questionable. You'll get different implementations doing it differently,
> followed by complaints that the standard didn't actually standardize it
> usefully.

Theres no arm waving there. It isn't hard to characterize this
functionality. Code point translation is well understood, been
implented in various operating systems and applications for many
decades. A precise definition of the contents of the code pages isn't
necessary to describe the general desired behavior. It isn't a problem
in the mast majority of usages that the mapping isn't perfect, that it
cant handle situations where the glyphs don't exist in one or the other
code page. You could even make those cases a one for one mapping to the
same code point value. Surely there are standards in this area that
could be referenced.

>
> It isn't as though it is difficult for the user to do such translation
> tables. The main benefit of standardizing it would be the portability...
> which you don't get with the arn-waving approach.

No, it isn't difficult for the user to perform such translations, even
in Fortran (much easier in REXX tho). But it would be a nice addition.

>
> Ah. Dinner call. Gotta go. That will have to do, though I don't think I
> said some parts very wel.
>


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary Scott wrote:
....
> [...] Code point translation is well understood, been
> implented in various operating systems and applications for many
> decades. A precise definition of the contents of the code pages isn't
> necessary to describe the general desired behavior. It isn't a
> problem in the mast majority of usages that the mapping isn't
> perfect, that it cant handle situations where the glyphs don't exist
> in one or the other code page. You could even make those cases a one
> for one mapping to the same code point value. Surely there are
> standards in this area that could be referenced.

The problem is that these issues are beyond the scope of the
Fortran standard. I think the committee should just go ahead
with permitting mixed-KIND character operations and use
the "implementation dependent" description. Then in the
section notes they should reference the appropriate other
standards (ASCII, ISO-8859-*, EBCDIC, etc.). Those
other standards are where the appropriate correspondences
are defined.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

"Simplicity is prerequisite for reliability" -- E. W. Dijkstra

Richard Maine schrieb:
[...]
> I didn't really expect acceptance of my comment, though I felt I should
> make it anyway. Probably the one other big thing is about the biggest
> single new feature in the draft. I share Bob Corbett's concern about
> co-arrays. (Hmm. I haven't studied it, but I wonder if an implementation
> might be able to squeek by with allowing only a single image and then
> making most of the co-array stuff pretty much collapse into extra rank
> of ordinary arrays.)
I'm pretty sure such an implementation would be conforming. However there's
a large class of parallel patterns which needs at least two images to run correctly,
and/or without blocking.

[...]