4 ms·

The only "safe" Wirth language I know about is Oberon-2, which has bounds-checking of arrays, sentinels and runtime-checking of pointers — though no compile-tim

The only "safe" Wirth language I know about is Oberon-2, which has bounds-checking of arrays, sentinels and runtime-checking of pointers — though no compile-time checking. Is this what you're referring to? I like Wirth, but his type systems were always super simple, and as far as I know, he never innovated at compile time safety in the way that, say, Rust or Haskell do. Again, Go seems a better analogue; anything that needs to deal with unsafe pointers needs to use the "unsafe" package.

pjmlp 11y ago
Not sure what you mean with runtime-compile time checking of pointers. Wirth type systems weren't always super simple, not when compared with C style ones. Wirth has designed Pascal, Modula-2, Oberon, Oberon-2, Active Oberon and Oberon-07 He has contributed to Extended Pascal, Object Pascal, Component Pascal. Also worked on Algol compilers and some of its dialects, Mesa and Cedar while at Xerox PARC. His work had an influence in Ada, Modula-2+ and Modula-3. Some of the type safe things that Modula-2 in 1978 already offered, that C still doesn't do today: - Type safe enumerations - Bounded checked arrays - Arrays indexed by enumerations - Type safe sets - Range typed integers - No implicit conversions - reference parameters instead of pointers for function/procedure calls - tagged records - low level coding/assembly intrisics require use of the SYSTEM package The only thing lacking was automatic memory management, which we later introduced in the Oberon family. However as you can see from the list there are a whole class of errors that aren't possible. If you like to research old stuff, have a look at B5000 system, which used Algol as their system programming language in 1961. Common to his languages and Xerox PARC ones, was the idea that you can do systems programming in higher level languages, provided the language provided some unsafe path that needs to be explicitly mentioned. But type safety should precede "performance at any cost" mantra. Something also mentioned by Hoare on his ACM Award speech in relation to Algol in 1980. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. " The problem is that younger devs never learned any of this and probably the only thing they know about Wirth languages is some braindead Pascal compiler.
- lobster_johnson 11y ago
  Oberon-2 had runtime-checking of pointers: It could check the validity of a pointer and immediately panic rather than return garbage or crash with a page fault. Similarly with arrays. Wirth did some nice things with type safety, of course (I've always liked his type-safe set/range types), but he never was much into type systems. For example, his set and range types were hardwired into the language; you couldn't build a set-like type yourself, or build something that acted as a range, or overload any of the standard function such as inc() or min(), or indeed any type coercion. With the exception of Oberon-2's (limited and highly Go-like) notion of abstract classes, nothing was polymorphic, every type was only "itself" and their purpose was always entirely about holding data. This is what I mean by his type systems always being "simple". He was attacking practical engineering problems, not type-theory problems. Go is exactly the same. Swift isn't; it has generics and sum types and protocols and OO and pattern matching and lambdas and a bunch of other stuff that Wirth would probably find too complex (his last few languages tended towards mercilessly removing features). I don't disagree that Wirth's languages are more advanced than C, though!
  - pjmlp 11y ago
    > Oberon-2 had runtime-checking of pointers: It could check the validity of a pointer and immediately panic rather than return garbage or crash with a page fault. Similarly with arrays. Ah, but this was a property of any sane systems programming language with automatic memory management. > With the exception of Oberon-2's .... How well do you know Active Oberon, Zonnon and Component Pascal? They extend Oberon(-2) with abstract classes, generics, tasks (active objects), type extensions, method definition signatures. Also many consider his work as influence in Ada and Modula-2 successors, whose type systems are not very far from C++ ones. Incidentally he became disillusioned with these language variants and went with a minimalist view (Oberon-07) that makes even Go look like a complex type system.
    - lobster_johnson 11y ago
      Sure, Active Oberon is pretty advanced, and Modula-3 had all sorts of things, including generics — but to my knowledge Wirth was not directly in those languages (or with Zonnon or Component Pascal), and he was unhappy with their complexity. (He apparently prefers the entire language's grammar to fit on a single screen.)

pjmlp 11y ago

Not sure what you mean with runtime-compile time checking of pointers. Wirth type systems weren't always super simple, not when compared with C style ones. Wirth has designed Pascal, Modula-2, Oberon, Oberon-2, Active Oberon and Oberon-07 He has contributed to Extended Pascal, Object Pascal, Component Pascal. Also worked on Algol compilers and some of its dialects, Mesa and Cedar while at Xerox PARC. His work had an influence in Ada, Modula-2+ and Modula-3. Some of the type safe things that Modula-2 in 1978 already offered, that C still doesn't do today: - Type safe enumerations - Bounded checked arrays - Arrays indexed by enumerations - Type safe sets - Range typed integers - No implicit conversions - reference parameters instead of pointers for function/procedure calls - tagged records - low level coding/assembly intrisics require use of the SYSTEM package The only thing lacking was automatic memory management, which we later introduced in the Oberon family. However as you can see from the list there are a whole class of errors that aren't possible. If you like to research old stuff, have a look at B5000 system, which used Algol as their system programming language in 1961. Common to his languages and Xerox PARC ones, was the idea that you can do systems programming in higher level languages, provided the language provided some unsafe path that needs to be explicitly mentioned. But type safety should precede "performance at any cost" mantra. Something also mentioned by Hoare on his ACM Award speech in relation to Algol in 1980. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. " The problem is that younger devs never learned any of this and probably the only thing they know about Wirth languages is some braindead Pascal compiler.

lobster_johnson 11y ago
Oberon-2 had runtime-checking of pointers: It could check the validity of a pointer and immediately panic rather than return garbage or crash with a page fault. Similarly with arrays. Wirth did some nice things with type safety, of course (I've always liked his type-safe set/range types), but he never was much into type systems. For example, his set and range types were hardwired into the language; you couldn't build a set-like type yourself, or build something that acted as a range, or overload any of the standard function such as inc() or min(), or indeed any type coercion. With the exception of Oberon-2's (limited and highly Go-like) notion of abstract classes, nothing was polymorphic, every type was only "itself" and their purpose was always entirely about holding data. This is what I mean by his type systems always being "simple". He was attacking practical engineering problems, not type-theory problems. Go is exactly the same. Swift isn't; it has generics and sum types and protocols and OO and pattern matching and lambdas and a bunch of other stuff that Wirth would probably find too complex (his last few languages tended towards mercilessly removing features). I don't disagree that Wirth's languages are more advanced than C, though!
- pjmlp 11y ago
  > Oberon-2 had runtime-checking of pointers: It could check the validity of a pointer and immediately panic rather than return garbage or crash with a page fault. Similarly with arrays. Ah, but this was a property of any sane systems programming language with automatic memory management. > With the exception of Oberon-2's .... How well do you know Active Oberon, Zonnon and Component Pascal? They extend Oberon(-2) with abstract classes, generics, tasks (active objects), type extensions, method definition signatures. Also many consider his work as influence in Ada and Modula-2 successors, whose type systems are not very far from C++ ones. Incidentally he became disillusioned with these language variants and went with a minimalist view (Oberon-07) that makes even Go look like a complex type system.
  - lobster_johnson 11y ago
    Sure, Active Oberon is pretty advanced, and Modula-3 had all sorts of things, including generics — but to my knowledge Wirth was not directly in those languages (or with Zonnon or Component Pascal), and he was unhappy with their complexity. (He apparently prefers the entire language's grammar to fit on a single screen.)