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

21–29 of 29 posts

Re: Typed Lisp, a Primer (2019)

#21

Post by zelphirkalt »

smabie wrote: post #14
caltelt wrote: post #13

Earlier quoted context omitted.

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.

I've tried racket/typed before and my knowledge or experience with it might be outdated, but sometimes I just could not get it to agree with my code. I fix one typing warning or thing it cannot infer and another would pop up. I fix the other, then a third pops up. I try to fix the third one, but realize I cannot and need to go back to the original state. When such things do not happen, it is very cool though. The code behing typed racket for me seems so mind bogglingly complex, I did not dare to investigate further. It is a language composed of macros, which use rackets macrology stuff, which is already more complex than other Schemes'. That language can be used to design any type system as far as I read about it.

With my typing trouble I should have come to the user list and asked, but I dId not, frustrated and thinking I was too stupid to get it ^^'

I did once at least see a question on the mailing list, where the answer was, that typed racket could not do it, as in infer types, so it might not be perfect yet, or perhaps it did improve since then.

I wish more Schemes could just copy the typed part of typed racket, using that macro language, as in theory they should be able to represent it, but I guess the devil is in the detail and slightly different workings of macro facilities.

Re: Typed Lisp, a Primer (2019)

#22

Post by spellcard199 »

lsh wrote: post #19
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

In the page you linked it says the text you are quoting refers to the EPLv2, while Clojure is licensed under the EPLv1 [1]. It seems [2] they discussed changing Clojure's license to EPLv2, but decided not to.

[1] https://clojure.org/community/license [2] https://groups.google.com/forum/#!topic/clojure/uWAWm0xqrTI

Re: Typed Lisp, a Primer (2019)

#23

Post by kwhitefoot »

smabie wrote: post #14
caltelt wrote: post #13

Earlier quoted context omitted.

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.

Not always. Quite a lot of contracts can be statically checked. Unfortunately the only contract checker [1] I have experience with is too slow to be useful on source code that is itself large enough to be really useful.

And in C# at least contracts can be disabled for release builds so that the performance penalty is only inflicted on the developers.

[1] https://docs.microsoft.com/en-us/dotnet/framework/debug-trac...

Re: Typed Lisp, a Primer (2019)

#24

Post by [deleted] »

lmm wrote: post #17
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…

[deleted]

Re: Typed Lisp, a Primer (2019)

#25

Post by dustingetz »

lmm wrote: post #17
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…

The closest thing I can think of from the pure FP community that makes queries compose in a monad is Scala Slick, which adds an extraordinary amount of complexity to compose queries in exactly the wrong way. The whole FP community's thesis seems to be "take adderall and follow the math" and that thesis leads to Slick, not Datomic. (Both are early 2010s era so i think this is a fair comparison)

Re: Typed Lisp, a Primer (2019)

#26

Post by smabie »

zelphirkalt wrote: post #21
smabie wrote: post #14

Earlier quoted context omitted.

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.

I've tried racket/typed before and my knowledge or experience with it might be outdated, but sometimes I just could not get it to agree with my code. I fix one typing warning or thing it cannot infer and another would pop up. I fix the other, then a third pops up. I try to fix the third one, but realize I cannot and need to go back to the original state. When such things do not happen, it is very cool though. The cod…

Racket has a much more advanced macro system than scheme's traditional syntax-case.

Re: Typed Lisp, a Primer (2019)

#27

Post by lmm »

dustingetz wrote: post #25
lmm wrote: post #17

Earlier quoted context omitted.

> 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…

The closest thing I can think of from the pure FP community that makes queries compose in a monad is Scala Slick, which adds an extraordinary amount of complexity to compose queries in exactly the wrong way. The whole FP community's thesis seems to be "take adderall and follow the math" and that thesis leads to Slick, not Datomic. (Both are early 2010s era so i think this is a fair comparison)

Slick is for querying traditional SQL RDBMSes, so it has to deal with a massive impedance mismatch compared to a greenfield project. I'd look at something like Facebook's Haxl (for querying GraphQL) for a fairer comparison IMO.

Re: Typed Lisp, a Primer (2019)

#28

Post by zelphirkalt »

smabie wrote: post #26
zelphirkalt wrote: post #21

Earlier quoted context omitted.

I've tried racket/typed before and my knowledge or experience with it might be outdated, but sometimes I just could not get it to agree with my code. I fix one typing warning or thing it cannot infer and another would pop up. I fix the other, then a third pops up. I try to fix the third one, but realize I cannot and need to go back to the original state. When such things do not happen, it is very cool though. The cod…

Racket has a much more advanced macro system than scheme's traditional syntax-case.

Yes, it certainly has, but I think it's still based on that traditional syntax-case stuff. So in theory other Schemes could perhaps copy it, if anyone can get all the macrology behind it. Also in theory it should be possible to express all the advanced Racket stuff in syntax-case.

Do you think it is not possible to express these things in syntax-case? And if so, why?

Re: Typed Lisp, a Primer (2019)

#29

Post by [deleted] »

smabie wrote: post #14
caltelt wrote: post #13

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN