Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typed Lisp, a Primer (2019)

alhassy.github.io

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Typed Lisp, a Primer (2019)

#11

Post by smabie »

dustingetz wrote: post #3

Clojure's take on types is not so much that types are bad at micro scale, it's that focusing on proving referential transparency above all else leads to cultural problems at the macro scale. For example, the Datomic Peer API is the most elegant and ergonomic database API I've ever seen. Queries compose as functions under the illusion that the database is a local data structure and this results in a beautiful informat…

I've personally never thought the cost of tracking mutation and IO in a type system is particularly worth the complexity and hassle. But for everything else, an advanced Hindley Milner derived type system is absolutely, 100% worth it.

I do think there might be some middle ground where you can annotate non pure functions in order to help the compiler with aggressive optimization.

Re: Typed Lisp, a Primer (2019)

#12

Post by spellcard199 »

smabie wrote: post #10
spellcard199 wrote: post #9

After trying Typed Clojure, liking it, but giving it up because of Clojure's GPL-incompatible license, I got interested in Kawa Scheme because it has some rudimentary form of type checking. For example, this produces warnings: (define (f1 x::String y::String) (x:concat y)) (define (f2) (f1 3 3)) ;; /dev/tty:3:19: warning - type integer is incompatible with required type java.lang.String ;; /dev/tty:3:21: warning - ty…

Typed Racket tends to work pretty well, and you can gradually add types to dynamic code. Probably the most mature type system of any Lisp. And if you feel like types are too constraining for a part of your code, you can just leave them out. You get the best of both worlds!

If Racket had packages functionally equivalent to the ones on the JVM that I can't live without (Selenium, JGraphX, ...) I would start learning it right away. However sticking to the JVM and Kawa I get a vaguely similar typed/untyped experience except for the un-lispyness of Java. Usually when I write a script I make a new Java project that also pulls the dependencies and then embed Kawa (or jshell/ammonite jupyter server) for interactivity. Between the pom.xml and the code itself embedding Kawa (or jshell/ammonite) in a java program is like 10 lines at most.

Re: Typed Lisp, a Primer (2019)

#13

Post by caltelt »

smabie wrote: post #10
spellcard199 wrote: post #9

After trying Typed Clojure, liking it, but giving it up because of Clojure's GPL-incompatible license, I got interested in Kawa Scheme because it has some rudimentary form of type checking. For example, this produces warnings: (define (f1 x::String y::String) (x:concat y)) (define (f2) (f1 3 3)) ;; /dev/tty:3:19: warning - type integer is incompatible with required type java.lang.String ;; /dev/tty:3:21: warning - ty…

Typed Racket tends to work pretty well, and you can gradually add types to dynamic code. Probably the most mature type system of any Lisp. And if you feel like types are too constraining for a part of your code, you can just leave them out. You get the best of both worlds!

I was really excited when I started using racket that I could switch to static typing when I wanted it. However after trying out contract's, I must say I'm quite a fan of them as an alternative. Sure, you lose out on static, compile time checking, but honestly, I haven't missed it. And it's _even more_ seamlessly integrated into un-contracted code. You can express more interesting things and complex relationships between parameters using the ->i contract than any type system I know of will allow. There's some limitations, but between it and unit testing, I've been having a blast.

Re: Typed Lisp, a Primer (2019)

#14

Post by smabie »

caltelt wrote: post #13
smabie wrote: post #10

Earlier quoted context omitted.

Typed Racket tends to work pretty well, and you can gradually add types to dynamic code. Probably the most mature type system of any Lisp. And if you feel like types are too constraining for a part of your code, you can just leave them out. You get the best of both worlds!

I was really excited when I started using racket that I could switch to static typing when I wanted it. However after trying out contract's, I must say I'm quite a fan of them as an alternative. Sure, you lose out on static, compile time checking, but honestly, I haven't missed it. And it's _even more_ seamlessly integrated into un-contracted code. You can express more interesting things and complex relationships bet…

Contracts incur absolutely massive performance penalties. Sparingly used, they can provide value though.

There's no reason why you can't have types and contracts though. I personally can't live without compile time guarantees.

Re: Typed Lisp, a Primer (2019)

#15

Post by swatson741 »

This is a good article but, the author doesn't show the limitations of type systems. If our world is small enough types can be very useful. There are many situations where we want to work in a small world.

>type's have always been there

I've seen this argument before and, I disagree with this statement as presented. The implication is that there is a type system underlying a language's semantics. But, really that's not true. It's more correct to say that objects have always been there.

Re: Typed Lisp, a Primer (2019)

#17

Post by lmm »

dustingetz wrote: post #3

Clojure's take on types is not so much that types are bad at micro scale, it's that focusing on proving referential transparency above all else leads to cultural problems at the macro scale. For example, the Datomic Peer API is the most elegant and ergonomic database API I've ever seen. Queries compose as functions under the illusion that the database is a local data structure and this results in a beautiful informat…

> But if you tried to put IO types on Datomic you find that it spews IO everywhere.

So you put it in a monad and get on with your life? It's like one or two extra characters on your operators just to mark out where you're doing effect composition, and the benefit is that you can immediately see where all the effects are happening. Code is read more than it's written, so it's a really good tradeoff.

> And yet it works incredibly well with good enough performance for a wide band of applications!

How big is it, and how many people work on it? IME not tracking effects works great as long as everyone working on the codebase can keep the whole thing in their head. But you hit a wall (for me it's about 20kloc - I'm sure smarter people can push it a bit further, but everyone will have a limit eventually) once you can no longer reason about how one part affects every other part, and at that point a little helping hand from the compiler helps a lot.

Re: Typed Lisp, a Primer (2019)

#18

Post by smabie »

spellcard199 wrote: post #12
smabie wrote: post #10

Earlier quoted context omitted.

Typed Racket tends to work pretty well, and you can gradually add types to dynamic code. Probably the most mature type system of any Lisp. And if you feel like types are too constraining for a part of your code, you can just leave them out. You get the best of both worlds!

If Racket had packages functionally equivalent to the ones on the JVM that I can't live without (Selenium, JGraphX, ...) I would start learning it right away. However sticking to the JVM and Kawa I get a vaguely similar typed/untyped experience except for the un-lispyness of Java. Usually when I write a script I make a new Java project that also pulls the dependencies and then embed Kawa (or jshell/ammonite jupyter s…

Racket's graph library can do everything jgraphx can do, and much more elegantly. There's also this (and others) for selenium:

http://planet.racket-lang.org/package-source/untyped/seleniu...

Re: Typed Lisp, a Primer (2019)

#19

Post by lsh »

spellcard199 wrote: post #9

After trying Typed Clojure, liking it, but giving it up because of Clojure's GPL-incompatible license, I got interested in Kawa Scheme because it has some rudimentary form of type checking. For example, this produces warnings: (define (f1 x::String y::String) (x:concat y)) (define (f2) (f1 3 3)) ;; /dev/tty:3:19: warning - type integer is incompatible with required type java.lang.String ;; /dev/tty:3:21: warning - ty…

> because of Clojure's GPL-incompatible license

"GPL compatible: Optionally but not by default[3]"

- https://en.wikipedia.org/wiki/Eclipse_Public_License

Re: Typed Lisp, a Primer (2019)

#20

Post by spellcard199 »

smabie wrote: post #18
spellcard199 wrote: post #12

Earlier quoted context omitted.

If Racket had packages functionally equivalent to the ones on the JVM that I can't live without (Selenium, JGraphX, ...) I would start learning it right away. However sticking to the JVM and Kawa I get a vaguely similar typed/untyped experience except for the un-lispyness of Java. Usually when I write a script I make a new Java project that also pulls the dependencies and then embed Kawa (or jshell/ammonite jupyter s…

Racket's graph library can do everything jgraphx can do, and much more elegantly. There's also this (and others) for selenium: http://planet.racket-lang.org/package-source/untyped/seleniu...

> Racket's graph library can do everything jgraphx can do

What I need is to make a diagram from a file produced by diagrams.net without me writing the parser (JGraphX can already parse diagrams.net's xml), show me a window where I can select and adjust elements by hand, transform the diagram programmatically in a language where I have both type-checking and good completion for (eg) the selected objects, export back to diagrams.net's format. Occasionally I want to extend the already interactive window myself. I also evaluated Typed Racket before picking Kawa and the JVM, but JGraphX was just a more appropriate tool for this specific workflow.

> There's also this (and others) for selenium

I remember finding that, and I counted it as a subset of Selenium's functionality rather than equivalent.

I agree on the sentiment on Racket though, as for the language itself Java was a second choice for me. What eventually convinced me to invest in it was that I could always call what I had already written from other languages on the JVM (mainly Scala and Kawa, which also happen to have decent repls) without writing any glue code.

Post reply on HN