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

Overloading the lambda abstraction in Haskell (2022)

acatalepsie.fr

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Overloading the lambda abstraction in Haskell (2022)

#11

Post by cryptonector »

_jackdk_ wrote: post #5

The linear functions/SMC work is really cool, but I am surprised to see the author calling it more mature than the compiling to CCCs work. The linear-smc library hasn't had an upload in a while, and it's currently missing any haddocks beyond the extracted type signatures. It's also a shame that it had to build its own typeclass for monoidal categories instead of using the one in https://hackage.haskell.org/package/ca…

> The linear functions/SMC work is really cool, but I am surprised to see the author calling it more mature than the compiling to CCCs work.

TFA doesn't call that more mature, just more workable and a thinner abstraction that presumably compiles to more efficient code than the proc-based alternative.

Re: Overloading the lambda abstraction in Haskell (2022)

#12

Post by cryptonector »

eru wrote: post #3
comex wrote: post #2

The fun thing is that this sounds like "just" a more type-safe version of the way DSLs are usually implemented in imperative languages, particularly scripting languages. In Python, if I have: def foo(x): return x**2 - 1 I can plug in a concrete argument: >>> foo(2) 3 But I can also plug in abstract values provided by some library where all operators are overloaded to return another AST node. For instance: >>> from z3…

You can do what you are describing in Haskell just fine. Eg you can implement 'overloaded' arithmetic operations for your custom data types. I think what's described in the article goes a lot further than this. (Though I'm not sure it's worth it.) Compare also https://okmij.org/ftp/tagless-final/

In Python you get run-time typing and dispatch. In Haskell you get static typing [and monomorphisation]. GP means that static typing is safer and faster.

Re: Overloading the lambda abstraction in Haskell (2022)

#13

Post by _jackdk_ »

cryptonector wrote: post #11
_jackdk_ wrote: post #5

The linear functions/SMC work is really cool, but I am surprised to see the author calling it more mature than the compiling to CCCs work. The linear-smc library hasn't had an upload in a while, and it's currently missing any haddocks beyond the extracted type signatures. It's also a shame that it had to build its own typeclass for monoidal categories instead of using the one in https://hackage.haskell.org/package/ca…

> The linear functions/SMC work is really cool, but I am surprised to see the author calling it more mature than the compiling to CCCs work. TFA doesn't call that more mature, just more workable and a thinner abstraction that presumably compiles to more efficient code than the proc-based alternative.

Fair. I think I mentally swapped adjectives while composing my response.

Re: Overloading the lambda abstraction in Haskell (2022)

#14

Post by cryptonector »

_jackdk_ wrote: post #13
cryptonector wrote: post #11

Earlier quoted context omitted.

> The linear functions/SMC work is really cool, but I am surprised to see the author calling it more mature than the compiling to CCCs work. TFA doesn't call that more mature, just more workable and a thinner abstraction that presumably compiles to more efficient code than the proc-based alternative.

Fair. I think I mentally swapped adjectives while composing my response.

Calling the proc stuff not mature might be totally fair when you consider that TFA got almost everything they wanted w/o it and the interface they got is more natural and the compiled code more efficient! Or it might just be fair to say that it is mature and just the wrong tool for TFA's task. I wouldn't know which is the case -- I'm not at the level of making my own categories.

Re: Overloading the lambda abstraction in Haskell (2022)

#15

Post by gsf_emergency »

Kinda tangential (since the linear vs Cartesian distinction wasn't made a big deal of here) but I liked the clarifying discussion (to layman me) of how "linear" and "affine" are related to the usage ones learns in uh middle school?

https://old.reddit.com/r/haskell/comments/txk3mn/why_are_the...

[And even the comment from the athletic river horse is thrilling to read]

Re: Overloading the lambda abstraction in Haskell (2022)

#16

Post by eru »

cryptonector wrote: post #12
eru wrote: post #3

Earlier quoted context omitted.

You can do what you are describing in Haskell just fine. Eg you can implement 'overloaded' arithmetic operations for your custom data types. I think what's described in the article goes a lot further than this. (Though I'm not sure it's worth it.) Compare also https://okmij.org/ftp/tagless-final/

In Python you get run-time typing and dispatch. In Haskell you get static typing [and monomorphisation]. GP means that static typing is safer and faster.

You can do the same AST trick in a type safe manner.

Re: Overloading the lambda abstraction in Haskell (2022)

#17

Post by eru »

comex wrote: post #7
eru wrote: post #3

Earlier quoted context omitted.

You can do what you are describing in Haskell just fine. Eg you can implement 'overloaded' arithmetic operations for your custom data types. I think what's described in the article goes a lot further than this. (Though I'm not sure it's worth it.) Compare also https://okmij.org/ftp/tagless-final/

I didn't mean to imply that you couldn't do the same in Haskell without the extra type-checking tricks in the article. I guess my main point is that the actual runtime semantics – like, if you take away the type checking, which functions are being called on what – are no different from what you'd see in Python. That differs from a lot of other Haskell techniques, where a direct port to Python would include tons of ne…

You can directly port the Python technique you mentioned without any extra closures.

(I mean not more than the normal amount of closures you'd get from straight-forward code that just calculates the answer as a number, instead of giving you the AST.)

Post reply on HN