[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

Bakul Shah bakul at bitblocks.com
Fri Sep 1 12:22:10 AEST 2017

> On Aug 31, 2017, at 6:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
>>> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
>>>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
>>> So what chaps my grumpy old hide is why the heck do a whole new language
>>> when you have one that is pretty good?  Suppose we took C and added a
>>> dialect via options:
>>> 	--no-ptrs	// use arrays and indices, you get bounds checking
>>> 	--strings	// system managed memory for strings, like tcl
>>> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
>> Such a language would stop being C.
> Indeed.  But it builds on C.
>> In Go you can use slices instead of arrays (but slices are only one dimensional).
>> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
>> return &local_variable. No perlism.
>> Go provides other features which are quite useful: concurrency, channels,
>> interfaces, packages.
>> People who like C tend to like Go. But Go is not low-level enough. No one
>> is writing a kernel in it! Or doing bare metal programming. AFAIK.
> Exactly.
>>> etc.  Why create an entirely new language, new syntax, new linkage, etc,
>>> instead of fixing C's shortcomings?
>> C has too many problems. If you try fixing them, none of the "dusty decks"
>> would run on such a compiler + the new language would be severely
>> hampered in its evolution due to its C legacy.
> So I'd need to understand more to believe that claim.  And for the record,
> what I'm going for is a new C that is still C enough to be useful but
> fixes the problems enough to be a new language.  Someone asked about
> C++ and D, nope.  Too far from C.  I just want a C that fixes enough
> of the problems that it is more acceptable to modern programmers but
> is still C.  Not sure if I'm explaining that well enough.

See below. I think it would be not easy to build a simpler language
that is consistent and regular. I just touched on a couple of things
but there would be many more such small decisions....

1. Ptrs. If you remove them completely, functions can become
   pure and can not change anything. Most likely you'd end up
   adding "ref" parameter, which would be sorta like Pascal's
   var parameters.

       int f(var int x) {
                return x

        int z = 1;
        int y = f(z);   // y should be 2
        int x = f(z);   // x should be 3

   The benefit is that now you can not clobber the ptr but
   otherwise the same result.

   Do you allow declaring refs? You should for consistency.

        int x1;
        ref int x2 = x1;

   But if you allow this, either this assignment behaves
   differently from a ref int parameter or it would crash
   since x2 doesn't really point anywhere on initialization.
   So now you will be tempted to say

        ref int x2 = ref x1;

   This is almost exactly like

        int *x2 = &x1;

   A bit ugly.  IIRC Algol68 had something similar and well
   defined rules for how multi level refs were handled.

2. Passing Arrays. Now you need a way to pass subarrays.

        int z[] = {1,2,3,4};
        int g(int x[]) {
        int x = g(z[3:5]);      // g.x[0] = z[3]; g.x[1] = z[4].

   Now you need a way to iterate through the array in g.

        int g(int x[]) int {
            int sum = 0;
            for (int i = 0; i < len(x); i++) sum += x[i];
            return sum;

   But what happens if in g you change x[i]? Does z change?
   If you don't allow this, x[] becomes a constant but a
   scalar variable can be changed. So this is inconsistent.

   If you allow this, int x[] almost acts like var int x[]!
   For consistency with scalars you should copy z[3:5] but
   that can be expensive for large arrays. So now you will be
   tempted to use const (now a ref can be impllicitly passed
   since array won't be written over).

   Then there is the issue of multidimensional arrays.

        int z[4][5];
        int h(int x[][]) {
        int w = g(z[2:4][1:3]);

   If you are fixing arrays, you may as well do them right
   so that fortran code can be easily ported.  So what about

        int h(int x[][]) {
                int s = g(x[1][]);

   Here we're passing a column of z as a vector to g.
   You'd end up with a illife vector or something! But
   if you do this, vector access can slow down...

More information about the TUHS mailing list