From julian at getcontented.com.au Mon Dec 2 09:16:33 2024 From: julian at getcontented.com.au (julian getcontented.com.au) Date: Mon, 2 Dec 2024 09:16:33 +0000 Subject: [Haskell-cafe] Files and Modules In-Reply-To: References: Message-ID: <127898BC-3D7A-48E4-9FB1-F7874EC51D7A@getcontented.com.au> In a recent project that compiles Haskell source from data (ie of type Text from the module Data.Text), it would be useful to be able to decouple the dependency between GHC’s notion of where modules are and the file system. This doesn’t seem to be programmatically controllable. How tenable is this? Would it be useful for anyone else to have compilation itself be more first class in the language? If I think about languages such as LISP/Racket/Clojure, there’s a certain flexibility there that Haskell lacks, but it’s not apparent why, other than historical reasons? Would this imply changing compiling and linking into a different Monad than IO? At the moment to compile some source that exists in Text, my system has to write a bunch of temp files including the Text that contains the main module, and then put other modules in directories named a certain way, run the compiler across them via some exec command to call GHC or stack externally, then read the resulting executable back off disk to store it in its final destination. It might be useful to be able to do this from within Haskell code directly, partly similarly to how the hint library works. Though, in this case it would almost certainly also require being able to have two versions of GHC loaded at once, which would also imply being able to simultaneously have multiple or different versions of libraries loaded at once, too, and possibly also just from data, ie not from disk. It feels like a massive, massive project at that point, though, like we’d be putting an entire dependency system into a first-class programmable context. I’m still interested in what folks think about these ideas, though, event though we this may never eventuate. Does it seem to anyone else like abstracting the library and module-access capabilities of compilation so that it’s polymorphic over where it gets its data from might be useful? Is this just ridiculous? Does this step into Backpack's territory? From memory, the Haskell report doesn’t specify that modules necessarily need to be tied to the file system, but I think GHC imposes one file per module and that it be one the FS. Julian From allbery.b at gmail.com Mon Dec 2 09:36:49 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 2 Dec 2024 04:36:49 -0500 Subject: [Haskell-cafe] Files and Modules In-Reply-To: <127898BC-3D7A-48E4-9FB1-F7874EC51D7A@getcontented.com.au> References: <127898BC-3D7A-48E4-9FB1-F7874EC51D7A@getcontented.com.au> Message-ID: As long as we're using system tools for assembling and linking, we must abide by their constraints. Not using them isn't really viable; linking in particular is a nightmare. The bytecode interpreter has a partial linker because it can't use the system one, and it's easily the nastiest part of ghc. It's also completely nonportable, by definition: every target has its own notion of what relocations are available and how they work. On Mon, Dec 2, 2024 at 4:16 AM julian getcontented.com.au < julian at getcontented.com.au> wrote: > In a recent project that compiles Haskell source from data (ie of type > Text from the module Data.Text), it would be useful to be able to decouple > the dependency between GHC’s notion of where modules are and the file > system. This doesn’t seem to be programmatically controllable. > > How tenable is this? Would it be useful for anyone else to have > compilation itself be more first class in the language? If I think about > languages such as LISP/Racket/Clojure, there’s a certain flexibility there > that Haskell lacks, but it’s not apparent why, other than historical > reasons? Would this imply changing compiling and linking into a different > Monad than IO? > > At the moment to compile some source that exists in Text, my system has to > write a bunch of temp files including the Text that contains the main > module, and then put other modules in directories named a certain way, run > the compiler across them via some exec command to call GHC or stack > externally, then read the resulting executable back off disk to store it in > its final destination. > > It might be useful to be able to do this from within Haskell code > directly, partly similarly to how the hint library works. Though, in this > case it would almost certainly also require being able to have two versions > of GHC loaded at once, which would also imply being able to simultaneously > have multiple or different versions of libraries loaded at once, too, and > possibly also just from data, ie not from disk. It feels like a massive, > massive project at that point, though, like we’d be putting an entire > dependency system into a first-class programmable context. I’m still > interested in what folks think about these ideas, though, event though we > this may never eventuate. > > Does it seem to anyone else like abstracting the library and module-access > capabilities of compilation so that it’s polymorphic over where it gets its > data from might be useful? Is this just ridiculous? Does this step into > Backpack's territory? From memory, the Haskell report doesn’t specify that > modules necessarily need to be tied to the file system, but I think GHC > imposes one file per module and that it be one the FS. > > Julian > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Mon Dec 2 09:42:28 2024 From: hecate at glitchbra.in (=?UTF-8?Q?H=C3=A9cate?=) Date: Mon, 2 Dec 2024 10:42:28 +0100 Subject: [Haskell-cafe] Files and Modules In-Reply-To: References: <127898BC-3D7A-48E4-9FB1-F7874EC51D7A@getcontented.com.au> Message-ID: <0d0d987e-5614-4026-897b-83559e240a4b@glitchbra.in> One compromise GHC could make would be abstract the notion of module from the Haskell source (multiple modules per file, no file involved at all), but ultimately as Brandon says, the file system has to get involved for the linker, so the concept of a module needs to remain compatible with the action of writing it as a file. Le 02/12/2024 à 10:36, Brandon Allbery a écrit : > As long as we're using system tools for assembling and linking, we > must abide by their constraints. Not using them isn't really viable; > linking in particular is a nightmare. The bytecode interpreter has a > partial linker because it can't use the system one, and it's easily > the nastiest part of ghc. It's also completely nonportable, by > definition: every target has its own notion of what relocations are > available and how they work. > > On Mon, Dec 2, 2024 at 4:16 AM julian getcontented.com.au > wrote: > > In a recent project that compiles Haskell source from data (ie of > type Text from the module Data.Text), it would be useful to be > able to decouple the dependency between GHC’s notion of where > modules are and the file system. This doesn’t seem to be > programmatically controllable. > > How tenable is this? Would it be useful for anyone else to have > compilation itself be more first class in the language? If I think > about languages such as LISP/Racket/Clojure, there’s a certain > flexibility there that Haskell lacks, but it’s not apparent why, > other than historical reasons? Would this imply changing compiling > and linking into a different Monad than IO? > > At the moment to compile some source that exists in Text, my > system has to write a bunch of temp files including the Text that > contains the main module, and then put other modules in > directories named a certain way, run the compiler across them via > some exec command to call GHC or stack externally, then read the > resulting executable back off disk to store it in its final > destination. > > It might be useful to be able to do this from within Haskell code > directly, partly similarly to how the hint library works. Though, > in this case it would almost certainly also require being able to > have two versions of GHC loaded at once, which would also imply > being able to simultaneously have multiple or different versions > of libraries loaded at once, too, and possibly also just from > data, ie not from disk. It feels like a massive, massive project > at that point, though, like we’d be putting an entire dependency > system into a first-class programmable context. I’m still > interested in what folks think about these ideas, though, event > though we this may never eventuate. > > Does it seem to anyone else like abstracting the library and > module-access capabilities of compilation so that it’s polymorphic > over where it gets its data from might be useful? Is this just > ridiculous? Does this step into Backpack's territory? From memory, > the Haskell report doesn’t specify that modules necessarily need > to be tied to the file system, but I think GHC imposes one file > per module and that it be one the FS. > > Julian > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at haskus.fr Mon Dec 2 12:31:55 2024 From: sylvain at haskus.fr (Sylvain Henry) Date: Mon, 2 Dec 2024 13:31:55 +0100 Subject: [Haskell-cafe] Files and Modules In-Reply-To: <127898BC-3D7A-48E4-9FB1-F7874EC51D7A@getcontented.com.au> References: <127898BC-3D7A-48E4-9FB1-F7874EC51D7A@getcontented.com.au> Message-ID: It's not ridiculous. I would also like the GHC API to abstract over the file system so that I can store modules in a DB. It would require quite a lot of refactoring though... Sylvain On 02/12/2024 10:16, julian getcontented.com.au wrote: > In a recent project that compiles Haskell source from data (ie of type Text from the module Data.Text), it would be useful to be able to decouple the dependency between GHC’s notion of where modules are and the file system. This doesn’t seem to be programmatically controllable. > > How tenable is this? Would it be useful for anyone else to have compilation itself be more first class in the language? If I think about languages such as LISP/Racket/Clojure, there’s a certain flexibility there that Haskell lacks, but it’s not apparent why, other than historical reasons? Would this imply changing compiling and linking into a different Monad than IO? > > At the moment to compile some source that exists in Text, my system has to write a bunch of temp files including the Text that contains the main module, and then put other modules in directories named a certain way, run the compiler across them via some exec command to call GHC or stack externally, then read the resulting executable back off disk to store it in its final destination. > > It might be useful to be able to do this from within Haskell code directly, partly similarly to how the hint library works. Though, in this case it would almost certainly also require being able to have two versions of GHC loaded at once, which would also imply being able to simultaneously have multiple or different versions of libraries loaded at once, too, and possibly also just from data, ie not from disk. It feels like a massive, massive project at that point, though, like we’d be putting an entire dependency system into a first-class programmable context. I’m still interested in what folks think about these ideas, though, event though we this may never eventuate. > > Does it seem to anyone else like abstracting the library and module-access capabilities of compilation so that it’s polymorphic over where it gets its data from might be useful? Is this just ridiculous? Does this step into Backpack's territory? From memory, the Haskell report doesn’t specify that modules necessarily need to be tied to the file system, but I think GHC imposes one file per module and that it be one the FS. > > Julian > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jo at durchholz.org Mon Dec 2 13:24:48 2024 From: jo at durchholz.org (jo at durchholz.org) Date: Mon, 2 Dec 2024 14:24:48 +0100 Subject: [Haskell-cafe] Files and Modules In-Reply-To: <127898BC-3D7A-48E4-9FB1-F7874EC51D7A@getcontented.com.au> References: <127898BC-3D7A-48E4-9FB1-F7874EC51D7A@getcontented.com.au> Message-ID: <67193f20-46ae-4523-9ec5-3c9625ee8788@durchholz.org> On 02.12.24 10:16, julian getcontented.com.au wrote: > In a recent project that compiles Haskell source from data (ie of type Text from the module Data.Text), it would be useful to be able to decouple the dependency between GHC’s notion of where modules are and the file system. This doesn’t seem to be programmatically controllable. > > How tenable is this? I can report how this works in the Java world, where this exists. TL;DR: The real issues are programmer workflows, tool integration, and optimization, not so much semantic issues. The mechanism itself is a non-problem there, as it was designed right into the ecosystem right from the start. Even there, it came with a number of significant downsides. It places pretty hefty constraints on global optimizations, inlining in particular: You can't usefully inline if you don't know if a call will be polymorphic because somebody added a subclass. You either have to prevent subclassing, or forfeit cross-module inlining, or keep track of dependencies so you can undo inlining whenever assumptions about polymorphism are broken by new code. Now Haskell's polymorphism is different from Java's, but I'd expect similar issues. In the Java world, this meant integrating the optimization phase into the runtime system, increasing the code and memory footprint of the JVM, and with a heavy runtime code during start-up when the bulk of optimisations is run. The Java world is currently swinging from dynamic code loading to static precompilation (look for references to GraalVM is you want to know more); however, this burdens the application programmer with defining the dynamic loading behaviour of the class system, even though that's done in the build specifications and not in the code itself (which comes with its own set of problems, such as having to cross-reference code and build specs when reasoning about code, though that affects only those who want to control compiler behaviour tightly). > Would it be useful for anyone else to have compilation itself be > more first class in the language? If I think about languages such as > LISP/Racket/Clojure, there’s a certain flexibility there that > Haskell lacks, but it’s not apparent why, other than historical > reasons? These languages are extremely hard to optimize, so at least the GHC people won't be able to follow that route. If that's fine, then your suggestions seems doable. > Would this imply changing compiling and linking into a different > Monad than IO? I can't say with confidence but I wouldn't expect that to be an issue. A compiler typically maps special operations like this to machine code or possibly intermediate code, as part of the optimization phase. The selection of IO mechanism is more a programmer-facing issue. The exact conditions under which what optimization is applicable does depend on the details of the IO mechanism's semantics, so I guess nobody will want to even touch that part of the mechanism, and say that IO is fine; they'd rather modify other systems to make IO work, if there are problems with it. > At the moment to compile some source that exists in Text, my system > has to write a bunch of temp files including the Text that contains > the main module, and then put other modules in directories named a > certain way, run the compiler across them via some exec command to > call GHC or stack externally, then read the resulting executable > back off disk to store it in its final destination. And now we're in the area of application programmer downsides. If you make these files temporary and unavailable to the programmer for debugging, stack traces and such become meaningless. You'll have to add tooling for that. I.e. code that takes the stack traces and maps them back to the specification language that you're generating code from. You'll have to consider the messages from that stack trace low-level, and add a translation step that transforms the low-level semantics to what the programmer specified, i.e. you have to know exactly what Haskell code patterns can exist, have a full list of possible errors, and code that does the translation. Similar considerations apply to debuggers, profiling tools and whatever other programming tools with a connection to code lines have. That's a pretty tall order, not only because of the translation step, but because you have to integrate that translation with a multitude of tools, some (most?) of them under active development, i.e. moving targets. It's a pretty tall order. Code generators like yours typically use another technique: Generate the code into a directory that's not under version control but part of the module paths of all tools. Generate code with comments that refer back to the original specification, utilizing the programmer's knowledge to do the backwards translation. In the Java world, this kind of stuff was recently integrated into the toolchains. There's a mechanism called an "annotation processor" (please ignore the "annotation" part, it's just the trigger for the mechanism) which will be run by the Java compiler and generate the code into a generated-code subdirectory; the toolchains know to include this directory into their module paths, since pretty recently even by default. > It might be useful to be able to do this from within Haskell code > directly, partly similarly to how the hint library works. Though, in > this case it would almost certainly also require being able to have > two versions of GHC loaded at once, which would also imply being > able to simultaneously have multiple or different versions of > libraries loaded at once, too, and possibly also just from data, ie > not from disk. It feels like a massive, massive project at that > point, though, like we’d be putting an entire dependency system into > a first-class programmable context. I’m still interested in what > folks think about these ideas, though, event though we this may > never eventuate. It will be less massive if you start with integrating code generation into the toolchains I think. But yeah, I think it's still a massive project. > Does it seem to anyone else like abstracting the library and module- > access capabilities of compilation so that it’s polymorphic over > where it gets its data from might be useful? You can't usefully work with generated code unless you automate the translation of messages from the Haskell level to the new combined Haskell+specifications language. I am not sure that such a thing is even realistically doable; even the Java ecosystem has been shying away from that approach, despite having much more manpower than Haskell's, and despite having a JVM that was designed and built for integrating anonymous code. E.g. I hit bugs^W unexpected behaviour in Hibernate-generated code that I couldn't diagnose. The behaviour remained a mystery, the code generation was too deeply hidden below layers of polymorphic library code, so I started the bytecode disassembler and found, to my incredulous amazement, that Hibernate would add attributes, a behaviour that Hibernate did not document ever; I had accidentally defined an attribute with a conflicting name, so Hibernate would interfere with application logic and vice versa. Sorry for the wall of text, but it's a pretty big topic. HTH Jo From julian at getcontented.com.au Mon Dec 2 14:22:03 2024 From: julian at getcontented.com.au (julian getcontented.com.au) Date: Mon, 2 Dec 2024 14:22:03 +0000 Subject: [Haskell-cafe] Files and Modules In-Reply-To: References: Message-ID: Thanks. Understood about the Linker. I was thinking the linking could be some final phase that was separated out in such a way that would still be compatible with the file system (a HasLinker constraint? ;-) j/k). But to go back to what you were saying, if we had the ability to decouple modules from files it would mean I could set up a notion of dependency between the modules that I have stored in Texts in such a way that I wouldn’t need to repeat code between the Texts when I want to share code as I’m compiling chunks of it. At the moment I try hard to keep the set of common items shared between all the code I have because it makes it simpler to manage and keeps duplication low, and it also means the call to stack that I have only has to include a small set of packages and can be common between all the combined sets of code I have. On 2 Dec 2024, at 11:00 PM, haskell-cafe-request at haskell.org wrote: One compromise GHC could make would be abstract the notion of module from the Haskell source (multiple modules per file, no file involved at all), but ultimately as Brandon says, the file system has to get involved for the linker, so the concept of a module needs to remain compatible with the action of writing it as a file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Dec 2 15:10:36 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 2 Dec 2024 10:10:36 -0500 Subject: [Haskell-cafe] Files and Modules In-Reply-To: References: Message-ID: On Mon, Dec 2, 2024 at 9:22 AM julian getcontented.com.au < julian at getcontented.com.au> wrote: > But to go back to what you were saying, if we had the ability to decouple > modules from files it would mean I could set up a notion of dependency > between the modules that I have stored in Texts in such a way that I > wouldn’t need to repeat code between the Texts when I want to share code as > I’m compiling chunks of it. At the moment I try hard to keep the set of > common items shared between all the code I have because it makes it simpler > to manage and keeps duplication low, and it also means the call to stack > that I have only has to include a small set of packages and can be common > between all the combined sets of code I have. > I wonder if an alternative would be a rope type with shareable strands. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian at getcontented.com.au Tue Dec 3 00:50:22 2024 From: julian at getcontented.com.au (julian getcontented.com.au) Date: Tue, 3 Dec 2024 00:50:22 +0000 Subject: [Haskell-cafe] Files and Modules In-Reply-To: References: Message-ID: <61FF71EC-F3EE-46FD-9B92-D67503128EB5@getcontented.com.au> If I understand your comment properly, using ropes wouldn’t help much because the duplication is duplication in individual Texts (ie think of it as manually inlining a function definition because importing is too much hassle), not any issue with duplicated fragments of Texts taking up too much space in memory when loaded. (They sit “at rest” in S3 at the moment, but really they can be thought of as just IO Text values) On 3 Dec 2024, at 2:10 AM, Brandon Allbery wrote: On Mon, Dec 2, 2024 at 9:22 AM julian getcontented.com.au > wrote: But to go back to what you were saying, if we had the ability to decouple modules from files it would mean I could set up a notion of dependency between the modules that I have stored in Texts in such a way that I wouldn’t need to repeat code between the Texts when I want to share code as I’m compiling chunks of it. At the moment I try hard to keep the set of common items shared between all the code I have because it makes it simpler to manage and keeps duplication low, and it also means the call to stack that I have only has to include a small set of packages and can be common between all the combined sets of code I have. I wonder if an alternative would be a rope type with shareable strands. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Dec 3 00:52:22 2024 From: ben at well-typed.com (Ben Gamari) Date: Mon, 02 Dec 2024 19:52:22 -0500 Subject: [Haskell-cafe] GHC 9.8.4 is now available Message-ID: <87mshd611p.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of GHC 9.8.4. Binary distributions, source distributions, and documentation are available on the [release] page. This release is a small release fixing a few issues noted in 9.8.3, including: * Update the `filepath` submodule to avoid a misbehavior of `splitFileName` under Windows. * Update the `unix` submodule to fix a compilation issue on `musl` platforms * Fix a potential source of miscompilation when building large projects on 32-bit platforms * Fix unsound optimisation of `prompt#` uses A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling! - Ben [release]: https://www.haskell.org/ghc/download_ghc_9_8_4.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.4/docs/users_guide/9.8.4-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From Graham.Hutton at nottingham.ac.uk Tue Dec 3 14:00:39 2024 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 3 Dec 2024 14:00:39 +0000 Subject: [Haskell-cafe] 10 PhD studentships in Nottingham Message-ID: <53716F5E-399D-45B6-A957-0C12288A98E7@nottingham.ac.uk> Dear all, The School of Computer Science at the University of Nottingham in the UK is seeking applications for 10 fully-funded PhD studentships: https://tinyurl.com/ten-phds-2025 Applicants in the area of the Functional Programming Lab (tinyurl.com/fp-notts) are strongly encouraged! If you are interested in applying, please contact a potential supervisor as soon as possible; the application deadline is 6th April 2025: Thorsten Altenkirch - constructive logic, proof assistants, homotopy type theory, category theory, lambda calculus. Ulrik Buchholtz - homotopy type theory, synthetic homotopy theory, proof assistants, constructive mathematics, and related topics. Graham Hutton - not seeking a new student this year, but these notes on the process may be useful: tinyurl.com/phd-notes Nicolai Kraus - not seeking a student through this scheme, but has two other PhD positions available: tinyurl.com/kraus-phds Dan Marsden - category theory, logic, finite model theory, diagrammatic reasoning, foundations of computer science. Best wishes, The FP Lab University of Nottingham +-----------------------------------------------------------+ 10 Fully-Funded PhD Studentships School of Computer Science University of Nottingham, UK https://tinyurl.com/ten-phds-2025 Applications are invited from home and international students for up to 10 fully-funded PhD studentships offered by the School of Computer Science, starting on 1st October 2025. The topics for the studentships are open, but should relate to the interests of one of the School’s research groups: Cyber-Physical Health and Assistive Robotics; Computational Optimisation and Learning Lab; Computer Vision Lab; Cyber Security; Functional Programming; Intelligent Modelling and Analysis; Mixed Reality Lab; Lab for Uncertainty in Data and Decision Making; Visualisation and Computer Graphics; Responsible Digital Futures. The studentships are fully funded for 3.5 years and include a stipend of £19,237 per year and tuition fees. Applicants are normally expected to have a first-class Bachelor or Masters degree or international equivalent, in a related discipline. If you are interested in applying, please contact a potential supervisor as soon as possible, and at least two weeks prior to the closing date. If the supervisor wishes to support your application, they will direct you to make an official application through the MyNottingham system. Closing date for applications: Sunday 6th April 2025 +-----------------------------------------------------------+ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From julian at getcontented.com.au Wed Dec 4 14:31:14 2024 From: julian at getcontented.com.au (julian getcontented.com.au) Date: Wed, 4 Dec 2024 14:31:14 +0000 Subject: [Haskell-cafe] Imports as first class functions Message-ID: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> Further to the previous message about modules and imports, what would be *really* useful would be if importing was in some sense “just a function” in IO or some other Monad and therefore also if modules were represented as some Haskell data structure. That’d obviously make the top level ambient context of a module of Haskell into a sort of monadic action, so it’d be a bit weird, tho at the moment who’s to say what it is anyway? It’s certainly not something that’s first class to the language or able to be programmed as it stands. I suppose this is sounding a little like I’m interested in homoiconicity in some sense, and that’s probably not far from the truth. The main reason I would find this useful is similar to what Sylvain was saying about storing modules of code in databases. I have a system that produces “representations” as Text and then sometimes compiles it as Haskell source (and it’s meta-recursive in that there are many of these little pieces of executed code that then compile others’ outputs, etc)… and even if we don’t have programmatic control over actual compilation or which versions of libraries of code to include, having programmatic control over where the data for modules’ sources comes from would be fantastic. Given that importing is just some magic declaration at the moment that’s kind of outside the language’s programmable constructs, tho, I can’t see that happening without some major reworking, tho, really. Is there appetite for such a thing? One of the things a little strange about the programming industry is how quick we are to invent entirely new languages rather than attempt to modify existing ones and beat them into a new more flexible shape so we can shoehorn our new requirements into a more flexible frame. I realise it’s not always possible, but surely if we all got together and worked on it we could do it? Really, I probably don’t know enough about the internal workings of Haskell & GHC to know if this is crazy or partly reasonable, but crazy ideas are sometimes fantastic, so I’m asking anyway. It would be *glorious* if stack (or cabal, or whatever package manager we use) itself were programmable in the sense that it could be called from within Haskell itself using a typed API and data could drive its included packages, and its type could be a function whose range was IO ByteString, providing the compiled binary. I guess where I’m driving with all this is that it’d be amazing if more of the language and package system and build tools and dependencies were first class and/or have an API just like the GHC API exists because being able to manipulate these things from programs would be great and simplify a lot of currently complex stuff; the only way to do that at the moment is to leave Haskell’s type safety and deal with the textual interfaces in System.Process et al. (I’m actually using System.Process.Streaming, but that’s neither here nor there). I do have a further idea I’ve been pondering for a long while that’s even more crazy than these two, but I might leave that for later, if at all; it has to do with programmability of syntax or lack thereof. Essentially, my system is aiming at keeping everything (source, executables, results of all kinds) separated into small pieces, and results cached so that I don’t have to continually recompile and recompute things that have already been compiled and computed before. It has some of the same ideas as unison in the content hashing sense, tho not the caching at the AST level because Haskell doesn’t work like that, and I’m not interested in building a monolithic unison/smalltalk-style “image/database/world” that has to have everything imported into it — rather the other way around — to have little programs that use parsing, do one thing, and have a typed interface between each of them that glues them all together as and when needed. Apologies that it’s so hand-wavey. Maybe there’s a better place or way to discuss such ideas? If so, let me know. Thanks! From allbery.b at gmail.com Wed Dec 4 17:08:11 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 4 Dec 2024 12:08:11 -0500 Subject: [Haskell-cafe] Imports as first class functions In-Reply-To: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> References: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> Message-ID: On Wed, Dec 4, 2024 at 9:31 AM julian getcontented.com.au < julian at getcontented.com.au> wrote: > One of the things a little strange about the programming industry is how > quick we are to invent entirely new languages rather than attempt to modify > existing ones and beat them into a new more flexible shape so we can > shoehorn our new requirements into a more flexible frame. I realise it’s > not always possible, but surely if we all got together and worked on it we > could do it? > Generally at the price of breaking backward compatibility, which is already a major issue with GHC and would get much worse here. > It would be *glorious* if stack (or cabal, or whatever package manager we > use) itself were programmable in the sense that it could be called from > within Haskell itself using a typed API and data could drive its included > packages, and its type could be a function whose range was IO ByteString, > providing the compiled binary. > The Cabal library is already largely programmable in this sense, although as it drives system tools you have the problem that inputs and outputs are disk files coming from or going to those tools. Changing this requires changing the system tools, or reimplementing them which would be prohibitively difficult and subject to regular breakage. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From isaace71295 at gmail.com Wed Dec 4 20:59:06 2024 From: isaace71295 at gmail.com (Isaac Elliott) Date: Thu, 5 Dec 2024 06:59:06 +1000 Subject: [Haskell-cafe] Imports as first class functions In-Reply-To: References: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> Message-ID: > what would be *really* useful would be if importing was in some sense “just a function” in IO or some other Monad and therefore also if modules were represented as some Haskell data structure. You can do something like this using the GHC API. A program that depends on the `ghc` library can parse and compile a module, and then look up module bindings by name and (unsafely) coerce them into normal values. See `hint` ( https://hackage.haskell.org/package/hint) for some inspiration. I was playing around with this sort of thing because I wanted to use Haskell modules as plugins for a program that I wrote. I got it working - the program could load and run the plugin module - but decided to go back to a fraught stringly-typed interface between two separately compiled processes. One reason was that the dynamic loading approach was too slow, and I wasn't interested in figuring out how to make it faster. Another reason was that my program is intended for use in certain Haskell projects, and it's unlikely that the GHC compiler embedded in the program will match the version that the user has for their project. I didn't want to allow the user to write code that compiles with their GHC but not when loaded into my program (e.g. if their GHC version is newer and they use a new feature). On Thu, 5 Dec 2024, 03:08 Brandon Allbery, wrote: > On Wed, Dec 4, 2024 at 9:31 AM julian getcontented.com.au < > julian at getcontented.com.au> wrote: > >> One of the things a little strange about the programming industry is how >> quick we are to invent entirely new languages rather than attempt to modify >> existing ones and beat them into a new more flexible shape so we can >> shoehorn our new requirements into a more flexible frame. I realise it’s >> not always possible, but surely if we all got together and worked on it we >> could do it? >> > > Generally at the price of breaking backward compatibility, which is > already a major issue with GHC and would get much worse here. > > >> It would be *glorious* if stack (or cabal, or whatever package manager we >> use) itself were programmable in the sense that it could be called from >> within Haskell itself using a typed API and data could drive its included >> packages, and its type could be a function whose range was IO ByteString, >> providing the compiled binary. >> > > The Cabal library is already largely programmable in this sense, although > as it drives system tools you have the problem that inputs and outputs are > disk files coming from or going to those tools. Changing this requires > changing the system tools, or reimplementing them which would be > prohibitively difficult and subject to regular breakage. > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian at getcontented.com.au Thu Dec 5 06:49:59 2024 From: julian at getcontented.com.au (julian getcontented.com.au) Date: Thu, 5 Dec 2024 06:49:59 +0000 Subject: [Haskell-cafe] Imports as first class functions In-Reply-To: References: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> Message-ID: <026B2029-6C8C-4BDE-AC2A-54F90F95AB12@getcontented.com.au> Yeah, thanks for the suggestions; I explored the GHC API and hint a few years ago (four). Even contributed to GHC’s linker to allow hint to do multi-layered interpretation when I was using it to build a distributed haskell / cloud haskell backed service that was the precursor to the system I’m building now. Of course sadly Cloud Haskell has been pretty much dropped in the last few years, so that possibility went away, and Hint is primarily aimed at interpretation not compilation, but I realise you’re suggesting to use hint as an example of how the GHCI API could be used, not saying to use hint itself necessarily. However I’m interested in compilation not interpretation. If I understand what you’re suggesting, I think it’d become pretty tedious if every single module we wrote had to import the GHC API just so it could import other modules? I wasn’t intending that imports should be dynamic, just that it’d be nice if it were more explicit about exactly what an import meant, in the sense that other Haskell expressions are, and thus more first class, which would allow using Text as source, and obtaining that source from a database or some other place just as easily as off disk. [68.png] Multiple embedded interpreter instances · Issue #68 · haskell-hint/hint github.com On 5 Dec 2024, at 7:59 AM, Isaac Elliott wrote: > what would be *really* useful would be if importing was in some sense “just a function” in IO or some other Monad and therefore also if modules were represented as some Haskell data structure. You can do something like this using the GHC API. A program that depends on the `ghc` library can parse and compile a module, and then look up module bindings by name and (unsafely) coerce them into normal values. See `hint` (https://hackage.haskell.org/package/hint) for some inspiration. I was playing around with this sort of thing because I wanted to use Haskell modules as plugins for a program that I wrote. I got it working - the program could load and run the plugin module - but decided to go back to a fraught stringly-typed interface between two separately compiled processes. One reason was that the dynamic loading approach was too slow, and I wasn't interested in figuring out how to make it faster. Another reason was that my program is intended for use in certain Haskell projects, and it's unlikely that the GHC compiler embedded in the program will match the version that the user has for their project. I didn't want to allow the user to write code that compiles with their GHC but not when loaded into my program (e.g. if their GHC version is newer and they use a new feature). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 68.png Type: image/png Size: 80532 bytes Desc: 68.png URL: From mostafatouny at protonmail.com Sat Dec 7 12:45:27 2024 From: mostafatouny at protonmail.com (Mostafa Touny) Date: Sat, 07 Dec 2024 12:45:27 +0000 Subject: [Haskell-cafe] Engineering Value of Functional Programming Message-ID: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Dear Haskellers, I hope my email finds you in a good shape. Software engineers usually deviate away from Haskell, in the name of rapid development. In Pure Math, I can see the power of abstraction; It resulted in broad applications, with a sustainable and scalable usage in all humanity's sciences. Software development should benefit as well, avoiding technical debts and refactoring costs. Haskell seems more promising as it is empowered by category and type theory. Nonetheless, I cannot find a single management methodology, like Eric Ries' lean startup and iterative agile, that demonstrates the power of functional programming from the perspective of project management. Discussion. - Do you agree category and type theory could reduce projects costs? - Is it true, no guideline is designed for demonstrating their worthiness? Sincerely, Mostafa Touny https://mostafatouny.github.io/ From jo at durchholz.org Sat Dec 7 14:48:24 2024 From: jo at durchholz.org (jo at durchholz.org) Date: Sat, 7 Dec 2024 15:48:24 +0100 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Message-ID: <31ec7135-d7db-41e4-9da5-2ccd3a9d4ffb@durchholz.org> On 07.12.24 13:45, Mostafa Touny via Haskell-Cafe wrote: > Software engineers usually deviate away from Haskell, in the name of rapid development. > > In Pure Math, I can see the power of abstraction; It resulted in broad applications, with a sustainable and scalable usage in all humanity's sciences. Software development should benefit as well, avoiding technical debts and refactoring costs. Haskell seems more promising as it is empowered by category and type theory. > > Nonetheless, I cannot find a single management methodology, like Eric Ries' lean startup and iterative agile, that demonstrates the power of functional programming from the perspective of project management. > > Discussion. > - Do you agree category and type theory could reduce projects costs? > - Is it true, no guideline is designed for demonstrating their worthiness? Frame challenge: Most programming is application programming, and application programming is finding, integrating and using the best libraries for the project. Guidelines are for application programming, they don't help much with libraries as each library is one of its kind (sort-of, usually there's one go-to libraries and maybe two, sometimes three competitors). So I think it's normal to expect that there's nothing that teaches type theory or category theory with the aim of reducing project cost. However, a lot of arguments can be made that these things make it easier to create good libraries. There is one exception: DDD. A domain type is straightforward to model in a pure language, and often pretty boilerplatey elsewhere. However, coding these types does not usually take a lot of time overall, so it's not a strong argument; having less boilerplate overall, though, would make a pretty strong argument, but again, that's not methodology, just practical experience, since the type system are given anyway so there's no methodology to teach. Just my 2c. Regards, Jo From jerzy.karczmarczuk at unicaen.fr Sat Dec 7 18:20:55 2024 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Sat, 7 Dec 2024 19:20:55 +0100 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: <31ec7135-d7db-41e4-9da5-2ccd3a9d4ffb@durchholz.org> References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> <31ec7135-d7db-41e4-9da5-2ccd3a9d4ffb@durchholz.org> Message-ID: <034875d2-d89d-4e4f-b7d6-4958fe880b5a@unicaen.fr> Joachim Durchholz observes (in reaction to Mostafa Touny): > application programming is finding, integrating and using the best > libraries for the project. Hmm. Nothing more? No original algorithm design? No cooking of specific (problem-oriented) data structures? And who worked out those "best libraries"? Further reading makes me curious what is Jo's  definition of the "methology", since the fragment: > /.../ that's not methodology, just practical experience, since the > type system are given anyway so there's no methodology to teach. -- is something I find a bit distant from the world of teaching. Jerzy Karczmarczuk (France) -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com From sergueyz at gmail.com Sat Dec 7 18:35:32 2024 From: sergueyz at gmail.com (Serguey Zefirov) Date: Sat, 7 Dec 2024 21:35:32 +0300 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Message-ID: The axiom of software engineering is "the longer the time between introduction of defect and its' discovery, the bigger the cost of fixing defect." This usually comes from "error in requirements is the hardest to fix," but is true in general too. Haskell does reduce time between introductions of defects and their discoveries. Many defects do not pass compiler type checks, for example. Monadic code allows one to combine local state and safe and atomic communication between different (parallel) parts of the program. сб, 7 дек. 2024 г. в 15:45, Mostafa Touny via Haskell-Cafe < haskell-cafe at haskell.org>: > Dear Haskellers, > I hope my email finds you in a good shape. > > Software engineers usually deviate away from Haskell, in the name of rapid > development. > > In Pure Math, I can see the power of abstraction; It resulted in broad > applications, with a sustainable and scalable usage in all humanity's > sciences. Software development should benefit as well, avoiding technical > debts and refactoring costs. Haskell seems more promising as it is > empowered by category and type theory. > > Nonetheless, I cannot find a single management methodology, like Eric > Ries' lean startup and iterative agile, that demonstrates the power of > functional programming from the perspective of project management. > > Discussion. > - Do you agree category and type theory could reduce projects costs? > - Is it true, no guideline is designed for demonstrating their worthiness? > > Sincerely, > Mostafa Touny > https://mostafatouny.github.io/ > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sat Dec 7 18:56:26 2024 From: jo at durchholz.org (jo at durchholz.org) Date: Sat, 7 Dec 2024 19:56:26 +0100 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: <034875d2-d89d-4e4f-b7d6-4958fe880b5a@unicaen.fr> References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> <31ec7135-d7db-41e4-9da5-2ccd3a9d4ffb@durchholz.org> <034875d2-d89d-4e4f-b7d6-4958fe880b5a@unicaen.fr> Message-ID: On 07.12.24 19:20, Jerzy Karczmarczuk wrote: > Joachim Durchholz observes (in reaction to Mostafa Touny): > >> application programming is finding, integrating and using the best >> libraries for the project. > Hmm. Nothing more? Heh. I might have overlooked something. > No original algorithm design? I haven't done that in decades for any application programming. Never for UX, almost never in the backend. The vast majority of backend(!) programming work is "please transform data A, combine it with B, and we'll deal with performance issues when they arise". Frontend work is more about correct validation and layout so it matches what the UX designer wanted. The biggest sort-of algorithmic work I did in the past 10 years was integrating a test system with standalone application. The biggest technical obstacle was to implement a table structure so the test system knew that the fields it was seeing in the UI were really part of a table. No real algorithmic work, the interfaces were all predefined, I just had to implement them, and I believe I used some Map data structures provided by the language's standard library. The main challenge was a correct implementation of the incompletely-specified API of the test system. That's not algorithmic work, that's experimenting until it works(TM). > No cooking of specific (problem-oriented) data structures? Domain objects, yes. But these are very straightforward; they may even be associated with computations, but that's just processing, there's usually no loops except for summation. Computing a histogram would be the limit of what you'd do there, usually. Essentially, you map everything to primitives, records, lists, and maps, and that's all you need. Algorithmic is needed if the performance is bad and neither caching nor adding a map helps. Even O(N²) is often accepted because N is usually limited to some fairly low number, if the system ever scales up enough that this starts to bite you, you'll have to refactor and even partially rewrite it anyway. > And who worked out those "best libraries"? Specialists. Not application programmers. Nobody codes a new ray-tracing engine anymore, unless for an ICFP contest. Which _is_ fun, but application programming does not do that kind of task. Application programming is about collecting data, doing some O(N) calculations on it, and shoving it to the next place, plus obviously UX. > Further reading makes me curious what is Jo's  definition of the > "methology", since the fragment: > >> /.../ that's not methodology, just practical experience, since the >> type system are given anyway so there's no methodology to teach. > -- is something I find a bit distant from the world of teaching. Well, I've been in the industrie (hah!) for decades now, and that's what I observe. As an application programmer, you still need to know about O limits (and most know horribly little about that kind of stuff), but algorithms - that's specialist work. The last time I saw the lead programmer do algorithmic work was when our design had data in different services that had to be updated transactionally. It was an attempt at reimplementing two-phase commit within a single phase, which couldn't work; the better solution was shifting service responsibilities slightly so the transaction would run within a single service. You may find that disappointing, but it's what all those people do once they hit the industry - except those few who actually hit a job where advanced work is actually needed. Regards, Jo From jerzy.karczmarczuk at unicaen.fr Sat Dec 7 21:36:22 2024 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Sat, 7 Dec 2024 22:36:22 +0100 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> <31ec7135-d7db-41e4-9da5-2ccd3a9d4ffb@durchholz.org> <034875d2-d89d-4e4f-b7d6-4958fe880b5a@unicaen.fr> Message-ID: <34b30552-c8da-45ba-add1-a8547cc1b52d@unicaen.fr> Joachim Durchholz: > >> And who worked out those "best libraries"? > > *Specialists. > Not application programmers. * Jo, did you ever teach  CompSci in a comprehensive context, so that it was (could be) useful to read some History? Well, I've been formed as physicist, so some examples. Almost whole CERNLIB has been created, implemented and analysed before Eru Ilúvatar created the race of Specialists. The accelerator users NEEDED intelligent code for their applications, and there were no Wizards in the neighbourhood. *Quicksort* has been invented by Tony Hoare between 1959 and 1961 (publication).  When he studied in Moscow, he was offered a work on a translation project, and needed a good method to process dictionaries.  It was thus an */application/* project, and in such a way TH *became* specialist! Interesting story... The Mercury Autocode was less then useful to reasonably implement sorting and TH, who in 1961 studied Algol 60 (in Brighton) found recursion. Partly thanks to him, the recursive algorithms began to proliferate, also in numerical realm; you might know that at the beginning Algol had no recursion, since some specialists within its Committee were against, saying that this was useless, only slowed down the programs. Well, the anti-recursionists continue until today... The first interesting "computer experiment", the dawn of simulation, with some new algorithms, is the FPUT work (Fermi, Pasta, Ulam, Tsingou, 1953). Will you call them "specialists" (surely of something) and not "applicative programmers"? Actually, the team had one true programmer, Mary Tsingou. All of you probably know who was Fermi or Ulam... Monte Carlo: Nicholas Metropolis was a physicist. What "best libraries" invented by "specialists" could he look for, while participating in the Manhattan project? The algebraic language Schoonschip with its wonderful rewriting system, is the creation of Martinus Veltman. Do I have to remind you what was his principal specialty? (and the successor of Schoonschip, Form was created by a physicist, Jon Vermaseren; Reduce: by Hearn, physicist as well). Do you think that Stephen Wolfram began his carreer  as a specialist in computer science? Verify. OK, I stop here. > > No cooking of specific (problem-oriented) data structures? > > Domain objects, yes. But these are very straightforward; they may even > be associated with computations, but that's just processing, there's > usually no loops except for summation. Computing a histogram would be > the limit of what you'd do there, usually. > Essentially, you map everything to primitives, records, lists, and > maps, *and that's all you need*. As you wish, but don't forget love... You know, it can also be mapped to primitives. Will then it make you happy? I am sorry, I don't want to be impolite, but I am afraid that you don't master this subject. Such objects as Graphs in hundreds of different favours find themselves beyond your "limits of utility"??  Do you know what data structures are needed in, say, robotics,  in inverse kinematics? > Nobody codes a new ray-tracing engine anymore, unless for an ICFP > contest. Do you really think that graphic/imagery/synthesis algorithms for the Film Industry people are primitive, assembly-style instructions, without loops etc., and everything stagnates? Ray tracing?? Do you know what organization of concurrency is needed in the implementation of real-time recursive radiosity? (and this is not so recent!) Well, I wish you the best. But, please, learn something off your present limits, you might find many interesting topics. Jerzy Karczmarczuk -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Sun Dec 8 02:51:39 2024 From: qdunkan at gmail.com (Evan Laforge) Date: Sat, 7 Dec 2024 18:51:39 -0800 Subject: [Haskell-cafe] Imports as first class functions In-Reply-To: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> References: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> Message-ID: Nix is an example of a language with first class imports, `import` is a plain function the returns the "module" which is just a record like any other. Based on my experience, it's not all that great. Of course it could be because the nix language itself is weak, with dynamic typing and no user defined data types. But the main effect is that it's hard to tell who imports what or where some value comes from, because import may syntactically occur in any expression, and then the module may be passed around arbitrarily far before being used. As opposed to haskell where you just look at the top of the file and a single step takes you to the definition. An advantage is that of course a "module" can just be a function which returns a module, which is similar to how I imagine ML functors being, except all in the value language. It's used to conveniently inject a bunch of variables into scope. Since there are no user-defined data types though, none of the traditional "define a hash map with built-in hash function" type stuff. I've (very) occasionally wanted a parameterized module in haskell, the closest analog is just a normal record, and you can then use RecordWildCards like a local import. It would be nice for DSLs if records and modules could be unified that way, so you could have both local imports and parameterized modules. I haven't really come up with a use for it outside of one particular DSL though. I gather there's a deep history for this in ML though, and I recall some dependently typed languages like Agda or Idris had unified modules and records to a greater degree than haskell. For GHC API, I have a program that uses it to implement a REPL which is then the main text-oriented UI. I originally wanted to use dynamic loading to be able to write and insert code at runtime, but never got that going. Instead it's reasonably fast to rebuild and relink and reload the program, which seems like a less finicky way to go about it, and I settle for the REPL which compiles fragments to modify the state, but are not themselves persistent unless I paste them into a module somewhere. From matti.johannes.nykanen at gmail.com Sun Dec 8 07:41:39 2024 From: matti.johannes.nykanen at gmail.com (=?UTF-8?Q?Matti_Nyk=C3=A4nen?=) Date: Sun, 8 Dec 2024 09:41:39 +0200 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Message-ID: <64fa072a-1350-432a-ac2c-d59ad1bf19e6@gmail.com> This is in fact a timely question! (Hope it wasn't homework...) As someone said somewhere, "Now it is the time for Functional Programming to fail", just like any other software design relig... methodology before it. Some recent books which try to address these issues are: * Alexander Granin: /Functional Design and Architecture/. (Manning, 2024) Still in my "to read" stack, to which I unfortunately "Keep on Pushin'" (like the Impressions sang)... * Robert C. (a.k.a. "uncle Bob") Martin: Functional Design. (Addison-Wesley, 2024) NOTE: This is a *really bad* book! But it serves to show that the big publishers and famous authors are beginning to smell money to be made in FP, and _that_ is encouraging! As a recently retired university lecturer of BS... sorry, CS, I cannot really claim any deep knowledge of the field, since my specialty was in algorithmics and automata. On a somewhat related note: * Recall Alan Perlis' Epigram #59 of Programming: "In English every word can be verbed. Would that it were so in our programming languages." FP (and especially Haskell) goes some way towards that goal by not separating functions and control structures as tightly as imperative programming languages. Great for the seasoned programmer... * ...but perhaps a nightmare for the newcomer? At least the book Felienne Hermans: /The Programmer's Brain/. (Manning,2021) seems to imply (but does not directly claim) so, because it says that we humans rely on "anchors" or words whose meaning stays the same while we are learning new concepts. Serguey Zefirov kirjoitti 7.12.2024 klo 20.35: > The axiom of software engineering is "the longer the time between > introduction of defect and its' discovery, the bigger the cost of > fixing defect." This usually comes from "error in requirements is the > hardest to fix," but is true in general too. > > Haskell does reduce time between introductions of defects and their > discoveries. Many defects do not pass compiler type checks, for example. > > Monadic code allows one to combine local state and safe and atomic > communication between different (parallel) parts of the program. > > сб, 7 дек. 2024 г. в 15:45, Mostafa Touny via Haskell-Cafe > : > > Dear Haskellers, > I hope my email finds you in a good shape. > > Software engineers usually deviate away from Haskell, in the name > of rapid development. > > In Pure Math, I can see the power of abstraction; It resulted in > broad applications, with a sustainable and scalable usage in all > humanity's sciences. Software development should benefit as well, > avoiding technical debts and refactoring costs. Haskell seems more > promising as it is empowered by category and type theory. > > Nonetheless, I cannot find a single management methodology, like > Eric Ries' lean startup and iterative agile, that demonstrates the > power of functional programming from the perspective of project > management. > > Discussion. > - Do you agree category and type theory could reduce projects costs? > - Is it true, no guideline is designed for demonstrating their > worthiness? > > Sincerely, > Mostafa Touny > https://mostafatouny.github.io/ > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Matti Nykänen -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Dec 8 10:29:54 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 8 Dec 2024 05:29:54 -0500 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: <64fa072a-1350-432a-ac2c-d59ad1bf19e6@gmail.com> References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> <64fa072a-1350-432a-ac2c-d59ad1bf19e6@gmail.com> Message-ID: On Sun, Dec 8, 2024 at 2:42 AM Matti Nykänen < matti.johannes.nykanen at gmail.com> wrote: > > - ...but perhaps a nightmare for the newcomer? At least the book > Felienne Hermans: *The Programmer's Brain*. (Manning,2021) > seems to imply (but does not directly claim) so, because it says that > we humans rely on "anchors" or words whose meaning stays the same while we > are learning new concepts. > > The good news there is that the anchors don't have to be keywords. Pick a program in a field you know and use the stuff you know as anchors. (I learned practical Haskell from the xmonad source code, using the XLib calls as anchors.) -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskellcafe at dandart.co.uk Sun Dec 8 18:12:26 2024 From: haskellcafe at dandart.co.uk (Dan Dart) Date: Sun, 8 Dec 2024 18:12:26 +0000 Subject: [Haskell-cafe] Imports as first class functions In-Reply-To: References: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> Message-ID: Personally, what I thought of immediately would be using dlopen() to import custom .so files (optionally located in database blobs?) Or, perhaps - the serialisable Free Function of a Category which looked interesting and inspired a project - https://www.youtube.com/watch?v=xZmPuz9m2t0 Ta-ta From allbery.b at gmail.com Sun Dec 8 18:19:52 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 8 Dec 2024 13:19:52 -0500 Subject: [Haskell-cafe] Imports as first class functions In-Reply-To: References: <5CC9C602-F39F-4484-8C55-EED6A11B5CA4@getcontented.com.au> Message-ID: On Sun, Dec 8, 2024 at 1:12 PM Dan Dart wrote: > Personally, what I thought of immediately would be using dlopen() to > import custom .so files (optionally located in database blobs?) > This used to be possible with the plugins package, but I think it's bitrotted now. Supposedly there are ghc-lib functions that can do it, but I don't know if you can apply them to a BLOB or if it has to be a disk file. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From noteed at gmail.com Mon Dec 9 12:13:02 2024 From: noteed at gmail.com (Vo Minh Thu) Date: Mon, 9 Dec 2024 13:13:02 +0100 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Message-ID: Hi, Since you're mentioning specifically Eric Ries, one of his companies is IMVU, where Haskell was adopted. A blog post about that adoption was written a while ago: https://chadaustin.me/2016/06/the-story-of-haskell-at-imvu/. Cheers, Thu Le sam. 7 déc. 2024 à 13:45, Mostafa Touny via Haskell-Cafe < haskell-cafe at haskell.org> a écrit : > Dear Haskellers, > I hope my email finds you in a good shape. > > Software engineers usually deviate away from Haskell, in the name of rapid > development. > > In Pure Math, I can see the power of abstraction; It resulted in broad > applications, with a sustainable and scalable usage in all humanity's > sciences. Software development should benefit as well, avoiding technical > debts and refactoring costs. Haskell seems more promising as it is > empowered by category and type theory. > > Nonetheless, I cannot find a single management methodology, like Eric > Ries' lean startup and iterative agile, that demonstrates the power of > functional programming from the perspective of project management. > > Discussion. > - Do you agree category and type theory could reduce projects costs? > - Is it true, no guideline is designed for demonstrating their worthiness? > > Sincerely, > Mostafa Touny > https://mostafatouny.github.io/ > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Francesco.Occhipinti at tracsis.com Mon Dec 9 12:22:59 2024 From: Francesco.Occhipinti at tracsis.com (Francesco Occhipinti) Date: Mon, 9 Dec 2024 12:22:59 +0000 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Message-ID: I do not think that an engineering approach needs a methodology in order to be considered effective. Type safety, for instance, is an appealing feature by itself. ________________________________ From: Haskell-Cafe on behalf of Mostafa Touny via Haskell-Cafe Sent: Saturday, December 7, 2024 1:45 PM To: haskell-cafe at haskell.org Subject: [Haskell-cafe] Engineering Value of Functional Programming CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. Dear Haskellers, I hope my email finds you in a good shape. Software engineers usually deviate away from Haskell, in the name of rapid development. In Pure Math, I can see the power of abstraction; It resulted in broad applications, with a sustainable and scalable usage in all humanity's sciences. Software development should benefit as well, avoiding technical debts and refactoring costs. Haskell seems more promising as it is empowered by category and type theory. Nonetheless, I cannot find a single management methodology, like Eric Ries' lean startup and iterative agile, that demonstrates the power of functional programming from the perspective of project management. Discussion. - Do you agree category and type theory could reduce projects costs? - Is it true, no guideline is designed for demonstrating their worthiness? Sincerely, Mostafa Touny https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmostafatouny.github.io%2F&data=05%7C02%7Cfrancescoocchipinti%40tracsis.com%7C46ef7f6e49294512511608dd16bd1514%7C6b98f2667d234d0a8b8a7e4cf7fded86%7C0%7C0%7C638691723544093562%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4JrqBCzr4eVhAY9ZEu7GUbA339YreqZxCLnzGDTuJZU%3D&reserved=0 _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell-cafe&data=05%7C02%7Cfrancescoocchipinti%40tracsis.com%7C46ef7f6e49294512511608dd16bd1514%7C6b98f2667d234d0a8b8a7e4cf7fded86%7C0%7C0%7C638691723544109390%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sBpM1mnmxpyyEySlCE3M%2FuADMShsOHIpWSUXL2H7%2FWw%3D&reserved=0 Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Tue Dec 10 01:25:29 2024 From: simon at joyful.com (Simon Michael) Date: Mon, 09 Dec 2024 15:25:29 -1000 Subject: [Haskell-cafe] ANN: hledger 1.41 Message-ID: <1026cf8e-1b43-4ff4-b27e-f403fed447e2@app.fastmail.com> I'm pleased to announce hledger 1.41 ! This release brings: - a notable valuation fix - pervasive improved HTML and FODS output - multiple depths - terminal pagination - robust export to Beancount ..and more. Thank you to contributors Dmitry Astapov, Stephen Morgan, Bas van Dijk, Gal Lakovnik Gorenec, amano.kenji, gesh, and especially Henning Thielemann ! Best wishes, -Simon - https://github.com/simonmichael/hledger/releases/1.41 - https://hledger.org/relnotes.html#2024-12-09-hledger-141 - https://hledger.org/install hledger is free, robust, friendly, multicurrency, double-entry, plain text accounting software for unix, mac, windows, and the web. Written in Haskell for reliability, it is built around human-readable, version-controllable plain text files. It is inspired by and largely compatible with Ledger CLI, and convertible to and from Beancount. For more info or help, see https://hledger.org and the support page. Newcomers, experts, contributors, sponsors, feedback are welcome! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mostafatouny at protonmail.com Tue Dec 10 14:29:12 2024 From: mostafatouny at protonmail.com (Mostafa Touny) Date: Tue, 10 Dec 2024 14:29:12 +0000 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Message-ID: Thank you all for your comments. The closest thing I found related to project management and haskell was Serokell's blog: https://serokell.io/blog/haskell-in-production I feel there is a space for designing new project management methodologies based on type and category theory. Let me know if anyone is curious to explore that. Best, Mostafa Touny From sergueyz at gmail.com Tue Dec 10 14:56:05 2024 From: sergueyz at gmail.com (Serguey Zefirov) Date: Tue, 10 Dec 2024 17:56:05 +0300 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Message-ID: https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence The program is the proof of the (problem-related) theorem. One can use type classes and HOT to express *requirements* and protocols of various parts of the program and then fill implementation details. Types allow for *tracking requirements* inside the implementation. Basically, by applying type systems like Haskell's one gets a requirement tracking system for free. And requirements' tracking is a very hard task. But it is a "waterfall" on steroids and as unhip as one can only imagine. вт, 10 дек. 2024 г. в 17:29, Mostafa Touny via Haskell-Cafe < haskell-cafe at haskell.org>: > Thank you all for your comments. > > The closest thing I found related to project management and haskell was > Serokell's blog: https://serokell.io/blog/haskell-in-production > > I feel there is a space for designing new project management methodologies > based on type and category theory. > > Let me know if anyone is curious to explore that. > > Best, > Mostafa Touny > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mostafatouny at protonmail.com Tue Dec 10 17:49:14 2024 From: mostafatouny at protonmail.com (Mostafa Touny) Date: Tue, 10 Dec 2024 17:49:14 +0000 Subject: [Haskell-cafe] Engineering Value of Functional Programming In-Reply-To: References: <__aVOkLlth5gj88Hfzv66ry6SlkVHy2cQABxhwe_C189LfH084xTGetqYvySyh9ClN08dRCtgXzd2i80OqUhu15a-rC2tPw9tV0tmitOZYs=@protonmail.com> Message-ID: <1qDcpbGwGB2jc3AM4mud7nVORsaNTbc7ABYAuKYIfXCzaZByhrirC-2iXQ1OXK-pOAcqWvSB09ng6hyufN8IUxhqx1TVdCWBxXaixLbtuE8=@protonmail.com> Thank you, Serguey. I like Haskell as a theory but I would remind myself that a good mathematician or a good engineer looks for solving the right problem using the right tools. I am trying to figure a methodology that boosts re-usability and cheap modifications using haskell, types, and categories. Any experience or guideline would be appreciated. Sincerely, Mostafa Touny From andreash87 at gmx.ch Sun Dec 15 16:55:43 2024 From: andreash87 at gmx.ch (Andreas Herrmann) Date: Sun, 15 Dec 2024 17:55:43 +0100 Subject: [Haskell-cafe] Save the date: Haskell Ecosystem Workshop and Haskell Implementors' Workshop 2025 Message-ID: Save the date for the Haskell Ecosystem Workshop and the Haskell Implementors' Workshop taking place on June 5 & 6 2025 near Zurich, Switzerland, hosted by the Haskell Foundation at the OST (Eastern Switzerland University of Applied Sciences) in Rapperswil, and co-located with ZuriHac (June 7-9). Expect a more detailed announcement, registration, and a call for proposals in early 2025. The Haskell Ecosystem Workshop is a workshop organized by the Haskell Foundation for those who want to gain a deeper understanding of the Haskell tooling ecosystem, whether to better leverage those tools or to become contributors. The Haskell Implementors' Workshop is a community event for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. In the past the Haskell Implementors' Workshop used to be co-located with ICFP (International Conference on Functional Programming), next year it will be co-located with ZuriHac to be accessible to a broader audience. Contact Jose Calderon, executive director of the Haskell Foundation, if you have any questions regarding the Haskell Ecosystem Workshop. Contact Andreas Herrmann, program chair for the Haskell Implementors' Workshop 2025, if you have any questions regarding the Haskell Implementors' Workshop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Mon Dec 16 10:20:54 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Mon, 16 Dec 2024 15:50:54 +0530 Subject: [Haskell-cafe] GHC 9.12.1 is now available Message-ID: The GHC developers are very pleased to announce the release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * Experimental support for the RISC-V platform with the native code generator. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/9.12.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From shayne.fletcher.50 at gmail.com Mon Dec 16 13:10:40 2024 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Mon, 16 Dec 2024 08:10:40 -0500 Subject: [Haskell-cafe] GHC 9.12.1 is now available In-Reply-To: References: Message-ID: There does not appear to be a ghc-9.12.1-release branch? On Mon, Dec 16, 2024 at 5:21 AM Zubin Duggal wrote: > The GHC developers are very pleased to announce the release of GHC 9.12.1. > Binary distributions, source distributions, and documentation are > available at > [downloads.haskell.org][]. > > We hope to have this release available via ghcup shortly. > > GHC 9.12 will bring a number of new features and improvements, including: > > * The new language extension [OrPatterns] allowing you to combine > multiple > pattern clauses into one. > > * The [MultilineStrings] language extension to allow you to more easily > write > strings spanning multiple lines in your source code. > > * Improvements to the OverloadedRecordDot extension, allowing the > built-in > `HasField` class to be used for records with fields of non lifted > representations. > > * The [NamedDefaults] language extension has been introduced allowing > you to > define defaults for typeclasses other than `Num`. > > * More deterministic object code output, controlled by the > `-fobject-determinism` > flag, which improves determinism of builds a lot (though does not > fully do so) > at the cost of some compiler performance (1-2%). See #12935 for the > details > > * GHC now accepts type syntax in expressions as part of [GHC Proposal > #281]. > > * The WASM backend now has support for TemplateHaskell. > > * Experimental support for the RISC-V platform with the native code > generator. > > * ... and many more > > A full accounting of changes can be found in the [release notes][]. > As always, GHC's release status, including planned future releases, can > be found on the GHC Wiki [status][]. > > We would like to thank GitHub, IOG, the Zw3rk stake pool, > Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell > Foundation, and other anonymous contributors whose on-going financial > and in-kind support has facilitated GHC maintenance and release > management over the years. Finally, this release would not have been > possible without the hundreds of open-source contributors whose work > comprise this release. > > As always, do give this release a try and open a [ticket][] if you see > anything amiss. > > > [release notes]: > https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/9.12.1-notes.html > [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status > [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1 > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [OrPatterns]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst > [MultilineStrings]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst > [GHC Proposal #281]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst > [NamedDefaults]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Mon Dec 16 13:19:17 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Mon, 16 Dec 2024 18:49:17 +0530 Subject: [Haskell-cafe] GHC 9.12.1 is now available In-Reply-To: References: Message-ID: <6v25dh46mmobe7eqekltrkoldqvgwfyzeoglnyaqqxzofzyni3@lzx2xomhgwr3> Ah sorry, I accidentally called the tag ghc-9.12.1 instead of ghc-9.12.1-release. The correct tag should be pushed now. On 24/12/16 08:10, Shayne Fletcher wrote: >There does not appear to be a ghc-9.12.1-release branch? > >On Mon, Dec 16, 2024 at 5:21 AM Zubin Duggal wrote: > >> The GHC developers are very pleased to announce the release of GHC 9.12.1. >> Binary distributions, source distributions, and documentation are >> available at >> [downloads.haskell.org][]. >> >> We hope to have this release available via ghcup shortly. >> >> GHC 9.12 will bring a number of new features and improvements, including: >> >> * The new language extension [OrPatterns] allowing you to combine >> multiple >> pattern clauses into one. >> >> * The [MultilineStrings] language extension to allow you to more easily >> write >> strings spanning multiple lines in your source code. >> >> * Improvements to the OverloadedRecordDot extension, allowing the >> built-in >> `HasField` class to be used for records with fields of non lifted >> representations. >> >> * The [NamedDefaults] language extension has been introduced allowing >> you to >> define defaults for typeclasses other than `Num`. >> >> * More deterministic object code output, controlled by the >> `-fobject-determinism` >> flag, which improves determinism of builds a lot (though does not >> fully do so) >> at the cost of some compiler performance (1-2%). See #12935 for the >> details >> >> * GHC now accepts type syntax in expressions as part of [GHC Proposal >> #281]. >> >> * The WASM backend now has support for TemplateHaskell. >> >> * Experimental support for the RISC-V platform with the native code >> generator. >> >> * ... and many more >> >> A full accounting of changes can be found in the [release notes][]. >> As always, GHC's release status, including planned future releases, can >> be found on the GHC Wiki [status][]. >> >> We would like to thank GitHub, IOG, the Zw3rk stake pool, >> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell >> Foundation, and other anonymous contributors whose on-going financial >> and in-kind support has facilitated GHC maintenance and release >> management over the years. Finally, this release would not have been >> possible without the hundreds of open-source contributors whose work >> comprise this release. >> >> As always, do give this release a try and open a [ticket][] if you see >> anything amiss. >> >> >> [release notes]: >> https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/9.12.1-notes.html >> [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status >> [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1 >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [OrPatterns]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst >> [MultilineStrings]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst >> [GHC Proposal #281]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst >> [NamedDefaults]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > >-- >Shayne Fletcher From shayne.fletcher.50 at gmail.com Mon Dec 16 13:20:02 2024 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Mon, 16 Dec 2024 08:20:02 -0500 Subject: [Haskell-cafe] GHC 9.12.1 is now available In-Reply-To: <6v25dh46mmobe7eqekltrkoldqvgwfyzeoglnyaqqxzofzyni3@lzx2xomhgwr3> References: <6v25dh46mmobe7eqekltrkoldqvgwfyzeoglnyaqqxzofzyni3@lzx2xomhgwr3> Message-ID: On Mon, Dec 16, 2024 at 8:19 AM Zubin Duggal wrote: > Ah sorry, I accidentally called the tag ghc-9.12.1 instead > of ghc-9.12.1-release. > > The correct tag should be pushed now. > Thank-you! > > On 24/12/16 08:10, Shayne Fletcher wrote: > >There does not appear to be a ghc-9.12.1-release branch? > > > >On Mon, Dec 16, 2024 at 5:21 AM Zubin Duggal > wrote: > > > >> The GHC developers are very pleased to announce the release of GHC > 9.12.1. > >> Binary distributions, source distributions, and documentation are > >> available at > >> [downloads.haskell.org][]. > >> > >> We hope to have this release available via ghcup shortly. > >> > >> GHC 9.12 will bring a number of new features and improvements, > including: > >> > >> * The new language extension [OrPatterns] allowing you to combine > >> multiple > >> pattern clauses into one. > >> > >> * The [MultilineStrings] language extension to allow you to more > easily > >> write > >> strings spanning multiple lines in your source code. > >> > >> * Improvements to the OverloadedRecordDot extension, allowing the > >> built-in > >> `HasField` class to be used for records with fields of non lifted > >> representations. > >> > >> * The [NamedDefaults] language extension has been introduced allowing > >> you to > >> define defaults for typeclasses other than `Num`. > >> > >> * More deterministic object code output, controlled by the > >> `-fobject-determinism` > >> flag, which improves determinism of builds a lot (though does not > >> fully do so) > >> at the cost of some compiler performance (1-2%). See #12935 for the > >> details > >> > >> * GHC now accepts type syntax in expressions as part of [GHC Proposal > >> #281]. > >> > >> * The WASM backend now has support for TemplateHaskell. > >> > >> * Experimental support for the RISC-V platform with the native code > >> generator. > >> > >> * ... and many more > >> > >> A full accounting of changes can be found in the [release notes][]. > >> As always, GHC's release status, including planned future releases, can > >> be found on the GHC Wiki [status][]. > >> > >> We would like to thank GitHub, IOG, the Zw3rk stake pool, > >> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell > >> Foundation, and other anonymous contributors whose on-going financial > >> and in-kind support has facilitated GHC maintenance and release > >> management over the years. Finally, this release would not have been > >> possible without the hundreds of open-source contributors whose work > >> comprise this release. > >> > >> As always, do give this release a try and open a [ticket][] if you see > >> anything amiss. > >> > >> > >> [release notes]: > >> > https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/9.12.1-notes.html > >> [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status > >> [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.1 > >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > >> [OrPatterns]: > >> > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst > >> [MultilineStrings]: > >> > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst > >> [GHC Proposal #281]: > >> > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst > >> [NamedDefaults]: > >> > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > > > >-- > >Shayne Fletcher > -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Dec 17 08:33:27 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 17 Dec 2024 08:33:27 +0000 Subject: [Haskell-cafe] Throwing an exception in STM without rolling back state? Message-ID: Dear Cafe, Is it possible to throw an exception in STM without rolling back state? (See program below for an demonstration that throwing an exception does roll back state.) I'm having a great deal of success using exceptions in my effect system Bluefin, to simulate early return and jumps: * https://hackage.haskell.org/package/bluefin-0.0.14.0/docs/Bluefin-EarlyReturn.html * https://hackage.haskell.org/package/bluefin-0.0.14.0/docs/Bluefin-Jump.html I'm interested in making a Bluefin interface to STM too, but the value of that would be significantly diminished if all exceptions roll back state. Instead I would like to be able to say "throwing this exception _shouldn't_ roll back state". Is that possible? If not in practice, is it possible in theory, if I were to modify the RTS somehow? Thanks, Tom {-# LANGUAGE GHC2021 #-} import GHC.Conc import GHC.Exception data MyEx = MyEx deriving Show instance Exception MyEx -- > main -- False main = do r <- atomically $ do v <- newTVar False catchSTM @MyEx (do writeTVar v True -- same with throw MyEx` throwSTM MyEx ) (\_ -> pure ()) readTVar v print r From stefan.wehr at gmail.com Tue Dec 17 13:04:13 2024 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Tue, 17 Dec 2024 14:04:13 +0100 Subject: [Haskell-cafe] Call for Participation: BOB 2025 (Berlin, Mar 14) Message-ID: ========================================================================= BOB 2025 Conference “What happens if we simply use what’s best?” March 14, 2025, Berlin https://bobkonf.de/2025/ Program: https://bobkonf.de/2025/program.html Registration: https://bobkonf.de/2025/registration.html ========================================================================= BOB conference is a place for developers, architects, and decision-makers to explore technologies beyond the mainstream in software development and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experience. The program features 16 talks and 8 tutorials on current topics: https://bobkonf.de/2025/program.html Talk subjects includes functional programming, property-based testing, language server implementation, domain-specific languages, domain-driven design, local-first software, formal methods, and microservices. BOB tutorial include sessions on frontend development, local-first programming, data science, Elixir, and software documentation, combining mob programming, TDD, and AI. Annette Bieniusa will give the keynote talk. Registration is open - many discount options are available, as are grants for members of groups underrepresented in tech. Early-bird discounts apply until Jan 17. https://bobkonf.de/2025/registration.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From fryguybob at gmail.com Wed Dec 18 03:00:20 2024 From: fryguybob at gmail.com (Ryan Yates) Date: Tue, 17 Dec 2024 22:00:20 -0500 Subject: [Haskell-cafe] Throwing an exception in STM without rolling back state? In-Reply-To: References: Message-ID: Hi Tom, I think the implementation choices around exceptions in STM are well informed and reasoned choices, but other choices could have been made. One motivating reason for exceptions having abort semantics, for instance, is asynchronous exceptions (see the *Exceptions* section of *Composable Memory Transactions*). Caught exceptions thrown within a transaction have the same abort semantics for the nested transaction (as your example shows), but there is no way to know that `MyEx` isn't thrown asynchronously leading to rather difficult to reason about outcomes. I think it would be straight forward to modify this behavior in the RTS, simply do not discard the transactional record of the nested transaction ( https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L1390). Ryan On Tue, Dec 17, 2024 at 3:33 AM Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > Dear Cafe, > > Is it possible to throw an exception in STM without rolling back > state? (See program below for an demonstration that throwing an > exception does roll back state.) > > I'm having a great deal of success using exceptions in my effect > system Bluefin, to simulate early return and jumps: > > * > https://hackage.haskell.org/package/bluefin-0.0.14.0/docs/Bluefin-EarlyReturn.html > > * > https://hackage.haskell.org/package/bluefin-0.0.14.0/docs/Bluefin-Jump.html > > I'm interested in making a Bluefin interface to STM too, but the > value of that would be significantly diminished if all exceptions roll > back state. > > Instead I would like to be able to say "throwing this exception > _shouldn't_ roll back state". Is that possible? If not in practice, > is it possible in theory, if I were to modify the RTS somehow? > > Thanks, > > Tom > > > > > > > {-# LANGUAGE GHC2021 #-} > > import GHC.Conc > import GHC.Exception > > data MyEx = MyEx deriving Show > > instance Exception MyEx > > -- > main > -- False > main = do > r <- atomically $ do > v <- newTVar False > > catchSTM @MyEx > (do > writeTVar v True > -- same with throw MyEx` > throwSTM MyEx > ) > (\_ -> pure ()) > > readTVar v > > print r > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Wed Dec 18 08:11:53 2024 From: P.Achten at cs.ru.nl (Peter Achten) Date: Wed, 18 Dec 2024 09:11:53 +0100 Subject: [Haskell-cafe] [TFP (and TFPiE) 2025] Call For Participation (January 13-16, Oxford, UK) Message-ID: TFP 2025 -- Call For Participation (trendsfp.github.io) Venue TFPiE and TFP will take place in-person in the Wolfson Building of the Department of Computer Science at the University of Oxford. Dates Early registration: December 20, 2024 Late registration: January 6, 2025 TFPiE Workshop: Monday 13th January, 2025 TFP Symposium: Tuesday 14th - Thursday 16th January, 2025 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. Keynote speakers We are happy to have the following keynotes in the programme: * Nicolas Wu (TFPiE), Imperial College London: "Fractal Foundations and Galactic Graphs: Structure and Strategy for Expanding Minds" * Graham Nelson, University of Oxford: "Literate Programming and Cultural Practice" * Mike Sperber, Active Group: "Things We Never Told Anyone About Functional Programming" * Kathrin Stark, Heriot-Watt University: "A Verified Foreign Function Interface Between Coq and C" Programme We have 28 paper presentations. The programme schedule can be found here: trendsfp.github.io/schedule.html Excursion and banquet In the afternoon and evening of Wednesday January 15th we have an excursion to the History of Science Museum. We have a break in a cosy pub, before proceeding to Kellogg College for the conference banquet. During dinner the winners of the best paper awards of last year's TFP are announced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Wed Dec 18 08:31:37 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 18 Dec 2024 08:31:37 +0000 Subject: [Haskell-cafe] Throwing an exception in STM without rolling back state? In-Reply-To: References: Message-ID: Thanks Ryan. I discovered that I can obtain the behaviour I want just by providing a different version of catch (specifically, wrapping IO's version of catch). Does this seem like a reasonable thing to do? Is there a reason that I shouldn't have this version of catch as an *alternative* method of catching exceptions in STM (not as the only one -- the original one will still remain). Is it somehow unsafe, or violating of some guarantee needed by STM? If not then I think it would be a good addition (to Bluefin's version of STM at least, if not the standard one). Tom {-# LANGUAGE GHC2021 #-} {-# LANGUAGE UnboxedTuples #-} import GHC.Conc import GHC.IO import GHC.Exception data MyEx = MyEx deriving Show instance Exception MyEx myCatchSTM :: Exception e => STM a -> (e -> STM a) -> STM a myCatchSTM m f = (STM . unIO) ((catch (IO (unSTM m)) (IO . unSTM . f))) where unSTM = (\(STM s) -> s) -- > main -- True main = do r <- atomically $ do v <- newTVar False catchSTM @MyEx (do writeTVar v True throwSTM MyEx ) (\_ -> pure ()) readTVar v print r On Tue, Dec 17, 2024 at 10:00:20PM -0500, Ryan Yates wrote: > Hi Tom, > > I think the implementation choices around exceptions in STM are well > informed and reasoned choices, but other choices could have been made. One > motivating reason for exceptions having abort semantics, for instance, is > asynchronous exceptions (see the *Exceptions* section of *Composable Memory > Transactions*). Caught exceptions thrown within a transaction have the > same abort semantics for the nested transaction (as your example shows), > but there is no way to know that `MyEx` isn't thrown asynchronously leading > to rather difficult to reason about outcomes. I think it would be straight > forward to modify this behavior in the RTS, simply do not discard the > transactional record of the nested transaction ( > https://github.com/ghc/ghc/blob/master/rts/PrimOps.cmm#L1390). > > Ryan > > On Tue, Dec 17, 2024 at 3:33 AM Tom Ellis < > tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > > > Dear Cafe, > > > > Is it possible to throw an exception in STM without rolling back > > state? (See program below for an demonstration that throwing an > > exception does roll back state.) > > > > I'm having a great deal of success using exceptions in my effect > > system Bluefin, to simulate early return and jumps: > > > > * > > https://hackage.haskell.org/package/bluefin-0.0.14.0/docs/Bluefin-EarlyReturn.html > > > > * > > https://hackage.haskell.org/package/bluefin-0.0.14.0/docs/Bluefin-Jump.html > > > > I'm interested in making a Bluefin interface to STM too, but the > > value of that would be significantly diminished if all exceptions roll > > back state. > > > > Instead I would like to be able to say "throwing this exception > > _shouldn't_ roll back state". Is that possible? If not in practice, > > is it possible in theory, if I were to modify the RTS somehow? > > > > {-# LANGUAGE GHC2021 #-} > > > > import GHC.Conc > > import GHC.Exception > > > > data MyEx = MyEx deriving Show > > > > instance Exception MyEx > > > > -- > main > > -- False > > main = do > > r <- atomically $ do > > v <- newTVar False > > > > catchSTM @MyEx > > (do > > writeTVar v True > > -- same with throw MyEx` > > throwSTM MyEx > > ) > > (\_ -> pure ()) > > > > readTVar v > > > > print r