5 ms·

I have no dogma about where you implement your typechecker; all I assert is that it's better to have one. The LISP philosophy is (in my impression from the lite

by gue5t 10y ago

I have no dogma about where you implement your typechecker; all I assert is that it's better to have one. The LISP philosophy is (in my impression from the literature) that with powerful enough abstractions, one writes so little code that there is hardly any room for mistakes to sneak in, so typecheckers could provide little benefit. In one sense this thesis is plausible: at some level you either stop encoding the specification of your intended functionality into your types, or you end up programming in a theorem-proving language like Coq or Agda, which everyone seems to agree is bad for productivity. But I think we should be trying to move toward more specifications, not fewer, and solve the ergonomics problems as we encounter them. Unrelatedly, I have worked in Typed Racket and the performance is so poor that I can't advocate its use. Of course you can profile and optimize anything, and avoid writing code which typechecks slowly, but such static analyses seem the sort of thing where incremental computation (caching, and amortization across executions of the typechecker) should make even very powerful analyses finish quickly. And Racket doesn't take advantage of the results of its typing analyses to optimize runtime representations of datatypes, so even after typechecking your code runs very slowly and uses a lot more memory than it needs.

Jtsummers 10y ago
> I have no dogma about where you implement your typechecker; all I assert is that it's better to have one. You seem to be suggesting that types are absent from lisp, that's not the case. Common Lisp, Scheme, and Emacs Lisp all make use of types. They are, to a first approximation [0], all strongly typed and dynamically typed languages. Since you're not dogmatic about the where of it, try computing: (+ 2 'atom) In your favorite common lisp. It will result in an error, specifically a `SIMPLE-TYPE-ERROR`. You can also specify types in function declarations in Common Lisp: (defun double-integer (x) (declare (type integer x)) (* 2 x)) This will only accept integers now. Other types passed in as a parameter to `double-integer` will result in an error. You can apply this at any level once you start building up your own types as well (structs, classes, etc.). The benefit here is that you can leave your code wide-open to allow for many cases at some stages, while optimizing or constraining it in others. This malleability is fantastic in lisps. While I'm certainly a great fan and proponent of static type checking, the benefits of lisp's concepts (the malleability of its semantics and syntax), make it a great force-multiplier for component users. A great number of concepts become practically trivial when given the level of abstraction that lisps permit. A good type system can give you something akin to a calculus of types. A good functional language (here I'll include lisps even though many these days seem to discard them as such) give you a sort of calculus over computation. But the structure of lisp (particularly its homoiconic nature) gives you a calculus over your programs syntax and semantics. [0] The places where they may be considered weakly typed are places where it's somewhat "natural". Such as in Common Lisp where there's the numeric tower. Technically your number does stay a number, but it moves from an integer to, say, a rational when you perform a division by a non-divisor integer. It maintains the highest level of precision/accuracy possible. So `(/ 1 3)` doesn't become some 32-bit float version like `0.3333334`, but rather `1/3`, nor does it do the C thing and turn it into 0.
- gue5t 10y ago
  I don't see how "typed/untyped" is a meaningful distinction if you consider "dynamic types" to be types. If the only observable effect of the typechecker in a dynamically-typed language is a runtime error, how do we distinguish an arbitrary source of runtime errors (e.g. "throw" or "error" statements) from a dynamic typechecker? Obviously it isn't the presence of the word "type" in error messages, but what is it? In the presence of the metaprogramming you describe, we can't say it's down to whether checks are inserted automatically either, since non-type dynamic checks may also be inserted pervasively and automatically with metaprogramming. If Lisp is typed, what's an "untyped" language? One in which the user hasn't done metaprogramming to insert runtime checks? Or is the distinction just about whether it's the end programmer or the language implementor who does the metaprogramming? None of these seem like very useful distinctions. If it's lispy to actually do a separate typechecking pass, please forgive my ignorance.
  - zem 10y ago
    i'd say an untyped (well, weakly typed; every language has some notion of types) language was one like C where you can construct a value of some type, and then treat the block of memory in which the physical representation of that value is stored as some other type. that said, eric lippert has a good blog post on [defining our terms more precisely before even asking the question](https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/ https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-...)
    - telotortium 10y ago
      There are in fact typeless languages that are neither statically nor dynamically typed, although they aren't particularly relevant nowadays -- BCPL, Forth, and assembly, among others. These languages have only words that hold integer values, with different operators treating the words as an integer, pointer, etc. Those who claim that only static types are worthy of the name "type" would probably consider both dynamically typed and typeless languages to be equally untyped -- dynamically typed languages just support richer semantics on their values, such as storing a "tag" (i.e., dynamic type) in each value.
taeric 10y ago
I am not aware of anyone that is against having a typechecking pass on the code that a LISP author writes. I fully acknowledge that my sphere of knowledge regarding who would be against it is pretty low, though. Do you have specific criticisms in mind? To me, most of the criticisms I see on LISP almost always come down to gripes about the parentheses. Usually it is said jokingly, but it is also the only criticism. Worse are when there are claims that there are no IDEs that can help with LISP. I don't even know what to say to that one. The birth of the modern IDE can easily be traced to predecessors of emacs. (Indeed, for most purposes today, the only difference between emacs and other IDEs is the language of extension. And... emacs being able to edit itself largely as it runs.) None of this is to say that a LISP is the panacea of development. I just don't think there is a panacea anymore.

by gue5t 10y ago

Jtsummers 10y ago

> I have no dogma about where you implement your typechecker; all I assert is that it's better to have one. You seem to be suggesting that types are absent from lisp, that's not the case. Common Lisp, Scheme, and Emacs Lisp all make use of types. They are, to a first approximation [0], all strongly typed and dynamically typed languages. Since you're not dogmatic about the where of it, try computing: (+ 2 'atom) In your favorite common lisp. It will result in an error, specifically a `SIMPLE-TYPE-ERROR`. You can also specify types in function declarations in Common Lisp: (defun double-integer (x) (declare (type integer x)) (* 2 x)) This will only accept integers now. Other types passed in as a parameter to `double-integer` will result in an error. You can apply this at any level once you start building up your own types as well (structs, classes, etc.). The benefit here is that you can leave your code wide-open to allow for many cases at some stages, while optimizing or constraining it in others. This malleability is fantastic in lisps. While I'm certainly a great fan and proponent of static type checking, the benefits of lisp's concepts (the malleability of its semantics and syntax), make it a great force-multiplier for component users. A great number of concepts become practically trivial when given the level of abstraction that lisps permit. A good type system can give you something akin to a calculus of types. A good functional language (here I'll include lisps even though many these days seem to discard them as such) give you a sort of calculus over computation. But the structure of lisp (particularly its homoiconic nature) gives you a calculus over your programs syntax and semantics. [0] The places where they may be considered weakly typed are places where it's somewhat "natural". Such as in Common Lisp where there's the numeric tower. Technically your number does stay a number, but it moves from an integer to, say, a rational when you perform a division by a non-divisor integer. It maintains the highest level of precision/accuracy possible. So `(/ 1 3)` doesn't become some 32-bit float version like `0.3333334`, but rather `1/3`, nor does it do the C thing and turn it into 0.

gue5t 10y ago
I don't see how "typed/untyped" is a meaningful distinction if you consider "dynamic types" to be types. If the only observable effect of the typechecker in a dynamically-typed language is a runtime error, how do we distinguish an arbitrary source of runtime errors (e.g. "throw" or "error" statements) from a dynamic typechecker? Obviously it isn't the presence of the word "type" in error messages, but what is it? In the presence of the metaprogramming you describe, we can't say it's down to whether checks are inserted automatically either, since non-type dynamic checks may also be inserted pervasively and automatically with metaprogramming. If Lisp is typed, what's an "untyped" language? One in which the user hasn't done metaprogramming to insert runtime checks? Or is the distinction just about whether it's the end programmer or the language implementor who does the metaprogramming? None of these seem like very useful distinctions. If it's lispy to actually do a separate typechecking pass, please forgive my ignorance.
- zem 10y ago
  i'd say an untyped (well, weakly typed; every language has some notion of types) language was one like C where you can construct a value of some type, and then treat the block of memory in which the physical representation of that value is stored as some other type. that said, eric lippert has a good blog post on [defining our terms more precisely before even asking the question](https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/ https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-...)
  - telotortium 10y ago
    There are in fact typeless languages that are neither statically nor dynamically typed, although they aren't particularly relevant nowadays -- BCPL, Forth, and assembly, among others. These languages have only words that hold integer values, with different operators treating the words as an integer, pointer, etc. Those who claim that only static types are worthy of the name "type" would probably consider both dynamically typed and typeless languages to be equally untyped -- dynamically typed languages just support richer semantics on their values, such as storing a "tag" (i.e., dynamic type) in each value.

taeric 10y ago

I am not aware of anyone that is against having a typechecking pass on the code that a LISP author writes. I fully acknowledge that my sphere of knowledge regarding who would be against it is pretty low, though. Do you have specific criticisms in mind? To me, most of the criticisms I see on LISP almost always come down to gripes about the parentheses. Usually it is said jokingly, but it is also the only criticism. Worse are when there are claims that there are no IDEs that can help with LISP. I don't even know what to say to that one. The birth of the modern IDE can easily be traced to predecessors of emacs. (Indeed, for most purposes today, the only difference between emacs and other IDEs is the language of extension. And... emacs being able to edit itself largely as it runs.) None of this is to say that a LISP is the panacea of development. I just don't think there is a panacea anymore.