Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Fortran2000

1 view

Skip to first unread message

Phillip Helbig

unread,

Mar 2, 1997, 3:00:00 AM3/2/97

| From: SMTP%"Miles...@etrc.ox.ac.uk" 1-MAR-1997 17:39:51.68
| To: sc22 <sc...@dkuug.dk>
| CC:
| Subj: The final content of Fortran 2000 is determined!

I would appreciate it if someone knowledgeable could write one or two
sentences about each of the (possible) new F2000 features, perhaps
indicating if (s)he is in favour of or opposed to it and why.

| It is the intention of WG5 that the revised standard shall be published no
| later than November 2002. (Whether it will be known as Fortran 2000,
| Fortran 2002, or something else has yet to be agreed!)

It should definitely be known as Fortran2000, since the lag of two years
is about what we had with F77 and F90. One should keep to the `new
standard every fve years, major revision every ten years' policy as
strictly as possible, so that there is a predictability and no fear of
the languge stagnating, as happened with F77.

| WG5 has also authorised X3J3 to work on a number of other relatively minor
| technical enhancements for incorporation in Fortran 2000

What about similar comments on these?

| However, WG5 has determined that nothing that is not on the above list of
| new features, or on the following list of minor technical enhancements,
| will appear in Fortran 2000.

This means anything not on the above lists will have to wait for F2005.

| Anyone with a particular interest in any of these minor enhancements,
| however, should contact the Chair of X3J3, Jerry Wagener
| <jwag...@ionet.net> as only by joining X3J3 and volunteering to work on
| the relevant item(s) will it be possible to influence their possible
| inclusion in Fortran 2000.
|
| Any other queries about Fortran 2000 should be directed to either your
| national Fortran standards committee, or to the Convenor of the ISO Fortran
| Working Group, whose personal details appear at the end of this
| announcement:

If I have a suggestion which is reasonably well though-out and
described, what's the best way to push for its inclusion in F2005?
There must be something more effective (well, maybe not) than posting to
the comp-fortran-90 mailing list or the comp.lang.fortran newsgroup.

--
Phillip Helbig Email ........... p.he...@jb.man.ac.uk
Nuffield Radio Astronomy Laboratories Tel. ...... +44 1477 571 321 (ext. 297)
Jodrell Bank Fax .................. +44 1477 571 618
Macclesfield Telex .................. 36149 JODREL G
UK-Cheshire SK11 9DL Web ..... http://www.jb.man.ac.uk/~pjh/

My opinions are not necessarily those of NRAL or the University of Manchester.
Email will COME from Hamburg for a while longer; send/reply TO either address.

Keith Bierman QED

unread,

Mar 2, 1997, 3:00:00 AM3/2/97

st2...@hsvax1.HS.UNI-HAMBURG.DE (Phillip Helbig) writes:

> I would appreciate it if someone knowledgeable could write one or two
> sentences about each of the (possible) new F2000 features, perhaps
> indicating if (s)he is in favour of or opposed to it and why.

Of course, the chances of everyone on the committee(s) agreeing either
with the summary or the merit may be small ;>

> | Asynchronous I/O (see N1189 item #52)

CPU's get faster, memories do but a lot slower, and mass storage very
slowly improves. So being able to overlap I/O with computation is
important (has been important) and will become more important to high
performance computing. <I, of course, favor this>

> | *Floating point exception handling (see N1231)

A "simple" binding to IEEE floating point facilities. Expose the
"flags" and allow for setting, getting, testing, etc. <I, of course,
favor this>

> | Interval arithmetic (see N1189 item #62)

One of the most expensive things for a commercial software shop (and
many internal software efforts) doing extensive floating point
arithmetic is quality assurance. That is, given three different
processors (perhaps same or different hardware, same or different
compilers, and same or different compiler options (or OS releases) or
whatever) one usually obtains three different answers. Are all three
right, wrong, two out of three, etc. Interval arithmetic allows one to
determine if they are consistent, and if consistent which is of higher
quality.

It is a powerful, albeit expensive tool, requiring work on the part of
the application developer, the compiler writer, and the runtime
system.

While there are 30 years or so of good literature, viable commercial
systems (with all due respect to the Acrith developers) have not yet
made it to market. There are those who feel that the technology is
finally ready, and that one of the best things that can be done for
Fortran is to make it uniquely good for numerical computing. So while
it is a gamble (and doing New work in a Standards body), it has been
argued that it is a uniquely appropriate gamble.

Of course, there is always the "starting problem". If there aren't
users, vendors tend to be uninterested. Users tend to be uninterested
if it isn't available in a consistent fashion. For interval
arithmetic, there are additional considerations such as are the
results meaningful (one could always return +-inf and be "correct" but
unhelpful) and are they fast enough. Sun has been working hard on
making this a reality (that is, it is more than my pet hobby horse).

> | *Allocatable components (see N1230)

Arguably "cleanup", if you can create user thingos, why can't you
create allocatable user thingos? While I agree it's a nice thing to
have, I'm somewhat agnostic on the question of whether it ranks among
the most important things we could add to the language.

> | Derived type I/O (see N1189 item #17)

It is fairly useless to add new datatypes and to not have any way to
get the data into and out of the processor. So this is high on my
personal list of things we left out.

> | Object-oriented Fortran:

I personally believe that OOF is either too late or too early. It's
too late to establish what OO technology should look, feel and "taste"
like. However, it is too early to pick the winner. Just as
interoperability with C is a major issue today (and Pascal isn't), I
believe that Fortran and *something* will have the same issue in
2003. However, I no longer think it is a safe bet that it will be
smalltalk vs. C++ vs+ objective C vs. Java. Efforts to combine very
different object models (e.g. CORBA) have borne fairly unpleasant
fruit. So my overall position is that f2K is not the right release of
Fortran to put such features into. Of course, I lost.

> | Constructors/destructors (see N1189 item #89)

When an object comes into "existence" what is it's value? Constructors
allow for it to be user defined. Destructors ensure that when
something ought to go away (release memory, etc.) that a programmer
can arrange the right thing. This paired functionality is important
for *safe* programming (as well as making life easier for the consumer
of a derived type). However, experience in other language systems
suggests that it creates a lot of new performance difficulties
(whether it is "intrinsic" to the feature, or merely to human nature
... I don't know. In the end I think it doesn't matter. It has proved
to result in extra performance analysis headaches). While I'm against
doing "OOF" at this juncture, constructors and destructors do more
good than harm. So if we are to do anything, we should do them.

> | Inheritance (see N1189 item #88 and N1272)

Part of what makes OO programming attractive is the promise that if
you have a nearly "right" object, you can "alter" it to suit your
local needs. Inheritance is a key component of being Object
Oriented. So while I'd rather wait, an OO language with inheritance is
a marketing ploy and not a real OO language.

> | Polymorphism (see N1189 item #88 and N1272)

I'll defer to someone else to cobble up a really good pithy way to
describe polymorphism. Otherwise, I suggest you go to the library;
there is a *lot* of literature on this topic.

> | Parameterized derived types (see N1189 item #14)

Just as there are REAL, KIND=1,4, 8, whatever, one may want to provide
different flavors of ones own derived types (e.g. Tensors in single
double and quad precisions). One could have this and not be "OOF" per
se. I think it's useful even in a non-OOF setting.

> | Procedure pointers (see N1189 item #43)

Being able to point at code, so you can switch implementations, etc. A
very powerful facility. Other languages have had it. May inhibit
optimization. I have mixed feelings about this myself.

> | Internationalization (see N1268 and N1273)

This is mostly viewed as a requirement by ISO. Certainly it is a
legitimate requirement for application developers, for codes which fit
"consumer" molds (e.g. word-processors that can't handle local
languages, aren't useful). It is less clear precisely what this ought
to mean to a language Standard. This is a "late breaking" requirement,
and the papers are still somewhat immature.

> | *Interoperability with C (see N1237)

Since most of the system services one might want have international
standards which are either defined in C terms, or at least have
established C bindings, the best single thing that one could do for
Fortran is to make all of that work accessible in a consistent
fashion. Of course, there are practical issues, and there will have to
be cooperation between C and Fortran processor providers (either via a
common ABI definition, or some other relationship). However, at least
making it *possible* for portable programs to be written would be a
large step forward. This is, IMNSHO, the single most important thing
that has to be done. And, to to it "right" we have to be prepared to
bind to *anything* that C developers come up with, because history
suggests that they use it all. The current TR effort falls short of
this. There is opposition to adding datatypes and making things too
"c-like" but one hopes that this will be fixed someday.

> It should definitely be known as Fortran2000, since the lag of two

Naming is one of those tricky topics that hardly anyone ever agrees
upon.

> standard every fve years, major revision every ten years' policy as
> strictly as possible, so that there is a predictability and no fear

It is unclear that given the current rules, and current staffing, that
work really can proceed upon that sort of plan. Nor is it obvious that
major revisions are acceptable. Major revisions tend to involve major
rewrites (either for vendors or users, possibly both).

The fundamental problem in 77-9x wasn't in that work wasn't done. But
that consensus wasn't achieved and delay was the outcome. If
predictability is the most important virtue, then the content of any
release must be flexible.

This particular area ("strategic plan") is likely to be a main topic
at Vienna at this summer's WG5 meeting. The old strategic plan has to
be revised in the light of our experience these last several years.

> What about similar comments on these?
>
> | Access to status error messages in text form

What does IOSTATE=88 mean? The processor knows. The documentation says
what it means. What text should be generated?

> | Allowing PUBLIC entities to have PRIVATE type

I defer to others.

> | Access to command line arguments and environment variables

The point of much other clf discussion.

> | Derived type encapsulation feature

I defer.

> | Enhanced complex constants

I'll let Loren answer this one; it's his baby.

> | Extending max/min intrinsics to character

While ditto, if ( IF a < b ) is defined, why isn't (max(a,b)) goes the
argument.

> | Extended initialization expressions

I defer.

> | Generic rate_count in system_clock

IBM PC's have an inconvenient real time clock rate. This is a proposal
to allow for fine tuning. One of the arguments against having
system_clock to begin with was that it would result in just such
additional complexity (and concomitment reduced portability).

> | IEEE I/O rounding inquiry intrinsics

Well, this is still somewhat misnamed. IEEE arithmetic has a small
variety of features not covered in the TR. Two notable areas are:
accuracy of base conversion and control of rounding during base
conversion. The former is needed to discover how bad read/writing is
on a given processor (it can be correct, nearly correct, correct as
per the standard, or really terrible) which might influence how one
treated one's results or the choice of formatted (and portable) or
unformatted (and non-portable) I/O in some particular application.

The control over rounding is useful in various contexts, the most
obvious being attempts to code interval arithmetic "by hand". However,
it is of use in other contexts.

The likely form of this is inquiry about accuracy, inquiry about
runtime rounding support, then getting, setting, clearing, rounding as
per the TR for arithmetic operations.

> | Increased statement length

In case one can't say all one wants with the number of characters and
continuation "cards" currently allowed.

> | Intent for pointer arguments

Possible optimization enhancement.

> | Mixed case syntax elements

Start using lower case in examples and such.

> | Named scratch files

When one establishes a scratch file, one may wish to place it
somewhere. Some systems allow scratch files to be named, and the name
may control where the result goes. In addition, in the case of process
failure, it may be useful for post-mortem dumps.

While Sun has long had this facility, I'm not particularly convinced
that it is worth the bother. The committee has already spent more time
on this topic than the feature is worth. Users can use named files and
close, status='delete', and do when they want portable results).

> | Stream I/O

access='binary'|'transparent' facilitates mixing languages, etc.

> | VOLATILE attribute

May be minimum needed to make MPI and other such things standard
compliant. The basic idea is that if you have some processing taking
place in the background, some optimizations need to be inhibited (such
as keeping values in registers). Also needed for writing device
drivers, some shared memory multi-processing and C interoperability.

> | Renaming defined operators

If a "market" in MODULES ever develops, it seems likely that vendors
will "collide". Allowing for renaming makes it possible for users to
mix different modules with more confidence. On the downside, it makes
writing confusing code somewhat easier.

> | Passing specific/generic names as arguments
> | PUBLIC and PRIVATE derived type components

> | Specifying pointer lower bounds

My writs grow numb, and I still have a paper to write. I defer to
others for definitions of these.

> This means anything not on the above lists will have to wait for
> F2005.

Or later.

> If I have a suggestion which is reasonably well though-out and
> described, what's the best way to push for its inclusion in F2005?
> There must be something more effective (well, maybe not) than posting to
> the comp-fortran-90 mailing list or the comp.lang.fortran newsgroup.

As the decision to place new features into the development list is
inherently an ISO decision, you'll have to lobby WG5 (and expect a
large uphill battle. There were *lots* of other good ideas, with years
of work behind them, that didn't make it. Resources are quite
finite). WG5 is an ISO group, so your country delegation has to take
up the cause. In the US, a large subset of X3J3 fills that role (there
are non-US based members, and they are certainly welcome. But they
can't form the US national position ;>). In the UK, it's BSI and it's
Fortran Specialists group. In Germany it's DIN, etc.

The requirements gathering process has been in place for years, if
there is any hope for a project to hit it's ship date, there must come
a time when new features are simply not allowed to be added. If we
follow the plan of work adopted by WG5, that time has come (and gone
as of the close of business of the LV meeting). There were many last
minute items considered (including an 80odd paper of Van Synders). I
hope that those who submitted such papers feel that their work was
given due consideration.

--
Keith H. Bierman keith....@Sun.COM| k...@chiba.Eng.Sun.COM
SunSoft Developer Products | k...@netcom.com
2550 Garcia UMPK16-304 415 786-9296 | (415 7869296) fax
Mountain View, CA 94043 <speaking for myself, not Sun*> Copyright 1997

Craig Burley

unread,

Mar 3, 1997, 3:00:00 AM3/3/97

In article <tazendx...@eng.sun.com> Keith Bierman QED <keith....@eng.sun.com> writes:

st2...@hsvax1.HS.UNI-HAMBURG.DE (Phillip Helbig) writes:

> | VOLATILE attribute

However, Fortran will become a worse language if the VOLATILE
attribute is added a la C.

I recommend that, in addition to specifying VOLATILE, _every_
reference to an entity with the VOLATILE attribute _must_ be done
via new language constructs like:

VOLATILE_WRITE (I) = VOLATILE_READ (I) + 1

Or, better yet, require:

CALL VOLATILE_READ (I, ITMP)
CALL VOLATILE_WRITE (I, ITMP+1)

Otherwise, VOLATILE will make existing, standard-conforming code
harder to read -- all programmers will have to repeatedly consult
declarations of variables to figure out whether they can treat

I = 2 * J

I = J + J

and so on.

Also, without the explicit-coding requirement, descriptions of
expressions in the standard and in all texts will have to become
much more complicated, when discussing things like optimizations.

(Witness the discussions here about functions and side effects. That's
about the degree of complexity that'll happen if VOLATILE gets added
as an attribute that quietly changes the meanings of existing expressions.)

Since VOLATILE is likely to be rarely used (the only possible argument
to "not worry" about the issues I point out above), nobody will mind
having to write the extra text. Besides, they can use smart editors
to do that for them.
--

"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu

Kearfott R. Baker

unread,

Mar 4, 1997, 3:00:00 AM3/4/97

Keith Bierman QED wrote:
>
> st2...@hsvax1.HS.UNI-HAMBURG.DE (Phillip Helbig) writes:
>
> > I would appreciate it if someone knowledgeable could write one or two
> > sentences about each of the (possible) new F2000 features, perhaps
> > indicating if (s)he is in favour of or opposed to it and why.
>
>

> > | Interval arithmetic (see N1189 item #62)
>

I would like to give a different perspective from Keith's (reproduced
below). In particular, used astutely and in the appropriate places,
interval arithmetic also

(1) makes certain computations simpler and more accurate,

and

(2) can even make some computations more efficient than using floating
point arithmetic.

Regarding (1), I take an example of numerical quadrature with error
bounds.
To bound the error in a classical quadrature formula with non-interval
means,
such as if you need to determine the number of subintervals in a
composite
formula, or in adaptive integration, you need to work with inequalities
and
obtain an estimate that overestimates the error. Doing so, the actual
numbers
the computer gives you are still just approximations, even if you add
the error.
With interval arithmetic, you simply evaluate the appropriate derivative
in
the error term using interval arithmetic, and add it to the
approximation.
The computer gives you rigorous bounds on the error that are sharper
than
with non-interval means, since you have explicitly added the correction
term.
In fact, when I teach introductory numerical analysis, I teach both
methods.
Given a choice on exams, students invariably prefer the interval
techniques.
(Of course, you need reasonable bounds on the range of the appropriate
derivative, but that is not difficult with functions given by formulas.)

Similarly, in adaptive quadrature, a heuristic is replaced by a rigorous
bound.
The formulas are simpler, since two levels of subdivision are replaced
by
a single level.

Regarding (2), take global optimization. Interval arithmetic is a
simple
way of getting upper and lower bounds on the value of an objective
function.
In some, if not most, cases, it is easier to get good bounds with
interval
arithmetic than with other means. Despite the fact that interval
arithmetic may
be slower than floating point, the extra power sometimes gives interval
algorithms a
speed advantage.

A third important application, where interval algorithms may actually be
faster, is
generally in constraint satisfaction techniques. In fact, interval
arithmetic may
be viewed as a relatively painless and efficient way of dealing with
systems of
intequalities.

Finally, once a good approximation to a solution to a linear or
nonlinear system
has been obtain (by whatever means), it is relatively inexpensive to use
interval arithmetic to construct narrow bounds within which the system
is automatically
verified to contain a unique solution. This adds a level of quality
assurance without
MUCH additional cost.

Thus, I feel use of interval arithmetic may not necessarily be a more
expensive
alternative, and its use will go beyond quality assurance of algorithms
that
are basically floating point algorithms.

--
---------------------------------------------------------------
R. Baker Kearfott, r...@usl.edu (318) 482-5346 (fax)
(318) 482-5270 (work) (318) 981-9744 (home)
URL: http://interval.usl.edu/kearfott.html
Department of Mathematics, University of Southwestern Louisiana
---------------------------------------------------------------

Malcolm Cohen

unread,

Mar 4, 1997, 3:00:00 AM3/4/97

>> | Allowing PUBLIC entities to have PRIVATE type

Currently any variable or parameter of PRIVATE type must itself be PRIVATE;
similarly any function or subroutine with a dummy argument or result variable
of PRIVATE type must be PRIVATE. These restrictions were intended to avoid the
situation where one could have access to an object without having access to its
type; but this situation arises in other ways anyway. The requirement is to
lift the restrictions.

This is more of a simplification that a major new feature. It does allow a
certain style of coding; e.g. as per this example:
MODULE m
TYPE,PRIVATE :: error_type
integer value
END TYPE
TYPE(error_type),PARAMETER :: err_abort = error_type(1)
TYPE(error_type),PARAMETER :: err_silent_continue = error_type(2)
TYPE(error_type),PARAMETER :: err_noisy_continue = error_type(3)
TYPE(error_type) :: err_application_default = err_abort
CONTAINS
SUBROUTINE do_something(...,err)
TYPE(error_type) err
...
END SUBROUTINE
END
!The type being private prevents the user from creating variables or values
!TYPE(error_type) himself, so "do_something" can only be called with one of
!the parameter values provided, or with the provided module variable. This
!prevents the user from supplying an erroneous or undefined value.

But mostly this is just a simplification.

>> | Derived type encapsulation feature

There is a problem with "derived type encapsulation" and the definition of
intrinsic assignment. Paper X3J3/97-145 gives more detail.

This is a minor bug fix rather than a big feature.

>> | Passing specific/generic names as arguments

Given
INTERFACE name
MODULE PROCEDURE name,name1,name2
END INTERFACE
Note that "name" is the name of one of the specific module procedures, as well
as the name of the generic. In Fortran 90, one could not pass "name" as an
actual argument; this was fixed in Fortran 95.

Thus this requirement does not require any further action.

>> | PUBLIC and PRIVATE derived type components

Having a derived type with some components public (i.e. visible outside the
defining module) and some components private (and thus not visible).

Cheers,
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
(mal...@nag.co.uk)

James Cownie

unread,

Mar 5, 1997, 3:00:00 AM3/5/97

to Craig Burley

Craig Burley wrote:
Craig says

> However, Fortran will become a worse language if the VOLATILE
> attribute is added a la C.
>
> I recommend that, in addition to specifying VOLATILE, _every_
> reference to an entity with the VOLATILE attribute _must_ be done
> via new language constructs like:
>
> VOLATILE_WRITE (I) = VOLATILE_READ (I) + 1
>
> Or, better yet, require:
>
> CALL VOLATILE_READ (I, ITMP)
> CALL VOLATILE_WRITE (I, ITMP+1)
>
> Otherwise, VOLATILE will make existing, standard-conforming code
> harder to read

This is all true, unfortunately it doesn't help with the problem for
which MPI (and other libraries) require VOLATILE.

The problem doens't arise with codes which are only written in Fortran,
because
the compiler has visibility of all of the updates which could occur, and
can therefore see the places where it must restore register copies of
variables to store.

The problem occurs where Fortran calls functions in C (or other
languages) which
do not obey the Fortran semantics. In particular consider functions
which perform
asynchronous operations (could be I/O, or in MPI message passing). Then
we have
something like

integer buffer(1000)
integer handle

call start_async_op (buffer, handle)
!*****
! Here the compiler sees no accesses to buffer
! but it is actually being updated by the asynchronous operation
!*****
call wait_for_async_op (handle)

So, what is wanted (and VOLATILE a la C is a blunt instrument for this)
is a way
of telling the compiler that the first argument of start_async_op should
not
be accessed (or held in registers) until the wait_for_async_op has
completed.

Of course this gets more complex when one has multiple possible
simultaneous
operations, and more than one way of finishing them, because the pairing
of start/complete points may no longer be compile time knowable.

-- Jim

James Cownie
Dolphin Interconnect Solutions
Phone : +44 117 9071438
E-Mail: jco...@dolphinics.com

William Clodius

unread,

Mar 5, 1997, 3:00:00 AM3/5/97

James Cownie wrote:
>
> <snip>

> The problem occurs where Fortran calls functions in C (or other
> languages) which
> do not obey the Fortran semantics. In particular consider functions
> which perform
> asynchronous operations (could be I/O, or in MPI message passing).

> <snip>

> So, what is wanted (and VOLATILE a la C is a blunt instrument for this)
> is a way
> of telling the compiler that the first argument of start_async_op should
> not
> be accessed (or held in registers) until the wait_for_async_op has
> completed.

> <snip>

Given that the sematics, e.g., "after this call wait untill the entity
is defined before you use it", is different from the normal semantics of
VOLATILE, e.g., "the entity's definition may have changed without any
obvious calls," I would suggest a different attribute name, say
ASYNCHRONOUS. The other semantics, "the entity's definition may have
changed without any obvious calls" could still be handled, albeit
awkwardly, the way it has always been handled in Fortran, i.e., through
arguments returned by subroutine calls coded in assembler or a lower
level language.

William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov

Van Snyder

unread,

Mar 12, 1997, 3:00:00 AM3/12/97

In article <5fho6j$b...@red.nag.co.uk>, mal...@sedi8.nag.co.uk (Malcolm Cohen) writes:
[...]

|> This is more of a simplification that a major new feature. It does allow a
|> certain style of coding; e.g. as per this example:
|> MODULE m
|> TYPE,PRIVATE :: error_type
|> integer value
|> END TYPE
|> TYPE(error_type),PARAMETER :: err_abort = error_type(1)
|> TYPE(error_type),PARAMETER :: err_silent_continue = error_type(2)
|> TYPE(error_type),PARAMETER :: err_noisy_continue = error_type(3)
|> TYPE(error_type) :: err_application_default = err_abort
|> CONTAINS
|> SUBROUTINE do_something(...,err)
|> TYPE(error_type) err
|> ...
|> END SUBROUTINE
|> END
|> !The type being private prevents the user from creating variables or values
|> !TYPE(error_type) himself, so "do_something" can only be called with one of
|> !the parameter values provided, or with the provided module variable. This
|> !prevents the user from supplying an erroneous or undefined value.

Enumerated types would be a simpler and more elegant solution to this particular
problem (but maybe not to others solved by allowing public entities of private
types).

--
What fraction of Americans believe | Van Snyder
Wrestling is real and NASA is fake? | vsn...@math.jpl.nasa.gov

Malcolm Cohen

unread,

Mar 13, 1997, 3:00:00 AM3/13/97

In article <5g7f8q$1...@netline-fddi.jpl.nasa.gov>,

Van Snyder <vsn...@gyre.jpl.nasa.gov> wrote:
>In article <5fho6j$b...@red.nag.co.uk>, mal...@sedi8.nag.co.uk (Malcolm Cohen) writes:
>[...]
>|> This is more of a simplification that a major new feature. It does allow a
>|> certain style of coding; e.g. as per this example:

[example omitted]

>|> !The type being private prevents the user from creating variables or values
>|> !TYPE(error_type) himself, so "do_something" can only be called with one of
>|> !the parameter values provided, or with the provided module variable. This
>|> !prevents the user from supplying an erroneous or undefined value.
>
>Enumerated types would be a simpler and more elegant solution to this particular
>problem

No, enumerated types have nothing to do with this feature. This feature is
just removing an unnecessary complication in type visibility.

And enumerated types would not "prevent the user from creating variables of
TYPE(error_type) himself". By preventing the user from declaring variables of
this type, the situation where an undefined value is created (by exiting from a
routine with an unSAVEd variable and re-entering) is avoided.

(Yes, the type which I made PRIVATE but had PUBLIC entities thereof could be
replaced by an enumerated type were we to have such things. But this is
orthogonal to the type/entity visibility issue which is what I was trying -
with a relatively simple example - to explain.)

Van Snyder

unread,

Mar 13, 1997, 3:00:00 AM3/13/97

Right. Enumerated types have nothing specific to do with public entities of
private types. But one _cannot_ (in all languages that support them) create
additional _values_ of an enumerated type. For the toy problem exhibited,
enumerated types are a better solution.

|> And enumerated types would not "prevent the user from creating variables of
|> TYPE(error_type) himself". By preventing the user from declaring variables of
|> this type, the situation where an undefined value is created (by exiting from a
|> routine with an unSAVEd variable and re-entering) is avoided.

Yes, private types prevent creating additional _variables_ of a type.

|> (Yes, the type which I made PRIVATE but had PUBLIC entities thereof could be
|> replaced by an enumerated type were we to have such things. But this is
|> orthogonal to the type/entity visibility issue which is what I was trying -
|> with a relatively simple example - to explain.)

Exactly.

0 new messages