- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] ghci's choice of names for type variables
by Johannes Waldmann 30 Oct '21

30 Oct '21

Just from observing the behaviour (not the source) - it seems that ghci tries to use the variables from the declaration of the/a function, type, or class that is being used. Prelude> data T c = T c Prelude> h x y = (T x, T y) Prelude> :t h h :: c1 -> c2 -> (T c1, T c2) Prelude> f :: foo -> foo ; f x = x Prelude> g = f Prelude> :t g g :: foo -> foo In the Haskell Standard, type variables are a, b, ... mostly (always?), hence you get `a` for anything with lists and Num. If there's no type to refer to, then your examples show that it's using t or p, but I don't know how. Prelude> i x = x Prelude> :t i i :: p -> p Prelude> k x y = x Prelude> :t k k :: p1 -> p2 -> p1 Prelude> s x y z = x z (y z) Prelude> :t s s :: (t1 -> t2 -> t3) -> (t1 -> t2) -> t1 -> t3 interesting! - J.W.

1 1

Re: [Haskell-cafe] simple word processor
by Olaf Klinke 27 Oct '21

27 Oct '21

> I am new to haskell and I need to create a simple word processor. It needs > to read text from the cmd and implement functions that would edit functions > found in the text so some other text.All functions in the text are odered. > Each function i.e section,table,figures and ref must be located and > numbered independently based on the order of occurence. Since tables and > figures are within the sections function(just like a book), when a new > section is encountered you will reset the value of tables and figures. So i > did a loop where the tables and figures are inside the section loop when > searching for the functions. The functions all start with this '' character > (escape character) and must be replaced with text using this method: > \Section{title}{id}: -> "Section n: title". Where n is the section number. > \table{title}{id} : -> "Table n.m : title". Where n is the number of the > last section encountered and m is the table number. And so on. Let me try to break your problem into sub-problems. 1. You have text where some patterns have meaning to your particular application (e.g. "\Section{title}{id}"). 2. When knowing this structure, you want to transform it from front to back while updating some counters. 3. Once that transformation is done, you want to write the structure back into a plain text. How to approach: 1. is addressed with parsers. There are plenty to choose from, e.g. parsec, attoparsec, megaparsec to name just tree applicative-style libraries. A parser looks for patterns in plain text and transforms it into a more stuctured type. The structured type may be somethig like data Block a = SomeText Text | Section Text a | Table Text s | etc. The parsing function will have a type similar to Text -> Either ParseError [Block ()] where () stands for a numbering that is not yet known. 2. May be modeled as a stateful traversal. First define a state with all the counters, say data Counters = Counters { theSection :: Int, theTable :: Int} Next define a traversal function Block () -> State Counters (Block Text) where the unknown numbering () is replaced with the appropriate Text- representation of theSection or (theSection,theTable) etc. Finally, traverse your parsed list of Blocks with this traversal. 3. essentially requires a Show instance for your (Block Text) type together with concatenation. Steps 1-3 will be combined like follows. fmap ((=<<) show . flip evalState start . traverse number) . parse where parser :: Text -> Either ParseError [Block ()] start :: Counters number :: Block () -> State Counters (Block Text) "traversal" -> hoogle for Data.Traversable "stateful" -> hoogle for Control.Monad.State Olaf

1 0

xmonad 0.17.0, xmonad-contrib 0.17.0 released!
by Brandon Allbery 27 Oct '21

27 Oct '21

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ XMONAD AND XMONAD-CONTRIB 0.17.0 ARE AVAILABLE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ New versions of xmonad and xmonad-contrib have been released. Check out our [download page] for instructions on where to get them. It's been a little over 3 years since xmonad 0.15, and a little over 2 years since xmonad-contrib 0.16. A lot has happened. This post is an overview of the most important changes. To celebrate this milestone, we would like to announce a contest for a new xmonad logo (see section 3). Last but not least, in section 4 we're looking to raise funds to keep the XMonad project and community alive and relevant in the next decade. With the [final X.Org Server 21.1 release] being announced today, there are some obvious challenges ahead of us. [download page]: <https://xmonad.org/download.html> [final X.Org Server 21.1 release]: <https://lists.x.org/archives/xorg-announce/2021-October/060799.html> 1 xmonad 0.17.0 ═══════════════ This release includes 156 non-merge commits by 22 contributors! For a full summary of all the changes, see [xmonad's CHANGES.md] file. [xmonad's CHANGES.md]: <https://github.com/xmonad/xmonad/blob/v0.17.0/CHANGES.md> 1.1 Major Breaking Changes ────────────────────────── • `util/GenerateManpage.hs' is no longer distributed in the tarball. 1.2 Selected Features and Improvements ────────────────────────────────────── • Migrated `X.L.LayoutCombinators.(|||)' into `XMonad.Layout', providing the ability to directly jump to a layout with the `JumpToLayout' message. • Improved handling of XDG directories. 1. If all three of xmonad's environment variables (`XMONAD_DATA_DIR', `XMONAD_CONFIG_DIR', and `XMONAD_CACHE_DIR') are set, use them. 2. If there is a build script called `build' (see [here] for usage examples) or configuration `xmonad.hs' in `~/.xmonad', set all three directories to `~/.xmonad'. 3. Otherwise, use the `xmonad' directory in `XDG_DATA_HOME', `XDG_CONFIG_HOME', and `XDG_CACHE_HOME' (or their respective fallbacks). These directories are created if necessary. In the cases of 1. and 3., the build script or executable is expected to be in the config dir. Additionally, the xmonad config binary and intermediate object files were moved to the cache directory (only relevant if using XDG or `XMONAD_CACHE_DIR'). • Recompilation now detects `stack.yaml' (can be a symlink) alongside `xmonad.hs' and switches to using `stack ghc'. Additionally, deprecation warnings during recompilation are no longer suppressed. These can still be suppressed manually using an `OPTIONS_GHC' pragma with `-Wno-deprecations'. [here]: <https://github.com/xmonad/xmonad-testing/tree/master/build-scripts> 2 xmonad-contrib 0.17.0 ═══════════════════════ This release includes 582 non-merge commits by 57 contributors! For a full summary of all the changes, see [xmonad-contrib's CHANGES.md] file. [xmonad-contrib's CHANGES.md]: <https://github.com/xmonad/xmonad-contrib/blob/v0.17.0/CHANGES.md> 2.1 Major Breaking Changes ────────────────────────── • All modules that export bitmap fonts as their default • If xmonad is compiled with XFT support (the default), use an XFT font instead. The previous default expected an X11 misc font (PCF), which is not supported in pango 1.44 anymore and thus some distributions have stopped shipping these. • All modules still exporting a `defaultFoo' constructor • All of these were now removed. You can use the re-exported `def' from `Data.Default' instead. • `XMonad.Hooks.StatusBar', `XMonad.Hooks.StatusBar.PP' (previously `XMonad.Hooks.DynamicLog') and `XMonad.Util.Run' • `spawnPipe' no longer uses binary mode handles and defaults to the current locale encoding instead, `xmonadPropLog' and `xmonadPropLog'' now encode their input string in UTF-8, and `dynamicLogString' no longer encodes its output in UTF-8. When these functions are used together, everything should continue to work as it always has, but in isolation behaviour might change. To get the old `spawnPipe' behaviour, `spawnPipeWithNoEncoding' can now be used, and `spawnPipeWithUtf8Encoding' was added as well to force UTF-8 regardless of locale. • `XMonad.Hooks.DynamicLog' will be deprecated soon in favor of `XMonad.Hooks.StatusBar' which offers a nicer and easier to use interface for status bars. Laptop users who (dis)connect external monitors dynamically should definitely try this new interface: `XMonad.Hooks.DynamicBars' has been deprecated already. • `XMonad.Hooks.EwmhDesktops' • It is no longer recommended to use standalone hooks directly: Instead of `ewmhDesktopsStartup', `ewmhDesktopsLogHook(Custom)' and `ewmhDesktopsEventHook(Custom)', users should now use the `ewmh' combinator. The `Custom' variants have been replaced by a [more composable interface] which now also allows simply marking windows that request focus as urgent instead of immediately focusing them. Instead of `fullscreenEventHook', use `ewmhFullscreen', which now advertises fullscreen support to applications, fixing fullscreen in [mpv] and many others. • `XMonad.Hooks.Script' • `execScriptHook' now has an `X' constraint (was: `MonadIO'), due to changes in how the xmonad core handles XDG directories. • `XMonad.Actions.WorkspaceNames' • The type of `getWorkspaceNames' was changed to fit into the new `ppRename' field of `PP'. [more composable interface]: <https://xmonad.github.io/xmonad-docs/xmonad-contrib-0.17.0/XMonad-Hooks-Ewm…> [mpv]: <https://mpv.io/> 2.2 Selected Features and Improvements ────────────────────────────────────── • `XMonad.Actions.EasyMotion' A new module that allows selection of visible screens using a key chord—inspired by [vim-easymotion]. See the animation in the vim-easymotion repo to get some idea of the functionality of this EasyMotion module. • `XMonad.Prompt.OrgMode' A prompt for interacting with [org-mode]. It can be used to quickly save TODOs, NOTEs, and the like with the additional capability to schedule/deadline a task, or use the primary selection as the contents of the note. • `XMonad.Hooks.StatusBar' A new module, providing a nicer, composable interface for status bars that replaces `XMonad.Hooks.DynamicLog' and `XMonad.Hooks.DynamicBars'. Supports property-based as well as pipe-based status bars, multiple status bars (Xinerama), and takes care of restarting the bars as needed. • `XMonad.Hooks.Rescreen' A new module, providing custom hooks for screen (xrandr) configuration changes. These are used internally by `XMonad.Hooks.StatusBar' to restart status bars/systrays after xrandr, and can also be used to invoke xrandr or autorandr when an output is (dis)connected. • `XMonad.Util.Hacks' A collection of hacks and fixes that should be easily accessible to users, like a fix for the fullscreen behaviour of chromium based applications when using windowed fullscreen, or a fix to make certain Java applications play more nicely with xmonad. • `XMonad.Hooks.WindowSwallowing' A new module to implement window swallowing; optionally via sublayouting. Hide parent windows like terminals when opening other programs (like image viewers) from within them, restoring them once the child application closes. • `XMonad.Util.ClickableWorkspaces' A new module providing `clickablePP', which when applied to the `PP' pretty-printer used by `XMonad.Hooks.StatusBar.PP', will make the workspace tags clickable in XMobar (for switching focus). Note that `XMonad.Layout.IndependentScreens' and `XMonad.Actions.WorkspaceNames' now also use the same composable `ppRename' interface as `XMonad.Util.ClickableWorkspaces' so it's much easier to use them with one another. • `XMonad.Util.Loggers' • Added `logTitles' to log all window titles (focused and unfocused ones) on the focused workspace, as well as `logTitlesOnScreen' as a screen-specific variant thereof. • `XMonad.Actions.TopicSpace' • Added `TopicItem', as well as the helper functions `topicNames', `tiActions', `tiDirs', `noAction', and `inHome' for a drastically simpler specification of topics. • `XMonad.Hooks.ServerMode' • To make it easier to use, the `xmonadctl' client is now included in `scripts/'. [vim-easymotion]: <https://github.com/easymotion/vim-easymotion> [org-mode]: <https://orgmode.org/> 3 Logo Contest ══════════════ We'd also like to announce a contest to create a new xmonad logo to replace the current one. If you want to participate, please submit at most /three/ logos (in SVG format) to [this GitHub Discussion] by the 31st of January. Please do not vote for a logo yet—voting will start after the above deadline. Your logo will need to be licensed under a suitable freely distributable license; for example, the CC BY-SA 4.0. The prize for the winner is `$100'! For voting, we will use an [instant-runoff] type system. In short: • Users rank a minimum of three submissions according to their preferences in decreasing order. • If a logo wins a majority of first-preference votes (> 50%) it is chosen. • If not, we eliminate the logo with the least amount of first preference votes, exposing the second preference of those who voted for it. • Rinse and repeat until we have a majority. • If at the end of all that we still don't have a majority, we will act as a tiebreaker and internally vote for a winner from the remaining logos. We will retain veto power in case of inappropriate logos. Team members whose submitted entries are amongst the remaining choices will not partake in the potential tiebreaking vote. [this GitHub Discussion]: https://github.com/xmonad/xmonad/discussions/343 [instant-runoff]: <https://en.wikipedia.org/wiki/Instant-runoff_voting> 4 Looking for Funding ═════════════════════ TL;DR: We would love your support to keep xmonad alive! You can support us via [GitHub Sponsors] and the [Open Collective] is our fiscal host such that our funds are fully transparent. [GitHub Sponsors]: <https://github.com/sponsors/xmonad> [Open Collective]: <https://opencollective.com/xmonad> XMonad has been around since 2007 and has a great track record in stability. There's an active, vibrant community of users and developers who help each other and contribute fixes and extensions. Keeping this community organized, reviewing and merging contributions and responding to bug reports is almost a full-time job, however, not to mention doing actual development. We've been struggling to find volunteers to do all this work, especially the less exciting bits like documentation. Despite that struggle, we managed to repay a portion of our technological and organizational debt over the last year, and to pick up the [pace of development]. We're worried about the sustainability of that pace, however. As with the previous generations of maintainers, our studies and sabbaticals won't last forever. Your help is needed to keep the project alive and well! We'd like to raise enough funds to enable at least one core developer to work on XMonad full-time (or several part-time). To learn more about our plans for the future, see our [GitHub Sponsors] profile. Thanks to [one unexpected appearance on the Hacker News front page], we already gathered a couple dozen sponsors who donate in total over $300 a month. We're incredibly grateful for this support! Our fiscal host is the [Open Source Collective], so our budget is fully transparent on [our Collective's page]. If you also want to aid our efforts going forward, please consider becoming a supporter as well. We accept both monthly and one-time donations through [GitHub Sponsors] and [Open Collective]. Thank you! [pace of development]: https://xmonad.org/images/xmonad-0-17/commits.svg [GitHub Sponsors]: <https://github.com/sponsors/xmonad> [one unexpected appearance on the Hacker News front page]: <https://news.ycombinator.com/item?id=28793941> [Open Source Collective]: <https://www.oscollective.org/> [our Collective's page]: <https://opencollective.com/xmonad> [Open Collective]: <https://opencollective.com/xmonad> -- brandon s allbery kf8nh allbery.b(a)gmail.com

1 0

type inference and FFI
by PICCA Frederic-Emmanuel 27 Oct '21

27 Oct '21

Hello, I have a bunch of C method that I need to call like this c'foo_unit16_t :: Ptr Word16 -> IO r c'foo_uint32_t :: Ptr Word32 -> IO r ... These methodes are called from a method like this process :: NativeType t => Dataframe t => IO r process df = do ... <pseudo code> case typeof t of WORD16 -> c'foo_unit16_t ... WORD32 -> c'foo_uint32_t ... Since there is type erasure, I would like to know what is the best way to write this process method. thanks for you help Frederic

2 1

simple word processor
by Dennis Gaita 26 Oct '21

26 Oct '21

-1 <https://stackoverflow.com/posts/69702739/timeline> I am new to haskell and I need to create a simple word processor. It needs to read text from the cmd and implement functions that would edit functions found in the text so some other text.All functions in the text are odered. Each function i.e section,table,figures and ref must be located and numbered independently based on the order of occurence. Since tables and figures are within the sections function(just like a book), when a new section is encountered you will reset the value of tables and figures. So i did a loop where the tables and figures are inside the section loop when searching for the functions. The functions all start with this '' character (escape character) and must be replaced with text using this method: \Section{title}{id}: -> "Section n: title". Where n is the section number. \table{title}{id} : -> "Table n.m : title". Where n is the number of the last section encountered and m is the table number. And so on. I need help because my code isn't running.This is the code: import Text.Format import Data.Text.Internal.Search import Data.Text s = count . "section" -- count number of occurences of a certain word t = count . "table" f = count . "Figure" r = count . "ref" forLoop :: Int - Int - Int - Int forLoop s value = if i < s then forLoop (i + 1) format "Section{title}{id}" [show i, show {title}] then replace "Section{i}{title}" "Section {i}:{title}" else value forLoop t value = if j < t then forLoop (j + 1) format "table{title}{id}" [show i.j, show {title}] --change the text then replace "table{i}.{j}{title}" "Table {i}.{j} : {title}" else value forLoop f value = if k < f then forLoop (k + 1) format "figure{title}{id}" [show i.k, show {title}] --change the text then replace "Figure{title}{id}" "Figure {i}.{k} : {title}" else value if "ref{id}" == "table{title}" then forLoop r value = if l < r then forLoop (l + 1) format "ref{id}" [show {title}] --change the text then replace "ref{id}" "see {title} {i}.{j}" else value else Nothing if "ref{id}" == "Figure{title}" then forLoop r value = if m < r then forLoop (m + 1) format "ref{id}" [show {title}] --change the text then replace "ref{id}" "see {title} {i}.{m}" else value else Nothing if "ref{id}" == "Section{title}" then forLoop r value = if n < r then forLoop(n+1) format "ref{id}" [show{title}] then replace "ref{id}" "see {title} {i}" else value else nothing

1 0

Numerics (was: Re: Trouble with asinh)
by Barak A. Pearlmutter 25 Oct '21

25 Oct '21

The numerics in Haskell have not been carefully vetted, for a variety of reasons. Not just under MS Windows, even under Linux. Here's an example: atan has drastic loss of precision in the imaginary direction around zero in the complex domain. $ ghci GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help Prelude> :m + Data.Complex Prelude Data.Complex> tan (1e-20 :+ 0) 1.0e-20 :+ 0.0 Prelude Data.Complex> atan (1e-20 :+ 0) 1.0e-20 :+ (-0.0) Prelude Data.Complex> tan (0 :+ 1e-20) 0.0 :+ 1.0e-20 Prelude Data.Complex> atan (0 :+ 1e-20) 0.0 :+ (-0.0) Although there have been amazing efforts to use fancy PLT methods to improve the numerics of programs using source-to-source transformations and such, the boring janitorial work of checking and fixing numeric issues in the standard library doesn't seem to attract people. To be fair, it isn't my cup of tea either...

6 7

[ANN] hslua 2.0.0, bridging Haskell and Lua
by Albert Krewinkel 23 Oct '21

23 Oct '21

I am pleased to announce the release of [HsLua] 2.0.0; a collection of packages offering (bidirectional) glue and abstractions bridging Haskell and Lua. HsLua is a featureful framework, enabling Haskell programmers to combine the embeddable scripting language Lua with code written Haskell. This new release is an almost complete rewrite and offers better performance, cleaner types, and adds more abstraction helpers. It supports exposing data and functions from Haskell to Lua in a convenient and structured way. Probably the best-known real world use case of HsLua is [pandoc], the universal document converter, where it serves as the central building block for [Lua filters] and custom writers. Contributions are welcome. [HsLua]: https://hslua.org [pandoc]: https://pandoc.org [Lua filters]: https://pandoc.org/lua-filters.html -- Albert Krewinkel GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124

1 0

Munich Haskell Meeting, 2021-10-26 @ 19:30
by Leah Neukirchen 22 Oct '21

22 Oct '21

Dear all, next week, our monthly Munich Haskell Meeting will take place again on Tuesday, October 26 at Augustiner-Gaststätte Rumpler(!!) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle until Tuesday 12:00 so we can reserve enough seats! 3G rules apply. It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-oct-2021/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

unexpected compile error with wrapped HList
by Zoran Bošnjak 22 Oct '21

22 Oct '21

Hello members, I am struggling to compile the snippet below. GHC version is 8.10.4. If I try to construct the 'Variation' (with the type signature), I am getting an unexpected error. (see the comments in the code below). The error is only present if the HList is empty. I would appreciate a suggestion how to fix it. regards, Zoran --- {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE PolyKinds #-} module Test where import Data.Kind data (a::k1) :<< (b::k2) infixr 5 :<< data HList (ts :: [Type]) where HNil :: HList '[] HCons :: x -> HList xs -> HList (x ': xs) data TVariation = TVariation1 | TVariation2 data Variation vt where Variation1 :: HList ts -> Variation ('TVariation1 :<< ts) Variation2 :: HList ts -> Variation ('TVariation2 :<< ts) -- This works as expected, including the explicit type signature. x1 :: Variation ('TVariation1 :<< '[()]) x1 = Variation1 (HCons () HNil) -- But the following 2 cases do not work as expected. -- 1. problem: -- This 'x0' type is inferred by GHC, -- but when specified as such, it won't compile. {- • Couldn't match type ‘k’ with ‘*’ ‘k’ is a rigid type variable bound by the type signature for: x0 :: forall k. Variation ('TVariation1 :<< '[]) at adhoc/test.hs:39:1-38 Expected type: Variation ((:<<) @TVariation @[k] 'TVariation1 ('[] @k)) Actual type: Variation ((:<<) @TVariation @[*] 'TVariation1 ('[] @*)) • In the expression: Variation1 HNil In an equation for ‘x0’: x0 = Variation1 HNil • Relevant bindings include x0 :: Variation ('TVariation1 :<< '[]) (bound at adhoc/test.hs:40:1) -} x0 :: Variation ('TVariation1 :<< '[]) x0 = Variation1 HNil class Empty t where mkEmpty :: t -- 2. problem: -- This instance declaration reports the same problem (as in x0 above). instance Empty (Variation ('TVariation1 :<< '[])) where mkEmpty = Variation1 HNil

2 1

Downsides to disabling unticked-promoted-constructor warning?
by Markus Läll 21 Oct '21

21 Oct '21

Hi! Is there any consensus on unticked promoted constructors -- are they generally safe to use? Currently the warning is part of -Wall, but having promoted constructors unticked is just aesthetically nicer. Thanks, -- Markus Läll

4 5

You're invited to the October virtual Haskell CoHack
by Chris Smith 19 Oct '21

19 Oct '21

Hi everyone, This Saturday, I’m once again hosting a virtual Haskell CoHack. In the past, we’ve had a great time with groups here working on various projects, whether it’s learning Haskell, hacking on GHC, writing documentation, making progress on personal projects, or just hanging out to chat with like-minded folk. You should consider coming if you would be excited to meet fellow Haskell programmers and work or learn together with them. There are details, including times, on the meetup page: https://www.meetup.com/NY-Haskell/events/280998863

1 0

GDB and ticks
by Henning Thielemann 18 Oct '21

18 Oct '21

I am stepping through a Haskell program using the GNU debugger GDB and see function calls to handle_tick, handleProfTick, stopTicker all over the place. It sounds like they would manage profiling, but I compiled the executable without profiling.

5 8

Looking for ESOP'22 AEC members
by Andreea Costea 18 Oct '21

18 Oct '21

For the first time since its foundation, ESOP will carry out an Artifact Evaluation process. The goal is to share with the community the research artefacts of papers accepted to its research track, acknowledging those works which have been rigorously implemented, tested and documented. To this purpose, we are looking for motivated students and postdocs to be members of the ESOP 2022 Artifact Evaluation Committee (AEC). The primary responsibility of an AEC member is to run the associated tools and confirm the results reported in the papers. If you know someone suitable for this role, please nominate them in the following form (or share the form with them for self-nomination): https://t.co/Jqa7edDqTg?amp=1 Come join us in this effort! Kind Regards, Andreea Costea and KC Sivaramakrishnan, AEC Co-Chairs of ESOP 2022

1 0

Bug in Data.Bits.shift?
by Keith 17 Oct '21

17 Oct '21

As currently defined, `shift x minBound` calls `shiftR` with a negative displacement. This would avoid that: ``` shift x n | n >= 0 = shiftL x n | n == minBound = shiftR (shiftR x maxBound) 1 | otherwise = shiftR x (-n) ``` P.S. Philosophically, `rotate` on a negative `Integer` should do sign extension in the least significant bits (though by the description of `rotate` it should not...). — Sent from my phone with K-9 Mail.

3 3

Resources on how to implement (Haskell 98) kind-checking?
by Benjamin Redelings 16 Oct '21

16 Oct '21

Hi, 1. I'm looking for resources that describe how to implement kind Haskell 98 checking. Does anyone have any suggestions? * I've looked at the PolyKinds paper, but it doesn't cover type classes. * I've looked at the source code to GHC, but it is hard to follow for a variety of reasons. It isn't laid out like an algorithm description, and the complexity to handle options like PolyKinds and DataKinds makes the code harder to follow. 2. One question that came up is how to handle type variables that are present in class methods, but are not type class parameters. If there are multiple types/classes in a single recursive group, the kind of such type variables might not be fully resolved until a later type-or-class is processed. Is there a recommended approach? I can see two ways to proceed: i) First determine the kinds of all the data types, classes, and type synonyms. Then perform a second pass over each type or class to determine the kinds of type variables (in class methods) that are not type class parameters. ii) Alternatively, record the kind of each type variable as it is encountered -- even though such kinds may contain unification kind variables. After visiting all types-or-classes in the recursive group, replace any kind variables with their definition, or with a * if there is no definition. I've currently implement approach i), which requires doing kind inference on class methods twice. Is this the recommended approach? 3. Also, is Haskell 98 kind checking the same as Haskell 2010 kind checking? -BenRI

8 12

Public floggings
by Michael Turner 13 Oct '21

13 Oct '21

>> Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be > publicly flogged on a regular basis. Since I'm to blame for raising the subject that turned into a thread about "the right exposition", I hereby surrender myself to be flogged in lieu of the intended. I've deserved it for years, just for how I've found perversely delightful ways to use the C preprocessor. Especially token-pasting. K&R (the book) was almost indecent exposure -- it left nothing to the imagination. As opposed to most writing on Haskell, where I'm befuddled because it's not at all obvious how it does its thing. It's like you're not /supposed/ to know. But K&R let it all hang out, and for that reason, I loved it. Whip me, beat me, make me write C code. Because that's just the kind of pervert I am. Still, sometimes. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry

2 1

[ANN] linear-generics
by David Feuer 12 Oct '21

12 Oct '21

I am pleased to announce the release of a new package, linear-generics[*], based on GHC.Generics and the venerable generic-deriving. The killer features: 1. Generic1 representations associate compositions the right way around, which is to say the *left* way around, meaning no more inefficient fmaps or pesky Functor constraints. 2. to, from, to1, and from1 are multiplicity polymorphic, so you can use them in all your fancy new linearly typed code. The package includes Template Haskell-based deriving, based closely on generic-deriving, which is the recommended way to write instances. There is also a limited, somewhat unsafe, and somewhat inefficient way using provided DerivingVia targets. Many thanks to Arnaud Spiwack and Ryan Scott for valuable advice and assistance. [*] https://hackage.haskell.org/package/linear-generics

1 0

Partially applied type synonyms
by Ttt Mmm 09 Oct '21

09 Oct '21

I was surprised to find the below code doesn't typecheck even with -XLiberalTypeSynonyms. Am I missing something or is this really not possible? Thanks, Tom --- {-# LANGUAGE FlexibleInstances, KindSignatures, LiberalTypeSynonyms, StandaloneDeriving #-} -- This works: data Foo s x = Foo (s x) x deriving (Eq) -- This replacement doesn't: {- data Foo' sx x = Foo' sx x deriving (Eq) type Foo (s :: * -> *) (x :: *) = Foo' (s x) x -} data Bar (m :: * -> *) = Bar (m Int) -- Neither of these typecheck: x :: Bar (Foo Maybe) x = undefined deriving instance Eq (Bar (Foo Maybe))

3 6

[ANN] Cabal-3.4.1.0, cabal-install-3.4.1.0, Cabal-3.6.2.0, and cabal-install-3.6.2.0
by Emily Pillmore 09 Oct '21

09 Oct '21

Hello Haskell, The Cabal team is excited to announce the release of `Cabal-3.6.2.0`, and `cabal-install-3.6.2.0`. ## Changelog for `Cabal-3.6.2.0` and `cabal-install-3.6.2.0` This is the fifth release of the 3.0 release series for both packages. This minor version release introduces a set of fixes for some regressions seen when the tool interacts with `autoconf`, as well as some fixes for regressions to the way Paths_ modules interact with non-standard preludes: - Making Paths_ modules work with non-standard preludes again [#5962]( https://github.com/haskell/cabal/issues/5962 ) - Generate Paths_ module with qualified Data.List.last import so that compatibility with non-standard preludes is not regressed compared to cabal 3.4. - Windows: redo the fix to breakage caused by new autoconf; the wrong fix made cabal sometimes fail with old autoconf [#7494]( https://github.com/haskell/cabal/issues/7494 ) [#7649]( https://github.com/haskell/cabal/issues/7649 ) - Reverts #7510 that failed on Windows when used with pre-generated scripts included in packages such as network, time, process. - Adds a subtler fix/workaround for the deficiencies of new autoconf versions on Windows. **IMPORTANT NOTE**: The last bug affects configuration files generated with `autoconf-2.70` or later. They will not work with `cabal-3.4.0.0`. Please either upgrade to `3.4.1.0` or the new `3.6.2.0` releases. I'd like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help! Happy hacking!

1 0

Examples of Continuation monad that impossible to understand and maintain?
by YueCompl 08 Oct '21

08 Oct '21

Dear Cafe, I'm wrapping up my CPS codebase to provide some monadic interface, it appears almost the Cont monad, so the following statement is a pretty valid caveat to me now: > Abuse of the Continuation monad can produce code that is impossible to understand and maintain. Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:tex… <https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:tex… of the Continuation monad can produce code that is impossible to understand and maintain> But I can't find concrete examples demonstrating the "impossible to understand and maintain" situation, in figuring out what pitfalls I'd rather to avoid. Please share what you know about it, many appreciations! Background of my CPS necessarity: Library code need to delegate STM transaction boundary delimitation to (scripting) application code, though `inlineSTM :: STM a -> m a` can be used to force some action to be within current tx, the usual `>>=` binding should honor whether a separate `atomically` tx should be issued for its rhs computation, as specified by the scripting context. Thanks, Compl

4 8

Re: [Haskell-cafe] Partially applied type synonyms
by Anthony Clayden 08 Oct '21

08 Oct '21

> I was surprised to find the below code doesn't typecheck even with -XLiberalTypeSynonyms. Am I missing something or is this really not possible? Reading the error message would help: * The type synonym `Foo' should have 2 arguments, but has been given 1 -XLiberalTypeSynonyms relaxes the 'saturated application' rule a little https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/liberal_type_synony… "You can apply a type synonym to a partially applied type synonym:" But that isn't what you're doing. The docs say that still " ... malformedness ... * Partially-applied type synonym." Type Synonyms are not functions. Think of them as 'macro' expansions. Possibly your `Bar` could be a type synonym, taking `(Foo Maybe)` as an argument in the `instance Eq`. What type is it exactly that you want to derive an instance for?

2 1

Re: [Haskell-cafe] Public floggings
by Anthony Clayden 07 Oct '21

07 Oct '21

> how I've found perversely delightful ways to use the C preprocessor. Especially token-pasting. Then boy! do I have an offer for you/you'll be like a pig in muck. There's a Haskell compiler written in C++, using all the tricks you love: * #define nested inside #if, so you're never quite sure which version of a macro is in play. * #defines that expand to a series of assignments and routine calls. * Module-wide and global variables that get updated as side-effects of routine calls (as well as those routines passing back results) * All data structures being cons pairs deeply nested, typically routines poke into hd(hd(tl(e))) or some such. Someone's generously put the source online https://github.com/FranklinChen/hugs98-plus-Sep2006/tree/master/src You can load it up into Visual Studio, and produce a genuine Windows executable with a Haskell REPL. (Ah, silly me, of course you'd want the familiar *nix command line -- that's even easier.) And there's real work you could contribute to https://mail.haskell.org/pipermail/hugs-bugs/2021-October/thread.html Enjoy!

1 0

Monomorphism restriction [Was: Rank2Types in let bindings]
by Olaf Klinke 07 Oct '21

07 Oct '21

> > {-# LANGUAGE RankNTypes #-} > > newtype General = General { > > useGeneral :: forall a. Integral a => a -> Bool > > } > > > > doesNotWork :: General > > doesNotWork = let > > g = even :: forall a. Integral a => a -> Bool > > b = specializeGeneral g > > in General g > > > > doesWork :: General > > doesWork = let > > g = General even > > b = specializeGeneral (useGeneral g) > > in g > > > > specializeGeneral :: (Int -> Bool) -> Bool > > specializeGeneral p = p 5 > > > > I was under the impression that one can always use a more general type > > where a more special type is needed. In `doesNotWork` above, despite the > > explicit Rank-2 type annotation, usage in `specializeGeneral` apparently > > makes the compiler infer the type of `g` to be (Int -> Bool) and > > complains that `a` can not me matched with `Bool`. What gets me is that > > the compiler error is at `General g`, so the compiler must have ignored > > my Rank-2 type annotation. Should it be allowed to do that? > > > > Olaf > > Hi Olaf, > > This is the monomorphism restriction. g is a binding without a > signature, so it gets specialized. The type annotation is part of the > body of g, but if you want to generalize g it should be a separate > declaration > > let g :: forall ... > g = ... > Oh, thanks! I should have suspected. But somehow I feel my type annotation should have circumvented the monomorphism restriction. So g = even is a pattern binding and therefore subject to monomorphism restriction, regardless of following type annotation? So thanks for teaching me that it is not irrelevant where to place a type annotation. To this day I believed that name = expression :: type and name :: type name = expression are equivalent because one is syntactic sugar for the other. Do the two give rise to different elements in the abstract syntax tree? Am I the only one who finds this odd? Which Haskell book should I have read to be aware of this? The Consequences part in Section 4.5.5 of the Haskell report mentions the distinction between function an pattern bindings, but is not clear about the position of the type annotation. It merely states "the user must be careful to affix these [pattern bindings] with type signatures to retain full overloading". Olaf

2 1

Re: [Haskell-cafe] Terminator syntax style (Was: Nested (=>) (Was: On finding the right exposition...))
by Douglas McIlroy 07 Oct '21

07 Oct '21

>> Could you say what "terminator syntax style" is? I'm not finding any >> hits on popular search engines. > https://wiki.haskell.org/Terminator_vs._separator Apropos of "finding the right exposition", consider this definition in the cited wiki article: Separator: There is a symbol between each element. The more carefully you read this the more it becomes nonsense. 1, "Each element" is an individual. You can't put something between an individual. 2 The defining sentence states a property of a representation of a sequence. It fails to indicate that "separator" is the symbol's role. In fact what's being defined is "separator notation", not the bare word "separator". The proper usage appears only later in the article. It should be employed throughout--most importantly in the title and the definition. The same goes for "terminator". Doug

1 0

Re: [Haskell-cafe] mine sockets lib vs yesod
by Branimir Maksimovic 06 Oct '21

06 Oct '21

> On 27.09.2021., at 12:13, Mikolaj Konarski <mikolaj.konarski(a)gmail.com> wrote: > > Hi Branimir, > >> I guess that if I port it to Haskell purely from CPP, I won’t have problems with copyright? > > I will retain exactly the same copyright it had. To get rid of the old > copyright, you'd need to clean-room re-implement it (you yell ideas > from another room and somebody implements them in Haskell not having > seen the CPP code beforehand). OK. > >> if using -threaded performance is *worse*. > > This is normal. You trade performance for the ability to pre-empt > (e.g., not get stuck on blocking FFI). > > Kind regards, > Mikolaj I will implement it whole in Haskell, in async fashion as it seems with current hardware bandwith is saturated with just single CPU/Core. Greettings, Branimir.

1 1

Rank2Types in let bindings
by Olaf Klinke 05 Oct '21

05 Oct '21

Dear Cafe, apologies if this is a duplicate question. I want to define an element of a Rank-2 type, use its specialization and then return the general thing. Apparently this is not possible without a newtype. {-# LANGUAGE RankNTypes #-} newtype General = General { useGeneral :: forall a. Integral a => a -> Bool } doesNotWork :: General doesNotWork = let g = even :: forall a. Integral a => a -> Bool b = specializeGeneral g in General g doesWork :: General doesWork = let g = General even b = specializeGeneral (useGeneral g) in g specializeGeneral :: (Int -> Bool) -> Bool specializeGeneral p = p 5 I was under the impression that one can always use a more general type where a more special type is needed. In `doesNotWork` above, despite the explicit Rank-2 type annotation, usage in `specializeGeneral` apparently makes the compiler infer the type of `g` to be (Int -> Bool) and complains that `a` can not me matched with `Bool`. What gets me is that the compiler error is at `General g`, so the compiler must have ignored my Rank-2 type annotation. Should it be allowed to do that? Olaf

2 1

Re: [Haskell-cafe] On finding the right exposition...
by Anthony Clayden 05 Oct '21

05 Oct '21

> ... I never understood why (->) is right associative in types, but (=>) is not and you are instead supposed to pack constraints in a tuple. `-XRankNTypes` enables something called Rank 1 types, which accepts this: > foo :: Ord a => Num b => a -> Show b => b > -- foo :: (Ord a, Num b, Show b) => a -> b -- inferred/canonical We should also have: > bar :: forall a. forall {- empty -}. forall b. blah > -- bar :: forall a b. blah -- equivalent But `PatternSynonyms` drives a cart and horses through that: you must have exactly 2 `... => ... => ...` and exactly 2 `forall`s (possibly empty) -- that is, if you explicitly quantify at all. Or you can go: > MyPat :: Num a => a -> Baz a -- which is shorthand for > MyPat :: Num a => () => a -> Baz a -- which is equiv to > MyPat :: Num a => Num a => a -> Baz a > MyPat :: () => Num a => a -> Baz a -- this means something different

2 1

Re: [Haskell-cafe] On finding the right exposition
by Douglas McIlroy 05 Oct '21

05 Oct '21

>> Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be > publicly flogged on a regular basis. > And for so many other reasons, too, like mandating a preprocessor (with > a complex, operationally defined semantics) simply because they couldn't > be bothered to design a (simple, 1st order) module system. Manners, please. Such immoderate words have no place on this mailing list. Doug

1 0

Massaging data from the `extensible` package
by Ruben Astudillo 05 Oct '21

05 Oct '21

Hello cafe I have been enjoying the `extensible` package [1] for extensible records and variants, kudos to the author. I have had a problem of not understanding how to "massage" data from one representation to another. To exemplify, suppose I have the following two extensible records {-# language OverloadedLabels #-} import Data.Extensible import Control.Lens type Ext1 = Record '[ "field1" >: String, "field2" >: Integer ] type Ext2 = Record '[ "field1" >: Text, "field2" >: Double ] and I want to map some piece of data between these two types. Currently I am projecting each field individually like this ex1 :: Ext1 ex1 = #field1 @= "hello" <: #field2 @= 2.71 <: nil currentMap :: Ext1 -> Ext2 currentMap s = #field1 @= T.pack (view #field1 s) <: #field2 @= fromInteger (view #field2 s) <: nil For data types with few fields it is not so bad. But I have to do this transformation of data types generated from TH, I am dealing with a few dozens. The transformations are always from `String -> Text` and `Integer -> Double`. I would like to write a high lever combinator that grabs an extensible record, transforms each `String` field on a `Text` one and does the same with `Integer -> Double`. Most of the combinators for transforming the data deal with natural transformations, such as hmap, hsequence and the like. The closest one to what I want is `hfoldMapFor` where I have to define a class with instances for all the types the extensible record has, but it doesn't let me change the type of the result. Does anyone have an idea on how to solve this? Thanks for your time. [1]: https://hackage.haskell.org/package/extensible -- Rubén. (pgp: 4EE9 28F7 932E F4AD)

3 5

Re: [Haskell-cafe] On finding the right exposition...
by Anthony Clayden 05 Oct '21

05 Oct '21

> GHC's use of a State-like monad to represent I/O is semantically bogus, .... I wouldn't take it as a good mental model. Indeed. I fondly remember that in my intro text (the 'Gentle Introduction'), there was a warning this section is not so gentle. But I was already well through the book so it didn't seem such a drama. I'd already figured that 'mentally evaluating' code wasn't about contents of memory locations. For Monads esp I/O, 'programmable semicolon' or 'workflow' might be a better model. Ref the current discussion, I'm expecting a learner would spend a long time writing expressions at the ghci prompt; investigating their type; chucking in a few in-line decls with `let { }`. Dropping those decls into a source file -- which would contain only decls, not even a `module { }` header. A few simple `do{ ; }` blocks at the prompt. I was advocating lambda-calculus for the pure function evaluation parts of an intro. Higher-order functions, partial evaluation, operator sections, (un)currying. The o.p. was having trouble with a signature like `(a -> b -> c) -> a -> b -> d`. Later remarks expressed surprise why function application wasn't written `add(x, y)`. The (very old) paper mentioned was nearly all pure code. Without a firm basis grokking type signatures, the Monad operators are going to seem deeply weird. If you're used to 'higher-order function' meaning something that passes round an entry point for a block of code, partial application will take some head-scratching. And I can see if you're used to `x ++` meaning something and `x+=1` meaning something similar and `* y` meaning something completely different and `(x +)` being a syntax error, Haskell is going to feel strange. (Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be publicly flogged on a regular basis. Why couldn't they just follow the model of BCPL, which is far more elegant and consistent in its syntax. They stole nearly everything else from BCPL.) Which reminds me ... My all-time favourite language intro text is still http://rabbit.eng.miami.edu/info/bcpl_reference_manual.pdf This serves also as a language definition.This was thrown at undergrads, and they were left to get on with it. (There was also a 'User Guide' that talked about the operating environment, debugging, IO and file handling -- essentially equiv to Haskell's Appendixes on the base modules.) I note again, the language is small and elegant (expressible in A5 minimanual format). Similarly, you can get enough of lambda-calculus on a few sheets of A4. I contrast that 'Category Theory for Programmers' (mentioned in this thread) is 500 pages, and not even a language primer, although it contains snippets of code. How many hundred pages must I read before I'm allowed to write a Foldable instance? I'm up to 100, and we seem to be still preparing the ground for what is an endomorph.

4 5

Vectors, vector spaces and type-level Haskell
by Stuart Hungerford 05 Oct '21

05 Oct '21

Greetings Haskellers, I'd like to model in Haskell two-dimensional vectors that "belong to" or "have an ambient space of" a two dimensional vector space. I'm also ignoring for now the issue of which field the vector space is over. I realize this is not strictly necessary to just start using 2D vectors, but I would like to bring the vector space in as a first class concept. Looking at for example this approach: https://hackage.haskell.org/package/linear-1.21.7/docs/Linear-V2.html, I get the impression this is likely to need some kind of type-level construct? e.g. type families or type-level literals? I haven't started learning yet about Haskell type-level programming so I thought I'd ask for advice first to see how this could be done idiomatically in Haskell either with or without type-level concepts. TIA, Stu

4 11

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 218, Issue 5
by Stuart Hungerford 05 Oct '21

05 Oct '21

On Mon, Oct 4, 2021 at 11:10 PM <haskell-cafe-request(a)haskell.org> wrote: > [...] > The V2 and V3 etc. types provided by the linear package (which you > already found) model vectors in 2- and 3-dimensional real vector spaces, > over the field given by their 'a' type parameter. Wanting to add a > vector from a 2-dimensional vector space over 'a' and a vector from a > 3-dimensional vector space over 'b' entails adding a 'V2 a' and 'V3 b'; > those are distinct types. The vector space of 'V2 a' is morally 'a^2'. > > It seems this satisfies what you want. Are there other guarantees you > want enforced at compile time that this cannot give you? Thanks Tom -- you're right this is enough for compile time guarantees. This need to encode dimensionality into a type seems to be a compelling use-case for type-level numbers or other type-level capabilities (which I've avoided learning about until now). Stu

1 0

Pattern guards seen in the wild?
by Anthony Clayden 04 Oct '21

04 Oct '21

Browsing some docos for a completely other purpose, I came across this code: > f' [x, y] | True <- x, True <- y = True > f' _ = False (In User Guide 6.7.4.5 Matching of Pattern Synonyms.) That business with the comma and left-arrows? They're 'Pattern guards', Language Report 2010 section 3.13. That also specs 'local bindings' introduced by `let`. In 10 years of reading Haskell code, I've never seen them. Does anybody use them? Are they more ergonomic than guards as plain Boolean expressions? Are 'local bindings' any different vs shunting the `let` to the rhs of the `=`? I'd write that code as: > f'' [x@True, y@True] = True > f'' _ = False I can see the rhs of the matching arrow could in general be a more complex expression. But to express that you could put a more complex Boolean guard(?) AntC

5 4

list of range
by PICCA Frederic-Emmanuel 04 Oct '21

04 Oct '21

Hello, I need to parse a commande line which allows user to describe indices like this 1 -> only one indice 1-5 -> [1..5] 1-5 6-10 ...-> [1..5] ++ [6..10] My question is what it the best type in order to store this information ? Range Int = Range Int | RangeFromTo Int Int | Range Int <+> Range Int At some point I would like to add the possibility to have multiples Indices with the ',' 1,3,5 -> [1,3,5] list of indices This type is used at some point as a List. My question is, are you aware of a similar type in the standar library. This is the kind of information tahth w should parse when we request to print pages. (list of pages to print). Cheers Frederic

4 8

Better writing about Haskell through multi-metaphor learning
by Michael Turner 04 Oct '21

04 Oct '21

Well, this is certainly blowing up into something bigger than I thought it would. (At one point last night, 12 people had my "Haskell in Plain English" essay/chapter open on Google Docs, a very unintentional side effect.) Me: "I finally got (most of?) what monads really mean for practical programming when none other than Simon Peyton-Jones said F# called a very similar construct "workflow," a word he likes." A response: "Was it literally just a single sentence introducing a new word for a concept that made you "get it"? Could you elaborate? This is really quite remarkable." Richard Eisenberg: "For me, coming from a mostly Java background (but with a healthy dollop of functional programming thrown in the mix -- but no Haskell), the phrase that unlocked monads was "programmable semicolon"." I think one explanation for the Monad Tutorial Explosion (and how it still didn't work for a lot of people) is that there's no single right metaphor that will finally make monads "click". It depends on what combination of conceptions (and perhaps all misconceptions to be dispelled) is floating around in given mind. And minds vary. Workflow is a metaphor at one useful level. "Programmable semicolon" is a metaphor at another useful level. Semicolon as imperative-language separator actually hides a lot that's going on in a real CPU. Even if the imperative language is assembly language, the compiled instructions go to an instruction fetch/decode unit that -- these days especially -- can be engaged in a bewildering number of tasks, including finishing up several previous instructions, translating the decoded instruction to what amounts to microcode that get sent to an instruction cache, and fetching the next few instructions even as it's been decoding the instruction fetched into a little to-do list for the CPU. Perhaps we can think of instruction fetch/decode as "monadal" -- it's wildly (but not chaotically) mapping a previous state of the machine into new one. After all, it's all still Turing machines down there somewhere (but even the Turing machine was mathematically defined as a function that maps one tape-state to the next while it's also mapping its internal state to a new state.) So the semicolon can be thought of as lexically exposing the fetch-decode operator in the CPU's own little program. The "workflow" metaphor is at a higher level. If you think of how incoming data can be sorted and parceled out as if to a number of desks in an office, with forms processed at a desk going from one outbox to another desk's inbox, you're ignoring exact sequencing. It's the view where you're labeling desks by their specialized tasks and drawing outbox-inbox connections. In this view, it matters little that, in the one-instruction-at-a-time CPU model, there's only one "clerk" who (ridiculously, I know) puts a form in an inbox, then takes it out again, puts it in the inbox of another desk, then sits down at that other desk, takes the same form out and does the very specific form-processing task assigned to that desk. You can instead imagine it as some sluggish bureaucracy where everyone else but the single busy clerk is waiting for a form to hit their empty inboxes. The fact is, "one-instruction-at-a-time CPUs" hardly exist anymore except in the cheapest microcontrollers -- there are all multitasking like crazy. And this is because CPU designers work very hard to see how much of the little bureaucracy they can actually keep busy, ideally at all times, but at least at high throughput for average instruction streams, even if 100% utilization is seldom reached. (Lambda, the Ultimate Semicolon?) Bryan: "Listing sequential actions one after the other is so intuitive you see it everywhere. Take baking recipes as one example. Or assembly code. Or poems." Yes, sequencing just grows out of the fact of time. You'd think that poems aren't really sequences of tasks to do. But in a way, they are, and in a sense that matters for my attempts at natural-language understanding. There IS an implicit imperative in the energy required to speak: the subtext of any statement addressed to another person (even when it's dead poet to living reader) is: think about what I'm saying. Each new word in a sentence being spoken maps the listener's mind-state to a new one. The purpose of the sequencing is to build up state in the listener's mind. "When a Haskeller says, "Monads are great! They let you chain effectful actions together!" it can take a very long time to understand they actually mean exactly what they're saying — the usual intuition is that sequencing actions can't possibly be a real problem, so you go round and round in circles trying to understand what "effectful" means, what "action" means, and how these oh-so-important "laws" have anything to do with it." Yes, it's sort of like aliens from outer space with a very alien consciousness, and a different relation to the dimension of time, and they are exulting (to each other, and to themselves, really, more than to you): "Periods at the ends of sentences are great! They enable these strange blobs of protoplasm who call themselves 'human' to more easily map the states of these internal things they call 'neurons' into new states. No wonder we've been having such trouble trying to tell them what to do, using our intuitively obvious gestaltic visual patterns that allow us to grasp, with our quantum-computer brains, a whole meaning at once, through our retinas." (Yes, I am riffing a little here on the SF movie Arrival.) Math is this world where we can feel a little like that. Instead of thinking of a function as a machine that takes inputs, grinds away for a little while, and extrudes outputs, you can think of all inputs and output as already existing, and reason logically from the resulting properties. Haskell's laziness helps you fake what you can't really have: infinite workspace and the ability to do everything in an instant. It's a fake-it-til-you-make-it language, and you don't have to be Buzz Lightyear going to infinity and beyond, perhaps to all the way to the galaxy Aleph-omega. You just have to make a Haskell program do something that people like as much as their Buzz Lightyear doll. The math view is a useful view at one level, but it can only help you so much. I greatly enjoyed the level where I could define a Turing machine as a mapper from one infinite tape to another, then imagine all possible Turing machines as a countably infinite set. I could then prove, with Cantor diagonalization (abstractly, at least, though not very intuitively) that there are things Turing machines can't do. I loved that. But I also listened to grad students mutter about how recursive function theory may be beautiful and all, but it's now classical, and therefore dead for their own practical purposes (getting a PhD, getting onto tenure track.) And by then I knew I wasn't good enough at math to make a go of computing theory in their world, as a career, no matter what. I think Simon Peyton-Jones had a similar experience of academia -- he wasn't a John Hughes -- but he found a way through anyway. Bryan: "I can understand why that [puzzled newbie] viewpoint might be long-forgotten by those who were involved in the effort to solve it. :) And I appreciate that it was solved in such a general way that it can be applied to so many seemingly unrelated things! That's the beauty of mathematics!" Yes, it's there. But in user experience design (and writings about Haskell ARE part of its user experience) there's a saying: the intuitive is the familiar. At some point in gaining sophistication, it's no longer intuitively obvious to you why something wasn't intuitively obvious for you before. You're so absorbed in where you are that you don't remember quite how you got there. You might even assume that everyone who has gotten where you are has gotten there by the same route. And, if you can dimly remember how you got a flash of inspiration, you might end up writing yet another monad tutorial that few people understand. "Workflow" helped me. And now "programmable semicolon" is helping a little, in another way. I presented a strategy at the NSMCon-2021 conference: think of NSM reductive paraphrasing as writing very complete and precise code for natural-language terms and grammar rules, using NSM primes and syntax as a kind of logic programming language -- one that might even be very simply translatable to Prolog. I did some coding experiments and saw a problem: viewed more procedurally -- i.e., with each line of an NSM explication adding to a conceptual schema of a natural-language meaning -- NSM wasn't single-assignment. A Prolog interpreter couldn't just try a match, looking at each statement of an explication in relative isolation, and bail out when a statement failed to be true in the given context of the attempted match. It had to drag some state along just to resolve what the NSM prime "this" referred to. (Think of "it" in GHCI.) OK: effects. But wait, more: scoped effects. You want to strip some schema-stuff back out if a match failed midway through, then try another match somewhere else. OK: I need a context stack to store assertions that succeeded. Uh-oh, Prolog doesn't give me that paper trail. Dang. And I still want the one-for-one translation of sentences in an NSM reductive paraphrase to something like Prolog. OK: I need to grab control of sequencing, so that I can not only use the intrinsic Horn clause resolution without pain. But I also want it to hold onto the assertions that succeeded, and knit them into the growing conceptual schema that's part of the state. AND I want it roll those back out, transactionally, if a match didn't succeed. It turns out that Prolog makes this not too much harder than, say, a Lisp with transactional memory. So: I think I might now return to my Prolog code and see if I was unconsciously reinventing some kind of monad. Because because I felt forced by Prolog's limits to write my own semicolon. It wasn't too hard, though the resulting code required for NSM explications looks clunkier now. (Prolog is very limited in syntax extensibility.) Maybe there's some way in which Haskell makes it easier still, and nicer-looking too. None of which is to say that "programmable semicolon" will immediately help everyone pick the conceptual lock of monads. But for those who just bonk on "programmable semicolon", it might help to point out that the load-operate-store model of CPUs is a lie these days. Say a little about why it's not true. Then again pose semicolon as a kind of operator. People like to think, "OK, this statement will finish, and the one after the semicolon will start." It's a convenient view, even though in fact, while the imperative statement is in progress, the CPU might have already fetched instructions beyond it, and scheduled them for speculative execution. Or, you can tell them, "Just learn lambda calculus, then study monads algebraically, and here's a side dish of category theory while I'm it. Bon appetit." How's that working for you, guys? It doesn't work for me. And I don't think it's because I can't do the math. It's that I often write code to see whether I'm thinking about a problem the right way. And is that so bad? I believe it was in Stewart Brand's "II Cybernetic Frontiers" where a researcher at Xerox PARC, Steve ("Slug") Russell, one of their star hackers, was described by his peers as "thinking with his fingertips." I'm no star hacker, but "workflow" feels like it will make my fingertips smarter. "Programmable semicolon" feels like it will make my fingertips smarter. You think top-down mathematically? Well, bon appetit. It's not to my taste. No single way is likely to work for all. Math is not some fundamental reality. It's not even reality -- in fact, it gains a lot of its power precisely from being imaginary. And it's just a bunch of metaphors too. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry

10 18

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 17
by Michael Turner 04 Oct '21

04 Oct '21

Wow, someone on this thread said of me, from what I wrote on the beginner's list, "He's trying to translate Haskell to C/C++." No. I started here: https://www.stwing.upenn.edu/~wlovas/hudak/aug.pdf I'd like to use this parsing technique for natural language. I had no intention of translating Haskell to C/C++ unless it turned out to matter for performance. What I didn't realize starting out in trying to understand that code is that it's horribly written code, and underdocumented. 'g' as a function name, a name not clearly related to any meaning? Oh, and how about this type signature: app :: (TTree -> TTree -> Tree) -> TTree -> TTree -> [TTree] I actually reached a point where I thought, "I'm never gonna understand this code," because of that line. Somehow, after weeks of scrolling past it, grimacing, then looking at it again, I figure out a clarification. -- Order (Before/After) type Order = Typed_Tree -> Typed_Tree -> Tree and then I get app :: Order -> Typed_Tree -- the TT to be applied -> Typed_Tree -- TT applied to -> [Typed_Tree] -- result list Is that "translating it to C++"? Or is it "translating it to something you can at least mentally translate into plain English"? (Current frustration: can't seem to find a clean way to extract "Before" and "After" type constructors from Order, as strings to print in trace messages. Several "solutions" found, all either not working in my version of GHC, or not even compilable.) I finally realized: that paper where I started learning Haskell may be a gem as a paper in English, but the code is basically dashed off, by people so steeped in Haskell that it was all obvious to them. And it uses a representation of a left upper-triangular array (in a list-of-lists approach that probably sprays garbage left and right in the course of Haskell evaluations of "transpose", "reverse", etc.) which only makes the code harder to understand. And I haven't convinced myself that it wouldn't just spray smaller numbers of larger pieces of garbage anyway, if I rewrote it to clean out all the list-hacking cruft. Maybe it's OK. Maybe the GHC optimizer really is that good. But before I refactor it to Vector, first I have to make sure I really understand what this code is doing, so that the unit tests I'm adding don't just fail mysteriously. And I'm not there yet. When you read a "diagnosis" of me as someone whose mind is resistant to the Haskell execution model, please ignore it. I'm not resisting it. I'm trying to internalize it. Unfortunately, I haven't found a treatment that ties the execution model to where the rubber hits the road: real computers, like you buy at a store, which are derided by this commenter as "Turing machines." Sorry, guy, but you wrote your reply on a Turing machine. Turing machines got it to my inbox. As Simon Peyton-Jones said, in a talk about how to handle effects, you can't really verify that your program is executing correctly by noticing that the box it's running on gets warmer. I'm quite fine with purity, at least where it can reduce debugging time. I've learned a couple of other functional languages, if you'll condescendingly permit that, say, Lisp and Erlang are "functional." In college, I got fascinated by the idea of a Lisp interpreter with lazy evaluation, and read some papers on the subject, and I even believe laziness could prove useful for the project I'm on. I'm all for static typing. I'm all for how lazy evaluation and purity and functional programming in general can facilitate exploitation of multi-core parallelism. What I want is a clear, concise description of the execution model, to tie it all finally back down to those horrible grubby Turing machines that people buy in stores. Like the one on my desk, right now. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry On Fri, Sep 17, 2021 at 11:18 AM <haskell-cafe-request(a)haskell.org> wrote: > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: Haskell's "historical futurism" needs better writing, not > better tools (Viktor Dukhovni) > 2. Re: Haskell's "historical futurism" needs better writing, not > better tools (David Feuer) > 3. Re: Haskell's "historical futurism" needs better writing, not > better tools (Viktor Dukhovni) > 4. Re: Haskell's "historical futurism" needs better writing, not > better tools (David Feuer) > 5. Re: Haskell's "historical futurism" needs better writing, not > better tools (Anthony Clayden) > 6. Haskell reference documentation, laws first or laws last? > (Viktor Dukhovni) > 7. Re: Haskell reference documentation, laws first or laws last? > (Anthony Clayden) > 8. Re: Haskell reference documentation, laws first or laws last? > (Chris Smith) > 9. Re: Haskell reference documentation, laws first or laws last? > (David Feuer) > 10. Re: Haskell reference documentation, laws first or laws last? > (Viktor Dukhovni) > 11. Re: Haskell reference documentation, laws first or laws last? > (Anthony Clayden) > 12. Re: Haskell reference documentation, laws first or laws last? > (Chris Smith) > 13. Re: Haskell reference documentation, laws first or laws last? > (David Feuer) > 14. Re: Haskell reference documentation, laws first or laws last? > (Viktor Dukhovni) > 15. Re: Haskell reference documentation, laws first or laws last? > (Sebastiaan Joosten) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Sep 2021 16:52:22 -0400 > From: Viktor Dukhovni <ietf-dane(a)dukhovni.org> > To: haskell-cafe(a)haskell.org > Cc: Michael Turner <michael.eugene.turner(a)gmail.com> > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs > better writing, not better tools > Message-ID: <YUOuhjb3t0bYRkI0(a)straasha.imrryr.org> > Content-Type: text/plain; charset=us-ascii > > On Wed, Sep 15, 2021 at 04:07:38PM +0900, Michael Turner wrote: > > > The real problem is that the writing sucks. Not all of it -- and some > > contributors to the community are stellar writers, even if, in the > > snarkish commentary they write about Haskell and the community, I > > don't quite get all the jokes. But speaking as a contributor to the > > Haskell.org wiki -- to which I contribute at times out of hope that > > clarifying points I understand will also lead to more clarity for > > myself -- I have to say it: the writing sucks. > > Can you be a bit more specific about which sort of writing you find > sufficiently unsatisfactory to say "the writing sucks"? > > * Books about Haskell > - Introductory (e.g. http://learnyouahaskell.com/) > - Comprehensive (e.g. the classic Real World Haskell) > - Topic focused (e.g. the IMHO rather excellent Parallel and > Concurrent Haskell) > - Theory focused (e.g. > https://bartoszmilewski.com/category/category-theory/) > - ... > * The library reference documentation? > * The GHC User's Guide? > * The Haskell report? > * Blog posts? > * The Haskell Wiki? > * r/haskell? > * Haskell mailing lists? > ... > * All of the above??? > > I am also curious whether I'm part of the solution or part of the > precipitate. I've recently contributed new documentation for > Data.Foldable and Data.Traversable: > > https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-F… > https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-T… > > are these a step in the right direction, or examples of more writing > that sucks? These are reference documentation, not beginner tutorials, > so a more detailed write up of the concepts, pitfalls, ... things to > keep in mind when using library, ... > > More of that sort of thing would help me to more quickly learn to use > some of the libraries that lack this sort of overview prose, but perhaps > what you're looking for is something else? > > -- > Viktor. > > > ------------------------------ > > Message: 2 > Date: Thu, 16 Sep 2021 16:57:28 -0400 > From: David Feuer <david.feuer(a)gmail.com> > To: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> > Cc: Michael Turner <michael.eugene.turner(a)gmail.com> > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs > better writing, not better tools > Message-ID: > <CAMgWh9tRX=r8MMSvzTGMr2iQMcgzKwdRc7SF=zx2wgPXPojN+A(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I am not a fan of how the new Traversable documentation buries the actual > laws. > > On Thu, Sep 16, 2021, 4:55 PM Viktor Dukhovni <ietf-dane(a)dukhovni.org> > wrote: > > > On Wed, Sep 15, 2021 at 04:07:38PM +0900, Michael Turner wrote: > > > > > The real problem is that the writing sucks. Not all of it -- and some > > > contributors to the community are stellar writers, even if, in the > > > snarkish commentary they write about Haskell and the community, I > > > don't quite get all the jokes. But speaking as a contributor to the > > > Haskell.org wiki -- to which I contribute at times out of hope that > > > clarifying points I understand will also lead to more clarity for > > > myself -- I have to say it: the writing sucks. > > > > Can you be a bit more specific about which sort of writing you find > > sufficiently unsatisfactory to say "the writing sucks"? > > > > * Books about Haskell > > - Introductory (e.g. http://learnyouahaskell.com/) > > - Comprehensive (e.g. the classic Real World Haskell) > > - Topic focused (e.g. the IMHO rather excellent Parallel and > > Concurrent Haskell) > > - Theory focused (e.g. > > https://bartoszmilewski.com/category/category-theory/) > > - ... > > * The library reference documentation? > > * The GHC User's Guide? > > * The Haskell report? > > * Blog posts? > > * The Haskell Wiki? > > * r/haskell? > > * Haskell mailing lists? > > ... > > * All of the above??? > > > > I am also curious whether I'm part of the solution or part of the > > precipitate. I've recently contributed new documentation for > > Data.Foldable and Data.Traversable: > > > > > > https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-F… > > > > https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-T… > > > > are these a step in the right direction, or examples of more writing > > that sucks? These are reference documentation, not beginner tutorials, > > so a more detailed write up of the concepts, pitfalls, ... things to > > keep in mind when using library, ... > > > > More of that sort of thing would help me to more quickly learn to use > > some of the libraries that lack this sort of overview prose, but perhaps > > what you're looking for is something else? > > > > -- > > 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. >

4 3

Haskell reference documentation, laws first or laws last?
by Viktor Dukhovni 04 Oct '21

04 Oct '21

On Thu, Sep 16, 2021 at 06:51:42PM -0400, David Feuer wrote: > The last time I went to look at the laws it took me a couple minutes to > find them. I use them to write instances. Pretty important, IMO. I agree the laws are important to document, I just don't think they belong at the top of the module. The beginner to intermediate users will be using the library and existing instances for some time before they start to write their own instances. If more modules adopt something like the style of the new Data.Foldable, experienced users will know to look for the laws at the end, if not still present at the top of the module. Of course perhaps the community would prefer the original Laws first format, I'm fine with that emerging as the consensus. Perhaps worthy of a separate thread (made it so). Of course the conjectured users who might most benefit from not being intimidated by being exposed to laws before they're ready to understand them might not be present on this forum... -- Viktor.

7 14

Haskell's "historical futurism" needs better writing, not better tools
by Michael Turner 04 Oct '21

04 Oct '21

I haven't been able to view Andrew Boardman's video so far, but I gather from the summary that he feels the solution to the most pressing problem -- growth through fostering newbies -- is simply . . . better tools. I beg to differ, as a newbie who is now struggling with the revival of some Haskell code only with a feeling of claustrophobia. Where is this incredible feeling of freedom I was promised? At the top of the learning curve. And it feels like a Sisyphean slope -- the boulder stops, when I lay off learning, and then slowly starts to roll down under the gravitational force of memory decay. The real problem is that the writing sucks. Not all of it -- and some contributors to the community are stellar writers, even if, in the snarkish commentary they write about Haskell and the community, I don't quite get all the jokes. But speaking as a contributor to the Haskell.org wiki -- to which I contribute at times out of hope that clarifying points I understand will also lead to more clarity for myself -- I have to say it: the writing sucks. Why does it suck? Well, there are several syndromes. One is to think that Haskell is so incredibly good and pure and elementally profound that one must start conceptually from scratch. (I've actually been curtly informed on the beginners' list -- yes, the beginner' list! -- that my problems of comprehension can be solved simply: "Learn lambda calculus.") I've had a book recommended to me whose author had such pretensions to writing in a way that was easily foundational that he actually claimed his book could teach you Haskell even if you have no programming experience at all. Now, in practical marketing terms, that's just silly: such an approach addresses a minuscule fraction of the book's potential audience. If you've heard of Haskell as a programming language, you're probably software-multilingual already. But in practical pedagogical terms, it's also a little ridiculous. Your average reader (already a programmer) would be better served by a comparative approach: Here's how to say something in a couple of other programming languages, here's how to say something roughly equivalent in Haskell -- BUT, here's how it's subtly different in Haskell. Here's how Haskell makes something easier (at least perhaps in being more concise, if the Haskell is more concise) but also conferring useful leverage where Haskell might otherwise seem unnecessarily verbose. The problem of better writing is ultimately social, I believe. I have a friend who's a tenured professor at Columbia University, who has used Haskell in courses, who praises Haskell for how it makes students think a little more clearly about how to structure software. However, his final verdict is this: Functional programming is a cult. Now, he's a unabashedly abrasive type. (Just ask him, he'll tell you.) And that verdict IS a little over the top. But I have to say, my impression of the community is that there are Founder demi-gods praised even though they leave something to be desired in how articulate and clear they are for newbies, even when claiming to be addressing newbies, while the language itself seems to be somewhat an object of worship. How can the writing be better? Well, here's a clue: Simon Peyton-Jones, somewhere in a talk where he was his usual vibrant self (but where the audience was clearly stunned and intimidated into silence even though he'd invited people to interrupt with questions) said that F# had settled on the term "workflow" instead of "monad", and he felt this was wise. Workflow? Workflow!? My still-feeble understanding of monads took a leap forward, because suddenly I had a motivation for them: abstraction of the idea of a workflow. Could it be that something as simple as Maybe was a kind of "degenerate case" of a "workflow abstraction"? I felt massively encouraged that I might finally figure out how great monads were. Which is not to say that I have. Writers: you need to stop speaking your own obscure little dialect of "programmer English". If you're not aware that you are, become more self-aware. If you ARE aware of it, become aware of how snobbish or pointlessly mysterious you sound. And if you do become aware of how you sound, but don't care, ask yourself: if the goal now is to spread Haskell and help it flourish, isn't your attitude more of a hindrance than a help? Tools? That's not the front I'd pick. Because I hit a glitch in getting VScode to work under Windows 10 (yes, cue the snobbery), I backed off to github bash and vim. And you know what? It's fine. Sorry if my knuckles seem to be dragging on the floor, but I'm from the Stone Age of Unix v7 command line and Bill Joy's original vi. I'd like nicer tools. But they aren't likely to help me with Haskell. What's not fine: half the time, I can't figure out the error messages from GHC, and a dismaying portion of the time, I can't figure out the language documentation. And since the concepts are seldom described in concrete enough and time-honored programming language terms (by comparison to other programming languages) they often don't really stick. It's like my Sysiphean boulder has been pre-greased -- if I stop pushing (hard enough with all the abstraction grease on it), it starts to slide even before it rolls, whenever I leave off coding in Haskell for any length of time. Sorry for not writing better email here -- my sentences get rather long and tortuous when I rant. But not sorry for ranting. You say the solution to a tool adoption problem (getting more people to use Haskell) is yet more tools written in Haskell, for your favorite language, Haskell? No. The failure here is a failure to communicate. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry

7 26

Seeking community input on change to Haskell.org Downloads page
by Tom Ellis 03 Oct '21

03 Oct '21

The Haskell.org committee is considering a change to the [Haskell.org Downloads page]. The change is being reviewed in a [GitHub PR]. The specifics of the change are to replace Chocolatey with ghcup as the preferred installation method of GHC, cabal-install and haskell-language-server on Windows. The overall effect is that the install instructions become common over Windows, Linux and MacOS. The Chocolatey install method is mentioned further down the page. (The PR does not impinge on Stack. The Stack instructions remain unchanged.) The committee would welcome input from any interested parties, particularly those who have familiarity with Chocolatey, or ghcup on Windows, or both. You are welcome to comment on the [PR itself][GitHub PR] (or this thread if absolutely necessary). Thanks to @bodigrim for the PR. [Haskell.org Downloads page]: https://www.haskell.org/downloads/ [GitHub PR]: https://github.com/haskell-infra/www.haskell.org/pull/125

3 3

Re: [Haskell-cafe] Improving the docs (specifically Data.Foldable)
by Anthony Clayden 02 Oct '21

02 Oct '21

At *Fri Oct 1 01:42:39 UTC 2021* Ben Franksen wrote >> Am 17.09.21 um 07:15 schrieb Michael Turner:>> >>* "The contribution of each element to the final result is combined with an *>>* accumulator via an /operator/ function. The operator may be explicitly *>>* provided by the caller as in `foldr` or may be implicit as in `length`. In *>>* the case of `foldMap`, the caller provides a function mapping each element *>>* into a suitable 'Monoid', which makes it possible to merge the per-element *>>* contributions via that monoid's `mappend` function." *> >>* This is a little better, but I'd write it this way, I think. *>> >>* "Folds take operators as arguments. In some cases, it's implicit, as *>>* in the function "length". These operators are applied to elements when *>>* lazy evaluation requires it, with a fold 'accumulator' as one of the *>>* operands. 'foldMap' uses a function (implicit? explicit?) that maps *>>* elements into . . . ." * > The problem you two are both facing is this: you want to describe, > abstractly, generally, the common principle behind an ad-hoc > lumped-together set of functions. This is very likely to result in > contortions and provides you with no insight. I think neither "ad-hoc" nor "lumped-together" is accurate. For both `Functor t` and `Foldable t` the metaphor is `t` as container. * For `Functor` we wish to preserve the shape/spine and mangle each element irrespective of other content. * For `Foldable` we wish to throw away the shape/spine and return some characteristic of the contents-as-a-whole. (The fold is possibly returning another container/contents, but it won't necessarily be the same `t`; even if it is, the result won't be the same shape/spine.) There are some frequent use-cases for "characteristic of the contents-as-a-whole": count, sum, min/max, is-element. So it makes sense to provide (possibly optimised) methods. Yes the insight is that there's a common principle. But the optimising devil is in the detail. The devilish detail is that although we're going to throw away the shape/spine, knowing its organising principle will help navigating it effectively. Otherwise we could stick with List as container -- but as Ref [1] points out, that's hardly ever wise. For somebody coming to the docos to generate their own `instance Foldable`, thinking in terms of `toList` might help in getting the right result; it won't explain why they'd want to use something other than a List.

2 1

Stack lock issue
by Dominick Samperi 01 Oct '21

01 Oct '21

Hi, Stack install does its thing in some hashed directory under .stack-work by default, but I want to write to <package-root>/bin as part of the configure process. I'm trying to do this as follows: -- configure file contains: cd $(stack path --project-root) echo "..." > .bin/foo.sh cd - > cd <project-root> > stack install I'm doing this under Windows with the born shell in my path. Problem: the use of stack to find the project-root directory is blocked waiting for the outer stack to terminate! This may have something to do with Windows "Device or resource busy" lock. Is there a better way? Thanks, Dominick <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

Cabal or stack in 2021 ?
by Alexis Praga 01 Oct '21

01 Oct '21

Hi, As an intermediate beginner, I've been back into Haskell for the last months for a small project, using stack as the building tool. Why stack ? A few years back, I learned that it was the "best" way to build projects to avoid "cabal hell", which I understood at the time as "managing dependencies with cabal is hard". As such, I've use stack since and have been quite happy with it. The only drawback is that building a project can be quite long. This is usually not a problem, except for writing Haskell scripts using shelly (for example), where the stack layout is a bit impractical for fast-paced development. A solution is to use `runghc` or a script interpreter [1]. However, I've seen some projects where cabal is used to build directly instead of cabal, so it looks like the situation improved. My question is this: in 2021, is there a reason to switch back to cabal ? Thanks, [1] https://www.fpcomplete.com/haskell/tutorial/stack-script/ -- Alexis Praga

8 11

Re: [Haskell-cafe] Pattern guards seen in the wild?
by Anthony Clayden 01 Oct '21

01 Oct '21

Thank you all for the examples. Hehe real-world data structures are messy. Especially if dictated by systems utilities that don't care for functional programming. In the back of my mind is: do these idioms date from before there were pattern synonyms? Would matching to a pattern synonym give clearer code in the case branching? (Would it be worth declaring a synonym for just one usage?) There's only one of those examples where I feel expressing without the Pattern guard would be awkward. Tom's example 1., whose characteristics are: * There's a long straggly sequence of matchers; * With a particularly awkward branch in the middle, needing sub-analysis of a _component_ of the scrutinee, and only if such a component is present; * If the sub-analysis fails to match, the logic must unnest itself and resume matching at the next branch of the straggle. The awkward branch (slightly reformatted) is > (GET, [x]) | Just (path', mime) <- List.lookup x staticFiles > -> Just (StaticFile mime path') `staticFiles` is a module-wide variable, so matching is looking outside the scrutinee, therefore couldn't be expressed as a pattern synonym. The `lookup` might return a `Nothing`, so the inner pattern match could fail/this is doing more than a 'local binding' with `let`, which "always succeed" says the Language Report.

1 0

Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools
by Anthony Clayden 01 Oct '21

01 Oct '21

Hi Michael, oh dear, oh dear, oh dear. The seeds of your confusion are very evident from your message. How to back you out of whatever deep rabbit-hole you've managed to get your head into? > ... Your average reader (already a programmer) would be better served by a comparative approach: Here's how to say something in a couple of other programming languages, here's how to say something roughly equivalent in Haskell -- BUT, here's how it's subtly different in Haskell. No. Just no. Haskell is not "subtly different" to (say) Java in the way that C++ or C# are different. (I'll leave others to judge how subtly different they are.) Haskell is dramatically and fundamentally different. You can't just 'translate' an algorithm from OOP to Haskell. Many newbies try, and there's many tales of woe on StackOverflow. Just No. I really don't know how you could have got any experience with Haskell and say "subtly". I suggest you unlearn everything you think you know about Haskell, and strike out in an entirely different direction. The best approach would be to spend a few days playing with lambda calculus. (That's what I did before tackling Haskell.) > (I've actually been curtly informed on the beginners' list -- yes, the beginner' list! -- that my problems of comprehension can be solved simply: "Learn lambda calculus.") Lambda calculus is an excellent place for beginners to start. What could be easier to learn? It's certainly easier than grokking a Turing machine; and much easier than Haskell: less than a handful of primitives yet can compute anything computable. > And since the concepts are seldom described in concrete enough and time-honored programming language terms (by comparison to other programming languages) I'm guessing that the concepts you're talking of simply don't correspond to anything in time-honoured (procedural) programming. Anybody writing about Haskell (including anybody writing the User Guide) assumes a base level of understanding of Haskell. You've clearly veered off the track and haven't yet reached base. Remember the User Guide builds on top of the Language Report. (On the point of 'time-honoured': lambda calculus is almost exactly the same age as Turing machines. The first well-known programming language using lambda-calculus ideas (LISP 1966) is almost exactly the same age as the first OOP language (Simula 1967). Which is the more time-honoured?) You do have a point that the terminology in Haskell is often mysterious > [SPJ said] F# had settled on the term "workflow" instead of "monad", and he felt this was wise. Yes many have yearned for a more warm-and-cuddly term than "monad". But the terminology barrier starts before that. Haskell typeclasses are not 'classes' in any sense recognisable from OOP. There are no objects, no hidden state, no destructive assignment. We might go back to February 1988 when a strawman for what became typeclasses used OVERLOAD/INSTANCE. AntC

5 5

Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools
by Anthony Clayden 01 Oct '21

01 Oct '21

> Switching subtopics to the "Chirality" section, ... I take Ben's point (with which I agree) to be that "Chirality" is an even more obscure word than "Endomorphism". (Except perhaps in the realm of subatomic particle physics.) Grokking this material is hard enough without having to reach for a dictionary. If you mean 'left-biased' vs 'right-biased', or 'from-front' vs 'from-rear' or 'Cons-oriented' vs 'Snoc-oriented', say that. (And I'll be interested to see how anyone explains this without `fromList` jigging their elbow.) Now I can see Foldable structures are abstract, not spatial. But Cons is recursive on its (textually) right operand, whereas `Bin` or `Node` are symmetric between their (textually) left/right recursive operands. I guessed that's what the Chirality section was talking about, so I skimmed the first sentence and skipped on.

3 2

Re: [Haskell-cafe] Pattern guards seen in the wild?
by Anthony Clayden 01 Oct '21

01 Oct '21

Thanks Viktor, you've answered (in the negative) one of my follow-on q's which was: isn't the comma just standing for Boolean `&&` ? > which would otherwise be something like: ... I would go: > smtpGreeting :: Int -> SmtpReply -> SmtpM B.ByteString > smtpGreeting _ r = > | replyCont r = pure B.empty > | code `div` 100 /= 2 = B.empty <$ modify' bail code > | otherwise = smtpSendHello > where > code = replyCode r > bail code s = > s { smtpErr = ProtoErr code $ replyText r } > but I find the pattern guard form to read "declarative", Hmm? Your `code <- ...` left-arrow doesn't look at all declarative to me. It's reminiscent of a binding in a do-block, or a 'source' in a comprehension. Strong imperative/sequential overtones. > with less "if then else" baggage and nesting getting in the way of seeing the essential conditions. My suggestion above also avoids "if then else". I guess a case of de gustibus ... To my taste, GHC Haskell is just too bloated/there's too many (equivalent) ways of writing code/there's too many idioms I have to keep up with to read code. It's not that there's anything particularly 'wrong' with any one of them; it's the sheer number of them. I'd have to say patterns/matching suffer a low power to weight ratio, where 'weight' means syntactic clutter and gotcha's: View pattern arrow-from-nowhere, I'm looking at you; pattern signatures double-forall's, empty forall's, double-constraints, I'm looking at you.

1 0

canonicalization of interval libraries
by Olaf Klinke 29 Sep '21

29 Sep '21

Emily Pillmore wrote: > Hello Haskell! > > I'm pleased to announce that the Core Libraries Committee Elections for September 2021 have concluded, and we have selected 2 new CLC members: > > - [Andrew Lelechenko]( https://github.com/Bodigrim ) > > - [Melanie Brown]( https://github.com/bi-functor ) > I could not help but notice that both new members have either written or contributed to an interval library. There are a handful out there (disclaimer: I have written one of them) but as far as I know there is no de-facto standard. Why is that? Is it because the applications of intervals are too diverse and hence no single type fits all? Or is it because it is such a niche application that no single library could gather enough traction? I'm curious whether others see the need to have a de-facto standard interval library that is both general and performant, as we are used to from our "core libraries". Judging from the number of downloads on hackage, people are mostly interested in intervals of floating point numbers and intervals of time. Olaf P.S. Yes, I am aware of the relevant xkcd comic on standards.

1 0

[ANN] CLC Elections Outcome - September 2021
by Emily Pillmore 29 Sep '21

29 Sep '21

Hello Haskell! I'm pleased to announce that the Core Libraries Committee Elections for September 2021 have concluded, and we have selected 2 new CLC members: - [Andrew Lelechenko]( https://github.com/Bodigrim ) - [Melanie Brown]( https://github.com/bi-functor ) The candidate pool was especially broad for this election and it was very difficult to choose, but we'd like to thank everyone for applying nonetheless. It is genuinely heartwarming to see so many people eager to help support the Haskell ecosystem in an official capacity! We encourage any and all candidates to continue helping to support the core libraries as we renovate the CLC. As mentioned in the latest CLC update (see: https://discourse.haskell.org/t/state-of-the-core-libraries-committee-updat… ), we are set to begin writing a new process and ways of working for the CLC now that the elections have concluded. We aim to have these finished within the month. Happy Hacking! Emily Pillmore - on behalf of the CLC

2 1

Very binding semicolon
by Anthony Clayden 28 Sep '21

28 Sep '21

>From the department of improbable syntax/I don't get how this works, but it does: > f :: [a] -> [a] > ;; f xs = xs ++ reverse xs Nicely (to my eye) groups/indents the binding under the signature. Especially handy with ScopedTypeVariables, to show how the scoped vars 'belong' > f :: forall a. [a] -> [a] > ;; f xs = xs ++ ys > where > ys :: [a] > ys = reverse xs The doubled `;;` stands out like a ditto. It could be a single semicolon (which means there's an empty decl/binding between the semis -- I don't see that's allowed by the syntax). Unfortunately, for multi-line bindings you need to repeat the `;;` > f :: [a] -> [a] > ;; f [] = [] > ;; f xs = xs ++ reverse xs

2 2

[TFP'22] first call for papers: Trends in Functional Programming 2022, 10-11 February (with Lambda Days 2022 & TFPIE 2022)
by Peter Achten 27 Sep '21

27 Sep '21

====== TFP 2022 ====== 23rd Symposium on Trends in Functional Programming 10-11 February, 2022 Krakow, Poland https://trendsfp.github.io/index.html == Important Dates == Submission deadline for pre-symposium review Wednesday 1st December, 2021 Submission deadline for draft papers Wednesday 12th January, 2022 Notification for pre-symposium submissions Friday 21st January, 2022 Notification for draft submissions Friday 21st January, 2022 Symposium dates Thursday 10th - Friday 11th February, 2022 Submission deadline for post-symposium reviewing Wednesday 16th March, 2022 Notification for post-symposium submissions Friday 13rd May, 2022 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. Please be aware that TFP uses two distinct rounds of submissions. TFP 2022 will be co-located with two other functional programming events. TFP 2022 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on February 11. Simultaneously with TFP, Lambda Days '22 is a two day conference where academia meets industry, where research and practical application collide. == Scope == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles: Leading-edge, previously unpublished research work * Position Articles: On what new trends should or should not be * Project Articles: Descriptions of recently started new projects * Evaluation Articles: What lessons can be drawn from a finished project * Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2022 program chairs, Wouter Swierstra and Nicolas Wu. == Best Paper Awards == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == Instructions to Author == Papers must be submitted at: https://easychair.org/conferences/?conf=tfp22 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Pre-symposium formal review == Papers to be formally reviewed before the symposium should be submitted before an early deadline and receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected in this process may still be accepted for presentation at the symposium, but will not be considered for the post-symposium formal review. == Post-symposium formal review == Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback received at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. == Program Committee == Program Co-chairs Nicolas Wu - Imperial College London Wouter Swierstra - Utrecht University The remainder of the PC will be announced on the conference website.

1 0