🚀 go-pugleaf

In article <SPACKMAN.92Oct28142448@disco-sol.dfki.uni-sb.de>, spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman) writes:
|> In article <1992Oct27.143849.26947@texhrc.uucp> pyeatt@Texaco.com (Larry D. Pyeatt) writes:
|> |I would not classify C and Pascal as very nearly the same thing.  C does
|> |almost no type checking, does not have the set type, only handles arrays
|> |between 0 and N, performs almost no run-time checking, passes parameters 
|> |differently, allows variable length parameter lists, cannot nest functions,
|> |has a more flexible FOR statement...  
|> 
|> I don't know; both languages provide optional, inadequate type checking;

How can you say that Pascal has optional or inadequate type checking? 
Last time I used it, it was reasonably picky about types.  C, on the
other hand, has almost no type checking at all.  

While we are talking about checking, let us mention run-time checking,
C provides almost no run-time checks.  The burden is on the programmer.
Pascal, on the other hand, performs adequate run-time checks.  Most
Pascal compilers provide an option whereby the run-time checking can
be turned off in order to get better run-time performance.

|> both languages have completely implementation-oriented type systems;

HUH?  I am not sure what you mean, unless you are referring to the 
underlying hardware implementation of the integer, character, etc.
If so, then you could say this about _most_ languages.

|> both provide small amounts of syntactic sugar for bitmaps (sets or bit
|> arithmetic, who cares? Neither has sets of integers, e.g.); 

Untrue.  Pascal has always supported sets on any enumerated type:

type
 intset  = set of integer;  
 charset = set of char;

|> both use
|> strange hacks to get variable-length parameter lists (Pascal's is
|> reserved to the implementation, but it's there sure enough); 

Which Pascal compiler have you been using?  I have never seen one which
supports variable length parameter lists.  However, variable length 
parameter lists are defined in both ANSI and K&R C standards.

|> both lack proper function values;

I am not sure what you mean by this

|> both provide explicit pointer values;

yes, but they work somewhat differently.

|> both
|> place the burden of storage management on the user;

True, neither language has automatic allocation or garbage collection.

|> both have really
|> stupid type declaration syntax.

What could be simpler and more clear than:

type
  mytype = array ['a'..'z'] of real;

  yourtype = array [-100..100] of char;

  thisrecord = record
    mine : mytype;
    yours: yourtype;
  end;

or in C:

typedef float[26] mytype;
typedef char[201] yourtype;
typedef struct{
mytype mine;
yourtype yours;
}thisrecord;

Note that these two pieces of code are _not_ the same.  There is no way
to declare the lower bound of an array in C. so the Pascal statement

writeln(mine['a'])

would print out the value of the first element in the array, while the C
statement

printf("%f\n",mine['a']);
 
would print out some weird value from the 97th position of an array which
only contains 26 elements.  It would not complain, hiccup, warn, or 
otherwize help you find your error.  In order to get the first element,
you have to write

printf("f\n",mine[0]);

|> Probably the most substantial difference between them is that C permits
|> variable initialisers.

Then why is it difficult to write C to Pascal and Pascal to C converters?
I have just shown a much more substantial difference.

|> |You could say that Pascal and Modula-2 are very nearly the same, but C
|> |has very little in common with Pascal other than that they both can
|> |be called ``block structured'' languages.
|> 
|> They're both Algol 68 downgrades. It's hard to find languages that are
|> more similar without actually being direct descendants, one of the
|> other.

I would not say that they are Algol 68 downgrades, but I would agree that
they are much smaller languages than Algol 68.  I would also say that 
Pascal is closer to Algol in many respects than C is.

|> ------------------------------------------------------------------------
|> stephen p spackman                                       stephen@acm.org
|> ------------------------------------------------------------------------

-- 
Larry D. Pyeatt                 The views expressed here are not
Internet : pyeatt@texaco.com    those of my employer or of anyone
Voice    : (713) 975-4056       that I know of with the possible
                                exception of myself.