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 From zoran.bosnjak at via.si Thu Dec 19 09:38:59 2024 From: zoran.bosnjak at via.si (=?UTF-8?Q?Zoran_Bo=C5=A1njak?=) Date: Thu, 19 Dec 2024 10:38:59 +0100 Subject: [Haskell-cafe] convert structures from type to value level Message-ID: <5b4f9501eb0fde425bda4a36c4cb6525@via.si> Dear haskell cafe, I would like to describe some structures as types (something like servant does) and I would also need to use the same structure in run-time as a value. I am trying to figure out how could I use GHC.Generics or something to do this for several user defined structures. Currently I am doing it manually (with does not work, but it might serve as intention), for example: -- generic example structure data GTest s n = GTest0 | GTest1 s | GTest2 n type TTest = GTest Symbol Nat -- type level type VTest = GTest String Integer -- value level For all my user defined structure, at the type level it will always be only (Symbol, Nat) which should translate to (Text, Int) or (String, Integer) for simplicity. -- | Convert schema from type to value class IsSchema t a where schema :: a instance KnownNat n => IsSchema n Integer where schema = natVal (Proxy @n) instance KnownSymbol s => IsSchema s String where schema = symbolVal (Proxy @s) instance IsSchema 'GTest0 VTest where schema = GTest0 instance ( IsSchema s String ) => IsSchema ('GTest1 s) VTest where schema = GTest1 (schema @s) instance ( IsSchema n Integer ) => IsSchema ('GTest2 n) VTest where schema = GTest2 (schema @n) I would like to generalize the process, by saying something like (not sure if I even need this): data Usage = TypeLevel | ValueLevel data GTest ? = Gtest0 | GTest1 ? | GTest2 ? (deriving ?) ... and be able to use the same Test structure in both cases, such as: Use it as a phantom type in some other type: data Item (t :: TTest) where Item0 :: Item 'GTest0 Item1 :: String -> Item ('GTest1 s) Item2 :: Integer -> Item ('GTest2 n) And use it as value, something like: data SomeItem = forall t a. IsSchema t a => SomeItem a (Item t) In other words... I would like to work with exact types (Item t) or generically with SomeItem, when the type is not exactly known, but the value level schema is known. I came far with manual approach, but I could not create SomeItem from the value schema. So, for example this does not compile (the error is about KnownSymbol/KnownNat): mkSomeItem :: VTest -> SomeItem mkSomeItem sch = case sch of GTest0 -> SomeItem sch Item0 GTest1 s -> SomeItem sch (Item1 (s <> s)) GTest2 n -> SomeItem sch (Item2 (succ n)) I am curious to know how to fix this problem. But the manual conversion approach is something I would like to avoid in the first place. Appreciate your help. regards, Zoran From isaace71295 at gmail.com Fri Dec 20 06:04:18 2024 From: isaace71295 at gmail.com (Isaac Elliott) Date: Fri, 20 Dec 2024 16:04:18 +1000 Subject: [Haskell-cafe] convert structures from type to value level In-Reply-To: <5b4f9501eb0fde425bda4a36c4cb6525@via.si> References: <5b4f9501eb0fde425bda4a36c4cb6525@via.si> Message-ID: The `singletons`[1] library is as convienient as you can get in Haskell. I find the second half of your question is confusing, but it seems like you're asking, "how do I make Haskell *truly* dependently typed". The answer being: you can't, so you use `singletons` while accepting the pain, or change to a dependently typed language like Agda or Idris. [1]: https://hackage.haskell.org/package/singletons On Thu, 19 Dec 2024, 19:39 Zoran Bošnjak, wrote: > Dear haskell cafe, > I would like to describe some structures as types (something like > servant does) and I would also need to use the same structure in > run-time as a value. I am trying to figure out how could I use > GHC.Generics or something to do this for several user defined > structures. > > Currently I am doing it manually (with does not work, but it might serve > as intention), for example: > > -- generic example structure > data GTest s n = GTest0 | GTest1 s | GTest2 n > > type TTest = GTest Symbol Nat -- type level > type VTest = GTest String Integer -- value level > > For all my user defined structure, at the type level it will always be > only (Symbol, Nat) which should translate to (Text, Int) or (String, > Integer) for simplicity. > > -- | Convert schema from type to value > class IsSchema t a where > schema :: a > > instance KnownNat n => IsSchema n Integer where > schema = natVal (Proxy @n) > > instance KnownSymbol s => IsSchema s String where > schema = symbolVal (Proxy @s) > > instance IsSchema 'GTest0 VTest where > schema = GTest0 > > instance > ( IsSchema s String > ) => IsSchema ('GTest1 s) VTest where > schema = GTest1 (schema @s) > > instance > ( IsSchema n Integer > ) => IsSchema ('GTest2 n) VTest where > schema = GTest2 (schema @n) > > I would like to generalize the process, by saying something like (not > sure if I even need this): > > data Usage = TypeLevel | ValueLevel > > data GTest ? = Gtest0 | GTest1 ? | GTest2 ? (deriving ?) > > ... and be able to use the same Test structure in both cases, such as: > > Use it as a phantom type in some other type: > > data Item (t :: TTest) where > Item0 :: Item 'GTest0 > Item1 :: String -> Item ('GTest1 s) > Item2 :: Integer -> Item ('GTest2 n) > > And use it as value, something like: > > data SomeItem = forall t a. IsSchema t a => SomeItem a (Item t) > > In other words... I would like to work with exact types (Item t) or > generically with SomeItem, when the type is not exactly known, but the > value level schema is known. > > I came far with manual approach, but I could not create SomeItem from > the value schema. So, for example this does not compile (the error is > about KnownSymbol/KnownNat): > > mkSomeItem :: VTest -> SomeItem > mkSomeItem sch = case sch of > GTest0 -> SomeItem sch Item0 > GTest1 s -> SomeItem sch (Item1 (s <> s)) > GTest2 n -> SomeItem sch (Item2 (succ n)) > > I am curious to know how to fix this problem. But the manual conversion > approach is something I would like to avoid in the first place. > Appreciate your help. > > regards, > Zoran > _______________________________________________ > 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 chisvasileandrei at gmail.com Fri Dec 20 14:56:44 2024 From: chisvasileandrei at gmail.com (Andrei Chis) Date: Fri, 20 Dec 2024 16:56:44 +0200 Subject: [Haskell-cafe] 2nd CfP: SLE 2025 - 18th ACM SIGPLAN International Conference on Software Language Engineering Message-ID: 18th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2025) 12-13 June 2025 Koblenz, Germany https://www.sleconf.org/2025/ https://x.com/sleconf ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 18th ACM SIGPLAN International Conference on Software Language Engineering (SLE) which is devoted to the principles of software languages: their design, their implementation, and their evolution. The SLE 2025 conference will be co-located with STAF 2025 and hosted in Koblenz, Germany, on 12-13 June 2025. --------------------------- Important Dates --------------------------- * Abstract submission: Fri 7 Feb 2025 * Paper submission: Fri 14 Feb 2025 * Authors response period: Tue 1 Apr - Sat 5 Apr 2025 * Notification: Tue 15 Apr 2025 * Conference: Thu 12 June - Fri 13 June 2025 (co-located with STAF) All dates are Anywhere on Earth. --------------------------- Topics of Interest --------------------------- SLE covers software language engineering in general, rather than engineering a specific software language. Topics of interest include, but are not limited to: * Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral/executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches - AI-assisted language design and optimisation * Software Language Validation - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages - Model-based testing - AI-assisted validation * Software Language Integration and Composition - Coordination of heterogeneous languages and tools - Mappings between languages (incl. transformation languages) - Traceability between languages - Deployment of languages to different platforms - AI-assisted refactoring * Software Language Maintenance - Software language reuse - Language evolution - Language families and variability, language and software product lines * Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) * Empirical evaluation and experience reports of language engineering tools - User studies evaluating usability - Performance benchmarks - Industrial applications * Synergies between Language Engineering and emerging/promising research areas - Generative AI in language engineering (e.g., AI-based language modelling, AI-driven code generation tools) - AI and ML language engineering (e.g., ML compiler testing, code classification) - Quantum language engineering (e.g., language design for quantum machines) - Language engineering for physical systems (e.g., CPS, IoT, digital twins) - Socio-technical systems and language engineering (e.g., language evolution to adapt to social requirements) --------------------------- Types of Submissions --------------------------- SLE accepts the following types of papers: * Research papers: These are “traditional” papers detailing research contributions to SLE. Papers may range from 6 to 12 pages in length and may optionally include 2 further pages of bibliography/appendices. Papers will be reviewed with an understanding that some results do not need 12 full pages and may be fully described in fewer pages. * New ideas/vision papers: These papers may describe new, unconventional software language engineering research positions or approaches that depart from standard practice. They can describe well-defined research ideas that are at an early stage of investigation. They could also provide new evidence to challenge common wisdom, present new unifying theories about existing SLE research that provides novel insight or that can lead to the development of new technologies or approaches, or apply SLE technology to radically new application areas. New ideas/vision papers must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. * SLE Body of Knowledge: The SLE Body of Knowledge (SLEBoK) is a community-wide effort to provide a unique and comprehensive description of the concepts, best practices, tools, and methods developed by the SLE community. In this respect, the SLE conference will accept surveys, essays, open challenges, empirical observations, and case study papers on the SLE topics. These can focus on, but are not limited to, methods, techniques, best practices, and teaching approaches. Papers in this category can have up to 20 pages, including bibliography/appendices. * Tool papers: These papers focus on the tooling aspects often forgotten or neglected in research papers. A good tool paper focuses on practical insights that will likely be useful to other implementers or users in the future. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must not exceed 5 pages and may optionally include 1 further page of bibliography/appendices. They may optionally include an appendix with a demo outline/screenshots and/or a short video/screencast illustrating the tool. Workshops: Workshops will be organised by STAF. Please inform us and contact STAF 2025 organisers if you would like to organise a workshop of interest to the SLE audience. Information on how to submit workshops can be found on the STAF 2025 Website. --------------------------- Submission --------------------------- SLE 2025 has a single submission round for papers, including a mandatory abstract registration and a rebuttal phase, where all authors of research papers will have the possibility of responding to the reviews on their submissions. Authors of accepted research papers will be invited to submit artefacts. --------------------------- Format --------------------------- Submissions have to use the ACM SIGPLAN Conference Format “acmart” ( https://sigplan.org/Resources/Author/#acmart-format); please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template, and that the document class definition is `\documentclass[sigplan,anonymous,review]{acmart}`. Do not make any changes to this format! Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colours remain distinct and font sizes in figures and tables are legible. To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. Accordingly, SLE will follow the double-blind process. Author names and institutions must be omitted from submitted papers, and references to the authors’ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. All submissions must be in PDF format. The submission website is: https://sle25.hotcrp.com --------------------------- Concurrent Submissions --------------------------- Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy ( https://www.sigplan.org/Resources/Policies/Republication/). Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism ( https://www.acm.org/publications/policies/plagiarism-overview). Submissions that violate these policies will be desk-rejected. --------------------------- Policy on Human Participant and Subject Research --------------------------- Authors conducting research involving human participants and subjects must ensure that their research complies with their local governing laws and regulations and the ACM’s general principles, as stated in the ACM’s Publications Policy on Research Involving Human Participants and Subjects ( https://www.acm.org/publications/policies/research-involving-human-participants-and-subjects). If submissions are found to be violating this policy, they will be rejected. --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning soundness, relevance, novelty, presentation, and replicability. New ideas/vision papers will be evaluated primarily concerning soundness, relevance, novelty, and presentation. SLEBoK papers will be reviewed on their soundness, relevance, originality, and presentation. Tool papers will be evaluated concerning relevance, presentation, and replicability. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review at the discretion of the PC chairs. For research papers, authors will get a chance to respond to the reviews before a final decision is made. --------------------------- Artefact Evaluation --------------------------- SLE will use an evaluation process to assess the quality of artefacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted research papers are invited to submit artefacts. --------------------------- Awards --------------------------- * Distinguished paper: Award for the most notable paper, as determined by the PC chairs based on the recommendations of the program committee. * Distinguished artefact: Award for the artefact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artefact evaluation committee. * Distinguished reviewer: Award for the programme committee member that produced the most useful reviews as assessed by paper authors. * Most Influential Paper: Award for the SLE 2015 paper with the greatest impact, as judged by the SLE Steering Committee. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. **AUTHORS TAKE NOTE**: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. --------------------------- Organisation --------------------------- * General chair: Görel Hedin, Lunds Universitet, Sweden * PC co-chair: Regina Hebig, Universität Rostock, Germany * PC co-chair: Vadim Zaytsev, Universiteit Twente, The Netherlands * Publicity chair: Andrei Chiş, feenk gmbh, Switzerland * Local chair: Ralf Lämmel, Universität Koblenz, Germany --------------------------- Contact --------------------------- For additional information, clarification, or answers to any questions, please get in touch with the program co-chairs (regina.hebig at uni-rostock.de and vadim at grammarware.net). -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Wed Dec 25 03:49:53 2024 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Wed, 25 Dec 2024 16:49:53 +1300 Subject: [Haskell-cafe] [ghc-proposals] Allow reserved identifiers as fields ... Message-ID: And Merry Christmas to all. I counsel against allowing reserved ids to be anything other than reserved ids. "... is fraught with peril, unduly complicates the parser, and harms readability. " says a language implementer I asked. But wanting to use field names dictated outside this language's control is a realistic requirement, for which there are several general approaches. The ghc proposal as it stands seems ad-hoc and very specific to one user organisation. Furthermore, this just ain't true: > ... SQL schemas. anyone working with those is stuck deciding between special-casing its naming, and consistently naming *everything* weirdly, ... SQL consistently supports things like embedded spaces, fields starting upper-case [**], embedded dots or other graphics -- by no means just names that clash with reserved ids. How does it do that? And this answer seems particularly relevant when these ids are going to feed into `HasField` constraints as a type-level String: put the id between quotes. > orgNotification."type" doesn't look too ugly to my eye. And to spj's repeated point: I could envisage allowing fields in `data` decls and record syntax to be quoted. (Again you couldn't use punning nor field-name as function.) The approach is sufficiently general it could be extended to `#"Label naming"`. [**] I'm particularly keen on field names starting upper case, because they're injective/part of the structure, like data constructors. AntC (Why am I posting to the cafe, not github? I seem to be blocked from posting on any topic, either on github or gitlab -- even for pages where I'm the sole author. I'd be grateful if somebody could post the above to the PR.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Wed Dec 25 15:59:56 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Wed, 25 Dec 2024 07:59:56 -0800 Subject: [Haskell-cafe] [ghc-proposals] Allow reserved identifiers as fields ... In-Reply-To: References: Message-ID: I don't know the history of why you might be banned if you are, so I feel comfortable being the proxy. Regardless, I've posted my own opinion on github ( https://github.com/ghc-proposals/ghc-proposals/pull/668) just now and *I urge others to do the same*. Allowing keywords as anything but keywords is a very bad idea. It should not be allowed. Ivan On Tue, 24 Dec 2024 at 19:50, Anthony Clayden wrote: > And Merry Christmas to all. > > I counsel against allowing reserved ids to be anything other than reserved > ids. "... is fraught with peril, unduly complicates the parser, and > harms readability. " says a language implementer I asked. > > But wanting to use field names dictated outside this language's control is > a realistic requirement, for which there are several general approaches. > The ghc proposal as it stands seems ad-hoc and very specific to one user > organisation. Furthermore, this just ain't true: > > > ... SQL schemas. anyone working with those is stuck deciding between > special-casing its naming, and consistently naming *everything* weirdly, > ... > > SQL consistently supports things like embedded spaces, fields starting > upper-case [**], embedded dots or other graphics -- by no means just names > that clash with reserved ids. > > How does it do that? And this answer seems particularly relevant when > these ids are going to feed into `HasField` constraints as a type-level > String: put the id between quotes. > > > orgNotification."type" > > doesn't look too ugly to my eye. And to spj's repeated point: I could > envisage allowing fields in `data` decls and record syntax to be quoted. > (Again you couldn't use punning nor field-name as function.) > > The approach is sufficiently general it could be extended to `#"Label > naming"`. > > [**] I'm particularly keen on field names starting upper case, because > they're injective/part of the structure, like data constructors. > > AntC > > (Why am I posting to the cafe, not github? I seem to be blocked from > posting on any topic, either on github or gitlab -- even for pages where > I'm the sole author. I'd be grateful if somebody could post the above to > the PR.) > _______________________________________________ > 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 jm at memorici.de Thu Dec 26 14:24:26 2024 From: jm at memorici.de (Jons Mostovojs) Date: Thu, 26 Dec 2024 14:24:26 +0000 Subject: [Haskell-cafe] [ghc-proposals] Allow reserved identifiers as fields ... In-Reply-To: References: Message-ID: Dear Ivan, I normally don't post, but I got quite scared after reading your commentary of the proposal. However, upon closer inspection, it became evident that it doesn't allow overriding keywords as your post suggested. (While the changes to *fbind* allow more record constructions to parse, a construction such as ``C { type = e }}`` or ``C { foo.bar = e }`` will continue to be rejected during name resolution.) Finally – ad absurdum – ["let", "it", "be"] is a valid Haskell term, despite starting with a string which is a string literal coinciding with a keyword. — Kindest regards, ¬Σ On Wed, 25 Dec 2024 at 16:01, Ivan Perez wrote: > I don't know the history of why you might be banned if you are, so I feel > comfortable being the proxy. > > Regardless, I've posted my own opinion on github ( > https://github.com/ghc-proposals/ghc-proposals/pull/668) just now and *I > urge others to do the same*. > > Allowing keywords as anything but keywords is a very bad idea. It should > not be allowed. > > Ivan > > On Tue, 24 Dec 2024 at 19:50, Anthony Clayden > wrote: > >> And Merry Christmas to all. >> >> I counsel against allowing reserved ids to be anything other than >> reserved ids. "... is fraught with peril, unduly complicates the >> parser, and harms readability. " says a language implementer I asked. >> >> But wanting to use field names dictated outside this language's control >> is a realistic requirement, for which there are several general approaches. >> The ghc proposal as it stands seems ad-hoc and very specific to one user >> organisation. Furthermore, this just ain't true: >> >> > ... SQL schemas. anyone working with those is stuck deciding between >> special-casing its naming, and consistently naming *everything* weirdly, >> ... >> >> SQL consistently supports things like embedded spaces, fields starting >> upper-case [**], embedded dots or other graphics -- by no means just names >> that clash with reserved ids. >> >> How does it do that? And this answer seems particularly relevant when >> these ids are going to feed into `HasField` constraints as a type-level >> String: put the id between quotes. >> >> > orgNotification."type" >> >> doesn't look too ugly to my eye. And to spj's repeated point: I could >> envisage allowing fields in `data` decls and record syntax to be quoted. >> (Again you couldn't use punning nor field-name as function.) >> >> The approach is sufficiently general it could be extended to `#"Label >> naming"`. >> >> [**] I'm particularly keen on field names starting upper case, because >> they're injective/part of the structure, like data constructors. >> >> AntC >> >> (Why am I posting to the cafe, not github? I seem to be blocked from >> posting on any topic, either on github or gitlab -- even for pages where >> I'm the sole author. I'd be grateful if somebody could post the above to >> the PR.) >> _______________________________________________ >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Thu Dec 26 14:39:59 2024 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Thu, 26 Dec 2024 09:39:59 -0500 Subject: [Haskell-cafe] [ghc-proposals] Allow reserved identifiers as fields ... In-Reply-To: References: Message-ID: >> orgNotification."type" > > doesn't look too ugly to my eye. That's what nix has when you need fields that don't lex as identifiers. So, at least some people (including me) would be familiar with that. However, it does require a certain leap in the mental model at first. -- Best, Artem On Thu, Dec 26, 2024 at 9:24 AM Jons Mostovojs wrote: > Dear Ivan, > > I normally don't post, but I got quite scared after reading your > commentary of the proposal. > > However, upon closer inspection, it became evident that it doesn't allow > overriding keywords as your post suggested. > > > (While the changes to *fbind* allow more record constructions > to parse, a construction such as ``C { type = e }}`` or ``C { foo.bar = e > }`` > will continue to be rejected during name resolution.) > > Finally – ad absurdum – ["let", "it", "be"] is a valid Haskell term, > despite starting with a string which is a string literal coinciding with a > keyword. > > — > Kindest regards, > ¬Σ > > > On Wed, 25 Dec 2024 at 16:01, Ivan Perez > wrote: > >> I don't know the history of why you might be banned if you are, so I feel >> comfortable being the proxy. >> >> Regardless, I've posted my own opinion on github ( >> https://github.com/ghc-proposals/ghc-proposals/pull/668) just now and *I >> urge others to do the same*. >> >> Allowing keywords as anything but keywords is a very bad idea. It should >> not be allowed. >> >> Ivan >> >> On Tue, 24 Dec 2024 at 19:50, Anthony Clayden < >> anthony.d.clayden at gmail.com> wrote: >> >>> And Merry Christmas to all. >>> >>> I counsel against allowing reserved ids to be anything other than >>> reserved ids. "... is fraught with peril, unduly complicates the >>> parser, and harms readability. " says a language implementer I asked. >>> >>> But wanting to use field names dictated outside this language's control >>> is a realistic requirement, for which there are several general approaches. >>> The ghc proposal as it stands seems ad-hoc and very specific to one user >>> organisation. Furthermore, this just ain't true: >>> >>> > ... SQL schemas. anyone working with those is stuck deciding between >>> special-casing its naming, and consistently naming *everything* weirdly, >>> ... >>> >>> SQL consistently supports things like embedded spaces, fields starting >>> upper-case [**], embedded dots or other graphics -- by no means just names >>> that clash with reserved ids. >>> >>> How does it do that? And this answer seems particularly relevant when >>> these ids are going to feed into `HasField` constraints as a type-level >>> String: put the id between quotes. >>> >>> > orgNotification."type" >>> >>> doesn't look too ugly to my eye. And to spj's repeated point: I could >>> envisage allowing fields in `data` decls and record syntax to be quoted. >>> (Again you couldn't use punning nor field-name as function.) >>> >>> The approach is sufficiently general it could be extended to `#"Label >>> naming"`. >>> >>> [**] I'm particularly keen on field names starting upper case, because >>> they're injective/part of the structure, like data constructors. >>> >>> AntC >>> >>> (Why am I posting to the cafe, not github? I seem to be blocked from >>> posting on any topic, either on github or gitlab -- even for pages where >>> I'm the sole author. I'd be grateful if somebody could post the above to >>> the PR.) >>> _______________________________________________ >>> 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. > > _______________________________________________ > 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 allbery.b at gmail.com Thu Dec 26 14:48:40 2024 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 26 Dec 2024 09:48:40 -0500 Subject: [Haskell-cafe] [ghc-proposals] Allow reserved identifiers as fields ... In-Reply-To: References: Message-ID: The quote syntax has me vaguely wondering if there would be some interaction with OverloadedLabels, but I haven't looked closely enough to see if it would be an actual problem. On Thu, Dec 26, 2024 at 9:40 AM Artem Pelenitsyn wrote: > > >> orgNotification."type" > > > > doesn't look too ugly to my eye. > > That's what nix has when you need fields that don't lex as identifiers. > So, at least some people (including me) would be familiar with that. > However, it does require a certain leap in the mental model at first. > > -- > Best, Artem > > > > > On Thu, Dec 26, 2024 at 9:24 AM Jons Mostovojs wrote: > >> Dear Ivan, >> >> I normally don't post, but I got quite scared after reading your >> commentary of the proposal. >> >> However, upon closer inspection, it became evident that it doesn't allow >> overriding keywords as your post suggested. >> >> >> (While the changes to *fbind* allow more record constructions >> to parse, a construction such as ``C { type = e }}`` or ``C { foo.bar = e >> }`` >> will continue to be rejected during name resolution.) >> >> Finally – ad absurdum – ["let", "it", "be"] is a valid Haskell term, >> despite starting with a string which is a string literal coinciding with a >> keyword. >> >> — >> Kindest regards, >> ¬Σ >> >> >> On Wed, 25 Dec 2024 at 16:01, Ivan Perez >> wrote: >> >>> I don't know the history of why you might be banned if you are, so I >>> feel comfortable being the proxy. >>> >>> Regardless, I've posted my own opinion on github ( >>> https://github.com/ghc-proposals/ghc-proposals/pull/668) just now and *I >>> urge others to do the same*. >>> >>> Allowing keywords as anything but keywords is a very bad idea. It should >>> not be allowed. >>> >>> Ivan >>> >>> On Tue, 24 Dec 2024 at 19:50, Anthony Clayden < >>> anthony.d.clayden at gmail.com> wrote: >>> >>>> And Merry Christmas to all. >>>> >>>> I counsel against allowing reserved ids to be anything other than >>>> reserved ids. "... is fraught with peril, unduly complicates the >>>> parser, and harms readability. " says a language implementer I asked. >>>> >>>> But wanting to use field names dictated outside this language's control >>>> is a realistic requirement, for which there are several general approaches. >>>> The ghc proposal as it stands seems ad-hoc and very specific to one user >>>> organisation. Furthermore, this just ain't true: >>>> >>>> > ... SQL schemas. anyone working with those is stuck deciding >>>> between special-casing its naming, and consistently naming *everything* weirdly, >>>> ... >>>> >>>> SQL consistently supports things like embedded spaces, fields starting >>>> upper-case [**], embedded dots or other graphics -- by no means just names >>>> that clash with reserved ids. >>>> >>>> How does it do that? And this answer seems particularly relevant when >>>> these ids are going to feed into `HasField` constraints as a type-level >>>> String: put the id between quotes. >>>> >>>> > orgNotification."type" >>>> >>>> doesn't look too ugly to my eye. And to spj's repeated point: I could >>>> envisage allowing fields in `data` decls and record syntax to be quoted. >>>> (Again you couldn't use punning nor field-name as function.) >>>> >>>> The approach is sufficiently general it could be extended to `#"Label >>>> naming"`. >>>> >>>> [**] I'm particularly keen on field names starting upper case, because >>>> they're injective/part of the structure, like data constructors. >>>> >>>> AntC >>>> >>>> (Why am I posting to the cafe, not github? I seem to be blocked from >>>> posting on any topic, either on github or gitlab -- even for pages where >>>> I'm the sole author. I'd be grateful if somebody could post the above to >>>> the PR.) >>>> _______________________________________________ >>>> 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. >> >> _______________________________________________ >> 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Thu Dec 26 22:15:00 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Thu, 26 Dec 2024 14:15:00 -0800 Subject: [Haskell-cafe] [ghc-proposals] Allow reserved identifiers as fields ... In-Reply-To: References: Message-ID: > > On Thu, Dec 26, 2024 at 9:24 AM Jons Mostovojs wrote: >> >>> Dear Ivan, >>> >>> I normally don't post, but I got quite scared after reading your >>> commentary of the proposal. >>> >>> However, upon closer inspection, it became evident that it doesn't allow >>> overriding keywords as your post suggested. >>> >>> >>> (While the changes to *fbind* allow more record constructions >>> to parse, a construction such as ``C { type = e }}`` or ``C { foo.bar = >>> e }`` >>> will continue to be rejected during name resolution.) >>> >>> It's literally from the motivating example (bold mine): @parsonsmatt commented on Jul 22 > > "This should enable the use of HasField "type" s a instances to be used > with OverloadedRecordDot -* foo.type.*" https://github.com/ghc-proposals/ghc-proposals/pull/668#issue-2423570608 https://gitlab.haskell.org/ghc/ghc/-/issues/24174 Both of those seem to indicate that a construction like *foo.type* would be allowed with that extension on. Not *foo."type"*, but *foo.type*. Also, I think we should strongly reconsider the choices being made in language design if anyone is seriously considering that, to avoid having to write foo.type_ the way to go is to design an extension that would have people write foo."type" Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.d.clayden at gmail.com Thu Dec 26 22:37:04 2024 From: anthony.d.clayden at gmail.com (Anthony Clayden) Date: Fri, 27 Dec 2024 11:37:04 +1300 Subject: [Haskell-cafe] [ghc-proposals] Allow reserved identifiers as fields ... In-Reply-To: References: Message-ID: On Fri, 27 Dec 2024 at 03:48, Brandon Allbery wrote: > The quote syntax has me vaguely wondering if there would be some > interaction with OverloadedLabels, ... > > Yes, OverloadedLabels is the thin end of the wedge. `#type` is already supported without quotes, and that's used as justification for `.type`. (But Labels starting upper case or with embedded spaces, etc aren't supported.) It's also something of a lexing/parsing disaster. ... > > > Indeed. Specifically all the developer tools are (I suspect) going to continue to treat `type` as a keyword (unless quoted). How does `blah.type` show in Visual Studio? This proposal doesn't for example include modifying HLS for the new context-awareness around reserved ids. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Thu Dec 26 23:00:19 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Thu, 26 Dec 2024 15:00:19 -0800 Subject: [Haskell-cafe] [ghc-proposals] Allow reserved identifiers as fields ... In-Reply-To: References: Message-ID: Just because it's possible to disambiguate with enough context, doesn't mean it's a good idea to add it. I've heard the idea of using keywords as identifiers in Haskell being proposed decades ago. It was a bad idea then, and it's a bad idea today. This extension would make Haskell harder to read. To save one character, we now have to have more context when reading Haskell. It's harder for newcomers. It's harder for experienced users. It's harder for syntax highlighters. What good reason could possibly exist to even entertain this thought? Please, make Haskell code easier to read. Ivan On Thu, 26 Dec 2024 at 14:37, Anthony Clayden wrote: > > > On Fri, 27 Dec 2024 at 03:48, Brandon Allbery wrote: > >> The quote syntax has me vaguely wondering if there would be some >> interaction with OverloadedLabels, ... >> >> > Yes, OverloadedLabels is the thin end of the wedge. `#type` is already > supported without quotes, and that's used as justification for `.type`. > (But Labels starting upper case or with embedded spaces, etc aren't > supported.) > > It's also something of a lexing/parsing disaster. ... >> >> >> > Indeed. Specifically all the developer tools are (I suspect) going to > continue to treat `type` as a keyword (unless quoted). How does `blah.type` > show in Visual Studio? > > This proposal doesn't for example include modifying HLS for the new > context-awareness around reserved ids. > > _______________________________________________ > 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 ivanperezdominguez at gmail.com Fri Dec 27 15:38:23 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 27 Dec 2024 07:38:23 -0800 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions In-Reply-To: References: Message-ID: Following up on this. Would there be interest in improving HPC and adding these features? Ivan On Thu, 24 Oct 2024 at 10:30, Ivan Perez wrote: > Ryan -- thanks! > > Café, GHC Devs -- is anyone actively working on HPC? > > Thanks, > > Ivan > > PS. Putting David Binder in CC since he seems to have been one of the most > active contributors as of lately. > > On Thu, 24 Oct 2024 at 07:57, Ryan Scott wrote: > >> Hi Ivan, >> >> Short answer: I'm not aware of a way to automate the process of excluding certain definitions from cabal-generated HPC coverage reports. >> >> Long answer: there is a way to manually modify HPC coverage reports using the hpc overlay command. Sadly, most the existing documentation on this command [1] is pretty sparse, so the only way I was able to discover this was by reading the original HPC paper [2] (in that paper, `hpc overlay` is called `hpc-makemtix`) and by finding an example of how to use `hpc overlay` in GHC's test suite [3]. To translate that example into prose: suppose you have the following program (hpc001.hs): >> >> main = print (const "Hello" "World") >> >> Here, the expression "World" is never evaluated, so by default HPC will claim that there is no coverage for it. This is pretty silly, however, so we'd like to instruct HPC not to warn about "World". To do so, first compile the example above with coverage enabled and run it: >> >> $ ghc -fhpc hpc001.hs $ ./hpc001 >> >> This should generate an hpc001.tix file. If you run `hpc markup hpc001.tix` and look at the resulting HTML report, you'll see that it warns about "World". Let's fix that. To do so, we have to define an HPC overlay file. The example given in GHC's test suite (sample_overlay.ovr) is: >> >> module "Main" { >> inside "main" { >> tick "\"World\"" on line 1; >> } >> } >> >> While I can't find a reference for the syntax that HPC overlay files use, this particular example is pretty self-explanatory: don't report about the expression "World" on line 1, which is found inside the `main` function in the `Main` module. In order to make use of this overlay file, we first have to convert it to a .tix file: >> >> $ hpc overlay sample_overlay.ovr > sample_overlay1.tix >> >> Then we have to combine it with our original .tix file: >> >> $ hpc combine hpc_sample.tix sample_overlay1.tix > total1.tix >> >> If we run `hpc markup total1.txt`, we now see that HPC no longer warns about "World", just as we'd hoped for. >> >> That is where my understanding of this feature ends, however. In particular, I'm not aware of a better way to generate overlay files (other than to write them by hand, which still feels somewhat laborious), and I'm not aware of any deeper integration with cabal so that these overlay files would be picked up and automatically applied (e.g., for reporting coverage on Hackage). Given that the HPC documentation for `hpc overlay` [1] labels this as an experimental feature, I'd be surprised if such tooling or integration existed. I agree that it would be cool if did, however. >> >> Best, >> >> Ryan >> ----- >> [1] https://hpc-bin.readthedocs.io/en/latest/hpc.html#hpc-overlay-and-hpc-draft >> [2] https://dl.acm.org/doi/abs/10.1145/1291201.1291203 >> [3] https://gitlab.haskell.org/ghc/ghc/-/blob/e39c8c993c1da534c5893ca418d1fa4cbb9e0a0a/testsuite/tests/hpc/simple/tixs/test.T#L44-50 >> >> _______________________________________________ >> 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 ben at smart-cactus.org Sun Dec 29 00:50:20 2024 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 28 Dec 2024 19:50:20 -0500 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions In-Reply-To: References: Message-ID: <878qrzia8d.fsf@smart-cactus.org> Ivan Perez writes: > Following up on this. > > Would there be interest in improving HPC and adding these features? > Indeed David Binder is currently the one thinking most about HPC. The general idea here sounds reasonable, although there is a some design work needed to bridge the gap between the idea and a supportable, user-facing feature. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From ietf-dane at dukhovni.org Sun Dec 29 18:57:41 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Dec 2024 05:57:41 +1100 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions In-Reply-To: <878qrzia8d.fsf@smart-cactus.org> References: <878qrzia8d.fsf@smart-cactus.org> Message-ID: On Sat, Dec 28, 2024 at 07:50:20PM -0500, Ben Gamari wrote: > Ivan Perez writes: > > > Following up on this. > > > > Would there be interest in improving HPC and adding these features? > > Indeed David Binder is currently the one thinking most about HPC. > The general idea here sounds reasonable, although there is a some > design work needed to bridge the gap between the idea and a supportable, > user-facing feature. Indeed. FWIW, this thread reminds me of a curiousity with HPC vs. case analysis involving "otherwise". case foo of X | ... -> ... | otherwise -> ... HPC always flags incomplete coverage of "otherwise", because it always evaluated True! :-) -- Viktor. From ivanperezdominguez at gmail.com Sun Dec 29 20:13:35 2024 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 29 Dec 2024 12:13:35 -0800 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions In-Reply-To: References: <878qrzia8d.fsf@smart-cactus.org> Message-ID: Wrt otherwise, yes, I also found that a bit confusing. Ivan On Sun, 29 Dec 2024 at 10:58, Viktor Dukhovni wrote: > On Sat, Dec 28, 2024 at 07:50:20PM -0500, Ben Gamari wrote: > > Ivan Perez writes: > > > > > Following up on this. > > > > > > Would there be interest in improving HPC and adding these features? > > > > Indeed David Binder is currently the one thinking most about HPC. > > The general idea here sounds reasonable, although there is a some > > design work needed to bridge the gap between the idea and a supportable, > > user-facing feature. > > Indeed. FWIW, this thread reminds me of a curiousity with HPC vs. case > analysis involving "otherwise". > > case foo of > X | ... -> ... > | otherwise -> ... > > HPC always flags incomplete coverage of "otherwise", because it always > evaluated True! :-) > > -- > Viktor. > _______________________________________________ > 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 ietf-dane at dukhovni.org Sun Dec 29 20:32:01 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Dec 2024 07:32:01 +1100 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions In-Reply-To: References: <878qrzia8d.fsf@smart-cactus.org> Message-ID: On Sun, Dec 29, 2024 at 12:13:35PM -0800, Ivan Perez wrote: > Wrt otherwise, yes, I also found that a bit confusing. Well, it isn't that confusing, it is a boolean function that has never been tested well enough to observe the effect of it returning False. :-) It is slightly surprising when first observed, but clear enough why this was flagged. -- Viktor. From amindfv at mailbox.org Sun Dec 29 21:32:48 2024 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Sun, 29 Dec 2024 13:32:48 -0800 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions In-Reply-To: References: <878qrzia8d.fsf@smart-cactus.org> Message-ID: On Mon, Dec 30, 2024 at 07:32:01AM +1100, Viktor Dukhovni wrote: > On Sun, Dec 29, 2024 at 12:13:35PM -0800, Ivan Perez wrote: > > > Wrt otherwise, yes, I also found that a bit confusing. > > Well, it isn't that confusing, it is a boolean function that > has never been tested well enough to observe the effect of > it returning False. :-) It is slightly surprising when > first observed, but clear enough why this was flagged. It's clear enough why this would happen, but it's serving the compiler, not the user. On an intuitive level, you want to be able to say "I have 100% test coverage" and not waste time on what are essentially false positives. Here's another annoying example: main :: IO () main = do _ <- foo pure () The unit ("()") is marked as "never executed" and highlighted in yellow, and expression coverage falls below 100%. While that may literally be true, this falls - for the programmer just trying to get something done - under the category of "why am I looking at this?" HPC is a great tool and a few human-aware improvements could really help quality of life (and HPC's adoption, imo). - Tom From ietf-dane at dukhovni.org Sun Dec 29 21:42:39 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 30 Dec 2024 08:42:39 +1100 Subject: [Haskell-cafe] Configuring cabal to tell HPC to ignore certain functions In-Reply-To: References: <878qrzia8d.fsf@smart-cactus.org> Message-ID: On Sun, Dec 29, 2024 at 01:32:48PM -0800, amindfv--- via Haskell-Cafe wrote: > On Mon, Dec 30, 2024 at 07:32:01AM +1100, Viktor Dukhovni wrote: > > On Sun, Dec 29, 2024 at 12:13:35PM -0800, Ivan Perez wrote: > > > > > Wrt otherwise, yes, I also found that a bit confusing. > > > > Well, it isn't that confusing, it is a boolean function that > > has never been tested well enough to observe the effect of > > it returning False. :-) It is slightly surprising when > > first observed, but clear enough why this was flagged. > > It's clear enough why this would happen, but it's serving the > compiler, not the user. I don't entirely disagree, though I also learned something useful (that is perhaps after the fact obvious, but only with some experience) from "otherwise" being flagged, which is that HPC covers evaluatio of expressions, not just execution of lines of code, and that for expressions that are branch heads it also checks whether both paths are taken. ... So it was educational (the first time). One of course nowdays define: patten Else :: Bool pattern Else = True and use "Else" instead of otherwise, and then perhaps the impossible branch not taken would not be flagged? > Here's another annoying example: > > main :: IO () > main = do > _ <- foo > pure () > > The unit ("()") is marked as "never executed" and highlighted in > yellow, and expression coverage falls below 100%. While that may > literally be true, this falls - for the programmer just trying to get > something done - under the category of "why am I looking at this?" > > HPC is a great tool and a few human-aware improvements could really > help quality of life (and HPC's adoption, imo). I really like HPC. But sure, some twkeaks might go a long way. -- Viktor.