Live data from Hacker News

Lisp and Haskell (2015)

markkarpov.com

11–20 of 173 posts

Re: Lisp and Haskell (2015)

#11
post #5

> if your code compiles, it probably works I'm always a little frustrated whenever I see this aphorism perpetuated since I think it gives the impression that a static type system is doing more than it is actually doing. In type systems that are used outside of academia, the main thing your static types are doing is checking whether the shapes of your data and functions all line up. With some small exceptions, that's…

If you use a powerful type system like Ocamls's, your can make many error states unrepresentable. This is basically impossible to do in Java.

Moreover, in OCaml it is idiomatic to use type inference everywhere except for interface files, so in practice you almost never annotate types.

Re: Lisp and Haskell (2015)

#12
post #5

> if your code compiles, it probably works I'm always a little frustrated whenever I see this aphorism perpetuated since I think it gives the impression that a static type system is doing more than it is actually doing. In type systems that are used outside of academia, the main thing your static types are doing is checking whether the shapes of your data and functions all line up. With some small exceptions, that's…

Type systems can encode proofs of properties that you want your data to have. For example, suppose you want to write a function that returns the first element of a list.

  head :: [a] -> a
This is the type of a function "head" that takes a list of values of some arbitrary type a, and returns an a.

if you feed this function an empty list, what will it do? You can reason from the type signature that the only thing it possibly can do is crash, since there's no way to produce a value of type a without knowing what a is in advance.

  head (h:_rest) = h
  head [] = error "Our function is badly behaved!"
To ensure that our function never crashes, we can encode the fact that our list is nonempty in a datatype.

  data Nonempty a = Nonempty a [a]
Ie, a nonempty list must contain a value of type a, and a (possible empty) list of as. Then instead of writing a function that crashes when it receives a nonempty list, we can write a function on nonempty lists that never crashes

  head :: Nonempty a -> a
  head (Nonempty x _rest) = x
What I'm getting at is that, yes, this is just the "shape" of our data. But you can encode more interesting and valuable properties in that shape than might be apparent at first. There are many other interesting examples of using types to ensure that properties that we want to hold for our values, do in fact hold.

Edit: I should probably add that "If it compiles it works" is absolutely not always true. It's more of a community in-joke than an actual belief. But it does turn out to be true surprisingly frequently.

Re: Lisp and Haskell (2015)

#13
post #9
post #3

Common Lisp could evolve into totally parenthesis-free language. By expanding the "powerfull and versatile" Loop-macro into full powerfullness and versatileness. Unfortunately two parenthessis needed, but you can redefine the language having those by default around every file.

Parentheses in Lisp is like significant whitespace in Python: A big stumbling block for people who don't use the language.

But for those who use the language one is a powerful feature and the other a minor annoyance.

Re: Lisp and Haskell (2015)

#14
post #12
post #5

> if your code compiles, it probably works I'm always a little frustrated whenever I see this aphorism perpetuated since I think it gives the impression that a static type system is doing more than it is actually doing. In type systems that are used outside of academia, the main thing your static types are doing is checking whether the shapes of your data and functions all line up. With some small exceptions, that's…

Type systems can encode proofs of properties that you want your data to have. For example, suppose you want to write a function that returns the first element of a list. head :: [a] -> a This is the type of a function "head" that takes a list of values of some arbitrary type a, and returns an a. if you feed this function an empty list, what will it do? You can reason from the type signature that the only thing it pos…

Sure, you can encode various properties in some languages, but it's not that common to actually do so.

Re: Lisp and Haskell (2015)

#15
post #14
post #12

Earlier quoted context omitted.

Type systems can encode proofs of properties that you want your data to have. For example, suppose you want to write a function that returns the first element of a list. head :: [a] -> a This is the type of a function "head" that takes a list of values of some arbitrary type a, and returns an a. if you feed this function an empty list, what will it do? You can reason from the type signature that the only thing it pos…

Sure, you can encode various properties in some languages, but it's not that common to actually do so.

In Haskell, it's both common and idiomatic. There's always a tradeoff between the usefulness of having static guarantees, and the complexity of the type system features that enable those guarantees. In some cases it's more trouble than it's worth to enforce certain static properties - you have to weigh the costs and benefits on a case by case basis. But it's nice to have the option, and Haskellers make use of it frequently.

Re: Lisp and Haskell (2015)

#16
post #3

Common Lisp could evolve into totally parenthesis-free language. By expanding the "powerfull and versatile" Loop-macro into full powerfullness and versatileness. Unfortunately two parenthessis needed, but you can redefine the language having those by default around every file.

It was originally supposed to, s-expressions (parenthesis) were supposed to be eventually replaced with m-expressions which were influenced by Algol and FORTRAN (the irony), but reviewers of the paper and the initial implementors of lisp preferred s-expressions, which stuck. That being said, having worked professionally in Lisp, the “un-lispy” macros like Loop are some of the worst parts of that language. They comple…

how would an idiomatic loop statement look like?

Re: Lisp and Haskell (2015)

#17
post #13
post #9

Earlier quoted context omitted.

Parentheses in Lisp is like significant whitespace in Python: A big stumbling block for people who don't use the language.

But for those who use the language one is a powerful feature and the other a minor annoyance.

I don't even remember when parens stopped being an issue.

I think my hate relationship toward algol syntax was so strong, sexp were an obvious answer from minute 0.

Re: Lisp and Haskell (2015)

#18
post #16

Earlier quoted context omitted.

It was originally supposed to, s-expressions (parenthesis) were supposed to be eventually replaced with m-expressions which were influenced by Algol and FORTRAN (the irony), but reviewers of the paper and the initial implementors of lisp preferred s-expressions, which stuck. That being said, having worked professionally in Lisp, the “un-lispy” macros like Loop are some of the worst parts of that language. They comple…

how would an idiomatic loop statement look like?

Like iterate (https://common-lisp.net/project/iterate/)

Re: Lisp and Haskell (2015)

#19
post #16

Earlier quoted context omitted.

It was originally supposed to, s-expressions (parenthesis) were supposed to be eventually replaced with m-expressions which were influenced by Algol and FORTRAN (the irony), but reviewers of the paper and the initial implementors of lisp preferred s-expressions, which stuck. That being said, having worked professionally in Lisp, the “un-lispy” macros like Loop are some of the worst parts of that language. They comple…

how would an idiomatic loop statement look like?

Iterate is more lispy, and for people that don't like macros transversing the loop body (because the errors you get when something like that goes wrong are hard to debug), something like foof-loop for scheme is pretty nice. I am writing this on neanderthal GPRS internet, so I leave finding documentation for these looping facilities an exercise for the reader.

Re: Lisp and Haskell (2015)

#20
post #16

Earlier quoted context omitted.

It was originally supposed to, s-expressions (parenthesis) were supposed to be eventually replaced with m-expressions which were influenced by Algol and FORTRAN (the irony), but reviewers of the paper and the initial implementors of lisp preferred s-expressions, which stuck. That being said, having worked professionally in Lisp, the “un-lispy” macros like Loop are some of the worst parts of that language. They comple…

how would an idiomatic loop statement look like?

[deleted]
Post reply on HN