> Why implement these projects in Algebraic Racket? Good question -- not so easy to answer cleanly. Here's a smattering.
I created Algebraic Racket to make functional meta-programming in Racket more enjoyable. My talk will demonstrate what I mean by that and why it matters in practice. The packages are also a field test for Algebraic Racket's extended feature set. The diagrams library uses classes for ad hoc polymorphism. The visualization and audio libraries use algebraic data for inter-process messaging. Algebraic Racket is designed to accommodate my programming style: mostly-pure, compositional, driven by structural pattern matching at multiple run-time phases. I like match and syntax-parse, but I love Algebraic Racket. (Don't tell Matthias I said this, but sometimes point-free style is more compact and easier to read. This happens a lot more often in Algebraic Racket, and it leads to good things.) Algebraic Racket is mostly just extra syntax for the Racket base. Replacing #lang racket/base with #lang algebraic/racket/base should not change what a program does or slow it down much, and modules in one language can be used in the other. Pattern-based variants of core Racket syntactic forms (e.g, let, case, define) can be imported, but that breaks drop-in compatibility. Eric -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAORuSUydHGPBd7bpKEtnqaL2-H5hCYUvysyn2tQ1-ai5JSejfA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
