Re: The linf project (2)

analyst41@xxxxxxxxxxx wrote:
....
OK let us tackle declarations next.

Does '*' belong at all - such as Real*8, Logical*1 etc.?

No. For one thing I see no reason to have more than one
LOGICAL type. And the numbers don't correspond to
anything portable anyway. Are they considered part of the
type name (in which case, why not REAL_8?) or are they
some KIND-like type parameter? By the way, instead of
REAL_8, I'd prefer DOUBLE anyway. But, it's your language.

Should regularity be imposed or only to be preferred in declarations?

In other words

if someone wants to do

character a, logical*8 b
dimension a(100),b(200)

I would certainly not permit someone to declare attributes
of a symbol anywhere other that its type declaration. I don't
want to have to look in more than one place for information
about a single symbol. But, it's your language.

how about "initializing declarations" such as

integer a,b,c/2,3,5/ (a,b,c being scalars)?

I think named constants must be initialized. I think that
SAVEd variables ought to be allowed initialization (and
all module variables should be SAVEd automatically with
no way to turn off that property, and no other variables
should be allowed to be SAVEd - hence no need for the
SAVE keyword). I don't think anything else should be
allowed to be initialized.

Using slash for initialization is peculiar, but familiarity
has maybe made it acceptable. I don't want initialization
to look like assignment. But, it's your language.

Why did :: come into f90 declarations - was it required for backward
compatibility with f77 while being able to hadling things like
allocatables and structures?

'::' looks awakward to me.

But, nearly all punctuation that improves clarity looks awkward
to you. The double colon was actually needed to distinguish
declarations from assignment statements:

real x = 5.0 ! in fixed source, is it a decl, or an assign?

I like it because (without attribute statements) it allows one
to dispense with the TYPE keyword in variable declarations:

type(my_stuff) var ! the Fortran style

I would vastly prefer:

my_stuff :: var

But, it's your language.

We have several logicals, several integers, several floats and char as
the data-primitives.

Why do you have several LOGICALs?

We need to be able to declare

Scalars, arrays and strings of any one of these primitives either as
variables or parameters.

Yeah. And since you don't like attributes on the same
line as type declarations, that could be a problem for
you. I'd like to see how you handle it. After all,
it's your language.

We also need to be able to declare arrays of strings.

Is there a schema to uniformly handle all possibilities ?

Well, there is, but you don't like user defined types.

....
[... you don't like derived types ...]

I was planning on springing it later - but how about exactly one more
structure besides arrays - TABLES ?

How does it differ from derived types? Can it be an
attribute that's orthogonal to base type? Or does it better
fit as a way of defining new base types?

--

And I really do wish you would cut the parts of articles
that you aren't responding to.

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


.

Relevant Pages

  • Re: "no variable or argument declarations are necessary."
    ... >>>Declarations also allow easier writable closures. ... >>>scope when a variable is rebound. ... > functionnal language I know but one do need variable declaration: ...
    (comp.lang.python)
  • Re: "no variable or argument declarations are necessary."
    ... >> Declarations also allow easier writable closures. ... Python would be a whole different language ... But AFAIK they don't work like python which makes any variable ... For whether or not a feature should be ...
    (comp.lang.python)
  • Re: Halt execution procedure
    ... by expressions that are not initialization expressions. ... Many of the reasons for this are historical. ... But the language isn't designed from scratch and it ... it doesn't matter what you think. ...
    (comp.lang.fortran)
  • Re: Check POP3 E-mail
    ... you're saying that the perl interpretter doesn't just skip the ... languages which did require explicit initialization, ... Granted, wise perl programmers like ... > across from one language to another. ...
    (comp.lang.perl.misc)
  • Re: Declarative constraints in practical terms
    ... of conjunction and disjunction and be sound w.r.t. ... how an imperative language would not meet this requirement? ... mathematics, then it's declarative. ...
    (comp.databases.theory)