Path: utzoo!attcan!uunet!munnari.oz.au!metro!cluster!ultima!jeremy From: jeremy@ultima.socs.uts.edu.au (Jeremy Fitzhardinge) Newsgroups: comp.society.futures Subject: Re: C's sins of commission (was: (pssst...fortran?)) Message-ID: <18377@ultima.socs.uts.edu.au> Date: 19 Sep 90 03:05:13 GMT References: <1990Sep14.212806.8131@abcfd20.larc.nasa.gov> <63218@lanl.gov> Organization: Mystaecle and Saecret Order of Dagon, Bexley Chapter Lines: 94 In comp.society.futures you write: |From article <1990Sep14.212806.8131@abcfd20.larc.nasa.gov>, by jcburt@ipsun.larc.nasa.gov (John Burton): |> [...] |> I guess the point I was trying to make was |> that pointers are NOT difficult to understand AND they provide |> much needed flexibility... | |Really? Iv'e been asking this same question for over two years |on the net - no one has yet answered it: Please give me a specific |example of a _legal_ C data structure which _cannot_ be implemented |with the same efficiency with the data structuring features below. |Note, there is not a _single_ explicit pointer data type in the |following list. | |1) 'Atomic' types (floats (various sizes), ints (various sizes), booleans, | characters (various character sets), etc....) | |2) Enumerated data types. These are simply a vay to allow the user to | invent a new 'atomic' type. | |3) Arrays. Mappings from a tuple of indices to a typed value. Note: an | array of arrays is legal and is _NOT_ the same as a 2-d array (although | a little syntactic sugar could allow this later - no one has ever asked | for it). | |4) Sequences. An ordered collection of zero or more objects to be | accessed in a specific order. Obvious syntactic sugar (like direct | referencing of the last element or an arbitrary element) is permitted. | The usual implementation of character strings in C is an example of an | inefficient implementation of a sequence. You can have a sequence of | any data type (including a sequence of sequences - which is what a | dictionary is). How does this differ from an array (or vica versa)? Is it that a sequence is a completely dynamic object, where arrays are created with a specific size (whether it be at compile or run time)? You seem to imply this later. Is an object in a sequence of any type? Do all objects have to be the same type? I guess a sequence of unions would achieve that effect while still only allowing a sequence of one type. |5) Records. Like C struct. No difference at all really. | |6) Unions. These are _always_ discriminated. The compiler is | responsible for maintaining and checking the type tags. Note that | this only _seems_ inefficient: _legal_ C programs should always | explicitly maintain a tag anyway. Careful selection of the tagging mechanism would be needed, I suppose. At a guess you would have some sort of tag field in the union that has a number representing the current type of the union. Since the union can be of any type (simple and derived) the actual tags used would have to be decided at compile time. This would make linking individually compiled modules and libraries using shared union types difficult, since they would all have to use the same tagging convention. I think it should become a task of the linker to organize this kind of thing. Have something like a "tag table" along side the "symbol table", and treat them similarly. Scoping of [union] types would have to be handled like scoping of variables, with similar name-space conflicts. Perhaps I'm taking a too C oriented approach, but this seems to accord with current practice with practical languages I know/use. |7) Recursive types. These may be given the attribute 'aliased' in order | to allow circular and overlapping references. Other than that, we have | discussed these before. | |In addition, all variables can be declared with a 'dynamic' attribute, |which means that they must be allocated before use (dynamic arrays give |their size at allocation time). It might be desireable for sequences |and recursive data type to be given the dynamic attribute automatically. | |I can demonstrate sample syntax for these if anyone thinks it is required. |Anyone who proposes a C data object that he claims is not representable |here is invited to do so (I'm not joking - I'm designing a language with |these features - this challenge is an attempt to find out whether I'm |leaving something out). How would you handle what is currently handled by pointers to functions in C? I'm primarily a C programmer, but I certainly don't want to let myself be caught by "How can I do it in C" as opposed to "How can it be done". For the things I do (OS hacks, graphics, realtime interactive) I've found C to be the most useful since, it is a simple language that can be found on a wide range of machines, or tends to be the best supported/implemented on those machines. Reciently I've been teaching myself C++ and found it to fill a lot of gaps and problems in C (although I hadn't noticed them until I used C++). No doubt there are other languages I will come across that have features I want in C++. I don't think they will be FORTRAN or COBOL. -- Jeremy Fitzhardinge: jeremy@ultima.socs.uts.edu.au jeremy@utscsd.csd.uts.edu.au DEATH TO ALL FANATICS!