News for hackers. Stuff that matters.
Re:Lisp and Haskell (2017) by crimsonalucard on Sunday July 15, 2018 @11:11AM (#17535554)
https://en.wikipedia.org/wiki/Church%E2%80%93Turing_thesis

It's lambda complete. Which has been famously proven to be the same as turing complete.

Also type checking is basically more or less putting restrictions on your code. If there is a language that doesn't have the syntax to compute certain things, how would restricting that language via type checking suddenly cause it to be able to compute everything and be turing complete? Makes no sense. To make a language change from not turing complete to turing complete you have to expand.. not restrict ... but expand it's computational ability. Again Type checking serves to restrict.

Type checking is essentially just pre runtime special syntax for:

  define add (x,y)
      if type(x) != 'int' or type(y) != 'int':
           throw TypeError
      return x+2
or in a lisp like functional language:

   (define (int) (x) 
      (if (equal? type(x) 'int') (x) (error 'Type Error'))

   (define add (x y))
      (+ int(x) int(y)))
It's not a big deal. I'm not sure what LINQ is, but you don't have to add a type checking system to a language to do type checking if you know what I mean.

He doesn't know what he's talking about.

Re:Lisp and Haskell (2017) by rs86 on Sunday July 15, 2018 @05:37PM (#17537235)
Type checking is much more than that. It is not the same as throwing exceptions when types don't match; it is about proving that a type checked program will never produce type errors.
Re:Lisp and Haskell (2017) by crimsonalucard on Sunday July 15, 2018 @10:46PM (#17538413)
You're right. I wanted to illustrate that type checking shouldn't be a factor in the the parents context as you can use code to explicitly type check or prove it.