Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ut-ngp.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!ut-sally!ut-ngp!kjm From: kjm@ut-ngp.UUCP (Ken Montgomery) Newsgroups: net.lang.pascal Subject: Re: PASCAL as a systems programming langugage Message-ID: <1180@ut-ngp.UUCP> Date: Fri, 11-Jan-85 17:44:53 EST Article-I.D.: ut-ngp.1180 Posted: Fri Jan 11 17:44:53 1985 Date-Received: Sun, 13-Jan-85 08:22:35 EST References: <282@harvard.ARPA> Distribution: net Organization: U.Texas Computation Center, Austin, Texas Lines: 135 [] >From: breuel@harvard.ARPA (Thomas M. Breuel) > >|>Perhaps the nicest (in the sense of clean) thing about PASCAL >|>is the way it bifurcates the universe of objects into pointers >|>and pointees. >| >|I've always thought that was one of its most *broken* features. >|This bifurcation is ridiculous in the light of such C objects >|as pointers to pointers. > >I don't know what you are talking about. PASCAL has a superset of the >data structures available in 'C'. In particular, you can get pointers >to pointers. You can even define a type 'TYPE foo= ^foo;' which is >impossible in 'C'. Touche. But you still can't allocate a static object and then create a pointer to it. I consider this to be a serious deficiency. >|> It is thus easier to debug monster programs >|>with monster data structures than is the case with C. >| >|Exactly contrary to my experience with ~1000 line programs. >|(Not really monsters, but large enough for comparison >|purposes...) > >Perhaps that would change if you worked with PASCAL a bit more? You >may find that it indeed is not a bad language for debugging. The >current state of the UN*X kernel (ever looked at namei or ever >wondered where all these unreferenced inodes come from) and the UN*X >utilities ("My sendmail has a bug!") seem to indicate that 'C' is not >that easy to debug either. OS code is not subject to ordinary debugging techniques. (Try Cyber Peripheral Processors some time!) Thus I think that your example (of namei() in UN?X) is suboptimal. Unfortunately, I can't comment any further than that, since the last time I looked at a UN?X kernel was in 1980 (Version 6 with buffer mods). I don't work on UN?X or its utilities now, so I haven't looked at sendmail either. However, C was my language of choice for my fullscreen editor (which I wrote in my spare time). I shudder to think of the amount of nonsense I would have gone through writing in Pascal... >|> Actually, >|>all PASCAL needs to be a superior systems language to C is a >|>casting operator, >| >|No pointer arithmetic? Or ability to take the address of a static >|object? ACK! The ability to have static headers for linked-lists >|in dynamic storage is one of the things I miss most in Pascal. > >Indeed, no pointer arithmetic. Using arrays and indices instead is a Arrays and indices are a pretty poor way to implement linked lists. >lot more portable How so? > and gives the compiler a lot more freedom for >optimisation Compilers should translate code, not second-guess programmers. > and adaptation to strange architectures. Such as? > Basically the same >is true for getting the address of a static object. If you are used to >it, you won't find it any less convenient than pointer arithmetic. You >may also discover that it helps avoid traps and pitfalls. Traps and pitfalls are *my* problem, not the compiler's. But I've not noticed any such problems in addressing static objects in C... >|>assuming the compiler knows how to optimize >|>programming constructs like sequential array references. >| >|I prefer a minimum of magic (like global optimizations; these >|are an invitation to the compiler to mysteriously break programs). > >Working compilers don't break correct programs. I prefer >a maximum of optimisation, and if 'magic' is involved, I couldn't >care less. If you, on the other hand, rely on certain 'features' of >the compiler (e.g. sequential allocation of static data &c), No. I merely want the compiler to translate what I said, not what it thought I meant. > then you >should not complain if you don't get what you expected. My experience has been that I get what I expect more often with C than with any other HLL. >PASCAL is written such that the compiler has a lot of freedom in >optimising the code. 'C' code, on the other hand, is very hard to >optimise, just because 'C' allows you to do funny things like get a >pointer to any variable anywhere &c. If you're talking about global optimizations, I mostly prefer to do them myself (which is why 'register' variables are so nice). >|>I can do without the demented precedence of logical operators, >|>though. >| >|Plus the fact that short-circuit evaluation is not required... > >[I'm not even sure that it would be permitted to happen..., I'll have >to look at Jensen&Wirth] > >So what? Why does the whole world have to look like '&&' and '||'? >Use 'IF' instead, it might even come out more readable. There is no direct way (that I'm aware of...) to represent the semantics of '||' using pure nested 'IF' constructions. (Of course you can always (Horrors! :-)) use 'GOTO'.) I think expressions using '&&' are cleaner, more readable, and more maintainable than equivalent nested 'IF' constructions, in most cases. > Thomas. > breuel@harvard -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cats and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ut-ngp.ARPA [for Arpanauts only]