Re: The linf project

analyst41@xxxxxxxxxxx wrote:
On Jun 6, 10:48 pm, Gary Scott <garylsc...@xxxxxxxxxxxxx> wrote:

analys...@xxxxxxxxxxx wrote:

On Jun 6, 3:02 pm, "James Giles" <jamesgi...@xxxxxxxxxxxxxxxx> wrote:

analys...@xxxxxxxxxxx wrote:

...

/* and */ to include blocks of comments anywhere in the code (no
special ways to start a comment line or comments at the end of a
program statement)?

It's known by direct experiment that such "run-on" comments
are counterproductive. Just like statements should be ended
by an (unescaped) end of line, so comments should end at the
end of a line (no continuation-mark escapes possible for
comments). Why design a language that violates results of
known productivity experimants?

--
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

Going forward I assume I have dictatorial powers to settle any
disagreements about the design of linf :-).

Dictatorial decision # 1: semicolons and only semicolons are
statement separators. No continuation character. There may be
multiple program statements on one line (as determined by the program
editor) and one program statement may span multiple lines.

Just lost 62% of your market share.



why don't you wait for some of the great features James has already
pre-alluded to before deciding? To say that 62 pct of the target
audience would walk away because of the statement separation character
requirement is a bit too extreme, I think.

Since semicolon has alredy entered official fortran, I think that
getting rid of continuation characters adds to the aesthetics of
source code.

Having lost the Fortran battle at work I am now using a semicolon
language and to be honest with you, its really not that bad.

At any rate linf would probably end up getting translated to f95
anyway - the translator can put back continuation characters if
needed.



A program is a sequence of program statements of arbitrary length.
Depending on the screen width, printer paper size etc., it may be
broken up into lines arbitrarily for viewing, printing etc.

Semicolons play no other role in the language (they may be part of
string literals).

comments must be enclosed by start comment and end comment character
strings.

This is essential for an essential code development chore -
"commenting out" statements.

Lost another 23%.




I also think that one should allow comments to be anywhere and depend
on the programmer's judgement to put them where they add to
legibility.

Any comments on /* and */ as comment containers?

If it's supposed to be Fortran-like, then that comment method doesn't
fit...retain "!"



"/*" or "!" doesn't matter to me. In fact "!" is preferable, thereby
preventing "/" and "*" from performing multiple functions in the
language.

Do you agree that comments should be enclosed between comment starter
and comment ender chracter sequences?

No, I prefer that end of line (CR/LF, etc) is equivalent to end statement, including comment





--

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 -

- Show quoted text -




--

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
.

Relevant Pages

  • Re: Intel Fortran Compiler 11.0 Now Available
    ... deferred-length allocatable character and parameterized derived types - that's the major list I can think of. ... That goes to show in just how many different directions F03 extended the language. ... Support the Original G95 Project: http://www.g95.org ... Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html ...
    (comp.lang.fortran)
  • Re: Fortran has little support for object-oriented
    ... I don't understand this reasoning - dumbing down the language in order ... Support the Original G95 Project: http://www.g95.org ... Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html ...
    (comp.lang.fortran)
  • Re: data with metadata
    ... Ken Plotkin wrote: ... Data format should not be part of a language. ... Support the Original G95 Project: http://www.g95.org ... Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html ...
    (comp.lang.fortran)
  • Re: Starting to doubt fortran
    ... yes, it is a pretty decent language, easier to use for many things than some other languages. ... Fortran Library: http://www.fortranlib.com ... Support the Original G95 Project: http://www.g95.org ... Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html ...
    (comp.lang.fortran)
  • Re: The linf project (2)
    ... names for a single data type. ... Support the Original G95 Project: http://www.g95.org ... Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html ...
    (comp.lang.fortran)