4 ms·

> Unityped, as in, they have only one type. If there are no distinguishable properties ("one type") then untyped vs unityped seems a distinction without a diff

by igouy 8y ago

> Unityped, as in, they have only one type. If there are no distinguishable properties ("one type") then untyped vs unityped seems a distinction without a difference.

naasking 8y ago
Upon further thought, there's probably a useful distinction to be made here. Let's take the classical untyped lambda calculus as a canonical untyped language. Every value is a lambda, so there is clearly only one type, and no deeper structure at play. Now contrast with something like Scheme or JS. Clearly there is richer underlying structure than mere lambdas, but since every value is still interchangeable (a global sum type) I think this suggests a "unityped" label as a meaningful distinction from the untyped case. So I would amend my original comment to move the lambda calculus out of unityped and into untyped, and possibly Tcl as well since everything is conceptually a string there.
- igouy 8y ago
  Let's take BCPL — 'The major difference between BCPL and ALGOL is that all ALGOL variables are declared with data-types (integer, real, boolean, string, array, procedure, label, pointer, etc.), whereas all BCPL variables have the same data-type: a 16-bit number. In ALGOL, the meaning of an expression is dependent both on its context and on the data-types of the entities involved, and only expressions with certain data-types may appear in a given context. In BCPL, any expression may be used in any context; the context alone determines how the 16-bit value of the expression is interpreted. BCPL never checks that a value is "appropriate" for use in a given way.' http://www.bitsavers.org/pdf/xerox/alto/bcpl/BCPL_Reference_Manual_Sep79.pdf http://www.bitsavers.org/pdf/xerox/alto/bcpl/BCPL_Reference_... ( I haven't been able to figure out what happens on divide-by-zero: The division operator / yields the correct result if E1 is divisible by E2; it is otherwise implementation dependent but the rounding error is never greater than 1. https://www.bell-labs.com/usr/dmr/www/bcpl.pdf https://www.bell-labs.com/usr/dmr/www/bcpl.pdf )
- igouy 8y ago
  Surely the meaningful distinction between BCPL and Scheme is that BCPL is not type safe and Scheme is type safe.
  - naasking 8y ago
    I disagree. "Type safety" is not the only kind of safety, and it's not the kind of safety found in either Scheme or BCPL.
    - igouy 8y ago
      > "Type safety" is not the only kind of safety Never said it was. "Type safety is the property that no primitive operation ever applies to values of the wrong type." I did say "BCPL is not type safe" (so on that we agree). Are you saying that, in Scheme, primitive operations can be applied to values of the wrong type? A string can be multiplied by 2?
      - naasking 8y ago
        > Are you saying that, in Scheme, primitive operations can be applied to values of the wrong type? Yes, that's a well-defined operation: it throws a runtime exception (which is also a value). All operations are well-defined in safe languages, that's what makes them safe. But dynamically "typed" languages aren't type safe. A truly undefined operation would immediately halt the program because the program simply cannot proceed. You can resolve this unsafety by defining semantics for these operations (like reifying errors as values as in dynamically typed languages), or you can add a type system which ensures only safe programs can be expressed.
        igouy 8y ago
        You say "Yes" "primitive operations can be applied to values of the wrong type", but then you say that doesn't happen and what actually happens is that "it throws a runtime exception". What you seem to mean is that isn't what I (`naasking`) would call type safety. That may be. However, it clearly has been a text-book meaning of type safety.

by igouy 8y ago

> Unityped, as in, they have only one type. If there are no distinguishable properties ("one type") then untyped vs unityped seems a distinction without a difference.

naasking 8y ago

Upon further thought, there's probably a useful distinction to be made here. Let's take the classical untyped lambda calculus as a canonical untyped language. Every value is a lambda, so there is clearly only one type, and no deeper structure at play. Now contrast with something like Scheme or JS. Clearly there is richer underlying structure than mere lambdas, but since every value is still interchangeable (a global sum type) I think this suggests a "unityped" label as a meaningful distinction from the untyped case. So I would amend my original comment to move the lambda calculus out of unityped and into untyped, and possibly Tcl as well since everything is conceptually a string there.

igouy 8y ago
Let's take BCPL — 'The major difference between BCPL and ALGOL is that all ALGOL variables are declared with data-types (integer, real, boolean, string, array, procedure, label, pointer, etc.), whereas all BCPL variables have the same data-type: a 16-bit number. In ALGOL, the meaning of an expression is dependent both on its context and on the data-types of the entities involved, and only expressions with certain data-types may appear in a given context. In BCPL, any expression may be used in any context; the context alone determines how the 16-bit value of the expression is interpreted. BCPL never checks that a value is "appropriate" for use in a given way.' http://www.bitsavers.org/pdf/xerox/alto/bcpl/BCPL_Reference_Manual_Sep79.pdf http://www.bitsavers.org/pdf/xerox/alto/bcpl/BCPL_Reference_... ( I haven't been able to figure out what happens on divide-by-zero: The division operator / yields the correct result if E1 is divisible by E2; it is otherwise implementation dependent but the rounding error is never greater than 1. https://www.bell-labs.com/usr/dmr/www/bcpl.pdf https://www.bell-labs.com/usr/dmr/www/bcpl.pdf )
igouy 8y ago
Surely the meaningful distinction between BCPL and Scheme is that BCPL is not type safe and Scheme is type safe.
- naasking 8y ago
  I disagree. "Type safety" is not the only kind of safety, and it's not the kind of safety found in either Scheme or BCPL.
  - igouy 8y ago
    > "Type safety" is not the only kind of safety Never said it was. "Type safety is the property that no primitive operation ever applies to values of the wrong type." I did say "BCPL is not type safe" (so on that we agree). Are you saying that, in Scheme, primitive operations can be applied to values of the wrong type? A string can be multiplied by 2?
    - naasking 8y ago
      > Are you saying that, in Scheme, primitive operations can be applied to values of the wrong type? Yes, that's a well-defined operation: it throws a runtime exception (which is also a value). All operations are well-defined in safe languages, that's what makes them safe. But dynamically "typed" languages aren't type safe. A truly undefined operation would immediately halt the program because the program simply cannot proceed. You can resolve this unsafety by defining semantics for these operations (like reifying errors as values as in dynamically typed languages), or you can add a type system which ensures only safe programs can be expressed.
      - igouy 8y ago
        You say "Yes" "primitive operations can be applied to values of the wrong type", but then you say that doesn't happen and what actually happens is that "it throws a runtime exception". What you seem to mean is that isn't what I (`naasking`) would call type safety. That may be. However, it clearly has been a text-book meaning of type safety.