Login

Recent searches

No recent searches

Search options

Not available on mastodon.zunda.ninja.
mastodon.zunda.ninja is one of the many independent Mastodon servers you can use to participate in the fediverse.
Zundon is a single user instance as home of @zundan as well as a test bed for changes of the code.

Administered by:

Server stats:

1
active users

mastodon.zunda.ninja: AboutPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.0-alpha.4+bd80a62a-ruby-3.5.0

#haskell

0 posts0 participants0 posts today
Public
juxtapose

스태키지 큐레이션이 성공할 수 있었던 것은 하스켈이라는 언어와 생태계의 특징도 컸습니다.

https://hackers.pub/@xt/2025/stackage-why

Hackers' Pub · 스태키지 큐레이션이 성공할 수 있었던 것은 하스켈이라는 언어와 생태계의 특징도 컸습니다.인용: https://hackers.pub/@bgl/0195f0eb-88dd-77e3-a864-f0371e85b270 스태키지(Stackage)는 하스켈이 (의외로) 성공하여 해키지(Hackage)가 거대해지자, 그 거대함 때문에 발생하는 불편을 해소하는 한 방책으로 고안되었습니다. 그런데 당시에 해키지만큼 거대한 생태계를 갖추고 있으면서 동시에 "컴파일이 성공한다면 실행도 아마 성공할 것"이라는 훌륭한 속성을 갖는 언어는 달리 없었죠. 러스트가 있지 않으냐? 스태키지가 처음 나온 게 2012년입니다. 러스트는 아직 crates.io 도 자리잡기 전이었죠. (사실 이 시점의 러스트는 지금과는 언어 자체가 많이 다른 언어였고요.) 하스켈의 패키지 버저닝 정책에 따르면, 후방호환성 깨지는 변경은 반드시 메이저 버전을 올려야 하고, 마이너 버전만 올리는 변경은 후방호환성 유지될 때에만 가능합니다. 이런 정책 당연히 좋지만, 사람이 내용을 잘 숙지하고 지켜야 의미가 있습니다. 후방호환성을 깨면서 마이너 버전만 올리는 실수는 어떤 개발자든 할 수 있죠. 그런데 하스켈의 경우, 인간이 실수해도 기계가 잡아 줄 여지가 처음부터 매우 큰 언어이고, 예를 들어 어떤 함수가 핵미사일을 발사할 수 있는지 아닌지를 함수 실행 없이도 식별할 수 있는 언어라고들 하죠. 하스켈의 마지막 표준이 2010년에 나왔으니 2010년을 기준으로 하면, 당시 하스켈이 제공하는 "컴파일 시간 보장"의 범위는 그야말로 독보적이었습니다. (하스켈보다 더 강한 보장을 제공하는 언어들은 있었지만, 그만한 라이브러리 에코시스템이 없었고요.) 그래서 스태키지라는 모형이 의미가 있었습니다. A라는 패키지의 새 마이너 버전이 해키지에 올라오면, 스태키지에서 자동으로 가져갑니다. 스태키지는 같은 큐레이션에 포함된 다른 패키지들 중 A에 의존하는 패키지들을 추리고, 얘네한테 A의 새 버전을 먹여도 빌드가 잘 되는지 검사합니다. 이들 중 하나라도 깨지면? A 패키지는 해키지에서는 버전이 올랐으나, 스태키지에서는 버전이 오르지 않게 됩니다. 그리고 A 패키지의 제공자에게 자동으로 깃허브 멘션 알림이 갑니다! ("패키지 저자"와 "패키지를 스태키지에 제공하는 제공자"가 같은 사람이 아니어도 된다는 점도, 노동력의 효과적 분담에 한몫했습니다.) 이 모든 과정이 자동화되어 있는데, 이것만으로도 99.99%의 호환성 문제가 사라지고, 그러면서도 웬만한 라이브러리들은 충분히 최신 버전으로 쓸 수 있습니다. LTS와 나이틀리가 구분되어 있는 것도, LTS가 GHC 버전에 대응하여 여러 버전이 유지되는 것도, 실제 개발에서 아주 편리하고요. 스태키지가 개쩌는 부분은 "버저닝 정책에 완벽하게 부합하는데도 현실적으로 후방호환성 파괴를 일으키는" 변경점들도 잡아낸다는 것입니다. 아주 단순한 예시로 "많이 쓰이는 이름"이 있습니다. 예를 들어 어떤 라이브러리가 아주 널리 쓰이는데, 제공하는 네임 바인딩은 몇 개 안 되고, 그래서 대부분의 사용자가 그걸 그냥 전역 네임스페이스에 다 반입해서 쓴다고 칩시다. 어느 날 이 라이브러리가 process 라든지 f 같은 새 네임을 추가 제공하기 시작하면? 정책 규범에 따르면, 이것도 마이너 버전만 올려도 되는 변경점이 맞습니다. 하지만 현실에서는 많은 패키지들을 박살내겠죠. 언어를 막론하고 있을 수 있는 일인데, 이런 것들까지 스태키지에서 아주 높은 확률로 다 잡힙니다. 그리고... 이런 게 잘 된다는 것은 언어 그 자체의 특성도 있지만, 생태계 전체의 문화적인 특성도 있는데요. 하스켈도 라이브러리 제작자가 충분히 악독하다면, 컴파일러에게 안 잡히면서 인류문명멸망시키는 코드 변경을 얼마든지 슬쩍 끼워넣을 수 있습니다. 악의가 아니더라도 부주의로 후방호환성을 깰 수 있고요. 그런데 하스켈은 대부분의 라이브러리 설계자들이 "되도록 많은 것을 컴파일 시간에 잡고 싶다"라는 명확한 욕망으로 설계를 하는 경향이 뚜렷합니다. 그래서 호환성 문제는 웬만하면 스태키지 선에서 잡히고, 스태키지 큐레이션은 지난 10년 동안 실무상 아주 유용한 도구로 기능해 온 것이죠. 어지간하면 큐레이션만 잘 고르고 잘 갱신하면 되고, 종속성 목록에는 mypkg >= 2.1.1 && < 2.1.2 이런 거 하나도 관리 안 하고 그냥 mypkg 라고만 써도 된다는 것이, 솔직히 개짱편합니다. 다행히 지난 10년 동안 "문제의 소지는 컴파일 시간에 검출하는 게 좋다"라는 생각이 더 널리 받아들여져서, 다른 언어들도 이런 접근을 더 시도할 여지가 생긴 것 같군요.
#haskell
Continued thread
Public *
洪 民憙 (Hong Minhee)

またまた世界にモナドの解説が増えてしまいました。😅 今回はHaskellとOCamlのアプローチを比較して、型クラスがどれだけ重要な違いを齎すかに就いて書いてみました。JavaScriptのPromiseと比べる譬えは半分しか真実を語っていないんですよね…

https://hackers.pub/@hongminhee/2025/monads

hackers.pub · Monads: Beyond Simple Analogies—Reflections on Functional Programming ParadigmsWhile exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool. The Elegant Power of Monads in Haskell It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem. The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated: You can write code once that works across many contexts (Maybe, [], IO, State, etc.) Generic functions like sequence, mapM, and others become available across all monadic types The same patterns and mental models apply consistently across different computational contexts For example, a simple conditional function like this works beautifully in any monadic context: whenM :: Monad m => m Bool -> m () -> m () whenM condition action = do result <- condition if result then action else return () Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse. OCaml's Different Approach Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design: Structural Differences OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient: (* OCaml monad implementation requires more boilerplate *) module type MONAD = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end module OptionMonad : MONAD with type 'a t = 'a option = struct type 'a t = 'a option let return x = Some x let bind m f = match m with | None -> None | Some x -> f x end OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive: -- Haskell's elegant do notation userInfo = do name <- getLine age <- readLn return (name, age) Compared to the more verbose OCaml equivalent: let user_info = get_line >>= fun name -> read_ln >>= fun age -> return (name, age) The readability difference becomes even more pronounced in more complex monadic operations. Philosophical Differences Beyond syntax, the languages differ in their fundamental approach to effects: Haskell is purely functional, making monads essential for managing effects in a principled way OCaml permits direct side effects, often making monadic abstractions optional This allows OCaml programmers to write more direct code when appropriate: (* Direct style in OCaml *) let get_user_info () = print_string "Name: "; let name = read_line () in print_string "Age: "; let age = int_of_string (read_line ()) in (name, age) OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring: Direct use of option and result types Module-level abstractions through functors Continuation-passing style when needed While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides. Reflections on Language Design These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system. Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts. OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount. After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience. What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?
#関数型プログラミング#Haskell#またモナドの話か
Public
洪 民憙 (Hong Minhee)

Just what the internet needed: another attempt to explain #monads! 🙄 But this time I'm comparing #Haskell and #OCaml approaches to show why #typeclasses make all the difference. Turns out those JavaScript Promise analogies only tell half the story…

https://hackers.pub/@hongminhee/2025/monads

hackers.pub · Monads: Beyond Simple Analogies—Reflections on Functional Programming ParadigmsWhile exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool. The Elegant Power of Monads in Haskell It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem. The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated: You can write code once that works across many contexts (Maybe, [], IO, State, etc.) Generic functions like sequence, mapM, and others become available across all monadic types The same patterns and mental models apply consistently across different computational contexts For example, a simple conditional function like this works beautifully in any monadic context: whenM :: Monad m => m Bool -> m () -> m () whenM condition action = do result <- condition if result then action else return () Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse. OCaml's Different Approach Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design: Structural Differences OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient: (* OCaml monad implementation requires more boilerplate *) module type MONAD = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end module OptionMonad : MONAD with type 'a t = 'a option = struct type 'a t = 'a option let return x = Some x let bind m f = match m with | None -> None | Some x -> f x end OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive: -- Haskell's elegant do notation userInfo = do name <- getLine age <- readLn return (name, age) Compared to the more verbose OCaml equivalent: let user_info = get_line >>= fun name -> read_ln >>= fun age -> return (name, age) The readability difference becomes even more pronounced in more complex monadic operations. Philosophical Differences Beyond syntax, the languages differ in their fundamental approach to effects: Haskell is purely functional, making monads essential for managing effects in a principled way OCaml permits direct side effects, often making monadic abstractions optional This allows OCaml programmers to write more direct code when appropriate: (* Direct style in OCaml *) let get_user_info () = print_string "Name: "; let name = read_line () in print_string "Age: "; let age = int_of_string (read_line ()) in (name, age) OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring: Direct use of option and result types Module-level abstractions through functors Continuation-passing style when needed While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides. Reflections on Language Design These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system. Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts. OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount. After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience. What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?
Public
洪 民憙 (Hong Minhee)

Monads: Beyond Simple Analogies—Reflections on Functional Programming Paradigms

https://hackers.pub/@hongminhee/2025/monads

hackers.pub · Monads: Beyond Simple Analogies—Reflections on Functional Programming ParadigmsWhile exploring functional programming languages, I've been reflecting on how different communities approach similar concepts. One pattern that seems particularly fascinating is how Haskell and OCaml communities differ in their embrace of monads as an abstraction tool. The Elegant Power of Monads in Haskell It's common to hear monads explained through analogies to concepts like JavaScript's Promise or jQuery chains. While these comparisons provide an entry point, they might miss what makes monads truly beautiful and powerful in Haskell's ecosystem. The real strength appears to lie in the Monad typeclass itself. This elegant abstraction allows for creating generic functions and types that work with any type that shares the monad property. This seems to offer a profound unification of concepts that might initially appear unrelated: You can write code once that works across many contexts (Maybe, [], IO, State, etc.) Generic functions like sequence, mapM, and others become available across all monadic types The same patterns and mental models apply consistently across different computational contexts For example, a simple conditional function like this works beautifully in any monadic context: whenM :: Monad m => m Bool -> m () -> m () whenM condition action = do result <- condition if result then action else return () Whether dealing with potentially missing values, asynchronous operations, or state transformations, the same function can be employed without modification. There's something genuinely satisfying about this level of abstraction and reuse. OCaml's Different Approach Interestingly, the OCaml community seems less enthusiastic about monads as a primary abstraction tool. This might stem from several factors related to language design: Structural Differences OCaml lacks built-in typeclass support, relying instead on its module system and functors. While powerful in its own right, this approach might not make monad abstractions feel as natural or convenient: (* OCaml monad implementation requires more boilerplate *) module type MONAD = sig type 'a t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end module OptionMonad : MONAD with type 'a t = 'a option = struct type 'a t = 'a option let return x = Some x let bind m f = match m with | None -> None | Some x -> f x end OCaml also doesn't offer syntactic sugar like Haskell's do notation, which makes monadic code in Haskell considerably more readable and expressive: -- Haskell's elegant do notation userInfo = do name <- getLine age <- readLn return (name, age) Compared to the more verbose OCaml equivalent: let user_info = get_line >>= fun name -> read_ln >>= fun age -> return (name, age) The readability difference becomes even more pronounced in more complex monadic operations. Philosophical Differences Beyond syntax, the languages differ in their fundamental approach to effects: Haskell is purely functional, making monads essential for managing effects in a principled way OCaml permits direct side effects, often making monadic abstractions optional This allows OCaml programmers to write more direct code when appropriate: (* Direct style in OCaml *) let get_user_info () = print_string "Name: "; let name = read_line () in print_string "Age: "; let age = int_of_string (read_line ()) in (name, age) OCaml's approach might favor pragmatism and directness in many cases, with programmers often preferring: Direct use of option and result types Module-level abstractions through functors Continuation-passing style when needed While this directness can be beneficial for immediate readability, it might come at the cost of some of the elegant uniformity that Haskell's monadic approach provides. Reflections on Language Design These differences highlight how programming language design shapes the idioms and patterns that emerge within their communities. Neither approach is objectively superior—they represent different philosophies about abstraction, explicitness, and the role of the type system. Haskell's approach encourages a high level of abstraction and consistency across different computational contexts, which can feel particularly satisfying when working with complex, interconnected systems. There's something intellectually pleasing about solving a problem once and having that solution generalize across many contexts. OCaml often favors more direct solutions that might be easier to reason about locally, though potentially at the cost of less uniformity across the codebase. This approach has its own virtues, particularly for systems where immediate comprehensibility is paramount. After working with both paradigms, I find myself drawn to the consistent abstractions that Haskell's approach provides, while still appreciating the pragmatic clarity that OCaml can offer in certain situations. The typeclasses and syntactic support in Haskell seem to unlock a particularly elegant way of structuring code that, while perhaps requiring a steeper initial learning curve, offers a uniquely satisfying programming experience. What patterns have you noticed in how different programming language communities approach similar problems? And have you found yourself drawn to the elegant abstractions of Haskell or the pragmatic approach of OCaml?
#abstraction#typeclasses#monads
Public *
justsoup :asexual_flag:

Since I am the newest Trusted Contributor with #postmarketOS I thought I would give a little introductory post. :blob_derpy:

Heyo! My name is Aster (they/them) and I do stuff with #Linux! I am hard at work getting immutability up and running on pmOS with the help of the amazing work being done to port #systemd.

You may know me for my work on #Lomiri on pmOS, my favorite #MobileLinux desktop environment!

I also dabble in #Rustlang and a bit of #Haskell.

Excited to work with all of y'all!

Public *
HaskellOrg

Haskell.org and the Haskell Foundation Join Forces!

The members of the Haskell.org Committee (@haskell) and the directors of the @haskell_foundation are pleased to announce that we have joined forces into a single not-for-profit corporation.

Together we continue our common mission to advance functional programming and to advocate for the Haskell language, its ecosystem, and its community.

Read the full announcement at blog.haskell.org/haskell-found

The Haskell Programming Language's blogHaskell.org and the Haskell Foundation Join Forces | The Haskell Programming Language's blog
#Haskell
Public
HaskellOrg

Activities report: March–May 2024 by Well-Typed''s GHC Team well-typed.com/blog/2024/06/gh

Highlights:
• Releases of GHC and HLS
• A two-part series of blog posts on Choreographing a Dance with the GHC Specializer
• Work on improving the profiling and debugging experience
#Haskell

www.well-typed.comGHC activities report: March–May 2024Read about the latest GHC, Cabal and HLS development activity in this report from Well-Typed.
Public *
Clash Language

Time for my #introduction to the Fediverse! :masto_love:

Clash is an open source functional hardware description language built on #Haskell.
The Clash compiler allows you to use Haskell features like its strong and powerful typesystem as well as use existing Haskell code and libraries in your #FPGA and #ASIC designs! You can test your designs right inside the REPL, simulate it alongside other Haskell code or output #VHDL / #Verilog / #SystemVerilog code for synthesis.

Links in the profile ✨

ExploreLive feeds
About