one-liner for characater replacement
anal...@hotmail.com
Surely this can be done with a one-liner?
Thanks for any responses.
Sjouke Burry
James Giles
> I want to replace every occurrence of a dash in a string by a space.
> Surely this can be done with a one-liner?
A very long and hard to read one-liner, sure. TRANSFER the string
to an array of character (you'll have to do this in two places: the TSOURCE
operand to MERGE, and inside the MASK expression to MERGE), use
MERGE (the FSOURCE operand is, of course, just a space character),
then use TRANSFER again to get the result back into the form of a string.
Unless the above is *very* much faster (or you can prove the code
using it is a *very* critical bottle-neck) you should prefer the more
legible simple scalar loop.
do i = 1, len(string)
if(string(i:i) == '-') String(i:i) = ' '
end do
Of course, you *can* make that a one liner:
do i = 1, len(string); if(string(i:i) == '-') String(i:i) = ' '; end do
--
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
Terence
CALL NODASH(len,string)
I always write a tiny Fortran (or even assembler) routine and add it
to my library if there's a chance of needing it more that once.
James Giles
Well, you shouldn't need to pass the length. The call should be
call replace(string, from, to)
Where FROM is a one character thing to be replaced and TO is
a one character thing to replace FROMs with.
Ron Ford
> anal...@hotmail.com wrote:
>> I want to replace every occurrence of a dash in a string by a space.
>> Surely this can be done with a one-liner?
>
> A very long and hard to read one-liner, sure. TRANSFER the string
> to an array of character (you'll have to do this in two places: the TSOURCE
> operand to MERGE, and inside the MASK expression to MERGE), use
> MERGE (the FSOURCE operand is, of course, just a space character),
> then use TRANSFER again to get the result back into the form of a string.
>
> Unless the above is *very* much faster (or you can prove the code
> using it is a *very* critical bottle-neck) you should prefer the more
> legible simple scalar loop.
>
> do i = 1, len(string)
> if(string(i:i) == '-') String(i:i) = ' '
> end do
>
> Of course, you *can* make that a one liner:
>
> do i = 1, len(string); if(string(i:i) == '-') String(i:i) = ' '; end do
CHARACTER (len=10):: string !line 1
string = "analyst-41"
do i = 1, len(string)
if(string(i:i) == '-') String(i:i) = ' '
end do
do i = 1, len(string); if(string(i:i) == '4') String(i:i) = '*'; end
do
do i = 1, len(string); if(string(i:i) == 'a')&
String(i:i) = 'b'; end do
WRITE(6,*) 'STRING=', STRiNG
end
! end source begin comment
I have a different reason for looking at this. I'm trying to take gdb
through its paces and realize that line numbers might be more important to
gdb than your average windows debugger. These loops behave differently in
salford's debugger.
It takes 20 "step-overs" to get through the first loop, 1 to get over the
second loop (the "do" folded over on posting), and 10 to get through the
ultimate loop.
Salford treats the lines with the continuation as different, so it would
appear that one's line number is exactly what one intuits, and blanks
count. Does anyone have a strategy for figuring out what line in source
he's on, short of counting them out from number one? I was thinking a
helper file might be a good thing, that takes the source and appends '!'
and the line number, not unlike what I did manually to line one above.
Grateful for any tips.
--
Ron Ford
David Frank
<anal...@hotmail.com> wrote in message
news:b35fe8c6-8cb4-49a4...@b1g2000hsg.googlegroups.com...
>I want to replace every occurrence of a dash in a string by a space.
> Surely this can be done with a one-liner?
>
> Thanks for any responses.
Yes it can be a 1-liner.
Below ought to execute as fast, maybe faster since no explicit index
variable is invoked.
! ------------------
program test
integer,parameter :: ML=80 ! max length string processing
character(ML) :: s = 'replace-these-dashs-with-space-with-1-statement'
character :: a(ML) ; equivalence (a,s)
where (a == '-') a = ' ' ! manipulate s string
write (*,*) trim(s)
end program
Walter Spector
> I want to replace every occurrence of a dash in a string by a space.
> Surely this can be done with a one-liner?
Of course.
program nodash
implicit none
character(20), parameter :: test_strings(3) = (/ &
"no-dashes-wanted----", &
"--------------------", &
"++++++++++++++++-+++" &
/)
character(20) :: results(3)
integer :: i,j
do, i=1, size (test_strings)
forall (j=1:len (test_strings)) &
results(i)(j:j) = merge (test_strings(i)(j:j), ' ', test_strings(i)(j:j) /= '-')
end do
print '(a/(a))', 'answers:', results
end program
W.
utab
> <analys...@hotmail.com> wrote in message
>
> news:b35fe8c6-8cb4-49a4...@b1g2000hsg.googlegroups.com...
>
> >I want to replace every occurrence of a dash in a string by a space.
> > Surely this can be done with a one-liner?
>
> > Thanks for any responses.
>
> Yes it can be a 1-liner.
> Below ought to execute as fast, maybe faster since no explicit index
> variable is invoked.
> ! ------------------
> program test
> integer,parameter :: ML=80 ! max length string processing
> character(ML) :: s = 'replace-these-dashs-with-space-with-1-statement'
> character :: a(ML) ; equivalence (a,s)
Why are you creating another name for the string variable s, namely a
in this case
Do you need that?
>
> where (a == '-') a = ' ' ! manipulate s string
this is the trick
David Frank
"utab" <umut....@gmail.com> wrote in message
news:5c1a8340-24b6-43e0...@24g2000hsh.googlegroups.com...
> On May 19, 11:01 am, "David Frank" <dave_fr...@hotmail.com> wrote:
>> <analys...@hotmail.com> wrote in message
>>
>> news:b35fe8c6-8cb4-49a4...@b1g2000hsg.googlegroups.com...
>>
>> >I want to replace every occurrence of a dash in a string by a space.
>> > Surely this can be done with a one-liner?
>>
>> > Thanks for any responses.
>>
>> Yes it can be a 1-liner.
>> Below ought to execute as fast, maybe faster since no explicit index
>> variable is invoked.
>> ! ------------------
>> program test
>> integer,parameter :: ML=80 ! max length string processing
>> character(ML) :: s = 'replace-these-dashs-with-space-with-1-statement'
>> character :: a(ML) ; equivalence (a,s)
>
> Why are you creating another name for the string variable s, namely a
> in this case
>
> Do you need that?
>
Yes, the where statement requires its argument to be an array, my string
variable is a scalar.
James Van Buskirk
news:wMudnfL3AePLRazV...@earthlink.com...
> Yes, the where statement requires its argument to be an array, my string
> variable is a scalar.
You could also have used a scalar-mask-expr in a FORALL statement,
combining your solution with that of Walter Spector. In that way
you get a brief statement without requiring EQUIVALENCE which isn't
possible for most kinds of data objects. The TRANSFER solution
alluded to by James Giles has the advantage that it doesn't change
its inputs.
C:\gfortran\clf\remove_dash>type remove_dash.f90
program remove_dash
character(*), parameter :: ps = 'replace-these-dashs-with'// &
'-space-with-1-statement'
character(len(ps)) :: s = ps
character, parameter :: q(1) = 'x'
print*, transfer(merge(transfer(s,q),' ',transfer(s,q)/='-'),s)
forall(i=1:len(s),s(i:i)=='-') s(i:i) = ' '
print*, s
end program remove_dash
C:\gfortran\clf\remove_dash>gfortran remove_dash.f90 -oremove_dash
C:\gfortran\clf\remove_dash>remove_dash
replace these dashs with space with 1 statement
replace these dashs with space with 1 statement
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
anal...@hotmail.com
wrote:
Thats great (and thanks David also).
Shouldn't things like this be offered as an intrinsic sub-program as
part of the language? After all this is 2008 and we have accumulated
a vast store of knowledge as to routine things programs need to do
which ought to be part of the language itself and instead requring
explicit code.
James Giles
...
> Shouldn't things like this be offered as an intrinsic sub-program as
No. I think most such things should be added as standardized
module procedures. That is, they aren't intrinsics (and therefore
don't clutter your namespace). You get them by USEing the
appropriate MODULE.
Now, the module probably *should* be one of the new fangled
"intrinsic" modules. That is, it should be built into the compiler
that supports it and the programmer needn't worry about where
its source is, or whether it's been compiled in the correct order
or anything like that. And, like all modules, the fact that dependent
compilation is happening anyway, the compiler should be free
to inline the module procedures. This shuld especially be true
of "intrinsic" modules.
anal...@hotmail.com
> analys...@hotmail.com wrote:
>
> ...
>
> > Shouldn't things like this be offered as an intrinsic sub-program as
> > part of the language? [...]
>
> No. I think most such things should be added as standardized
> module procedures. That is, they aren't intrinsics (and therefore
> don't clutter your namespace). You get them by USEing the
> appropriate MODULE.
>
> Now, the module probably *should* be one of the new fangled
> "intrinsic" modules. That is, it should be built into the compiler
> that supports it and the programmer needn't worry about where
> its source is, or whether it's been compiled in the correct order
> or anything like that. And, like all modules, the fact that dependent
> compilation is happening anyway, the compiler should be free
> to inline the module procedures. This shuld especially be true
> of "intrinsic" modules.
>
So in the future, the language will have standardized intrinsic
modules (you seem to be somewhat against them) that would include
procedures to do things like this?
That makes a lot of sense. The more we hide away the "slashqz"s and
laborious repetition of the same constructs, the more easily programs
can be seen to be isomorphic to the programming task being
accomplished.
I think things like this would make it easier to achieve the first
alternative in your sig line.
Also by the way (at the risk of igniting a flame war) I have now come
to the conclusion that the use-base shrinkage of Fortran did not
happen for any irrational reasons as is often postulated in this ng.
The absence of little things like testing for a <= x <= b naturally
has a cumulative effect on the objective desirability of using a
language. Writing three lines each time to achieve something that
ought to be achieved in one (or having to write the above expression
in Fortran's stilted syntax) would tend to fatigue the programmer
making him more susceptible to errors. I suspect that these subtle
factors ultimately showed up in the form of actual defects,
maintainability etc. of fortran programs running in commercial
environments, therby reducing its use in that arena drastically.
James Giles
> On May 20, 2:19 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
>> analys...@hotmail.com wrote:
>>
>> ...
>>
>>> Shouldn't things like this be offered as an intrinsic sub-program as
>>> part of the language? [...]
>>
>> No. I think most such things should be added as standardized
>> module procedures. That is, they aren't intrinsics (and therefore
>> don't clutter your namespace). You get them by USEing the
>> appropriate MODULE.
>>
>> Now, the module probably *should* be one of the new fangled
>> "intrinsic" modules. That is, it should be built into the compiler
>> that supports it and the programmer needn't worry about where
>> its source is, or whether it's been compiled in the correct order
>> or anything like that. And, like all modules, the fact that dependent
>> compilation is happening anyway, the compiler should be free
>> of "intrinsic" modules.
>>
>
> So in the future, the language will have standardized intrinsic
> modules (you seem to be somewhat against them) that would include
> procedures to do things like this?
Since I'm strongly recommending them, why would you think
I have something against them? To be sure, I find the term
"intrinsic" ill suited to modules. But maybe that's a matter
of unfamiliarity anyway. Rergardless of the term though,
I think that's the best model for new standardized procedures.
I just wish they had applied it earlier. There are several things
that are just plain intrinsics that clutter the namespace and shouldn't.
In fact, I'm leaning toward the idea that *no* intrinsics and few
operators should be in a language without having to USE to
get them.
.......................
> The absence of little things like testing for a <= x <= b naturally
> has a cumulative effect on the objective desirability of using a
> language. [...]
The easiest is to have a function that applies to rank-1 arrays and
returns true only if all the elements are in ascending order:
if (ascending([a, x, b])) ...
Even so, you would have to have several to accomodate things
like <= vs. <, and users would probably insist on the DESCENDING
set of functions as well. Or, maybe you could have another operator
like:
if (x .in. [a, b]) ...
But again, you would probably have to accomodate open vs. closed
vs. half-open intervals.
It's not actually a simple thing you are asking for. I've tried quite
a number of different approaches to this very problem and have yet
be even marginally satisfied.
Jan Vorbrüggen
> has a cumulative effect on the objective desirability of using a
> language.
The presence of such little things has a cumulative effect...Note that
defining the correct semantics for these and similar "little things",
including all of their interactions with the rest of the language, has
been and still is a huge stumbling block for C et al. I doubt that there
are more than a handful of people world-wide who really know all of the
pitfalls this generates, and can write code (if they were to do such a
lowly thing) that avoids them.
For me, this amounts to saying that there is this wonderful dish made of
fish (called fugu, BTW), but there are only a few people who can prepare
it in such a way that you don't risk death through consumption. Thanks
but no thanks - any normal restaurant with, say, two Michelin stars will
do fine for me.
Jan
rudra
if you want to edit your output in unix editor(vi say), you can always
do that with :%s/-/ /g
else, you can always opt for "awk"
Steven G. Kargl
tr or sed would be better choices than awk.
mobile:kargl[208] cat infile
kl-jk
-df-op-
mobile:kargl[209] tr "-" " " < infile
kl jk
df op
mobile:kargl[210] cat infile | sed s/-/\ /g
kl jk
df op
anal...@hotmail.com
wrote:
> > The absence of little things like testing for a <= x <= b naturally
> > has a cumulative effect on the objective desirability of using a
> > language.
>
> The presence of such little things has a cumulative effect...Note that
> defining the correct semantics for these and similar "little things",
> including all of their interactions with the rest of the language,
which language?
could testing for a <= x <= b have been added fairly easily to f77?
If the mass of complexity that has been added to f77 has made this
next to impossible, then that is regrettable.
James Van Buskirk
news:93b98c60-dc14-40eb...@x35g2000hsb.googlegroups.com...
On May 21, 6:06 am, Jan Vorbrüggen <Jan.Vorbrueg...@not-thomson.net>
wrote:
> > > The absence of little things like testing for a <= x <= b naturally
> > > has a cumulative effect on the objective desirability of using a
> > > language.
> > The presence of such little things has a cumulative effect...Note that
> > defining the correct semantics for these and similar "little things",
> > including all of their interactions with the rest of the language,
> which language?
> could testing for a <= x <= b have been added fairly easily to f77?
> If the mass of complexity that has been added to f77 has made this
> next to impossible, then that is regrettable.
Given that a, x, and b could each be any of 5 integer or 3 real
kinds in gfortran for one example, and considering that you wouldn't
want to disallow syntax like a > x >= b, I am getting a count of
8*2*8*2*8*2 = 4096 operators that would have to be implemented and
tested. Numeric comparison currently stands at (real or integer)
.op. (real or integer): 8*6*8 = 384, complex .op. complex: 3*2*3 = 18
character comparison: 1*6*1 = 6 (or maybe 12: can you compare
character variables of different kinds?) logical comparison is
5*2*5 = 50, so we have about 384+18+6+50 = 458 operators to
implement and test. The new syntax suggested is in itself 8.94X
as many operators (not counting character forms) as all existing
comparison operators put together. The complexity goes up for
f90 where the operators would have to be elemental.
anal...@hotmail.com
wrote:
> <analys...@hotmail.com> wrote in message
I know litle about compiler construction, but given that
(a op x .and. x op b) can be implemented, wouldn't it be possible to
deduce that
(a op x op b) is supposed to mean the above?
Richard Maine
> <anal...@hotmail.com> wrote in message
> news:93b98c60-dc14-40eb...@x35g2000hsb.googlegroups.com...
> > could testing for a <= x <= b have been added fairly easily to f77?
> I am getting a count of
> 8*2*8*2*8*2 = 4096 operators that would have to be implemented and
> tested.
That's not counting the difficulty of precisely and unambiguously
specifying the rules for parsing such things. You can't just say "define
these operators" and wave your hands. You have to define precisely how
they fit into the whole form of expressions. That is *NOT* trivial. Nor
was it trivial in f77.
I'm not even going to try to describe the details; I haven't even sat
down to try to think through them to come up with examples of the
issues. Too much bother. (In particular, it is *WAY* to much bother to
answer a question from analyst41. He has been on my killfile for years
and I don't feel particularly charitable in terms of spending any more
of my time for his benefit. His quota is long used up. I wouldn't have
seen his post if you hadn't quoted it.)
I'l just claim that, if someone hasn't say down with the actual text of
that part of the standard, made at least some attempt to write out the
proposed changes and then verify that the result is precise and
unambiguous, they aren't likely to be in a good position to appreciate
the issues. Pretty much anything short of that counts as "hand waving."
Yes, the "hand-waving" description applies to this post of mine as well.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
James Van Buskirk
news:a2ad6f7c-ec44-46c7...@d77g2000hsb.googlegroups.com...
> I know litle about compiler construction, but given that
> (a op x .and. x op b) can be implemented, wouldn't it be possible to
> deduce that
> (a op x op b) is supposed to mean the above?
First off, I forgot about complex .op. (real or integer) and converse
for 3*2*8*2 = 96 cases giving a count of 554 perexisting operators
and a ratio of 4096/554 = 7.39 (or maybe 4104/554 = 7.41 -- I forgot
about character .op. character .op. character.
The compiler still has to detect and implement all possible cases,
and since in f95 there has to be 3 compilers, this is a lot of
work considering that you could have written a function like
IS_NONDECREASING(array, n) or even used an expression like
abs(2*x-(a+b)) <= b-a
there wouldn't be much benefit from all the added complexity.
James Giles
...
> could testing for a <= x <= b have been added fairly easily to f77?
>
> If the mass of complexity that has been added to f77 has made this
> next to impossible, then that is regrettable.
It's not the complexity but the feature that's bad. In addition to
the problems others have cited, there's the fact that A, B, and
X are allowed to themselves be large expressions. Sure. it
looks simple as you write a canonical example. But what
of:
if (a_very_ling expression <= another_long_expression <= &
a_third_very_long_expression) ...
How does the compiler know that the user didn't inadvertently
leave out an .AND. operator that was supposed to be in the
middle of the second expression? How does the programmer
even know that? One of the advantages of limiting operator
fixity is that common errors are rarer and easier for both
the compiler and the programmer to detect.
Further, once you have that operator, why not all the others
people often informally use? How about the following tests
all involving inclusion in interval [a,b]:
a <= x < y <= b ! X and Y are distinct and in order
a <= x,y <= b ! X and Y are maybe equal, or in either order
a > x > b ! X is outside the interval (?!?)
Finally, distributed fixity (of which this is an example) is known,
by direct productivity experiments, to be a bad idea. Even experts
in programming are prone to errors with such features. Such errors
once made are *usually* of that variety that are hard to find and
correct - even if you recognize the program's plausible wrong
answers are at fault at all. Such productivity experiments match
my experience with large user communities. I find this last argument
compelling.
Now, some whole languages get this wrong. In C, (a<x<b) is defined
and *doesn't* do anything particularly useful. I don't remember many
languages which permit this - and get it right.
glen herrmannsfeldt
> anal...@hotmail.com wrote:
>>could testing for a <= x <= b have been added fairly easily to f77?
(snip)
> It's not the complexity but the feature that's bad. In addition to
> the problems others have cited, there's the fact that A, B, and
> X are allowed to themselves be large expressions. Sure. it
> looks simple as you write a canonical example. But what
> of:
> if (a_very_ling expression <= another_long_expression <= &
> a_third_very_long_expression) ...
> How does the compiler know that the user didn't inadvertently
> leave out an .AND. operator that was supposed to be in the
> middle of the second expression?
Not that I think it is a good feature, but this is a
strange reason. There are many mistakes that programmers
can make that it is impossible for compilers to detect.
Precedence is convenient in allowing some more readable
forms without parenthesis, but in other cases it makes
them less readable.
> How does the programmer
> even know that? One of the advantages of limiting operator
> fixity is that common errors are rarer and easier for both
> the compiler and the programmer to detect.
(snip)
> Finally, distributed fixity (of which this is an example) is known,
> by direct productivity experiments, to be a bad idea. Even experts
> in programming are prone to errors with such features. Such errors
> once made are *usually* of that variety that are hard to find and
> correct - even if you recognize the program's plausible wrong
> answers are at fault at all. Such productivity experiments match
> my experience with large user communities. I find this last argument
> compelling.
> Now, some whole languages get this wrong. In C, (a<x<b) is defined
> and *doesn't* do anything particularly useful. I don't remember many
> languages which permit this - and get it right.
The only one I know is Mathematica. Maybe because it is designed
more around (theoretical) mathematical notation than most languages.
It translates to the internal form Less[a,x,b], where it makes
a little more sense. I might have thought Mathematica wouldn't
allow mixed forms, but it does. That is, a<x<=b also works,
but presumably has a more complex internal form.
As you know, it won't work in any language where relational
operators have numerical values, such as C. Many Fortran
systems allow conversion between integer and logical, such
that these forms are legal and have a different meaning.
Java specifically does not convert between boolean and
numeric types, though I don't believe there is any interest
in adding it.
In PL/I, relational operators have a BIT(1) result
(that is, bit string of length 1). Conversions between
BIT and integer values are done when needed. I am not
sure, though, for a<x<b if it converts BIT to integer,
or numeric to a BIT string. (Relational operators
can be applied to BIT strings similar to they way
they work on CHAR strings, and unlike the way they
work on numeric values.)
-- glen
James Giles
...
> Not that I think it is a good feature, but this is a
> strange reason. There are many mistakes that programmers
> can make that it is impossible for compilers to detect.
Yes, and there are many errors that are rarer or even eliminated
by careful design of the language. The fact that you can't
make the language perfect is no reason to make it as bad
as you can. Features that introduce few real advantages
and are _KNOWN_ to be the source of error are to be
avoided. Unfortunately there are few experiments intended
to identify error-prone vs. ergonomic features any more. :-(
That's no reason not to use experience with user's problems
and past such experiments as a guide.
Frankly I actually find something like IN(x,[a.b]) or even
INORDER([a,x,b]) more legible.
glen herrmannsfeldt
(I wrote)
>>Not that I think it is a good feature, but this is a
>>strange reason. There are many mistakes that programmers
>>can make that it is impossible for compilers to detect.
> Yes, and there are many errors that are rarer or even eliminated
> by careful design of the language. The fact that you can't
> make the language perfect is no reason to make it as bad
> as you can. Features that introduce few real advantages
> and are _KNOWN_ to be the source of error are to be
> avoided.
It is, though, a balance between being general and the
ability to detect some errors.
The C ability to do assignment inside expressions is
a result of generalizing assignment to an operator.
It also allows the common error of using the wrong
operator in if statements.
if(a=b) statement;
when one wanted
if(a==b) statement;
To fix this, Java requires the expression in if to be
boolean, in which case the error only appears doing
equality tests for boolean variables. (Legal in Java.)
I agree one shouldn't try to make a language bad,
but in some cases generalizations can be good when
used one way, bad another way.
-- glen
James Giles
...
> The C ability to do assignment inside expressions is
> a result of generalizing assignment to an operator.
> It also allows the common error of using the wrong
> operator in if statements.
>
> if(a=b) statement;
>
> when one wanted
>
> if(a==b) statement;
It causes a number of errors unrelated to that one. So
called "expression languages", where assignment (and
some other things which are usually statements) can be
used in expressions are known to be significant causes
of decreased programmer productivity. Usually for
the same reasons that many people want to eliminate
side-effects from functions.
Functions with side-effects are tough enough to deal with
(but are hard not to allow in imperative languages). There's
no call to gratuitously increase side-effects within expressions.
...
> I agree one shouldn't try to make a language bad,
> but in some cases generalizations can be good when
> used one way, bad another way.
But, the language designer can't control usages, only what
features are present and what they mean. A feature known
to decrease productivity, even among seasoned programmers,
is to be avoided.
anal...@hotmail.com
wrote:
> <analys...@hotmail.com> wrote in message
>
> news:a2ad6f7c-ec44-46c7...@d77g2000hsb.googlegroups.com...
>
> > I know litle about compiler construction, but given that
> > (a op x .and. x op b) can be implemented, wouldn't it be possible to
> > deduce that
> > (a op x op b) is supposed to mean the above?
>
> First off, I forgot about complex .op. (real or integer) and converse
> for 3*2*8*2 = 96 cases giving a count of 554 perexisting operators
> and a ratio of 4096/554 = 7.39 (or maybe 4104/554 = 7.41 -- I forgot
> about character .op. character .op. character.
>
> The compiler still has to detect and implement all possible cases,
> and since in f95 there has to be 3 compilers, this is a lot of
> work considering that you could have written a function like
> IS_NONDECREASING(array, n) or even used an expression like
>
> abs(2*x-(a+b)) <= b-a
you gotta be kidding.
You din't answer my question:
If (a1 op1 a2 .and. a2 op2 a3 .and......and.a9 op9 a10)
can be interpreted correctly (I left out parentheses assuming that
".and." takes precedence over all the operatations involved), what are
the issues connected with interpreting
a1 op1 a2 op2 a3.....a9 op9 a10
as equivalent to the first expression?
glen herrmannsfeldt
(snip)
> If (a1 op1 a2 .and. a2 op2 a3 .and......and.a9 op9 a10)
> can be interpreted correctly (I left out parentheses assuming that
> ".and." takes precedence over all the operatations involved), what are
> the issues connected with interpreting
It is incompatible with the extension of treating logical
values as integers, which many compilers do.
The advantage is very small.
How about a statement function:
less(a,b,c)=(a.lt.b.and.b.lt.c)
-- glen
anal...@hotmail.com
wrote:
If there is a valid reason for not allowing A < B < C, then thats that
but all the workarounds that have been offered to avoid (a < b .and. b
< c) are simply awful.
I wonder if features are getting added/not added to fortran without
any strategic thought as to its natural domain of application and its
look and feel.
Since C interoperability has been added, that ought to take care of
the ability to control where every bit and byte starts out and ends
up.
Fortran's core strength has always been arrays and for the vast mass
of looping through arrays, SQL like whole array operations out to
improve the look and feel of fortran code for rapid prototyping.
prototypes should allow easy QA and hew as close to the task being
accomplished as possible.
In many "throw away" coding instances, the prototype would be fast
enough. Turning in into production code can then be accomplished with
the correct answers from the prototype to check against.
I also think mutiplying the kinds of available floating point and
integer numbers has been a colossal mistake. Kinds different from the
default should have been realized through libraries and not entered
the language itself.
The language as it stands seems to be loaded with features that are
mostly useless in its domain of application and still lacks simple
features that are by now pretty much universally acknowledged as
desirable, even essential.
Gary Scott
--
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
James Giles
...
> Since C interoperability has been added, that ought to take care of
> the ability to control where every bit and byte starts out and ends
> up.
Not even close. That's the kind of thing that's explicitly left out
of C interop so far. If a C struct has bit-resolution component
sizes, there is no way to declare a Fortran derived type to
correspond.
...
> I also think mutiplying the kinds of available floating point and
> integer numbers has been a colossal mistake. Kinds different from the
> default should have been realized through libraries and not entered
> the language itself.
I think the concept of KIND was a mistake. I think decimal float
will be a big mistake. I think multiple integer and real types is
merely a recognition of common practice. Implementors have
always had nonstandard support for multiple sizes of integers.
Many have had more than two floats (and that will soon be a
necessity, as more people find single precision inadequate, and
more people at least occasionally need more than double).
...
> The language as it stands seems to be loaded with features that are
> mostly useless in its domain of application and still lacks simple
> features that are by now pretty much universally acknowledged as
> desirable, even essential.
I can only think of a few things in this last category. Most people
have long assumed that some simple form of stantardized macros
was overdue (like: since the late 1970's). Some sort of variant
derived type is widely desired. Unsigned integers are on the list.
And bit strings. (Though what some people expect bit strings to
be is difficult to discern. One person that frequently mentions
them has explicitly rejected in past discussions the idea that
they should be strings whose components are bits.)
I don't think any of these qualify as "essential".
I think that a clean way to declare generic procedures is needed.
(No CLASS(*) isn't an example. I want something that doesn't
simply turn the language into a "typeless' one.)
A feature like A < X < B was certainly *not* "universally acknowledged
as desirable, even essential". C allows the syntax, but the semantics is
vastly different than you desire (and is almost always a mistake).
Other than that, I can't find any mention of it in any literature on
popular language features. And if it's in many languages, it's not
a feature that makes their public lists of important features.
Gary Scott
I think that would be a fine implementation of a bit string, a string of
bits, exactly what I want (to access the individual substrings using
character string syntax). Just don't limit it to some arbitrarily small
length (number of bits in the string).
<snip>
James Giles
> [...](Though what some people expect bit strings to
>> be is difficult to discern. One person that frequently mentions
>> them has explicitly rejected in past discussions the idea that
>> they should be strings whose components are bits.)
>
> I think that would be a fine implementation of a bit string, a string
> of bits, exactly what I want (to access the individual substrings
> using character string syntax). Just don't limit it to some
> arbitrarily small length (number of bits in the string).
But I've actually posted proposals that include that capability
quite explicitly and you've said that it wasn't what you wanted.
A string is (ought to be) an arbitrarily long sequence of some
base type. Stringness should be an orthogonal attribute to base
type - that is, you should be able to have strings of anything
you like. You should be able to declare a maximum length
of a string, or allow it to be dynamically allocated.
The differences between a string and a rank-1 array should be:
1) assingment not required to be conformable with strings;
2) string comparisons should be lexicographic, not elemental;
3) concatenate should be defined on strings. Seems to me I
once came across another legitimate difference between strings
and arrays, but I can't recall it now. Given that strings should
otherwise be interoperable with rank-1 arrays (provided the
length of the string is the same as the size of the array, even
elemental operations should interoperate), and that arrayness
is also orthogonal to base type, you can choose which concept
is appropriate at will.
One particular similarity should be that if MYSTRING is a sring
(of any base type), then MYSTRING(i) should be the I'th element
of MYSTRING. You should *not* need to say MYSTRING(i:i).
You should be permitted to use the colon notation (just like you can
with rank-1 arrays), but it shouldn't be required.
Now, given strings defined that way, all that's needed to support
bit strings is some base data type that's one bit long. In Fortran,
bit-wise operations are defined on the INTEGER data type. So,
that seems the most appropriate place. If we had bit-resolution
INTEGER KINDs, it would permit declaring one-bit integers as
a base type for arrays, strings, and anything else we choose to
support as collection attributes (linked-lists, bags, trees, stacks,
and so on). Voila! Bit strings.
Bit resolution KINDs are useful independent of strings/arrays.
Many system programming tasks involve the use of derived
types with fields whose size is specified with bit-resolution.
C calls these "bit fields".
You've explicitly rejected this proposal before.
Gary Scott
> Gary Scott wrote:
>
>>[...](Though what some people expect bit strings to
>>
>>>be is difficult to discern. One person that frequently mentions
>>>them has explicitly rejected in past discussions the idea that
>>>they should be strings whose components are bits.)
>>
>>I think that would be a fine implementation of a bit string, a string
>>of bits, exactly what I want (to access the individual substrings
>>using character string syntax). Just don't limit it to some
>>arbitrarily small length (number of bits in the string).
>
>
> But I've actually posted proposals that include that capability
> quite explicitly and you've said that it wasn't what you wanted.
>
I'm afraid I don't recall. I doubt I would have been opposed to it but
I think all of my public commentary was relative to "typeless". I'm
perfectly happy with a basic feature. I longer term desire though is
for it to evolve into something more flexible and feature rich (a bit
string is just a small part of it). However, I can emulate the features
I want now, so anything that gets added would likely serve little else
but to reduce the complexity a bit.
I don't recall having done that (not saying I didn't leave that
impression, but it would have been accidental). I may have rejected
TYPELESS/BITS.
Ron Ford
> James Giles wrote:
>> Gary Scott wrote:
>>
>>>[...](Though what some people expect bit strings to
>>>
>>>>be is difficult to discern. One person that frequently mentions
>>>>them has explicitly rejected in past discussions the idea that
>>>>they should be strings whose components are bits.)
>>>
>>>I think that would be a fine implementation of a bit string, a string
>>>of bits, exactly what I want (to access the individual substrings
>>>using character string syntax). Just don't limit it to some
>>>arbitrarily small length (number of bits in the string).
>>
>>
>> But I've actually posted proposals that include that capability
>> quite explicitly and you've said that it wasn't what you wanted.
>>
>
> I'm afraid I don't recall. I doubt I would have been opposed to it but
> I think all of my public commentary was relative to "typeless". I'm
> perfectly happy with a basic feature. I longer term desire though is
> for it to evolve into something more flexible and feature rich (a bit
> string is just a small part of it). However, I can emulate the features
> I want now, so anything that gets added would likely serve little else
> but to reduce the complexity a bit.
I would put forth that their disagreement reflects that a large language
has users with differing concerns.
Is James' string notion anywhere near feasible?
--
Ron Ford
James Giles
>> The language as it stands seems to be loaded with features that are
>> mostly useless in its domain of application and still lacks simple
>> features that are by now pretty much universally acknowledged as
>> desirable, even essential.
>
> I can only think of a few things in this last category. Most people
> have long assumed that some simple form of stantardized macros
> was overdue (like: since the late 1970's). Some sort of variant
> derived type is widely desired. Unsigned integers are on the list.
> And bit strings. (Though what some people expect bit strings to
> be is difficult to discern. One person that frequently mentions
> them has explicitly rejected in past discussions the idea that
> they should be strings whose components are bits.)
>
> I don't think any of these qualify as "essential".
OK. Exception handling also is long overdue. I suspect that
it's not in the standard because there are too many distinct
ways of doing it - none of which are obviously superior,
yet each is oncompatible with the others. The committee
probably can't decide on a particular one. (You know how
it is: everyone has a strong preference and a strong aversion
to everyone else's preference. So even though they may all
agree that something should be done, they don't do it.)
anal...@hotmail.com
> James Giles wrote:
>
> - Show quoted text -
In order to determine where Fortran ought to go from here - do you
think the following strategic question needs to be asked and if so
what would be your answer?
As we speak now, is Fortran any longer a viable choice for software
developed and maintained by one organization intended to be sold to
others with customer service and other paraphernelia of commercial
software development?
In fact, I remember reading in this ng. that commercial Fortran
compilers themselves might no longer be viable.
If the answer (as I suspect it is) is that Fortran can only live on in
non-profit organizations, I think that should impact how the language
evolves in the future.
James Giles
...
> In order to determine where Fortran ought to go from here - do you
> think the following strategic question needs to be asked and if so
> what would be your answer?
>
> As we speak now, is Fortran any longer a viable choice for software
> developed and maintained by one organization intended to be sold to
> others with customer service and other paraphernelia of commercial
> software development?
>
> In fact, I remember reading in this ng. that commercial Fortran
> compilers themselves might no longer be viable.
>
> If the answer (as I suspect it is) is that Fortran can only live on in
> non-profit organizations, I think that should impact how the language
> evolves in the future.
I can't see the relevance. Certainly existing software companies
believe that Fortran is a viable product. They still have reps on
the committee. They still sell compilers. But I don't see why
that should affect the features of the language. That's a matter
of usage, not where you got the implementation/
glen herrmannsfeldt
> anal...@hotmail.com wrote:
>>Since C interoperability has been added, that ought to take care of
>>the ability to control where every bit and byte starts out and ends
>>up.
> Not even close. That's the kind of thing that's explicitly left out
> of C interop so far. If a C struct has bit-resolution component
> sizes, there is no way to declare a Fortran derived type to
> correspond.
They are not portable in C, so it isn't surprising that
they aren't portable in Fortran. C allows bit fields, but
doesn't say where in the word they end up. That makes them
not useful in most situations.
(snip)
> And bit strings. (Though what some people expect bit strings to
> be is difficult to discern. One person that frequently mentions
> them has explicitly rejected in past discussions the idea that
> they should be strings whose components are bits.)
I think I asked before, if you thought the PL/I bit string
variables are reasonable. Well, it might depend on the
features added to CHARACTER variables, but PL/I BIT
works very much the same as CHAR, but with only two
values. You can use SUBSTR on them, as well as other
functions that normally work on strings. They compare
left to right in the usual way for character strings.
A popular length limit is 32767, such that it fits
in a 16 bit signed integer.
PL/I structures allow for either ALIGNED or PACKED, such
that bit strings in a structure do or don't start on
a byte boundary. (The bits within a string are always
packed.) The main problem is that they can be slow,
especially working with two strings with different
bit alignment.
-- glen
James Giles
> James Giles wrote:
...
>> And bit strings. (Though what some people expect bit strings to
>> be is difficult to discern. One person that frequently mentions
>> them has explicitly rejected in past discussions the idea that
>> they should be strings whose components are bits.)
>
> I think I asked before, if you thought the PL/I bit string
I think I've said before. No, I don't think they're really much
worth imitating. I particularly wouldn't want their implicit
conversion to fixed binary. A bit string is a sequence of values,
it isn't a single numeric value. No doubt there would need to
be some transfer-like conversion between bit strings and integers.
Such conversions should be explicit.
glen herrmannsfeldt
(snip on bit strings and the PL/I implementation)
> I think I've said before. No, I don't think they're really much
> worth imitating. I particularly wouldn't want their implicit
> conversion to fixed binary. A bit string is a sequence of values,
> it isn't a single numeric value. No doubt there would need to
> be some transfer-like conversion between bit strings and integers.
> Such conversions should be explicit.
The conversion property is more of a general language feature
than a bit string feature. Note that it will also convert
CHAR strings, assuming an appropriate value. (Pretty much the
same as done by list directed I/O.) Since Fortran doesn't do
that for CHARACTER variables I wouldn't expect it for BIT,
either.
Would you allow for automatic conversion between BIT(1)
and LOGICAL? Bit strings and LOGICAL arrays?
Otherwise, the usual built-in functions would apply,
SUBSTR and INDEX being the popular ones. There is
also BOOL, which allows for any of the 16 possible
logical operations between two BIT values.
There is also UNSPEC, which allows conversion of the
bit patters of other values to/from BIT strings.
The equivalent of TRANSFER between an expression and
a variable of the same size can be done as:
UNSPEC(A)=UNSPEC(B);
Not that I would expect any to work the same in a Fortran
implementation, but only for comparison purposes.
-- glen
anal...@hotmail.com
> analys...@hotmail.com wrote:
>
> ...
>
> > In order to determine where Fortran ought to go from here - do you
> > think the following strategic question needs to be asked and if so
> > what would be your answer?
>
> > As we speak now, is Fortran any longer a viable choice for software
> > developed and maintained by one organization intended to be sold to
> > others with customer service and other paraphernelia of commercial
> > software development?
>
> > In fact, I remember reading in this ng. that commercial Fortran
> > compilers themselves might no longer be viable.
>
> > If the answer (as I suspect it is) is that Fortran can only live on in
> > non-profit organizations, I think that should impact how the language
> > evolves in the future.
>
> I can't see the relevance. Certainly existing software companies
> believe that Fortran is a viable product. They still have reps on
> the committee. They still sell compilers. But I don't see why
> that should affect the features of the language. That's a matter
> of usage, not where you got the implementation/
>
> --
> J. Giles
Given the incontrovertible fact that as of today Fortran represents
totally negligible revenues/profits to the Suns, IBMs etc. of the
world, whether they send representatives to meetings or not is
irrelevant. I strongly suspect that their aim is to maintain support
for a steadily dwindling pool of legacy applications.
Why can't the Fortarn community face facts and agree that Fortran's
future consists of flat files in - flatfiles out mathematically
intensive processing on a single machine with only primitive
prettification of output (if any)?
If we do, perhaps we'll stay away from endlessly cluttering the
language with features that are now universally handled by other
programming/scripting languages.
In other words, GUIs, internet, relational databases, sophiticated
dispays of numerical output etc. - a.k.a modern computing has passed
Fortran by and the custodians of Fortran should either have the grace
to let it die or clearly understand its mission going forward and
evolve it with a tight focus on what it does best.
Take a "grown up" computing feature such as exception handling. Why
is that needed in Fortran when in most instances the user is the same
as the programmer and he can do bug fixes in his own idiosyncratic
way?
I can see exception handling being crucial in a commercial setting -
the executable is given over to end-users who may be running tens or
hundreds or more instances of it under different processors, different
data inputs, different run control parameters, different number of
simultaneous users etc. and debugging needs to be done in a formal
documented setting, with significant economic consequences from
defects.
Gary Scott
Hogwash, Fortran is a fine general purpose language and only getting
better. I see it attracting more users not fewer as it finally acquires
essential features that pulled users away in the first place. Given
the need to remain backward compatible, it will never achieve true
beauty, but at least you can now look it in the face without laughing.<snip>
James Giles
...
> Would you allow for automatic conversion between BIT(1)
> and LOGICAL? Bit strings and LOGICAL arrays?
Probably not automatic. I'd have to see the whole proposal.
Anything that even suggests some specific limitation on the
internal representation of a LOGICAL I would oppose.
> Otherwise, the usual built-in functions would apply,
> SUBSTR and INDEX being the popular ones. There is
> also BOOL, which allows for any of the 16 possible
> logical operations between two BIT values.
I don't recall BOOL. What fortran has (iand, ior, not, etc.)
should apply elementally to a bit string (or pair of strings of the
same length). Of course, since those are INTEGER functions,
that suggests that the elements of the bit strings are regarded
as small integers. Which is what they should be.
Ah yes, here it is (PL/I manual). Well, if BOOL is really considered
necessary, it should be added as an INTEGER bitwise function.
Frankly it looks like a recipe for hidden mistakes to me. To be
sure, it allows the user to define any of the 16 different operations
that can be defined on a pair of one-bit operands (including several
essentially useless ones, like always returning zero regardless
of the operand values). But if the third operand is defined elsewhere,
it leaves the reader guessing which operation is being performed.
Maybe that's the point?
> There is also UNSPEC, which allows conversion of the
> bit patters of other values to/from BIT strings.
> The equivalent of TRANSFER between an expression and
> a variable of the same size can be done as:
>
> UNSPEC(A)=UNSPEC(B);
UNSPEC is syntactically unsavory. It looks like an array
element assignment. In an assignment statement in Fortran
the entity being defined (wholly or in part) is named by the
first token of the statement (disregarding labels). I think
that's a property worth preserving, since it improves legibility.
However, the concept isn't bad. Just reversing the notation
has some merit:
A%%unspec = B%%unspec
Here the %% notation is used to distinguish UNSPEC from
a normal component selection (Fortran has no reserved keywords).
However, since one of the things you're likely to want to do
on the righthand side of the assignment is some bitwise operation,
and since Fortran bitwise operations are defined on integers,
the spelling probably should be:
A%%asInt = B%%asInt
Now, since assignment is elemental, the above operation
should be too. That is, the %%asInt suffix doesn't make
an array into some single *very* big integer, it makes each
element into an integer and proceeds elementally. That's
consistent with Fortran's basic design.
Also, %%asInt probably shouldn't be defined on derived type
objects at all. (That includes COMPLEX objects, which should
be considered as a derived type with two REAL components.)
Again, how big an integer do you think we should support?
And in any case, TRANSFER-like operations on derived
types are very error prone, and seem to me only to have the
purpose of allowing hackers to reverse engineer the internals
of POINTER and ALLOCATABLE descriptors.
Finally, %%asInt obviously doesn't need to be defined on
INTEGERs, though I suppose it might make certain CLASS(*)
and other generic operations easier if it was. And I'm not
sure it should be allowed for LOGICAL data: that would
likely only serve to allow reverse engineering to LOGICALs
to no useful purpose.
None of this even addresses the issue of converting a string or
array of small integers (the smallest being one-bit) into one
(or a sequence of) larger integer(s). Or vice-versa for that
matter. The TRANSFER intrinsic itself could still do it.
A more succinct way could be found if TRANSFER is not
widely acceptable.
> Not that I would expect any to work the same in a Fortran
> implementation, but only for comparison purposes.
How come you always use the *same* small set of languages
"for comparison purposes"? It's believable if you actually
compared to a wide variety. Constantly choosing from the
same set tends to suggest promotion rather than just comparison.
How about comparing to Haskell, Prolog, Lisp, Forth, or any
of more than 1000 other languages people have developed over
the years?
James Giles
...
> Given the incontrovertible fact that as of today Fortran represents
> totally negligible revenues/profits to the Suns, IBMs etc. of the
> world, whether they send representatives to meetings or not is
> irrelevant. I strongly suspect that their aim is to maintain support
> for a steadily dwindling pool of legacy applications.
No. By definition, legacy applications don't have any use for
new features. That's what makes them legacy codes. The only
recent development relevant to legacy codes is C-interop.
This is because that's often the only part of a legacy code
that's ever modified or extended - in order to move the
application to a neww platform. Once they've begun using
teh standard C-interop stuff, they may never again even need
to change that part.
For whatever reason, the committee is extending the language
in fairly massive ways. For the vendors with reps on the
committee, this implies they think it has big future sales.
How else could they justify the expense in manpower
(womanpower?) necessary to implement these big new
features?
...
> Take a "grown up" computing feature such as exception handling. Why
> is that needed in Fortran when in most instances the user is the same
> as the programmer and he can do bug fixes in his own idiosyncratic
> way?
Well, that's the very person that needs exception handling. He doesn't
have a staff of junior programmers to hand off the problem to and
say "fix it". I'm such a lone programmer at the moment. I want
exception handling for *me*. Sure, making programming easier
will also help the big commercial shops. But not as much as it
will help individuals.
--
J. Giles
dpb
>> Take a "grown up" computing feature such as exception handling. Why
>> is that needed in Fortran when in most instances the user is the same
>> as the programmer and he can do bug fixes in his own idiosyncratic
>> way?
>
> Well, that's the very person that needs exception handling. He doesn't
> have a staff of junior programmers to hand off the problem to and
> say "fix it". I'm such a lone programmer at the moment. I want
> exception handling for *me*. Sure, making programming easier
> will also help the big commercial shops. But not as much as it
> will help individuals.
In addition, there are many places where Fortran codes _are_ production
codes and programmers are not involved in the day-to-day application of
the code. I worked in such an environment for years on both ends and
while rare, exception handling would have shortened the repair time on
both ends when it did occur.
--
James Giles
> [...] I see it attracting more users not fewer as it finally
> acquires essential features that pulled users away in the first
> place. [...]
I actually don't see that happening. Switching languages is
a big dislocation (that's the proper economic term for a big
change that costs a lot to accommodate). People that I know
who abandoned Fortran have no interest in ever coming back.
The only thing that would lure them would be some market
leading, not playing "me-too" with features they already
have in whatever language they switched to.
To be sure, in large institutions with lots of "linguistic inertia",
they haven't abandoned Fortran (not wholly anyway) like their
more nimble colleagues outside. That's where interest in new
Fortran features seems the highest. That, I suspect, is where
vendors see a future market for Fortran compilers.
> [...] Given the need to remain backward compatible, it will never achieve
> true beauty, but at least you can now look it in the face without
> laughing.<snip>
Some of the features are either comedy or tragedy. Between
15 and 20 years ago I predicted that by the time Fortran had
standardized OOP features in it, and implementations were
finally becoming available, the rest of the programming
community would be moving on to other things. In those days
I regarded OOP and inheritance as interchangeable. Well,
implementations of Fortran's inheritance features are now
becoming available. And OOP (they've change the definition)
is moving away from inheritance as fast as they can.
I also predicted that the next paradigm after inheritance would
be generic programming. Guess what the OOP people are now
embracing as the big new thing? If we had gone directly for
generic programming 15 years ago, F2003 would now be
leading the pack. At least some might find that worth a laugh.
Well, Fortran can't now be expected to have standardized generic
programming features - with implementations widely available - for
perhaps 10 years. And I've lost the gift of prophecy. I have no
idea what the market leadng paradigm will be 10 years from now.
I'd bet it isn't generic programming anymore. So, Fortran will
be trailing the pack again.
--
J. Giles
anal...@hotmail.com
> Gary Scott wrote:
> > [...] I see it attracting more users not fewer as it finally
> > acquires essential features that pulled users away in the first
> > place. [...]
>
> I actually don't see that happening. Switching languages is
> a big dislocation (that's the proper economic term for a big
> change that costs a lot to accommodate). People that I know
> who abandoned Fortran have no interest in ever coming back.
> The only thing that would lure them would be some market
> leading, not playing "me-too" with features they already
> have in whatever language they switched to.
>
> To be sure, in large institutions with lots of "linguistic inertia",
> they haven't abandoned Fortran (not wholly anyway) like their
> more nimble colleagues outside.
Would it be accurate to say the the large institutions you have in
mind are non-profit ones (universities, government funded research
orgs etc.) ?
That's where interest in new
> Fortran features seems the highest. That, I suspect, is where
> vendors see a future market for Fortran compilers.
rather like the Readers' Digest - the only reason its still around is
that its subscribers are too senile to remember to send in their
cancellation.
I suspect that the vendors are humoring the remaining fortran diehards
as loss -leaders - they'll give you the newer fortrans for free if you
buy something else (the box, or middleware or something).
>
> > [...] Given the need to remain backward compatible, it will never achieve
> > true beauty, but at least you can now look it in the face without
> > laughing.<snip>
>
> Some of the features are either comedy or tragedy. Between
That something is seriously wrong with where Fortran is headed is like
Peak Oil - some early pioneers saw it, the established kicked and
screamed in denial - but now the signs are too clearly visible to keep
up the party line.
My top candidate for Fortran tragi-comedy is the "and then" operator
- i had huge fun at its expense when it was proposed - but I guess
the laugh is on me because it looks like it has been adopted.
But at least thats a small relatively harmless thing - some of the big
ticket items such as the stilted "me too" imitations of fads like OOP
seem directly intended to destroy what remains of the language.
> 15 and 20 years ago I predicted that by the time Fortran had
> standardized OOP features in it, and implementations were
> finally becoming available, the rest of the programming
> community would be moving on to other things. In those days
> I regarded OOP and inheritance as interchangeable. Well,
> implementations of Fortran's inheritance features are now
> becoming available. And OOP (they've change the definition)
> is moving away from inheritance as fast as they can.
>
> I also predicted that the next paradigm after inheritance would
> be generic programming. Guess what the OOP people are now
> embracing as the big new thing? If we had gone directly for
> generic programming 15 years ago, F2003 would now be
> leading the pack. At least some might find that worth a laugh.
>
> Well, Fortran can't now be expected to have standardized generic
> programming features - with implementations widely available - for
> perhaps 10 years. And I've lost the gift of prophecy. I have no
> idea what the market leadng paradigm will be 10 years from now.
> I'd bet it isn't generic programming anymore. So, Fortran will
> be trailing the pack again.
>
Its actually not too late. A group can secede from the committee and
go "back to the future" and create an alternative evolutiuon path from
f77. I only wish I had the time to do it.
James Giles
...
> My top candidate for Fortran tragi-comedy is the "and then" operator
> - i had huge fun at its expense when it was proposed - but I guess
> the laugh is on me because it looks like it has been adopted.
I can't find it in F2008. Maybe it's not spelled AND THEN.
In any case, I opposed the feature. Not because it was a bad
idea to have the capability, but because the committee wanted to
adopt it without treating the underlying properties of the feature
in a systematc way - particulary the issue of a procedure being
explicitly non-strict with respect to its operands.
dpb
>> To be sure, in large institutions with lots of "linguistic inertia",
>> they haven't abandoned Fortran (not wholly anyway) like their
>> more nimble colleagues outside.
>
> Would it be accurate to say the the large institutions you have in
> mind are non-profit ones (universities, government funded research
> orgs etc.) ?
I'm not James (obviously :) ), but I'll throw in my $0.02 as I pretty
much agree w/ his characterization overall...
No, it wouldn't be accurate to say the institutions I would have in mind
in thinking similar things as James are non-profit. I also wouldn't say
any of them are Fortran-only by any means any more, either, but they
certainly haven't abandoned it and have no intentions of doing so.
--
--
James Giles
Correct.
anal...@hotmail.com
Could you or James give an example of a for-profit company that would
be of say, fortune 1000 size, that has an active Fortran application
that controls something significant (you need not give any
confidential info.). Are they enhancing the Fortran or is it only
maintenance?
An unimaginable amount of math is done in the financial indutry and I
would suspect that by now they have pretty much eliminated Fortran
altogether from a fairly large base in the 1970s.
James Giles
> Could you or James give an example of a for-profit company that would
> be of say, fortune 1000 size, that has an active Fortran application
> that controls something significant (you need not give any
> confidential info.). Are they enhancing the Fortran or is it only
> maintenance?
Oil companies (geophysical modelling, seismic interpretation,
etc.) and aerospace companies (aircraft design, flight simulation, etc.)
are hiring now. I just looked them up. I'm sure I could find more
if I wanted to look longer than half a minute. Boeing still has a
big investiment in Fortran. I think so does Chevron.
Gary Scott
Lockheed Martin, Boeing, numerous internal applications. I'm working on
a new data acquisition application at the moment (ExpressCard interface).
>
> An unimaginable amount of math is done in the financial indutry and I
> would suspect that by now they have pretty much eliminated Fortran
> altogether from a fairly large base in the 1970s.
dpb
> anal...@hotmail.com wrote:
>> On May 26, 8:22 pm, dpb <n...@non.net> wrote:
> ...
>> Could you or James give an example of a for-profit company that would
>> be of say, fortune 1000 size, that has an active Fortran application
>> that controls something significant (you need not give any
>> confidential info.). Are they enhancing the Fortran or is it only
>> maintenance?
>
> Oil companies (geophysical modelling, seismic interpretation,
> etc.) and aerospace companies (aircraft design, flight simulation, etc.)
> are hiring now. I just looked them up. I'm sure I could find more
> if I wanted to look longer than half a minute. Boeing still has a
> big investiment in Fortran. I think so does Chevron.
Add to them the (commercial) nuclear reactor vendors and utilities.
--
anal...@hotmail.com
Lockheed Martin and Boeing are quasi-government sector in my
opinion :-)
Will everything go to a fashionable language if and when you leave or
retire? In other words, are you the reason the Fortran is still
around?
>
> > An unimaginable amount of math is done in the financial indutry and I
> > would suspect that by now they have pretty much eliminated Fortran
> > altogether from a fairly large base in the 1970s.
>
> --
>
> 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- Hide quoted text -
anal...@hotmail.com
Still - "quasi public sector" entities with the exception of oil
companies. It would be very interesting to know why there is Fortran
still at Chevron - it is all but certain that mission critical stuff
such as seismic imaging is being done using "modern" languages.
James Giles
...
> Still - "quasi public sector" entities with the exception of oil
> companies. It would be very interesting to know why there is Fortran
> still at Chevron - it is all but certain that mission critical stuff
> such as seismic imaging is being done using "modern" languages.
Rewriting hundreds of thousands (if not millions) of lines of
code is expensive. That's a big price to pay to be fashionable.
All the big oil companies are most likely still predominantly
Fortran.
Besides, you still haven't made a case that it makes any difference.
How is "public sector" ("quasi" or not) any different as regards
language design? Isn't government just a particularly large
corporate customer? And I still don't buy your claim that
big corporate customers require different language designs
from small users. So far you've done nothing to support
your claims about what direction the language should go,
and this current discussion isn't even relevant to the
question.
dpb
...
> Still - "quasi public sector" entities with the exception of oil
> companies. It would be very interesting to know why there is Fortran
> still at Chevron - it is all but certain that mission critical stuff
> such as seismic imaging is being done using "modern" languages.
I fail to follow whatever logic is driving your complaint -- certainly
Boeing, Westinghouse, GE, Duke Energy, et al are no less profit-driven
than Chevron.
I've not looked at precise numbers, but I'm pretty sure the commercial
side of Boeing is at least as large as the military.
On the "mission critical" stuff, there's nothing any less critical to
the business in the reservoir modeling simulations, etc., than the
downhole data acq and processing stuff. The same can be said for
reactor calculations for fuel cycle reload computations as compared to
the operator displays--can't have one w/o the other.
--
dpb
...
> Lockheed Martin and Boeing are quasi-government sector in my
> opinion :-)
I'd say your opinion is malformed in my opinion... :)
> Will everything go to a fashionable language if and when you leave or
> retire? In other words, are you the reason the Fortran is still
> around?
...
You think one individual is going to make such a major paradigm shift
for a corporation the size of these? Surely you must jest...
--
dpb
...
> ... The same can be said for
> the operator displays--can't have one w/o the other.
In fact, it could easily be argued the former far exceed the latter in
importance. Reactors ran successfully for years w/ no more operator
information than that available from fully analog instruments whereas
modern reactor design demands more detailed computations than could
possibly be accomplished by hand calculations. Current digital
displays, graphics, etc., are of value but hardly "mission critical".
--
glen herrmannsfeldt
(snip)
> How come you always use the *same* small set of languages
> "for comparison purposes"? It's believable if you actually
> compared to a wide variety. Constantly choosing from the
> same set tends to suggest promotion rather than just comparison.
> How about comparing to Haskell, Prolog, Lisp, Forth, or any
> of more than 1000 other languages people have developed over
> the years?
I only use languages that I know well enough to use
as example, or at least know well enough to find the appropriate
point in the manual. I know some Lisp and Forth, and with the
manual I could probably use them for comparison, too.
Comparisons to Fortran probably work best against compiled
languages designed for scientific computing. In some cases,
comparisons to interpreted languages make sense, but often
they don't. (I have used Mathematica and R in comparisons.)
While there may be 1000 languages developed over the years,
if they aren't at least slightly popular it is likely because
they don't support the needed features, but also likely that
I don't know enough about them to use them in comparisons.
I learned Fortran IV the summer before I started high
school, and PL/I about a year later. (Both from reading
the IBM reference manual.) Over the years I have learned
many other languages, but not near 1000. Among the
popular ones I never learned is COBOL. If others want
to compare to other languages I might look up the appropriate
reference to understand the comparison.
-- glen
glen herrmannsfeldt
(after I wrote)
>>There is also UNSPEC, which allows conversion of the
>>bit patters of other values to/from BIT strings.
>>The equivalent of TRANSFER between an expression and
>>a variable of the same size can be done as:
>>UNSPEC(A)=UNSPEC(B);
> UNSPEC is syntactically unsavory. It looks like an array
> element assignment. In an assignment statement in Fortran
> the entity being defined (wholly or in part) is named by the
> first token of the statement (disregarding labels). I think
> that's a property worth preserving, since it improves legibility.
Pseudo-variables are an interesting feature but, yes, they
don't seem to fit Fortran very well.
> However, the concept isn't bad. Just reversing the notation
> has some merit:
> A%%unspec = B%%unspec
An interesting way to do it. Sounds fine to me.
> Here the %% notation is used to distinguish UNSPEC from
> a normal component selection (Fortran has no reserved keywords).
> However, since one of the things you're likely to want to do
> on the righthand side of the assignment is some bitwise operation,
> and since Fortran bitwise operations are defined on integers,
> the spelling probably should be:
> A%%asInt = B%%asInt
> Now, since assignment is elemental, the above operation
> should be too. That is, the %%asInt suffix doesn't make
> an array into some single *very* big integer, it makes each
> element into an integer and proceeds elementally. That's
> consistent with Fortran's basic design.
I forgot the PL/I functions ALL and ANY, which are in the
array handling section instead of the bit string section.
They generate the logical AND or OR of the elements of
an array of bit strings.
> Also, %%asInt probably shouldn't be defined on derived type
> objects at all. (That includes COMPLEX objects, which should
> be considered as a derived type with two REAL components.)
> Again, how big an integer do you think we should support?
> And in any case, TRANSFER-like operations on derived
> types are very error prone, and seem to me only to have the
> purpose of allowing hackers to reverse engineer the internals
> of POINTER and ALLOCATABLE descriptors.
Unless Fortran adds structure expressions, it does seem
that such shouldn't apply to them. Personally, I don't
see anything wrong with structure expressions, but they
don't seem to be very popular.
> Finally, %%asInt obviously doesn't need to be defined on
> INTEGERs, though I suppose it might make certain CLASS(*)
> and other generic operations easier if it was. And I'm not
> sure it should be allowed for LOGICAL data: that would
> likely only serve to allow reverse engineering to LOGICALs
> to no useful purpose.
> None of this even addresses the issue of converting a string or
> array of small integers (the smallest being one-bit) into one
> (or a sequence of) larger integer(s). Or vice-versa for that
> matter. The TRANSFER intrinsic itself could still do it.
> A more succinct way could be found if TRANSFER is not
> widely acceptable.
It would be nice to convert between an array of LOGICAL
and a bit string. Transfer doesn't seem right for that.
(snip, previously answered)
-- glen
James Giles
...
> It would be nice to convert between an array of LOGICAL
> and a bit string. Transfer doesn't seem right for that.
Well, as I say, I think a BIT is simply a KIND of INTEGER. And
perhaps there should be a simple conversion between INTEGER
and LOGICAL. It certainly shouldn't be implicit. And it opens
that whole can of worms about internal representations of LOGICALs
about which no two people seem to agree.
Since a string (As I've described it) is almost identical to a rank-1
array, whatever the rule for convering a scalar INTEGER to/from
a scalar LOGICAL would be applied elementally to either arrays
or strings. So the issue is one of agreeing on a semantics for
INTEGER/LOGICAL conversion of scalar values.
Now, If Lvar is of type LOGICAL (of some KIND), the obviously
the following should be true:
LOGICAL(INT(Lvar)) .eqv. Lvar
And I think that should remain true even if optional KIND arguments
are used in the conversions. No matter what INTEGER KIND is the
intermediate value, and no matter what LOGICAL KIND the final value
is, the result should still be equivalent (as regards the .eqv. operator)
to the original Lvar.
Now I don't believe the reverse can be assumed. If Ivar is of type
INTEGER, the following *can't* be assumed true:
INT(LOGICAL(Ivar)) == Ivar
I don't tink it can be assumed no matter what the optional KIND
args might say. So our hypothetical conversions between LOGICAL
and INTEGER must be just that: conversions. They can't be some
sort of implicit TRANSFER. So I guess we agree, TRANSFER
just doesn't seem right.
anal...@hotmail.com
> analys...@hotmail.com wrote:
>
> ...
>
> > Still - "quasi public sector" entities with the exception of oil
> > companies. It would be very interesting to know why there is Fortran
> > still at Chevron - it is all but certain that mission critical stuff
> > such as seismic imaging is being done using "modern" languages.
>
> Rewriting hundreds of thousands (if not millions) of lines of
> code is expensive. That's a big price to pay to be fashionable.
HArdly a ringing endorsement of the merits of the incumbent language,
wouldn't you say?
> All the big oil companies are most likely still predominantly
> Fortran.
>
> Besides, you still haven't made a case that it makes any difference.
> How is "public sector" ("quasi" or not) any different as regards
> language design? Isn't government just a particularly large
> corporate customer? And I still don't buy your claim that
> big corporate customers require different language designs
> from small users. So far you've done nothing to support
> your claims about what direction the language should go,
> and this current discussion isn't even relevant to the
> question.
>
I'll need some time to formulate my reply. But let me turn the
question around - before we decide what features we would like a
language to have and not have - shouldn't we first have a strategic
view as to who would use the language for whst purposes?
It is of course true that just about any programming task can be
achived through just about any language - but we are talking about the
natural domain of appications for which the language under
consideration would have unique advantages over other languages.
James Giles
> On May 27, 8:15 am, "James Giles" <jamesgi...@worldnet.att.net> wrote:
>> analys...@hotmail.com wrote:
>>
>> ...
>>
>>> Still - "quasi public sector" entities with the exception of oil
>>> companies. It would be very interesting to know why there is Fortran
>>> still at Chevron - it is all but certain that mission critical stuff
>>> such as seismic imaging is being done using "modern" languages.
>>
>> Rewriting hundreds of thousands (if not millions) of lines of
>> code is expensive. That's a big price to pay to be fashionable.
>
> HArdly a ringing endorsement of the merits of the incumbent language,
> wouldn't you say?
It wasn't an endorsement at all. It wasn't intended as one. It's
an observation.
You have been claiming that the only Fortran users in the future
will be small-scale individual user looking for quick-and-dirty
short-term solutions (which they then discard after one or two
runs). At least, that's how I read you position. I don't see that as
the future of Fortran at all. That kind of thing is almost a perfect
match for what scripting languages are intended to do.
You've also been claiming that large corporate or industrial
users *won't* be using Fortran. Yet, that's the main (even *only*)
customer base I see. It's not that they don't want new language
features. They just can't afford a sudden migration. They're
willing to wait for future enhancements to Fortran to use for
incrementally upgrading their programs. That's a much more cost-
effective solution for them.
...
> I'll need some time to formulate my reply. But let me turn the
> question around - before we decide what features we would like a
> language to have and not have - shouldn't we first have a strategic
> view as to who would use the language for whst purposes?
But, for Fortran that's not a very small or well-defined set. Just
because you want it to be a special-purpose language (geared for
whatever you regard as *your* use of it) doesn't mean that others
must stop using it for their purposes. And it certainly doesn't
mean that those others shouldn't advocate changes that *they*
find desirable.
anal...@hotmail.com
> analys...@hotmail.com wrote:
> > On May 27, 8:15 am, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> >> analys...@hotmail.com wrote:
>
> >> ...
>
> >>> Still - "quasi public sector" entities with the exception of oil
> >>> companies. It would be very interesting to know why there is Fortran
> >>> still at Chevron - it is all but certain that mission critical stuff
> >>> such as seismic imaging is being done using "modern" languages.
>
> >> Rewriting hundreds of thousands (if not millions) of lines of
> >> code is expensive. That's a big price to pay to be fashionable.
>
> > HArdly a ringing endorsement of the merits of the incumbent language,
> > wouldn't you say?
>
> It wasn't an endorsement at all. It wasn't intended as one. It's
> an observation.
>
OK I misunderstood you. Are you saying that there are millions of
lines of Fortran 77 code that is too valuable to risk either
switching to another language or for that matter upgrade to f90, f95
f2003 etc.?
> You have been claiming that the only Fortran users in the future
> will be small-scale individual user looking for quick-and-dirty
> short-term solutions (which they then discard after one or two
> runs). At least, that's how I read you position. I don't see that as
> the future of Fortran at all. That kind of thing is almost a perfect
> match for what scripting languages are intended to do.
Yes. and Excel can do a hell of a lot of stuff too that can be then
be thrown into Excel's superb graphics package with a few keystrokes.
And yes - I see Fortran's future as a high-powered excel sans the
Graphics and interfaces to databases etc. Fortran will live (if at
all) purely as a prototyping/throw-away code/proof-of-concept
langauge.
Another huge mistake in f90 onwards has been to include f77 as a
subset. F77 cannot and need not be "modernized" - it is a superb tool
designed to solve a clearly defined set of problems (the only things
it needed were "dirty" things such as APIs, system calls etc.) that
should have been accoplished with libraries.
Th inclusion of f77 in f90 should have been handled through a switch -
you toggle between a pure f77 complier (that would be frozen in place)
and a new modern language that hews to f77 only in look and feel.
The language as it stands now is absolutely puke-making and its
extremely hard to believe that requests for some of its more grotesque
features are coming from large corporations with financial investment
in Fortran to defend.
>
> You've also been claiming that large corporate or industrial
> users *won't* be using Fortran. Yet, that's the main (even *only*)
> customer base I see. It's not that they don't want new language
> features. They just can't afford a sudden migration. They're
> willing to wait for future enhancements to Fortran to use for
> incrementally upgrading their programs. That's a much more cost-
> effective solution for them.
>
> ...
>
> > I'll need some time to formulate my reply. But let me turn the
> > question around - before we decide what features we would like a
> > language to have and not have - shouldn't we first have a strategic
> > view as to who would use the language for whst purposes?
>
> But, for Fortran that's not a very small or well-defined set. Just
Are you seeing that the fortran user base - although a shadow of what
what it was in Fortran's heyday is still too diverse to be defined
tightly?
Is that your reason why the current "design by committee" process to
define the language is the only viable approach?
> because you want it to be a special-purpose language (geared for
> whatever you regard as *your* use of it) doesn't mean that others
> must stop using it for their purposes. And it certainly doesn't
> mean that those others shouldn't advocate changes that *they*
> find desirable.
My only concern is that some of the truly bizarre features that seem
to be coming from folks who have never worked in the private sector
might push the remaining corporate users over the edge and decimate
Fortran uasge further.
>
> --
> 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- Hide quoted text -
Gary Scott
This is just a truly bizarre misunderstanding of what the private sector
is doing.
>
>
>
>>--
>>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- Hide quoted text -
>>
>>- Show quoted text -
>
>
James Giles
...
> OK I misunderstood you. Are you saying that there are millions of
> lines of Fortran 77 code that is too valuable to risk either
> switching to another language or for that matter upgrade to f90, f95
> f2003 etc.?
I don't know where you got the word "risk". It's expensive to
convert to another language. It's less expensive to incrementally
upgrade to upward compatible versions of the same language.
Some things *have* to be upgraded (to take advantage of new
parallel hardware features, for example).
So what I'm saying is that the future users of new Fortran features
will almost all be in large institutions (commercial or not) that have
too much of an investment in Fortran to afford conversion to another
language. And they probably *will* (slowly and incrementally)
upgrade to several of the more recently added features.
> And yes - I see Fortran's future as a high-powered excel sans the
> Graphics and interfaces to databases etc. Fortran will live (if at
> all) purely as a prototyping/throw-away code/proof-of-concept
> langauge.
I don't think it's ever been that. Nor do I think it ever will be.
If the committee decides to target that usage it really will kill
the language. There are plenty of languages already in that
category that do that sort of thing better than Fortran (any
flavor) ever has or ever will.
>>> I'll need some time to formulate my reply. But let me turn the
>>> question around - before we decide what features we would like a
>>> language to have and not have - shouldn't we first have a strategic
>>> view as to who would use the language for whst purposes?
>>
>> But, for Fortran that's not a very small or well-defined set. Just
>
>
> Are you seeing that the fortran user base - although a shadow of what
> what it was in Fortran's heyday is still too diverse to be defined
> tightly?
The diversity of the user base is practically identical to what it was in
the past. The user base has not shrunk all that much (in absolute terms).
The rest of the computing has grown vastly. That might give the illusion
that Fortran's user base is shrinking. But I think most of the shrinkage
is in the form I already mentioned - small users have moved away
never to return. Sort of the same set of people you seem to regard as
the *only* future users are the ones that were the first to go.
> My only concern is that some of the truly bizarre features that seem
> to be coming from folks who have never worked in the private sector
> might push the remaining corporate users over the edge and decimate
> Fortran uasge further.
"Decimate" is probably about right since it means "reduce by ten
percent". In absolute terms, that's probably about where Fortran is
compared to it high point.
FX
That's when I realised it had to be a joke ;-) Frankly, there's a lot to
be said about Excel (which I don't use much, but my wife uses it as her
Swiss army knife for numerical tasks), but "superb graphics" is surely
not one of them. Have you ever used other graphing tools and compared the
output?
--
FX
anal...@hotmail.com
wrote:
> analys...@hotmail.com wrote:
>
> ...
>
> > OK I misunderstood you. Are you saying that there are millions of
> > lines of Fortran 77 code that is too valuable to risk either
> > switching to another language or for that matter upgrade to f90, f95
> > f2003 etc.?
>
> I don't know where you got the word "risk". It's expensive to
> convert to another language. It's less expensive to incrementally
> upgrade to upward compatible versions of the same language.
> Some things *have* to be upgraded (to take advantage of new
> parallel hardware features, for example).
>
In the business world I am familar with, software is "owned" by non-
programmers. many people have to sign off before changes are made to
production programs. Risk is a primary consideration to decide
whether or not to change a production program.
You can practically never make a "business case" to merely upgrade a
program to a more modern language or dialect if it doesn't offer new
functions that are seen to benefit the business somehow.
Under the above rules of the game, unless the Fortran world announces
that as of a certain date pure f77 compilers would no longer be
available, upgradation to more modern Fortrans would be a tough sell.
> So what I'm saying is that the future users of new Fortran features
> will almost all be in large institutions (commercial or not) that have
> too much of an investment in Fortran to afford conversion to another
> language. And they probably *will* (slowly and incrementally)
> upgrade to several of the more recently added features.
>
Have you observed whats missing from the picture?
Yes - you seem to have studiously avoided the topic of initiation of
new Fortran projects in the commercial world.
Why should a language undergo so many changes, some wise and some
otherwise, if its only possible future use is the continuation of a
code base that was developed in the 1970s at the latest?
> > And yes - I see Fortran's future as a high-powered excel sans the
> > Graphics and interfaces to databases etc. Fortran will live (if at
> > all) purely as a prototyping/throw-away code/proof-of-concept
> > langauge.
>
> I don't think it's ever been that. Nor do I think it ever will be.
> If the committee decides to target that usage it really will kill
> the language. There are plenty of languages already in that
> category that do that sort of thing better than Fortran (any
> flavor) ever has or ever will.
By the same token, there are plenty of languages that can take and
have taken (with a vengeance) the place of Fortran for large
numerically intesive software projects.
>
> >>> I'll need some time to formulate my reply. But let me turn the
> >>> question around - before we decide what features we would like a
> >>> language to have and not have - shouldn't we first have a strategic
> >>> view as to who would use the language for whst purposes?
>
> >> But, for Fortran that's not a very small or well-defined set. Just
>
> > Are you seeing that the fortran user base - although a shadow of what
> > what it was in Fortran's heyday is still too diverse to be defined
> > tightly?
>
> The diversity of the user base is practically identical to what it was in
> the past. The user base has not shrunk all that much (in absolute terms).
As always, everybody handwaves on this, but there is no hard data.
> The rest of the computing has grown vastly. That might give the illusion
> that Fortran's user base is shrinking. But I think most of the shrinkage
> is in the form I already mentioned - small users have moved away
> never to return. Sort of the same set of people you seem to regard as
> the *only* future users are the ones that were the first to go.
>
I believe your data are wrong in this regard. Are you familiar with
Les Hatton's surveys of Fortran usage?
Let me ask this question: Is it conceivable that a software rewrite
project in a fairly large organization (private or public) takes
place toward Fortran and not away from it?
anal...@hotmail.com
If you are aware of graphics tools that are better than excel please
let me know.
Tom Micevski
well i think that R <www.r-project.org> makes pretty graphs.
FX
> let me know.
It's all a matter of taste, but all the following are imho widely better
graphing tools than Excel. Some have a nice graphical user interface,
some don't, some work on different OSes, but that should give you a good
choice to start with:
-- Origin http://www.originlab.com/
-- Plot http://plot.micw.eu/
-- Matlab
-- Grace http://plasma-gate.weizmann.ac.il/Grace/
-- R http://www.r-project.org/
-- gnuplot http://www.gnuplot.info/
-- viewpoints http://astrophysics.arc.nasa.gov/~pgazis/viewpoints.htm
--
FX
dpb
>> If you are aware of graphics tools that are better than excel please
>> let me know.
>
> It's all a matter of taste, but all the following are imho widely better
...preceding choices snipped for brevity...
Add Tecplot to the list http://www.amtec.com/
--
GaryScott
You have to roll your own, but GINO and Winteracter have extensive
plotting capabilities, GINO historically provided device drivers for
REAL plotters in addition to the usual rasterization process. It also
does 3D and fairly lifelike/gamelike moving images and dynamic plots.
Since they are fairly complete APIs, you can write the entire
application, not just the plotting parts with either one.
James Giles
In any case, he still hasn't made any connections between what
he thinks the target user community is and what he thinks the
languae design should be. It seems to me that a poorly considered
feature is just a bad whether you write and maintain large codes
in a corporate setting or if you write (and throw away) short
codes in a garage.
anal...@hotmail.com
> FX wrote:
> >> Excel's superb graphics package
>
> > That's when I realised it had to be a joke ;-) Frankly, there's a
> > lot to be said about Excel (which I don't use much, but my wife uses
> > it as her Swiss army knife for numerical tasks), but "superb
> > graphics" is surely not one of them. Have you ever used other
> > graphing tools and compared the output?
>
> In any case, he still hasn't made any connections between what
> he thinks the target user community is and what he thinks the
> languae design should be.
I interpret this as "the design of a product need not consider what
its users want to do with it".
Such a statement can only be made by someone who has never been in the
profit-making world.
I'll wait for the ongoing tragedy of Fortran to unfold some more
before reiterating my futile indignation over the destruction of
something that has been a central part of my computing career pretty
much all my adult life.
It seems to me that a poorly considered
> feature is just a bad whether you write and maintain large codes
> in a corporate setting or if you write (and throw away) short
> codes in a garage.
>
http://www.bcs.org/server.php?show=ConWebDoc.12160&changeNav=9834
Ron Bell described use of Fortran at the Atomic Weapons Establishment.
Fortran 90 had been enthusiastically adopted there and was much prized
for its performance. Comparable US sites had moved to C and C++
because they were the languages with which new recruits were familiar;
this was regarded at AWE as a retrograde step.
end quote.
Evidence like the above will eventually force the remaining
Fortranners with their head buried in concrete to take notice of the
world around them.
Fortran is dying not because of the presence or absence of this or
that feature - sometime in the early 1970s-late 1980s timeframe it
stopped being a grown up language. A grown up language in my
definition is one which has new young users taking it up naturally,
one that is considered sufficiently reliable to have millions or
billions of dollars of revenue depend on programs written in it, one
which allows vendors and clients enter into legal contracts with
Service Level Agreements for the performance of programs written in
it , one that has a large users' forum with people exchanging their
latest and greatest code snippets and I am sure I can add other
criteria with a little more thought.
It almost seems like bad manners on Fortran's part to be still alive
in the eyes of mainstream computing. This cannot be remedied in any
way.
The sooner we all agree that it is detined to be a niche language
intended to be used by amateurs and professsionals such as Physicists
who are not software professionals, the sooner we can come down to
earth and design a language only slightly larger than f77 that can
live on indefinitely to fulfill its natural purpose.
James Giles
>> In any case, he still hasn't made any connections between what
>> he thinks the target user community is and what he thinks the
>> languae design should be.
>
> I interpret this as "the design of a product need not consider what
> its users want to do with it".
Most people want to write correct, efficient code ant not errors.
So far all your recommendations regard the promotion of error
prone features. That helps *no *one*.
I have no particular love form many of the changes rto the language
since F90 (in fact, my public review of F90 recommended that
it not be approved - for reasons I still consider valid). But I don't
see any of your recommendations even coming up to that standard.
Killing the language quickly is hardly a useful alternative to killing
the language slowly.
dpb
...
> The sooner we all agree that it is detined to be a niche language
> intended to be used by amateurs and professsionals such as Physicists
> who are not software professionals, the sooner we can come down to
> earth and design a language only slightly larger than f77 that can
> live on indefinitely to fulfill its natural purpose.
Since it isn't true, I don't think it is possible to ever reach
agreement that such is true.
If one wants to remain using F77 features, fine; but don't see how any
of what you have said re: your version of whatever is a "profit-making"
enterprise is has anything whatsoever to do w/ the price of tea (or Fxx
for that matter).
--
Jan Vorbrüggen
> definition is one which has new young users taking it up naturally,
> one that is considered sufficiently reliable to have millions or
> billions of dollars of revenue depend on programs written in it, one
> which allows vendors and clients enter into legal contracts with
> Service Level Agreements for the performance of programs written in
> it , one that has a large users' forum with people exchanging their
> latest and greatest code snippets and I am sure I can add other
> criteria with a little more thought.
The problem in software "engineering" is that these criteria are almost
entirely irrelevant to the actual decision making, which in turn is
almost entirely of the "follow the lemmings" kind.
Jan
anal...@hotmail.com
wrote:
This is purely uninformed arrogance. Profit-making enterprises
(vendors of stat/optimzation packages and wall Street to name but two
industry categories (the occasional Bear Stearns has nothing to do
with Fortran's use or the lack of it :-))) have replaced Fortran with
C/C++/Java in its core applicability domain (large scale mathematical
computing) and are doing just fine, thank you.
This process is somewhat similar to how Latin became
French,Spanish,Italian etc. - it is not correct or incorrect - it has
simply happened. And if you observe, Latin lives on in "Non-profit"
institutions such as schools, colleges and Churches.
It now takes energy (in the sense of getting water to run uphill) to
keep fortran alive in commercial settings - and the few remaining
islands of fortran usage will die out once its few remaining diehard
advocates retire eventually and water will relentlessly flow downhill
sweeping Fortran away from where it no longer belongs.
anal...@hotmail.com
wrote:
> analys...@hotmail.com wrote:
> > On May 29, 4:32 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
> ...
> >> In any case, he still hasn't made any connections between what
> >> he thinks the target user community is and what he thinks the
> >> languae design should be.
>
> > I interpret this as "the design of a product need not consider what
> > its users want to do with it".
>
> Most people want to write correct, efficient code ant not errors.
> So far all your recommendations regard the promotion of error
> prone features. That helps *no *one*.
>
> I have no particular love form many of the changes rto the language
> since F90 (in fact, my public review of F90 recommended that
> it not be approved - for reasons I still consider valid). But I don't
> see any of your recommendations even coming up to that standard.
What is stopping you from observing that it the Fortran written using
"error-prone" features (before the dying off period of early 1970s -
late 1980s) that has the best chance of survival going forward?
For example, I think that implicit typing is actually error-reducing
and not error-inducing. That you can occasionally type "tets" for
"test" and the unintended variable would live merrily on in your code
wreaking havoc is now caught by modern compilers (typically when you
have done that you would be using a a variable to which a value has
not been assigned).
But all this "saving the programmer from himself" mentality is not
going to help when both test1 and test2 have been dutifully declared
in fortran 90s puke-making style ("real kind allocatable :: whatever")
and the programmer calls a subprogram with test1 in the argument when
he intended test2.
Implicit typing allows for idiom and continuity of style. And during
code development, imagine that you want to bring in a value for
debugging purposes sixty or seventy lines deep in a subprogram and if
it is real, imagine how easy it is to define a function realfun and
invoke realfun exactly where you want it without having to scroll up
to where the declarations are and declaring realfun.
Implicit typing makes the process of code development more fluid, not
forcing the programmer to break his chain of thought too often and
actually reduces errors in my opinion.
Its such alleged warts of f77 that actually led to its phenomenal
success and it was destroyed by a language (C) that had no safety net
for the programmer at all (at least back in the dying off period of
Fortran - I wouldn't be surprised if the custodians of C are now
tyring to kill it by making it "safe".).
dpb
...
> What is stopping you from observing that it the Fortran written using
> "error-prone" features (before the dying off period of early 1970s -
> late 1980s) that has the best chance of survival going forward?
That it was written in earlier versions is somewhat a given given the
time frame... :) I have absolutely no doubt if I had had an F95 or
later compiler while using pre-F77 or even F77 compilers I would have
been gleeful in using its feature set to accomplish the same set of
tasks which could now be going forward.
> For example, I think that implicit typing is actually error-reducing
> and not error-inducing. That you can occasionally type "tets" for
> "test" and the unintended variable would live merrily on in your code
> wreaking havoc is now caught by modern compilers (typically when you
> have done that you would be using a a variable to which a value has
> not been assigned).
>
> But all this "saving the programmer from himself" mentality is not
> going to help when both test1 and test2 have been dutifully declared
> in fortran 90s puke-making style ("real kind allocatable :: whatever")
> and the programmer calls a subprogram with test1 in the argument when
> he intended test2.
No language feature of any language can catch logic errors.
> Implicit typing allows for idiom and continuity of style. And during
> code development, imagine that you want to bring in a value for
> debugging purposes sixty or seventy lines deep in a subprogram and if
> it is real, imagine how easy it is to define a function realfun and
> invoke realfun exactly where you want it without having to scroll up
> to where the declarations are and declaring realfun.
Or, alternatively, imagine how easy it is to have a second window in the
editor open to the declarations area simultaneously.
> Implicit typing makes the process of code development more fluid, not
> forcing the programmer to break his chain of thought too often and
> actually reduces errors in my opinion.
This holding to a 30-yr out-of-date programming style as an argument
seems awfully shallow basis for the "design" of some modern
language--and, of course, one can write F77 (w/ few exceptions) in Fxx
compilers. Studies have pretty much documented that the types of style
you're advocating do indeed reduce productivity and raise error count.
...
--
Jan Vorbrüggen
Bah. How do you think I earn my living?
> Profit-making enterprises
> (vendors of stat/optimzation packages and wall Street to name but two
> industry categories (the occasional Bear Stearns has nothing to do
> with Fortran's use or the lack of it :-))) have replaced Fortran with
> C/C++/Java in its core applicability domain (large scale mathematical
> computing) and are doing just fine, thank you.
Wall Street doesn't even know what C/C++/Java or Fortran means or what
differentiates them. They gladly pay at least ten times as much as
necessary and make a profit in spite of that, not because of it.
Have you seen the reports of mistrades at the Tokyo stock exchange in
the past several years, e.g., in comp.risks? You get to guess what
language those systems are written in.
Jan
James Giles
> On May 29, 10:23 pm, "James Giles" <jamesgi...@worldnet.att.net>
> wrote:
>> I have no particular love form many of the changes rto the language
>> since F90 (in fact, my public review of F90 recommended that
>> it not be approved - for reasons I still consider valid). But I don't
>> see any of your recommendations even coming up to that standard.
>
> What is stopping you from observing that it the Fortran written using
> "error-prone" features (before the dying off period of early 1970s -
> late 1980s) that has the best chance of survival going forward?
A <= X <= B is from before 1970??? Adopting Excel graphics
is a pre-1907's idea??? SQL array ops are pre-1970's??? Make
up your mind.
> But all this "saving the programmer from himself" mentality is not
> going to help when both test1 and test2 have been dutifully declared
> in fortran 90s puke-making style ("real kind allocatable :: whatever")
> and the programmer calls a subprogram with test1 in the argument when
> he intended test2.
Same error possible with pre-1970's Fortran. Sorry, no points given
for examples where your alternative is not an advantage.
> Implicit typing allows for idiom and continuity of style. [...]
So does any language. Adopt a better idiom and you'll have even
better style.
> Its such alleged warts of f77 that actually led to its phenomenal
> success and it was destroyed by a language (C) that had no safety net
> for the programmer at all (at least back in the dying off period of
> Fortran - I wouldn't be surprised if the custodians of C are now
> tyring to kill it by making it "safe".).
Yet C *doesn't* have implicit typing. Hmm. Evidently not the
panacea you're making it out to be.
I think you would be a fun subject in those productivity experiments
they used to do in the 1970's. No matter what they were testing, one
pattern emerged over and over again: the subjects of the experiment
(the programmers themselves) were *least* qualified to predict
what features would hurt or enhance their own productivity. Time
and again, the feature the programmers *liked* was the one that
they were *least* productive with. That lead to one of my favorite
sayings (which some even attribute to me): programmers don't like
their favorite programming language "warts and all", they like the
warts best.
In any case, the phenominal success of Fortran might have more
to do with the fact that it was the first high-level, platform independent
language and that it was promoted by the largest computing company
in the world (the latter by a very large margin - like all other companies
cumulatively would still have been smaller than IBM). I've never
noticed any correlation between popularity and quality.
C became popular because both it and UNIX were free and open-
source when nearly all the colleges and universities in the world
were looking for cheap ways to get a CS department started.
I never heard anyone praise either for quality in those days. That
only started when the departments began to be run by the first set
of CS graduates (who had almost no experience outside of C
and UNIX). Once again, the advantages of being first (the first
widespread teaching environment) and the advantages of being
promoted by powerful organization(s) (lots of universities in
this case) had a lot more to do with the popularity of the language
than any issue of quality.
anal...@hotmail.com
I was trying to figure out how to have a dialogue and not relentlessly
talk past each other.
OK. If someone wanted a Fortran-like prototyping/proof-of-concept
language for mathematically oriented computing (not necessarily
backwards compatible with f77 code) that incorporates as much as
possible of what has been learnt about computing after f77 - what
would your specs of the language for him look like?
James Giles
...
> OK. If someone wanted a Fortran-like prototyping/proof-of-concept
> language for mathematically oriented computing (not necessarily
> backwards compatible with f77 code) that incorporates as much as
> possible of what has been learnt about computing after f77 - what
> would your specs of the language for him look like?
Well, that's still an awfully big project (just defining *any* language
is a big project). I've seen languages where the whole description
of both the syntax and semantics could fit in two or three pages.
The person (or people) that wrote it probably took a month or
more to decide what those pages should say.
So, where do you want to start? My preference is 1) the language
(as constrained above) is *not* Fortran. It's not a subset of Fortran.
Not of any flavor of Fortran. To be sure it would have a very
Fortran-like syntax (syntax is what most people think of as being
the basic characteristic of a language). And, things that are common
to *most* languages (including Fortran) woud be kept in the new
language. The reason that there are things common to most
languages is that there are few sensible alternative ways to do
those things. Everything else is on the cutting board!
2) Lexical structure next? Well, case should have no significance
except in character literals. Identifiers should have no a-priori limit
in length. The bracketing delimiters {}, [], and () should all have
identical meanings. And so on. Settling all these issues would take
an afternoon (at least). Like: should keywords be reserved?
3) Intrinsic data types? Floats (at least all the types supported by
the host hardware), integer (one type, arbitrary precision), rationals
(arbitrary precision), character (at least ASCII, Latin-1, and some
UNICODE - I'd personally prefer UTF-16), and Logical (one type).
No KINDs, all these are distinct types. (No parameterized types
at all: you did posit it had to be a simple language.) Other intrinsics
might be desirable (bits say). Depends on details elsewhere.
4) Modules or COMMON? Everything is on the cutting board.
A simple language should have only one of these. Modules are
the simpler of the two: no storage association. Also, a module
gives an obvious place for initializations and can also hold named
constants. In any case, even in a scripting language or that kind
of thing, there are likely to be things you want to save end reuse
over several projects and modules provide good packaging for
that kind of thing.
5) External procedures, module procedures, or internal procedures?
A simple language should have only one of these features. Modules
are a cleaner solution than externals and provide a way to share
some things without making them public. As for compilation cascades:
well such a language is involved with small programs anyway (and
may even be implemented interpretively), so it's not really an issue.
And again, you will probably want to save an reuse *some* codes:
modules provide good packaging.
6) Derived data types, yes or no? I think yes. If you need the ability,
there's no useful alternative. And if you don't need it, you won't
notice it's there. It's not like it's something you can accidentally
trip over. If you have this, then COMPLEX (which I didn't mention
as an intrinsic) should be a predefined one of these. This obviously
involves the introduction of overloaded operators and intrinsic
functions.
7) SAVE or not? All module variables should have that property
automatically, no other variable should be permitted to have it.
Arrays? Yes (arbitrary dimension, local arrays can be "automatic").
Strings? Yes (any base type, and always dynamic length). Pointers?
No. Allocatable? Probably no. INTENT? Yes (IN or OUT - not
specifying should mean the same thing as INOUT, so you don't
actually need to be able to say INOUT). OPTIONAL? Maybe,
but with different rules than Fortran. Asynchronous, protected,
volatile, etc.? No. This is supposed to be a simple language.
8) Inheritance? Certainly not. There's no evidence it improves
productivity. (In fact, there's evidence to the contrary.) And it's
a *VERY* big feature to haveto support in a simple language.
Generic procedures? Maybe. It has to be simple. It actually can
be. Generic data type (variant derived types)? Maybe. Of course
you can't have those unless you have derived types at all (6).
9) Operator precedence? C/C++ have 15 (or more, depends on
how you count). Fortran has 10 (or more, depends on how you count).
Pascal has 4. I think there should be 6 or 8 depending on whether
you allow user defined operators or not. User defined operators?
I could be convinced either way.
10) ... and so on. I can think of about a dozen other issues off
the top of my head. If I dug out the Fortran manual and read
through it page by page I could probably think of several dozen.
Just hashing out what all the basic issues are would be a task
for a week or more. *Deciding* on all of them is months.
(The above is not in any particular order of priority. It's just the
order the issues came to mind, and is not recommended as any
outline for further discussion. Indeed, since it's just off the cuff,
there may be issues not on the list that, on reflection, I would
regard as more important than many of the things I mentioned.)
glen herrmannsfeldt
> anal...@hotmail.com wrote:
>>OK. If someone wanted a Fortran-like prototyping/proof-of-concept
>>language for mathematically oriented computing (not necessarily
>>backwards compatible with f77 code) that incorporates as much as
>>possible of what has been learnt about computing after f77 - what
>>would your specs of the language for him look like?
Do you want an interpreted language? There are Mathematica,
Matlab, and R (or S) as mathematical prototyping (interpreted)
languages. Otherwise, PL/I was designed as a replacement
for Fortran. As I understand it, IBM originally was not planning
Fortran compilers for OS/360, expecting to convert everyone over
to PL/I.
C was designed as a systems programming language, mostly
not emphasizing mathematical uses. (Note that the
mathematical functions are in a separate library often
not included by default.) C++ and Java similarly don't
emphasize mathematical use. All three can be used for
mathematical applications, though.
> Well, that's still an awfully big project (just defining *any* language
> is a big project). I've seen languages where the whole description
> of both the syntax and semantics could fit in two or three pages.
> The person (or people) that wrote it probably took a month or
> more to decide what those pages should say.
Not trying to promote PL/I, but only make constructive
comparisons, it seems to me that PL/I is the only language
since the beginning of Fortran with replacement of Fortran
as part of its design. More specifically, a language
designed to be compiled and run reasonably fast.
> So, where do you want to start? My preference is 1) the language
> (as constrained above) is *not* Fortran. It's not a subset of Fortran.
> Not of any flavor of Fortran. To be sure it would have a very
> Fortran-like syntax (syntax is what most people think of as being
> the basic characteristic of a language). And, things that are common
> to *most* languages (including Fortran) woud be kept in the new
> language. The reason that there are things common to most
> languages is that there are few sensible alternative ways to do
> those things. Everything else is on the cutting board!
PL/I keeps no reserved words, using a free form semicolon
terminated statement syntax.
> 2) Lexical structure next? Well, case should have no significance
> except in character literals. Identifiers should have no a-priori limit
> in length. The bracketing delimiters {}, [], and () should all have
> identical meanings. And so on. Settling all these issues would take
> an afternoon (at least). Like: should keywords be reserved?
PL/I uses () for bracketing delimiters, except for statement
groups which use PROC/END, BEGIN/END, or DO/END. It originally
only had one case, and has no reserved words (except in the
48 character source character set option).
> 3) Intrinsic data types? Floats (at least all the types supported by
> the host hardware), integer (one type, arbitrary precision), rationals
> (arbitrary precision), character (at least ASCII, Latin-1, and some
> UNICODE - I'd personally prefer UTF-16), and Logical (one type).
> No KINDs, all these are distinct types. (No parameterized types
> at all: you did posit it had to be a simple language.) Other intrinsics
> might be desirable (bits say). Depends on details elsewhere.
Data types may be the biggest complaint about PL/I. Floating
point and fixed point data precision may be specified in bits
or digits, as needed. An appropriate type will be supplied.
For fixed point, a scaling factor (number of digits after
the radix point.) (There is some suggestion that it also
specifies the base used in arithmetic. This isn't so
obvious as it seems.)
> 4) Modules or COMMON? Everything is on the cutting board.
> A simple language should have only one of these. Modules are
> the simpler of the two: no storage association. Also, a module
> gives an obvious place for initializations and can also hold named
> constants. In any case, even in a scripting language or that kind
> of thing, there are likely to be things you want to save end reuse
> over several projects and modules provide good packaging for
> that kind of thing.
PL/I uses STATIC EXTERNAL structures, somewhat similar to
the way they work in C.
> 5) External procedures, module procedures, or internal procedures?
> A simple language should have only one of these features. Modules
> are a cleaner solution than externals and provide a way to share
> some things without making them public. As for compilation cascades:
> well such a language is involved with small programs anyway (and
> may even be implemented interpretively), so it's not really an issue.
> And again, you will probably want to save an reuse *some* codes:
> modules provide good packaging.
Internal procedures complicate separate compilation, so
I don't believe they should be the only option.
> 6) Derived data types, yes or no? I think yes. If you need the ability,
> there's no useful alternative. And if you don't need it, you won't
> notice it's there. It's not like it's something you can accidentally
> trip over. If you have this, then COMPLEX (which I didn't mention
> as an intrinsic) should be a predefined one of these. This obviously
> involves the introduction of overloaded operators and intrinsic
> functions.
I believe that PL/I structures were borrowed from COBOL.
(Features came from Fortran, ALGOL, and COBOL.) Having
COMPLEX as a predefined structure data type is an interesting
idea. PL/I uses it as an attribute to any numeric data type.
That is, fixed point or floating point data is either REAL
or COMPLEX.
> 7) SAVE or not? All module variables should have that property
> automatically, no other variable should be permitted to have it.
> Arrays? Yes (arbitrary dimension, local arrays can be "automatic").
> Strings? Yes (any base type, and always dynamic length). Pointers?
> No. Allocatable? Probably no. INTENT? Yes (IN or OUT - not
> specifying should mean the same thing as INOUT, so you don't
> actually need to be able to say INOUT). OPTIONAL? Maybe,
> but with different rules than Fortran. Asynchronous, protected,
> volatile, etc.? No. This is supposed to be a simple language.
PL/I has four storage attributes, STATIC, AUTOMATIC, BASED,
and CONTROLLED. Also, scope attributes of INTERNAL and EXTERNAL.
Some combinations are not allowed, such as AUTOMATIC EXTERNAL.
Not having to support legacy code, arrays are only passed as
descriptors. STATIC array dimensions must be compile time
constants, otherwise dynamic. Expressions, including a
variable in parenthesis or an expression with a different
type than the declared dummy as converted and a temporary
is passed. The called routine is allowed to modify the
temporary.
> 8) Inheritance? Certainly not. There's no evidence it improves
> productivity. (In fact, there's evidence to the contrary.) And it's
> a *VERY* big feature to haveto support in a simple language.
> Generic procedures? Maybe. It has to be simple. It actually can
> be. Generic data type (variant derived types)? Maybe. Of course
> you can't have those unless you have derived types at all (6).
No comment on this one.
> 9) Operator precedence? C/C++ have 15 (or more, depends on
> how you count). Fortran has 10 (or more, depends on how you count).
> Pascal has 4. I think there should be 6 or 8 depending on whether
> you allow user defined operators or not. User defined operators?
> I could be convinced either way.
PL/I seems to have seven:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ibmol004/3.1.3.5.1
1) **, prefix +, prefix -, not (¬)
2) *, /
3) infix +, infix -
4) string concatenation (||)
5) relational (comparison) operators
6) boolean AND (&)
7) boolean OR (|)
The four operators at the highest level seem a little
unusual, as languages go. PL/I will convert data where
needed, such that some combinations not allowed in other
languages are allowed in PL/I.
> 10) ... and so on. I can think of about a dozen other issues off
> the top of my head. If I dug out the Fortran manual and read
> through it page by page I could probably think of several dozen.
> Just hashing out what all the basic issues are would be a task
> for a week or more. *Deciding* on all of them is months.
I agree.
> (The above is not in any particular order of priority. It's just the
> order the issues came to mind, and is not recommended as any
> outline for further discussion. Indeed, since it's just off the cuff,
> there may be issues not on the list that, on reflection, I would
> regard as more important than many of the things I mentioned.)
One that I don't see mentioned is I/O. That may or may not
be important for any particular problem.
Again, this is not meant to promote PL/I. Only to show that
some issues have been considered before. The reasons behind
the decisions may have changed over the years, though.
I would be interested in comparisons to other languages
designed for mathematical programming.
-- glen
James Giles
...
> PL/I keeps no reserved words, using a free form semicolon
> terminated statement syntax.
The latter known to be a bad idea (from direct productivity experiments).
> PL/I uses () for bracketing delimiters, except for statement
> groups which use PROC/END, BEGIN/END, or DO/END. It originally
> only had one case, and has no reserved words (except in the
> 48 character source character set option).
Again, that kind of statement grouping has long been known to be
a bad idea. Well, PL/I gets it half right.
> Data types may be the biggest complaint about PL/I. Floating
> point and fixed point data precision may be specified in bits
> or digits, as needed. An appropriate type will be supplied.
> For fixed point, a scaling factor (number of digits after
> the radix point.) (There is some suggestion that it also
> specifies the base used in arithmetic. This isn't so
> obvious as it seems.)
Yeah, I wouldn't recommend anyone immitate PL/I's types or
it's syntax, One *supporter* of PL/I recommended that you should
never use the divide operator (/) on fixed-point types: there were
too many "gotcha's". Instead, he recommended that people should
use the DIVIDE intrinsic (which has 4 arguments). Sounds real
natural to me.
>> 4) Modules or COMMON? [...]
> PL/I uses STATIC EXTERNAL structures, somewhat similar to
> the way they work in C.
Too prolific in spreading things around the global namespace.
Using either COMMON or modules only adds the name of the
block or the module to the global namespace - not the name of
every object you decide to share.
> Internal procedures complicate separate compilation, so
> I don't believe they should be the only option.
A language intended only for small programs probably doesn't
need to worry about separate compilation. In any case, I already
excluded internal procedures. Module procedures require
dependent (but still separate) compilation (assuming the
implementation is a compiler). Either that, or you need the
modules to separate their definition part from their implementation
part (kind of an unnecessary complication for something that's
supposed to be a simple language).
> [...] Having
> COMPLEX as a predefined structure data type is an interesting
> idea. PL/I uses it as an attribute to any numeric data type.
> That is, fixed point or floating point data is either REAL
> or COMPLEX.
Another thing I wouldn't recommend even for a complex language,
much less a simple one.
>> 9) Operator precedence? C/C++ have 15 (or more, depends on
>> how you count). Fortran has 10 (or more, depends on how you count).
>> Pascal has 4. I think there should be 6 or 8 depending on whether
>> you allow user defined operators or not. User defined operators?
>> I could be convinced either way.
>
> PL/I seems to have seven:
Yeah, right after I posted the last article, I realized that 7 are needed
(or nine - if user defined operators are permitted):
1) user defined prefix operators
2) exponentiation (I prefer to spell it ^)
3) multiply, divide (*,/)
4) unary + or -, infix + or -
5) concatenate (//)
6) relational operators (oh, you know the usual ones)
7) logical not (¬ is fine)
8) logical and (/\), logical or (\/), logical xor (><)
9) user defined infix operators.
> 1) **, prefix +, prefix -, not (¬)
This doesn't match normal mathematical usage (where unary
signs are lower precedence than exponentiation). Further, all
logical oparators really should be lower than the relational
operators.
> 6) boolean AND (&)
> 7) boolean OR (|)
Dijkstra recommended that those operators have the same
precedence and that parenthesis should always be used to
emphasize order (that is, the language processor should
insist on it). I have come to agree.
> The four operators at the highest level seem a little
> unusual, as languages go. PL/I will convert data where
> needed, such that some combinations not allowed in other
> languages are allowed in PL/I.
Probably another bad idea. Too many things that are often
(maybe even usually) errors cannot be detected or reported
by the compiler.
And of course there's the lexical issues: should user defined
operators be delimited by periods or something else? If something
else, should period be used as the component selector for derived
types? Should enumerated types be permitted? If so, shouldn't
LOGICAL be a built-in enumeration? Should enumeration literals
be spelled distinctively? Should *they* be spelled delimited by
periods (like .true. and .false.)? Etc.
...
> One that I don't see mentioned is I/O. That may or may not
> be important for any particular problem.
And I left out whole-array operations. Are they simple enough?
As I mentioned before, I probably left out a whole lot of important
stuff.
dpb
...
> And I left out whole-array operations. Are they simple enough?
> As I mentioned before, I probably left out a whole lot of important
> stuff.
I'm not a language designer by any stretch but I can't imagine designing
a simple, prototyping language w/o the feature. In my mind, other than
free form source, the largest contribution of F90/95.
I'm also curious about the earlier proscription on ALLOCATABLE--unless
you're intending transparent allocation/assignment a la Matlab for a
prototyping, simple language. To me, the removal of fixed memory
requirements is mandatory for simplicity in writing/prototyping (albeit
w/ a lack of performance unless somewhat careful, but this is
prototyping, right?)
That said, and while it's some interest, I'm curious why OP asked for
that as a target since earlier emphasis seemed to be on large corporate
clients.
--
James Giles
> James Giles wrote:
> ...
>> And I left out whole-array operations. Are they simple enough?
>> As I mentioned before, I probably left out a whole lot of important
>> stuff.
>
> I'm not a language designer by any stretch but I can't imagine
> designing a simple, prototyping language w/o the feature. In my
> mind, other than free form source, the largest contribution of F90/95.
Oh I agree that it's important. And if it's included I can only think
of a few changes to make to the way Fortran does it (mostly leaving
out minor appendages). But, it does have some dark corners of
complexity (both for users and implementors) that may make it
unsuitable for inclusion in a language intended to be bargain
basement simple.
> I'm also curious about the earlier proscription on ALLOCATABLE--unless
> you're intending transparent allocation/assignment a la Matlab for a
> prototyping, simple language. [...]
That's a possibility. But I do have automatic arrays (size declared
on entry to a scoping unit) as well as strings of *any* base type
that are always dynamic length. Since (as addressed elsewhere)
I believe strings to be basically identical to rank-1 arrays with
only a few distinctions (variable length is one of them), they are
interoperable with rank-1 arrays for most operations.
Still, dynamic memory with arrays not of rank-1 may be important.
Again, is it simple enough?
> That said, and while it's some interest, I'm curious why OP asked for
> that as a target since earlier emphasis seemed to be on large
> corporate clients.
He also mentioned Les Hatton's work - which pretty much contradicts
the claims made by the OP. Hatton's surveys indicate that something
like 80% of the programmer's time on a given program is spend in
maintenance (which, in one paper, he divides into three categories
and plots their average duration). So the direst quote:
Productivity. Programmers cost a lot of money, so any silver bullet
should
increase productivity, but what does this mean? Productivity, or the
rate at
which a task is completed, depends directly on the ability to carry out
the
essential tasks of development or the three components of maintenance.
[...] For example, the very rapid production of inferior code could not
conceivably be called productivity because of the nature of Figure 1.
"Silver bullet" being some magical paradigm that would solve all you
computing
needs, and Figure 1 being the place where he reports that maintenance (of
three kinds) occupy 80% of the programmer's time.
dpb
>> James Giles wrote:
...
> Oh I agree that it's important. And if it's included I can only think
> of a few changes to make to the way Fortran does it (mostly leaving
> out minor appendages). But, it does have some dark corners of
> complexity (both for users and implementors) that may make it
> unsuitable for inclusion in a language intended to be bargain
> basement simple.
And there's the difference between the designer side and a user--I don't
think much about the problems implementors may have when thinking of
features I want/like...not _my_ problem! :)
>> I'm also curious about the earlier proscription on ALLOCATABLE--unless
>> you're intending transparent allocation/assignment a la Matlab for a
>> prototyping, simple language. [...]
>
> That's a possibility. But I do have automatic arrays (size declared
> on entry to a scoping unit) as well as strings of *any* base type
> that are always dynamic length. Since (as addressed elsewhere)
> I believe strings to be basically identical to rank-1 arrays with
> only a few distinctions (variable length is one of them), they are
> interoperable with rank-1 arrays for most operations.
>
> Still, dynamic memory with arrays not of rank-1 may be important.
> Again, is it simple enough?
Hmmm...same/similar comment--I was thinking only from the end-user side
essentially.
>> That said, and while it's some interest, I'm curious why OP asked for
>> that as a target since earlier emphasis seemed to be on large
>> corporate clients.
>
> He also mentioned Les Hatton's work - which pretty much contradicts
> the claims made by the OP. Hatton's surveys indicate that something
> like 80% of the programmer's time on a given program is spend in
> maintenance ...
If the definition of "maintenance" would include extensions or
enhancement of existing code (albeit maybe extensive but still nothing
like writing a whole new application of the same scope/type/problem
domain) I would estimate that for the codes I worked on in the
commercial nuclear industry that would be approaching 90% or maybe even
higher and only gets larger each passing day/month/year. I suspect it
is that whole class of Fortran users which OP may not realize exists as
it does (in, of course, most all of which would qualify his
"non-profit-base" large corporations thereby not being "real" users). :)
--
James Giles
...
> And there's the difference between the designer side and a user--I
> don't think much about the problems implementors may have when
> thinking of features I want/like...not _my_ problem! :)
Of course, it's not really that easy. If only (as a user) I could
disregard the problems I have (as an implementor), designing
a language would be so much easier.
For example: in a simple language you would like to eliminate
line length limits and limits on the number of continuation
lines. Except, since Fortran-like languages have no reserved
keywords, it's possibly necessary to look at the *whole*
statement before you can identify even the first token. You
can't incrementally process Fortran-like statement syntax.
Yes, you can handle the problem by dynamically buffering
statements (your limit is then how much dynamic memory
the compiler has free when it starts processing the long
statement). Many implementators would probably prefer
just to set a large-enough arbitrary limit though rather than
consume all their dynamic space.
There are other solutions. You can make the keywords reserved.
That's not very Fortran-like. (And it's not "simple". A new user
would have to memorize all the keywords even for features s/he
never intended to use.) You could require all keywords to have
a special syntax form (like italics, or boldface), or require
keywords to begin with underscore. Again not much like regular
Fortran.
And this is a simple case. So, it really isn't possible to completely
disregard implementation issues when designing how you want
a language to work.
dpb
Oh, of course! I'm not saying I don't understand there are all these
problems and more; just that I'm not at all a designer nor implementor
of compilers/languages so I only know enough to know what I like/want or
conversely don't like.
For example, for a prototyping simply language, the namespace clutter of
Matlab is simply getting totally out of hand--there are so many supplied
functions now it's impossible for even the experts to remember them all
and when one adds on all the optional toolboxes to the base product it's
just mind-numbing. Which, of course, begins to defeat the whole purpose
for which it exists.
--
James Giles
...
> For example, for a prototyping simply language, the namespace clutter
> of Matlab is simply getting totally out of hand--there are so many
> supplied functions now it's impossible for even the experts to
> remember them all and when one adds on all the optional toolboxes to
> the base product it's just mind-numbing. Which, of course, begins to
> defeat the whole purpose for which it exists.
I'm convinced that intrinsics should all be packaged in "intrinsic
modules" and you would have to explicitly import them in (or use
qualified names) if you want to use them. That way the namespace
for your own program only contains the things you are actually
using. This doesn't help the user in working through the myriad
comlexities of which "intrinsic module" to use or which procedure
does what's needed. It just keeps the local namespace uncluttered.
If anyone has other ideas that help, I'd like to hear it.
Craig Powers
> dpb wrote:
> ...
>> For example, for a prototyping simply language, the namespace clutter
>> of Matlab is simply getting totally out of hand--there are so many
>> supplied functions now it's impossible for even the experts to
>> remember them all and when one adds on all the optional toolboxes to
>> the base product it's just mind-numbing. Which, of course, begins to
>> defeat the whole purpose for which it exists.
>
> I'm convinced that intrinsics should all be packaged in "intrinsic
> modules" and you would have to explicitly import them in (or use
> qualified names) if you want to use them. That way the namespace
> for your own program only contains the things you are actually
> using. This doesn't help the user in working through the myriad
> comlexities of which "intrinsic module" to use or which procedure
> does what's needed. It just keeps the local namespace uncluttered.
>
> If anyone has other ideas that help, I'd like to hear it.
I believe VB sort of does this. Everything that's in the runtime
library (basically, everything that's not a keyword) is in IIRC the VBA
namespace. Although everything is hoisted into the global namespace by
default, you can use the module name to disambiguate. (If there's an
ambiguity, I'm not sure offhand how the module precedence is established.)
Classic VB is actually a very nice language, notwithstanding some
backwards-compatibility hiccups (i.e. two ways to spell while loops).
Too bad the OO zealots got their hands on it.
ejk...@gmail.com
> I'm convinced that intrinsics should all be packaged in "intrinsic
> modules" and you would have to explicitly import them in (or use
> qualified names) if you want to use them. That way the namespace
> for your own program only contains the things you are actually
> using. This doesn't help the user in working through the myriad
> comlexities of which "intrinsic module" to use or which procedure
> does what's needed. It just keeps the local namespace uncluttered.
>
> If anyone has other ideas that help, I'd like to hear it.
The problem with intrinsic modules is that the "myriad complexities"
appear pretty quickly. Stroustrup lists 56 standard header files
in his 3rd edition's chapter on the C++ standard library. I found
this to be a significant barrier in trying to learn C++ from his
book: I rarely could figure out, from his examples, which
include files were needed to make the code compile.
At least with Fortran, you don't have to know or worry about all
the intrinsic names. If you happen to use SUM as a variable
in a particular subroutine, for instance, then no harm is done.
Fortran 2003 already has a few intrinsic modules, of course.
If one were going to package the other existing intrinsics
into modules, I would argue for at most two: one for mathematical
functions (SIN, COS, etc.) and another for character manipulation
(INDEX, VERIFY, etc.)
I would also introduce the syntax MODNAME % X to distinguish
between the X in module MODNAME and the local variable X.
This would be an alternative to the USE, ONLY syntax, which I
think is clumsy (and makes me have to refer repeatedly back
to the start of a large routine to understand where the names
are defined).
--Eric