- Haskell-Cafe - Haskell.org

[ANN] mig-0.2 library to build servers and clients
by Anton Kholomiov 10 Nov '23

10 Nov '23

I’m happy to announce the latest release of mig-0.2 <https://github.com/anton-k/mig> library. It is a library to write composable servers for simple / boring haskell. The main focus of this release is the ability to serve Swagger UI from the server with ease and ability to create clients from the same code as servers. I’m happy to confirm that both goals are reached with this release. The tutorial for the library <https://anton-k.github.io/mig/> was created. Also there are many other improvements: - OpenApi schema for servers - swagger servers support (we can add swagger to server with one line of code: withSwagger def server ) - clients from the same code as servers - redesign of internal types - redesign of DSL for routes - many ergonomic improvements - packages for extra utils - split of mig package to several packages: - mig <https://hackage.haskell.org/package/mig> - core - mig-wai <https://hackage.haskell.org/package/mig-wai> - rendering servers to wai apps - mig-client <https://hackage.haskell.org/package/mig-client> - clients - mig-extra <https://hackage.haskell.org/package/mig-extra> - extra utils - mig-server <https://hackage.haskell.org/package/mig-server> - mig servers with batteries - mig-swagger-ui <https://hackage.haskell.org/package/mig-swagger-ui> - swagger ui server - tutorial and quickstart guide <https://anton-k.github.io/mig/> on github pages - CI for repo with formatter, build and tests and update of docs on github pages The internal type for Servers was redesigned so that we assemble the handler function with API description at the same time. In the first release it was just a handler function under the hood. As a refresher mig <https://github.com/anton-k/mig> is a family of libraries to write lightweight, simple, type-safe and composable servers. It strives to be in the middle ground between scotty and servant. To be composable, flexible and type-safe as servant and simple and lightweight in concepts as scotty. One thing that interesting to think about as Server is a first-class value and all servers have the same type and we have just a small number of functions to compose them (they are link server to path and make alternative routes with Monoid) it’s interesting to explore the possibility of creation small grain-like servers for typical tasks. For example, a server can be a function from interfaces (logging, DB or something else) to server value and we can join them together on various paths. This idea is interesting to consider. Thanks to Ambros for contribution. Also I’d like to thank the authors of packages servant, servant-swagger-ui and servant-openapi3 packages for inspiration for my work in this release. Many lines of code are influenced by those packages. Links: - github <https://github.com/anton-k/mig> - tutorial <https://anton-k.github.io/mig/> - mig on hackage <https://hackage.haskell.org/package/mig> also see packages mig-server <https://hackage.haskell.org/package/mig-server> and mig-client <https://hackage.haskell.org/package/mig-client>. - examples <https://github.com/anton-k/mig/tree/main/examples/mig-example-apps> Cheers, Anton

1 0

[ANN] Copilot 3.17
by Ivan Perez 09 Nov '23

09 Nov '23

Hi everyone!! We are very excited to announce Copilot 3.17 [2]. Copilot is a stream-based EDSL in Haskell for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Copilotis being used at NASA in drone test flights. Through the NASA tool Ogma [1] (also written in Haskell), Copilot also serves as a runtime monitoring backend for NASA's Core Flight System, Robot Operating System (ROS2), and FPrime (the software framework used in the Mars Helicopter) applications. This release introduces compatibility with what4 versions up to 1.5.1, and replaces several functions in copilot-core. The second change is a breaking change: the functions replaced have been deprecated and new alternatives introduced instead. As always, we're releasing exactly 2 months since the last release. Our next release is scheduled for Jan 7th, 2024. In our last announcement, we mentioned that Copilot has received full approval for release as NASA Class D open-source software. Current emphasis is on increasing test coverage for the two remaining libraries without tests (copilot-libraries and copilot-theorem), removing unnecessary dependencies, hiding internal definitions, and formatting the code to meet our new coding standards. Users are encouraged to participate by opening issues and asking questions via our github repo [3]. There have been many updates on the Copilot front in the last few months. We'll be able to announce more soon. Stay tuned. Happy Haskelling! Ivan [1] https://github.com/nasa/ogma [2] https://github.com/Copilot-Language/copilot/releases/tag/v3.17 [3] https://github.com/Copilot-Language/copilot [4] https://hackage.haskell.org/package/copilot

1 0

Call for Contributions: BOB 2024 [March 15, Deadline Nov 17]
by Stefan Wehr 03 Nov '23

03 Nov '23

======================================================================== BOB Conference 2024 "What happens when we use what's best for a change?" https://bobkonf.de/2024/cfc.html Berlin, Mar 17 Call for Contributions Deadline: November 17, 2023 ======================================================================== You are actively engaged in advanced software engineering methods, solve ambitious problem with software and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions. Specifically: - advice on structure and presentation - review of talk slides Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, and speakers who are not able to attend the conference for financial reasons. Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - "fancy types" (dependent types, gradual typing, linear types, ...) - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - program synthesis - next-generation IDEs - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be - … includeing rough ideas worth discussing. Presenters should provide the audience with information that is practically useful for software developers. Challenges ---------- Furthermore, we seek contributions on successful approaches for solving hard problems, for example: - bias in machine-learning systems - digital transformation in difficult settings - accessibiltity - systems with critical reliability requirements - ecologically sustainable software development We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) Organisation ------------ - Direct questions to konferenz at bobkonf dot de - Proposal deadline: November 17, 2023 - Notification: December 5, 2023 - Program: December 12, 2023 Submit here: https://pretalx.com/bob-2024/submit/ Program Committee ----------------- (more information here: https://bobkonf.de/2024/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg

1 0

Question on Lexing Haskell syntax
by Travis Athougies 03 Nov '23

03 Nov '23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 According to the Haskell report [1] (See Note 5), a virtual `}` token is inserted if parsing the next token would cause a parse error and the indentation stack is non-empty. I'm trying to lex and parse Haskell source and this sort of interplay (which requires two-way communication between lexer and parser) makes it very difficult to write a conformant implementation. I can't change the standard (obviously), but I'm wondering if this is actually what GHC (de facto the only Haskell compiler) does, or if it applies some other rule. If so, does anyone know the exact mechanism of its implementation? I've been programming Haskell for more than a decade, and while I have an intuitive understanding of the indentation rules, I would have assumed the source could be lexed without also having a parser. In particular, the note seems to imply that the main purpose of this is to properly lex `let`/`in` bindings. Perhaps there's an alternate equivalent rule? Curious to hear other's thoughts. Travis [1] https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17800… -----BEGIN PGP SIGNATURE----- iIsEARYKADMWIQRW81c55hOCXuY5k/H+BxaRGQDTjQUCZUGARhUcdHJhdmlzQGF0 aG91Z2llcy5uZXQACgkQ/gcWkRkA041W+wEA/7n5NejGTYu4O6N+Pt7Rn0bBRw6D 5D96idagahXqXioA/18hxYFpY45lWwB7pKCh83xQJu2Bcwkxj1xhhCEZBcoA =FrDy -----END PGP SIGNATURE-----

5 6

Munich Haskell Meeting, 2023-10-31 @ 19:30
by Leah Neukirchen 31 Oct '23

31 Oct '23

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, October 31 at Iveria (Lindwurmstraße 159A) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can reserve enough seats! It is OK to add yourself to the nuudel anonymously or pseudonymously. https://nuudel.digitalcourage.de/7ST4pxNRVj3rGLdO Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

2 1

Re: [Haskell-cafe] Should GHC 9.4.7 be native on MacBook Air M2?
by David Banas 29 Oct '23

29 Oct '23

Ah, I needed this line in my stack.yaml file: arch: aarch64 Why is that? Shouldn’t it use the native architecture if it can support it? -db

2 1

Should GHC 9.4.7 be native on MacBook Air M2?
by David Banas 29 Oct '23

29 Oct '23

I’m working on a new MacBook Air M2. I just bumped my current Haskell project to stack LTS-21.17, after catching up on the GHC porting effort news. I did a stack clean / stack build and saw GHC 9.4.7 being installed, as expected, but still to the x86_64-osx directory: % l ~/.stack/programs x86_64-osx % l ~/.stack/programs/x86_64-osx ghc-8.10.3 ghc-8.10.4.tar.bz2 ghc-8.6.3.installed ghc-9.0.2 ghc-9.2.2.tar.bz2 ghc-9.2.7.installed ghc-8.10.3.installed ghc-8.4.3 ghc-8.6.3.tar.bz2 ghc-9.0.2.installed ghc-9.2.5 ghc-9.2.7.tar.bz2 ghc-8.10.3.tar.bz2 ghc-8.4.3.installed ghc-8.6.5 ghc-9.0.2.tar.bz2 ghc-9.2.5.installed ghc-9.4.7 ghc-8.10.4 ghc-8.4.3.tar.bz2 ghc-8.6.5.installed ghc-9.2.2 ghc-9.2.5.tar.bz2 ghc-9.4.7.installed ghc-8.10.4.installed ghc-8.6.3 ghc-8.6.5.tar.bz2 ghc-9.2.2.installed ghc-9.2.7 ghc-9.4.7.tar.bz2 I was expecting a native version; do I misunderstand something?

1 0

Simplest way to move a ... `using` ... line into the IO monad?
by David Banas 28 Oct '23

28 Oct '23

Hi all, What is the simplest way to translate a non-monadic line of Haskell code, such as: res = map foo xs `using` parList rseq For use in the IO monad? This doesn’t work: res <- mapM fooM xs `using` parTraversable rseq complaining: No Traversable instance for IO. Thanks, -db

4 6

Re: [Haskell-cafe] when does ghc(i) expand type synonyms?
by Olaf Klinke 27 Oct '23

27 Oct '23

> ghci> :set +t > > ghci> "foo" > "foo" > it :: String > > ghci> reverse "foo" > "oof" > it :: [Char] I'm not a GHC expert, but my guess is: It must have something to do with unifying the argument types with the type signature of the function. In (<>), the two argument and the result types are identical. Hence it can be safely said that x <> whatever as long as this expression is valid, has the same type as x. In contrast, the result type of (++) is always of the shape [a]. Hence String gets unified with [a] which forces expansion of the type synonym. Consider: class Foo a where {rev :: a -> a; conc :: a -> a -> a} instance Foo [a] where {rev = reverse; conc = (++)} revconc :: Foo a => a -> a; revconc a = conc a (rev a) :t revconc ("foo" :: String) revconc ("foo" :: String) :: String So as long has you hide (++) in a type signature that proves input and output are the same, synonyms don't get expanded. Olaf

1 0

when does ghc(i) expand type synonyms?
by Johannes Waldmann 26 Oct '23

26 Oct '23

Dear cafe, my students were asking: why are types printed differently here? ghci> :set +t ghci> "foo" "foo" it :: String ghci> reverse "foo" "oof" it :: [Char] ... and I add ghci> fst ("foo", 42) "foo" it :: String compiler docs do not really explain the difference https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html#ghci-cm… (it says "display the type of .." while technically it is "display some representation of the type of ..."?) I found this explanation of a somewhat related issue https://gitlab.haskell.org/ghc/ghc/-/issues/9183#note_83743 While playing around with this, I noticed: ghci> let x = "foo" in (x <> reverse x) "foooof" it :: String ghci> let x = "foo" in (x ++ reverse x) "foooof" it :: [Char] Well, it's just optics: when I extract the type programmatically, the synonym necessarily does get expanded ghci> import Data.Data ghci> typeOf (let x = "foo" in (x <> reverse x)) [Char] it :: TypeRep - Johannes

2 1