Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!hc!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran Subject: Re: data types without pointers Message-ID: <4152@lanl.gov> Date: 24 Sep 88 21:32:06 GMT References: <1058@amelia.nas.nasa.gov> Organization: Los Alamos National Laboratory Lines: 117 From article <1058@amelia.nas.nasa.gov>, by fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts): >>> [...] Try representing a dynamic length >>> fifo using Hoare's structure and answering the questions: >>> 1) What happens when I add to a fifo? >>> 2) How do I represent this structure? >>> 3) How do I keep track of the head/tail? >>> 4) How do I detect an empty fifo? >> [... stuff deleted which deteted my Fortran 8x - like versions ...] > Err, you didn't even try to answer my question. Your fortran 8x was > just like my fortran, except that 8x allows you to keep the pieces > together in a structure. I already showed how to do it with arrays. > Any thoughts on the question I asked? I thought I had answered your question. The differences between the 8x-like program I presented and the syntax Hoare used are trivially superficial: 1) Hoare uses semicolon ';' to end statements, Fortran 8x uses end of line. 2) Hoare uses parenthesis to begin and end a type declaration, Fortran 8x uses an explicit END TYPE ... statement: Hoare Fortran type example ( TYPE EXAMPLE ... ... ); END TYPE EXAMPLE 3) Hoare puts the data type after the variable list and Fortran 8x puts it before: Hoare Fortran head, tail : integer integer head, tail 4) Hoare always requires a colon between the variables and the type (as above), Fortran 8x _allows_ double colons but doesn't require it. 5) I don't have the book in front of me, so I can't be sure, but I think Hoare used ':=' for assignment rather than just '='. 6) Again, I don't have the book with me, but I think Hoare used the Pascal - like rule for IF control (more than one statement in the scope of an IF required BEGIN ... END marks - rather like C {...}). 7) I think Hoare used square brackets '[...]' for array indices. 8) Hoare used '.' rather than '%' to reference components of syructured variables. Apply those rules to the Fortran-like code I already posted and you'll have a pretty good imitation of Hoare's version of FIFOs. So, in answer to your 'Any thoughts on the question I asked?': > [...] Try representing a dynamic length > fifo using Hoare's structure and answering the questions: I think that's pretty clear by now. In any well designed language the implementation of a FIFO queue is pretty much the same (including your C version). > 1) What happens when I add to a fifo? The same thing that most of the other versions do: if there's no room for the new element, the queue is extended to make room, when there's room the new element is added and the queue is tested to see if it's full (for future reference). Then the ADDTO routine returns. > 2) How do I represent this structure? Internally, it's probably the same as the C version of the same thing. The only difference from the user's point of view is the lack of explicit pointers so that it is not possible for the queue%data array to be aliased to something else. > 3) How do I keep track of the head/tail? queue%head and queue%tail are indexes into queue%data. What else do you need? > 4) How do I detect an empty fifo? queue%empty is a boolean variable which always is true if the queue is empty, and false otherwise. >>> BTW, recursive structures are a very clumsy way to think about bags, >> [... my agreement ...] > OK. How do I implement bags. Certainly not with arrays. (;-) Best > with linked lists. Now you've got me confused again. Linked lists are for large lists in which the order is important and which are often altered. For other things, arrays (or some other structure) are best. All the implementations of bags I've seen were done with arrays (all from SmallTalk to data packages for Pascal code). The order is simply not important for a bag. The other thing that confuses me is that recursive structures and pointers implement linked lists in exactly the same way. The difference between them is the lack of an explicit pointer. Semantically and syntactically the difference is otherwise completely superficial. >>[...] It is better to have different functionality actually have different >>syntax as well. Most uses of pointers are actually something else >>in disguise. > > And most other forms of other addressing are just uses of pointers in > disguise. [...] I agree. Many of the data structures people use are internally implemented with pointers. But making the pointer explicit carries penalties that the user doesn't want. As I just finished pointing out in another article, explicit pointers clutter the scope with unneeded names and degrade performance because the compiler must assume possible aliasing (where the user intended none). There are probably many other problems with explicit pointers as well, but just one of these is sufficient cause to reject explicit pointers if something else is available. J. Giles Los alamos