Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.misc Subject: Re: C's sins of commission Message-ID: Date: 12 Oct 90 08:20:45 GMT References: <64618@lanl.gov) <2883@igloo.scum.com) <2171@enea.se> <1990Oct8.135551.21639@arnor.uucp> <1990Oct10.101527.2247@maths.nott.ac.uk> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 70 Nntp-Posting-Host: odin In-reply-to: anw@maths.nott.ac.uk's message of 10 Oct 90 10:15:27 GMT On 10 Oct 90 10:15:27 GMT, anw@maths.nott.ac.uk (Dr A. N. Walker) said: anw> Like everyone else over here, I'm missing the (initial) context, but I anw> found this interesting: Yes, good spotting! anw> In article <1990Oct8.135551.21639@arnor.uucp> anw> lowry@lusitania.watson.ibm.com (Andy Lowry) writes: lowry> I personally have written a great deal of code in Hermes and have lowry> found the lack of pointers to be no hindrance. [...] lowry> Of course, our compiler and run-time system make heavy use of lowry> pointers and shared data for reasons of efficiency, but this is lowry> completely hidden from the Hermes programmer. anw> In other words, here is a construct which is incredibly useful for anw> writing compilers and other programs, but which the ordinary anw> programmer is unable to use. Good point! And precisely my point too: pointers are nearly indispensable to write *implementations*, because our machines use them. But the other guy also has a point: if your implementation is efficiently written using pointers, your application can abstract away from them. anw> I don't think languages should hide useful abstractions from anw> programmers; they should hide annoying concretions instead. But pointers are a useful concretion, not an abstraction... anw> I don't really want to know the machine address of a variable, anw> or how to represent a conditional jump in machine code, or which anw> registers need to be saved over a procedure call. If you are doing fundamental *implementation* (OS, runtime library, profiler, debugger, compiler, ...) work, you want of course to deal explicitly with such things. It all depends on where you put your virtual machine boundary -- if your virtual machine is a C virtual machine, or an Ingres virtual machine, or a SPARC virtual machine, etc... anw> But I do want to be able to express within my language all the anw> abstractions that naturally arise in modelling my problem. These anw> may well include pointers ["keep a finger on that variable"], even anw> when there are no `data structures' around. Again: you never need pointers to model your *application*. Pointers actually cloud abstractions because they introduce an extra layer of manipulation (pointer values) that does not exist at the application level (that is only expressed in data values). If you have very simple relationships in your application, pointers are just one of the ways of *implementing* them, and one of the least interesting and nastier. If the machines we are programming had identification-by-contents for objects we would not need pointers at the implementation level; but they do not, so we must use pointers, identification-by-tagging, as a poor substitute on which to build the more useful and application oriented abstractions for relationships, using usually far more sophisticated mechanisms than pointers. I strongly believe that a lot of computer science, I think actually almost all of it (if you accept the idea that numeric analysis is not strictly CS :->), is about trying to simulate identification-by-contents using identification-by-tagging. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk