3 ms·

The way I remember the pascal type system is arrays of different lengths were different types.

by bigbillheck 3y ago

filmor 3y ago
They are pretty much everywhere when statically allocated.
- zabzonk 3y ago
  well, not in c.
  - Kamq 3y ago
    I believe they are in C, but arrays degrade to pointers when you look at them wrong, and _those_ don't have length as part of their type. At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing.
    - zabzonk 3y ago
      > when you look at them wrong no, almost whenever you look at them. it is very hard to carry around the size of an array in C. > At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing. post some code that illustrates what you are talking about
      - Kamq 3y ago
        I was trying to get clang to throw an error that included type information to double check what it thought the type was. Quickest thing I could think of was trying to assign to an array. The exact error in question was: error: array type 'int[3]' is not assignable Which seems to imply that clang is considering the length to be part of the type. edit: You asked for code (my apologies that it's rather trivial). int x[3] = {1, 2, 3}; int y[3]; y = x;
  - filmor 3y ago
    Even in C, citing the standard (6.2.4, 20): > Array types are characterized by their element type and by the number of elements in the array.
fuzztester 3y ago
There's more to it than that. You could (from early Pascal days) and can have arrays where the array index range is a previously defined subrange of integers, or maybe even of an enumerated type. Then you have sets as a built-in type, which is big. Some more.
AnimalMuppet 3y ago
In the original Pascal, that was true. The standard (and, I think, Jensen & Wirth) were that way. And it was a fatal flaw. I had a program that I took over that did a numerical simulation on a 2D grid with user-specified size. The original author simulated that 2D grid with a 1D doubly-linked list. As you might expect, this was both slow and error-prone. But he did it because there was no possible type that you could give to a user-sized array. There was literally no way to talk about such a thing. We eventually "fixed" it by allocating the largest 2D array possible within our memory limitations, and using only the user-specified part of it. Most "real" Pascals (Turbo Pascal, but others that were intended to be used in the real world, not just in the classroom) developed some way to give a type to a variable-length array (and also to do a C-ish cast). Unfortunately they all did it in different ways, so there was no code portability between compilers if your code needed such things. So, yeah, "objectively better than C" is quite a stretch, even just in the type system.

The way I remember the pascal type system is arrays of different lengths were different types.

filmor 3y ago

They are pretty much everywhere when statically allocated.

zabzonk 3y ago
well, not in c.
- Kamq 3y ago
  I believe they are in C, but arrays degrade to pointers when you look at them wrong, and _those_ don't have length as part of their type. At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing.
  - zabzonk 3y ago
    > when you look at them wrong no, almost whenever you look at them. it is very hard to carry around the size of an array in C. > At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing. post some code that illustrates what you are talking about
    - Kamq 3y ago
      I was trying to get clang to throw an error that included type information to double check what it thought the type was. Quickest thing I could think of was trying to assign to an array. The exact error in question was: error: array type 'int[3]' is not assignable Which seems to imply that clang is considering the length to be part of the type. edit: You asked for code (my apologies that it's rather trivial). int x[3] = {1, 2, 3}; int y[3]; y = x;
- filmor 3y ago
  Even in C, citing the standard (6.2.4, 20): > Array types are characterized by their element type and by the number of elements in the array.

fuzztester 3y ago

There's more to it than that. You could (from early Pascal days) and can have arrays where the array index range is a previously defined subrange of integers, or maybe even of an enumerated type. Then you have sets as a built-in type, which is big. Some more.

AnimalMuppet 3y ago

In the original Pascal, that was true. The standard (and, I think, Jensen & Wirth) were that way. And it was a fatal flaw. I had a program that I took over that did a numerical simulation on a 2D grid with user-specified size. The original author simulated that 2D grid with a 1D doubly-linked list. As you might expect, this was both slow and error-prone. But he did it because there was no possible type that you could give to a user-sized array. There was literally no way to talk about such a thing. We eventually "fixed" it by allocating the largest 2D array possible within our memory limitations, and using only the user-specified part of it. Most "real" Pascals (Turbo Pascal, but others that were intended to be used in the real world, not just in the classroom) developed some way to give a type to a variable-length array (and also to do a C-ish cast). Unfortunately they all did it in different ways, so there was no code portability between compilers if your code needed such things. So, yeah, "objectively better than C" is quite a stretch, even just in the type system.