Subject: significant blanks

From: [email-masked] (Keith Bierman fpgroup)
Date: Tue, 23 Jun 92 18:38:57 PDT

>> Douglas Walls brought the recent discussions to my attention. I may
>> not have studied them carefully enough, so if I've missed the main
>> points I apologize in advance.
>> 
>> In the free form source (ISO 1539:1991) form, blanks are already
>> significant (3.3.1).
>> 
>> I know that there has been a lot of effort expended to make the HPF
>> additions to the language fit nicely in a subset which looks
>> remarkably like some extended FORTRAN 77s, it would seem that we would
>> be much better off with the Free Form source form (in light of the
>> current discussion).
>> 
>> A separate question, but related in the sense that it too is
>> "spelling" is that of directives versus syntax. When X3H5 faced this
>> question, the vote went to syntax. X3J3 was asked for a sense of the
>> committee (straw vote) and syntax won hands down.
>> 
>> If HPF is sucessful, we'll have codes with these constructs for at
>> least 10-20 years; so using syntax might be a good idea.
>> 
>> Sorry to jump into the middle of things.
>> 
>> khb

---

From: [email-masked]
Date: Wed, 24 Jun 92 09:49:00 -0500

> Date: Tue, 23 Jun 92 18:28:49 PDT
> From: [email-masked] (Keith Bierman fpgroup)
> To: [email-masked], [email-masked]
> Subject: significant blanks

> be much better off with the Free Form source form (in light of the

You're right, there's no problem with significant blanks in free form source.

The problem is, supporting fixed form source is not optional in
Fortran 90.  Nor is it a deprecated feature.  In other words, there
will be programs that count on insignificant blanks for many moons
yet.  As screwey as they make lexing, I don't think we can define HPF
to get rid insignificant blanks.  

> least 10-20 years; so using syntax might be a good idea.

My understanding was that there has been a fair amount of dissention
at X3J3 on this point; apparently I'm wrong.

HPFF went for the following strategy:
	Features that do not affect the value semantics of a program
	(i.e. they don't change the printed answer, like ALIGN) are
	directives that non-HPF compilers can ignore.
	Features that do introduce new semantics (FORALL, new
	intrinsics) are new syntax elements; non-HPF compilers can't
	handle them without change anyway.
The reasoning was to maintain as much backward compatibility (to
workstations, for example) as possible.  I'm happy with that decision,
but if you want to reopen the discussion in this forum I won't stop you.

> Sorry to jump into the middle of things.

What makes you think you're the only one? :-)

	Chuck