The linf project
anal...@hotmail.com
fortran like language (but not fortran) for which a need exists IMHO.
I'll attempt to collect the language definition together and all
inputs are welcome, starting with James Giles' original specs:
My comments in square brackets.
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!
[Amen.]
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?
[a look and feel issue: periods ampersands, percent signs etc. in
contexts that give a slashqz feel to code would be extirpated.
single and double quotes should have the same functionality? ]
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.
[everything except integer double (do you really need single float
anymore) and basic character types should be realized through
libraries.]
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.
[modules it is. ]
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.
[external procs?
modules only for data?]
[The language will not attempt to provide safety by itself. All
facilities for safe coding will be provided and it would be the
responsibility of the programmer to discern teh safe features and only
use them.]
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.
[does this include structures? structures immediately introduce
slashqzs and I would stay away.]
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.
[YES - dynamic strings only.
fixed length realized as an array of chars of length 1.]
[prissy spinster-aunt features such as IN INOUT etc. don't belong.
The language will allow for correct legible fast code to be written
but will not sacrifice its internal beauty to protect programmers from
themselves.]
[optionals realized by contiguous commas?]
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).
[None except generic procedures.]
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.
[forget user defined operators - nerdy, prissy, too cute by half.]
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.)
Beliavsky
> The linf (look, its not fortran) project is an attempt to define a
> fortran like language (but not fortran) for which a need exists IMHO.
>
> I'll attempt to collect the language definition together and all
> inputs are welcome, starting with James Giles' original specs:
>
> My comments in square brackets.
>
> 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!
Good luck, you will need it. I suggest that your language be
translatable to Fortran 95, Fortran 77, or C, or otherwise you will
need to write a compiler, which is difficult. It sounds like you may
want to create a subset of Fortran 95. F and ELF90 were attempts at
this by experienced Fortranners, several of whom had served on
standards committees. Neither language became a commercial success,
although some programmers decided to use those subsets.
James Giles
> 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?
>
> [a look and feel issue: periods ampersands, percent signs etc. in
> contexts that give a slashqz feel to code would be extirpated.
> single and double quotes should have the same functionality? ]
oppose (for any language) having reserved keywords for reasons
I gave previously in the thread (or the other thread that this
continues). But the decision has consequences.
Now, what are the consequences of what answers you did
provide? I've never seen the word "slashqz" before. But
I presume you mean the C-like line noise simulation. While
it's true that cryptic notation should be avoided whenever
possible, there are no absolutes.
A language needs clarity, succinctness (without being terse),
and there are only so many characters to choose from. If you
leave out features because *you* think their notation is not
aesthetic, you will also be leaving out users that need that
feature. If you design-out what you consider the inaesthetic
notation, the feature is likely to be verbose and *less*
legible - and, again, you will leave out users that need the
feature frequently. Language design is an exercise in
compromise.
Hmm. No ampersands? How do you do continuation? And
don't say column 6. That's seriously anti-productive no matter
how large or small programs are, no matter how fast or slow
you develop them, and no matter how long you intend them to
last.
Of course, especially if there is no arbitrary line length limit,
you *could* say that no continuation is allowed. I doubt you
would get much agreement.
For a simple language (and, I believe, for *any* language)
continuation should be explicit and there should be only one
syntax for it. (There are productivity experiments that
demonstrate that line-wrapping instead of explicit continuation
is bad for productivity. And yes, even for short, quickly
written programs.)
And, continuation shouldn't be allowed to break any tokens.
I think the best solution is the only one that Fortran
explicitly prohibits: the continuation character should
be the first non-blank character of the continuing line,
not the last non-comment character of the continued line.
And the continuation character should be required on every
line (after the initial line), even otherwise blank lines,
or lines with only comments. Oh, and there should be no
arbitrary limit on how many lines a statement can span.
(As another aside, if two lines both begin with a continuation
character, they must both be part of the same continued
statement. Ending one statement and beginning another
incomplete one on the same line is a nasty practice
that the language can easily just prohibit.)
Now, what should that continuation character be? I like the
ampersand. It's a ligature for the Latin word et. Using it
to denote continuation is closer to the usual meaning of et
(in Latin sayings I've been exposed to anyway - I don't pretend
I know Latin) than, say, using it to mean logical AND.
I mentioned before that your character set is limited. If
you are really serious about developing a language, I'm
sure you'll find yourself staring at the summary card for
your character set and wishing there were more (and that
they more closely fit the meanings you wish to ascribe to
them). Continuation is probably the least cryptic use of
ampersand you are likely to find. You can even put it in
column 6 if you like.
Hmm. No cryptic periods? OK that leaves .TRUE. and
.FALSE. out of the language. You don't think that's cryptic?
You've been indoctrinated. In most languages that have
enumerated types (yes, that's what LOGICAL is) the literals
are just ordinary identifiers. I think that enumeration literals
actually *should* be distinct from identifiers. I may be the
odd man out. Whether delimiting with periods is the best
way to make them distinctive is hard to judge (I'm indoctrinated
too).
And, you can't have .AND., .LE., etc. Well, I think the usual
symbolic operators are preferable anyway. I haven't seen any
actual experiments proving it, but it seems right. For AND, OR,
NOT, and NEQV (XOR), I prefer /\, \/, ¬ (~), and ><. And since
you prefer leaving out user defined operators (with the loss of
users that like them), I guess you can to without periods as
delimiters.
Hmm. No cryptic percent? OK without delimited enumeration
literals or operators you can use period. Oh, but you said
you didn't want *any* derived types. OK, so you do without
a quite large segement of your potential users.
> 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.
>
> [everything except integer double (do you really need single float
> anymore) and basic character types should be realized through
> libraries.]
Well, I didn't mention "integer double". Perhaps you meant
"integer, double, and basic character types"? In any case, how
does'someone realize a new data type through libraries. I've
never seen that done. If you mean the clumsy way we used to
simulate derived types with integer arrays and type-cheats,
that clearly *not* a recipe for improving productivity, whether
the program is rapidly prototyped or written for the long haul.
> 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.
>
> [external procs?
>
> modules only for data?]
>
> [The language will not attempt to provide safety by itself. All
> facilities for safe coding will be provided and it would be the
> responsibility of the programmer to discern teh safe features and only
> use them.]
I agree that features that decrease the expressiveness of a language
merely for the elusive goal of safety are to be avoided. However,
putting procedures into modules *doesn't* decrease expressiveness
(in fact, by allowing the sharingof PRIVATE things, your expressive-
ness is increased). Adopting less expressive features simply to
make the language less safe seems lose/lose to me.
> 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.
>
> [does this include structures? structures immediately introduce
> slashqzs and I would stay away.]
Ok, but I should warn you that you are probably not only in a
small minority, but very close to unique in your opposition
to user defined data types.
> 7)
> [...]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.
[...]
> [prissy spinster-aunt features such as IN INOUT etc. don't belong.
> The language will allow for correct legible fast code to be written
> but will not sacrifice its internal beauty to protect programmers from
> themselves.]
Well, you are pretty much alone on this one too. Nice propaganda
though.
I don't have all to address what's likely to die on the vine anyway.
But:
> (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.)
I think you need to take this to heart. An informally ordered
unsystematic presentation simply confuses. I suspect most
aren't reading this. You need to specify clearly, and in some
systematic order what your language's syntax, semantics, and
pragmatics are expected to be. And, since it's such a big subject,
you should probably stick to a single issue or feature per article,
not the whole language. I made an extensive list only to point
out how big the subject really was.
--
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
anal...@hotmail.com
OK. I really appreciate your time and and let us go one or two issues
at a time (as of now I am seriously expecting to have spec-ed out the
linf language by the end of this dialog - which I can see can take
months).
agreed - no reserve words. And here we are also in philosophical
agreement - we will not try to protect the programmer from folly such
as calling variables "DO" or "IF" or "TRUE" etc. (by the way , "OPEN"
and "CLOSE" are very much needed natural variable names).
I believe we have also agreed that [],{} and () mean exactly the same
thing, as do ' and " .
Spaces are only for aesthetic reasons except within chracter literals.
Can we agree that linf will use as few special characters as possible
(@ # % & | etc.) ?
would the null character have to be recognized?
Should we allow ";" as an optional statement delimiter?
It seems useful for writing several small assignment statements in the
same line.
By the way I want linf to be a compiled language - I don't know how
that would affect program statements are delimited.
continuation characters are fundamentally unaesthetic and REQUIRING a
statement delimiter such as ";" induces an urge to physical violence
in me.
can carriage return or Carriage return/linefeed serve as the implicit
delimiter ? In other words, the responsibility is with the program
code editor not to put in CRs when the programmer wants a long
statement?
I'd like to hash the above issues out before proceeding further.
> that there are no obvious deficiencies." -- C. A. R. Hoare- Hide quoted text -
>
> - Show quoted text -
James Giles
...
> Spaces are only for aesthetic reasons except within chracter literals.
Well, I disagree with that. Again, making spaces insignificant
doesn't improve the language in any useful way. It just makes
some errors harder to find (for both the user and the compiler).
Why not make them significant?
> Can we agree that linf will use as few special characters as possible
> (@ # % & | etc.) ?
It's your language. I'll just comment that such characters may have
unexpected (and quite good) uses. Don't be arbitrary.
> would the null character have to be recognized?
Except blanks (and maybe tabs) no unprintable character should be
permitted - especially not in character literals (whose meaning should
match their appearance).
> Should we allow ";" as an optional statement delimiter?
It's allowed in Fortran and I never use it. It's allowed in my own
language and I use it only in a particular idiom:
Do; while(cond)
...
Until(cond); end do
Since WHILE and UNTIL are separate statements, they can be
anywhere in the block. But if they happen to be coincident with
one end or the other I think the code reads better if they're on the
same line.
> It seems useful for writing several small assignment statements in the
> same line.
I suppose. I don't write any code that way. I have no evidence it's
a bad thing to do.
> By the way I want linf to be a compiled language - I don't know how
> that would affect program statements are delimited.
Whether the language is compiled or not usually makes no syntactic
difference. It can make some semantic differences (but probably
most such things should work as if the language were compiled).
...
> can carriage return or Carriage return/linefeed serve as the implicit
> delimiter ? In other words, the responsibility is with the program
> code editor not to put in CRs when the programmer wants a long
> statement?
An example would clarify here. I don't understand what distinction
you're making. Show me an example of a sequence of lines containing
Fortran-like statements, some of which are continued and some aren't.
glen herrmannsfeldt
(snip)
> Should we allow ";" as an optional statement delimiter?
> It seems useful for writing several small assignment statements in the
> same line.
Not so bad for assigning the same value to many variables.
Well, whatever is most readable. Multiple assignment of
the same value is usually readable.
C has: a=b=c=1;
PL/I has: a,b,c=1;
-- glen
James Giles
Depends on the semantics. If a, b, and c are different types and
implicit converions are applied right to left, the answer can be
quite confusing. Of course, for this example, 1 is 1 is 1 (for
most numeric types anyway).
But suppose the constant were 0.1d0? In C, if the variable c is
an integral type all three variables are set to 0 no matter what
the types of a and b are. I don't remember the PL/I rule.
In practice, people don't use this much even in languages that
allow it. I have several papers on the semantics of multiple
assignment - somewhere. (I really need to unpack some
storage boxes.) But it may be moot since a rarely used
feature really has no place in a simple language.
Ron Ford
> Now, what should that continuation character be? I like the
> ampersand. It's a ligature for the Latin word et. Using it
> to denote continuation is closer to the usual meaning of et
> (in Latin sayings I've been exposed to anyway - I don't pretend
> I know Latin) than, say, using it to mean logical AND.
> I mentioned before that your character set is limited. If
> you are really serious about developing a language, I'm
> sure you'll find yourself staring at the summary card for
> your character set and wishing there were more (and that
> they more closely fit the meanings you wish to ascribe to
> them). Continuation is probably the least cryptic use of
> ampersand you are likely to find. You can even put it in
> column 6 if you like.
I didn't know that & meant "et" in Latin. So you could say Ora & Labora
where et is "and."
Had to look up ligature. The etymology is "to bind." The fourth
definition is "a printed or written character consisting of two or more
letters or characters joined together."
It used to be that there were plenty of Catholics who could help with
Latin. With Vatican II this far behind us, the Willaim Buckleys are nearly
dead or more. It's most frustrating when reading Gauss, who wrote in
Latin. If there's one author I'd like to read in his native tongue, it
would be him.
--
Ron Ford
Richard Maine
ether."
>
> It used to be that there were plenty of Catholics who could help with
One of my friends wore a tee-shirt to work a few years ago, which said
"sic hoc legere, scis nimium eruditionis habes." Rusty though my
highschool Latin was, I had to admit to being able to read at least
enough of that to interpolate the rest.
(And no, I didn't recall the exact Latin phrase to quote here, but close
enough to google and find an add for the tee shirt, giving me the rest.)
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
(snip, I wrote)
>>PL/I has: a,b,c=1;
> Depends on the semantics. If a, b, and c are different types and
> implicit converions are applied right to left, the answer can be
> quite confusing. Of course, for this example, 1 is 1 is 1 (for
> most numeric types anyway).
Yes, PL/I is not like C.
> But suppose the constant were 0.1d0? In C, if the variable c is
> an integral type all three variables are set to 0 no matter what
> the types of a and b are. I don't remember the PL/I rule.
That is related to = being an operator in C, where assignment
has a value. It is probably best not to use it in cases
where the assigned variables have different type.
It seems also that PL/I evaluates all subscript expressions
on the left side before evaluating the right side. It then
assigns left to right, though it would seem that in most
cases it shouldn't matter what order the assignments are
done in. Conversions from a temporary of the appropriate
type for the expression on the right are done for the
variables on the left. Also, PL/I allows array assignment,
structure assignment, and array of structure assignment
(and structures can contain arrays).
> In practice, people don't use this much even in languages that
> allow it. I have several papers on the semantics of multiple
> assignment - somewhere. (I really need to unpack some
> storage boxes.) But it may be moot since a rarely used
> feature really has no place in a simple language.
I probably only ever use it in C for assigning zero or one,
and mostly in loop initializations.
-- glen
David Simpson
a lot of the baggage of old-fortran (e.g. common blocks!), and I still
like to use it where I can, even to build modules/routines before
implementing in a much larger program (give or take a few quibles).
Jan Vorbrüggen
> "sic hoc legere, scis nimium eruditionis habes." Rusty though my
> highschool Latin was, I had to admit to being able to read at least
> enough of that to interpolate the rest.
But by putting the comma a word too early, you certainly threw me.
Jan
Paul van Delst
I'm (just mildly) curious too. Why not use something else entirely. Like ruby, or python,
or <insert any other non-compiled language of choice>?
Creating a language simply so it's not Fortran..... hmmm....
Crikey, why am I even writing this? Five more minutes of my life I won't get back. Sigh
cheers,
paulv
GaryScott
These may be defined to mean the same thing in these languages, but
they don't necessarily mean the same thing. The first could be a
right to left sequential assignment possibly involving type conversion
(c=1;b=c;a=b). The second would be my prefered syntax if the intent
is to write the equivalent of a=1;b=1;c=1.
>
> -- glen
Beliavsky
> David Simpson wrote:
> > Just curious, why aren't you starting with e.g. F for this? F removed
> > a lot of the baggage of old-fortran (e.g. common blocks!), and I still
> > like to use it where I can, even to build modules/routines before
> > implementing in a much larger program (give or take a few quibles).
>
> I'm (just mildly) curious too. Why not use something else entirely. Like ruby, or python,
> or <insert any other non-compiled language of choice>?
I know Python but not Ruby. Python was born in 1991, and its creator
(GvR) could build upon decades of experience with programming
languages. There is little "cruft" in the current Python, and GvR is
leading an effort to create Python 3, which be allowed to break
backward compatibility and remove all cruft (as perceived by GvR). The
job of creating a "perfect" language modelled on Python is already
taken.
Fortran 2003 is very different. There is lots of cruft, for many
reasons, and I understand why the committee is not going to remove any
of it in future versions. So the project of creating of a better
Fortran-like language (FLL) that can leverage the vast investments in
Fortran compilers is interesting. I wonder if the Gfortran developers
have thought about creating a FLL that could leverage existing code in
Gfortran/GCC .
Here are a few things I'd like in an FLL:
(1) The code
character, allocatable :: x(2)
x = ["boy","girl"]
should create a two-element array of character strings, where the
individual elements have lengths 3 and 4.
(2) Use [] for function calls and array subscripts, to reduce the over-
use of () .
(3) Allow functions to return multiple values, so that a function
function foo(a,b) result(x,y)
could be written. This a useful feature of some Fortran competitors
such as Matlab/Octave and Python with Numeric.
(4) Allow variable types to be inferred from their first use, so that
one could write just
x = ["boy","girl"]
without the earlier declaration and get the same effect as intended in
(1). Variables would still have static typing, and explicitly
declaring variables would be permitted.
(5) Allow for generic functions as with C++ templates (but is it
possible without the complications of C++ templates).
(6) Have built-in data structures other than arrays, such as the list,
set, and dictionary of Python.
Paul van Delst
> On Jun 5, 9:09 am, Paul van Delst <Paul.vanDe...@noaa.gov> wrote:
>> David Simpson wrote:
>>> Just curious, why aren't you starting with e.g. F for this? F removed
>>> a lot of the baggage of old-fortran (e.g. common blocks!), and I still
>>> like to use it where I can, even to build modules/routines before
>>> implementing in a much larger program (give or take a few quibles).
>> I'm (just mildly) curious too. Why not use something else entirely. Like ruby, or python,
>> or <insert any other non-compiled language of choice>?
>
> I know Python but not Ruby. Python was born in 1991, and its creator
> (GvR) could build upon decades of experience with programming
> languages. There is little "cruft" in the current Python, and GvR is
> leading an effort to create Python 3, which be allowed to break
> backward compatibility and remove all cruft (as perceived by GvR). The
> job of creating a "perfect" language modelled on Python is already
> taken.
Same dog, different leg IMO.
And, FWIW, ruby is a little bit more perfect than python. :o) To quote Matz: "In
addition, it [python] was a hybrid language of procedural programming and object-oriented
programming. I wanted a scripting language that was more powerful than Perl, and more
object-oriented than Python. That's why I decided to design my own language."
> Fortran 2003 is very different. There is lots of cruft, for many
> reasons, and I understand why the committee is not going to remove any
> of it in future versions. So the project of creating of a better
> Fortran-like language (FLL) that can leverage the vast investments in
> Fortran compilers is interesting. I wonder if the Gfortran developers
> have thought about creating a FLL that could leverage existing code in
> Gfortran/GCC .
Well, what you call cruft, others might call critical.
I guess that, given the raft of alternatives already available, I'm slightly amazed that a
response to what is not liked about f2003 is to create a completely new language.
I mean, don't we have enough things to do already?
If you want an "FLL", try IDL:
>
> Here are a few things I'd like in an FLL:
>
> (1) The code
>
> character, allocatable :: x(2)
>
> x = ["boy","girl"]
IDL> x = ["boy","girl"]
IDL> help, x
X STRING = Array[2]
IDL> help, strlen(x)
<Expression> LONG = Array[2]
IDL> print, strlen(x)
3 4
>
> should create a two-element array of character strings, where the
> individual elements have lengths 3 and 4.
>
> (2) Use [] for function calls and array subscripts, to reduce the over-
> use of () .
See example above.
> (3) Allow functions to return multiple values, so that a function
>
> function foo(a,b) result(x,y)
>
> could be written. This a useful feature of some Fortran competitors
> such as Matlab/Octave and Python with Numeric.
Eh. That, to me, looks like cruft. Or, more politely, a Special Case (tm). :o)
> (4) Allow variable types to be inferred from their first use, so that
> one could write just
>
> x = ["boy","girl"]
>
> without the earlier declaration and get the same effect as intended in
> (1). Variables would still have static typing, and explicitly
> declaring variables would be permitted.
IDL> q = ["boy","girl"]
IDL> help, q
Q STRING = Array[2]
IDL> q = 3.1415927
IDL> help, q
Q FLOAT = 3.14159
IDL> q = 3.1415927d0
IDL> help, q
Q DOUBLE = 3.1415927
IDL> q = 14B
IDL> help, q
Q BYTE = 14
Obviously not statically typed. But, why let that get in the way after the first
assignment? :o)
>
> (5) Allow for generic functions as with C++ templates (but is it
> possible without the complications of C++ templates).
>
> (6) Have built-in data structures other than arrays, such as the list,
> set, and dictionary of Python.
How are your (5) and (6) distinguishable from "cruft"?
cheers,
paulv
GaryScott
Allow the programmer to decide his convention. I prefer () for
funcion calls and [] for arrays. (i.e. treat () and [] as
interchangeable.)
>
> (3) Allow functions to return multiple values, so that a function
>
> function foo(a,b) result(x,y)
>
> could be written. This a useful feature of some Fortran competitors
> such as Matlab/Octave and Python with Numeric.
>
> (4) Allow variable types to be inferred from their first use, so that
> one could write just
>
> x = ["boy","girl"]
I don't like much of anything being inferred.
Richard Maine
doing so. I don't find interactions with the OP to be useful. (In fact,
I have him killfiled).
Beliavsky <beli...@aol.com> wrote:
> (4) Allow variable types to be inferred from their first use, so that
> one could write just
>
> x = ["boy","girl"]
>
> without the earlier declaration and get the same effect as intended in
> (1). Variables would still have static typing,
Ouch. That seems like a *HORRID* combination. So the typing is order
dependent in the source code? Swap 2 lines and the implied typing
changes, but you are still stuck with whatever one you get? Seems like
you are either saying that or perhaps you are asking for something that
is so strict about implicit conversions that there is never any
possibility of ambiguity, which seems entirely at odds with the rest of
the style suggested. That is
x = 42
tells you for sure that x is an integer scalar. It can't be a real, it
can't be an array, and, because of the static typing, it can't ever
become one of those.
Not to speak of all the contexts where a type can't be inferred, unless
you'll somehow get rid of all of those. So
x = 42
call sub(x)
implicitly declares x, but
call sub(x)
x = 42
doesn't?
anal...@hotmail.com
I am saying that statement delimiters are these and only these:
(1) The start of the source code file
(2) Whatever yoru editor puts into the file when you press "enter"
(3) The end of the source code file
Whatever wraps are performed to visually show the coder his code
should be irrelevant.
How do you react to the idea of a specialized souce code editor (an
editor that would say things like do you mean "character" instead of
"charcater"?) ?
coloring keywords also seems to be very helpful with respect to
productivity.
GaryScott
Please don't entangle the language with the editor this way. You
should be able to use any text editor that you prefer. Nearly all
support basic syntax highlighting and coloring and support building
macros to do nearly everything you've listed related to formatting
(including spell checking and auto-correction).
>
>
>
>
>
> > --
> > 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 -- Hide quoted text -
James Giles
Well, I can't speak for the OP doing this, but there are things
a language needs (so you can't just remove them) which Fortran
(even F) isn't well designed for. So, just subsetting won't do.
If you are designing a wholly new language you have the
opportunity to to fix some of these things. But that means
you aren't a subset.
Further, the OP even wants to cut deeper than the F specification
did. F still has pointers, derived types, etc.
James Giles
...
> And, FWIW, ruby is a little bit more perfect than python. :o) To
> quote Matz: "In addition, it [python] was a hybrid language of
> procedural programming and object-oriented programming. I wanted a
> scripting language that was more powerful than Perl, and more
> object-oriented than Python. That's why I decided to design my own
> language."
I guess you have to define the word "perfect". And what again
is the difference between "procedural" and "object oriented"?
The syntax for invoking procedures is different. And the
syntax for declaring procedures is different. And in OOP they
are called "methods" instead of "procedures". That seems to be all.
Now I'm the first to say that syntax is important. A language with
incomprehensible syntax is a bad language no matter how impeccable
the semantics and pragmatics of the language are. But the above
doesn't seems sufficient to qualify as a major paradigm shift.
James Giles
...
>>> can carriage return or Carriage return/linefeed serve as the
>>> implicit delimiter ? In other words, the responsibility is with the
>>> program code editor not to put in CRs when the programmer wants a
>>> long statement?
>>
>> An example would clarify here. I don't understand what distinction
>> you're making. Show me an example of a sequence of lines containing
>> Fortran-like statements, some of which are continued and some aren't.
>
>
> I am saying that statement delimiters are these and only these:
>
> (1) The start of the source code file
>
> (2) Whatever yoru editor puts into the file when you press "enter"
>
> (3) The end of the source code file
>
> Whatever wraps are performed to visually show the coder his code
> should be irrelevant.
Oh, so you mean that you really are taking an option I mentioned
before: since line lengths aren't limited you will not allow continued
source statements at all. A single statement must be entirely on one
line. Then you're relying on the source editor to display such things
(with some clarity let's hope).
This really doesn't answer the problem since you've just dumped
the burden onto the text editor. It's clarity that's the most important.
However continuations are handled must be clear to the programmer.
The harder it is to tell what's going on simply, the longer it's going
to take for the programmer to do his job. Is the editor required to
highlight lines that have been wrapped? Is it guaranteed to indent
wrapped lines as far as (or further than) the initial line? I'm not
allowed to use my own favorite editor? :-(
John Harper
Beliavsky <beli...@aol.com> wrote:
>
>(1) The code
>
>character, allocatable :: x(2)
>
>x = ["boy","girl"]
>
>should create a two-element array of character strings, where the
>individual elements have lengths 3 and 4.
>
>(4) Allow variable types to be inferred from their first use, so that
>one could write just
>
>x = ["boy","girl"]
>
>without the earlier declaration and get the same effect as intended in
>(1). Variables would still have static typing, and explicitly
>declaring variables would be permitted.
The "same effect" would make x allocatable. Is that consistent with
static typing?
And in the absence of any declaration of y,
y = 1
would make y of integer type. The opposite problem has long been with
us: a colleague once admitted he found that my data wouldn't give
sensible results with his program because my name begins with J so
his program had assumed my real numbers were integers.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045
Ron Ford
I see a differing error in that the first word should be Si. If he meant
sic, he could write sic [sic] hoc legere ....
There seems to be a lot of webpages out there with Latin sayings. This one
is drop-dead funny:
http://www.biopsych.net/psyhumor/latin_phrases_for_all_occasions.htm
My favorites were:
Caesar si viveret, ad remum dareris.
If Caesar were alive, you'd be strapped to an oar.
Insula Gilliganis.
Gilligan's Island
--
Ron Ford
Paul van Delst
> Paul van Delst wrote:
> ...
>> And, FWIW, ruby is a little bit more perfect than python. :o) To
>> quote Matz: "In addition, it [python] was a hybrid language of
>> procedural programming and object-oriented programming. I wanted a
>> scripting language that was more powerful than Perl, and more
>> object-oriented than Python. That's why I decided to design my own
>> language."
>
> I guess you have to define the word "perfect". And what again
> is the difference between "procedural" and "object oriented"?
> The syntax for invoking procedures is different. And the
> syntax for declaring procedures is different. And in OOP they
> are called "methods" instead of "procedures". That seems to be all.
>
> Now I'm the first to say that syntax is important. A language with
> incomprehensible syntax is a bad language no matter how impeccable
> the semantics and pragmatics of the language are. But the above
> doesn't seems sufficient to qualify as a major paradigm shift.
That part of my post was slightly toungue-in-cheek, but your point is valid. I simply
prefer ruby because the first book I picked up told me *everything* in ruby was an object
(my python book tells me that *most* things in python are objects) Since I wanted to learn
a "real" OO language in preparation for f2003, I figured I'd pick the one with no special
cases.
But, regardless, I agree with you.
cheers,
paulv
p.s. Now, how can we construct a sentence that includes both of the words "paradigm" and
"synergy"? :o)
dpb
...
> words "paradigm" and "synergy"? :o)
I guess they would be synergistic paradigms... :)
--
anal...@hotmail.com
I actually changed my mind. The coder might want to insert "enter"
into his code to split a multi-line (line here would mean what the
program editor considers a line) statement for legibility.
based on your and Gary Scott's comments no special editor would be
necessary (although one wouldn't hurt and I plan to propose an editor
that would do corrections and insert lines to take care of crossing
t's and dotting i's on behalf of teh coder.)
So we have to burn a special character for statement separation - and
semicolon it is then. This way we get uniformity - both "long" and
"short" program statements would be separated by semicolons.
I also want an iron rule that
(1) Linf source code will minimize the use of special characters.
(2) Each special character will perform exactly one function and no
more ("synonyms" are allowed - we have already agreed that [], {} and
() would mean the same, as would " and '.)
Going forward, I plan to post the agreed upon features at the top and
carry out the discussion of the topic at hand after that.
I also think linf should be a small language definable in 10 pages or
fewer.
> "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
dpb
...
> So we have to burn a special character for statement separation - and
> semicolon it is then. This way we get uniformity - both "long" and
> "short" program statements would be separated by semicolons.
Bleech... :( I _detest_ the EOL character requirement.
(See how easy it is to satisfy everybody? :) )
--
Paul van Delst
> anal...@hotmail.com wrote:
> ...
>> So we have to burn a special character for statement separation - and
>> semicolon it is then. This way we get uniformity - both "long" and
>> "short" program statements would be separated by semicolons.
>
> Bleech... :( I _detest_ the EOL character requirement.
Yeah, it makes the source code look decidedly low-rent. That is, "we couldn't bothered
doing it right."
anal...@hotmail.com
OK - what do you suggest?
All source being free form, it would be best to avoid continuation
characters.
we need two things EOL (end of line as seen by the editor) and EOS
(end of statement as seen by the compiler).
EOS = EOL or ; makes a lot of sesne.
But then if you say that each EOL is also an EOS then you lose the
ability to wrap a long program-statement into several editor-lines in
a way that increases legibility.
I happen to loathe ";", ":" etc. in programming languages and if ";"
does appear in a language, it is better if it is strictly relegated to
a trivial function (namely program statement separation).
and we might as well open up the next can of worms - comments:
/* 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)?
dpb
>> Bleech... :( I _detest_ the EOL character requirement.
> OK - what do you suggest?
>
> All source being free form, it would be best to avoid continuation
> characters.
...
I don't have any problem w/ continuation lines...far preferable imo to
the EOL character solution.
--
James Giles
...
> So we have to burn a special character for statement separation - and
> semicolon it is then. This way we get uniformity - both "long" and
> "short" program statements would be separated by semicolons.
> Going forward, I plan to post the agreed upon features at the top and
> carry out the discussion of the topic at hand after that.
Well, I think you should say "features that you've decide upon".
You're the only one in agreement here. I've already stated that
objective experiments have shown that languages that just
wrap until you reach explicit statement terminators are less
productive than ones that require explicit continuation marks.
(Comments that just wrap until you reach a comment terminator
are also known to be bad.)
It's your language and you can decide what you like, but don't
call it an agreement with the rest of us.
--
J. Giles
James Giles
...
> /* 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
dpb
...
> and we might as well open up the next can of worms - comments:
>
> /* and */ to include blocks of comments anywhere in the code
NO! and double NO! NO! (See James' response for more than a visceral
reaction :) ).
> ...(no
> special ways to start a comment line or comments at the end of a
> program statement)?
I'm in agreement w/ JG here and while one could live w/o them if had to
(I suppose), I certainly use end-of-line comments extensively so
wouldn't like to not have that as a feature, either...
--
Gordon Sande
> On Jun 6, 12:49 pm, dpb <n...@non.net> wrote:
>> analys...@hotmail.com wrote:
>>
>> ...
>>
>>> So we have to burn a special character for statement separation - and
>>> semicolon it is then. This way we get uniformity - both "long" and
>>> "short" program statements would be separated by semicolons.
>>
>> Bleech... :( I _detest_ the EOL character requirement.
>>
>> (See how easy it is to satisfy everybody? :) )
>>
>> --
>
> OK - what do you suggest?
>
> All source being free form, it would be best to avoid continuation
> characters.
>
> we need two things EOL (end of line as seen by the editor) and EOS
> (end of statement as seen by the compiler).
>
> EOS = EOL or ; makes a lot of sesne.
>
> But then if you say that each EOL is also an EOS then you lose the
> ability to wrap a long program-statement into several editor-lines in
> a way that increases legibility.
Having an editor rewrap a carefully formatted long expression
does not seem very friendly. As in - to hell with being able to read it!
Editors are so personal that asking most to change is a nonstarter.
I like treating operators like +, -, *, or / and syntax elements like
( or = as continuation operators as they signal more is to come. To
force continuation something like _ is nice. This means that _ in
identifiers is like capitalization in that it helps reading but is
otherwise of no import. (To deal with operating systems that
require other conventions there needs to be either an alias mechanism
of a local pass through that can be done with quoting. Reverse quotes
are not otherwise used in practice.)
Continuing strings seems like a exercise in being overly and obsessively
concerned with consistency as there is always a concatenation operator
around.
/ as continuation does not work with Fortran DATA statements but that
is more a comment on the curious form of DATA statements.
> I happen to loathe ";", ":" etc. in programming languages and if ";"
> does appear in a language, it is better if it is strictly relegated to
> a trivial function (namely program statement separation).
>
> and we might as well open up the next can of worms - comments:
>
> /* 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)?
I have never found comments in the middle of statements very readable.
Any of the many conventions of a single opening character makes a comment
that goes to the end of the line is OK. Well almost any as I find -- a bit
curious as I have been long cultured to #. ! should not so I am not
fond of the F90 free format convention in other contexts. ! and | end
up looking similar but the same confusion exists away from programming
languages so one is used to noticing the details more closely.
Nesting of comments implied by comment blocks seems like an accident
waiting to ambush any passers by.
I have used a modified RatFor with these conventions and found others
can also read the code. [ and ] for subscripts is possible instead of
the over used ( and ).
dpb
...
> I don't have any problem w/ continuation lines...far preferable imo to
> the EOL character solution.
Stylistically, I prefer the Matlab or VB choice of the ellipsis (...) or
underscore (_) over the Fortran ampersand as a choice altho it's
somewhat immaterial. The ellipsis is a little bit of a pita from simply
a typing standpoint but it does have visual impact better than the
single underscore. I agree w/ the precept of not allowing splitting of
any symbol/token and therefore no need for the trailing and leading
indicator characters; the single trailing continuation character is enough.
--
anal...@hotmail.com
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.
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.
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?
dpb
...
> Dictatorial decision # 1: semicolons and only semicolons are
> statement separators. No continuation character.
Just lost one user... :)
...
> Any comments on /* and */ as comment containers?
Comments already made...it's a pxxx-poor choice of forming comments.
--
dpb
...
> Comments already made...it's a pxxx-poor choice of forming comments.
To be slightly more constructive -- any decent editor can insert comment
characters appropriately automagically to comment out any selected block
of code so the encapsulating-style comments offer no positive benefit,
only the drawbacks outlined by James previously.
--
Ron Ford
> James Giles wrote:
>> Paul van Delst wrote:
>> ...
>>> And, FWIW, ruby is a little bit more perfect than python. :o) To
>>> quote Matz: "In addition, it [python] was a hybrid language of
>>> procedural programming and object-oriented programming. I wanted a
>>> scripting language that was more powerful than Perl, and more
>>> object-oriented than Python. That's why I decided to design my own
>>> language."
>>
>> I guess you have to define the word "perfect". And what again
>> is the difference between "procedural" and "object oriented"?
>> The syntax for invoking procedures is different. And the
>> syntax for declaring procedures is different. And in OOP they
>> are called "methods" instead of "procedures". That seems to be all.
>>
>> Now I'm the first to say that syntax is important. A language with
>> incomprehensible syntax is a bad language no matter how impeccable
>> the semantics and pragmatics of the language are. But the above
>> doesn't seems sufficient to qualify as a major paradigm shift.
>
> That part of my post was slightly toungue-in-cheek, but your point is valid. I simply
> prefer ruby because the first book I picked up told me *everything* in ruby was an object
> (my python book tells me that *most* things in python are objects) Since I wanted to learn
> a "real" OO language in preparation for f2003, I figured I'd pick the one with no special
> cases.
I spend a fair amount of time developing ruby capabilities. A lot of
people who post here are working up a game in ruby as well. The visual
capabilities are simply stunning with their tie-ins to things like Google's
SketchUp. I haven't tried interoperation with fortran, but I haven't had a
reason to yet. I do like that everything's an object. It takes all the
guesswork out of it. And no, I would never want that for fortran.
The test suite that Andrew Chen had for fortran was realized through ruby.
It had problems but the method seems popular for the right reasons.
--
Ron Ford
I missed /* ... */ sincerely when I forsook C for its common extension,
fortran. (I think it's funny how C defines fortran.)
I regained much of this functionality by using the Plato IDE. It
comments-out blocks, which a person can comment back in using the same GUI
tools.
PROGRAM GLAVNI
! GLAVNI PROGRAM ZA ANALIZU POTENCIJALNOG STRUJANJA OKO BRODA
! Main program for potential flow analysis around the ship hull
! USE MSFLIB
REAL MINUTE
INCLUDE 'PARAM.FOR'
INCLUDE 'COMMON.FOR'
INTEGER NDS,BDS,BDSM,CC,SIT,M,MM,IDEV,ROTELIP,UT
CHARACTER*11 SIG(30),SIGSP(30)
C$$$$$$ DATA SIG/'SIGME01.PLT','SIGME02.PLT','SIGME03.PLT',
C$$$$$$ & 'SIGME04.PLT','SIGME05.PLT','SIGME06.PLT',
C$$$$$$ & 'SIGME07.PLT','SIGME08.PLT','SIGME09.PLT',
C$$$$$$ & 'SIGME10.PLT','SIGME11.PLT','SIGME12.PLT',
C$$$$$$ & 'SIGME13.PLT','SIGME14.PLT','SIGME15.PLT',
C$$$$$$ & 'SIGME16.PLT','SIGME17.PLT','SIGME18.PLT',
C$$$$$$ & 'SIGME19.PLT','SIGME20.PLT','SIGME21.PLT',
C$$$$$$ & 'SIGME22.PLT','SIGME23.PLT','SIGME24.PLT',
C$$$$$$ & 'SIGME25.PLT','SIGME26.PLT','SIGME27.PLT',
C$$$$$$ & 'SIGME28.PLT','SIGME29.PLT','SIGME30.PLT'/
I see that C is considered more appropriate for this occasion than !.
--
It doesn't take a majority to make a rebellion; it takes only a few
determined leaders and a sound cause.
H. L. Mencken
glen herrmannsfeldt
(snip)
> Dictatorial decision # 1: semicolons and only semicolons are
> statement separators.
Separators or terminators? In C, C++, Java, and PL/I they
are statement terminators. In Pascal, they are statement
separators, the difference being most obvious in IF/THEN/ELSE
constructs.
-- glen
Gary Scott
Just lost 62% of your market share.
>
> 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 "!"
>
>
--
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
anal...@hotmail.com
will you please explain the difference with a small example?
Thanks.
anal...@hotmail.com
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?
>
>
> --
>
> 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 -
Dan Nagle
On 2008-06-07 06:42:35 -0400, anal...@hotmail.com said:
>
> Since semicolon has alredy entered official fortran, I think that
> getting rid of continuation characters adds to the aesthetics of
> source code.
Aesthetics? I won't argue.
Perception psychology says to mark the unusual case,
rather than the usual case. That helps the eye
catch the unusual case.
I think continuation is less usual;
one statement per line is more usual.
YMMV, I suppose.
--
Cheers!
Dan Nagle
Gordon Sande
In languages with reserved BEGIN and END the question is whether
you need a semicolon before an END. For separator the answer is no
but for terminator the answer is yes (and causes lots of confusion).
If the mode is separator then the semicolon before the END generates
a null statement which does nothing.
Thomas Koenig
> So the project of creating of a better
> Fortran-like language (FLL) that can leverage the vast investments in
> Fortran compilers is interesting. I wonder if the Gfortran developers
> have thought about creating a FLL that could leverage existing code in
> Gfortran/GCC .
Not seriously.
There's a longstanding wishlist item to implement the F restrictions
in gfortran, but nobody has done any serious work on it. There's
more than enough work fixing bugs and implementing F2003 features :-)
anal...@hotmail.com
>
> - Show quoted text -
I am pretty positive that I don't want to have any reserved words - in
that case would statement terminators and separators be equivalent?
Gordon Sande
For BEGIN read {, for END read } and then read the above again.
If you are not into { and } then use what ever you have in mind for
beginning statement group and ending statement group.
From the tone of your questions and decisions I expect that I bailed
out of your market some time ago. I do use a preprocessor to modify
some of the Fortran decisions. Now that is largely inertia on syntactic
sugar but it also provides a number of software engineering capabilites
that are not part of Fortran.
anal...@hotmail.com
I am kind of in a "field of dreams" mode - you know - "if you build
it, they will come" :-)
I think that Fortran achieved phenomenal success just around the time
structured programming concepts were discovered and doing things
differently from fortran seems to have been the guiding principle of
programming languages that came afterwards.
But I think that lurking somewhere in all the fortrans and anti-
fortrans extant today - an irreducible core language exists that can
ideally address a fairly well-defined set of needed programming tasks
and linf is my attempt to bring it out.
Jumping ahead - linf will hve exactly the same subprograms as Fortran
- subroutines and functions:
So instead of
Subroutine sub(a,b,c)
statements
return
end
Linf will read
subroutine sub(a,b,c);
statement1;
statement2;
....
statementn;
return;
end;
I see it having exactly one do statement and an if statement that
would work exactly as in fortran.
As far as I can see insisting on that ";" at the end is all that would
differentiate linf from fortran in terms of writing language
statements and i still don't see the need to differentiate statement
separators from statement terminators.
Of course the ";' will be forgotten from time to time leading to
unexpected behavior but thats something that would become mostly
automatic over time (as it has for me with the ";" language I am using
to earn my living these days).
I do use a preprocessor to modify
> some of the Fortran decisions. Now that is largely inertia on syntactic
> sugar but it also provides a number of software engineering capabilites
> that are not part of Fortran.- Hide quoted text -
Gary Scott
No, I prefer that end of line (CR/LF, etc) is equivalent to end
statement, including comment
dpb
...
> Subroutine sub(a,b,c)
> statements
...
> Linf will read
>
> subroutine sub(a,b,c);
> statement1;
But _why_? What is gained by the extra obfuscation and the added pita
of the occasional missed terminator that makes up for more than that by
sufficient [fill in the blanks here] properties?
> I see it having exactly one do statement and an if statement that
> would work exactly as in fortran.
Well, that's a start, but there are many other branching and looping
constructs that are also useful in their place. Why force everything to
look like a nail just because you're only going to let the programer
have a hammer instead of a hammer _and_ a screwdriver?
> As far as I can see insisting on that ";" at the end is all that would
> differentiate linf from fortran in terms of writing language
> statements and i still don't see the need to differentiate statement
> separators from statement terminators.
If that is all that differentiates, then I fail to see the purpose in
having the line terminator instead of EOL.
> Of course the ";' will be forgotten from time to time leading to
> unexpected behavior ...
Which is the primary strike against it (and it's just simply ugly,
besides :) ) unless there is some overarching reason it is required and
as noted above that reason more than makes up for the losses owing to
the problems introduced (which, so far, you've shown no reason for it to
do so).
Aside--there already is such a programming language as you have
described (other than the ";") -- it's a subset of Fortran. All you
have to do is to restrict yourself to whatever subset pleases you.
Do you write in such a limited vocabulary w/ your present programming
language?
--
Gordon Sande
> anal...@hotmail.com wrote:
> ...
>
>> Subroutine sub(a,b,c)
>> statements
> ...
>> Linf will read
>>
>> subroutine sub(a,b,c);
>> statement1;
>
> But _why_? What is gained by the extra obfuscation and the added pita
> of the occasional missed terminator that makes up for more than that by
> sufficient [fill in the blanks here] properties?
>
>> I see it having exactly one do statement and an if statement that
>> would work exactly as in fortran.
>
> Well, that's a start, but there are many other branching and looping
> constructs that are also useful in their place. Why force everything
> to look like a nail just because you're only going to let the programer
> have a hammer instead of a hammer _and_ a screwdriver?
I used the Algol 60 FOR loop in all its many faceted glory at one time. Now
I find that the vanilla Fortran DO loop serves 90+% of the time. The rest
takes two forms: 1. chasing down a linked list 2. a DO where I want to
fuss with either or both the index and upper limit. The C FOR loop
packages both of these fairly compactly. One can ask whether WHILE and
UNTIL loops are DO loops or not but I tend to classify loop constructs as
to whether the index in included or not. Top, middle or bottom testing
separate these forms of nonindex loops.
A missing construct is the search that succeeds or fails but needs a cleanup
to deal with the failure. Nothing has struck me has so obvious and clear
that I should agitate for it.
anal...@hotmail.com
> analys...@hotmail.com wrote:
>
> ...
>
>
>
> > Subroutine sub(a,b,c)
> > statements
> ...
> > Linf will read
>
> > subroutine sub(a,b,c);
> > statement1;
>
> But _why_? What is gained by the extra obfuscation and the added pita
> of the occasional missed terminator that makes up for more than that by
> sufficient [fill in the blanks here] properties?
>
> > I see it having exactly one do statement and an if statement that
> > would work exactly as in fortran.
>
> Well, that's a start, but there are many other branching and looping
> constructs that are also useful in their place. Why force everything to
> look like a nail just because you're only going to let the programer
> have a hammer instead of a hammer _and_ a screwdriver?
>
> > As far as I can see insisting on that ";" at the end is all that would
> > differentiate linf from fortran in terms of writing language
> > statements and i still don't see the need to differentiate statement
> > separators from statement terminators.
>
> If that is all that differentiates, then I fail to see the purpose in
> having the line terminator instead of EOL.
Now that I am writing <=, < etc. .LE. and .LT. induce nausea. The
same thing with respect to continuation characters - they gotta go.
And as I mentioned earlier, since ";" has already entered f95 as a
statement separator/terminator - (I do wish somebody would explain the
difference to me) lets have uniformity.
On the other hand, I don't want to make a fetish of uniformity/
regularity (the undoing of F). I totally concur with James Giles'
suggestion that [], {} and () should mean the same thing and there
should be no differentiation of upper and lower case, although both
should be present in the language.
Both subroutine and function should be present but not four types of
do loops. The guiding pricinples are beauty and parsimony, but at the
same time recognizing that redundancy/synonyms etc. sometimes help the
human programmer.
(I have found it invaluable to write debugging code in lower case so
that if you have forgotten some short-circuiting code written earlier,
you can find it by looking for lower case - especially annoying
debugging output to the screen lurking amongst several program files
and thousands of lines of code.).
To get back to CR/LF -
"lines" would have no meaning to the compiler - thats for the monitor/
printer to worry about. In my current ";" language, I thrown in
"enter" around 70-80 characters so that I can edit code with a 80
column widow.
The compiler is only looking for program statements and commment
statements either of which which may be part of a line or span many
lines.
>
> > Of course the ";' will be forgotten from time to time leading to
> > unexpected behavior ...
>
> Which is the primary strike against it (and it's just simply ugly,
> besides :) ) unless there is some overarching reason it is required and
> as noted above that reason more than makes up for the losses owing to
> the problems introduced (which, so far, you've shown no reason for it to
> do so).
>
> Aside--there already is such a programming language as you have
> described (other than the ";") -- it's a subset of Fortran. All you
> have to do is to restrict yourself to whatever subset pleases you.
>
As a preview to what lies ahead, I am thinking of eliminating gotos
and statement numbers. Thoughts?
> Do you write in such a limited vocabulary w/ your present programming
> language?
>
I write enough for my boss to think that I am doing useful stuff :-).
More about my present language anon.
> --
dpb
> On Jun 7, 12:14 pm, dpb <n...@non.net> wrote:
>> analys...@hotmail.com wrote:
...
>>> differentiate linf from fortran in terms of writing language
>> If that is all that differentiates, then I fail to see the purpose in
>> having the line terminator instead of EOL.
>
> Now that I am writing <=, < etc. .LE. and .LT. induce nausea. The
> same thing with respect to continuation characters - they gotta go.
Well, of course, one can write eliminate those in F90, too... :)
But so you're eliminating one ugly piece of syntax (that is simply
syntax in that it is a symbol-parsing choice only) and introducing
another that clutters up the visual sense as a minimum and introduces
coding errors when forgotten (which as you've already mentioned aren't
always all that easy to find in the language which won't be mentioned
which uses them) -- makes absolutely _NO_ sense to me.
> And as I mentioned earlier, since ";" has already entered f95 as a
> statement separator/terminator - (I do wish somebody would explain the
> difference to me) lets have uniformity.
If the only reason is so you can write multiple statements on a visual
line, that's a verboten in my coding style anyway (or at least one that
is so rarely used I won't miss it if it isn't allowed). It simply isn't
sufficient imo to even consider. In fact, as above, it's one of the
areas in Fortran that if it were removed it wouldn't bother.
> On the other hand, I don't want to make a fetish of uniformity/
> regularity (the undoing of F). I totally concur with James Giles'
> suggestion that [], {} and () should mean the same thing and there
> should be no differentiation of upper and lower case, although both
> should be present in the language.
>
> Both subroutine and function should be present but not four types of
> do loops. The guiding pricinples are beauty and parsimony, but at the
> same time recognizing that redundancy/synonyms etc. sometimes help the
> human programmer.
But an occasional WHILE loop or CASE construct doesn't? Sorry, I don't
buy it.
> (I have found it invaluable to write debugging code in lower case so
> that if you have forgotten some short-circuiting code written earlier,
> you can find it by looking for lower case - especially annoying
> debugging output to the screen lurking amongst several program files
> and thousands of lines of code.).
That's not a bad style altho I would turn it around -- I no longer want
my code to SHOUT.
> To get back to CR/LF -
>
> "lines" would have no meaning to the compiler - thats for the monitor/
> printer to worry about. In my current ";" language, I thrown in
> "enter" around 70-80 characters so that I can edit code with a 80
> column widow.
Anything over should be broken into multiple lines (and attempted to
minimize as much as possible anyway) and should be at the programmer's
pleasure, not the whim of an editor whose ideas of where breaks should
be are undoubtedly never going to match up w/ more than one programmer
(and probably not even that one all the time).
It's simply going down the wrong path imo, looking for justification in
meaningless features.
What would be far more useful imo would be the direction some have taken
of mixing code and documents so that the compiler and the documentation
are inseparable and include whatever type of formatting up to and
including graphics, links to first source references, test data, etc.,
etc., etc., ... It would be the job of the editor/compiler to "handle it".
W/ such a fundamental disagreement on vision of what is "wrong" w/
Fortran and your apparent ideas of what is "right" w/ linf, I see no
point in my further participation.
--
dpb
...
> I used the Algol 60 FOR loop in all its many faceted glory at one time. Now
> I find that the vanilla Fortran DO loop serves 90+% of the time. The rest
> takes two forms: 1. chasing down a linked list 2. a DO where I want to
> fuss with either or both the index and upper limit. The C FOR loop
> packages both of these fairly compactly. One can ask whether WHILE and
> UNTIL loops are DO loops or not but I tend to classify loop constructs as
> to whether the index in included or not. Top, middle or bottom testing
> separate these forms of nonindex loops.
I don't know enough of Algol to know what facets its FOR had, sorry...
I was thinking of WHILE and similar top/bottom testing and CASE as
companion to IF as just examples where some richness is suited if not
mandatory.
It seemed to me OP was trying to minimalize to the point of absurdity
(actually, still does).
--
glen herrmannsfeldt
(I wrote)
>>Separators or terminators? In C, C++, Java, and PL/I they
>>are statement terminators. In Pascal, they are statement
>>separators, the difference being most obvious in IF/THEN/ELSE
>>constructs.
> will you please explain the difference with a small example?
C, C++, Java:
if(x>y) a=3;
else a=4;
PL/I:
if x>y then a=3;
else a=4;
Pascal:
if x>y then a=3
else a=4;
From: http://en.wikipedia.org/wiki/Pascal_programming_language
function next(k: integer): integer;
begin
next := k + 1
end;
Note, as someone else mentioned, no semicolon before the end
statement, and also not after the begin statement.
In most cases an extra semicolon will add a null statement
with no effect.
I believe ALGOL also uses semicolon as a separator, which is
likely where PASCAL got it from. PL/I, inheriting much from
ALGOL, didn't inherit that.
-- glen
Gary Scott
But you're adding 100's of times more unnecessary statement terminators
to replace the fairly rare continuation character. I don't think that's
a fair trade.
<snip>
Gary Scott
Supplemental data associated with the source doesn't even need to be
kept in the same file as the source code. There are many ways to
synchronize documentation, links to external files, links to requirement
documents (specifications), links to autogenerated code (e.g. from
UML/SysML). I would vote for this to be part of the development
environment, not the source code of the language. It would be nice to
have some of this standardized (and is being), external to the language
definition.
>
> W/ such a fundamental disagreement on vision of what is "wrong" w/
> Fortran and your apparent ideas of what is "right" w/ linf, I see no
> point in my further participation.
>
> --
James Giles
...
> 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.
No, it just adopt arbitrary and irrelevant aesthetics. The purpose
of punctuation is exactly what you seem to object about it: it makes
the code clearer. Aiding the programmer in writing clear, correct
code is the only purpose of a language. The only aesthetic of a
designer should be to work toward that end. No other aesthetic
is relevant.
> Do you agree that comments should be enclosed between comment starter
> and comment ender chracter sequences?
I've already pointed out that it's known to be counterproductive.
What other relevant consideration is there?
Gary Scott
Jovial also uses it...still a lot written in Jovial...
>
> -- glen
dpb
...
> ... I would vote for this to be part of the development
> have some of this standardized (and is being), external to the language
> definition.
I agree; I was simply suggesting that would be a more productive area
than OP's direction--I used "editor/compiler" which was probably a poor
choice as opposed to "language-aware IDE".
--
James Giles
...
> For BEGIN read {, for END read } and then read the above again.
> If you are not into { and } then use what ever you have in mind for
> beginning statement group and ending statement group.
Statement grouping is only needed for control constructs and
scoping constructs. Those constructs themselves should be
the delimiters, not anonymous grouping within. There were
some experiments in the 1970s that should be famous (or
even infamous) on that subject. One style consisted of:
if (contition) statement
Where "statement" is allowed to be a block (begin/end, {/},
doesn't matter). Another style consisted of the use of conditional
GOTOs (well, the keyword they used in the experiments was
JUMP). Another style essentially consisted of:
if (condition) then
...
endif (condition)
The first style (with the anonymous begin/end) lost. OK, it was
about tied with the JUMP language. (JUMP made more initial errors
but fixed them faster. You could judge either as the winner over
the other.) It matters not at all which of the two losers you regard
as best since the third form won so big: almost no errors related
to delimiting statements, and all errors that did occur were fixed
almost immediately.
The reason for the superiority of the last is that it became possible
to unambiguously identify which End went with which initial line.
(So labels, instead of reiterating the conditional expression is even
better.)
No language designed completely from scratch since those tests
has had the anonymous begin/end ({/}) style delimiting. Sure,
there are lots of "we designed the language to be C-like, but changed
so-and-so" languages. But those don't count as being from scratch.
Gordon Sande
> Gordon Sande wrote:
> ...
>> I used the Algol 60 FOR loop in all its many faceted glory at one time. Now
>> I find that the vanilla Fortran DO loop serves 90+% of the time. The rest
>> takes two forms: 1. chasing down a linked list 2. a DO where I want to
>> fuss with either or both the index and upper limit. The C FOR loop
>> packages both of these fairly compactly. One can ask whether WHILE and
>> UNTIL loops are DO loops or not but I tend to classify loop constructs as
>> to whether the index in included or not. Top, middle or bottom testing
>> separate these forms of nonindex loops.
>
> I don't know enough of Algol to know what facets its FOR had, sorry...
for i := 0 step 1 to 9, 10 step 10 to 90, 91 step 1 to 100 do
begin
...
end
is a pretty tame example as those things go. There were also logic
modifiers so there were various fixed iterations followed by convergence
tests. It has quie a while and I am not even sure where I could quickly
find a reference. (Yeh - Ask google!)
Conditional expressions were hard to give up. They were easy to abuse so
were a mixed blessing. One sees a goodly variety of hacks to get them
with the F90 features.
James Giles
...
> What would be far more useful imo would be the direction some have
> taken of mixing code and documents so that the compiler and the
> documentation are inseparable and include whatever type of formatting
> up to and including graphics, links to first source references, test
> data, etc., etc., etc., ... It would be the job of the
> editor/compiler to "handle it".
I've seen attempts to do that. And the clever people that
initially promote it make it look very nice. Then, average
programmers start using it and the result is illegible. The
documentation doesn't actually describe the code and the
code is difficult to find buried among all the documentation.
A language design is not judged by how well experts manage
to make it look, but by how well average programmers do when
using it day to day.
James Giles
...
> for i := 0 step 1 to 9, 10 step 10 to 90, 91 step 1 to 100 do
> begin
> ...
> end
The original of this preceeded Fortran (and was less wordy).
From memory, it was something like:
do i = 0 (1) 10 (10) 90 (1) 100
(The "DO=" is wrong, I only remember the part about the
extents and strides.) So, zero by one to ten, by ten to nenety,
and then by one to one hundred.
Ron Shepard
<a3d5c589-7b07-4e45...@k13g2000hse.googlegroups.com>,
anal...@hotmail.com wrote:
> Do you agree that comments should be enclosed between comment starter
> and comment ender chracter sequences?
In case this is not obvious, here is the problem with this approach.
Suppose you have some code like:
t = y /* save a copy */
y = x /* move the old one */
x = t /* swap the original values */
and you want to comment this out. Doing something like
/*
t = y /* save a copy */
y = x /* move the old one */
x = t /* swap the original values */
*/
would seem to be the obvious thing to do, right? But it doesn't
work, and it is really a PITA that it doesn't work.
Of course, there are other problems in the C language with this
approach that don't occur in fortran. For example, suppose that x
is a pointer to a floating point number, and *x is a reference to
that item, and you want to use that reference in an expression such
as y/*x to divide two numbers. See the problem? You didn't do what
looks like the obvious expression, you instead opened up a new
comment block which continues on until the end of the next "real"
comment string (which might even be in the next function in the
source code, not the one you are in at the time). This kind of crap
is extremely frustrating in a computer language, not only for humans
typing code but also for automatic code generation tools, string
substitutions, and so on.
$.02 -Ron Shepard
dpb
> dpb wrote:
> ...
>> What would be far more useful imo would be the direction some have
>> taken of mixing code and documents so that the compiler and the
>> documentation are inseparable and include whatever type of formatting
>> up to and including graphics, links to first source references, test
>> data, etc., etc., etc., ... It would be the job of the
>> editor/compiler to "handle it".
>
> I've seen attempts to do that. And the clever people that
> initially promote it make it look very nice. Then, average
> programmers start using it and the result is illegible. The
> documentation doesn't actually describe the code and the
> code is difficult to find buried among all the documentation.
>
> A language design is not judged by how well experts manage
> to make it look, but by how well average programmers do when
> using it day to day.
Agreed as noted in response to Gary I used "compiler" where should have
used "IDE" or similar. I don't believe the language itself should be
burdened w/ such but it would seem more productive for OP to concentrate
on something other than his language fixes to make any progress so I was
trying to give another alternative for consideration... :)
--
anal...@hotmail.com
OK - now I see the difficulties faced by the committee :-)
Agreed to features:
(0) It is agreed that Linf will have statements of arbitrary length.
The decision as to statement teminators/separators and how comments
would be placed in code is deferred.
Current item under discussion:
The linf character set:
A-Z
a-z
0,1,2,3,4,5,6,7,8,9
+,-,/,*
[],{},(),<,>,',",<space>,<comma>
The above seem non-controversial:
each uppercase letter is synonymous with its lower-case counterpart
except within string literals.
[], {}, () are synonymous with one another.
^ or ** for exponentiation?
what subset of [ ~,!,@,#,$,%,&,_,|,;,:,? ] belong?
how about the null character?
Should the language allow str = ''? and also things like "thorn" þ
within strings or char variables?
Gordon Sande
> Gordon Sande wrote:
> ...
>> for i := 0 step 1 to 9, 10 step 10 to 90, 91 step 1 to 100 do
>> begin
>> ...
>> end
>
> The original of this preceeded Fortran (and was less wordy).
> From memory, it was something like:
>
> do i = 0 (1) 10 (10) 90 (1) 100
When I first saw this it was called table maker's notation, but
without the "do i =".
Nobody ever accused Algol 60 of be overly terse. But it made for good
literature.
LR
There is an example here
http://www1.cs.columbia.edu/~sedwards/classes/2003/w4115/syntax.9up.pdf
>
> On the other hand, I don't want to make a fetish of uniformity/
> regularity (the undoing of F). I totally concur with James Giles'
> suggestion that [], {} and () should mean the same thing and there
> should be no differentiation of upper and lower case, although both
> should be present in the language.
I think you may find these useful,
http://www.amazon.com/gp/product/0321486811/
http://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools
http://www.holub.com/software/compiler.design.in.c.html
There are plenty of others.
>
> To get back to CR/LF -
>
> "lines" would have no meaning to the compiler - thats for the monitor/
> printer to worry about. In my current ";" language, I thrown in
> "enter" around 70-80 characters so that I can edit code with a 80
> column widow.
>
> The compiler is only looking for program statements and commment
> statements either of which which may be part of a line or span many
> lines.
Are you familiar with C's continuation character?
Are you going to have any sort of preprocessor? C++ style templates? At
least support for includes? Will this be similar to C's? PL/I's?
Something else?
>>> Of course the ";' will be forgotten from time to time leading to
>>> unexpected behavior ...
>> Which is the primary strike against it (and it's just simply ugly,
>> besides :) ) unless there is some overarching reason it is required and
>> as noted above that reason more than makes up for the losses owing to
>> the problems introduced (which, so far, you've shown no reason for it to
>> do so).
http://en.wikipedia.org/wiki/PL/I
IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF;
> As a preview to what lies ahead, I am thinking of eliminating gotos
> and statement numbers. Thoughts?
What will your I/O look like?
I've always liked this quote attributed to Bjarne Stroustrup, "There are
two kinds of languages: The ones everybody bicker about, and the ones
nobody uses."
LR
glen herrmannsfeldt
(snip)
> Jovial also uses it...still a lot written in Jovial...
When I was first getting interested in computers, I used
to look for books at library used book sales.
I believe I had one about Jovial, but never knew anyone
else using it, or a system with a compiler.
Now it isn't hard to find useful used computer books,
but 30 years ago it was much harder.
Which systems have Jovial compilers?
-- glen
glen herrmannsfeldt
(snip)
> But you're adding 100's of times more unnecessary statement terminators
> to replace the fairly rare continuation character. I don't think that's
> a fair trade.
You hope they are rare. If you have very long identifiers and
slightly complex statements it is easy to run only multiple lines.
-- glen
Gordon Sande
A purely functional language without "="?
> The above seem non-controversial:
Or is it just a typo?
anal...@hotmail.com
what do you think :-) ?
Will fix it along with changes proposed by responders.
>
>
> > each uppercase letter is synonymous with its lower-case counterpart
> > except within string literals.
>
> > [], {}, () are synonymous with one another.
>
> > ^ or ** for exponentiation?
>
> > what subset of [ ~,!,@,#,$,%,&,_,|,;,:,? ] belong?
>
> > how about the null character?
>
> > Should the language allow str = ''? and also things like "thorn" þ
> > within strings or char variables?- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
James Giles
...
> The linf character set:
>
> A-Z
> a-z
> 0,1,2,3,4,5,6,7,8,9
> +,-,/,*
> [],{},(),<,>,',",<space>,<comma>
>
> The above seem non-controversial:
>
> each uppercase letter is synonymous with its lower-case counterpart
> except within string literals.
>
> [], {}, () are synonymous with one another.
>
> ^ or ** for exponentiation?
>
> what subset of [ ~,!,@,#,$,%,&,_,|,;,:,? ] belong?
>
> how about the null character?
>
> within strings or char variables?
If your language is successful, it will probably be implemented
on a variety of platforms. Whatever the native character set on
each platform, all the printable (visible) characters of that set
should be permitted in string literals. No non-printable character
(except space - if you regard it as non-printable) should be
permitted in literals (which should have the same meaning
as their appearance).
I hesitate to mention that maybe tab should be allowed in normal
source (outside of literals), with the same meaning as a space.
In comments, so character has any significance, so any printable
character, space, and maybe tab should be permitted.
Of course, there's no point to other non-printable characters being
permitted anywhere - they can't possibly *clearly* show anything.
As for using the other special characters [ ~,!,@,#,$,%,&,_,|,;,:,? ]
in source, that depends on what you use them for. You have an
incomprehensible aversion to them. But they can be useful.
James Giles
...
> In comments, so character has any significance, so any printable
Sorry, "In comments, *no* character has any significance".
James Giles
>> do i = 0 (1) 10 (10) 90 (1) 100
>
> When I first saw this it was called table maker's notation, but
> without the "do i =".
Interesting. So it may predate computing entirely.
LR
> On Jun 7, 2:23 pm, "James Giles" <jamesgi...@worldnet.att.net> wrote:
>> analys...@hotmail.com wrote:
> OK - now I see the difficulties faced by the committee :-)
>
> Agreed to features:
>
> (0) It is agreed that Linf will have statements of arbitrary length.
>
> The decision as to statement teminators/separators and how comments
> would be placed in code is deferred.
>
> Current item under discussion:
>
> The linf character set:
>
> A-Z
> a-z
> 0,1,2,3,4,5,6,7,8,9
> +,-,/,*
> [],{},(),<,>,',",<space>,<comma>
I don't see =
>
> The above seem non-controversial:
>
> each uppercase letter is synonymous with its lower-case counterpart
> except within string literals.
>
> [], {}, () are synonymous with one another.
So someone could write
subroutine x(a);
or
subroutine x[a];
or
subroutine x{a};
what about
subroutine x[a};
Even if you just allow the first three I think it'll make for some
complication for whomever is writing tools for code in this language.
> ^ or ** for exponentiation?
>
> what subset of [ ~,!,@,#,$,%,&,_,|,;,:,? ] belong?
>
> how about the null character?
>
> Should the language allow str = ''?
That depends. What do think str=''; should do?
> and also things like "thorn" ş
I yink we should follow ye new style of using y as a glyph to represent
yorn.
For another important consideration see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2601.html
> within strings or char variables?
Are you going to distinguish between strings and char variables? Are
you going to have other types for wide chars and wide strings?
I'm curious to know, since the = came up, and since you mentioned that
you prefer <= to .le., if you're going to have separate operators for
assignment and equal comparison, similar to what C does = and ==
respectively or := and = like some other language I recall seeing, or
use = for both.
IE would you prefer something like
logical x = true;
logical y = false;
and then
logical z = x == y;
or
logical z = x = y;
what about
z = x == y;
or
z = x = y;
LR
dpb
> Gordon Sande wrote:
>> On 2008-06-07 16:10:47 -0300, "James Giles"
>> <james...@worldnet.att.net> said:
> ...
>>> do i = 0 (1) 10 (10) 90 (1) 100
>> When I first saw this it was called table maker's notation, but
>> without the "do i =".
>
> Interesting. So it may predate computing entirely.
No, simply from a time when "computing" was still a profession rather
than a machine...
:)
--
Gary Scott
I use keyboards that don't have a ^ character, so I vote for something
more common. I've never liked double characters having unique meaning,
but I'm used to it by now so I don't oppose **.
>
> what subset of [ ~,!,@,#,$,%,&,_,|,;,:,? ] belong?
>
> how about the null character?
I don't object to restricting the character set for source form beyond
Fortran, so long as the language provides me the flexibility to
manipulate internal representations (achar, iachar, ichar, etc) for
"system programming" purposes and supports stream I/O of byte streams or
whatever the smallest addressable unit is for the system. I want to
strive for portability, but most of my programming needs involve some
low-level processing that must be supported by any language I use for
other than a very domain-specific purpose (which usually limits the
market share potential) (domain-specific example: a language designed
specifically to model navigation solutions, or weapon trajectories, or
CEPs, or an autotest language)
>
> Should the language allow str = ''? and also things like "thorn" ş
> within strings or char variables?
>
>
>
>
James Giles
...
> I'm curious to know, since the = came up, and since you mentioned that
I think he may have preferred the other way around (I know people
that do).
> [...] if you're going to have separate operators for
> assignment and equal comparison, similar to what C does = and ==
That's already the Fortran rule, with the addition that = is never
permitted in any context that == is permitted and vice-versa.
James Giles
Well, the purpose of allowing unlimited length lines, statements,
continuaton sequences, or identifiers is not to encourage excesses
in those lengths. The purpose is that, past a certain point, such
limits are completely arbitrary. I almost never have any identifiers
more than about 16 characters long (and most are a lot shorter),
but I don't what to have to count characters as I compose my
code on those rare occasions I have longer names. Similarly
for line lengths, statement lengths, etc.
People get excessive on these things to their own detriment.
The only things that may *need* long names, for example,
are those things that occupy the one and only global namespace.
Local names and names of things within modules can be
shorter, since they don't need to be disambiguated from
huge numbers of other symbols (their locality serves the
purpose).
Gordon Sande
> Gordon Sande wrote:
>> On 2008-06-07 16:10:47 -0300, "James Giles"
>> <james...@worldnet.att.net> said:
> ...
>>> do i = 0 (1) 10 (10) 90 (1) 100
>>
>> When I first saw this it was called table maker's notation, but
>> without the "do i =".
>
> Interesting. So it may predate computing entirely.
Depends on how you define computing. Is making tables computing?
I presume there is an electronic or automated or some similar adjective
missing somewhere.
Computor used to commonly mean someone who used a calculator.
Gary Scott
I'm sure there are others, but ours are (yes they're still in use)
Targets: 1750A, 8000, 8002
Hosts: VAX/VMS, Solaris
"aerospace" systems have to last a long time
Of course they are slowly being migrated over time.
Gary Scott
Of course it is possible to make nearly every statement a continuation
line, but in most source code that I've seen, continuations are a small
percentage of the LOC.
Gordon Sande
I have used a simulation language where ( were { treated alike, also ) and }
but were required to separately balance. Lower rate of badly formed
complicated expressions was the impression. [ and ] were used to
denote subscripts. I still find it hard to look at { and } for functions.
James Van Buskirk
news:6gC2k.51969$SV4....@bgtnsc04-news.ops.worldnet.att.net...
> LR wrote:
>> I'm curious to know, since the = came up, and since you mentioned that
>> you prefer <= to .le., [...]
What happened to ACHAR(46)?
>> [...] if you're going to have separate operators for
>> assignment and equal comparison, similar to what C does = and ==
> That's already the Fortran rule, with the addition that = is never
> permitted in any context that == is permitted and vice-versa.
Are you saying that:
C:\gfortran\clf\equals_challenge>type equals_challenge.f90
program equals_challenge
character(10) string
logical back
logical test
interface operator(==)
function equals(a,b)
logical, intent(in) :: a, b
logical equals
end function equals
end interface operator(==)
test = .TRUE.
back = .FALSE.
string = 'ABCDEEDCBA'
write(*,*) index(string,'A',back=test)
write(*,*) index(string,'A',back==test)
end program equals_challenge
function equals(a,b)
logical, intent(in) :: a, b
logical equals
equals = a .eqv. b
end function equals
C:\gfortran\clf\equals_challenge>gfortran -std=f2003 -Wall -pedantic
equals_chal
lenge.f90 -oequals_challenge
C:\gfortran\clf\equals_challenge>equals_challenge
10
1
Is a bug in gfortran?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
James Giles
...
> I use keyboards that don't have a ^ character, so I vote for something
> more common. I've never liked double characters having unique
> meaning, but I'm used to it by now so I don't oppose **.
I don't oppose ** as an alias for ^, but ^ is just plain ascii. Ascii
is the base page for all (non-obsolescent) character sets. If you
can't handle it, where have you been in the last 20 years? ISO8859
is now itself so old that they've disbanded the committee, frozen
the standard, and recommended UNICODE as the next step.
> I don't object to restricting the character set for source form beyond
> Fortran, so long as the language provides me the flexibility to
> manipulate internal representations (achar, iachar, ichar, etc) for
Obviously.
> "system programming" purposes and supports stream I/O of byte streams
Well, Fortran's *unformatted* streams are usually octets (bytes) these
days (but could be some other unit). Fortran's *formatted* streams don't
do what you seem to expect (they still process and can alter record marks).
--
By the way, for several of us in this thread, could we adopt the
common net etiquette of removing the parts of preceding articles
that aren't being responded to? Wading through whole exchanges
for a few embedded lines of response is not good eats.
James Giles
> "James Giles" <james...@worldnet.att.net> wrote in message
> news:6gC2k.51969$SV4....@bgtnsc04-news.ops.worldnet.att.net...
>> That's already the Fortran rule, with the addition that = is never
>> permitted in any context that == is permitted and vice-versa.
> write(*,*) index(string,'A',back=test)
> write(*,*) index(string,'A',back==test)
> Is a bug in gfortran?
Yikes! OK, it's Fortran. I've always considered it a mistake in the
design. Argument designators (which Fortran calls "keywords"
for reasons that were never really clear) should not have been
applied with assignment-like syntax. This is the forst time I've
seen the reason for opposing that syntax so clearly exhibited.
Terence
> On Jun 4, 3:09 pm, analys...@hotmail.com wrote:
ETC
> Good luck, you will need it. I suggest that your language be
> translatable to Fortran 95, Fortran 77, or C, or otherwise you will
> need to write a compiler, which is difficult.
Sorry, I don't have time to read though all the contributions.
I was busy on something else while all this happened.
My points, which may have been duplicated elsewhere.
1) I hope bit-wise boolean logic will be included as integer-encased
bit strings.
2) I write table-driven programs each as a form of a compiler, where
the language module is exterior to the program ans so the user defines
his own keywords and messages (and language and language symbols).
I use F77 to write these programs/compilers/result-executors. So my
humble advice is "make the new language translatable to F77". It's a
far simpler language but evry bit as poweful as "the later stuff", and
easier, global and compact, and everybody can lay his/her hands on an
F77 compiler for zero to peanuts. And being Fortran, for onverting a
Fortran-like new language, it should be very easy to do.
James Van Buskirk
> James Van Buskirk wrote:
>> write(*,*) index(string,'A',back=test)
>> write(*,*) index(string,'A',back==test)
> Yikes!
}:->
But I felt bad about having to overload operator(==), so I offer
another example:
C:\gfortran\clf\equals_challenge>type equals_challenge2.f90
program equals_challenge2
character(10) string
integer, parameter :: test = selected_int_kind(9)
integer kind
integer x(3,3)
integer dim
integer one
kind = test
string = 'ABCDEEDCBA'
write(*,*) index(string,'A',kind=test)
write(*,*) index(string,'A',kind==test)
x = reshape( &
[1,2,3, &
4,5,6, &
7,8,9], &
shape = shape(x), order = [2,1])
dim = 1
one = 1
write(*,*) maxloc(x,dim=one)
write(*,*) maxloc(x,dim==one)
end program equals_challenge2
C:\gfortran\clf\equals_challenge>gfortran -std=f2003 -Wall -Wsurprising -pedanti
c equals_challenge2.f90 -oequals_challenge2
C:\gfortran\clf\equals_challenge>equals_challenge2
10
10
3 3 3
3 3
The first line of output is in fact a bug in gfortran.
C:\gfortran\clf\equals_challenge>gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../gcc/configure -q --prefix=/var/tmp/w64 --with-sysroot=/var/t
mp/w64 --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --silent
Thread model: win32
gcc version 4.4.0 20080528 (experimental) (GCC)
glen herrmannsfeldt
(snip)
> Well, the purpose of allowing unlimited length lines, statements,
> continuaton sequences, or identifiers is not to encourage excesses
> in those lengths. The purpose is that, past a certain point, such
> limits are completely arbitrary. I almost never have any identifiers
> more than about 16 characters long (and most are a lot shorter),
> but I don't what to have to count characters as I compose my
> code on those rare occasions I have longer names. Similarly
> for line lengths, statement lengths, etc.
The ALGOL-W compiler (written by Wirth in the 1960's) allowed
(past tense, no copies are known to exist) 255 character
long identifiers. That is with card (LRECL=80) input so it
takes up to five cards each.
> People get excessive on these things to their own detriment.
> The only things that may *need* long names, for example,
> are those things that occupy the one and only global namespace.
> Local names and names of things within modules can be
> shorter, since they don't need to be disambiguated from
> huge numbers of other symbols (their locality serves the
> purpose).
Allowing long identifies is convenient when doing
automated translation from another language with long
identifiers.
-- glen
James Giles
> James Giles wrote:
...
>> People get excessive on these things to their own detriment.
> Allowing long identifies is convenient when doing
> automated translation from another language with long
> identifiers.
Then the program was already problematical before translation.
In any case, as I said, I favor having no limit to the length of an
identifier. I just think people should develop a style where
very long names are rare.
ttw...@att.net
There are generally more statements in a program than continuations.
Thus the continuation should be marked rather than the statement. I
don't like having to end a statement with a ;. I would prefer not
allowing more than one statement on a line than to have a
continuation. It's much easier to read. So I would prefer the "current
text processor's end of line" to terminate a statement.
Null statements have no effects.
For comments, I would simply pick a comment character, for example !.
Should the first non-blank (or non-tab should tabs be deemed
equivalent to blanks) be a !, the line is a comment. (Or one could
simply define ! to end-of-line to be a comment as Fortran does.)
I also currently far prefer the dot-deliminated operators for the
relations and logic to the jumble of special characters that also are
used. As having significant blanks are a useful featuer, the relations
could be just blank deliminated. Things like a le b cannot be anything
except a relational espression. I wouldn't try to put a hierarchy on
these; you are providing more bracketing notation anyway. Some people
I've discussed this with would also like to include angle brackets
giving 4 sets, (), [], {}, <>. At least no one has suggested French
quotes (which I would approve for general English usage.)
Gary Scott
"angle brackets" aren't brackets in my opinion, they are greater than
and less than symbols. Where did this crazy idea to use them as
brackets come from? And wouldn't that make parsing complicated for
statements that had <> comparisons?
James Giles
> ttw...@att.net wrote:
>> [...] Some people I've discussed this with would also like to
>> include angle brackets giving 4 sets, (), [], {}, <>. At least no
>> one has suggested French quotes (which I would approve for general
>> English usage.)
> "angle brackets" aren't brackets in my opinion, they are greater than
> and less than symbols. Where did this crazy idea to use them as
> brackets come from? And wouldn't that make parsing complicated for
> statements that had <> comparisons?
There are such things as angle breckets, but they appear visually
different from the less-than/greater-than symbols. I would not
recommend any language use the ASCII symbols for both purposes.
And, in any case, if I wanted angle brackets, I would want real
ones (ie. symbols that display as tall or taller than upper case
letters and touch - or even extend below - the baseline). The
UNICODE character set contains such things. I wish all my
fonts supported them.
I like French quotes as well. It means that I (as an English
speaking programmer) can make character literals without
the need for doubling-up on the other quote marks, or using
some other escape mechanism. Vis:
aString = «"That's all Folks!"»
Gordon Sande
> Gary Scott wrote:
>> ttw...@att.net wrote:
>>> [...] Some people I've discussed this with would also like to
>>> include angle brackets giving 4 sets, (), [], {}, <>. At least no
>>> one has suggested French quotes (which I would approve for general
>>> English usage.)
>> "angle brackets" aren't brackets in my opinion, they are greater than
>> and less than symbols. Where did this crazy idea to use them as
>> brackets come from? And wouldn't that make parsing complicated for
>> statements that had <> comparisons?
>
> There are such things as angle breckets, but they appear visually
> different from the less-than/greater-than symbols. I would not
> recommend any language use the ASCII symbols for both purposes.
> And, in any case, if I wanted angle brackets, I would want real
> ones (ie. symbols that display as tall or taller than upper case
> letters and touch - or even extend below - the baseline). The
> UNICODE character set contains such things. I wish all my
> fonts supported them.
>
> I like French quotes as well. It means that I (as an English
> speaking programmer) can make character literals without
> the need for doubling-up on the other quote marks, or using
> some other escape mechanism. Vis:
>
> aString = «"That's all Folks!"»
I have found that strings generate two types of problems. One is the
doubling up issue for embedding the string quote. The other is
continuation of a string. I would appear that both can be addressed
by a variant on the common rules. Adjacent literal strings should be
concatenated to form a single longer string. This does continuation
as the two parts would be on different lines but syntacticly adjacent
by whatever the continuation rule is. Doubling up is avoided by use
of the other string quotes as it is assumed there are two forms of
string quotes. This is much the same as requiring a concatenation
operator but automatic joining of literal strings feels more like
Fortran with the notion that simple things should be seen to be done
efficiently. Explict concatenation to deal with doubling up seems
overly fussy.
REXX uses a rule of adjacent strings (not just literal ones) are
concatenated with an blank in the middle. To avoid the blank an
explicit concatenation operator is required. This is good human
engineering of a scripting language as I observe that I have not
gotten the blank included upon occasion when manipulating text.