The linf project
  Home FAQ Contact Sign in
comp.lang.fortran only
 
Advanced search
POPULAR GROUPS

more...

comp.lang.fortran Profile…
 Up
The linf project         


Author: analyst41
Date: Jun 4, 2008 12:09

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!

[Amen.]
Show full article (6.14Kb)
47 Comments
Re: The linf project         


Author: Beliavsky
Date: Jun 4, 2008 14:14

On Jun 4, 3:09 pm, analys...@hotmail.com wrote:
> 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...
Show full article (1.37Kb)
no comments
Re: The linf project         


Author: analyst41
Date: Jun 4, 2008 18:28

On Jun 4, 7:49 pm, "James Giles" worldnet.att.net> wrote:
> analys...@hotmail.com wrote:
>> 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? ]
>
> Well, you didn't answer the question about keywords.  I would
> 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 ...
Show full article (11.69Kb)
no comments
Re: The linf project         


Author: James Giles
Date: Jun 4, 2008 19:21

analyst41@hotmail.com wrote:
...
> 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:
Show full article (2.41Kb)
no comments
Re: The linf project         


Author: glen herrmannsfeldt
Date: Jun 4, 2008 21:49

analyst41@hotmail.com wrote:
(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
no comments
Re: The linf project         


Author: James Giles
Date: Jun 4, 2008 21:17

glen herrmannsfeldt wrote:
> analyst41@hotmail.com wrote:
> (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;
Show full article (1.40Kb)
no comments
Re: The linf project         


Author: Ron Ford
Date: Jun 4, 2008 22:08

On Wed, 04 Jun 2008 23:49:43 GMT, James Giles wrote:
> 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."
Show full article (1.39Kb)
no comments
Re: The linf project         


Author: nospam
Date: Jun 4, 2008 22:59

Ron Ford nowhere.net> wrote:
ether."
>
> It used to be that there were plenty of Catholics who could help with
> Latin...

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
no comments
Re: The linf project         


Author: glen herrmannsfeldt
Date: Jun 5, 2008 00:00

James Giles wrote:
(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.
Show full article (1.59Kb)
no comments
Re: The linf project         


Author: David Simpson
Date: Jun 5, 2008 04:34

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).
no comments

RELATED THREADS
SubjectArticles qty Group
US-NJ: Lindenwold-Architectural Project Architect/Project Manager...alt.jobs ·
1 2 3 4 5