🚀 go-pugleaf

[]
>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]