reference type for C

[Keith Thompson]

Do you like the way Java treats arrays better?

Among other things, they do have a length that goes along with them.

I don't know Java well enough to have much of an opinion.

Java's mechanism likely involves some extra overhead relative to the C
approach. That's probably fine given the kinds of applications Java
targets. C is a substantially lower-level language, and I'm glad it
exists (for things like writing Java byte-code interpreters).
(Disclaimer: I don't know what language the Java byte-code interpreter
is written in.)

It would be interesting to have a language that's on a similar semantic
level to C, but that doesn't have C's odd treatment of arrays and
pointers. Such a language might not have arrays as first-class types,
but it wouldn't pretend to do so by adding special-case rules. It might
have the same underlying semantics as C, but with different syntax to
express its semantics.

I haven't given much thought to what it would look like.

 

[Keith Thompson]

Yes, the C++ vector is a standard library over the common C way
of doing things, which is to have a buffer which may only be partly
filled with data. If the array needs to grow indefinitely, the C
way is to call realloc(), but often C programmers impose an arbitrary
limit because of the complexity of coding this.
I don't see how you can implement a vector efficiently if it is passed
by value, however. Inherently you need to make a local copy, which
is O(N).

A vector object is probably something similar to a C struct object. It
wouldn't contain the elements of the vector; those would be accesses via
internal pointers.

 

[Keith Thompson]

I guess so.


Arrays were also largely second-class in the language I was working from.
However the language syntax and semantics were not altered so that it was
impossible to express first-class operations as they have been in C.

C's syntax and semantics weren't exactly "altered". C inherited these
features from its predecessors, BCPL and B. I think there was more
concern for maintaining backward compatibility than for making it
possible for some future version of the language to add first-class
arrays.

In a C-like language with first-class arrays, I wonder what the
consequences of something like this would be:

char s[5];
s = "Hello, world";

In Pascal, as I recall, the equivalent code is a compile-time error,
because arrays of different length have distinct and incompatible
types. In Ada, it's raises a run-time exception. In Perl and
similar languages, the length of an array isn't part of its type,
and the assignment just makes the array longer. I don't think any
of those solutions would be in the vaguely-defined "spirit of C".

That means a few first-class ops on arrays can be implemented (assignment
for example), but it also means explicit address-of and deref operators and
so on often need to be used to make them work like C.

But I agree C should be left alone now; this would be too big a fundamental
change at this point.

I think we're in agreement. How the heck did that happen?

 

[Keith Thompson]

I guess so.


Arrays were also largely second-class in the language I was working from.
However the language syntax and semantics were not altered so that it was
impossible to express first-class operations as they have been in C.

C's syntax and semantics weren't exactly "altered". C inherited these
features from its predecessors, BCPL and B. I think there was more
concern for maintaining backward compatibility than for making it
possible for some future version of the language to add first-class
arrays.

In a C-like language with first-class arrays, I wonder what the
consequences of something like this would be:

char s[5];
s = "Hello, world";

In Pascal, as I recall, the equivalent code is a compile-time error,
because arrays of different length have distinct and incompatible
types. In Ada, it's raises a run-time exception. In Perl and
similar languages, the length of an array isn't part of its type,
and the assignment just makes the array longer. I don't think any
of those solutions would be in the vaguely-defined "spirit of C".

That means a few first-class ops on arrays can be implemented (assignment
for example), but it also means explicit address-of and deref operators and
so on often need to be used to make them work like C.

But I agree C should be left alone now; this would be too big a fundamental
change at this point.

I think we're in agreement. How the heck did that happen?

 

[Keith Thompson]

I guess so.


Arrays were also largely second-class in the language I was working from.
However the language syntax and semantics were not altered so that it was
impossible to express first-class operations as they have been in C.

C's syntax and semantics weren't exactly "altered". C inherited these
features from its predecessors, BCPL and B. I think there was more
concern for maintaining backward compatibility than for making it
possible for some future version of the language to add first-class
arrays.

In a C-like language with first-class arrays, I wonder what the
consequences of something like this would be:

char s[5];
s = "Hello, world";

In Pascal, as I recall, the equivalent code is a compile-time error,
because arrays of different length have distinct and incompatible
types. In Ada, it's raises a run-time exception. In Perl and
similar languages, the length of an array isn't part of its type,
and the assignment just makes the array longer. I don't think any
of those solutions would be in the vaguely-defined "spirit of C".

That means a few first-class ops on arrays can be implemented (assignment
for example), but it also means explicit address-of and deref operators and
so on often need to be used to make them work like C.

But I agree C should be left alone now; this would be too big a fundamental
change at this point.

I think we're in agreement. How the heck did that happen?

 

[Keith Thompson]

I guess so.


Arrays were also largely second-class in the language I was working from.
However the language syntax and semantics were not altered so that it was
impossible to express first-class operations as they have been in C.

C's syntax and semantics weren't exactly "altered". C inherited these
features from its predecessors, BCPL and B. I think there was more
concern for maintaining backward compatibility than for making it
possible for some future version of the language to add first-class
arrays.

In a C-like language with first-class arrays, I wonder what the
consequences of something like this would be:

char s[5];
s = "Hello, world";

In Pascal, as I recall, the equivalent code is a compile-time error,
because arrays of different length have distinct and incompatible
types. In Ada, it's raises a run-time exception. In Perl and
similar languages, the length of an array isn't part of its type,
and the assignment just makes the array longer. I don't think any
of those solutions would be in the vaguely-defined "spirit of C".

That means a few first-class ops on arrays can be implemented (assignment
for example), but it also means explicit address-of and deref operators and
so on often need to be used to make them work like C.

But I agree C should be left alone now; this would be too big a fundamental
change at this point.

I think we're in agreement. How the heck did that happen?

 

[Keith Thompson]

[SNIP]

Sorry for the quadruple post; my newsreader and/or server was acting up.