From: James Giles on
John Harper wrote:
> In article
> <Gr3Sf.567858$qk4.49132(a)>, James
> Giles <jamesgiles(a)> wrote:
>> Defined operators I also support
>> but with even stronger misgivings. I don't think anything
>> would convince me that allowing users to define the precedence
>> of their defined operators was a good idea.
> Having had that in Algol 68, and wanting to do 3-D vector analysis
> in Fortran in which .DOT. and .CROSS. would have to be defined ops
> with the same precedence as * (the usual maths convention), I
> disagree.

As much as it wouldbe convenient to have that, if I'm using
your code, how do I know you've done it? If precedence
is definable, there is nothing about the appearance of the
operator to tell me what precedence it has. At present, in
Fortran, I *can* tell exactly what precedence all operators
have just by inspection of the operators - I never have to
look at any declarations. Never mind that definable
precedence is *much* harder to implement, it's also much
harder to document and read for us ordinary humans.

Now, I've suggested this before, but what about allowing
users to define meanings for presently unassigned operator
symbols that have predefined precedences? There aren't
many if we stick to ASCII, but there are some. The two
character operator */ has no meaning in Fortran, could be
given the same precendence as *, and could be defined
with the meaning "cross product". Similarly, /* could be
given a meaning. Etc. Now, instead of these combinations,
I'd prefer to allow latin-1 characters. That has such symbols
as centered dot (?), cross product (?), conventional divide (?),
and a few others whose precedence could be defined by the
language and whose meaning could be defined by the user.

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

From: Gordon Sande on
On 2006-03-15 20:12:53 -0400, "James Giles" <jamesgiles(a)> said:

> Walt Brainerd wrote:
>> James Giles wrote:
> ...
>>> You are using *all* those operators and assignments
>>> in each local context? You must have some very busy
>>> code.
>> The particular example is using a module that defines
>> a big integer data type.
>> I have a hard time imagining many lines of code that
>> do integer arithmetic that don't use add, subtract,
>> multiply, divide, sqrt, assignment, compare (there's
>> six right there) operations, but maybe your imagination
>> is better than mine.
> Well, I guess so. Most uses of big-integers are for an
> expression or two, maybe a few lines even, to accomplish
> things beyond the ability of the intrinsic INTEGER (or
> even REAL) type(s). This small amount of code may
> actually use only, say, add, divide, and assignment (to
> compute the average of a large array of integers without
> the risk of overflow, and without losing precision like
> you would if you use REAL intermediates).

I have seen a couple serious applications of rather long
integers. In each case the operations were quite serious
mathematics and involved nontrivial programs.

There are several packages of nontrivial operations
research or combinatorics that are exact as they use
a high precision integer package.

My experience must be limited as I have never seen a case
where the intent was to have a bit more precision for a
while. I have seen some things that are sort of like
that for reals but never for integers.

From: Dave Thompson on
On Wed, 08 Mar 2006 15:37:28 GMT, Dan Nagle <dannagle(a)>

> Hello,
> Pierre Asselin wrote:
> <snip a bunch>
> > Playing Devil's Advocate, in C the tradition is to #include all headers
> > at file scope and to #include needed headers from headers. Transliterated

And specifically to #include all headers _at the top_ of the source
file -- certainly before any code, and usually before any (file-scope)
variables or types.

The second is not universal however. I have seen projects where you
must (and it is documented you must) #include "lowerlevel.h" before
you #include "mediumlevel_uses_lower.h". (The actual names aren't that
explanatory, of course. <G>) Although I would say in recent years the
trend is toward "medium.h takes care of it for you".

> > to Fortran, that would mean USE at module scope (contrary to what I said)
> > and single-module wrappers (as I said).
> Playing Devil's Advocate further, an unqualified private statement
> in each module to prevent "leak-through" of names could be considered
> the equivalent of the ubiquitous C construct
> #ifndef FUBAR_H
> #define FUBAR_H
> /* stuff from fubar.h */
> #endif

No. This (only) protects against (arguably spurious) errors caused by
nominal duplication(s) if you #include the same header twice -- which
you don't normally do explicitly, but as above get if you #include
"lower.h" and also #include "medium.h" which includes lower.h.
Everything declared in fubar.h is still visible and in the namespace.

You may thinking of things like
/*--- unistd.h or similar ---*/
.... here features in the "basic" API ...
.... here features applicable only to level 2 ...

or things like
/*--- myproj.h ---*/
extern myfunc (blah blah blah) ;
extern struct { int a; float b; char * c; } mydata
= { 42, 3.1416, "whoa nelly" }

- David.Thompson1 at