C/C++ Interactive Reference Guide/C-C++ Interactive Reference Guide.iso/c_ref/csource3/137_01/sep84col.ddj

Text File | 1979-12-31 | 20.8 KB | 676 lines

.pl 61
.po 4
..
.. this article was prepared for the C/Unix Programmer's Notebook
.. Copyright 1984 Pyramid Systems, Inc.
..
.. by A. Skjellum
..
.he "C/Unix Programmer's Notebook"   for September, 1984 DDJ.


                               Introduction

.. okay
    Past  columns have been devoted to topics about C and Unix as  they

exist in the real world.   In this column,  I depart from this precedent by

discussing  some  proposals for increasing the power and flexibility of  C.

We  work in an evolving field where change  is  inevitable.   Consequently,

many languages go through regular upgrades and improvements (eg Fortran IV,

Fortran  66,  and Fortran 77).   C has been more immune than other  popular

languages.   The  lack  of upgrades is probably due mainly to C's  lack  of

intrinsic functions,  but clearly points to the basic elegance and power of

C.

.. okay
    I  am  aware of only a few upgrades beyond the language  definition

specified in The C Programming Language (K&R).  These are enumerated  types

and structure assignment.  Both of these features were introduced with Unix

version 7 and are detailed in Unix v7 documentation.   Structure assignment

is  useful  in what follows,  but type enumeration will not  be  mentioned.

Therefore, while we base our definition on the Unix 7 version of C, this is

not  likely  to  confuse those who have access only to  The  C  Programming

Language.

.. okay
    Purists  may argue that I have no business recommending changes  or

upgrades  to  C.   Others  may argue that many of the  suggestions  can  be

implemented via compiler preprocessors or by function calls and need not be

part  of  the  language.   (This  second point is discussed  later  in  the

column.)  In order to head off the critisism that I am 'tampering' with the

C language, I offer my recommendations as a new language grammar based on C

but  called 'X.' The letter X was chosen to denote language  extensibility,

which is the main point of the following proposals.

                          Language Extensibility

.. okay
    Most  languages allow user defined functions,  subroutines and many

newer languages allow user defined data types.   Extensible languages  like

Forth  and APL allow functions,  operators,  and data types  to be added to

the programming environment in a way that makes them equivalent in  stature

to  predefined  operations.   While  C retains  tremendous  flexibility  by

excluding  intrinsic functions,  it does not allow user defined types to be

treated  as easily as ints,  longs or  floats.   Specifically,  one  cannot

extend  the definitions of operators such as addition or multiplication  to

new  data types created with typedef.   This means that function calls must

be used,  which while a completely viable approach,  lacks elegance.   This

concept is illustrated in the following example.


.. okay
    As part of a program,  I need to define a data type called  COMPLEX

which  will  function like Fortran's complex data type.  This data type  is

used  for  handling  complex  numbers of the form A + iB  where  i  is  the

imaginary  unit and A and B are real numbers.  This might be done with  the

following definition:

.cp 6
        typedef struct  /* complex number type definition */
        {
            double _creal;    /* real part */
            double _cimag;  /* imaginary part */

        } COMPLEX;

.. okay
    I  will work with several variables of type COMPLEX (eg  alpha  and

beta) which are defined as follows:

        COMPLEX alpha, beta;   /* alpha and beta are complex #'s */

Up  to this point,  we have treated the complex data type  equivalently  to

built-in types.  We can also work with pointers to or arrays of COMPLEX, so

there  is  no  deficiency along these  lines.   However,  to  assign,  add,

multiply, or subtract these COMPLEX variables, subroutines would have to be

invented.  Subroutines for two representative operations are illustrated in

Figure I.

.pa
                      ---------- FIGURE I. ----------

    Assignment:  alpha = A + iB; /* pseudo code */

    Function:
        calling sequence    (K&R C):     cassign(&alpha,A,B);
        calling sequence    (Unix 7 C):  alpha = cassign(A,B);

        function definition (K&R C):

            cassign(comp,a,b)
            COMPLEX *comp;
            double a,b;
            {
                comp->_creal = a;
                comp->_cimag = b;
            }

        function definition (Unix 7 C):

            COMPLEX cassign(a,b)
            double a,b;
            {
                COMPLEX temp;   /* temporary variable */

                temp._creal = a;
                temp._cimag = b;
                return(temp);   /* return structure */
            }



    Addition:  gamma = alpha + beta; /* pseudo code */

    Function:
        calling sequence    (K&R C):     cadd(&gamma,&alpha,&beta);
        calling sequence    (Unix 7 C):  gamma = cadd(alpha,beta);

        function definition (K&R C):

            cadd(gamma,alpha,beta)
            COMPLEX *gamma;    /* destination */
            COMPLEX *alpha; /* addend */
            COMPLEX *beta;  /* augend */
            {
                gamma->_creal = alpha->_creal + beta->_creal;
                gamma->_cimag = alpha->_cimag + beta->_cimag;
            }

.cp 10
        function definition (Unix 7 C):

            COMPLEX cadd(alpha,beta)
            COMPLEX alpha,beta; /* addend, augend */
            {
                COMPLEX temp; /* temporary */

                temp._creal = alpha._creal + beta._creal;
                temp._cimag = alpha._cimag + beta._cimag;

                return(temp);
            }


                    ---------- END FIGURE I. ----------


.. okay
    The pseudo code presented with the subroutines in Figure I.  is the

most convenient way to specify the operations desired.   If the data  types

had been intrinsic, we could have used similar real C statements in lieu of

subroutines.   To utilize '+', '*' or other operators with the COMPLEX data

type  we must introduce a mechanism for defining these operations.

                                 Operators

.. okay
    How  could  we  specify new operations?  For example how  would  we

define  addition  for  the  complex  data  type?   The  following  type  of

definition could be used to extend addition to the COMPLEX type:

        COMPLEX oper `+`(alpha,beta)    /* X grammar */
        COMPLEX alpha,beta;
        {
            COMPLEX __temp; /* temporary */
            __temp._creal = alpha._creal + beta._creal;
            __temp._cimag = alpha._cimag + beta._cimag;

            return(__temp); /* return result */
        }

The  keyword oper is new:  oper indicates that the following definition  is

for  an operator.   The return keyword used in function calls also  appears

with a similar meaning.      Since COMPLEX preceeds oper,  this defines  an

operation  over  the  COMPLEX data type.   Since there  are  two  arguments

(alpha,  beta), the operator is binary.  Finally, note that the '+' sign is

enclosed  in graven accents.   Quoting by graven accents is chosen as a way

to distinguish operator names.   We will see that quotation will not always

be needed.

.. okay
    To  use  this  new operator (and assuming that '='  had  also  been

defined,) the following statement could be used:

        gamma = alpha + beta;    /* add complex numbers */

Note  that  we  have  omitted the graven accents.   Since the  '+'  can  be

distinguished from keywords or identifiers in this context, quoting  is not

required.  The  operator definition specified above gives the X compiler  a

means to evaluate the addition request specified in the example  statement.

The  parser would break this statement down until it could pass an argument

garnered from the left and right of the addition operator,  much as it does

with  intrinsic  operators  and data types.   Whether  this  results  in  a

subroutine   call   or  in-line  code  would  depend  on   the   compiler's

implementation.

                             More on Operators

.. okay
    Operators  turn out to be a very powerful and useful  concept.   We

needn't  limit  ourselves to defining standard operations  for  new  types.

There  is nothing to stop the definition of arbitrary operators.   A  crude

facility  already  exists  for  this in C  via  the  parameterized  #define

statement.  However, the above facility is more general and more consistent

with the syntax of C than the preprocessor #define approach.   To encompass

the  generation of inline code as provided by #define,  we would also offer

the inline adjective, which could be used as follows:

        COMPLEX inline oper `-`(alpha,beta) /* subtraction inline */
        ...

This  keyword  would  instruct the compiler to  generate  inline  code  (as

opposed to a subroutine call) whenever possible.   It's use is analogous to

the use of the register adjective:  the compiler complies when feasible and

silently ignores the request when it cannot comply.

.. okay
    In  some  cases,  C definitions can be shortened when no  ambiguity

exists  (eg 'unsigned' instead of  'unsigned  int').   Therefore,  'inline'

would  replace 'inline oper' in actual  practice.   Furthermore,  operators

would by default work on and return integers, as functions do by default.

                         Other Users for Operators

.. okay
    In  my view,  operators would be used not only to  define  existing

operations  over new data types,  but also for specifying other  operations

over  new  as  well  as existing data types.   These  new  operators  would

normally  have alphanumeric names and would thus require quoting in  graven

accents  when  they  appear in expressions.   For example,  we  define  the

operation of NAND (negated and) for integers as follows (no graven  accents

are required in the definition but are required in the below invocation):

        int oper nand(a,b)
        int a,b;
        {
            return(~(a & b));
        }

To use this in an actual expression we would have to quote the nand:

        c = a `nand` b;

                            Operator Hierarchy

.. okay
    C already has a built-in hierarchy for known operations.   The most

reasonable  approach is to give user-defined operators the lowest priority.

This might require more parentheses, but seems logical.

                           Pointers to Operators

.. okay
    C  provides  the facility to use pointers to functions.   It  could

potentially  prove  useful  to  have pointers  to  operators  as  well.   A

function's  address is specified by its name without trailing  parentheses.

Unfortunately,  operator  names  are  used  in this  way  to  indicate  the

operation they represent.   In order to remove the ambiguity in  requesting

the pointer, the operator name could be parenthesized (eg (+) or (`nand`)).

.. okay
    Using  pointers  to operators implies that defined operations  must

have  subroutines associated with them.   Thus truly inline operators could

have no pointers associated with them.

                   Dichotomy of Operators and Functions

.. okay
    Functions and operators are almost the same  thing.   However,  the

compiler  must  know if an operator is binary  or  unary.   Therefore,  its

definition must be available before use.  On the other hand, arguments to C

functions  are not checked for number or type.    Therefore,  we choose  to

keep operators and functions separate, although there is nothing to prevent

operators using function calls.

.. okay
    In  order to avoid lexical conflicts,  operator and function  names

would  have  to be different.   This is also desirable from  a  programming

viewpoint, in order to avoid confusion and errors.

                              Other Proposals

.. okay
    With the addition of operators,  the X grammar provides a much more

consistent  programming environment than standard C.   However,  there  are

some  other  points  with deserve consideration.   The first  of  these  is

providing  a  means  to  handle  subroutines  with  a  variable  number  of

arguments.  This is considered first.

    Since  C makes no assumptions about its function library,  the user

is free to write his own,  should the standard functions prove  inadequate.

However,  the user cannot properly handle functions with variable number of

arguments,  as must be done by printf(),  scanf() and their relatives.   We

solve  this  problem by introducing a typing adjective called vec which  is

short  for vector.   This adjective is used to indicate the the  number  of

arguments  to  the  function is  variable.   For  example,  the  ficticious

function  my_printf()  which  allows  variable arguments  (and  returns  an

integer) would be defined as follows:

        vec int my_printf(argcnt,argvec)
        int argcnt;
        char *argvec[];
        {
            /* code goes here */
        }

.. okay
A  function declared with vec always has  two  arguments:  argcnt,  argvec.

These variables are analogous to main()'s (argc,argv) pair.   Before use, a

definition of the form:

        vec my_printf();

would  be  included  in each file where  my_printf()  is  referenced.  This

definition  causes  command line arguments to be  processed  normally:  the

rightmost argument is pushed (placed on the stack) first,  and the leftmost

last when code is generated.   However, the two additional arguments argcnt

and  argvec  are  also stacked.   The argvec variable points to  the  stack

location where the first real argument is located.  Since normal stacks are

push-down,  this should provide the arguments in the correct order.  argcnt

contains  the  number of arguments plus one to account  for  argvec.   This

makes it completely analogous to argc.   argvec always contains an address,

but this is not very useful if no arguments were specified in the  function

call.

.. okay
    To  illustrate  the  stacking mechanism,  imagine  that  we  invoke

my_printf() as follows:

        my_printf(arg1,arg2,arg3,arg4,arg5);

For  this  specific call,  the stacking arrangment (excluding  any  special

register saves) would look as specified in Figure II.   Note that argcnt is

six (five arguments) for this case, as described above.

.pa
                     ---------- Figure II. ----------

            Memory Layout for a variable argument function call

                            -------------------
                            |   Low memory    |
                            -------------------
                            |       ...       |
                            -------------------
                            |   argcnt = 6    |
                            -------------------
                            |   argvec = ADDR |
                            -------------------
                      ADDR: |      arg1       |
                            -------------------
                            |      arg2       |
                            -------------------
                            |      arg3       |
                            -------------------
                            |      arg4       |
                            -------------------
                            |      arg5       |
                            -------------------
                            |       ...       |
                            -------------------
                            |   High memory   |
                            -------------------

                   ---------- End Figure II. ----------


.. okay
    It might be worthwhile to have variable argument calls, even if the

function were not declared as using this calling convention. To allow this,

we  introduce  the  ellispis (...) concept into the  argument  string.   If

my_printf()  were  not declared as vec,  we could force  variable  argument

format as follows:

        my_printf(arg1,arg2,arg3,arg4,arg5...);

Always  including  the  ellipsis mark for this variety  of  call  seems  to

improve  readability,  but  is not required in order that compatibility  is

kept with current C usage.

                              Fixed Arguments

.. okay
    The  argvec variable always points to the first variable  specified

on  the  command  line.   However,  the  function  definition  could  still

explicitly  declare  a  finite number of arguments which  it  may  wish  to

examine more directly.   For example,  if the first argument of my_printf()

were a control string, we could declare my_printf() as follows:

        vec int my_printf(argcnt,argvec,control_string);
        int argcnt;
        char **argvec;
        char *control_string;

Notice that contents of control_string would be meaningless if argcnt  were

less than two.

.. okay
     One final note about variable argument control is that it enhances

a  function's  ability  to  detect  incorrect  input.   With  reference  to

printf(),  Kernighan and Ritchie state:  "A warning:  printf uses its first

argument to decide how many arguments follow and what their types are.   It

will  get confused,  if there are not enough arguments or if they  are  the

wrong  type."  If implemented with the vec arrangement,  printf() could  at

least  know if it has been given the right number of arguments.   It  still

would not know if they were of the correct types.

                     Variable length automatic arrays

.. okay
    Another  element  of  the  X  grammar is  the  ability  to  declare

automatic arrays which possess variable length.   Since stack displacements

are  computed at each entry to a block,  this only forces a  computed  size

allocation.   At worst, a memory allocation mechanism must be tied into the

compiler.   This  latter restriction can be serious if C is used in a  very

low  level environment,  such as in operating system development.   So that

the use of this feature can be seen readily,  we require the use of the var

adjective  in conjunction with such definitions.   For  most  purposes,  it

offers  a  welcome enhancement.   Where it is inappropriate,  this  feature

should be disabled via a compiler switch.

    As  a general example,  we declare a variable length array  in  the

following routine:

                /* declare an array of integers one larger than argument */
        array_test(length)
        int length;
        {
            var int test[length+1]; /* declare array */
            ...
        }

                          A new looping structure

.. okay
    Many  loops  are  unconditional  with breaks  generated  only  from

within.   Therefore  it  is often useful to have an  unconditional  looping

command.   This  avoids  a  lot of  'while(1)'  sequences.  This  could  be

implemented as follows:

.cp 7
        loop
        {
            ... code ...
        }

replaces

        while(1)
        {
            ... code ...
        }


                    Preprocessors and related comments

.. okay
    Preprocessors  could be used to implement several of the X features

mentioned above.   The statements and expressions would be expanded by  the

preprocessor  into  standard function calls.   The preprocessor would  also

provide  subroutines from definitions,  as needed.   New data  types  could

certainly be handled in this way.  However, changes to the C parser must be

made  in order to handle the vec and var features.   Trivial additions such

as loop can be handled with the existing C preprocessor.

.. okay
    Some programmers may argue that no additions are needed since  most

of  the features outlined above can all be achieved through function calls.

In my view, the X grammar makes C more (and not less) consistent because it

allows both intrinsic and user-defined types to be handled in similarly. It

also allows greater portability by defining a means through which  variable

argument functions can be handled uniformly.  In summation, it turns C into

an extensible language while adding only a few new keywords.

                                Conclusion

.. okay
    In  this column,  I have suggested an enhanced C grammar which  was

denoted  X to indicate extensibility.   It is the (Unix 7) C language  with

enhancements   designed  to  allow  the  incorporation  of   user-specified

operators into programs.  This should provide  more flexible and consistent

reference to user-defined data types.   Also mentioned were variable length

automatic  arrays  (var)  and a mechanism for  allowing  variable  argument

functions (vec).   Finally, the use of preprocessors for implementing these

ideas was mentioned.

    I  look forward to any other ideas about X or enhanced C which  may

be forthcoming from our readers.