One of the things I like about Pascal (Yes I *definitely* do like
Pascal) is its handling of enumerated scalar types (and subranges thereof)
I could find true happiness and fulfilment if C would handle
enums the same way - right now the approach seems to be muddled
and schizophrenic. Imagine, with the power C has to be able to
increase its readiblity (which it hasn't) by allowing TRUE array
indexing with enums( 'twould be paradise enow)

                                    Jerry Freedman,Jr

  Lets talk about Pascal.

  Let me see you write a single function to do a sumation over an array of
of integers of arbitrary size.  Can't do it huh. The problem, Pascal
doesn't suppose "generic" array sizes.

  Case statements in Pascal are a total failure. Since there is no
default clause, one has to test whether the switch variable
is in the case statement's range or is outside the range. You might
as well use if-then-elses.

  There are loop holes in Pascals suppositely "can't{*filter*}yourself over"
attitude too.   One in the function as a parameter to function
construct, there's no way of specifying the arguements to the input
function.  Hence one could do something like declare a function that takes 2
arguements. Pass that function to another function as an arguement and
call the input function with 3 arguements when it was declared to take
only two.  

   The other loop hole that I can think of is the use of case variant
records to access data that is in one form say int as another say
float.

   Another flop is the conditional expressions.  Pascal does not do
short-circuit evaluation of conditional expressions.  This
posses at least two problems, the obvious one being less efficient code.
The other being the awkward constructs that one must use to
achieve the equivalent of short-circuit evaluation.  The old

        if (not (p = nil)) then
                if (p^.field = x) then .....

You  call that more readable then this!

        if (p && p->field == x) ...

  And how about "despose".  Dynamic memory allocation is in the Pascal
definition.  I would like to see one implementation of "despose" that
did something reasonably.  Clearing the heap up until the pointer
that you are freeing is not reasonable!

  Other little things to squawk about
        o no bit-wise operations
        o no separate compulation
        o no utilities like most C implementations
          (refering to stdio.h, varargs.h ....)

  Now for the issue of readability in C.  This really is more of an issue
of the PROGRAMMER'S ABLITY to write readable code, not the languages
syntax or semantics! At least in the case of C vs Pascal.

--
                                        Eddie Wyatt

terrorist, cryptography, DES, {*filter*}, cipher, secret, decode, NSA, CIA, NRO.

  Example of the pathological case for enums array indexes.  (An implementors
perspective)

        typedef enum    {W = -10, X = -100, Y = 10, P = 0, Z = 0} PATHO ;

        int sumation(x)
            int x[PATHO];
            {
            register PATH i;
            register int sum;

            for (i = W; i <= Z; i = successor(i))
                    sum += x[i];

            return(sum);
            }

  The task here is to sum the over the first 5 indexes of  array x.

  Lets consider the code that needs to be generated for the statements:

                for (i = W; i <= Z; i = successor(i))
                    sum += x[i];

        first try

                for (i = -10, i <= 0; i = enum_get_next(i))
                    sum += *(x + lookup_hashtable(i));

        execute the loop and we get :

                i = -10, -100, 10 - exit loop.

        Nope that can't be right.

  Assume we can fix the above problem somehow and lets consider the code
generated for, lets say:

                sum += x[P];

        try

                sum += *(x + lookup_hashtable(0));

        Hmmm does lookup_hashtable return 3 or 4???

   Lets consider an alternate solution enums as array indexes.  Allow each
enumeration element  have two values associated with it - the place it
holds in the enumeration (for W that would be the value 0) and the
assigned value (for W that would be the value -10).

  From the context, one MIGHT be able to determine which is the correct
value to use.  In the above case.

        for (i = W; i <= Z; i = successor(i))
                    sum += x[i];

yields :

        for (i = 0; i <= 4; i++)
                sum += *(x+i);

    The above context prescribes that W,Z and i be intepreted as "place"
values, not the "assigned" values.  Look here too, no hashing function
either - efficient code.

   The major question here is whether the correct interpretation can
always be choosen given the context the variable is being used in.

Example :

        typdef enum {RED = 30, GREEN = 40, BLUE = 50} COLORTABLE;
        ......
        colortable[RED] = 64;
        .....

Are we indexing colortable[0] or colortable[30]??

We might say that if colortable is defined as

        int colortable[COLORTABLE] then the actual index is 0.

If colortable is defined as

        int colartable[] or colortable[256]

then we are refering to index 30.

  There are more things to be thought out, but this is a posible
implementation alternative for enums in C.

--
                                        Eddie Wyatt

terrorist, cryptography, DES, {*filter*}, cipher, secret, decode, NSA, CIA, NRO.