Fortran - Re: Why these original FORTRAN quirks?

Author

Re: Why these original FORTRAN quirks?

Richard E Maine

2006-10-18, 7:02 pm

<jmfbahciv@aol.com> wrote:

> In article <1hndkwm.1gruz8s1ka6txoN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) wrote:
> <snip>
>
>
> I'd chop your nine edge off. There is no excuse to do this.

There's no excuse for not being able to forsee multiple decades into the
future? That seems a little harsh. :-(

Elsewhere in my post, I mentioned that one of the ways this comes up is
when new intrinsics are added to the language. Concrete examples in
common practice exist. One particular one that comes to mind...

The old CalComp plotter HCBS (Host Computer Basic Software - I think)
library included an external procedure named SCALE. This library was
widely used in its day. Offshoots of it, using compatible interfaces (or
nearly so - the transition from f66 Hollerith to f77 character caused a
bit of a glitch) continue to be used today. The f90 standard added an
intrinsic named SCALE.

I apologize for my inexcusable use of the HCBS SCALE procedure in 1970
when I first saw it. F90 was only 20 years in the future; I should have
known. :-)

From the other direction, the HCBS library was well enough known that I
was somewhat surprised that the f90 standard added an intrinsic that had
a name conflict with it. But then I've never seen a program that had
much need to use both of them in the same scoping unit. It could
concievably happen, but doesn't seem particularly likely and I haven't
happened to see it. There probably were programs somewhere that broke
because they failed to specify the external attribute for SCALE.

There are several other intrinsics whose names I'm sure I used for local
variables of my own prior to the introduction of the intrinsic into the
language. I couldn't pull out the specific codes right now, but I'm
quite likely to have used names such as index, len, sum, and a few
others at one time or another prior to their standardization as
intrinsics.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Brian Inglis

2006-10-20, 7:02 pm

fOn Fri, 20 Oct 2006 18:47:21 +0000 (UTC) in alt.folklore.computers,
glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:

>In comp.lang.fortran Larry__Weiss <lfw@airmail.net> wrote:
>
>
>Not exactly the same, but WITH always reminded me of
>structure assignment that PL/I has, but many other languages don't.
>
>ANSI C allows passing structures as function arguments, but
>won't do a simple structure assignment. K&R C only allowed
>pointers to structures to be passed to functions.

C89 says:
"6.3.16.1 Simple Assignment
Constraints
....
-- the left operand has a qualified or unqualified version of a
structure or union type compatible with the type of the right;"

so structures and unions can be passed as arguments to and returned as
results from functions and assigned e.g.
struct t v1, v2 = { 0 }; v1 = f( v2 );
is valid.

--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

Brian.Inglis@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]a
b[dot]ca)
fake address use address above to reply

glen herrmannsfeldt

2006-10-20, 7:02 pm

In comp.lang.fortran Brian Inglis <Brian.Inglis@systematicsw.invalid> wrote:
(snip on structure expressions)

> C89 says:
> "6.3.16.1 Simple Assignment
> Constraints

> -- the left operand has a qualified or unqualified version of a
> structure or union type compatible with the type of the right;"

> so structures and unions can be passed as arguments to and returned as
> results from functions and assigned e.g.
> struct t v1, v2 = { 0 }; v1 = f( v2 );
> is valid.

But nothing more than that.

You can't use a struct with any other operators.
You can't assign a scalar expression, or even a constant to
a struct.

v1=0;
v1=v2+1;
v1=v2+v2;

Anything other than v1=v2; or v1=f(v2); doesn't work (at least in C90).

-- glen

jmfbahciv@aol.com

2006-10-30, 7:15 pm

In article <vBr_g.14795$GR.13058@newssvr29.news.prodigy.net>,
Gary Scott <garylscott@sbcglobal.net> wrote:
>Richard Steiner wrote:
>
>I tend to agree in that I never had much difficulty with 6 character
>names because there was considerable discipline used in the naming
>conventions we used. However, moderately increasing the lengths beyond
>6 does provide a modest improvement in readability and you can still use
>a disciplined approach to your naming convention with increased
>flexibility. It used to be common to name OS/macro/JCL commands with
>two letter mnemonics: CO for copy, PR for print, ED for edit. You
>quickly run into the situation where the same two "obvious" characters
>could mean multiple things.

Once you expand the limit, you'll always end up with bit leak
which rapidly becomes bit rot.

Six was sufficient. We used the characters dot and percent
and their position within the six-char field to have meaning.

You could at a glance whether the variable name was an error
code, a word index, a field, an address, a bit mask or a bit
definition.

/BAH

glen herrmannsfeldt

2006-10-30, 7:16 pm

In comp.lang.fortran jmfbahciv@aol.com wrote:
(snip on 6 character symbol length)

> Once you expand the limit, you'll always end up with bit leak
> which rapidly becomes bit rot.

> Six was sufficient. We used the characters dot and percent
> and their position within the six-char field to have meaning.

DEC did like 6 character symbols, with sixbit on 36 bit machines,
and RAD50 on 16 bit machines.

One thing, though, was that DEC assemblers had local symbols.
Between any two normal alphanumeric symbols, you could put
local symbols, which I believe where a digit followed by a $.
That saves a lot of symbol space for real symbols.

IBM S/360 assemblers use eight character symbols, with a
way to generate a unique temporary symbol when needed. The
temporary symbol is some letters followed by a number that is
incremented on each request.

-- glen

> You could at a glance whether the variable name was an error
> code, a word index, a field, an address, a bit mask or a bit
> definition.

Sponsored Links