jlg@lanl.gov (Jim Giles) (10/20/90)
There has been some confusion among some people posting to the net about the context of this discussion. This thread began on the comp.society.futures and was about the design of _future_ programming languages. Many articles have missed that point and have latched on to some out-of-context part of the discussion and made comments which were not germane. The last item on this chapter reintroduces the original context of the discussion. > You're repeatedly making statements like these: > > Pointers can never be more efficient than arrays because *(p+i) is > just as slow as p[i]. Yes, I do keep making that statement. It's true, unless you live in a world of obsolete compilers. Since my interest is in design of _future_ languages, I don't have any interest in obsolete compilers. > Pointers inherently force the programmer not to use any higher-level > abstraction. Indeed, if the higher-level structures are not available or are only available from preprocessors, the adept user _will_ be forced not to use the higher-level stuff - unless he's willing to take the performance hit that preprocessors imply. So, you're right again, I _DO_ repeatedly make such statements - and I will continue to do so. > All data structures may be expressed as recursive data structures. I have _never_ made such a statement. I _have_ made the statement that all high-level data structures can be expressed as some combination of seven structures (and three attributes). I have sent you a list of such structures (more than once, I think). I have posted the list on this thread at least 4 times (twice, while the thread was still on comp.society.futures and twice on this newsgroup). However, I will post the list again: 1) atomic types (integers, floats, etc.) 2) enumerated types 3) arrays (one or _more_ dimensions) 4) sequences (variable size, one dimensional) 5) unions (always tagged) 6) Records (or STRUCTS, or whatever you want to call them). 7 Recursive data structures (just records with one or more recursive components) Attributes are applicable to individual variables, not to whole data types. Attributes are as follows: a) static, automatic, or dynamic. The first two are the same as the C keywords of the same name (actually, I recommend different keywords, but it's the concept I want to expound here - so why complicate things) Dynamic means that the variable is not allocated until the user specifically allocates space for it, and its lifetime continues until the user explicitly deallocates its space (or, possibly its automatically garbage collected - if the user is willing to put up with the overhead of such a tool). b) aliased. This attribute allows any two names of the same type to refer to the _same_ object in the system. The presence of this attribute on a variable declaration implies to the compiler that all the identifiers in the same declaration _might_ be aliased, overlapping, etc.. Such a declaration also tells the compiler to allow such variables (and their components) to be assigned to each other with the "shallow copy" operator - the only way that two things should _ever_ become aliased. c) map ... as .... This attribute says that a specific set of variables are to be mapped or overlayed (storage association) by some record data type. This permits the machine dependent access to internal specifics of the implementation. The obvious example is the ability to bit twiddle floats (for efficient I/O conversion, for example): float :: x type float_internal !Internal structure of IEEE float bit.1 :: sign !one bit sign int.8 :: exponent !8-bit biased exponent (treated as !a signed integer with 8-bits) int.23 :: significand !remember, if exponent is zero !the use of this must _not_ add !a hidden normalization bit on end type float_internal map x as float_internal ... x=5.0 !use x as float x.sign = 1 !make x negative x.exponent=x.exponent+1 !double x (assuming it's in range) It is with a language such as I've described here that I claim that pointers are redundant. The examples you've given so far have failed miserably to convince me that I'm wrong. End of chapter 5 J. Giles
rh@smds.UUCP (Richard Harter) (10/23/90)
In article <66257@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
= I _have_ made the statement that
= all high-level data structures can be expressed as some combination of
= seven structures (and three attributes)...
= 1) atomic types (integers, floats, etc.)
= 2) enumerated types
= 3) arrays (one or _more_ dimensions)
= 4) sequences (variable size, one dimensional)
= 5) unions (always tagged)
= 6) Records (or STRUCTS, or whatever you want to call them).
= 7 Recursive data structures (just records with one or more recursive
= components)
= Attributes are applicable to individual variables, not to whole data
= types. Attributes are as follows:
= a) static, automatic, or dynamic....
= b) aliased...
= c) map ... as ....
Interesting. Is this an opinion, or is this something that you can
prove? Offhand it seems to that there are three requirements which
must be met to establish this claim.
I. You need a specification or description of "high-level data
structures" that is both general enough to actually include
all high-level data structures and is detailed enough so that
you can actually use it in proofs.
II. You need to be able to show that the cited list can in fact
express all high-level data structures.
III. You also need to be able to show that this expression is
effective, i.e. that the implementation cost in time and space
of expressing an arbitrary high level structure in terms of
the cited seven structures is of the same order as that of
the arbitrary structure.
Has all of this been done? If it has, it might be useful to post
references to the relevant work.
--
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb. This sentence short. This signature done.peter@ficc.ferranti.com (Peter da Silva) (10/24/90)
Is it my imagination or are neither of these guys talking about *modern* programming languages methods, such as object-oriented programming? Seems more like alt.religion.computers material to me. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com