X3J3/96-163 Date: November 8, 1996 To: X3J3 From: David Epstein Subject: Replies to Henry Zongaro comments on X3J3/96-161 Below is a copy of a note from Henry (with comments on X3J3/96-161) with replies from the Project Editor on lines that begin with #DE# David Epstein ---- Replies to note from Henry Zongaro on paper X3J3/96-161 ------ > - I believe you need a constraint after R306: > "Constraint: must have the PARAMETER attribute." > ##P.E.Reply> > ## No. > ## This is not found in Part1 R307 True, but Part 1 does specify (2.4.3.1.2) that a constant is either a named constant or a literal constant, and that a named constant has the PARAMETER attribute. I don't think the draft of Part 3 specifies the definition of a named constant. You don't necessarily have to make it a constraint, but you should say it somewhere. #DE# Accepted. A constraint has been added. > - In 3.2, in the discussion of coco character context, you need to specify > which characters are permitted. You should be able to scavenge from > Fortran 95 for this. > ##P.E.Reply> > ## Unclear. > ## Where do you see this in Part 1? Part 1 Section 3.3 does not > ## mention anything along those lines. Section 3.3 of Part 1 has a reference to 4.3.2.1, which explicitly states which characters are permitted in a character context. #DE# No change. Section CC3.1 also has a reference to 4.3.2.1. > You also need to indicate that if PARAMETER > appears in the , the s > have the PARAMETER attribute. > ##P.E.Reply> > ## Unclear. > ## It would help me if you pointed out where this is mentioned in Part1? At the beginning of Section 5, it's stated that "All of its attributes may be included in a type declaration statement or may be specified individually in separate specification statements." #DE# Accepted. The beginning of Section CC4 has changed. > - In 4, the constraint after R403, I think this needs to be rephrased as: > "Constraint: The type of a shall not be specified more > than once." > or something along those lines. > ##P.E.Reply> > ## Unclear. > ## How is this better? What about ??INTEGER :: NAME, NAME > ## Do the current words truly need more standardese? I think so. The current constraint reads, "A shall not be the same as any other ." Normally, a constraint applies to the syntax items that appear in the immediately preceding syntax rules, so I take this to say that a in a single must not appear more than once. So the way the current constraint reads, it sounds like this would be permitted: ?? INTEGER :: NAME ?? LOGICAL :: NAME #DE# Accepted. The constraint has changed. > - In 5.2, you need to specify the meanings of the expressions in the same > way that Section 7 of Fortran 95 does. > ##P.E.Reply> > ## Unclear. > ## Could you be more specific? Part 1 Section 7 is quite large. Simply that you have to define what "+" means, and what ".and." means, etc. But it looks like you've done that. #DE# OK. > - In 7, why not use something like "MESSAGE" or "PRINT" rather than "ERROR", > since the purpose of these things is not necessarily for error situations. > ##P.E.Reply> > ## No. > ## The purpose is indeed for error situations only. OK, but what if I what to inform a user about the implications of any command-line values that they've specified? That is, things that aren't necessarily errors. #DE# I don't understand your concerns. > - In 10, R1001 to R1003. I'm not convinced that the option syntax should be > described. You've given suggestions as to how the values could be > communicated to the processor - I think anything more is beyond the scope > of the standard. For instance, the Fortran standard doesn't specify how > the processor is to be told whether a file is in fixed or free source form, > just that there needs to be some way. > ##P.E.Reply> > ## Unclear. > ## Without R1001 to R1003 there cannot be constraints and those constraints > ## are needed. Is it possible to set them apart as a list of rules, and require a processor to detect violations of syntax and constraints, along with those rules? #DE# Don't know. I will ask X3J3 for guidance on this topic.