3 ms·

Disclosure: dynamic typer here. The way I understand it, a part of the issue is about possibly deferring the time at which the type of data is known to the tim

Disclosure: dynamic typer here. The way I understand it, a part of the issue is about possibly deferring the time at which the type of data is known to the time at which the data is operated upon, since calling a numeric addition function on not-numbers, e.g. strings, is a type violation, no matter which programming language you are writing in. The question is where you want your parsing-or-validating to occur, since this decision makes piece of the software either more tightly coupled or more heterogenous in which kinds of data they accept. The author makes and proves a claim that this decision, which is naturally postponable in JS due to its highly dynamic and schemaless-by-default object nature, is similarly postponable in Haskell. The other part about ignoring unknown keywords is very simple and understandable to me - you can indeed allow a statically typed program to ignore unknown schema keywords as you can allow a dynamically typed one to error on them.

StandardFuture 7y ago
I actually really enjoy your views on dynamic typing. But, if we agree on this definition then is it not an admittance that "dynamic type systems" don't actually exist and instead we are simply talking about evaluation/validation being programatically specified by the programmer instead of embedded evaluation/validation by the compiler and/or runtime? And since it is being specified by the programmer, then we run into the possibility of that validation being incorrectly implemented or possibly forgotten entirely. Any type system that had better verification of self-programmed type validation code from the programmer would solve this issue, no?
- phoe-krk 7y ago
  > "dynamic type systems" don't actually exist One definition of a "dynamic type system" that I am aware of is that there is runtime-existent information about types of particular pieces of data - or, somewhat equivalently, that types are information associated with values, not variables. Therefore, one could imply that e.g. Java has a dynamic type system. The way I understand the question you're asking is: if a language has an "eval" function that accepts arbitrary code as input, what prevents it from having static-type-system-class parsing and type safety guarantees as a part of its functioning? It essentially means that the compiler for a language must both be permanently present in memory (like for Javascript, or Lisp, or Smalltalk) and it must implement the static type checks for all code that it parses (like for Haskell). I think that these two requirements are orthogonal to each other and therefore they don't really clash with each other. Either there will be languages which implement both of these paradigms at the same time, or there already are such languages, and I am not yet aware of their existence.
zozbot234 7y ago
The author actually argues against Haskell as an example of their philosophy, because Haskell has poor support for open static types. They generally have to be faked in unintuitive ways by relying on the typeclasses feature, and something like OCaml's support for structural, extensible records and variants seems to be entirely off limits out-of-the-box.
- yakshaving_jgt 7y ago
  I don’t think that’s correct. The author’s point is that structural typing is possible in statically-typed languages, but isn’t a thing in Haskell. To learn more, Google for “Haskell row polymorphism”. The author correctly points out that structural vs nominal is a separate argument from static vs dynamic.
  - zozbot234 7y ago
    The whole point of row polymorphism (for both records and variants) is that it allow for implementing open types in a static typing context. And OCaml supports this out of the box whereas Haskell does not.
    - yakshaving_jgt 7y ago
      Yes, that’s true. I’m not disputing that. Perhaps I misinterpreted your previous comment. I think the point I want to make is that in the argument between static vs dynamic, the structural vs nominal argument is not really relevant.

StandardFuture 7y ago

I actually really enjoy your views on dynamic typing. But, if we agree on this definition then is it not an admittance that "dynamic type systems" don't actually exist and instead we are simply talking about evaluation/validation being programatically specified by the programmer instead of embedded evaluation/validation by the compiler and/or runtime? And since it is being specified by the programmer, then we run into the possibility of that validation being incorrectly implemented or possibly forgotten entirely. Any type system that had better verification of self-programmed type validation code from the programmer would solve this issue, no?

phoe-krk 7y ago
> "dynamic type systems" don't actually exist One definition of a "dynamic type system" that I am aware of is that there is runtime-existent information about types of particular pieces of data - or, somewhat equivalently, that types are information associated with values, not variables. Therefore, one could imply that e.g. Java has a dynamic type system. The way I understand the question you're asking is: if a language has an "eval" function that accepts arbitrary code as input, what prevents it from having static-type-system-class parsing and type safety guarantees as a part of its functioning? It essentially means that the compiler for a language must both be permanently present in memory (like for Javascript, or Lisp, or Smalltalk) and it must implement the static type checks for all code that it parses (like for Haskell). I think that these two requirements are orthogonal to each other and therefore they don't really clash with each other. Either there will be languages which implement both of these paradigms at the same time, or there already are such languages, and I am not yet aware of their existence.

zozbot234 7y ago

The author actually argues against Haskell as an example of their philosophy, because Haskell has poor support for open static types. They generally have to be faked in unintuitive ways by relying on the typeclasses feature, and something like OCaml's support for structural, extensible records and variants seems to be entirely off limits out-of-the-box.

yakshaving_jgt 7y ago
I don’t think that’s correct. The author’s point is that structural typing is possible in statically-typed languages, but isn’t a thing in Haskell. To learn more, Google for “Haskell row polymorphism”. The author correctly points out that structural vs nominal is a separate argument from static vs dynamic.
- zozbot234 7y ago
  The whole point of row polymorphism (for both records and variants) is that it allow for implementing open types in a static typing context. And OCaml supports this out of the box whereas Haskell does not.
  - yakshaving_jgt 7y ago
    Yes, that’s true. I’m not disputing that. Perhaps I misinterpreted your previous comment. I think the point I want to make is that in the argument between static vs dynamic, the structural vs nominal argument is not really relevant.