From plredmond at ucsc.edu  Thu Sep  1 17:46:49 2022
From: plredmond at ucsc.edu (Patrick L Redmond)
Date: Thu, 1 Sep 2022 10:46:49 -0700
Subject: [Haskell-cafe] selectively allow alternatives in a sum type
In-Reply-To: <CAMgWh9vwxVh6RxgswhC3yc6eyi3kPLLAnJ8raz3LBOR4xF=LAw@mail.gmail.com>
References: <fdd352f16f833aa295131a6ed07ca7819854b91f.camel@aatal-apotheke.de>
 <CAMgWh9vwxVh6RxgswhC3yc6eyi3kPLLAnJ8raz3LBOR4xF=LAw@mail.gmail.com>
Message-ID: <CAE_N5O4F_1Q1O4FzbJR5ukCQ6g3dddYOs=szZ02Fs+1L+AMLQA@mail.gmail.com>

>
> Sometimes I feel the need to selectively allow or disallow alternatives
>

This seems like the kind of lightweight property that Liquid Haskell (a GHC
plugin) is especially suited for. Here's a small example of "at some places
in the program we want the type system to enforce that only the constructor
LeftFoo can be used."

data Foo = LeftFoo !Int | RightFoo !Char

{-@ measure isLeftFoo @-}
isLeftFoo :: Foo -> Bool
isLeftFoo LeftFoo{} = True
isLeftFoo _ = False

{-@ takesOnlyLeftFoo :: {x:Foo | isLeftFoo x} -> Int @-}
takesOnlyLeftFoo :: Foo -> Int
takesOnlyLeftFoo (LeftFoo i) = i

I've taken Olaf's hypothetical Foo and swapped in Int for A and Char for B,
defined a function *isLeftFoo* that returns True for LeftFoo-constructed
Foos, and I call *isLeftFoo* in the type of a function that is meant to
only be called with LeftFoo values.

This syntax in the mushroom-at-symbol comments is a refinement type. It has
the same structure as the haskell type `Foo -> Int` but adds a precondition
on the input that *isLeftFoo* returns True. When you compile your project
with Liquid Haskell, the precondition will be checked at compile time by
checking that callers establish the fact on any value they pass into
*takesOnlyLeftFoo*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220901/cc809444/attachment.html>

From dominik.schrempf at gmail.com  Thu Sep  1 20:33:03 2022
From: dominik.schrempf at gmail.com (Dominik Schrempf)
Date: Thu, 01 Sep 2022 22:33:03 +0200
Subject: [Haskell-cafe] selectively allow alternatives in a sum type
In-Reply-To: <CAE_N5O4F_1Q1O4FzbJR5ukCQ6g3dddYOs=szZ02Fs+1L+AMLQA@mail.gmail.com>
References: <fdd352f16f833aa295131a6ed07ca7819854b91f.camel@aatal-apotheke.de>
 <CAMgWh9vwxVh6RxgswhC3yc6eyi3kPLLAnJ8raz3LBOR4xF=LAw@mail.gmail.com>
 <CAE_N5O4F_1Q1O4FzbJR5ukCQ6g3dddYOs=szZ02Fs+1L+AMLQA@mail.gmail.com>
Message-ID: <87fsha7ry7.fsf@gmail.com>

Chiming in here, maybe I missed something. Liquid Haskell is great, but in this
case, in my opinion, easier is better:

newtype LeftFoo = LeftFoo !Int

newtype RightFoo = RightFoo !Char

data Foo = LFoo LeftFoo | RFoo RightFoo – Probably with strictness annotations.

isLeftFoo :: Foo -> Bool
isLeftFoo (LFoo _) = True
isLeftFoo _ = False

takesOnlyLeftFoo :: LeftFoo -> Int
takesOnlyLeftFoo (LeftFoo i) = i

Dominik

Patrick L Redmond via Haskell-Cafe <haskell-cafe at haskell.org> writes:

>  Sometimes I feel the need to selectively allow or disallow alternatives
>
> This seems like the kind of lightweight property that Liquid Haskell (a GHC plugin) is especially suited for. Here’s a small example of “at some
> places in the program we want the type system to enforce that only the constructor LeftFoo can be used.”
>
> data Foo = LeftFoo !Int | RightFoo !Char
>
> {-@ measure isLeftFoo @-}
> isLeftFoo :: Foo -> Bool
> isLeftFoo LeftFoo{} = True
> isLeftFoo _ = False
>
> {-@ takesOnlyLeftFoo :: {x:Foo | isLeftFoo x} -> Int @-}
> takesOnlyLeftFoo :: Foo -> Int
> takesOnlyLeftFoo (LeftFoo i) = i
>
> I’ve taken Olaf’s hypothetical Foo and swapped in Int for A and Char for B, defined a function isLeftFoo that returns True for LeftFoo-constructed
> Foos, and I call isLeftFoo in the type of a function that is meant to only be called with LeftFoo values.
>
> This syntax in the mushroom-at-symbol comments is a refinement type. It has the same structure as the haskell type `Foo -> Int` but adds a
> precondition on the input that isLeftFoo returns True. When you compile your project with Liquid Haskell, the precondition will be checked at
> compile time by checking that callers establish the fact on any value they pass into takesOnlyLeftFoo.
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> Only members subscribed via the mailman list are allowed to post.

From ruben.astud at gmail.com  Thu Sep  1 22:54:39 2022
From: ruben.astud at gmail.com (Ruben Astudillo)
Date: Thu, 1 Sep 2022 18:54:39 -0400
Subject: [Haskell-cafe] selectively allow alternatives in a sum type
In-Reply-To: <87fsha7ry7.fsf@gmail.com>
References: <fdd352f16f833aa295131a6ed07ca7819854b91f.camel@aatal-apotheke.de>
 <CAMgWh9vwxVh6RxgswhC3yc6eyi3kPLLAnJ8raz3LBOR4xF=LAw@mail.gmail.com>
 <CAE_N5O4F_1Q1O4FzbJR5ukCQ6g3dddYOs=szZ02Fs+1L+AMLQA@mail.gmail.com>
 <87fsha7ry7.fsf@gmail.com>
Message-ID: <b90eb426-ac50-7965-1702-0c004755341c@gmail.com>

On 01-09-22 16:33, Dominik Schrempf wrote:
> Chiming in here, maybe I missed something. Liquid Haskell is great, but in this
> case, in my opinion, easier is better:
> 
> newtype LeftFoo = LeftFoo !Int
> 
> newtype RightFoo = RightFoo !Char
> 
> data Foo = LFoo LeftFoo | RFoo RightFoo – Probably with strictness annotations.
> 
> isLeftFoo :: Foo -> Bool
> isLeftFoo (LFoo _) = True
> isLeftFoo _ = False
> 
> takesOnlyLeftFoo :: LeftFoo -> Int
> takesOnlyLeftFoo (LeftFoo i) = i
> 
> Dominik

Chiming in here too. I do this all the time if the subpart is to be used on
2 or more places. Easiest way to do this without extensions.

-- 
Rubén. (pgp: 1E88 3AC4 89EB FA22)


From plredmond at ucsc.edu  Fri Sep  2 00:12:51 2022
From: plredmond at ucsc.edu (Patrick L Redmond)
Date: Thu, 1 Sep 2022 17:12:51 -0700
Subject: [Haskell-cafe] selectively allow alternatives in a sum type
In-Reply-To: <b90eb426-ac50-7965-1702-0c004755341c@gmail.com>
References: <fdd352f16f833aa295131a6ed07ca7819854b91f.camel@aatal-apotheke.de>
 <CAMgWh9vwxVh6RxgswhC3yc6eyi3kPLLAnJ8raz3LBOR4xF=LAw@mail.gmail.com>
 <CAE_N5O4F_1Q1O4FzbJR5ukCQ6g3dddYOs=szZ02Fs+1L+AMLQA@mail.gmail.com>
 <87fsha7ry7.fsf@gmail.com> <b90eb426-ac50-7965-1702-0c004755341c@gmail.com>
Message-ID: <CAE_N5O4ODdx8nCnM6cFN44GZ9rQae8uajusnHaiKzozEPcY3KQ@mail.gmail.com>

I made a TH function earlier this year to produce types for constructors:

data Foo = LeftFoo !Int | RightFoo !Char
    deriving Show

$(constructorType 'LeftFoo)
deriving instance Show LeftFooC

In a repl you can see it generates a type with a single constructor, an
introducer, and an eliminator.

*Main> :browse
type Foo :: *
data Foo = LeftFoo !Int | RightFoo !Char
type LeftFooC :: *
data LeftFooC = LeftFooC Int
introLeftFooC :: Foo -> Maybe LeftFooC
elimLeftFooC :: LeftFooC -> Foo

*Main> introLeftFooC (RightFoo 'a')
Nothing

*Main> introLeftFooC (LeftFoo 123)
Just (LeftFooC 123)

*Main> elimLeftFooC $ LeftFooC 456
LeftFoo 456

If you find that useful, I ripped it out of my other repo and pasted it
here: https://gist.github.com/plredmond/5fd15fb388647b248de87693542d2adb

On Thu, Sep 1, 2022 at 3:54 PM Ruben Astudillo <ruben.astud at gmail.com>
wrote:

> On 01-09-22 16:33, Dominik Schrempf wrote:
> > Chiming in here, maybe I missed something. Liquid Haskell is great, but
> in this
> > case, in my opinion, easier is better:
> >
> > newtype LeftFoo = LeftFoo !Int
> >
> > newtype RightFoo = RightFoo !Char
> >
> > data Foo = LFoo LeftFoo | RFoo RightFoo – Probably with strictness
> annotations.
> >
> > isLeftFoo :: Foo -> Bool
> > isLeftFoo (LFoo _) = True
> > isLeftFoo _ = False
> >
> > takesOnlyLeftFoo :: LeftFoo -> Int
> > takesOnlyLeftFoo (LeftFoo i) = i
> >
> > Dominik
>
> Chiming in here too. I do this all the time if the subpart is to be used on
> 2 or more places. Easiest way to do this without extensions.
>
> --
> Rubén. (pgp: 1E88 3AC4 89EB FA22)
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220901/4cb3f4d9/attachment.html>

From simon at joyful.com  Fri Sep  2 01:10:10 2022
From: simon at joyful.com (Simon Michael)
Date: Thu, 1 Sep 2022 18:10:10 -0700
Subject: [Haskell-cafe] ANN: hledger 1.27
Message-ID: <9A27B48C-CB85-484D-976F-964AFDC06B1E@joyful.com>

I'm pleased to announce hledger 1.27 !

https://github.com/simonmichael/hledger/releases/1.27
https://hledger.org/install
https://hledger.org/release-notes.html#hledger-1-27

Highlights include inferring costs from equity postings,
new error checks, and improved error messages.

Thank you to release contributors
Stephen Morgan,
Alex Hirzel,
Pranesh Prakash,
David D Lowe,
Charlotte Van Petegem,
Max Thomas,
Andrew Lelechenko.

What is hledger ?

- Fast, reliable, free, multicurrency, double-entry, plain text
  accounting[1] software that runs on unix, mac, windows, and the web

- Built around human-readable, version-controllable plain text files

- Inspired by and largely compatible with Ledger CLI[2];
  convertible to and from Beancount[3]

- Written in Haskell for correctness and longevity.

For help getting started, or more info, see https://hledger.org
and join our chat via Matrix or IRC: https://hledger.org/support
Newcomers, experts, contributors, sponsors, feedback are welcome!

Aloha,
-Simon


[1] https://plaintextaccounting.org
[2] https://ledger-cli.org
[3] https://beancount.github.io


From olf at aatal-apotheke.de  Fri Sep  2 12:13:27 2022
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Fri, 02 Sep 2022 14:13:27 +0200
Subject: [Haskell-cafe] selectively allow alternatives in a sum type
In-Reply-To: <87fsha7ry7.fsf@gmail.com>
References: <fdd352f16f833aa295131a6ed07ca7819854b91f.camel@aatal-apotheke.de>
 <CAMgWh9vwxVh6RxgswhC3yc6eyi3kPLLAnJ8raz3LBOR4xF=LAw@mail.gmail.com>
 <CAE_N5O4F_1Q1O4FzbJR5ukCQ6g3dddYOs=szZ02Fs+1L+AMLQA@mail.gmail.com>
 <87fsha7ry7.fsf@gmail.com>
Message-ID: <88618974179310956c472d142be745a44f6eb8ef.camel@aatal-apotheke.de>

In my real use case, things are not as simple as the example Foo, of
course. 
There are fields of the same type, distributed across the choices, but
some are optional in some choices and mandatory in others. Rank-1
parameters permit a range including, but not limited, to
	Indentity  -- mandatory
	Maybe      -- optional
	Const ()   -- missing
	Const Void -- constructor disallowed

e.g. 

data Bar left right = LeftBar A (left O) | RightBar A B (right O)

type OptionalLeftMandatoryRight = Bar Maybe Identity
-- encodes: "If B is present so must be O, but if not, O is optional".

type OnlyA = Bar (Const ()) (Const Void)
-- isomorphic to A 

getO :: Applicative f => Bar f Identity -> f O
getO (LeftBar _ o) = o
getO (RightBar _ _ (Identity o)) = pure o

getA :: Bar left right -> A
getA (LeftBar a _) = a
getA (RightBar a _ _) = a

With distinct data types for LeftBar and RightBar, the functions getO,
getA in their generality would only be possible via type classes. In
some sense, the type parameters act as an explicit type class
dictionary. I believe this is in the spirit of Trees that Grow, 
where the combination (left,right) = (Maybe,Identity) would be encoded
in a type family. 

Olaf

On Thu, 2022-09-01 at 22:33 +0200, Dominik Schrempf wrote:
> Chiming in here, maybe I missed something. Liquid Haskell is great, but in this
> case, in my opinion, easier is better:
> 
> newtype LeftFoo = LeftFoo !Int
> 
> newtype RightFoo = RightFoo !Char
> 
> data Foo = LFoo LeftFoo | RFoo RightFoo – Probably with strictness annotations.
> 
> isLeftFoo :: Foo -> Bool
> isLeftFoo (LFoo _) = True
> isLeftFoo _ = False
> 
> takesOnlyLeftFoo :: LeftFoo -> Int
> takesOnlyLeftFoo (LeftFoo i) = i
> 
> Dominik
> 
> Patrick L Redmond via Haskell-Cafe <haskell-cafe at haskell.org> writes:
> 
> >  Sometimes I feel the need to selectively allow or disallow alternatives
> > 
> > This seems like the kind of lightweight property that Liquid Haskell (a GHC plugin) is especially suited for. Here’s a small example of “at some
> > places in the program we want the type system to enforce that only the constructor LeftFoo can be used.”
> > 
> > data Foo = LeftFoo !Int | RightFoo !Char
> > 
> > {-@ measure isLeftFoo @-}
> > isLeftFoo :: Foo -> Bool
> > isLeftFoo LeftFoo{} = True
> > isLeftFoo _ = False
> > 
> > {-@ takesOnlyLeftFoo :: {x:Foo | isLeftFoo x} -> Int @-}
> > takesOnlyLeftFoo :: Foo -> Int
> > takesOnlyLeftFoo (LeftFoo i) = i
> > 
> > I’ve taken Olaf’s hypothetical Foo and swapped in Int for A and Char for B, defined a function isLeftFoo that returns True for LeftFoo-constructed
> > Foos, and I call isLeftFoo in the type of a function that is meant to only be called with LeftFoo values.
> > 
> > This syntax in the mushroom-at-symbol comments is a refinement type. It has the same structure as the haskell type `Foo -> Int` but adds a
> > precondition on the input that isLeftFoo returns True. When you compile your project with Liquid Haskell, the precondition will be checked at
> > compile time by checking that callers establish the fact on any value they pass into takesOnlyLeftFoo.
> > 
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
> > Only members subscribed via the mailman list are allowed to post.



From tonyzorman at mailbox.org  Sat Sep  3 14:24:00 2022
From: tonyzorman at mailbox.org (Tony Zorman)
Date: Sat, 03 Sep 2022 16:24:00 +0200
Subject: [Haskell-cafe] [ANN] xmonad and xmonad-contrib 0.17.1 are available
Message-ID: <87sfl8r0xr.fsf@hyperspace>

            ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
             XMONAD AND XMONAD-CONTRIB 0.17.1 ARE AVAILABLE
            ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

New versions of xmonad and xmonad-contrib have been released. Check out
our [download page] for instructions on where to get them.

About 10 months after the big release of 0.17.0, we—as promised—picked
up the pace a bit and are back with a new minor version; don't let that
fool you though, this one still packs a punch!  Plus, we now sport a
brand-new [logo], courtesy of [Hans Heintze].

As this is a minor release, we tried to keep the breaking changes to a
minimum (xmonad core does not have a single one!) However, some were
unavoidable for `xmonad-contrib', so be sure to at least glance at the
[release notes]!

For help getting started—or more info—see [our website] and [talk to
us]! If you like what we do, you can support us on [Open Collective] or
via [GitHub Sponsors]. Thanks!

[GitHub Sponsors] <https://github.com/sponsors/xmonad>
[Hans Heintze] <https://github.com/literallyunplayable>
[Open Collective] <https://opencollective.com/xmonad>
[download page] <https://xmonad.org/download.html>
[logo] <https://xmonad.org/images/logo.svg>
[our website] <https://xmonad.org/>
[release notes] See section 2
[talk to us] <https://xmonad.org/community.html>

1 xmonad 0.17.1
═══════════════

  This release includes 32 non-merge commits by 6 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.1/CHANGES.md>

1.1 Enhancements
────────────────

  • Added custom cursor shapes for resizing and moving windows.

1.2 Bug Fixes
─────────────

  • Change the main loop to try to avoid [GHC bug 21708] on systems
    running GHC 9.2 up to version 9.2.3. The issue has been fixed in
    [GHC 9.2.4] and all later releases.

  • Fixed border color of windows with alpha channel. Now all windows
    have the same opaque border color.

[GHC bug 21708] <https://gitlab.haskell.org/ghc/ghc/-/issues/21708>
[GHC 9.2.4] <https://discourse.haskell.org/t/ghc-9-2-4-released/4851>

2 xmonad-contrib 0.17.1
═══════════════════════

  This release includes 212 non-merge commits by 32 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.1/CHANGES.md>

2.1 Breaking Changes
────────────────────

  • `XMonad.Config.{Arossato,Dmwit,Droundy,Monad,Prime,Saegesser,Sjanssen}':
    deprecated all of these modules. The user-specific configuration
    modules may still be found [on the website].

  • `XMonad.Util.NamedScratchpad': scratchpads are now only based on the
    argument given to `namedScratchpadManageHook'; all other scratchpad
    arguments are, while still present, ignored. Users passing all of
    their scratchpads to functions like `namedScratchpadAction' (as is
    shown in the module's documentation) should /not/ notice any
    difference in behaviour.

  • `XMonad.Util.DynamicScratchpads': deprecated the module; use the new
    dynamic scratchpad functionality of `XMonad.Util.NamedScratchpad'
    instead.

  • `XMonad.Hooks.UrgencyHook': deprecated `urgencyConfig'; use `def'
    from the new `Default' instance of `UrgencyConfig' instead.

[on the website] <https://xmonad.org/configurations.html>

2.2 New Modules
───────────────

  • `XMonad.Hooks.Modal': a module implementing modal keybindings for
    XMonad.

  • `XMonad.Layout.SideBorderDecoration': this module allows for having
    a configurable border position around windows; i.e., it can move the
    border to either cardinal direction.

  • `XMonad.Actions.PerLayoutKeys': a new module for customising
    keybindings on a per-layout basis.

  • `XMonad.Actions.RepeatAction': a module for adding a keybinding to
    repeat the last action, similar to Vim's `.' or Emacs's `dot-mode'.

2.3 Bug Fixes and Minor Changes
───────────────────────────────

  • `XMonad.Prompt' and `XMonad.Actions.TreeSelect': added xft-based
    font fallback support. This may be used by appending other fonts to
    the given string: `xft:iosevka-11,FontAwesome-9'. Note that this
    requires `xmonad-contrib' to be compiled with `X11-xft' version
    0.3.4 or higher.

  • `XMonad.Util.Run': added an EDSL—particularly geared towards
    programs like terminals or Emacs—to spawn processes from XMonad in a
    compositional way.

  • `XMonad.Util.Hacks': added `trayerPaddingXmobarEventHook' (plus
    generic variants for other trays/panels) to communicate trayer
    resize events to xmobar so that padding space may be reserved on
    xmobar for the tray. Requires `xmobar' version 0.40 or higher.

  • `XMonad.Prompt.OrgMode': added the ability to specify alphabetic
    (`#A', `#B', and `#C') [priorities] at the end of the input note.

  • `XMonad.Actions.Submap': added `visualSubmap' to visualise the
    available keys and their actions when inside a submap.

  • `XMonad.Util.NamedScratchpad': added support for dynamic scratchpads
    in the form of `dynamicNSPAction' and `toggleDynamicNSP'.

  • `XMonad.Hooks.WindowSwallowing': fixed windows getting lost when
    used in conjunction with `smartBorders' and a single window.

[priorities] <https://orgmode.org/manual/Priorities.html>

-- 
Tony Zorman | https://tony-zorman.com/

From goemansrowan at gmail.com  Sat Sep  3 14:31:12 2022
From: goemansrowan at gmail.com (rowan goemans)
Date: Sat, 3 Sep 2022 16:31:12 +0200
Subject: [Haskell-cafe] Getting a breakdown of time spend in compile phases
Message-ID: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>

Dear Cafe,

I have a Haskell Project where I have a module that quite heavily makes 
use of constraints and takes ages to compile per module. It also uses 
some type checker plugins but I'm unsure if they are causing the 
slowness. So what I would like to see is a breakdown of how much time 
GHC is spending on compilation of a module. Does something like this exist?

Best regards,

Rowan Goemans


From allbery.b at gmail.com  Sat Sep  3 14:34:46 2022
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 3 Sep 2022 10:34:46 -0400
Subject: [Haskell-cafe] Getting a breakdown of time spend in compile
	phases
In-Reply-To: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>
References: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>
Message-ID: <CAKFCL4VccGuOLiUKo8HnUL+yRXrAKrP38rGsUuq+6t-GuvWLmg@mail.gmail.com>

There is `-ddump-timings`.

On Sat, Sep 3, 2022 at 10:31 AM rowan goemans <goemansrowan at gmail.com> wrote:
>
> Dear Cafe,
>
> I have a Haskell Project where I have a module that quite heavily makes
> use of constraints and takes ages to compile per module. It also uses
> some type checker plugins but I'm unsure if they are causing the
> slowness. So what I would like to see is a breakdown of how much time
> GHC is spending on compilation of a module. Does something like this exist?
>
> Best regards,
>
> Rowan Goemans
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From goemansrowan at gmail.com  Sat Sep  3 14:36:57 2022
From: goemansrowan at gmail.com (rowan goemans)
Date: Sat, 3 Sep 2022 16:36:57 +0200
Subject: [Haskell-cafe] Getting a breakdown of time spend in compile
 phases
In-Reply-To: <CAKFCL4VccGuOLiUKo8HnUL+yRXrAKrP38rGsUuq+6t-GuvWLmg@mail.gmail.com>
References: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>
 <CAKFCL4VccGuOLiUKo8HnUL+yRXrAKrP38rGsUuq+6t-GuvWLmg@mail.gmail.com>
Message-ID: <74b676f3-66e2-5073-b185-7542465ed576@gmail.com>

Great, exactly what I was looking for, thanks! For some reason I wasn't 
able to find this.

On 9/3/22 16:34, Brandon Allbery wrote:
> There is `-ddump-timings`.
>
> On Sat, Sep 3, 2022 at 10:31 AM rowan goemans <goemansrowan at gmail.com> wrote:
>> Dear Cafe,
>>
>> I have a Haskell Project where I have a module that quite heavily makes
>> use of constraints and takes ages to compile per module. It also uses
>> some type checker plugins but I'm unsure if they are causing the
>> slowness. So what I would like to see is a breakdown of how much time
>> GHC is spending on compilation of a module. Does something like this exist?
>>
>> Best regards,
>>
>> Rowan Goemans
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>

From hecate at glitchbra.in  Sat Sep  3 18:21:06 2022
From: hecate at glitchbra.in (=?UTF-8?B?SMOpY2F0ZQ==?=)
Date: Sat, 03 Sep 2022 20:21:06 +0200
Subject: [Haskell-cafe] Getting a breakdown of time spend in compile
	phases
In-Reply-To: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>
References: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>
Message-ID: <1830495be50.278a.00f17733d2c9eabc5e044ce8e37597ac@glitchbra.in>

Hi Rowan,

I had a nice experience using 
https://github.com/codedownio/time-ghc-modules. Do tell us if this fits 
your needs. :)

Cheers,
Hécate

Le 3 septembre 2022 16:31:35 rowan goemans <goemansrowan at gmail.com> a écrit :

> Dear Cafe,
>
> I have a Haskell Project where I have a module that quite heavily makes
> use of constraints and takes ages to compile per module. It also uses
> some type checker plugins but I'm unsure if they are causing the
> slowness. So what I would like to see is a breakdown of how much time
> GHC is spending on compilation of a module. Does something like this exist?
>
> Best regards,
>
> Rowan Goemans
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220903/11c49708/attachment.html>

From goemansrowan at gmail.com  Sat Sep  3 20:56:42 2022
From: goemansrowan at gmail.com (rowan goemans)
Date: Sat, 3 Sep 2022 22:56:42 +0200
Subject: [Haskell-cafe] Getting a breakdown of time spend in compile
 phases
In-Reply-To: <1830495be50.278a.00f17733d2c9eabc5e044ce8e37597ac@glitchbra.in>
References: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>
 <1830495be50.278a.00f17733d2c9eabc5e044ce8e37597ac@glitchbra.in>
Message-ID: <2f8d0b5b-03c9-0d29-7ff7-7752708a8d5b@gmail.com>

Hi Hécate,

Thank you this helps a lot. I now at least have confirmed my suspicion 
that it's the type checker. It spends a whopping 50 seconds in there for 
a module not even 300 lines of code. Is there someway to analyze the 
type checker specifically? I know there is tc-trace but that doesn't 
really tell me what is taking long.

Best regards,

Rowan Goemans

On 9/3/22 20:21, Hécate wrote:
> Hi Rowan,
>
> I had a nice experience using 
> https://github.com/codedownio/time-ghc-modules. Do tell us if this 
> fits your needs. :)
>
> Cheers,
> Hécate
>
> Le 3 septembre 2022 16:31:35 rowan goemans <goemansrowan at gmail.com> a 
> écrit :
>
>> Dear Cafe,
>>
>> I have a Haskell Project where I have a module that quite heavily makes
>> use of constraints and takes ages to compile per module. It also uses
>> some type checker plugins but I'm unsure if they are causing the
>> slowness. So what I would like to see is a breakdown of how much time
>> GHC is spending on compilation of a module. Does something like this 
>> exist?
>>
>> Best regards,
>>
>> Rowan Goemans
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220903/c3916522/attachment.html>

From simon.jakobi at googlemail.com  Sat Sep  3 21:08:41 2022
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Sat, 3 Sep 2022 23:08:41 +0200
Subject: [Haskell-cafe] Getting a breakdown of time spend in compile
	phases
In-Reply-To: <2f8d0b5b-03c9-0d29-7ff7-7752708a8d5b@gmail.com>
References: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>
 <1830495be50.278a.00f17733d2c9eabc5e044ce8e37597ac@glitchbra.in>
 <2f8d0b5b-03c9-0d29-7ff7-7752708a8d5b@gmail.com>
Message-ID: <CAGtp2Sj7ZhzH-bE0oLRbgTNPDefaigD84m917yFMVnpWT_nfDg@mail.gmail.com>

You may find more help with debugging GHC on the ghc-devs mailing list:
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Am Sa., 3. Sept. 2022 um 22:57 Uhr schrieb rowan goemans <
goemansrowan at gmail.com>:

> Hi Hécate,
>
> Thank you this helps a lot. I now at least have confirmed my suspicion
> that it's the type checker. It spends a whopping 50 seconds in there for a
> module not even 300 lines of code. Is there someway to analyze the type
> checker specifically? I know there is tc-trace but that doesn't really tell
> me what is taking long.
>
> Best regards,
>
> Rowan Goemans
> On 9/3/22 20:21, Hécate wrote:
>
> Hi Rowan,
>
> I had a nice experience using
> https://github.com/codedownio/time-ghc-modules. Do tell us if this fits
> your needs. :)
>
> Cheers,
> Hécate
>
> Le 3 septembre 2022 16:31:35 rowan goemans <goemansrowan at gmail.com>
> <goemansrowan at gmail.com> a écrit :
>
> Dear Cafe,
>>
>> I have a Haskell Project where I have a module that quite heavily makes
>> use of constraints and takes ages to compile per module. It also uses
>> some type checker plugins but I'm unsure if they are causing the
>> slowness. So what I would like to see is a breakdown of how much time
>> GHC is spending on compilation of a module. Does something like this
>> exist?
>>
>> Best regards,
>>
>> Rowan Goemans
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220903/1b3dbb36/attachment.html>

From harendra.kumar at gmail.com  Sun Sep  4 07:56:09 2022
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Sun, 4 Sep 2022 13:26:09 +0530
Subject: [Haskell-cafe] Getting a breakdown of time spend in compile
	phases
In-Reply-To: <2f8d0b5b-03c9-0d29-7ff7-7752708a8d5b@gmail.com>
References: <21c1d3ff-eb29-c6c5-0483-2d1201a3955c@gmail.com>
 <1830495be50.278a.00f17733d2c9eabc5e044ce8e37597ac@glitchbra.in>
 <2f8d0b5b-03c9-0d29-7ff7-7752708a8d5b@gmail.com>
Message-ID: <CAPW+kka_cCyut7DfbZsV-+hEP29YdLZhKJBe8OXhvsYtzdbTeA@mail.gmail.com>

You may want to take a look at this talk
https://www.youtube.com/watch?v=ABScdJqy5wg by Edsko. It talks about
several cases where the compile time may blow up quadratically
depending on the size of the structure. Your problem might be
something similar. Also see
https://hackage.haskell.org/package/large-records .

-harendra

On Sun, 4 Sept 2022 at 02:26, rowan goemans <goemansrowan at gmail.com> wrote:
>
> Hi Hécate,
>
> Thank you this helps a lot. I now at least have confirmed my suspicion that it's the type checker. It spends a whopping 50 seconds in there for a module not even 300 lines of code. Is there someway to analyze the type checker specifically? I know there is tc-trace but that doesn't really tell me what is taking long.
>
> Best regards,
>
> Rowan Goemans
>
> On 9/3/22 20:21, Hécate wrote:
>
> Hi Rowan,
>
> I had a nice experience using https://github.com/codedownio/time-ghc-modules. Do tell us if this fits your needs. :)
>
> Cheers,
> Hécate
>
> Le 3 septembre 2022 16:31:35 rowan goemans <goemansrowan at gmail.com> a écrit :
>
>> Dear Cafe,
>>
>> I have a Haskell Project where I have a module that quite heavily makes
>> use of constraints and takes ages to compile per module. It also uses
>> some type checker plugins but I'm unsure if they are causing the
>> slowness. So what I would like to see is a breakdown of how much time
>> GHC is spending on compilation of a module. Does something like this exist?
>>
>> Best regards,
>>
>> Rowan Goemans
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From dburke.gw at gmail.com  Mon Sep  5 22:00:30 2022
From: dburke.gw at gmail.com (Doug Burke)
Date: Mon, 5 Sep 2022 18:00:30 -0400
Subject: [Haskell-cafe] any advice for tracking down a failure to compile
 (it just hangs) with ghc 9.2.4?
Message-ID: <CALkjVLDH1kK2+BO27VmGoXPxkfGvtrVFEjrwsLFb+9g20F-PDQ@mail.gmail.com>

I have noticed I can't run one of my tests when building with ghc
9.2.4 (tried via stack and nix) that doesn't happen with ghc 9.2.3 (or
older versions).

Is there a way to diagnose the problem (so I can look at the ghc bug
tracker or try and make the code smaller for testing)?

I can see this behavior with the following reproducer (it's a bit
heavyweight at the moment!):

% git clone https://gitlab.com/dburke/swish temp
% cd temp

Added to get the timings, but it's not strictly necessary:

% sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal

Now try to build and run the test. The following build and run the
test quickly if using an older GHC (e.g. "--resolver lts" for the
stack case or "--argstr compiler ghc923" for the nix case).

First with stack

% sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal
% stack test --resolver nightly-2022-09-05 :test-rdfproof
Stack has not been tested with GHC versions above 9.0, and using
9.2.4, this may fail
Stack has not been tested with Cabal versions above 3.4, but version
3.6.3.0 was found, this may fail
swish> configure (lib + test)
Configuring swish-0.10.2.0...
swish> build (lib + test)
Preprocessing library for swish-0.10.2.0..
Building library for swish-0.10.2.0..
Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0..
Building test suite 'test-rdfproof' for swish-0.10.2.0..
*** initializing unit database:
initializing unit database: alloc=7350056 time=8.753
*** initializing unit database:
initializing unit database: alloc=3999144 time=16.194
*** Chasing dependencies:
*** systool:cpp:
systool:cpp: alloc=271104 time=1.991
Chasing dependencies: alloc=10233768 time=8.400
[2 of 2] Compiling Main
*** Parser [Main]:
Parser [Main]: alloc=24346344 time=33.067
*** Renamer/typechecker [Main]:
Renamer/typechecker [Main]: alloc=101896128 time=134.992
*** Desugar [Main]:
Desugar [Main]: alloc=24628816 time=24.813
*** Simplifier [Main]:
Simplifier [Main]: alloc=667236400 time=775.137
*** Specialise [Main]:
Specialise [Main]: alloc=45057312 time=40.543
*** Float out(FOS {Lam = Just 0,
                   Consts = True,
                   OverSatApps = False}) [Main]:
Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
[Main]: alloc=208806472 time=330.396
*** Simplifier [Main]:
Simplifier [Main]: alloc=603245992 time=747.067
*** Simplifier [Main]:
Simplifier [Main]: alloc=564322584 time=709.583
*** Simplifier [Main]:
Simplifier [Main]: alloc=728039528 time=835.525
*** Float inwards [Main]:
*** Called arity analysis [Main]:
*** Simplifier [Main]:
Float inwards [Main]: alloc=23720 time=0.017
Called arity analysis [Main]: alloc=25848 time=0.016
Progress 0/2


Now with nix

% nix-shell --argstr compiler ghc924
... wait an indeterminate amount of time
% ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.4
% cabal test test-rdfproof
Warning: The package list for 'hackage.haskell.org' is 19 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
Build profile: -w ghc-9.2.4 -O1
In order, the following will be built (use -v for more details):
 - swish-0.10.2.0 (lib) (first run)
 - swish-0.10.2.0 (test:test-rdfproof) (first run)
Configuring library for swish-0.10.2.0..
Preprocessing library for swish-0.10.2.0..
Building library for swish-0.10.2.0..
[ 1 of 55] Compiling Data.Interned.URI
[ 2 of 55] Compiling Data.Ord.Partial
[ 3 of 55] Compiling Data.String.ShowLines
[ 4 of 55] Compiling Network.URI.Ord
[ 5 of 55] Compiling Swish.GraphClass
...
... a lot more, including some annoying non-exhaustive patterns I
don't know how to fix
... but that's for a different post
...
[55 of 55] Compiling Swish
Configuring test suite 'test-rdfproof' for swish-0.10.2.0..
Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0..
Building test suite 'test-rdfproof' for swish-0.10.2.0..
*** initializing unit database:
initializing unit database: alloc=7389248 time=4.436
*** initializing unit database:
initializing unit database: alloc=4001312 time=11.992
*** Chasing dependencies:
*** systool:cpp:
systool:cpp: alloc=319464 time=0.520
Chasing dependencies: alloc=12863280 time=6.581
[1 of 2] Compiling TestHelpers      ( tests/TestHelpers.hs,
/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.o
)
*** Parser [TestHelpers]:
Parser [TestHelpers]: alloc=5469952 time=2.325
*** Renamer/typechecker [TestHelpers]:
Renamer/typechecker [TestHelpers]: alloc=94049744 time=106.001
*** Desugar [TestHelpers]:
Desugar [TestHelpers]: alloc=5551840 time=2.974
*** Simplifier [TestHelpers]:
Simplifier [TestHelpers]: alloc=45720248 time=28.537
*** Specialise [TestHelpers]:
Specialise [TestHelpers]: alloc=2198344 time=0.717
*** Float out(FOS {Lam = Just 0,
                   Consts = True,
                   OverSatApps = False}) [TestHelpers]:
Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
[TestHelpers]: alloc=6183280 time=3.109
*** Simplifier [TestHelpers]:
Simplifier [TestHelpers]: alloc=27272104 time=16.042
*** Simplifier [TestHelpers]:
Simplifier [TestHelpers]: alloc=20805544 time=12.332
*** Simplifier [TestHelpers]:
Simplifier [TestHelpers]: alloc=6175584 time=2.825
*** Float inwards [TestHelpers]:
Float inwards [TestHelpers]: alloc=26272 time=0.012
*** Called arity analysis [TestHelpers]:
Called arity analysis [TestHelpers]: alloc=28392 time=0.012
*** Simplifier [TestHelpers]:
Simplifier [TestHelpers]: alloc=14755744 time=7.017
*** Demand analysis [TestHelpers]:
Demand analysis [TestHelpers]: alloc=2061096 time=1.296
*** Constructed Product Result analysis [TestHelpers]:
Constructed Product Result analysis [TestHelpers]: alloc=466968 time=0.197
*** Worker Wrapper binds [TestHelpers]:
Worker Wrapper binds [TestHelpers]: alloc=436552 time=0.201
*** Simplifier [TestHelpers]:
Simplifier [TestHelpers]: alloc=31897488 time=18.652
*** Exitification transformation [TestHelpers]:
Exitification transformation [TestHelpers]: alloc=29808 time=0.013
*** Float out(FOS {Lam = Just 0,
                   Consts = True,
                   OverSatApps = True}) [TestHelpers]:
Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True})
[TestHelpers]: alloc=5508568 time=4.009
*** Common sub-expression [TestHelpers]:
Common sub-expression [TestHelpers]: alloc=27896 time=0.013
*** Float inwards [TestHelpers]:
Float inwards [TestHelpers]: alloc=26272 time=0.021
*** Simplifier [TestHelpers]:
Simplifier [TestHelpers]: alloc=24835440 time=15.291
*** Demand analysis [TestHelpers]:
Demand analysis [TestHelpers]: alloc=2214560 time=1.044
*** CoreTidy [TestHelpers]:
CoreTidy [TestHelpers]: alloc=2814672 time=1.457
*** CorePrep [TestHelpers]:
CorePrep [TestHelpers]: alloc=1965920 time=2.636
*** CoreToStg [TestHelpers]:
CoreToStg [TestHelpers]: alloc=3134560 time=1.484
*** CodeGen [TestHelpers]:
CodeGen [TestHelpers]: alloc=80232584 time=46.410
*** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]:
WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]:
alloc=1780688 time=0.766
*** systool:as:
systool:as: alloc=137200 time=0.360
[2 of 2] Compiling Main             ( tests/RDFProofTest.hs,
/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o
)
*** Parser [Main]:
Parser [Main]: alloc=25235720 time=8.851
*** Renamer/typechecker [Main]:
Renamer/typechecker [Main]: alloc=58415520 time=45.291
*** Desugar [Main]:
Desugar [Main]: alloc=22098688 time=46.709
*** Simplifier [Main]:
Simplifier [Main]: alloc=654052760 time=511.390
*** Specialise [Main]:
Specialise [Main]: alloc=44439912 time=34.132
*** Float out(FOS {Lam = Just 0,
                   Consts = True,
                   OverSatApps = False}) [Main]:
Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
[Main]: alloc=208317448 time=252.154
*** Simplifier [Main]:
Simplifier [Main]: alloc=601002912 time=546.343
*** Simplifier [Main]:
Simplifier [Main]: alloc=564371608 time=546.970
*** Simplifier [Main]:
Simplifier [Main]: alloc=726902400 time=613.423
*** Float inwards [Main]:
Float inwards [Main]: alloc=23720 time=0.024
*** Called arity analysis [Main]:
Called arity analysis [Main]: alloc=25856 time=0.013
*** Simplifier [Main]:

At this point my laptop just sits there making whooshing noises as if
it's trying to become an aeroplane, but it never gets to where it's
going (to mix up my metaphors).

Any help would be appreciated,
Doug

From simon.jakobi at googlemail.com  Tue Sep  6 12:08:15 2022
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Tue, 6 Sep 2022 14:08:15 +0200
Subject: [Haskell-cafe] any advice for tracking down a failure to
 compile (it just hangs) with ghc 9.2.4?
In-Reply-To: <CALkjVLDH1kK2+BO27VmGoXPxkfGvtrVFEjrwsLFb+9g20F-PDQ@mail.gmail.com>
References: <CALkjVLDH1kK2+BO27VmGoXPxkfGvtrVFEjrwsLFb+9g20F-PDQ@mail.gmail.com>
Message-ID: <CAGtp2SjMjTcO6W0kVFw9W7do+rjLTDbkR5F1j6ue__W4rA4vbg@mail.gmail.com>

Since this seems to be a regression in 9.2.4, I'd suggest not to wait too
long with reporting this on GHC's issue tracker. The GHC devs can also give
you advice on diagnosing this further.

Am Di., 6. Sept. 2022 um 00:01 Uhr schrieb Doug Burke <dburke.gw at gmail.com>:

> I have noticed I can't run one of my tests when building with ghc
> 9.2.4 (tried via stack and nix) that doesn't happen with ghc 9.2.3 (or
> older versions).
>
> Is there a way to diagnose the problem (so I can look at the ghc bug
> tracker or try and make the code smaller for testing)?
>
> I can see this behavior with the following reproducer (it's a bit
> heavyweight at the moment!):
>
> % git clone https://gitlab.com/dburke/swish temp
> % cd temp
>
> Added to get the timings, but it's not strictly necessary:
>
> % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal
>
> Now try to build and run the test. The following build and run the
> test quickly if using an older GHC (e.g. "--resolver lts" for the
> stack case or "--argstr compiler ghc923" for the nix case).
>
> First with stack
>
> % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal
> % stack test --resolver nightly-2022-09-05 :test-rdfproof
> Stack has not been tested with GHC versions above 9.0, and using
> 9.2.4, this may fail
> Stack has not been tested with Cabal versions above 3.4, but version
> 3.6.3.0 was found, this may fail
> swish> configure (lib + test)
> Configuring swish-0.10.2.0...
> swish> build (lib + test)
> Preprocessing library for swish-0.10.2.0..
> Building library for swish-0.10.2.0..
> Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0..
> Building test suite 'test-rdfproof' for swish-0.10.2.0..
> *** initializing unit database:
> initializing unit database: alloc=7350056 time=8.753
> *** initializing unit database:
> initializing unit database: alloc=3999144 time=16.194
> *** Chasing dependencies:
> *** systool:cpp:
> systool:cpp: alloc=271104 time=1.991
> Chasing dependencies: alloc=10233768 time=8.400
> [2 of 2] Compiling Main
> *** Parser [Main]:
> Parser [Main]: alloc=24346344 time=33.067
> *** Renamer/typechecker [Main]:
> Renamer/typechecker [Main]: alloc=101896128 time=134.992
> *** Desugar [Main]:
> Desugar [Main]: alloc=24628816 time=24.813
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=667236400 time=775.137
> *** Specialise [Main]:
> Specialise [Main]: alloc=45057312 time=40.543
> *** Float out(FOS {Lam = Just 0,
>                    Consts = True,
>                    OverSatApps = False}) [Main]:
> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
> [Main]: alloc=208806472 time=330.396
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=603245992 time=747.067
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=564322584 time=709.583
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=728039528 time=835.525
> *** Float inwards [Main]:
> *** Called arity analysis [Main]:
> *** Simplifier [Main]:
> Float inwards [Main]: alloc=23720 time=0.017
> Called arity analysis [Main]: alloc=25848 time=0.016
> Progress 0/2
>
>
> Now with nix
>
> % nix-shell --argstr compiler ghc924
> ... wait an indeterminate amount of time
> % ghc --version
> The Glorious Glasgow Haskell Compilation System, version 9.2.4
> % cabal test test-rdfproof
> Warning: The package list for 'hackage.haskell.org' is 19 days old.
> Run 'cabal update' to get the latest list of available packages.
> Resolving dependencies...
> Build profile: -w ghc-9.2.4 -O1
> In order, the following will be built (use -v for more details):
>  - swish-0.10.2.0 (lib) (first run)
>  - swish-0.10.2.0 (test:test-rdfproof) (first run)
> Configuring library for swish-0.10.2.0..
> Preprocessing library for swish-0.10.2.0..
> Building library for swish-0.10.2.0..
> [ 1 of 55] Compiling Data.Interned.URI
> [ 2 of 55] Compiling Data.Ord.Partial
> [ 3 of 55] Compiling Data.String.ShowLines
> [ 4 of 55] Compiling Network.URI.Ord
> [ 5 of 55] Compiling Swish.GraphClass
> ...
> ... a lot more, including some annoying non-exhaustive patterns I
> don't know how to fix
> ... but that's for a different post
> ...
> [55 of 55] Compiling Swish
> Configuring test suite 'test-rdfproof' for swish-0.10.2.0..
> Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0..
> Building test suite 'test-rdfproof' for swish-0.10.2.0..
> *** initializing unit database:
> initializing unit database: alloc=7389248 time=4.436
> *** initializing unit database:
> initializing unit database: alloc=4001312 time=11.992
> *** Chasing dependencies:
> *** systool:cpp:
> systool:cpp: alloc=319464 time=0.520
> Chasing dependencies: alloc=12863280 time=6.581
> [1 of 2] Compiling TestHelpers      ( tests/TestHelpers.hs,
>
> /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.o
> )
> *** Parser [TestHelpers]:
> Parser [TestHelpers]: alloc=5469952 time=2.325
> *** Renamer/typechecker [TestHelpers]:
> Renamer/typechecker [TestHelpers]: alloc=94049744 time=106.001
> *** Desugar [TestHelpers]:
> Desugar [TestHelpers]: alloc=5551840 time=2.974
> *** Simplifier [TestHelpers]:
> Simplifier [TestHelpers]: alloc=45720248 time=28.537
> *** Specialise [TestHelpers]:
> Specialise [TestHelpers]: alloc=2198344 time=0.717
> *** Float out(FOS {Lam = Just 0,
>                    Consts = True,
>                    OverSatApps = False}) [TestHelpers]:
> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
> [TestHelpers]: alloc=6183280 time=3.109
> *** Simplifier [TestHelpers]:
> Simplifier [TestHelpers]: alloc=27272104 time=16.042
> *** Simplifier [TestHelpers]:
> Simplifier [TestHelpers]: alloc=20805544 time=12.332
> *** Simplifier [TestHelpers]:
> Simplifier [TestHelpers]: alloc=6175584 time=2.825
> *** Float inwards [TestHelpers]:
> Float inwards [TestHelpers]: alloc=26272 time=0.012
> *** Called arity analysis [TestHelpers]:
> Called arity analysis [TestHelpers]: alloc=28392 time=0.012
> *** Simplifier [TestHelpers]:
> Simplifier [TestHelpers]: alloc=14755744 time=7.017
> *** Demand analysis [TestHelpers]:
> Demand analysis [TestHelpers]: alloc=2061096 time=1.296
> *** Constructed Product Result analysis [TestHelpers]:
> Constructed Product Result analysis [TestHelpers]: alloc=466968 time=0.197
> *** Worker Wrapper binds [TestHelpers]:
> Worker Wrapper binds [TestHelpers]: alloc=436552 time=0.201
> *** Simplifier [TestHelpers]:
> Simplifier [TestHelpers]: alloc=31897488 time=18.652
> *** Exitification transformation [TestHelpers]:
> Exitification transformation [TestHelpers]: alloc=29808 time=0.013
> *** Float out(FOS {Lam = Just 0,
>                    Consts = True,
>                    OverSatApps = True}) [TestHelpers]:
> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True})
> [TestHelpers]: alloc=5508568 time=4.009
> *** Common sub-expression [TestHelpers]:
> Common sub-expression [TestHelpers]: alloc=27896 time=0.013
> *** Float inwards [TestHelpers]:
> Float inwards [TestHelpers]: alloc=26272 time=0.021
> *** Simplifier [TestHelpers]:
> Simplifier [TestHelpers]: alloc=24835440 time=15.291
> *** Demand analysis [TestHelpers]:
> Demand analysis [TestHelpers]: alloc=2214560 time=1.044
> *** CoreTidy [TestHelpers]:
> CoreTidy [TestHelpers]: alloc=2814672 time=1.457
> *** CorePrep [TestHelpers]:
> CorePrep [TestHelpers]: alloc=1965920 time=2.636
> *** CoreToStg [TestHelpers]:
> CoreToStg [TestHelpers]: alloc=3134560 time=1.484
> *** CodeGen [TestHelpers]:
> CodeGen [TestHelpers]: alloc=80232584 time=46.410
> *** WriteIface
> [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]:
> WriteIface
> [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]:
> alloc=1780688 time=0.766
> *** systool:as:
> systool:as: alloc=137200 time=0.360
> [2 of 2] Compiling Main             ( tests/RDFProofTest.hs,
>
> /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o
> )
> *** Parser [Main]:
> Parser [Main]: alloc=25235720 time=8.851
> *** Renamer/typechecker [Main]:
> Renamer/typechecker [Main]: alloc=58415520 time=45.291
> *** Desugar [Main]:
> Desugar [Main]: alloc=22098688 time=46.709
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=654052760 time=511.390
> *** Specialise [Main]:
> Specialise [Main]: alloc=44439912 time=34.132
> *** Float out(FOS {Lam = Just 0,
>                    Consts = True,
>                    OverSatApps = False}) [Main]:
> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
> [Main]: alloc=208317448 time=252.154
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=601002912 time=546.343
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=564371608 time=546.970
> *** Simplifier [Main]:
> Simplifier [Main]: alloc=726902400 time=613.423
> *** Float inwards [Main]:
> Float inwards [Main]: alloc=23720 time=0.024
> *** Called arity analysis [Main]:
> Called arity analysis [Main]: alloc=25856 time=0.013
> *** Simplifier [Main]:
>
> At this point my laptop just sits there making whooshing noises as if
> it's trying to become an aeroplane, but it never gets to where it's
> going (to mix up my metaphors).
>
> Any help would be appreciated,
> Doug
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220906/6b007ebe/attachment.html>

From dburke.gw at gmail.com  Tue Sep  6 13:02:45 2022
From: dburke.gw at gmail.com (Doug Burke)
Date: Tue, 6 Sep 2022 09:02:45 -0400
Subject: [Haskell-cafe] any advice for tracking down a failure to
 compile (it just hangs) with ghc 9.2.4?
In-Reply-To: <CAGtp2SjMjTcO6W0kVFw9W7do+rjLTDbkR5F1j6ue__W4rA4vbg@mail.gmail.com>
References: <CALkjVLDH1kK2+BO27VmGoXPxkfGvtrVFEjrwsLFb+9g20F-PDQ@mail.gmail.com>
 <CAGtp2SjMjTcO6W0kVFw9W7do+rjLTDbkR5F1j6ue__W4rA4vbg@mail.gmail.com>
Message-ID: <CALkjVLBityvqYw_sD46XeCb0hZ5=_ZvE=t1n83eCtihnOnOptw@mail.gmail.com>

Cheers - email sent to ghc-devs.

Doug

On Tue, Sep 6, 2022 at 8:08 AM Simon Jakobi <simon.jakobi at googlemail.com> wrote:
>
> Since this seems to be a regression in 9.2.4, I'd suggest not to wait too long with reporting this on GHC's issue tracker. The GHC devs can also give you advice on diagnosing this further.
>
> Am Di., 6. Sept. 2022 um 00:01 Uhr schrieb Doug Burke <dburke.gw at gmail.com>:
>>
>> I have noticed I can't run one of my tests when building with ghc
>> 9.2.4 (tried via stack and nix) that doesn't happen with ghc 9.2.3 (or
>> older versions).
>>
>> Is there a way to diagnose the problem (so I can look at the ghc bug
>> tracker or try and make the code smaller for testing)?
>>
>> I can see this behavior with the following reproducer (it's a bit
>> heavyweight at the moment!):
>>
>> % git clone https://gitlab.com/dburke/swish temp
>> % cd temp
>>
>> Added to get the timings, but it's not strictly necessary:
>>
>> % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal
>>
>> Now try to build and run the test. The following build and run the
>> test quickly if using an older GHC (e.g. "--resolver lts" for the
>> stack case or "--argstr compiler ghc923" for the nix case).
>>
>> First with stack
>>
>> % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal
>> % stack test --resolver nightly-2022-09-05 :test-rdfproof
>> Stack has not been tested with GHC versions above 9.0, and using
>> 9.2.4, this may fail
>> Stack has not been tested with Cabal versions above 3.4, but version
>> 3.6.3.0 was found, this may fail
>> swish> configure (lib + test)
>> Configuring swish-0.10.2.0...
>> swish> build (lib + test)
>> Preprocessing library for swish-0.10.2.0..
>> Building library for swish-0.10.2.0..
>> Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0..
>> Building test suite 'test-rdfproof' for swish-0.10.2.0..
>> *** initializing unit database:
>> initializing unit database: alloc=7350056 time=8.753
>> *** initializing unit database:
>> initializing unit database: alloc=3999144 time=16.194
>> *** Chasing dependencies:
>> *** systool:cpp:
>> systool:cpp: alloc=271104 time=1.991
>> Chasing dependencies: alloc=10233768 time=8.400
>> [2 of 2] Compiling Main
>> *** Parser [Main]:
>> Parser [Main]: alloc=24346344 time=33.067
>> *** Renamer/typechecker [Main]:
>> Renamer/typechecker [Main]: alloc=101896128 time=134.992
>> *** Desugar [Main]:
>> Desugar [Main]: alloc=24628816 time=24.813
>> *** Simplifier [Main]:
>> Simplifier [Main]: alloc=667236400 time=775.137
>> *** Specialise [Main]:
>> Specialise [Main]: alloc=45057312 time=40.543
>> *** Float out(FOS {Lam = Just 0,
>>                    Consts = True,
>>                    OverSatApps = False}) [Main]:
>> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
>> [Main]: alloc=208806472 time=330.396
>> *** Simplifier [Main]:
>> Simplifier [Main]: alloc=603245992 time=747.067
>> *** Simplifier [Main]:
>> Simplifier [Main]: alloc=564322584 time=709.583
>> *** Simplifier [Main]:
>> Simplifier [Main]: alloc=728039528 time=835.525
>> *** Float inwards [Main]:
>> *** Called arity analysis [Main]:
>> *** Simplifier [Main]:
>> Float inwards [Main]: alloc=23720 time=0.017
>> Called arity analysis [Main]: alloc=25848 time=0.016
>> Progress 0/2
>>
>>
>> Now with nix
>>
>> % nix-shell --argstr compiler ghc924
>> ... wait an indeterminate amount of time
>> % ghc --version
>> The Glorious Glasgow Haskell Compilation System, version 9.2.4
>> % cabal test test-rdfproof
>> Warning: The package list for 'hackage.haskell.org' is 19 days old.
>> Run 'cabal update' to get the latest list of available packages.
>> Resolving dependencies...
>> Build profile: -w ghc-9.2.4 -O1
>> In order, the following will be built (use -v for more details):
>>  - swish-0.10.2.0 (lib) (first run)
>>  - swish-0.10.2.0 (test:test-rdfproof) (first run)
>> Configuring library for swish-0.10.2.0..
>> Preprocessing library for swish-0.10.2.0..
>> Building library for swish-0.10.2.0..
>> [ 1 of 55] Compiling Data.Interned.URI
>> [ 2 of 55] Compiling Data.Ord.Partial
>> [ 3 of 55] Compiling Data.String.ShowLines
>> [ 4 of 55] Compiling Network.URI.Ord
>> [ 5 of 55] Compiling Swish.GraphClass
>> ...
>> ... a lot more, including some annoying non-exhaustive patterns I
>> don't know how to fix
>> ... but that's for a different post
>> ...
>> [55 of 55] Compiling Swish
>> Configuring test suite 'test-rdfproof' for swish-0.10.2.0..
>> Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0..
>> Building test suite 'test-rdfproof' for swish-0.10.2.0..
>> *** initializing unit database:
>> initializing unit database: alloc=7389248 time=4.436
>> *** initializing unit database:
>> initializing unit database: alloc=4001312 time=11.992
>> *** Chasing dependencies:
>> *** systool:cpp:
>> systool:cpp: alloc=319464 time=0.520
>> Chasing dependencies: alloc=12863280 time=6.581
>> [1 of 2] Compiling TestHelpers      ( tests/TestHelpers.hs,
>> /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.o
>> )
>> *** Parser [TestHelpers]:
>> Parser [TestHelpers]: alloc=5469952 time=2.325
>> *** Renamer/typechecker [TestHelpers]:
>> Renamer/typechecker [TestHelpers]: alloc=94049744 time=106.001
>> *** Desugar [TestHelpers]:
>> Desugar [TestHelpers]: alloc=5551840 time=2.974
>> *** Simplifier [TestHelpers]:
>> Simplifier [TestHelpers]: alloc=45720248 time=28.537
>> *** Specialise [TestHelpers]:
>> Specialise [TestHelpers]: alloc=2198344 time=0.717
>> *** Float out(FOS {Lam = Just 0,
>>                    Consts = True,
>>                    OverSatApps = False}) [TestHelpers]:
>> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
>> [TestHelpers]: alloc=6183280 time=3.109
>> *** Simplifier [TestHelpers]:
>> Simplifier [TestHelpers]: alloc=27272104 time=16.042
>> *** Simplifier [TestHelpers]:
>> Simplifier [TestHelpers]: alloc=20805544 time=12.332
>> *** Simplifier [TestHelpers]:
>> Simplifier [TestHelpers]: alloc=6175584 time=2.825
>> *** Float inwards [TestHelpers]:
>> Float inwards [TestHelpers]: alloc=26272 time=0.012
>> *** Called arity analysis [TestHelpers]:
>> Called arity analysis [TestHelpers]: alloc=28392 time=0.012
>> *** Simplifier [TestHelpers]:
>> Simplifier [TestHelpers]: alloc=14755744 time=7.017
>> *** Demand analysis [TestHelpers]:
>> Demand analysis [TestHelpers]: alloc=2061096 time=1.296
>> *** Constructed Product Result analysis [TestHelpers]:
>> Constructed Product Result analysis [TestHelpers]: alloc=466968 time=0.197
>> *** Worker Wrapper binds [TestHelpers]:
>> Worker Wrapper binds [TestHelpers]: alloc=436552 time=0.201
>> *** Simplifier [TestHelpers]:
>> Simplifier [TestHelpers]: alloc=31897488 time=18.652
>> *** Exitification transformation [TestHelpers]:
>> Exitification transformation [TestHelpers]: alloc=29808 time=0.013
>> *** Float out(FOS {Lam = Just 0,
>>                    Consts = True,
>>                    OverSatApps = True}) [TestHelpers]:
>> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True})
>> [TestHelpers]: alloc=5508568 time=4.009
>> *** Common sub-expression [TestHelpers]:
>> Common sub-expression [TestHelpers]: alloc=27896 time=0.013
>> *** Float inwards [TestHelpers]:
>> Float inwards [TestHelpers]: alloc=26272 time=0.021
>> *** Simplifier [TestHelpers]:
>> Simplifier [TestHelpers]: alloc=24835440 time=15.291
>> *** Demand analysis [TestHelpers]:
>> Demand analysis [TestHelpers]: alloc=2214560 time=1.044
>> *** CoreTidy [TestHelpers]:
>> CoreTidy [TestHelpers]: alloc=2814672 time=1.457
>> *** CorePrep [TestHelpers]:
>> CorePrep [TestHelpers]: alloc=1965920 time=2.636
>> *** CoreToStg [TestHelpers]:
>> CoreToStg [TestHelpers]: alloc=3134560 time=1.484
>> *** CodeGen [TestHelpers]:
>> CodeGen [TestHelpers]: alloc=80232584 time=46.410
>> *** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]:
>> WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/TestHelpers.hi]:
>> alloc=1780688 time=0.766
>> *** systool:as:
>> systool:as: alloc=137200 time=0.360
>> [2 of 2] Compiling Main             ( tests/RDFProofTest.hs,
>> /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o
>> )
>> *** Parser [Main]:
>> Parser [Main]: alloc=25235720 time=8.851
>> *** Renamer/typechecker [Main]:
>> Renamer/typechecker [Main]: alloc=58415520 time=45.291
>> *** Desugar [Main]:
>> Desugar [Main]: alloc=22098688 time=46.709
>> *** Simplifier [Main]:
>> Simplifier [Main]: alloc=654052760 time=511.390
>> *** Specialise [Main]:
>> Specialise [Main]: alloc=44439912 time=34.132
>> *** Float out(FOS {Lam = Just 0,
>>                    Consts = True,
>>                    OverSatApps = False}) [Main]:
>> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False})
>> [Main]: alloc=208317448 time=252.154
>> *** Simplifier [Main]:
>> Simplifier [Main]: alloc=601002912 time=546.343
>> *** Simplifier [Main]:
>> Simplifier [Main]: alloc=564371608 time=546.970
>> *** Simplifier [Main]:
>> Simplifier [Main]: alloc=726902400 time=613.423
>> *** Float inwards [Main]:
>> Float inwards [Main]: alloc=23720 time=0.024
>> *** Called arity analysis [Main]:
>> Called arity analysis [Main]: alloc=25856 time=0.013
>> *** Simplifier [Main]:
>>
>> At this point my laptop just sits there making whooshing noises as if
>> it's trying to become an aeroplane, but it never gets to where it's
>> going (to mix up my metaphors).
>>
>> Any help would be appreciated,
>> Doug
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.

From ivanperezdominguez at gmail.com  Thu Sep  8 00:59:39 2022
From: ivanperezdominguez at gmail.com (Ivan Perez)
Date: Wed, 7 Sep 2022 17:59:39 -0700
Subject: [Haskell-cafe] [ANN] Copilot 3.11 -- hard realtime C runtime
	verification
Message-ID: <CACZKWEJSkO-d4sr5Mh61kTZ9wBF9fy=Oa7tmNWxjxqP3MK6tgw@mail.gmail.com>

Dear all,

We are very happy to announce the release of Copilot 3.11. Copilot is a
runtime verification system implemented as a Haskell DSL that generates
hard-realtime C99. Among others, Copilot is being used by the Safety
Critical Avionics Systems Branch of NASA Langley Research Center for
monitoring test flights of drones. You can learn more about it at [1].

Copilot 3.11 introduces a new library, copilot-interpreter, that
isolates all functions related to simulation of Copilot specifications.
The release also contains a number of bug fixes, provides a simplified
API, deprecates outdated elements, removes unused code, and introduces
support for GHC 9.2. A full list of changes merged is available at [2].

A substantial effort is being made to achieve NASA's Class D software
classification, most notably in terms of development process (which you
can partly witness in how issues and PRs are being handled on our github
repo), test coverage (mostly with quickcheck), and proofs of correctness
of the generated code (with what4).

Copilot is being used by the Safety-Critical Avionics Systems Branch
(D320) of NASA Langley Research Center to conduct experiments related to
flight safety of aerial vehicles. We have also built Ogma [3], a tool
that allows us to generate full monitoring applications (e.g., NASA's
Core Flight System [4] and Robot Operating System [5] applications) from
requirements in structured natural language.

We invite you all to explore Copilot, to try it, and to extend it. If
you like it, please help us draw attention to this work with a star on
github or a mention online.

Happy Haskelling,
The Copilot Team

[1] https://github.com/Copilot-Language/copilot
[2] https://github.com/Copilot-Language/copilot/milestone/15?closed=1
[3] https://github.com/nasa/ogma
[4] https://cfs.gsfc.nasa.gov/
[5] https://www.ros.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220907/8e734a52/attachment.html>

From will.yager at gmail.com  Fri Sep  9 19:07:13 2022
From: will.yager at gmail.com (William Yager)
Date: Fri, 9 Sep 2022 15:07:13 -0400
Subject: [Haskell-cafe] Generic "annotations" on type definitions
Message-ID: <CAG8oi1Myx+AoBwpJGi--RQpQj7gd4qREoQN2uQqYtcY9f-WegQ@mail.gmail.com>

Hello all,

I was recently thinking about a generic programming application
(auto-generating UI code from data definitions) that would benefit from the
ability to "annotate" data definitions. For example, let's say you have a
type

data Foo = Foo {barred :: Boolean}

You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps
the generic UI code defaults to making a check-box for Boolean values, but
you would rather have it be a radio button. It would be advantageous to be
able to write something like e.g.

data Foo = Foo {barred :: Boolean # RenderMode RadioButton}

In many languages, you have the ability to annotate data fields in a way
which has no bearing whatsoever on the first-order behavior or
representation of the type, and is only reflected via the language's
generic programming API. For example, in Java, you have

class Foo {
@RenderMode(RadioButton)
bool barred;
}

And in Rust, you have
struct Foo {
#[render_mode(radio_button)]
barred : bool
}

In Haskell, I do not believe we have any such system in place for
interfacing with Generics.

The closest I am familiar with is from the optparse-generic package, where
you write code of the form

data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton}

See
https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Generic.html#t::
::

This is basically a clever way to sort of re-create what we have available
in Rust or Java, using type families, but with the annoying downside that
it makes interacting with your type in normal code much more cumbersome,
and is also relatively confusing to read and write.

Compare Rust's Clap package, which is very similar to optparse-generic, but
more convenient to work with because the annotations don't impact normal
usage of the type.

See https://docs.rs/clap/latest/clap/#example

Would it be technically feasible to add such a thing to GHC's Generics
support? I could imagine something like updating the GHC.Generics Meta
type's MetaCons constructor to

MetaCons Symbol FixityI Bool *[Annotation]*

Best,
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220909/cd12ef34/attachment.html>

From lysxia at gmail.com  Fri Sep  9 21:48:25 2022
From: lysxia at gmail.com (Li-yao Xia)
Date: Fri, 9 Sep 2022 22:48:25 +0100
Subject: [Haskell-cafe] Generic "annotations" on type definitions
In-Reply-To: <CAG8oi1Myx+AoBwpJGi--RQpQj7gd4qREoQN2uQqYtcY9f-WegQ@mail.gmail.com>
References: <CAG8oi1Myx+AoBwpJGi--RQpQj7gd4qREoQN2uQqYtcY9f-WegQ@mail.gmail.com>
Message-ID: <157f5cbf-02a3-cacd-6e1f-bf7222bdd7a0@gmail.com>

An alternative to having metadata on the type is to have the generic UI 
code take the metadata as an extra parameter.

For example in generic-random, users can provide a list of "custom 
generators" to tweak how certain fields are generated.

- See tutorial, section "Custom generators for some fields" 
https://hackage.haskell.org/package/generic-random-1.5.0.1/docs/Generic-Random-Tutorial.html

 > data Foo = Foo {barred :: Boolean # RenderMode RadioButton}

This is actually legal: type a # b = a

and this is preserved in the metadata from Template Haskell queries. 
Hence, it's possible to have a TH command to derive a `Generic` instance 
with that metadata. You don't even need to change the `Metadata` field. 
If you're willing to be hacky, you can also insert an extra `M1` 
constructor to carry ad-hoc metadata.

Li-yao

(William: you may get this twice because I forgot to reply to the 
mailing list the first time.)

On 2022-09-09 8:07 PM, William Yager wrote:
> Hello all,
>
> I was recently thinking about a generic programming application 
> (auto-generating UI code from data definitions) that would benefit 
> from the ability to "annotate" data definitions. For example, let's 
> say you have a type
>
> data Foo = Foo {barred :: Boolean}
>
> You are (auto-)generating a UI to display and manipulate `Foo`s. 
> Perhaps the generic UI code defaults to making a check-box for Boolean 
> values, but you would rather have it be a radio button. It would be 
> advantageous to be able to write something like e.g.
>
> data Foo = Foo {barred :: Boolean # RenderMode RadioButton}
>
> In many languages, you have the ability to annotate data fields in a 
> way which has no bearing whatsoever on the first-order behavior or 
> representation of the type, and is only reflected via the language's 
> generic programming API. For example, in Java, you have
>
> class Foo {
> @RenderMode(RadioButton)
> bool barred;
> }
>
> And in Rust, you have
> struct Foo {
> #[render_mode(radio_button)]
> barred : bool
> }
>
> In Haskell, I do not believe we have any such system in place for 
> interfacing with Generics.
>
> The closest I am familiar with is from the optparse-generic package, 
> where you write code of the form
>
> data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton}
>
> See 
> https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Generic.html#t::::
>
> This is basically a clever way to sort of re-create what we have 
> available in Rust or Java, using type families, but with the annoying 
> downside that it makes interacting with your type in normal code much 
> more cumbersome, and is also relatively confusing to read and write.
>
> Compare Rust's Clap package, which is very similar to 
> optparse-generic, but more convenient to work with because the 
> annotations don't impact normal usage of the type.
>
> See https://docs.rs/clap/latest/clap/#example
>
> Would it be technically feasible to add such a thing to GHC's Generics 
> support? I could imagine something like updating the GHC.Generics Meta 
> type's MetaCons constructor to
>
> MetaCons Symbol FixityI Bool *[Annotation]*
>
> Best,
> Will
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220909/13a8739f/attachment.html>

From will.yager at gmail.com  Fri Sep  9 22:03:26 2022
From: will.yager at gmail.com (Will Yager)
Date: Fri, 9 Sep 2022 18:03:26 -0400
Subject: [Haskell-cafe] Generic "annotations" on type definitions
In-Reply-To: <157f5cbf-02a3-cacd-6e1f-bf7222bdd7a0@gmail.com>
References: <157f5cbf-02a3-cacd-6e1f-bf7222bdd7a0@gmail.com>
Message-ID: <A11B549A-C432-4155-8D2A-80B55DEA50E5@gmail.com>

The generic-random approach is interesting. I will ruminate on that. I could also see allowing the user to pass in a special "annotator" type which is structurally similar to the type being processed (e.g. it has constructor and field names like the original object but with "_" at the end) but instead of containing any data, it just contains annotations and is "generically zipped" with the generic representation of the first object. 

I would prefer not to use TH if possible. The fact that Haskell's generic programming is generally sufficiently powerful to avoid using TH is really nice, in my opinion. It's much better than Rust in this regard. 

> On Sep 9, 2022, at 17:49, Li-yao Xia <lysxia at gmail.com> wrote:
> 
> 
> An alternative to having metadata on the type is to have the generic UI code take the metadata as an extra parameter.
> 
> For example in generic-random, users can provide a list of "custom generators" to tweak how certain fields are generated.
> 
> - See tutorial, section "Custom generators for some fields" https://hackage.haskell.org/package/generic-random-1.5.0.1/docs/Generic-Random-Tutorial.html
> 
> > data Foo = Foo {barred :: Boolean # RenderMode RadioButton}
> 
> This is actually legal: type a # b = a
> 
> and this is preserved in the metadata from Template Haskell queries. Hence, it's possible to have a TH command to derive a `Generic` instance with that metadata. You don't even need to change the `Metadata` field. If you're willing to be hacky, you can also insert an extra `M1` constructor to carry ad-hoc metadata.
> 
> Li-yao
> 
> (William: you may get this twice because I forgot to reply to the mailing list the first time.)
> 
> On 2022-09-09 8:07 PM, William Yager wrote:
>> Hello all,
>> 
>> I was recently thinking about a generic programming application (auto-generating UI code from data definitions) that would benefit from the ability to "annotate" data definitions. For example, let's say you have a type
>> 
>> data Foo = Foo {barred :: Boolean} 
>> 
>> You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps the generic UI code defaults to making a check-box for Boolean values, but you would rather have it be a radio button. It would be advantageous to be able to write something like e.g.
>> 
>> data Foo = Foo {barred :: Boolean # RenderMode RadioButton} 
>> 
>> In many languages, you have the ability to annotate data fields in a way which has no bearing whatsoever on the first-order behavior or representation of the type, and is only reflected via the language's generic programming API. For example, in Java, you have
>> 
>> class Foo {
>> @RenderMode(RadioButton)
>> bool barred;
>> }
>> 
>> And in Rust, you have
>> struct Foo {
>> #[render_mode(radio_button)]
>> barred : bool
>> }
>> 
>> In Haskell, I do not believe we have any such system in place for interfacing with Generics.
>> 
>> The closest I am familiar with is from the optparse-generic package, where you write code of the form
>> 
>> data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton}
>> 
>> See https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Generic.html#t::::
>> 
>> This is basically a clever way to sort of re-create what we have available in Rust or Java, using type families, but with the annoying downside that it makes interacting with your type in normal code much more cumbersome, and is also relatively confusing to read and write. 
>> 
>> Compare Rust's Clap package, which is very similar to optparse-generic, but more convenient to work with because the annotations don't impact normal usage of the type.
>> 
>> See https://docs.rs/clap/latest/clap/#example
>> 
>> Would it be technically feasible to add such a thing to GHC's Generics support? I could imagine something like updating the GHC.Generics Meta type's MetaCons constructor to 
>> 
>> MetaCons Symbol FixityI Bool [Annotation]
>> 
>> Best,
>> Will
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220909/72376440/attachment.html>

From olf at aatal-apotheke.de  Sat Sep 10 17:26:34 2022
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 10 Sep 2022 19:26:34 +0200
Subject: [Haskell-cafe] Generic "annotations" on type definitions
Message-ID: <908ce00f67b4f14b0d72589f8610f42e85810a6d.camel@aatal-apotheke.de>

> Hello all,
> 
> I was recently thinking about a generic programming application
> (auto-generating UI code from data definitions) that would benefit from the
> ability to "annotate" data definitions. For example, let's say you have a
> type
> 
> data Foo = Foo {barred :: Boolean}
> 
> You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps
> the generic UI code defaults to making a check-box for Boolean values, but
> you would rather have it be a radio button. It would be advantageous to be
> able to write something like e.g.
> 
> data Foo = Foo {barred :: Boolean # RenderMode RadioButton}
> 
> In many languages, you have the ability to annotate data fields in a way
> which has no bearing whatsoever on the first-order behavior or
> representation of the type, and is only reflected via the language's
> generic programming API. For example, in Java, you have
> 
> class Foo {
> @RenderMode(RadioButton)
> bool barred;
> }
> 
> And in Rust, you have
> struct Foo {
> #[render_mode(radio_button)]
> barred : bool
> }
> 
> In Haskell, I do not believe we have any such system in place for
> interfacing with Generics.
> 
> The closest I am familiar with is from the optparse-generic package, where
> you write code of the form
> 
> data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton}
> 
> See
> https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Generic.html#t::
> ::
> 
> This is basically a clever way to sort of re-create what we have available
> in Rust or Java, using type families, but with the annoying downside that
> it makes interacting with your type in normal code much more cumbersome,
> and is also relatively confusing to read and write.
> 
> Compare Rust's Clap package, which is very similar to optparse-generic, but
> more convenient to work with because the annotations don't impact normal
> usage of the type.
> 
> See https://docs.rs/clap/latest/clap/#example
> 
> Would it be technically feasible to add such a thing to GHC's Generics
> support? I could imagine something like updating the GHC.Generics Meta
> type's MetaCons constructor to
> 
> MetaCons Symbol FixityI Bool *[Annotation]*
> 
> Best,
> Will


Why not use special syntax in comments, like we do for Haddock,
doctests etc. 

data Foo = Foo {
	barred :: Boolean -- ^ #GUI[RenderMode RadioButton]
	}

There is a functional language capable of auto-generating input forms: 
Clean https://clean.cs.ru.nl/Clean with the iTask library on top. It
can also generate forms for recursive types. The Dutch coast guard uses
it to interactively design queries to a database of marine vessel
movements. 
It'd be cool if Haskell's Generics also could do that. 

Olaf


From will.yager at gmail.com  Sat Sep 10 19:20:02 2022
From: will.yager at gmail.com (Will Yager)
Date: Sat, 10 Sep 2022 15:20:02 -0400
Subject: [Haskell-cafe] Generic "annotations" on type definitions
In-Reply-To: <908ce00f67b4f14b0d72589f8610f42e85810a6d.camel@aatal-apotheke.de>
References: <908ce00f67b4f14b0d72589f8610f42e85810a6d.camel@aatal-apotheke.de>
Message-ID: <E6CE1DFA-4186-477B-A254-A8FAD338977D@gmail.com>

Doesn't this require TH? A primary constraint here is using generics only, since TH has many undesirable properties. 

In the original question, I gave an unfair advantage to Rust, because it uses macros, which are similar to TH. Java's system is perhaps a fairer comparison, although it works mostly via runtime inspection. 

The idea is to provide information about a type to Generic, without changing the way that type behaves for programmers. 

Will

> On Sep 10, 2022, at 13:26, Olaf Klinke <olf at aatal-apotheke.de> wrote:
> 
> 
>> 
>> Hello all,
>> 
>> I was recently thinking about a generic programming application
>> (auto-generating UI code from data definitions) that would benefit from the
>> ability to "annotate" data definitions. For example, let's say you have a
>> type
>> 
>> data Foo = Foo {barred :: Boolean}
>> 
>> You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps
>> the generic UI code defaults to making a check-box for Boolean values, but
>> you would rather have it be a radio button. It would be advantageous to be
>> able to write something like e.g.
>> 
>> data Foo = Foo {barred :: Boolean # RenderMode RadioButton}
>> 
>> In many languages, you have the ability to annotate data fields in a way
>> which has no bearing whatsoever on the first-order behavior or
>> representation of the type, and is only reflected via the language's
>> generic programming API. For example, in Java, you have
>> 
>> class Foo {
>> @RenderMode(RadioButton)
>> bool barred;
>> }
>> 
>> And in Rust, you have
>> struct Foo {
>> #[render_mode(radio_button)]
>> barred : bool
>> }
>> 
>> In Haskell, I do not believe we have any such system in place for
>> interfacing with Generics.
>> 
>> The closest I am familiar with is from the optparse-generic package, where
>> you write code of the form
>> 
>> data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton}
>> 
>> See
>> https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Generic.html#t::
>> ::
>> 
>> This is basically a clever way to sort of re-create what we have available
>> in Rust or Java, using type families, but with the annoying downside that
>> it makes interacting with your type in normal code much more cumbersome,
>> and is also relatively confusing to read and write.
>> 
>> Compare Rust's Clap package, which is very similar to optparse-generic, but
>> more convenient to work with because the annotations don't impact normal
>> usage of the type.
>> 
>> See https://docs.rs/clap/latest/clap/#example
>> 
>> Would it be technically feasible to add such a thing to GHC's Generics
>> support? I could imagine something like updating the GHC.Generics Meta
>> type's MetaCons constructor to
>> 
>> MetaCons Symbol FixityI Bool *[Annotation]*
>> 
>> Best,
>> Will
> 
> 
> Why not use special syntax in comments, like we do for Haddock,
> doctests etc. 
> 
> data Foo = Foo {
>    barred :: Boolean -- ^ #GUI[RenderMode RadioButton]
>    }
> 
> There is a functional language capable of auto-generating input forms: 
> Clean https://clean.cs.ru.nl/Clean with the iTask library on top. It
> can also generate forms for recursive types. The Dutch coast guard uses
> it to interactively design queries to a database of marine vessel
> movements. 
> It'd be cool if Haskell's Generics also could do that. 
> 
> Olaf
> 

From olf at aatal-apotheke.de  Sat Sep 10 20:37:43 2022
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Sat, 10 Sep 2022 22:37:43 +0200
Subject: [Haskell-cafe] Generic "annotations" on type definitions
In-Reply-To: <E6CE1DFA-4186-477B-A254-A8FAD338977D@gmail.com>
References: <908ce00f67b4f14b0d72589f8610f42e85810a6d.camel@aatal-apotheke.de>
 <E6CE1DFA-4186-477B-A254-A8FAD338977D@gmail.com>
Message-ID: <8a3019da777c5d4a842b7562f8baee3f6234fb64.camel@aatal-apotheke.de>

On Sat, 2022-09-10 at 15:20 -0400, Will Yager wrote:
> Doesn't this require TH? A primary constraint here is using generics only, since TH has many undesirable properties. 
> 
> In the original question, I gave an unfair advantage to Rust, because it uses macros, which are similar to TH. Java's system is perhaps a fairer comparison, although it works mostly via runtime inspection. 
> 
> The idea is to provide information about a type to Generic, without changing the way that type behaves for programmers. 
> 
> Will

Since your question is about choices of display/input, how about
delaying the choice to the call site? To use your example, the UI
generator knows that a Bool can be used with either check box or radio
button, and the programmer must provide the choice via a settings
record at every instance. This would potentially reduce clutter, as for
many types there might only be one sensible UI choice available, hence
a Data.Default.def suffices. The (admittedly hard) problem then is that
the shape of the settings record must match the shape of the displayed
type. In Haskell pseudocode:

instance UI Bool where
   type UISettings Bool = RadioButton | CheckBox
   defaultUISettings = CheckBox
instance (UI a, UI b) => UI (a :+: b) where
   type UISettings (a :+: b) = (UISettings a :*: UISettings b)
   -- must provide settings for both options

inputForm :: UI a => UISettings a -> Form a

I have personal interest in getting to work what you propose, so let's
collaborate. Maybe Yesod's Form Monad is a good starting point for a
proof-of-concept? 

Olaf

> 
> > On Sep 10, 2022, at 13:26, Olaf Klinke <olf at aatal-apotheke.de> wrote:
> > 
> > 
> > > Hello all,
> > > 
> > > I was recently thinking about a generic programming application
> > > (auto-generating UI code from data definitions) that would benefit from the
> > > ability to "annotate" data definitions. For example, let's say you have a
> > > type
> > > 
> > > data Foo = Foo {barred :: Boolean}
> > > 
> > > You are (auto-)generating a UI to display and manipulate `Foo`s. Perhaps
> > > the generic UI code defaults to making a check-box for Boolean values, but
> > > you would rather have it be a radio button. It would be advantageous to be
> > > able to write something like e.g.
> > > 
> > > data Foo = Foo {barred :: Boolean # RenderMode RadioButton}
> > > 
> > > In many languages, you have the ability to annotate data fields in a way
> > > which has no bearing whatsoever on the first-order behavior or
> > > representation of the type, and is only reflected via the language's
> > > generic programming API. For example, in Java, you have
> > > 
> > > class Foo {
> > > @RenderMode(RadioButton)
> > > bool barred;
> > > }
> > > 
> > > And in Rust, you have
> > > struct Foo {
> > > #[render_mode(radio_button)]
> > > barred : bool
> > > }
> > > 
> > > In Haskell, I do not believe we have any such system in place for
> > > interfacing with Generics.
> > > 
> > > The closest I am familiar with is from the optparse-generic package, where
> > > you write code of the form
> > > 
> > > data Foo w = Foo {barred :: w ::: Boolean <?> RenderMode RadioButton}
> > > 
> > > See
> > > https://hackage.haskell.org/package/optparse-generic-1.4.8/docs/Options-Generic.html#t::
> > > ::
> > > 
> > > This is basically a clever way to sort of re-create what we have available
> > > in Rust or Java, using type families, but with the annoying downside that
> > > it makes interacting with your type in normal code much more cumbersome,
> > > and is also relatively confusing to read and write.
> > > 
> > > Compare Rust's Clap package, which is very similar to optparse-generic, but
> > > more convenient to work with because the annotations don't impact normal
> > > usage of the type.
> > > 
> > > See https://docs.rs/clap/latest/clap/#example
> > > 
> > > Would it be technically feasible to add such a thing to GHC's Generics
> > > support? I could imagine something like updating the GHC.Generics Meta
> > > type's MetaCons constructor to
> > > 
> > > MetaCons Symbol FixityI Bool *[Annotation]*
> > > 
> > > Best,
> > > Will
> > 
> > Why not use special syntax in comments, like we do for Haddock,
> > doctests etc. 
> > 
> > data Foo = Foo {
> >    barred :: Boolean -- ^ #GUI[RenderMode RadioButton]
> >    }
> > 
> > There is a functional language capable of auto-generating input forms: 
> > Clean https://clean.cs.ru.nl/Clean with the iTask library on top. It
> > can also generate forms for recursive types. The Dutch coast guard uses
> > it to interactively design queries to a database of marine vessel
> > movements. 
> > It'd be cool if Haskell's Generics also could do that. 
> > 
> > Olaf
> > 



From lysxia at gmail.com  Sun Sep 11 09:19:23 2022
From: lysxia at gmail.com (Li-yao Xia)
Date: Sun, 11 Sep 2022 10:19:23 +0100
Subject: [Haskell-cafe] Generic "annotations" on type definitions
In-Reply-To: <E6CE1DFA-4186-477B-A254-A8FAD338977D@gmail.com>
References: <908ce00f67b4f14b0d72589f8610f42e85810a6d.camel@aatal-apotheke.de>
 <E6CE1DFA-4186-477B-A254-A8FAD338977D@gmail.com>
Message-ID: <56836e7a-586b-8623-b092-27be53c5d830@gmail.com>

 > Doesn't this require TH? A primary constraint here is using generics 
only, since TH has many undesirable properties.

What syntax the metadata comes in is orthogonal to whether it's provided 
and processed using TH. That goes back to this previous question of yours:

 > Would it be technically feasible to add such a thing to 
GHC's Generics support?

Yes, it is technically feasible to extend GHC generics to reflect as 
much metadata as you want. It's a matter of deciding what syntax it's 
going to come in (whether in types, comments, or whatever else), how 
it's going to be encoded (via an extra `Meta` field, constructor, or 
whatever), and correspondingly adapting the code that generates Generic 
instances.

However, changing GHC is something that takes a lot of effort. A 
short-term compromise is to reimplement the deriving of Generic 
instances in TH. TH would only be used for that, then the processing of 
that metadata by applications can be done purely in Haskell.

Li-yao

From david.feuer at gmail.com  Sun Sep 11 23:05:32 2022
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 11 Sep 2022 19:05:32 -0400
Subject: [Haskell-cafe] Can this be made to fuse?
Message-ID: <CAMgWh9vRJHW2VJMg2WnSw3UmXfzNwuMzm1taZXuoyb=EWD0vbw@mail.gmail.com>

The template-haskell package has functions `tupE` and `tupP` for
building tuple expressions and patterns, respectively, but nothing
really similar for building tuple types. I came up with the version
below the other day:

-- | Given a list of types, produce the type of a tuple of
-- those types. This is analogous to 'tupE' and 'tupP'.
--
-- @
-- tupT [[t|Int|], [t|Char|], [t|Bool]] = [t| (Int, Char, Bool) |]
-- @
tupT :: [Q Type] -> Q Type
tupT ts = n `seq` res
  where
    -- We build the expression with a thunk inside that will be filled in with
    -- the length of the list once that's been determined. This works
    -- efficiently (in one pass) because TH.Type is rather lazy.
    (res, n) = foldl' (\(acc, !k) ty -> ([t| $acc $ty |], k + 1))
                      (tupleT n, 0)
                      ts

I strongly suspect this is quite fast enough in practice, but it's a
bit annoying that it won't participate in list fusion; tupT (map f xs)
will (lazily) generate an intermediate list. I wasn't able to convince
GHC to fuse it, short of a custom rewrite rule or two (tupT (build f)
= ..., tupT (augment f r = ...). Does anyone know if it's possible?

From goemansrowan at gmail.com  Mon Sep 12 08:33:07 2022
From: goemansrowan at gmail.com (rowan goemans)
Date: Mon, 12 Sep 2022 10:33:07 +0200
Subject: [Haskell-cafe] Combine pattern synonyms and record wild cards
Message-ID: <4fb101ed-309c-e6b8-d104-940516492273@gmail.com>

Hello all,

I'm playing with pattern synonyms to create a more intuitive API. 
Essentially what I would like is to allow a record wild card through a 
pattern synonym. Allow me to illustrate with an example.

I have a data type. `data Foo a = Foo { unFoo :: a }` and a type 
`FooMaybe a = Maybe (Foo a)`. Now I have a pattern synonym `pattern 
FooJust x = Just (Foo x)`. This works and I can match on it no problem. 
But by doing this I lose the ability to use RecordWildCards. I can do 
this `myFun (Just Foo{..}) but not this `myFun FooJust{..}`. Is there 
some way to use pattern synonym while preserving the ability of using 
record wild cards?

Best regards,

Rowan Goemans


From andreeac at comp.nus.edu.sg  Mon Sep 12 13:42:28 2022
From: andreeac at comp.nus.edu.sg (Andreea Costea)
Date: Mon, 12 Sep 2022 21:42:28 +0800
Subject: [Haskell-cafe] OOPSLA 2023: Round 1 Call for Papers
Message-ID: <c62faa1d4e44d3acbff798a41746627e@comp.nus.edu.sg>

========================================================================
                       PACMPL Issue OOPSLA 2023

                          Call for Papers

                OOPSLA 2023 will be held as part of
The ACM Conference on Systems, Programming, Languages, and Applications:
                  Software for Humanity (SPLASH'23)

              October 23-27, 2023, Lisbon, Portugal

           https://2023.splashcon.org/track/splash-2023-oopsla
========================================================================

### Important dates

ROUND 1:
Submission Deadline:      Fri Oct 28, 2022
Author Response:          Wed Dec 07 - Fri Dec 9
Author Notification:      Thu Dec 22
Submission of Revisions:  Mon Feb 13 - Fri Feb 24

ROUND 2:
Submission Deadline:      Fri Apr 14, 2023
Author Response:          Wed Jun 14 - Fri Jun 16
Author Notification:      Fri Jun 30
Submission of Revisions:  Mon Aug 14 - Fri Aug 18

Camera ready:             Thu Aug 31

Papers accepted at either of the rounds will be published in the 2023 
volume of PACMPL(OOPSLA) and invited to be presented at the SPLASH 
conference in October 2023.

### Scope

The OOPSLA issue of the Proceedings of the ACM on Programming Languages 
(PACMPL) welcomes papers focusing on all practical and theoretical 
investigations of programming languages, systems and environments. 
Papers may target any stage of software development, including 
requirements, modeling, prototyping, design, implementation, generation, 
analysis, verification, testing, evaluation, maintenance, and reuse of 
software systems. Contributions may include the development of new 
tools, techniques, principles, and evaluations.

### Review Process

PACMPL(OOPSLA) has two _rounds_ of reviewing. The final outcome of each 
round can be one of Accept, Revise or Reject.

*Accept*: Accepted papers will appear at the next PACMPL(OOPSLA).

*Revise*: Papers in this category are invited to submit a revision to 
the _next round_ of submissions with a specific set of expectations to 
be met.  When authors resubmit, they should clearly explain how the 
revisions address the comments of the reviewers. The revised paper will 
be re-evaluated, and either accepted or rejected.  Resubmitted papers 
will retain the same reviewers throughout the process.

*Reject*: Rejected papers will not be included in the 2023 volume of 
PACMPL(OOPSLA). Papers in this category are not guaranteed a review if 
resubmitted less than one year from the date of original submission. A 
paper will be judged to be a resubmission if it is substantially similar 
to the original submission. The judgment that a paper is a resubmission 
of the same work and whether, in this case, it will be reviewed or not 
is at the discretion of the Chair. Obviously, this same policy applies 
to papers that were rejected for inclusion in the 2022 volume of 
PACMPL(OOPSLA).

Each _round_ of reviewing consists of two _phases_. The first phase 
evaluates the papers and results in an early notification of Reject, 
Revise, or Conditional Accept. During the first phase, authors will be 
able to read their reviews and respond to them. The second phase is 
restricted to conditionally accepted papers. Authors must make a set of 
mandatory revisions. The second phase assesses whether the required 
revisions have been addressed. The outcome can be Accept, Revise or 
Reject.

### Submissions

Submitted papers must be at most **23 pages** in 10 point font. There is 
no page limit on references. No appendices are allowed on the main 
paper, instead authors can upload supplementary material with no page or 
content restrictions, but reviewers may choose to ignore it. Submissions 
must adhere to the "ACM Small" template available from [the 
ACM](http://www.acm.org/publications/authors/submissions). Papers are 
expected to use author-year citations. Author-year citations may be used 
as either a noun phrase, such as "The lambda calculus was originally 
conceived by Church (1932)", or a parenthetic phase, such as "The lambda 
calculus (Church 1932) was intended as a foundation for mathematics".

PACMPL uses double-blind reviewing. Authors' identities are only 
revealed if a paper is accepted. Papers must

1. omit author names and institutions,
2. use the third person when referencing your work,
3. anonymise supplementary material.

Nothing should be done in the name of anonymity that weakens the 
submission; see the DBR FAQ. When in doubt, contact the Review Committee 
Chairs.

Papers must describe unpublished work that is not currently submitted 
for publication elsewhere as described by [SIGPLAN's Republication 
Policy](http://www.sigplan.org/Resources/Policies/Republication). 
Submitters should also be aware of [ACM's Policy and Procedures on 
Plagiarism](http://www.acm.org/publications/policies/plagiarism_policy). 
Submissions are expected to comply with the [ACM Policies for 
Authorship](https://www.acm.org/publications/authors/information-for-authors).

### Artifacts

Authors should indicate with their initial submission if an artifact 
exists, describe its nature and limitations, and indicate if it will be 
submitted for evaluation. Accepted papers that fail to provide an 
artifact will be requested to explain the reason they cannot support 
replication. It is understood that some papers have no artifacts.

### Publication

PACMPL is a Gold Open Access journal, all papers will be freely 
available to the public. Authors can voluntarily cover the article 
processing charge ($400), but payment is not required. The official 
publication date is the date the journal are made available in the ACM 
Digital Library. The journal issue and associated papers may be 
published up to two weeks prior to the first day of the conference.

### Additional Information

Consult FAQ in Call for Papers at:  
https://2023.splashcon.org/track/splash-2023-oopsla

### Review Committee

PC Chair:    Mira Mezini  (TU Darmstadt)

Derek Dreyer (MPI-SWS, DE)- Associate Chair
Sophia Drosopolou (Facebook; Imperial College, UK)- Associate Chair
Patrick Eugster (USI, Switzerland; Purdue U.)- Associate Chair
Shriram Krishnamurthi (Brown University, USA)- Associate Chair
Jonathan Aldrich (CMU, USA)
Karim Ali (U. Alberta, Canada)
Peter Alvaro (UC Santa Cruz, USA)
Stefanie Balzer (CMU, USA)
Osbert Bastani (U. Penn, USA)
Annette Bieniusa (U. Kaiserslautern, Germany)
Sebastian Burkhardt (MSR, Switzerland)
Satish Chandra (Facebook, USA)
James Cheney (University of Edinburgh; Alan Turing Institute, UK)
Albert Cohen (Google, France)
Wolfgang De Meuter (VUB, BE)
Dominique Devriese (KU Leuven, Belgium)
Dana Drachsler Cohen (Technion, Israel)
Jana Dunfield (Queen’s University in Kingston, Ontario, CA)
Sebastian Erdweg (U. Mainz, Germany)
Matthew Flatt (U. Utah, USA)
Jeremy Gibbons (U. Oxford, UK)
Anitha Gollamudi (UMass, USA)
Elisa Gonzalez Boix (VUB, Belgien)
Andrew Gordon (MS Research, Edinburgh, UK)
Dan Grossman (U. Washington, USA)
Arjun Guha (Northeastern U., USA)
Philipp Haller (KTH, Sweden)
Görel Hedin (Lund University, Sweden)
Steven Holtzen (Northeastern U., USA)
Justin Hsu (Cornell University, USA)
Atsushi Igarashi (Kyoto U., Japan)
Ranjit Jhala (UC San Diego, USA)
Gowtham Kaki (U. Colorado, USA)
Neel Krishnaswami (Cambridge, UK)
Burcu Kulahcioglu Ozkan (Delft University of Technology, The 
Netherlands)
Sorin Lerner (UCSD, USA)
Hongjin Liang (Nanjing University, CN)
Crista Lopes (UC Irvine, USA)
Kenji Maillard (Inria Nantes & University of Chile)
Hidehiko Masuhara (Tokyo Institute of Technology, Japan)
Ana Milanova (Rensselaer Polytechnic Institute)
Heather Miller (CMU, USA)
Ragnar Mogk (TU Darmstadt, DE)
Anders Møller (Aarhus U,, Danemark)
Fabrizio Montesi (Univ. of Southern Denmark, Denmark)
Sarah Nadi (U. Alberta, Canada)
James Noble (U. Wellington, New Zealand)
Bruno C. d. S.  Oliveira (U. Hong Kong, Hong Kong)
Klaus Ostermann (U. Tübingen, Germany)
Mangpo Phothilimthana (Google Brain, USA)
Benjamin Pierce (UPenn, USA)
Nadia Polikarpova (UC San Diego, USA)
Michael Pradel (U. Stuttgart, Germany)
Shaz Qadeer (Facebook, USA)
Marianna Rapoport (Amazon Web Services, Canada)
Cindy Rubio-González (UC Davis, USA)
Sukyoung Ryu (KAIST, Korea)
Guido Salvaneschi (U. St. Gallen, Switzerland)
Mark Santolucito (Columbia, USA)
Ilya Sergey (National University of Singapore, Singapore)
Armando Solar-Lezama (MIT, USA)
Manu Sridharan (University of California, USA)
Charles Sutton (Google, UK)
Joseph Tassarotti (New York University, USA)
Ross Tate (Cornell U., USA)
Peter Thiemann (U. Freiburg, Germany)
Bernardo Toninho (Universidade Nova de Lisboa, Portugal)
Viktor Vafeiadis (MPI, Germany)
Tijs van der Storm (CWI; University of Groningen, Netherlands)
Vasco Vasconcelos (U. Lisbon, Portugal)
Jan Vitek (Northeastern U./Czech Technical University)
Dimitrios Vytiniotis (DeepMind, UK)
David Walker (Princeton, USA)
Conrad Watt (U. Cambridge, UK)
Pascal Weisenburger (U. St. Gallen, Switzerland)
Qirun Zhang (Gatech, USA)


From coot at coot.me  Mon Sep 12 19:47:46 2022
From: coot at coot.me (coot at coot.me)
Date: Mon, 12 Sep 2022 19:47:46 +0000
Subject: [Haskell-cafe] Build haddock documentation of a cabal project
Message-ID: <u1I4zvkLcrFef6hjb2ZexpYCHBwnWD7PgPzFOLYavvJaFfAxsOKXxfwxD6L6Xy4QGcK-AGLHQZsLl6gzb3ak_vRL4C5migNngEeTXTYK8BQ=@coot.me>

Hello Haskell Cafe

Next release of `cabal` and `haddock` will gain the capability of building documentation of a cabal project.   A few weeks ago when the PR (https://github.com/haskell/cabal/pull/8162) was still in review I wrote a blog post about it: https://coot.me/posts/cabal-haddock-project.html

Cheers,
Marcin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220912/e8f24524/attachment.sig>

From hecate at glitchbra.in  Mon Sep 12 20:59:51 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Mon, 12 Sep 2022 22:59:51 +0200
Subject: [Haskell-cafe] Build haddock documentation of a cabal project
In-Reply-To: <u1I4zvkLcrFef6hjb2ZexpYCHBwnWD7PgPzFOLYavvJaFfAxsOKXxfwxD6L6Xy4QGcK-AGLHQZsLl6gzb3ak_vRL4C5migNngEeTXTYK8BQ=@coot.me>
References: <u1I4zvkLcrFef6hjb2ZexpYCHBwnWD7PgPzFOLYavvJaFfAxsOKXxfwxD6L6Xy4QGcK-AGLHQZsLl6gzb3ak_vRL4C5migNngEeTXTYK8BQ=@coot.me>
Message-ID: <3546eaf6-7fef-7440-c942-c40ff16e904f@glitchbra.in>

Część Marcin,
Thank you very much for this useful addition!! This will definitely help 
users of mono-repos.

Cheers,
Hécate

Le 12/09/2022 à 21:47, coot at coot.me a écrit :
> Hello Haskell Cafe
>
> Next release of `cabal` and `haddock` will gain the capability of building documentation of a cabal project.   A few weeks ago when the PR (https://github.com/haskell/cabal/pull/8162) was still in review I wrote a blog post about it:https://coot.me/posts/cabal-haddock-project.html
>
> Cheers,
> Marcin
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220912/6daf00a7/attachment.html>

From olf at aatal-apotheke.de  Wed Sep 14 07:45:41 2022
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Wed, 14 Sep 2022 09:45:41 +0200
Subject: [Haskell-cafe] What became of James Cook? (Need package update)
Message-ID: <b030bd17c8211ea23fdbf446782f10f27be738e6.camel@aatal-apotheke.de>

Dear Café, 

does anyone happen to know what became of James Cook? (The programmer
[1,2] a.k.a. mokus, not the explorer.) On github his last commit was in
May. I've been trying to contact him at mokus at deepbondi.net three timessince March, but no luck. 
I'm using his package [3] which does not have a public repo. It needs
minor adjustments to comply with the MonadFail change. Currently I have
no intentions to properly take over the package, since James does seem
to be an active developer generally, but James hasn't answered my
request to become a hackage co-maintainer of [3] either. Does anyone
know alternative channels to reach James? Or could such a minor
adjustment [4] be made by the hackage trustees? 

Thanks
Olaf

[1] https://hackage.haskell.org/user/JamesCook
[2] https://github.com/mokus0
[3] https://hackage.haskell.org/package/dbf
[4]
dbf-0.0.0.2 is broken by the removal of "fail" from the Monad class, as
src/Database/XBase/Dbf/Structures.hs uses fail in line 61
and binary does not implement MonadFail for its PutM Monad. 

A quick workaround is to replace the call to fail by error. (Which
should be semantically equivalent for the old Control.Monad.fail) 


From post at volker-wysk.de  Thu Sep 15 15:23:10 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 15 Sep 2022 17:23:10 +0200
Subject: [Haskell-cafe] Cabal problem, broken packages?
Message-ID: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>

Hi!

I've lately set up the Haskell environment on my Linux box, with no
problems. Then I have installed some packages with "cabal install", again
without problems. But now I'm trying to install another package and I get a
dependency conflict. It doesn't seem to matter which package I try to
install:


desktop ~ $ cabal install rfc5051
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] next goal: directory (user goal)
[__0] rejecting: directory-1.3.8.0 (constraint from user target requires
==1.3.7.1)
[__0] trying: directory-1.3.7.1
[__1] next goal: ghc (user goal)
[__1] rejecting: ghc-9.4.2, ghc-9.4.1, ghc-9.2.4, ghc-9.2.3, ghc-9.2.2,
ghc-9.2.1, ghc-9.0.2, ghc-8.10.7, ghc-8.10.2, ghc-8.10.1 (constraint from
user
target requires ==8.8.4)
[__1] rejecting: ghc-8.8.4/installed-8.8... (conflict: directory==1.3.7.1,
ghc
=> directory==1.3.6.0/installed-1.3...)
[__1] rejecting: ghc-8.8.3, ghc-8.8.1, ghc-8.6.5, ghc-8.6.4, ghc-8.6.1,
ghc-8.4.4, ghc-8.4.3, ghc-8.4.1, ghc-8.2.2, ghc-8.2.1, ghc-9.2.3.20220620
(constraint from user target requires ==8.8.4)
[__1] fail (backjumping, conflict set: directory, ghc)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: directory, ghc


This doesn't make much sense to me. How can I repair it? Are the packages
broken? Can a solution somehow be specified?

Cheers,
Volker

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Sep 15 15:31:41 2022
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 15 Sep 2022 16:31:41 +0100
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
Message-ID: <YyNFXRH0YrnCxFph@cloudinit-builder>

On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> I've lately set up the Haskell environment on my Linux box, with no
> problems. Then I have installed some packages with "cabal install", again
> without problems. But now I'm trying to install another package and I get a
> dependency conflict. It doesn't seem to matter which package I try to
> install:

This is quite weird, because neither directory nor ghc are
dependencies of rfc5051.

As a first step, can you try the following and report back whether you
successfully get to a GHCi a prompt?

$ cabal repl -z --build-depends rfc5051

> desktop ~ $ cabal install rfc5051
> Resolving dependencies...
> cabal: Could not resolve dependencies:
> [__0] next goal: directory (user goal)
> [__0] rejecting: directory-1.3.8.0 (constraint from user target requires
> ==1.3.7.1)
> [__0] trying: directory-1.3.7.1
> [__1] next goal: ghc (user goal)
> [__1] rejecting: ghc-9.4.2, ghc-9.4.1, ghc-9.2.4, ghc-9.2.3, ghc-9.2.2,
> ghc-9.2.1, ghc-9.0.2, ghc-8.10.7, ghc-8.10.2, ghc-8.10.1 (constraint from
> user
> target requires ==8.8.4)
> [__1] rejecting: ghc-8.8.4/installed-8.8... (conflict: directory==1.3.7.1,
> ghc
> => directory==1.3.6.0/installed-1.3...)
> [__1] rejecting: ghc-8.8.3, ghc-8.8.1, ghc-8.6.5, ghc-8.6.4, ghc-8.6.1,
> ghc-8.4.4, ghc-8.4.3, ghc-8.4.1, ghc-8.2.2, ghc-8.2.1, ghc-9.2.3.20220620
> (constraint from user target requires ==8.8.4)
> [__1] fail (backjumping, conflict set: directory, ghc)
> After searching the rest of the dependency tree exhaustively, these were the
> goals I've had most trouble fulfilling: directory, ghc

From mikolaj at well-typed.com  Thu Sep 15 15:47:12 2022
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Thu, 15 Sep 2022 17:47:12 +0200
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <YyNFXRH0YrnCxFph@cloudinit-builder>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
Message-ID: <CAHFo2up155vs_cSuUmAxz8ZMUJa=LZF6j_pxKPHR6+BB7WSQ_g@mail.gmail.com>

This may be caused by some cabal.project lying around
(e.g., in the directory you are in when you are installing, but also
in any parent directory) or by .ghc.environment.arch-os-version
files lying around

https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments

which is likely if you indeed installed whole packages, and not just
executables from the packages (`cabal install` only installs executables).
If the problem persists please file a ticket on cabal github bug tracker.

BTW, I haven't received your email, but only the response from Tom.
Nothing in the spam folder, either. Strange.



On Thu, Sep 15, 2022 at 5:32 PM Tom Ellis
<tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>
> On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> > I've lately set up the Haskell environment on my Linux box, with no
> > problems. Then I have installed some packages with "cabal install", again
> > without problems. But now I'm trying to install another package and I get a
> > dependency conflict. It doesn't seem to matter which package I try to
> > install:
>
> This is quite weird, because neither directory nor ghc are
> dependencies of rfc5051.
>
> As a first step, can you try the following and report back whether you
> successfully get to a GHCi a prompt?
>
> $ cabal repl -z --build-depends rfc5051
>
> > desktop ~ $ cabal install rfc5051
> > Resolving dependencies...
> > cabal: Could not resolve dependencies:
> > [__0] next goal: directory (user goal)
> > [__0] rejecting: directory-1.3.8.0 (constraint from user target requires
> > ==1.3.7.1)
> > [__0] trying: directory-1.3.7.1
> > [__1] next goal: ghc (user goal)
> > [__1] rejecting: ghc-9.4.2, ghc-9.4.1, ghc-9.2.4, ghc-9.2.3, ghc-9.2.2,
> > ghc-9.2.1, ghc-9.0.2, ghc-8.10.7, ghc-8.10.2, ghc-8.10.1 (constraint from
> > user
> > target requires ==8.8.4)
> > [__1] rejecting: ghc-8.8.4/installed-8.8... (conflict: directory==1.3.7.1,
> > ghc
> > => directory==1.3.6.0/installed-1.3...)
> > [__1] rejecting: ghc-8.8.3, ghc-8.8.1, ghc-8.6.5, ghc-8.6.4, ghc-8.6.1,
> > ghc-8.4.4, ghc-8.4.3, ghc-8.4.1, ghc-8.2.2, ghc-8.2.1, ghc-9.2.3.20220620
> > (constraint from user target requires ==8.8.4)
> > [__1] fail (backjumping, conflict set: directory, ghc)
> > After searching the rest of the dependency tree exhaustively, these were the
> > goals I've had most trouble fulfilling: directory, ghc
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From post at volker-wysk.de  Thu Sep 15 16:09:33 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 15 Sep 2022 18:09:33 +0200
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <CAHFo2up155vs_cSuUmAxz8ZMUJa=LZF6j_pxKPHR6+BB7WSQ_g@mail.gmail.com>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <CAHFo2up155vs_cSuUmAxz8ZMUJa=LZF6j_pxKPHR6+BB7WSQ_g@mail.gmail.com>
Message-ID: <1ccde593a57e40ec076aab62652eb0fd6500d432.camel@volker-wysk.de>

Am Donnerstag, dem 15.09.2022 um 17:47 +0200 schrieb Mikolaj Konarski:
> This may be caused by some cabal.project lying around
> (e.g., in the directory you are in when you are installing, but also
> in any parent directory) or by .ghc.environment.arch-os-version
> files lying around
> 
> https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments

I don't have a cabal.project or .ghc.environment.arch-os-version lying
around. However, I've found ~/.ghc/x86_64-linux-8.8.4/environments/default,
which contains this:


clear-package-db
global-package-db
package-db /home/v/.cabal/store/ghc-8.8.4/package.db
package-id ghc-8.8.4
package-id bytestring-0.10.10.1
package-id unix-2.7.3-
f9e049162269c42fac796ce2193bc96fb95dfe3ac975de03338213cf0e37a14a
package-id base-4.13.0.0
package-id time-1.12.1-
79940fa11921893814fd2d9a0f4653cb6d9b3a2de6720e03a14215ba5d4e06e7
package-id hpc-0.6.0.3
package-id filepath-1.4.2.1
package-id process-1.6.15.0-
0397a5aa0d99937f979c3ecfb8c3917000787735a4c430a5ee92c026f8987cf0
package-id array-0.5.4.0
package-id integer-gmp-1.0.2.0
package-id containers-0.6.2.1
package-id ghc-boot-8.8.4
package-id binary-0.8.7.0
package-id ghc-prim-0.5.3
package-id ghci-8.8.4
package-id rts
package-id terminfo-0.4.1.4
package-id transformers-0.5.6.2
package-id deepseq-1.4.4.0
package-id ghc-boot-th-8.8.4
package-id pretty-1.1.3.6
package-id template-haskell-2.15.0.0
package-id directory-1.3.7.1-
ada0557c8af940ba0586588eddbc02eb543cb70097182636c20a53c37f6c724e
package-id text-1.2.4.0
package-id random-1.2.1.1-
96a066a3c9e6ce9db8a64c0229a4a92c26549367424a16852f798314b610d9ae
package-id hsshellscript-3.5.0-
d22730dc2a5e25b97ff191ad98a6a1517ff456eecf456231207a8e35d428732e


I've tried the "cabal install --lib" commmand in /tmp, but it's the same.

> 
> which is likely if you indeed installed whole packages, and not just
> executables from the packages (`cabal install` only installs executables).

What I've actually called is "cabal install --lib rfc5051", sorry.

> If the problem persists please file a ticket on cabal github bug tracker.
> 
> BTW, I haven't received your email, but only the response from Tom.
> Nothing in the spam folder, either. Strange.


Cheers,
Volker

From post at volker-wysk.de  Thu Sep 15 16:11:55 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 15 Sep 2022 18:11:55 +0200
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <YyNFXRH0YrnCxFph@cloudinit-builder>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
Message-ID: <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>

Am Donnerstag, dem 15.09.2022 um 16:31 +0100 schrieb Tom Ellis:
> On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> > I've lately set up the Haskell environment on my Linux box, with no
> > problems. Then I have installed some packages with "cabal install", again
> > without problems. But now I'm trying to install another package and I get a
> > dependency conflict. It doesn't seem to matter which package I try to
> > install:
> 
> This is quite weird, because neither directory nor ghc are
> dependencies of rfc5051.
> 
> As a first step, can you try the following and report back whether you
> successfully get to a GHCi a prompt?
> 
> $ cabal repl -z --build-depends rfc5051

This results in:


desktop ~ $ cabal repl -z --build-depends rfc5051
Resolving dependencies...
Build profile: -w ghc-8.8.4 -O1
In order, the following will be built (use -v for more details):
 - rfc5051-0.2 (lib) (requires download & build)
 - fake-package-0 (lib) (first run)
Downloading  rfc5051-0.2
Downloaded   rfc5051-0.2
Starting     rfc5051-0.2 (lib)
Building     rfc5051-0.2 (lib)
Installing   rfc5051-0.2 (lib)
Completed    rfc5051-0.2 (lib)
Configuring library for fake-package-0..
Preprocessing library for fake-package-0..
Warning: No exposed modules
GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /tmp/cabal-repl.-17863/setcwd.ghci
Prelude> 


Looks good, doesn't it..?

Volker

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Sep 15 16:17:30 2022
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 15 Sep 2022 17:17:30 +0100
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
Message-ID: <YyNQGspg3pvyXz6Y@cloudinit-builder>

On Thu, Sep 15, 2022 at 06:11:55PM +0200, Volker Wysk wrote:
> Am Donnerstag, dem 15.09.2022 um 16:31 +0100 schrieb Tom Ellis:
> > On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> > > I've lately set up the Haskell environment on my Linux box, with no
> > > problems. Then I have installed some packages with "cabal install", again
> > > without problems. But now I'm trying to install another package and I get a
> > > dependency conflict. It doesn't seem to matter which package I try to
> > > install:
> > 
> > This is quite weird, because neither directory nor ghc are
> > dependencies of rfc5051.
> > 
> > As a first step, can you try the following and report back whether you
> > successfully get to a GHCi a prompt?
> > 
> > $ cabal repl -z --build-depends rfc5051
> 
> This results in:
> 
> 
> desktop ~ $ cabal repl -z --build-depends rfc5051
> Resolving dependencies...
> Build profile: -w ghc-8.8.4 -O1
> In order, the following will be built (use -v for more details):
>  - rfc5051-0.2 (lib) (requires download & build)
>  - fake-package-0 (lib) (first run)
> Downloading  rfc5051-0.2
> Downloaded   rfc5051-0.2
> Starting     rfc5051-0.2 (lib)
> Building     rfc5051-0.2 (lib)
> Installing   rfc5051-0.2 (lib)
> Completed    rfc5051-0.2 (lib)
> Configuring library for fake-package-0..
> Preprocessing library for fake-package-0..
> Warning: No exposed modules
> GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
> Loaded GHCi configuration from /tmp/cabal-repl.-17863/setcwd.ghci
> Prelude> 
> 
> 
> Looks good, doesn't it..?

Yes, so this means that the problem is indeed the
~/.ghc/x86_64-linux-8.8.4/environments/default that Mikolaj predicted
and you confirmed in a sibling thread.

I'm not sure what the suggested fix is.  I find this part of the cabal
command line API extremely inscrutable.

Tom

From allbery.b at gmail.com  Thu Sep 15 16:25:11 2022
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 15 Sep 2022 12:25:11 -0400
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
Message-ID: <CAKFCL4VGb6GQs-QnWkTnSG0bhHvr39HaVNHFu9SrKC5qxcxFuQ@mail.gmail.com>

It looks good because you're using it the way you're supposed to
instead of blindly using --lib to install things. That creates
dependency issues like what you're having. Basically, don't use --lib
unless you know what you're doing.

Remove the environment file, and create projects with dependencies on
the libraries you want, instead of trying to preinstall them. Cabal
knows how to manage packages for you so they don't conflict.

On Thu, Sep 15, 2022 at 12:12 PM Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Donnerstag, dem 15.09.2022 um 16:31 +0100 schrieb Tom Ellis:
> > On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> > > I've lately set up the Haskell environment on my Linux box, with no
> > > problems. Then I have installed some packages with "cabal install", again
> > > without problems. But now I'm trying to install another package and I get a
> > > dependency conflict. It doesn't seem to matter which package I try to
> > > install:
> >
> > This is quite weird, because neither directory nor ghc are
> > dependencies of rfc5051.
> >
> > As a first step, can you try the following and report back whether you
> > successfully get to a GHCi a prompt?
> >
> > $ cabal repl -z --build-depends rfc5051
>
> This results in:
>
>
> desktop ~ $ cabal repl -z --build-depends rfc5051
> Resolving dependencies...
> Build profile: -w ghc-8.8.4 -O1
> In order, the following will be built (use -v for more details):
>  - rfc5051-0.2 (lib) (requires download & build)
>  - fake-package-0 (lib) (first run)
> Downloading  rfc5051-0.2
> Downloaded   rfc5051-0.2
> Starting     rfc5051-0.2 (lib)
> Building     rfc5051-0.2 (lib)
> Installing   rfc5051-0.2 (lib)
> Completed    rfc5051-0.2 (lib)
> Configuring library for fake-package-0..
> Preprocessing library for fake-package-0..
> Warning: No exposed modules
> GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
> Loaded GHCi configuration from /tmp/cabal-repl.-17863/setcwd.ghci
> Prelude>
>
>
> Looks good, doesn't it..?
>
> Volker
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From post at volker-wysk.de  Thu Sep 15 16:27:26 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 15 Sep 2022 18:27:26 +0200
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <YyNQGspg3pvyXz6Y@cloudinit-builder>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
 <YyNQGspg3pvyXz6Y@cloudinit-builder>
Message-ID: <d6be7e6b9d51b33872a62d57c7fd31368363c0f9.camel@volker-wysk.de>

Am Donnerstag, dem 15.09.2022 um 17:17 +0100 schrieb Tom Ellis:
> On Thu, Sep 15, 2022 at 06:11:55PM +0200, Volker Wysk wrote:
> > Am Donnerstag, dem 15.09.2022 um 16:31 +0100 schrieb Tom Ellis:
> > > On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> > > > I've lately set up the Haskell environment on my Linux box, with no
> > > > problems. Then I have installed some packages with "cabal install", again
> > > > without problems. But now I'm trying to install another package and I get a
> > > > dependency conflict. It doesn't seem to matter which package I try to
> > > > install:
> > > 
> > > This is quite weird, because neither directory nor ghc are
> > > dependencies of rfc5051.
> > > 
> > > As a first step, can you try the following and report back whether you
> > > successfully get to a GHCi a prompt?
> > > 
> > > $ cabal repl -z --build-depends rfc5051
> > 
> > This results in:
> > 
> > 
> > desktop ~ $ cabal repl -z --build-depends rfc5051
> > Resolving dependencies...
> > Build profile: -w ghc-8.8.4 -O1
> > In order, the following will be built (use -v for more details):
> >  - rfc5051-0.2 (lib) (requires download & build)
> >  - fake-package-0 (lib) (first run)
> > Downloading  rfc5051-0.2
> > Downloaded   rfc5051-0.2
> > Starting     rfc5051-0.2 (lib)
> > Building     rfc5051-0.2 (lib)
> > Installing   rfc5051-0.2 (lib)
> > Completed    rfc5051-0.2 (lib)
> > Configuring library for fake-package-0..
> > Preprocessing library for fake-package-0..
> > Warning: No exposed modules
> > GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
> > Loaded GHCi configuration from /tmp/cabal-repl.-17863/setcwd.ghci
> > Prelude> 
> > 
> > 
> > Looks good, doesn't it..?
> 
> Yes, so this means that the problem is indeed the
> ~/.ghc/x86_64-linux-8.8.4/environments/default that Mikolaj predicted
> and you confirmed in a sibling thread.

For reference, here's the beginning of that file again:


clear-package-db
global-package-db
package-db /home/v/.cabal/store/ghc-8.8.4/package.db
package-id ghc-8.8.4
package-id bytestring-0.10.10.1
package-id unix-2.7.3-
f9e049162269c42fac796ce2193bc96fb95dfe3ac975de03338213cf0e37a14a
package-id base-4.13.0.0
...


What makes me wonder is, that some but not all "package-id" entries have a
large hexadecimal string at the end of the line...

> 
> I'm not sure what the suggested fix is.  I find this part of the cabal
> command line API extremely inscrutable.

Bye
Volker

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Sep 15 16:33:06 2022
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 15 Sep 2022 17:33:06 +0100
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <1ccde593a57e40ec076aab62652eb0fd6500d432.camel@volker-wysk.de>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <CAHFo2up155vs_cSuUmAxz8ZMUJa=LZF6j_pxKPHR6+BB7WSQ_g@mail.gmail.com>
 <1ccde593a57e40ec076aab62652eb0fd6500d432.camel@volker-wysk.de>
Message-ID: <YyNTwtJxUm/nC2Rh@cloudinit-builder>

On Thu, Sep 15, 2022 at 06:09:33PM +0200, Volker Wysk wrote:
> Am Donnerstag, dem 15.09.2022 um 17:47 +0200 schrieb Mikolaj Konarski:
> > This may be caused by some cabal.project lying around
> > (e.g., in the directory you are in when you are installing, but also
> > in any parent directory) or by .ghc.environment.arch-os-version
> > files lying around
> > 
> > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments
> 
> I don't have a cabal.project or .ghc.environment.arch-os-version lying
> around. However, I've found ~/.ghc/x86_64-linux-8.8.4/environments/default,
> which contains this:

GHC 8.8.4 depends on directory 1.3.6.0, therefore the GHC API package,
ghc, does too as mentioned in the original error message:


[__1] rejecting: ghc-8.8.4/installed-8.8... (conflict: directory==1.3.7.1, ghc
=> directory==1.3.6.0/installed-1.3...)


and can be verified at:

https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history


However, you have got an environment file that requires ghc-8.8.4 and
directory-1.3.7.1 at the same time.  Something's funny about that
because it's impossible to satisfy and I'm not sure how it could have
happened in the first place.  Perhaps some cabal expert can weigh in.

Tom


> clear-package-db
> global-package-db
> package-db /home/v/.cabal/store/ghc-8.8.4/package.db
> package-id ghc-8.8.4
> package-id bytestring-0.10.10.1
> package-id unix-2.7.3-
> f9e049162269c42fac796ce2193bc96fb95dfe3ac975de03338213cf0e37a14a
> package-id base-4.13.0.0
> package-id time-1.12.1-
> 79940fa11921893814fd2d9a0f4653cb6d9b3a2de6720e03a14215ba5d4e06e7
> package-id hpc-0.6.0.3
> package-id filepath-1.4.2.1
> package-id process-1.6.15.0-
> 0397a5aa0d99937f979c3ecfb8c3917000787735a4c430a5ee92c026f8987cf0
> package-id array-0.5.4.0
> package-id integer-gmp-1.0.2.0
> package-id containers-0.6.2.1
> package-id ghc-boot-8.8.4
> package-id binary-0.8.7.0
> package-id ghc-prim-0.5.3
> package-id ghci-8.8.4
> package-id rts
> package-id terminfo-0.4.1.4
> package-id transformers-0.5.6.2
> package-id deepseq-1.4.4.0
> package-id ghc-boot-th-8.8.4
> package-id pretty-1.1.3.6
> package-id template-haskell-2.15.0.0
> package-id directory-1.3.7.1-
> ada0557c8af940ba0586588eddbc02eb543cb70097182636c20a53c37f6c724e
> package-id text-1.2.4.0
> package-id random-1.2.1.1-
> 96a066a3c9e6ce9db8a64c0229a4a92c26549367424a16852f798314b610d9ae
> package-id hsshellscript-3.5.0-
> d22730dc2a5e25b97ff191ad98a6a1517ff456eecf456231207a8e35d428732e

From allbery.b at gmail.com  Thu Sep 15 16:34:01 2022
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 15 Sep 2022 12:34:01 -0400
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <d6be7e6b9d51b33872a62d57c7fd31368363c0f9.camel@volker-wysk.de>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
 <YyNQGspg3pvyXz6Y@cloudinit-builder>
 <d6be7e6b9d51b33872a62d57c7fd31368363c0f9.camel@volker-wysk.de>
Message-ID: <CAKFCL4WXuFmrLU76ZemFy_1o=tAhkVGpLYP324hdVmoQDRc27w@mail.gmail.com>

The hex ID is an ABI hash. It is included for libraries installed by
cabal, but not those that ship with ghc itself.

On Thu, Sep 15, 2022 at 12:27 PM Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Donnerstag, dem 15.09.2022 um 17:17 +0100 schrieb Tom Ellis:
> > On Thu, Sep 15, 2022 at 06:11:55PM +0200, Volker Wysk wrote:
> > > Am Donnerstag, dem 15.09.2022 um 16:31 +0100 schrieb Tom Ellis:
> > > > On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> > > > > I've lately set up the Haskell environment on my Linux box, with no
> > > > > problems. Then I have installed some packages with "cabal install", again
> > > > > without problems. But now I'm trying to install another package and I get a
> > > > > dependency conflict. It doesn't seem to matter which package I try to
> > > > > install:
> > > >
> > > > This is quite weird, because neither directory nor ghc are
> > > > dependencies of rfc5051.
> > > >
> > > > As a first step, can you try the following and report back whether you
> > > > successfully get to a GHCi a prompt?
> > > >
> > > > $ cabal repl -z --build-depends rfc5051
> > >
> > > This results in:
> > >
> > >
> > > desktop ~ $ cabal repl -z --build-depends rfc5051
> > > Resolving dependencies...
> > > Build profile: -w ghc-8.8.4 -O1
> > > In order, the following will be built (use -v for more details):
> > >  - rfc5051-0.2 (lib) (requires download & build)
> > >  - fake-package-0 (lib) (first run)
> > > Downloading  rfc5051-0.2
> > > Downloaded   rfc5051-0.2
> > > Starting     rfc5051-0.2 (lib)
> > > Building     rfc5051-0.2 (lib)
> > > Installing   rfc5051-0.2 (lib)
> > > Completed    rfc5051-0.2 (lib)
> > > Configuring library for fake-package-0..
> > > Preprocessing library for fake-package-0..
> > > Warning: No exposed modules
> > > GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
> > > Loaded GHCi configuration from /tmp/cabal-repl.-17863/setcwd.ghci
> > > Prelude>
> > >
> > >
> > > Looks good, doesn't it..?
> >
> > Yes, so this means that the problem is indeed the
> > ~/.ghc/x86_64-linux-8.8.4/environments/default that Mikolaj predicted
> > and you confirmed in a sibling thread.
>
> For reference, here's the beginning of that file again:
>
>
> clear-package-db
> global-package-db
> package-db /home/v/.cabal/store/ghc-8.8.4/package.db
> package-id ghc-8.8.4
> package-id bytestring-0.10.10.1
> package-id unix-2.7.3-
> f9e049162269c42fac796ce2193bc96fb95dfe3ac975de03338213cf0e37a14a
> package-id base-4.13.0.0
> ...
>
>
> What makes me wonder is, that some but not all "package-id" entries have a
> large hexadecimal string at the end of the line...
>
> >
> > I'm not sure what the suggested fix is.  I find this part of the cabal
> > command line API extremely inscrutable.
>
> Bye
> Volker
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Sep 15 16:34:24 2022
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 15 Sep 2022 17:34:24 +0100
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <d6be7e6b9d51b33872a62d57c7fd31368363c0f9.camel@volker-wysk.de>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
 <YyNQGspg3pvyXz6Y@cloudinit-builder>
 <d6be7e6b9d51b33872a62d57c7fd31368363c0f9.camel@volker-wysk.de>
Message-ID: <YyNUEKfiv1Uh4Jv+@cloudinit-builder>

On Thu, Sep 15, 2022 at 06:27:26PM +0200, Volker Wysk wrote:
> What makes me wonder is, that some but not all "package-id" entries have a
> large hexadecimal string at the end of the line...

Those are the boot packages, i.e. the ones that come built in to your
GHC distribution.

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Sep 15 16:38:51 2022
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 15 Sep 2022 17:38:51 +0100
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <CAKFCL4VGb6GQs-QnWkTnSG0bhHvr39HaVNHFu9SrKC5qxcxFuQ@mail.gmail.com>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
 <CAKFCL4VGb6GQs-QnWkTnSG0bhHvr39HaVNHFu9SrKC5qxcxFuQ@mail.gmail.com>
Message-ID: <YyNVG05gnBgIXX+7@cloudinit-builder>

On Thu, Sep 15, 2022 at 12:25:11PM -0400, Brandon Allbery wrote:
> It looks good because you're using it the way you're supposed to
> instead of blindly using --lib to install things. That creates
> dependency issues like what you're having. Basically, don't use --lib
> unless you know what you're doing.

+1, although I'm yet to see evidence that anyone knows what
they're doing with --lib.

Unfortunately instructions like

  This package can be installed using the Cabal package manager for
  Haskell by issuing the following command:
  
  cabal install QuickCheck

are still prevalent around the web.  When the user tries he or she
gets the response


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: Installation might not be completed as desired! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The command "cabal install [TARGETS]" doesn't expose libraries.
* You might have wanted to add them as dependencies to your package. In this
case add "QuickCheck" to the build-depends field(s) of your package's .cabal
file.
* You might have wanted to add them to a GHC environment. In this case use
"cabal install --lib QuickCheck". The "--lib" flag is provisional: see
https://github.com/haskell/cabal/issues/6481 for more information.


The next natural course of action is "cabal install --lib".

Tom

From post at volker-wysk.de  Thu Sep 15 16:39:39 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 15 Sep 2022 18:39:39 +0200
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <CAKFCL4VGb6GQs-QnWkTnSG0bhHvr39HaVNHFu9SrKC5qxcxFuQ@mail.gmail.com>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
 <CAKFCL4VGb6GQs-QnWkTnSG0bhHvr39HaVNHFu9SrKC5qxcxFuQ@mail.gmail.com>
Message-ID: <61ec30d54db82cff18cb11827cb8c0d6a7286c59.camel@volker-wysk.de>

Am Donnerstag, dem 15.09.2022 um 12:25 -0400 schrieb Brandon Allbery:
> It looks good because you're using it the way you're supposed to
> instead of blindly using --lib to install things. That creates
> dependency issues like what you're having. Basically, don't use --lib
> unless you know what you're doing.
> 
> Remove the environment file, and create projects with dependencies on
> the libraries you want, instead of trying to preinstall them. Cabal
> knows how to manage packages for you so they don't conflict.

I admit that I don't really know what I'm doing, when using cabal. I've 
built my projects by calling ghc from a generic Makefile for a long time
now. And you're saying I should build them with "cabal build" instead? This
would mean that I must change my long-fostered build environment. 

Looks like I have to do some reading.

Bye,
Volker

> 
> On Thu, Sep 15, 2022 at 12:12 PM Volker Wysk <post at volker-wysk.de> wrote:
> > 
> > Am Donnerstag, dem 15.09.2022 um 16:31 +0100 schrieb Tom Ellis:
> > > On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> > > > I've lately set up the Haskell environment on my Linux box, with no
> > > > problems. Then I have installed some packages with "cabal install", again
> > > > without problems. But now I'm trying to install another package and I get a
> > > > dependency conflict. It doesn't seem to matter which package I try to
> > > > install:
> > > 
> > > This is quite weird, because neither directory nor ghc are
> > > dependencies of rfc5051.
> > > 
> > > As a first step, can you try the following and report back whether you
> > > successfully get to a GHCi a prompt?
> > > 
> > > $ cabal repl -z --build-depends rfc5051
> > 
> > This results in:
> > 
> > 
> > desktop ~ $ cabal repl -z --build-depends rfc5051
> > Resolving dependencies...
> > Build profile: -w ghc-8.8.4 -O1
> > In order, the following will be built (use -v for more details):
> >  - rfc5051-0.2 (lib) (requires download & build)
> >  - fake-package-0 (lib) (first run)
> > Downloading  rfc5051-0.2
> > Downloaded   rfc5051-0.2
> > Starting     rfc5051-0.2 (lib)
> > Building     rfc5051-0.2 (lib)
> > Installing   rfc5051-0.2 (lib)
> > Completed    rfc5051-0.2 (lib)
> > Configuring library for fake-package-0..
> > Preprocessing library for fake-package-0..
> > Warning: No exposed modules
> > GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
> > Loaded GHCi configuration from /tmp/cabal-repl.-17863/setcwd.ghci
> > Prelude>
> > 
> > 
> > Looks good, doesn't it..?
> > 
> > Volker
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> 
> 
> 


From allbery.b at gmail.com  Thu Sep 15 17:01:10 2022
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 15 Sep 2022 13:01:10 -0400
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <YyNVG05gnBgIXX+7@cloudinit-builder>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
 <CAKFCL4VGb6GQs-QnWkTnSG0bhHvr39HaVNHFu9SrKC5qxcxFuQ@mail.gmail.com>
 <YyNVG05gnBgIXX+7@cloudinit-builder>
Message-ID: <CAKFCL4VyVP30R5y4MJr+TEddzb9S2p_0Lu1DXvcXJwH7QEQdCQ@mail.gmail.com>

xmonad uses `--lib` along with `--package-env` so its packages are
visible only to xmonad during mod-q rebuilds. This works well without
polluting the global package environment.

On Thu, Sep 15, 2022 at 12:38 PM Tom Ellis
<tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>
> On Thu, Sep 15, 2022 at 12:25:11PM -0400, Brandon Allbery wrote:
> > It looks good because you're using it the way you're supposed to
> > instead of blindly using --lib to install things. That creates
> > dependency issues like what you're having. Basically, don't use --lib
> > unless you know what you're doing.
>
> +1, although I'm yet to see evidence that anyone knows what
> they're doing with --lib.
>
> Unfortunately instructions like
>
>   This package can be installed using the Cabal package manager for
>   Haskell by issuing the following command:
>
>   cabal install QuickCheck
>
> are still prevalent around the web.  When the user tries he or she
> gets the response
>
>
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @ WARNING: Installation might not be completed as desired! @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> The command "cabal install [TARGETS]" doesn't expose libraries.
> * You might have wanted to add them as dependencies to your package. In this
> case add "QuickCheck" to the build-depends field(s) of your package's .cabal
> file.
> * You might have wanted to add them to a GHC environment. In this case use
> "cabal install --lib QuickCheck". The "--lib" flag is provisional: see
> https://github.com/haskell/cabal/issues/6481 for more information.
>
>
> The next natural course of action is "cabal install --lib".
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From allbery.b at gmail.com  Thu Sep 15 17:02:53 2022
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 15 Sep 2022 13:02:53 -0400
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <61ec30d54db82cff18cb11827cb8c0d6a7286c59.camel@volker-wysk.de>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <a641c089209afb411d9bc028c8ce1e48084f5078.camel@volker-wysk.de>
 <CAKFCL4VGb6GQs-QnWkTnSG0bhHvr39HaVNHFu9SrKC5qxcxFuQ@mail.gmail.com>
 <61ec30d54db82cff18cb11827cb8c0d6a7286c59.camel@volker-wysk.de>
Message-ID: <CAKFCL4XWeCruZAmi3=xvjitK6o0OP07FxEy_pwnBmuh2bs0oQw@mail.gmail.com>

The problem with the old way of doing things is exactly what you're
seeing: conflicting package versions that interfere with each other.
Cabal and stack both know how to expose only the package versions
needed by a build, while retaining all versions needed by various
build environments.

On Thu, Sep 15, 2022 at 12:39 PM Volker Wysk <post at volker-wysk.de> wrote:
>
> Am Donnerstag, dem 15.09.2022 um 12:25 -0400 schrieb Brandon Allbery:
> > It looks good because you're using it the way you're supposed to
> > instead of blindly using --lib to install things. That creates
> > dependency issues like what you're having. Basically, don't use --lib
> > unless you know what you're doing.
> >
> > Remove the environment file, and create projects with dependencies on
> > the libraries you want, instead of trying to preinstall them. Cabal
> > knows how to manage packages for you so they don't conflict.
>
> I admit that I don't really know what I'm doing, when using cabal. I've
> built my projects by calling ghc from a generic Makefile for a long time
> now. And you're saying I should build them with "cabal build" instead? This
> would mean that I must change my long-fostered build environment.
>
> Looks like I have to do some reading.
>
> Bye,
> Volker
>
> >
> > On Thu, Sep 15, 2022 at 12:12 PM Volker Wysk <post at volker-wysk.de> wrote:
> > >
> > > Am Donnerstag, dem 15.09.2022 um 16:31 +0100 schrieb Tom Ellis:
> > > > On Thu, Sep 15, 2022 at 05:23:10PM +0200, Volker Wysk wrote:
> > > > > I've lately set up the Haskell environment on my Linux box, with no
> > > > > problems. Then I have installed some packages with "cabal install", again
> > > > > without problems. But now I'm trying to install another package and I get a
> > > > > dependency conflict. It doesn't seem to matter which package I try to
> > > > > install:
> > > >
> > > > This is quite weird, because neither directory nor ghc are
> > > > dependencies of rfc5051.
> > > >
> > > > As a first step, can you try the following and report back whether you
> > > > successfully get to a GHCi a prompt?
> > > >
> > > > $ cabal repl -z --build-depends rfc5051
> > >
> > > This results in:
> > >
> > >
> > > desktop ~ $ cabal repl -z --build-depends rfc5051
> > > Resolving dependencies...
> > > Build profile: -w ghc-8.8.4 -O1
> > > In order, the following will be built (use -v for more details):
> > >  - rfc5051-0.2 (lib) (requires download & build)
> > >  - fake-package-0 (lib) (first run)
> > > Downloading  rfc5051-0.2
> > > Downloaded   rfc5051-0.2
> > > Starting     rfc5051-0.2 (lib)
> > > Building     rfc5051-0.2 (lib)
> > > Installing   rfc5051-0.2 (lib)
> > > Completed    rfc5051-0.2 (lib)
> > > Configuring library for fake-package-0..
> > > Preprocessing library for fake-package-0..
> > > Warning: No exposed modules
> > > GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
> > > Loaded GHCi configuration from /tmp/cabal-repl.-17863/setcwd.ghci
> > > Prelude>
> > >
> > >
> > > Looks good, doesn't it..?
> > >
> > > Volker
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > To (un)subscribe, modify options or view archives go to:
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > Only members subscribed via the mailman list are allowed to post.
> >
> >
> >
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Fri Sep 16 07:38:22 2022
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Fri, 16 Sep 2022 08:38:22 +0100
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <YyNTwtJxUm/nC2Rh@cloudinit-builder>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <CAHFo2up155vs_cSuUmAxz8ZMUJa=LZF6j_pxKPHR6+BB7WSQ_g@mail.gmail.com>
 <1ccde593a57e40ec076aab62652eb0fd6500d432.camel@volker-wysk.de>
 <YyNTwtJxUm/nC2Rh@cloudinit-builder>
Message-ID: <YyQn7jim3zyuWdee@cloudinit-builder>

On Thu, Sep 15, 2022 at 05:33:06PM +0100, Tom Ellis wrote:
> On Thu, Sep 15, 2022 at 06:09:33PM +0200, Volker Wysk wrote:
> > Am Donnerstag, dem 15.09.2022 um 17:47 +0200 schrieb Mikolaj Konarski:
> > > This may be caused by some cabal.project lying around
> > > (e.g., in the directory you are in when you are installing, but also
> > > in any parent directory) or by .ghc.environment.arch-os-version
> > > files lying around
> > > 
> > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments
> > 
> > I don't have a cabal.project or .ghc.environment.arch-os-version lying
> > around. However, I've found ~/.ghc/x86_64-linux-8.8.4/environments/default,
> > which contains this:
> 
> GHC 8.8.4 depends on directory 1.3.6.0, therefore the GHC API package,
> ghc, does too as mentioned in the original error message:
> 
> 
> [__1] rejecting: ghc-8.8.4/installed-8.8... (conflict: directory==1.3.7.1, ghc
> => directory==1.3.6.0/installed-1.3...)
> 
> 
> and can be verified at:
> 
> https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history
> 
> 
> However, you have got an environment file that requires ghc-8.8.4 and
> directory-1.3.7.1 at the same time.  Something's funny about that
> because it's impossible to satisfy and I'm not sure how it could have
> happened in the first place.  Perhaps some cabal expert can weigh in.

In the hope that a cabal expert can explain this behaviour I have
opened as issue:

https://github.com/haskell/cabal/issues/8473

From post at volker-wysk.de  Fri Sep 16 08:20:55 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Fri, 16 Sep 2022 10:20:55 +0200
Subject: [Haskell-cafe] Cabal problem, broken packages?
In-Reply-To: <YyQn7jim3zyuWdee@cloudinit-builder>
References: <8132abdf81ecb5bde292c96020d5ee3f52373715.camel@volker-wysk.de>
 <YyNFXRH0YrnCxFph@cloudinit-builder>
 <CAHFo2up155vs_cSuUmAxz8ZMUJa=LZF6j_pxKPHR6+BB7WSQ_g@mail.gmail.com>
 <1ccde593a57e40ec076aab62652eb0fd6500d432.camel@volker-wysk.de>
 <YyNTwtJxUm/nC2Rh@cloudinit-builder> <YyQn7jim3zyuWdee@cloudinit-builder>
Message-ID: <0c728cb3b076e933dd55e10ed01f8352b5d156c4.camel@volker-wysk.de>

Am Freitag, dem 16.09.2022 um 08:38 +0100 schrieb Tom Ellis:
> On Thu, Sep 15, 2022 at 05:33:06PM +0100, Tom Ellis wrote:
> > On Thu, Sep 15, 2022 at 06:09:33PM +0200, Volker Wysk wrote:
> > > Am Donnerstag, dem 15.09.2022 um 17:47 +0200 schrieb Mikolaj Konarski:
> > > > This may be caused by some cabal.project lying around
> > > > (e.g., in the directory you are in when you are installing, but also
> > > > in any parent directory) or by .ghc.environment.arch-os-version
> > > > files lying around
> > > > 
> > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments
> > > 
> > > I don't have a cabal.project or .ghc.environment.arch-os-version lying
> > > around. However, I've found ~/.ghc/x86_64-linux-8.8.4/environments/default,
> > > which contains this:
> > 
> > GHC 8.8.4 depends on directory 1.3.6.0, therefore the GHC API package,
> > ghc, does too as mentioned in the original error message:
> > 
> > 
> > [__1] rejecting: ghc-8.8.4/installed-8.8... (conflict: directory==1.3.7.1, ghc
> > => directory==1.3.6.0/installed-1.3...)
> > 
> > 
> > and can be verified at:
> > 
> > https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history
> > 
> > 
> > However, you have got an environment file that requires ghc-8.8.4 and
> > directory-1.3.7.1 at the same time.  Something's funny about that
> > because it's impossible to satisfy and I'm not sure how it could have
> > happened in the first place.  Perhaps some cabal expert can weigh in.
> 
> In the hope that a cabal expert can explain this behaviour I have
> opened as issue:
> 
> https://github.com/haskell/cabal/issues/8473

Thanks for that. But I'm switching to cabal ("cabal build") now, instead of
my Makefile. Of course the problem should be minded, if it is a bug.
However, I don't need that any longer.

Cheers,
Volker

From post at volker-wysk.de  Fri Sep 16 08:47:47 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Fri, 16 Sep 2022 10:47:47 +0200
Subject: [Haskell-cafe] Cabal: other-modules necessary?
Message-ID: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>

Hi

The cabal user guide says (in section 6.2.12): "Every module in the package
must be listed in one of other-modules, library:exposed-modules or
executable:main-is fields."

However, I only get a warning message, when I comment out the other-modules
field in my .cabal file. The program compiles. This is the message:

<no location info>: warning: [-Wmissing-home-modules]
    These modules are needed for compilation but not listed in your .cabal 
    file's other-modules: 
        Hsskripte Sicherung SicherungAktionen Text Wahl Zeit

Is it really necessary to specify all the imported modules? If so, why does
the program compile? Can that warning message be turned off?

Apart from that, I'm happy with cabal.   :-)

Cheers,
Volker

From ikke at nicolast.be  Fri Sep 16 08:53:29 2022
From: ikke at nicolast.be (Nicolas Trangez)
Date: Fri, 16 Sep 2022 10:53:29 +0200
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
Message-ID: <b37172700bc9485a2b7c0e30970297eb77228cc2.camel@nicolast.be>

Hello Volker,

Compilation will, indeed, succeed. However, distribution won't: if the
module is not listed in `Other-Modules` (or any of the other sections),
it won't be included in the tarball generated when you invoke `cabal
sdist`, i.e., the source archive uploaded to Hackage.

Hence, if someone then tries to download and build your package from
Hackage, this will fail, since some module source files are missing.

There may be other effects of not listing some module, though above is
the one I'm aware of.

Cheers,

Nicolas

On Fri, 2022-09-16 at 10:47 +0200, Volker Wysk wrote:
> Hi
> 
> The cabal user guide says (in section 6.2.12): "Every module in the
> package
> must be listed in one of other-modules, library:exposed-modules or
> executable:main-is fields."
> 
> However, I only get a warning message, when I comment out the other-
> modules
> field in my .cabal file. The program compiles. This is the message:
> 
> <no location info>: warning: [-Wmissing-home-modules]
>     These modules are needed for compilation but not listed in your
> .cabal 
>     file's other-modules: 
>         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> 
> Is it really necessary to specify all the imported modules? If so,
> why does
> the program compile? Can that warning message be turned off?
> 
> Apart from that, I'm happy with cabal.   :-)
> 
> Cheers,
> Volker
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


From post at volker-wysk.de  Fri Sep 16 09:10:35 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Fri, 16 Sep 2022 11:10:35 +0200
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <b37172700bc9485a2b7c0e30970297eb77228cc2.camel@nicolast.be>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <b37172700bc9485a2b7c0e30970297eb77228cc2.camel@nicolast.be>
Message-ID: <1204b51c4240942d626c2249c9c455528fd5dcc5.camel@volker-wysk.de>

Am Freitag, dem 16.09.2022 um 10:53 +0200 schrieb Nicolas Trangez:
> Hello Volker,
> 
> Compilation will, indeed, succeed. However, distribution won't: if the
> module is not listed in `Other-Modules` (or any of the other sections),
> it won't be included in the tarball generated when you invoke `cabal
> sdist`, i.e., the source archive uploaded to Hackage.

That's fine im my case. I don't want to distribute that.

Regarding my other question (Can that warning message be turned off?), I've
found out. It can be turned off with this line in the cabal.project file:

Wmissing-home-modules: False


Regards,
Volker


> Hence, if someone then tries to download and build your package from
> Hackage, this will fail, since some module source files are missing.
> 
> There may be other effects of not listing some module, though above is
> the one I'm aware of.
> 
> Cheers,
> 
> Nicolas
> 
> On Fri, 2022-09-16 at 10:47 +0200, Volker Wysk wrote:
> > Hi
> > 
> > The cabal user guide says (in section 6.2.12): "Every module in the
> > package
> > must be listed in one of other-modules, library:exposed-modules or
> > executable:main-is fields."
> > 
> > However, I only get a warning message, when I comment out the other-
> > modules
> > field in my .cabal file. The program compiles. This is the message:
> > 
> > <no location info>: warning: [-Wmissing-home-modules]
> >     These modules are needed for compilation but not listed in your
> > .cabal 
> >     file's other-modules: 
> >         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> > 
> > Is it really necessary to specify all the imported modules? If so,
> > why does
> > the program compile? Can that warning message be turned off?
> > 
> > Apart from that, I'm happy with cabal.   :-)
> > 
> > Cheers,
> > Volker
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> 


From oleg.grenrus at iki.fi  Fri Sep 16 09:12:04 2022
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Fri, 16 Sep 2022 12:12:04 +0300
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <b37172700bc9485a2b7c0e30970297eb77228cc2.camel@nicolast.be>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <b37172700bc9485a2b7c0e30970297eb77228cc2.camel@nicolast.be>
Message-ID: <e1c4aa92-0d9a-ae6e-dfd0-e820fb185b23@iki.fi>

Also even locally, when you depend on the library and try to link you'll
get linker errors as omitted modules are not part of linkage.

Write a test-suite for your library, and you'll notice!


For example, if I comment out other-modules in postgresql-simple and try
to run a test-suite named "test"

cabal run test

I'll get (just) a warning when compiling the library

<no location info>: warning: [-Wmissing-home-modules]
    These modules are needed for compilation but not listed in your
.cabal file's other-modules:
        Database.PostgreSQL.Simple.Compat
        Database.PostgreSQL.Simple.HStore.Implementation
        Database.PostgreSQL.Simple.Internal.PQResultUtils
        Database.PostgreSQL.Simple.Time.Implementation
        Database.PostgreSQL.Simple.Time.Internal.Parser
        Database.PostgreSQL.Simple.Time.Internal.Printer
        Database.PostgreSQL.Simple.TypeInfo.Types

but compilation of test-suite fails (it uses TemplateHaskell, otherwise
it probably would fail when linking the executable)

<command line>: can't load .so/.DLL for:
/code/public-haskell/postgresql-simple/dist-newstyle/build/x86_64-linux/ghc-8.6.5/postgresql-simple-0.6.4/build/libHSpostgresql-simple-0.6.4-inplace-ghc8.6.5.so
(/code/public-haskell/postgresql-simple/dist-newstyle/build/x86_64-linux/ghc-8.6.5/postgresql-simple-0.6.4/build/libHSpostgresql-simple-0.6.4-inplace-ghc8.6.5.so:
undefined symbol:
postgresqlzmsimplezm0zi6zi4zminplace_DatabaseziPostgreSQLziSimpleziInternalziPQResultUtils_zdwfinishQueryWith_closure)

What is additionally annoying, is that if your executable doesn't
actually (even transitively) use any symbols from other-modules (which
some test-suites may not), they won't be needed for linking and it will
succeed... until you add something, and linking will fail with
incomprehensible error like above.

- Oleg

On 16.9.2022 11.53, Nicolas Trangez wrote:
> Hello Volker,
>
> Compilation will, indeed, succeed. However, distribution won't: if the
> module is not listed in `Other-Modules` (or any of the other sections),
> it won't be included in the tarball generated when you invoke `cabal
> sdist`, i.e., the source archive uploaded to Hackage.
>
> Hence, if someone then tries to download and build your package from
> Hackage, this will fail, since some module source files are missing.
>
> There may be other effects of not listing some module, though above is
> the one I'm aware of.
>
> Cheers,
>
> Nicolas
>
> On Fri, 2022-09-16 at 10:47 +0200, Volker Wysk wrote:
>> Hi
>>
>> The cabal user guide says (in section 6.2.12): "Every module in the
>> package
>> must be listed in one of other-modules, library:exposed-modules or
>> executable:main-is fields."
>>
>> However, I only get a warning message, when I comment out the other-
>> modules
>> field in my .cabal file. The program compiles. This is the message:
>>
>> <no location info>: warning: [-Wmissing-home-modules]
>>     These modules are needed for compilation but not listed in your
>> .cabal 
>>     file's other-modules: 
>>         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
>>
>> Is it really necessary to specify all the imported modules? If so,
>> why does
>> the program compile? Can that warning message be turned off?
>>
>> Apart from that, I'm happy with cabal.   :-)
>>
>> Cheers,
>> Volker
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From ollie at ocharles.org.uk  Fri Sep 16 09:12:06 2022
From: ollie at ocharles.org.uk (Oliver Charles)
Date: Fri, 16 Sep 2022 10:12:06 +0100
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
Message-ID: <047ed173-9a3b-406c-9bbf-995b4f198652@www.fastmail.com>

Hi Volker,

If you don't mention all modules in your Cabal file you may well get some very confusing linker errors later on when you build an executable, or try to use your library in another component. See https://stackoverflow.com/questions/28857275/cabal-test-fails-to-link-its-own-objects for one such example of the very cryptic error you'll likely eventually run into!

Ollie

On Fri, 16 Sep 2022, at 9:47 AM, Volker Wysk wrote:
> Hi
> 
> The cabal user guide says (in section 6.2.12): "Every module in the package
> must be listed in one of other-modules, library:exposed-modules or
> executable:main-is fields."
> 
> However, I only get a warning message, when I comment out the other-modules
> field in my .cabal file. The program compiles. This is the message:
> 
> <no location info>: warning: [-Wmissing-home-modules]
>     These modules are needed for compilation but not listed in your .cabal 
>     file's other-modules: 
>         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> 
> Is it really necessary to specify all the imported modules? If so, why does
> the program compile? Can that warning message be turned off?
> 
> Apart from that, I'm happy with cabal.   :-)
> 
> Cheers,
> Volker
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220916/e0a6655c/attachment-0001.html>

From post at volker-wysk.de  Fri Sep 16 09:19:05 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Fri, 16 Sep 2022 11:19:05 +0200
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <e1c4aa92-0d9a-ae6e-dfd0-e820fb185b23@iki.fi>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <b37172700bc9485a2b7c0e30970297eb77228cc2.camel@nicolast.be>
 <e1c4aa92-0d9a-ae6e-dfd0-e820fb185b23@iki.fi>
Message-ID: <59b001b15a1555087bfd2d3aa64fed80b159424a.camel@volker-wysk.de>

Hi!

Am Freitag, dem 16.09.2022 um 12:12 +0300 schrieb Oleg Grenrus:
> Also even locally, when you depend on the library and try to link you'll
> get linker errors as omitted modules are not part of linkage.
> 
> Write a test-suite for your library, and you'll notice!

I'm not writing a library here, but several executables. And it works,
without specifying "other-modules". 

But I guess you're right when a library is to be compiled.

Bye,
Volker

> For example, if I comment out other-modules in postgresql-simple and try
> to run a test-suite named "test"
> 
> cabal run test
> 
> I'll get (just) a warning when compiling the library
> 
> <no location info>: warning: [-Wmissing-home-modules]
>     These modules are needed for compilation but not listed in your
> .cabal file's other-modules:
>         Database.PostgreSQL.Simple.Compat
>         Database.PostgreSQL.Simple.HStore.Implementation
>         Database.PostgreSQL.Simple.Internal.PQResultUtils
>         Database.PostgreSQL.Simple.Time.Implementation
>         Database.PostgreSQL.Simple.Time.Internal.Parser
>         Database.PostgreSQL.Simple.Time.Internal.Printer
>         Database.PostgreSQL.Simple.TypeInfo.Types
> 
> but compilation of test-suite fails (it uses TemplateHaskell, otherwise
> it probably would fail when linking the executable)
> 
> <command line>: can't load .so/.DLL for:
> /code/public-haskell/postgresql-simple/dist-newstyle/build/x86_64-linux/ghc-8.6.5/postgresql-simple-0.6.4/build/libHSpostgresql-simple-0.6.4-inplace-ghc8.6.5.so
> (/code/public-haskell/postgresql-simple/dist-newstyle/build/x86_64-linux/ghc-8.6.5/postgresql-simple-0.6.4/build/libHSpostgresql-simple-0.6.4-inplace-ghc8.6.5.so:
> undefined symbol:
> postgresqlzmsimplezm0zi6zi4zminplace_DatabaseziPostgreSQLziSimpleziInternalziPQResultUtils_zdwfinishQueryWith_closure)
> 
> What is additionally annoying, is that if your executable doesn't
> actually (even transitively) use any symbols from other-modules (which
> some test-suites may not), they won't be needed for linking and it will
> succeed... until you add something, and linking will fail with
> incomprehensible error like above.
> 
> - Oleg
> 
> On 16.9.2022 11.53, Nicolas Trangez wrote:
> > Hello Volker,
> > 
> > Compilation will, indeed, succeed. However, distribution won't: if the
> > module is not listed in `Other-Modules` (or any of the other sections),
> > it won't be included in the tarball generated when you invoke `cabal
> > sdist`, i.e., the source archive uploaded to Hackage.
> > 
> > Hence, if someone then tries to download and build your package from
> > Hackage, this will fail, since some module source files are missing.
> > 
> > There may be other effects of not listing some module, though above is
> > the one I'm aware of.
> > 
> > Cheers,
> > 
> > Nicolas
> > 
> > On Fri, 2022-09-16 at 10:47 +0200, Volker Wysk wrote:
> > > Hi
> > > 
> > > The cabal user guide says (in section 6.2.12): "Every module in the
> > > package
> > > must be listed in one of other-modules, library:exposed-modules or
> > > executable:main-is fields."
> > > 
> > > However, I only get a warning message, when I comment out the other-
> > > modules
> > > field in my .cabal file. The program compiles. This is the message:
> > > 
> > > <no location info>: warning: [-Wmissing-home-modules]
> > >     These modules are needed for compilation but not listed in your
> > > .cabal 
> > >     file's other-modules: 
> > >         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> > > 
> > > Is it really necessary to specify all the imported modules? If so,
> > > why does
> > > the program compile? Can that warning message be turned off?
> > > 
> > > Apart from that, I'm happy with cabal.   :-)
> > > 
> > > Cheers,
> > > Volker
> > > _______________________________________________
> > > Haskell-Cafe mailing list
> > > To (un)subscribe, modify options or view archives go to:
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > > Only members subscribed via the mailman list are allowed to post.
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Fri Sep 16 09:23:50 2022
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Fri, 16 Sep 2022 10:23:50 +0100
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
Message-ID: <YyRApvLiBNRMBVz/@cloudinit-builder>

On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote:
> The cabal user guide says (in section 6.2.12): "Every module in the package
> must be listed in one of other-modules, library:exposed-modules or
> executable:main-is fields."
> 
> However, I only get a warning message, when I comment out the other-modules
> field in my .cabal file. The program compiles. This is the message:
> 
> <no location info>: warning: [-Wmissing-home-modules]
>     These modules are needed for compilation but not listed in your .cabal 
>     file's other-modules: 
>         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> 
> Is it really necessary to specify all the imported modules? If so, why does
> the program compile? Can that warning message be turned off?

In response to all the sibling replies at once, is there a good reason
for this behaviour?  Succeeding but then failing later with obscure
errors (once the original warning message is nowhere to be seen) seems
like the worst of all worlds.  Suppose cabal errored here and failed
to proceed.  What would be the downside of that (besides backward
incompatibility)?

Tom

From post at volker-wysk.de  Fri Sep 16 09:28:36 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Fri, 16 Sep 2022 11:28:36 +0200
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <047ed173-9a3b-406c-9bbf-995b4f198652@www.fastmail.com>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <047ed173-9a3b-406c-9bbf-995b4f198652@www.fastmail.com>
Message-ID: <2e1989130b7f7a810ddd2a586b17bc47b2dae5a7.camel@volker-wysk.de>

Am Freitag, dem 16.09.2022 um 10:12 +0100 schrieb Oliver Charles:
> Hi Volker,
> 
> If you don't mention all modules in your Cabal file you may well get some
> very confusing linker errors later on when you build an executable, or try
> to use your library in another component. See
> https://stackoverflow.com/questions/28857275/cabal-test-fails-to-link-its-own-objects
>   for one such example of the very cryptic error you'll likely eventually
> run into!

It works now, without other-modules. I don't have a library in my package,
just executables.

But I guess you're right. I'll rather add all the modules to the cabal file.
It's just a little bothersome.

Volker

> 
> Ollie
> 
> On Fri, 16 Sep 2022, at 9:47 AM, Volker Wysk wrote:
> > Hi
> > 
> > The cabal user guide says (in section 6.2.12): "Every module in the
> > package
> > must be listed in one of other-modules, library:exposed-modules or
> > executable:main-is fields."
> > 
> > However, I only get a warning message, when I comment out the other-
> > modules
> > field in my .cabal file. The program compiles. This is the message:
> > 
> > <no location info>: warning: [-Wmissing-home-modules]
> >     These modules are needed for compilation but not listed in your
> > .cabal 
> >     file's other-modules: 
> >         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> > 
> > Is it really necessary to specify all the imported modules? If so, why
> > does
> > the program compile? Can that warning message be turned off?
> > 
> > Apart from that, I'm happy with cabal.   :-)
> > 
> > Cheers,
> > Volker
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> 
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.


From post at volker-wysk.de  Fri Sep 16 09:33:34 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Fri, 16 Sep 2022 11:33:34 +0200
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <YyRApvLiBNRMBVz/@cloudinit-builder>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <YyRApvLiBNRMBVz/@cloudinit-builder>
Message-ID: <ac49cd81d46a11f8a59803408914c73b4bfcb9e7.camel@volker-wysk.de>

Am Freitag, dem 16.09.2022 um 10:23 +0100 schrieb Tom Ellis:
> On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote:
> > The cabal user guide says (in section 6.2.12): "Every module in the package
> > must be listed in one of other-modules, library:exposed-modules or
> > executable:main-is fields."
> > 
> > However, I only get a warning message, when I comment out the other-modules
> > field in my .cabal file. The program compiles. This is the message:
> > 
> > <no location info>: warning: [-Wmissing-home-modules]
> >     These modules are needed for compilation but not listed in your .cabal 
> >     file's other-modules: 
> >         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> > 
> > Is it really necessary to specify all the imported modules? If so, why does
> > the program compile? Can that warning message be turned off?
> 
> In response to all the sibling replies at once, is there a good reason
> for this behaviour?  Succeeding but then failing later with obscure
> errors (once the original warning message is nowhere to be seen) seems
> like the worst of all worlds.  Suppose cabal errored here and failed
> to proceed.  What would be the downside of that (besides backward
> incompatibility)?

I've already changed my mind. It's a little bothersome to manually add all
the modules, which could be determined automatically. But it's better than
having linker errors later.

Regards,
Volker

From post at volker-wysk.de  Fri Sep 16 09:36:34 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Fri, 16 Sep 2022 11:36:34 +0200
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <1204b51c4240942d626c2249c9c455528fd5dcc5.camel@volker-wysk.de>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <b37172700bc9485a2b7c0e30970297eb77228cc2.camel@nicolast.be>
 <1204b51c4240942d626c2249c9c455528fd5dcc5.camel@volker-wysk.de>
Message-ID: <cdfd8aa61e3c4b035615bd305de422512c99be6c.camel@volker-wysk.de>

Am Freitag, dem 16.09.2022 um 11:10 +0200 schrieb Volker Wysk:
> Regarding my other question (Can that warning message be turned off?), I've
> found out. It can be turned off with this line in the cabal.project file:
> 
> Wmissing-home-modules: False

Oh, I made a mistake. This DOESN'T work.

Volker


From konn.jinro at gmail.com  Fri Sep 16 09:42:36 2022
From: konn.jinro at gmail.com (=?UTF-8?B?55+z5LqV5aSn5rW3?=)
Date: Fri, 16 Sep 2022 18:42:36 +0900
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <ac49cd81d46a11f8a59803408914c73b4bfcb9e7.camel@volker-wysk.de>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <YyRApvLiBNRMBVz/@cloudinit-builder>
 <ac49cd81d46a11f8a59803408914c73b4bfcb9e7.camel@volker-wysk.de>
Message-ID: <CAGo1DoGrLOV62MLco8MeaKZ_yLvTqKZ7ZRmfF2zy_44CnYos_A@mail.gmail.com>

FWIW, You could use hpack (package.yaml) to automatically fill
exposed-module:

https://github.com/sol/hpack

In short, hpack is a YAML-encoded cabal format with some syntax sugars and
automatic module list generation.
Downside is that if you're using cabal-install as the package manager, you
should convert hpack to cabal each time you edit package.yaml or add new
modules (you could set up editor save hook and/or git pre-commit hook to
reduce such burden, though).
If you're using stack, however, stack will automatically generate .cabal
from package.yaml whenever it's needed, as hpack is integrated into stack.

2022年9月16日(金) 18:34 Volker Wysk <post at volker-wysk.de>:

> Am Freitag, dem 16.09.2022 um 10:23 +0100 schrieb Tom Ellis:
> > On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote:
> > > The cabal user guide says (in section 6.2.12): "Every module in the
> package
> > > must be listed in one of other-modules, library:exposed-modules or
> > > executable:main-is fields."
> > >
> > > However, I only get a warning message, when I comment out the
> other-modules
> > > field in my .cabal file. The program compiles. This is the message:
> > >
> > > <no location info>: warning: [-Wmissing-home-modules]
> > >     These modules are needed for compilation but not listed in your
> .cabal
> > >     file's other-modules:
> > >         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> > >
> > > Is it really necessary to specify all the imported modules? If so, why
> does
> > > the program compile? Can that warning message be turned off?
> >
> > In response to all the sibling replies at once, is there a good reason
> > for this behaviour?  Succeeding but then failing later with obscure
> > errors (once the original warning message is nowhere to be seen) seems
> > like the worst of all worlds.  Suppose cabal errored here and failed
> > to proceed.  What would be the downside of that (besides backward
> > incompatibility)?
>
> I've already changed my mind. It's a little bothersome to manually add all
> the modules, which could be determined automatically. But it's better than
> having linker errors later.
>
> Regards,
> Volker
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220916/fd24a911/attachment.html>

From allbery.b at gmail.com  Fri Sep 16 10:14:01 2022
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 16 Sep 2022 06:14:01 -0400
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <YyRApvLiBNRMBVz/@cloudinit-builder>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <YyRApvLiBNRMBVz/@cloudinit-builder>
Message-ID: <CAKFCL4Vbmy76jB8=1jUxdjygrqzWwU_rzVM7OSgg-CX3DJ+TaA@mail.gmail.com>

Cabal doesn't know. GHC does, and is producing the
missing-home-modules warning. And even there, you're getting lucky; it
could miss one. Only the link step knows for certain what is missing,
because you would need whole-program compilation to reliably catch it
during the compile step.

On Fri, Sep 16, 2022 at 5:24 AM Tom Ellis
<tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>
> On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote:
> > The cabal user guide says (in section 6.2.12): "Every module in the package
> > must be listed in one of other-modules, library:exposed-modules or
> > executable:main-is fields."
> >
> > However, I only get a warning message, when I comment out the other-modules
> > field in my .cabal file. The program compiles. This is the message:
> >
> > <no location info>: warning: [-Wmissing-home-modules]
> >     These modules are needed for compilation but not listed in your .cabal
> >     file's other-modules:
> >         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> >
> > Is it really necessary to specify all the imported modules? If so, why does
> > the program compile? Can that warning message be turned off?
>
> In response to all the sibling replies at once, is there a good reason
> for this behaviour?  Succeeding but then failing later with obscure
> errors (once the original warning message is nowhere to be seen) seems
> like the worst of all worlds.  Suppose cabal errored here and failed
> to proceed.  What would be the downside of that (besides backward
> incompatibility)?
>
> Tom
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From post at volker-wysk.de  Fri Sep 16 10:52:15 2022
From: post at volker-wysk.de (Volker Wysk)
Date: Fri, 16 Sep 2022 12:52:15 +0200
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <CAGo1DoGrLOV62MLco8MeaKZ_yLvTqKZ7ZRmfF2zy_44CnYos_A@mail.gmail.com>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <YyRApvLiBNRMBVz/@cloudinit-builder>
 <ac49cd81d46a11f8a59803408914c73b4bfcb9e7.camel@volker-wysk.de>
 <CAGo1DoGrLOV62MLco8MeaKZ_yLvTqKZ7ZRmfF2zy_44CnYos_A@mail.gmail.com>
Message-ID: <6cbf6ff202a15d873d2c80917764779e89594de5.camel@volker-wysk.de>

Am Freitag, dem 16.09.2022 um 18:42 +0900 schrieb 石井大海:
> FWIW, You could use hpack (package.yaml) to automatically fill exposed-
> module:
> 
> https://github.com/sol/hpack
> 
> In short, hpack is a YAML-encoded cabal format with some syntax sugars and
> automatic module list generation.
> Downside is that if you're using cabal-install as the package manager, you
> should convert hpack to cabal each time you edit package.yaml or add new
> modules (you could set up editor save hook and/or git pre-commit hook to
> reduce such burden, though).

I've taken a look at this. It's somewhat complicated, even though it claims
it doesn't "require the user to state the obvious, make sensible assumptions
by default". There's no user manual. And the examples are quite verbose
(again, even though it claims to be simple).

I'll stick to cabal for now. At least until I know it better.

Thanks for the hint.

Volker


> If you're using stack, however, stack will automatically generate .cabal
> from package.yaml whenever it's needed, as hpack is integrated into stack.
> 
> 2022年9月16日(金) 18:34 Volker Wysk <post at volker-wysk.de>:
> > Am Freitag, dem 16.09.2022 um 10:23 +0100 schrieb Tom Ellis:
> > > On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote:
> > > > The cabal user guide says (in section 6.2.12): "Every module in the
> > > > package
> > > > must be listed in one of other-modules, library:exposed-modules or
> > > > executable:main-is fields."
> > > > 
> > > > However, I only get a warning message, when I comment out the other-
> > > > modules
> > > > field in my .cabal file. The program compiles. This is the message:
> > > > 
> > > > <no location info>: warning: [-Wmissing-home-modules]
> > > >      These modules are needed for compilation but not listed in your
> > > > .cabal 
> > > >      file's other-modules: 
> > > >          Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> > > > 
> > > > Is it really necessary to specify all the imported modules? If so,
> > > > why does
> > > > the program compile? Can that warning message be turned off?
> > > 
> > > In response to all the sibling replies at once, is there a good reason
> > > for this behaviour?  Succeeding but then failing later with obscure
> > > errors (once the original warning message is nowhere to be seen) seems
> > > like the worst of all worlds.  Suppose cabal errored here and failed
> > > to proceed.  What would be the downside of that (besides backward
> > > incompatibility)?
> > 
> > I've already changed my mind. It's a little bothersome to manually add
> > all
> > the modules, which could be determined automatically. But it's better
> > than
> > having linker errors later.
> > 
> > Regards,
> > Volker
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.


From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Sun Sep 18 16:47:11 2022
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 18 Sep 2022 17:47:11 +0100
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <ca1154c6-6974-acfe-f705-19646382a3b7@iki.fi>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <YyRApvLiBNRMBVz/@cloudinit-builder>
 <ca1154c6-6974-acfe-f705-19646382a3b7@iki.fi>
Message-ID: <YydLj8GKVmI/QWSb@cloudinit-builder>

Ah, that's interesting Oleg, thanks.  I like the idea of Cabal being
able to specify the exact mapping between modules and source files.

Tom

On Fri, Sep 16, 2022 at 04:05:53PM +0300, Oleg Grenrus wrote:
> That is error generated by GHC.
> 
> The culprit is `ghc --make` mode which discovers modules/files on its own.
> 
> If there were a way to say (for Cabal to GHC) that use these files to
> compile the component, and fail otherwise, then -Wmissing-home-modules
> would turn into error.
> 
> In fact, it would be great if it where possible to say that *this*
> module is in *that* file, something like `MyFoo:src/MyFoo.hs`.
> 
> That would also solve a problem of having same hs-source-dirs for
> different components, as Cabal would be able to tell GHC that "don't
> look for this modules locally, use dependencies". As currently GHC will
> eagerly look for modules locally first. Always.
> 
> - Oleg
> 
> On 16.9.2022 12.23, Tom Ellis wrote:
> > On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote:
> >> The cabal user guide says (in section 6.2.12): "Every module in the package
> >> must be listed in one of other-modules, library:exposed-modules or
> >> executable:main-is fields."
> >>
> >> However, I only get a warning message, when I comment out the other-modules
> >> field in my .cabal file. The program compiles. This is the message:
> >>
> >> <no location info>: warning: [-Wmissing-home-modules]
> >>     These modules are needed for compilation but not listed in your .cabal 
> >>     file's other-modules: 
> >>         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> >>
> >> Is it really necessary to specify all the imported modules? If so, why does
> >> the program compile? Can that warning message be turned off?
> > In response to all the sibling replies at once, is there a good reason
> > for this behaviour?  Succeeding but then failing later with obscure
> > errors (once the original warning message is nowhere to be seen) seems
> > like the worst of all worlds.  Suppose cabal errored here and failed
> > to proceed.  What would be the downside of that (besides backward
> > incompatibility)?

From P.Achten at cs.ru.nl  Mon Sep 19 17:59:24 2022
From: P.Achten at cs.ru.nl (Peter Achten)
Date: Mon, 19 Sep 2022 19:59:24 +0200
Subject: [Haskell-cafe] [TFP 2023 Call for Papers] 24th International
 Symposium on Trends in Functional Programming
Message-ID: <9a196c50-3ec5-f88b-1358-b2c95011e7b0@cs.ru.nl>

# TFP 2023 -- Call for Papers
(trendsfp.github.io)

## Important Dates

Submission deadline: pre-symposium, full papers,  Wednesday 23rd 
November, 2022
Submission deadline: pre-symposium, draft papers, Friday 16th December, 2022
Notification:        pre-symposium submissions,   Friday 23rd December, 2022
Registration:                                     Friday 6th January, 2023
TFPIE Workshop:                                   Thursday 12th January, 
2023
TFP Symposium:                                    Friday 13th - Sunday 
15th January, 2023
Submission deadline: post-symposium review,       Friday 17th February, 2023
Notification:        post-symposium submissions,  Friday 31st March, 2023

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.

This year, TFP will take place in-person at UMass Boston,
Massachusetts in the United States.  It is co-located with the Trends
in Functional Programming in Education (TFPIE) workshop, which will
take on the day before the main symposium.

Please be aware that TFP has several submission deadlines. The first,
November 23, is for authors that wish to have their full paper
reviewed prior to the symposium. Papers that are accepted in this way
must also be presented at the symposium. The second, December 16, is
for authors that wish to present their work or work-in progress at the
symposium first without submitting to the full review process for
publication. These authors can then take into account
feedback received at the symposium and submit a full article for
review by the third deadline, February 17.

## 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 2023 program chair, Stephen Chang.

## Best Paper Awards

TFP awards two prizes for the best papers each year.

First, to reward excellent contributions, TFP awards a prize for the best
overall paper accepted for the post-conference formal proceedings.

Second, a prize for the best student paper is awarded each year.
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.

In both cases, it is the PC of TFP that awards the prize. In case the
best paper happens to be a student paper, then that paper will receive
both prizes.


## Instructions to Authors

Papers must be submitted at:

   <https://easychair.org/conferences/?conf=tfp23>

Authors of papers have the choice of having their contributions
formally reviewed either before or after the Symposium.
Further, pre-symposium submissions may either be full (earlier deadline)
or draft papers (later deadline).

## Pre-symposium formal review

Papers to be formally reviewed before the symposium should be
submitted before the early deadline and will receive their reviews and
notification of acceptance for both presentation and publication
before the symposium. A paper that has been rejected for publication
but accepted for presentation may be resubmitted 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 receive
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

Peter Achten,              Radboud University Nijmegen, Netherlands
Nada Amin,                 Harvard University, USA
Ambrose Bonnaire-Sergeant, Untypable LLC, USA
Laura M. Castro,           University of A Coruña, Spain
Stephen Chang (Chair),     University of Massachusetts Boston, US
John Clements,             Cal Poly, USA
Youyou Cong,               Tokyo Institute of Technology, Japan
Paul Downen,               University of Massachusetts Lowell, USA
Kathy Gray,                Meta Platforms, Inc., UK
Ben Greenman,              University of Utah, USA
Jason Hemann,              Seton Hall University, USA
Patricia Johann,           Appalachian State University, USA
Alexis King,               Tweag, USA
Julia Lawall,              Inria-Paris, France
Barak Pearlmutter,         Maynooth University, Ireland
Norman Ramsey,             Tufts University, USA
Ilya Sergey,               National University of Singapore, Singapore
Melinda Tóth,              Eötvös Loránd University, Hungary
Ningning Xie,              University of Toronto, Canada


From a.pelenitsyn at gmail.com  Mon Sep 19 22:53:12 2022
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Mon, 19 Sep 2022 18:53:12 -0400
Subject: [Haskell-cafe] Cabal: other-modules necessary?
In-Reply-To: <YydLj8GKVmI/QWSb@cloudinit-builder>
References: <70a3d2404631c0c44255c9e8ce4cd30e9a3a2255.camel@volker-wysk.de>
 <YyRApvLiBNRMBVz/@cloudinit-builder>
 <ca1154c6-6974-acfe-f705-19646382a3b7@iki.fi>
 <YydLj8GKVmI/QWSb@cloudinit-builder>
Message-ID: <CAPKAvQWyF2=9infFuV5A-wfe_yWW35f=iyOEHCOf4hSbUSLvHQ@mail.gmail.com>

On the topic of cabal creating inconsistent environments: I keep seeing
these issues on SO and elsewhere.
This thread was the last drop for me, and I started an RFC over on cabal
bug tracker with a proposal to simply refuse to do the thing that is known
to fail.
https://github.com/haskell/cabal/issues/8483
Unfortunately, it's not going well so far. See if you have something to
contribute there.

--
Best, Artem

On Sun, 18 Sept 2022 at 12:47, Tom Ellis <
tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:

> Ah, that's interesting Oleg, thanks.  I like the idea of Cabal being
> able to specify the exact mapping between modules and source files.
>
> Tom
>
> On Fri, Sep 16, 2022 at 04:05:53PM +0300, Oleg Grenrus wrote:
> > That is error generated by GHC.
> >
> > The culprit is `ghc --make` mode which discovers modules/files on its
> own.
> >
> > If there were a way to say (for Cabal to GHC) that use these files to
> > compile the component, and fail otherwise, then -Wmissing-home-modules
> > would turn into error.
> >
> > In fact, it would be great if it where possible to say that *this*
> > module is in *that* file, something like `MyFoo:src/MyFoo.hs`.
> >
> > That would also solve a problem of having same hs-source-dirs for
> > different components, as Cabal would be able to tell GHC that "don't
> > look for this modules locally, use dependencies". As currently GHC will
> > eagerly look for modules locally first. Always.
> >
> > - Oleg
> >
> > On 16.9.2022 12.23, Tom Ellis wrote:
> > > On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote:
> > >> The cabal user guide says (in section 6.2.12): "Every module in the
> package
> > >> must be listed in one of other-modules, library:exposed-modules or
> > >> executable:main-is fields."
> > >>
> > >> However, I only get a warning message, when I comment out the
> other-modules
> > >> field in my .cabal file. The program compiles. This is the message:
> > >>
> > >> <no location info>: warning: [-Wmissing-home-modules]
> > >>     These modules are needed for compilation but not listed in your
> .cabal
> > >>     file's other-modules:
> > >>         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit
> > >>
> > >> Is it really necessary to specify all the imported modules? If so,
> why does
> > >> the program compile? Can that warning message be turned off?
> > > In response to all the sibling replies at once, is there a good reason
> > > for this behaviour?  Succeeding but then failing later with obscure
> > > errors (once the original warning message is nowhere to be seen) seems
> > > like the worst of all worlds.  Suppose cabal errored here and failed
> > > to proceed.  What would be the downside of that (besides backward
> > > incompatibility)?
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220919/9bd3ddc7/attachment.html>

From anthony.d.clayden at gmail.com  Tue Sep 20 01:19:21 2022
From: anthony.d.clayden at gmail.com (Anthony Clayden)
Date: Tue, 20 Sep 2022 13:19:21 +1200
Subject: [Haskell-cafe] Props to cpphs; why so little used?
Message-ID: <CABU_mxj1Rc=0AQOnZdc7mBCgViNGfLHENqNE4VFyEV=N2M1rhA@mail.gmail.com>

Thank you to the author and maintainers of cpphs
https://hackage.haskell.org/package/cpphs

It has tightly-focussed functionality for what I wanted to do: a more
haskell-friendly counterpart to cpp.

How to get it to behave as I wanted wasn't always obvious. I made some
notes  https://stackoverflow.com/a/73768057/2840542

Haskell libraries generally use cpp -- and then users complain how awkward
it can be. I don't see that cpp does anything better/different vs cpphs --
that is, cpphs understands all the #if compiler_version logic. Then why
isn't every library preferring cpphs?


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220920/91199848/attachment.html>

From allbery.b at gmail.com  Tue Sep 20 01:25:25 2022
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 19 Sep 2022 21:25:25 -0400
Subject: [Haskell-cafe] Props to cpphs; why so little used?
In-Reply-To: <CABU_mxj1Rc=0AQOnZdc7mBCgViNGfLHENqNE4VFyEV=N2M1rhA@mail.gmail.com>
References: <CABU_mxj1Rc=0AQOnZdc7mBCgViNGfLHENqNE4VFyEV=N2M1rhA@mail.gmail.com>
Message-ID: <CAKFCL4X9NTZWDV16qvaJhg2FxZHwCPDCBcNP+AEkx_TLkkC1yQ@mail.gmail.com>

Not everyone wants to be restricted to GPL, for one.

On Mon, Sep 19, 2022 at 9:19 PM Anthony Clayden
<anthony.d.clayden at gmail.com> wrote:
>
> Thank you to the author and maintainers of cpphs  https://hackage.haskell.org/package/cpphs
>
> It has tightly-focussed functionality for what I wanted to do: a more haskell-friendly counterpart to cpp.
>
> How to get it to behave as I wanted wasn't always obvious. I made some notes  https://stackoverflow.com/a/73768057/2840542
>
> Haskell libraries generally use cpp -- and then users complain how awkward it can be. I don't see that cpp does anything better/different vs cpphs -- that is, cpphs understands all the #if compiler_version logic. Then why isn't every library preferring cpphs?
>
>
> AntC
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From mikolaj at well-typed.com  Tue Sep 20 08:01:01 2022
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Tue, 20 Sep 2022 10:01:01 +0200
Subject: [Haskell-cafe] Props to cpphs; why so little used?
In-Reply-To: <CAKFCL4X9NTZWDV16qvaJhg2FxZHwCPDCBcNP+AEkx_TLkkC1yQ@mail.gmail.com>
References: <CABU_mxj1Rc=0AQOnZdc7mBCgViNGfLHENqNE4VFyEV=N2M1rhA@mail.gmail.com>
 <CAKFCL4X9NTZWDV16qvaJhg2FxZHwCPDCBcNP+AEkx_TLkkC1yQ@mail.gmail.com>
Message-ID: <CAHFo2urwDjPVdGbj3rs=kjSvz_9h6kgdSK7tUL2+TPUPDSuUAA@mail.gmail.com>

> Not everyone wants to be restricted to GPL, for one.

The license is GNU LGPL, not GNU GPL, so liberating your code
is optional, unless you actually copy and paste the code
of the library into your code. IANAL though.

From vamchale at gmail.com  Tue Sep 20 11:21:09 2022
From: vamchale at gmail.com (Vanessa McHale)
Date: Tue, 20 Sep 2022 07:21:09 -0400
Subject: [Haskell-cafe] Props to cpphs; why so little used?
In-Reply-To: <CABU_mxj1Rc=0AQOnZdc7mBCgViNGfLHENqNE4VFyEV=N2M1rhA@mail.gmail.com>
References: <CABU_mxj1Rc=0AQOnZdc7mBCgViNGfLHENqNE4VFyEV=N2M1rhA@mail.gmail.com>
Message-ID: <465CF025-04C2-433A-AF05-FC8B205582C6@gmail.com>

1. It doesn’t actually get used by Cabal (as of several years): https://github.com/haskell/cabal/issues/4278

2. cabal-install does cross-compilation + preprocessors wrong. By default using ghc as preprocessor works.

I think some of the reasons for using cpphs no longer apply (e.g. hugs on windows)

Cheers,
Vanessa McHale

> On Sep 19, 2022, at 9:19 PM, Anthony Clayden <anthony.d.clayden at gmail.com> wrote:
> 
> Thank you to the author and maintainers of cpphs  https://hackage.haskell.org/package/cpphs <https://hackage.haskell.org/package/cpphs>
> 
> It has tightly-focussed functionality for what I wanted to do: a more haskell-friendly counterpart to cpp.
> 
> How to get it to behave as I wanted wasn't always obvious. I made some notes  https://stackoverflow.com/a/73768057/2840542 <https://stackoverflow.com/a/73768057/2840542>
> 
> Haskell libraries generally use cpp -- and then users complain how awkward it can be. I don't see that cpp does anything better/different vs cpphs -- that is, cpphs understands all the #if compiler_version logic. Then why isn't every library preferring cpphs?
> 
> 
> AntC
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220920/3809bbd2/attachment.html>

From allbery.b at gmail.com  Tue Sep 20 11:58:17 2022
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 20 Sep 2022 07:58:17 -0400
Subject: [Haskell-cafe] Props to cpphs; why so little used?
In-Reply-To: <CAHFo2urwDjPVdGbj3rs=kjSvz_9h6kgdSK7tUL2+TPUPDSuUAA@mail.gmail.com>
References: <CABU_mxj1Rc=0AQOnZdc7mBCgViNGfLHENqNE4VFyEV=N2M1rhA@mail.gmail.com>
 <CAKFCL4X9NTZWDV16qvaJhg2FxZHwCPDCBcNP+AEkx_TLkkC1yQ@mail.gmail.com>
 <CAHFo2urwDjPVdGbj3rs=kjSvz_9h6kgdSK7tUL2+TPUPDSuUAA@mail.gmail.com>
Message-ID: <CAKFCL4WEC_VWMDYKTa1EPoYQZD6Uio9LOcLYYvWYXp-gvj9yRA@mail.gmail.com>

There are still corporate users who will not touch anything which has
been tainted by GPL/LGPL in any way. So you won't be seeing it used by
e.g. text.

On Tue, Sep 20, 2022 at 4:01 AM Mikolaj Konarski <mikolaj at well-typed.com> wrote:
>
> > Not everyone wants to be restricted to GPL, for one.
>
> The license is GNU LGPL, not GNU GPL, so liberating your code
> is optional, unless you actually copy and paste the code
> of the library into your code. IANAL though.



-- 
brandon s allbery kf8nh
allbery.b at gmail.com

From lysxia at gmail.com  Tue Sep 20 21:07:11 2022
From: lysxia at gmail.com (Li-yao Xia)
Date: Tue, 20 Sep 2022 22:07:11 +0100
Subject: [Haskell-cafe] What's different about quantified constraints since
	GHC 9.2?
Message-ID: <4e11fdc4-064a-1b57-16f5-4b06e5db0e1f@gmail.com>

Dear Café,

There's a trick [1] involving quantified constraints (and usually type 
families) where a function has a quantified constraint (forall a. CF a) 
and which is explicitly instantiated with a well-placed type annotation 
(_ :: CF x => ...). Since GHC 9.2, this trick works without that type 
annotation. How did GHC get smarter at instantiating this quantified 
constraint? Below is a minimized example which compiles on GHC 9.2.1 but 
not 9.0.1 (haven't tested 9.0.2), unless you uncomment the last line.

Cheers,
Li-yao

[1]: an Iceland_jack trick 
https://gitlab.haskell.org/ghc/ghc/-/issues/14860#note_151394


{-# LANGUAGE TypeFamilies, FlexibleInstances, FlexibleContexts, 
QuantifiedConstraints, ScopedTypeVariables #-}
module A where

type family F a
class C a
class C (F a) => CF a

f :: C (F a) => a
f = undefined

g :: (forall a. CF a) => a
g = f
   -- :: forall a. CF a => a  -- needed until GHC 9.0.1 but not GHC 
9.2.1 (and later)


From han.joosten.han at gmail.com  Thu Sep 22 08:26:12 2022
From: han.joosten.han at gmail.com (Han Joosten)
Date: Thu, 22 Sep 2022 10:26:12 +0200
Subject: [Haskell-cafe] How to diagnose a loop in a large Haskell program?
Message-ID: <CAKzCsfhVpwbuhzUFdtb7Ww6y3h7+iiMcJ7Bx_RwZ6pmk_9=5TQ@mail.gmail.com>

Hi,

I am struggling to debug a loop (some nontermination behaviour) of a huge
program. Normally, I use `stack build` to generate it. I have tried to use
`trace` at lots of places in the code, recompile and see what happens.
However, it isn't always clear in what order the trace statements are
fired, because of the lazy evaluation of Haskell.

So I tried another approach. I have a function

fatal :: HasCallStack => Text -> a
fatal msg =
  exitWith . Fatal . T.lines $
    ( msg <> "\n"
        <> (utf8BuilderToText . displayCallStackFull $ callStack)
    )

displayCallStackFull :: CallStack -> Utf8Builder
displayCallStackFull cs =
  case reverse $ getCallStack cs of
    [] -> "<no call stack found>"
    xs -> mconcat $ fmap showCall xs
  where
    showCall :: (String, SrcLoc) -> Utf8Builder
    showCall (desc, loc) =
      let file = srcLocFile loc
       in "\n"
            <> fromString file
            <> ":"
            <> displayShow (srcLocStartLine loc)
            <> ":"
            <> displayShow (srcLocStartCol loc)
            <> " "
            <> fromString desc


(The function to show the stack was inspired from
https://hackage.haskell.org/package/rio-0.1.22.0/docs/RIO.html#v:displayCallStack
).

I would expect that at any place where I force a call to `fatal`, I would
get the full stacktrace. Unfortunately, I only get the place where the call
to fatal is in the code.

I have been looking at the documentation of both stack and ghc, but I don't
understand how to compile my code in a way that the full stacktrace is
shown.

Until now the best guess I have is

stack install --profile --no-strip && ampersand -- check
testing/Sentinel/Tests/ShouldSucceed/OnlyValidation/Issue280.adl

The ultimate goal is to get rid of this ugly bug regarding the loop. Any
help/suggestions is really appreciated!

Thanks for reading.
Han Joosten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220922/0e2411fa/attachment.html>

From coplot at mail.com  Thu Sep 22 09:03:58 2022
From: coplot at mail.com (coplot coplot)
Date: Thu, 22 Sep 2022 11:03:58 +0200
Subject: [Haskell-cafe] monoid homomorphism
Message-ID: <trinity-5e41d251-42f6-413c-94d6-849a4145a0b9-1663837438339@3c-app-mailcom-lxa02>

An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220922/0105592b/attachment.html>

From dominik.schrempf at gmail.com  Thu Sep 22 09:03:56 2022
From: dominik.schrempf at gmail.com (Dominik Schrempf)
Date: Thu, 22 Sep 2022 11:03:56 +0200
Subject: [Haskell-cafe] How to diagnose a loop in a large Haskell
	program?
In-Reply-To: <CAKzCsfhVpwbuhzUFdtb7Ww6y3h7+iiMcJ7Bx_RwZ6pmk_9=5TQ@mail.gmail.com>
References: <CAKzCsfhVpwbuhzUFdtb7Ww6y3h7+iiMcJ7Bx_RwZ6pmk_9=5TQ@mail.gmail.com>
Message-ID: <87wn9v4vxm.fsf@gmail.com>


Han Joosten <han.joosten.han at gmail.com> writes:

> Hi,
>
> I am struggling to debug a loop (some nontermination behaviour) of a huge program. Normally, I use `stack build` to generate it. I have tried to use
> `trace` at lots of places in the code, recompile and see what happens. However, it isn't always clear in what order the trace statements are fired,
> because of the lazy evaluation of Haskell.
>
> So I tried another approach. I have a function
>
> fatal :: HasCallStack => Text -> a
> fatal msg =
>   exitWith . Fatal . T.lines $
>     ( msg <> "\n"
>         <> (utf8BuilderToText . displayCallStackFull $ callStack)
>     )
>
> displayCallStackFull :: CallStack -> Utf8Builder
> displayCallStackFull cs =
>   case reverse $ getCallStack cs of
>     [] -> "<no call stack found>"
>     xs -> mconcat $ fmap showCall xs
>   where
>     showCall :: (String, SrcLoc) -> Utf8Builder
>     showCall (desc, loc) =
>       let file = srcLocFile loc
>        in "\n"
>             <> fromString file
>             <> ":"
>             <> displayShow (srcLocStartLine loc)
>             <> ":"
>             <> displayShow (srcLocStartCol loc)
>             <> " "
>             <> fromString desc
>
> (The function to show the stack was inspired from https://hackage.haskell.org/package/rio-0.1.22.0/docs/RIO.html#v:displayCallStack).
>
> I would expect that at any place where I force a call to `fatal`, I would get the full stacktrace. Unfortunately, I only get the place where the call to
> fatal is in the code.

Hi.

Do the calling functions have call stack constraints?

Quoting from the GHC manual: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/callstack.html

"The call stack will only extend as far as the types allow it."

I think compilation with `--profile` (stack) or `--enable-profiling` (cabal-install) activates "simulated call-stacks" which seem to differ from the call stacks obtained by `HasCallStack`. Is this correct?

On a side note: I usually get a complete call stacks when compiling with `cabal build --enable-profiling`.

Dominik

>
> I have been looking at the documentation of both stack and ghc, but I don't understand how to compile my code in a way that the full stacktrace is
> shown.
>
> Until now the best guess I have is
>
> stack install --profile --no-strip && ampersand -- check testing/Sentinel/Tests/ShouldSucceed/OnlyValidation/Issue280.adl
>
> The ultimate goal is to get rid of this ugly bug regarding the loop. Any help/suggestions is really appreciated!
>
> Thanks for reading.
> Han Joosten
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

From dominik.schrempf at gmail.com  Thu Sep 22 09:51:35 2022
From: dominik.schrempf at gmail.com (Dominik Schrempf)
Date: Thu, 22 Sep 2022 11:51:35 +0200
Subject: [Haskell-cafe] How to diagnose a loop in a large Haskell
	program?
In-Reply-To: <87wn9v4vxm.fsf@gmail.com>
References: <CAKzCsfhVpwbuhzUFdtb7Ww6y3h7+iiMcJ7Bx_RwZ6pmk_9=5TQ@mail.gmail.com>
 <87wn9v4vxm.fsf@gmail.com>
Message-ID: <87sfkj4tya.fsf@gmail.com>

I just noticed, maybe you are interested in the `-xc` runtime system
option? This option can be activated when compiling with profiling
support. See here:

https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--xc

Dominik

Dominik Schrempf <dominik.schrempf at gmail.com> writes:

> Han Joosten <han.joosten.han at gmail.com> writes:
>
>> Hi,
>>
>> I am struggling to debug a loop (some nontermination behaviour) of a huge program. Normally, I use `stack build` to generate it. I have tried to use
>> `trace` at lots of places in the code, recompile and see what happens. However, it isn't always clear in what order the trace statements are fired,
>> because of the lazy evaluation of Haskell.
>>
>> So I tried another approach. I have a function
>>
>> fatal :: HasCallStack => Text -> a
>> fatal msg =
>>   exitWith . Fatal . T.lines $
>>     ( msg <> "\n"
>>         <> (utf8BuilderToText . displayCallStackFull $ callStack)
>>     )
>>
>> displayCallStackFull :: CallStack -> Utf8Builder
>> displayCallStackFull cs =
>>   case reverse $ getCallStack cs of
>>     [] -> "<no call stack found>"
>>     xs -> mconcat $ fmap showCall xs
>>   where
>>     showCall :: (String, SrcLoc) -> Utf8Builder
>>     showCall (desc, loc) =
>>       let file = srcLocFile loc
>>        in "\n"
>>             <> fromString file
>>             <> ":"
>>             <> displayShow (srcLocStartLine loc)
>>             <> ":"
>>             <> displayShow (srcLocStartCol loc)
>>             <> " "
>>             <> fromString desc
>>
>> (The function to show the stack was inspired from https://hackage.haskell.org/package/rio-0.1.22.0/docs/RIO.html#v:displayCallStack).
>>
>> I would expect that at any place where I force a call to `fatal`, I would get the full stacktrace. Unfortunately, I only get the place where the call to
>> fatal is in the code.
>
> Hi.
>
> Do the calling functions have call stack constraints?
>
> Quoting from the GHC manual: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/callstack.html
>
> "The call stack will only extend as far as the types allow it."
>
> I think compilation with `--profile` (stack) or `--enable-profiling` (cabal-install) activates "simulated call-stacks" which seem to differ from the call stacks obtained by `HasCallStack`. Is this correct?
>
> On a side note: I usually get a complete call stacks when compiling with `cabal build --enable-profiling`.
>
> Dominik
>
>>
>> I have been looking at the documentation of both stack and ghc, but I don't understand how to compile my code in a way that the full stacktrace is
>> shown.
>>
>> Until now the best guess I have is
>>
>> stack install --profile --no-strip && ampersand -- check testing/Sentinel/Tests/ShouldSucceed/OnlyValidation/Issue280.adl
>>
>> The ultimate goal is to get rid of this ugly bug regarding the loop. Any help/suggestions is really appreciated!
>>
>> Thanks for reading.
>> Han Joosten
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.

From lysxia at gmail.com  Thu Sep 22 10:49:15 2022
From: lysxia at gmail.com (Li-yao Xia)
Date: Thu, 22 Sep 2022 11:49:15 +0100
Subject: [Haskell-cafe] monoid homomorphism
In-Reply-To: <trinity-5e41d251-42f6-413c-94d6-849a4145a0b9-1663837438339@3c-app-mailcom-lxa02>
References: <trinity-5e41d251-42f6-413c-94d6-849a4145a0b9-1663837438339@3c-app-mailcom-lxa02>
Message-ID: <42476898-3096-5c1d-130a-3914a76182e0@gmail.com>

Hi Co,

(This email in a gist in case the ASCII art below gets lost in 
translation https://gist.github.com/Lysxia/d81abf4e35e8094df0a92ec5ff1467da)

Categorically, we prefer looking at a monoid (Z, 1, (*)) as a pair of morphisms (functions in Set) (const 1 : () -> Z) and (uncurry (*) : Z x Z -> Z).
A monoid homomorphism is_odd : Z -> B is a morphism which makes the following diagrams commute:

            const 1
      () ------------> Z
      |                |
   id |                | is_odd
      |                |
      v                v
      () ------------> B
          const True

                          (*)
                 Z x Z ---------> Z
                   |              |
is_odd *** is_odd |              | is_odd
                   |              |
                   v              v
                 B x B ---------> B
                         (&&)

Cheers,
Li-yao


On 2022-09-22 10:03 AM, coplot coplot wrote:
Hello every one,
I'm reading "Programming with Categories Brendan Fong Bartosz Milewski 
David I. Spivak"
and here there's an example of monoid in Haskell:

/Consider the monoidsZ×�(Z,1,×)andBAND�(B,true,AND).Let
is_odd:Z→Bbe the function that sends odd numbers totrueand even numbers to
false. This is a monoid homomorphism. It preserves identities because1is 
odd, and
it preserves composition because the product of any two odd numbers is 
odd, but the
product of anything with an even number is even./


I'd like representing it graphically I mean the object Zx and arrows 
about is_odd function,
but I do not know how can do it.

This is a valid example of monoid homomorphism and I'd like to know
the Haskell implementation and the corresponding categorically view.

Thanks
Co

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220922/d269463b/attachment.html>

From han.joosten.han at gmail.com  Thu Sep 22 17:11:10 2022
From: han.joosten.han at gmail.com (Han Joosten)
Date: Thu, 22 Sep 2022 19:11:10 +0200
Subject: [Haskell-cafe] How to diagnose a loop in a large Haskell
	program?
In-Reply-To: <87sfkj4tya.fsf@gmail.com>
References: <CAKzCsfhVpwbuhzUFdtb7Ww6y3h7+iiMcJ7Bx_RwZ6pmk_9=5TQ@mail.gmail.com>
 <87wn9v4vxm.fsf@gmail.com> <87sfkj4tya.fsf@gmail.com>
Message-ID: <CAKzCsfirU79pNfGTK78yprBHTqBUzk_vrFRM0dFw8pX=OrOCow@mail.gmail.com>

Thanks for the pointers. I never realized that "simulated call-stack" could
be something different than the HasCallStack stuff. When I used the
following command, I get the callstack info I was looking for:

stack install --profile --no-strip --ghc-options -fprof-auto-calls &&
ampersand -- check
testing/Sentinel/Tests/ShouldSucceed/OnlyValidation/Issue280.adl

I hope this will help me to find the loop.

Op do 22 sep. 2022 om 11:52 schreef Dominik Schrempf <
dominik.schrempf at gmail.com>:

> I just noticed, maybe you are interested in the `-xc` runtime system
> option? This option can be activated when compiling with profiling
> support. See here:
>
>
> https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--xc
>
> Dominik
>
> Dominik Schrempf <dominik.schrempf at gmail.com> writes:
>
> > Han Joosten <han.joosten.han at gmail.com> writes:
> >
> >> Hi,
> >>
> >> I am struggling to debug a loop (some nontermination behaviour) of a
> huge program. Normally, I use `stack build` to generate it. I have tried to
> use
> >> `trace` at lots of places in the code, recompile and see what happens.
> However, it isn't always clear in what order the trace statements are fired,
> >> because of the lazy evaluation of Haskell.
> >>
> >> So I tried another approach. I have a function
> >>
> >> fatal :: HasCallStack => Text -> a
> >> fatal msg =
> >>   exitWith . Fatal . T.lines $
> >>     ( msg <> "\n"
> >>         <> (utf8BuilderToText . displayCallStackFull $ callStack)
> >>     )
> >>
> >> displayCallStackFull :: CallStack -> Utf8Builder
> >> displayCallStackFull cs =
> >>   case reverse $ getCallStack cs of
> >>     [] -> "<no call stack found>"
> >>     xs -> mconcat $ fmap showCall xs
> >>   where
> >>     showCall :: (String, SrcLoc) -> Utf8Builder
> >>     showCall (desc, loc) =
> >>       let file = srcLocFile loc
> >>        in "\n"
> >>             <> fromString file
> >>             <> ":"
> >>             <> displayShow (srcLocStartLine loc)
> >>             <> ":"
> >>             <> displayShow (srcLocStartCol loc)
> >>             <> " "
> >>             <> fromString desc
> >>
> >> (The function to show the stack was inspired from
> https://hackage.haskell.org/package/rio-0.1.22.0/docs/RIO.html#v:displayCallStack
> ).
> >>
> >> I would expect that at any place where I force a call to `fatal`, I
> would get the full stacktrace. Unfortunately, I only get the place where
> the call to
> >> fatal is in the code.
> >
> > Hi.
> >
> > Do the calling functions have call stack constraints?
> >
> > Quoting from the GHC manual:
> https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/callstack.html
> >
> > "The call stack will only extend as far as the types allow it."
> >
> > I think compilation with `--profile` (stack) or `--enable-profiling`
> (cabal-install) activates "simulated call-stacks" which seem to differ from
> the call stacks obtained by `HasCallStack`. Is this correct?
> >
> > On a side note: I usually get a complete call stacks when compiling with
> `cabal build --enable-profiling`.
> >
> > Dominik
> >
> >>
> >> I have been looking at the documentation of both stack and ghc, but I
> don't understand how to compile my code in a way that the full stacktrace is
> >> shown.
> >>
> >> Until now the best guess I have is
> >>
> >> stack install --profile --no-strip && ampersand -- check
> testing/Sentinel/Tests/ShouldSucceed/OnlyValidation/Issue280.adl
> >>
> >> The ultimate goal is to get rid of this ugly bug regarding the loop.
> Any help/suggestions is really appreciated!
> >>
> >> Thanks for reading.
> >> Han Joosten
> >>
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> To (un)subscribe, modify options or view archives go to:
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220922/32794e13/attachment.html>

From mail at joachim-breitner.de  Thu Sep 22 17:56:12 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 22 Sep 2022 19:56:12 +0200
Subject: [Haskell-cafe] Can this be made to fuse?
In-Reply-To: <CAMgWh9vRJHW2VJMg2WnSw3UmXfzNwuMzm1taZXuoyb=EWD0vbw@mail.gmail.com>
References: <CAMgWh9vRJHW2VJMg2WnSw3UmXfzNwuMzm1taZXuoyb=EWD0vbw@mail.gmail.com>
Message-ID: <fd5b6f4dd8d570d6d6d043dd9f03a6cc58440bcb.camel@joachim-breitner.de>

Hi,

Am Sonntag, dem 11.09.2022 um 19:05 -0400 schrieb David Feuer:
> The template-haskell package has functions `tupE` and `tupP` for
> building tuple expressions and patterns, respectively, but nothing
> really similar for building tuple types. I came up with the version
> below the other day:
> 
> -- | Given a list of types, produce the type of a tuple of
> -- those types. This is analogous to 'tupE' and 'tupP'.
> --
> -- @
> -- tupT [[t|Int|], [t|Char|], [t|Bool]] = [t| (Int, Char, Bool) |]
> -- @
> tupT :: [Q Type] -> Q Type
> tupT ts = n `seq` res
>   where
>     -- We build the expression with a thunk inside that will be filled in with
>     -- the length of the list once that's been determined. This works
>     -- efficiently (in one pass) because TH.Type is rather lazy.
>     (res, n) = foldl' (\(acc, !k) ty -> ([t| $acc $ty |], k + 1))
>                       (tupleT n, 0)
>                       ts
> 
> I strongly suspect this is quite fast enough in practice, but it's a
> bit annoying that it won't participate in list fusion; tupT (map f xs)
> will (lazily) generate an intermediate list. I wasn't able to convince
> GHC to fuse it, short of a custom rewrite rule or two (tupT (build f)
> = ..., tupT (augment f r = ...). Does anyone know if it's possible?

Can you say why it would not fuse? It seems it could, if tupT inlines,
and then you have foldl' applied to (map f xs), and at this point I
would hope that fusion kicks in.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From david.feuer at gmail.com  Thu Sep 22 18:13:53 2022
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 22 Sep 2022 14:13:53 -0400
Subject: [Haskell-cafe] Can this be made to fuse?
In-Reply-To: <fd5b6f4dd8d570d6d6d043dd9f03a6cc58440bcb.camel@joachim-breitner.de>
References: <CAMgWh9vRJHW2VJMg2WnSw3UmXfzNwuMzm1taZXuoyb=EWD0vbw@mail.gmail.com>
 <fd5b6f4dd8d570d6d6d043dd9f03a6cc58440bcb.camel@joachim-breitner.de>
Message-ID: <CAMgWh9uBqbFDEaAuv6xyn0LPRuYFdnAUDJ3H=BFGhN=5dSG1VA@mail.gmail.com>

The recursion is the first barrier. The whole thing ends up a loop breaker.
Using `fix` fixes that, but it still doesn't fuse for some reason. After I
sent this, I realized that foldl' is really the wrong thing, since that
builds up a large Q action that, when run, produces the expression. The
nicer thing is to use foldM within Q, and wrap mfix around that. I'm still
not seeing fusion with that, and I wonder if that's because of the
complexity of the Q type with its higher-rank constrained polymorphism and
such.

On Thu, Sep 22, 2022, 1:56 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Sonntag, dem 11.09.2022 um 19:05 -0400 schrieb David Feuer:
> > The template-haskell package has functions `tupE` and `tupP` for
> > building tuple expressions and patterns, respectively, but nothing
> > really similar for building tuple types. I came up with the version
> > below the other day:
> >
> > -- | Given a list of types, produce the type of a tuple of
> > -- those types. This is analogous to 'tupE' and 'tupP'.
> > --
> > -- @
> > -- tupT [[t|Int|], [t|Char|], [t|Bool]] = [t| (Int, Char, Bool) |]
> > -- @
> > tupT :: [Q Type] -> Q Type
> > tupT ts = n `seq` res
> >   where
> >     -- We build the expression with a thunk inside that will be filled
> in with
> >     -- the length of the list once that's been determined. This works
> >     -- efficiently (in one pass) because TH.Type is rather lazy.
> >     (res, n) = foldl' (\(acc, !k) ty -> ([t| $acc $ty |], k + 1))
> >                       (tupleT n, 0)
> >                       ts
> >
> > I strongly suspect this is quite fast enough in practice, but it's a
> > bit annoying that it won't participate in list fusion; tupT (map f xs)
> > will (lazily) generate an intermediate list. I wasn't able to convince
> > GHC to fuse it, short of a custom rewrite rule or two (tupT (build f)
> > = ..., tupT (augment f r = ...). Does anyone know if it's possible?
>
> Can you say why it would not fuse? It seems it could, if tupT inlines,
> and then you have foldl' applied to (map f xs), and at this point I
> would hope that fusion kicks in.
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220922/74b94570/attachment.html>

From mail at joachim-breitner.de  Thu Sep 22 19:12:52 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 22 Sep 2022 19:12:52 +0000 (UTC)
Subject: [Haskell-cafe] Can this be made to fuse?
In-Reply-To: <CAMgWh9uBqbFDEaAuv6xyn0LPRuYFdnAUDJ3H=BFGhN=5dSG1VA@mail.gmail.com>
References: <CAMgWh9vRJHW2VJMg2WnSw3UmXfzNwuMzm1taZXuoyb=EWD0vbw@mail.gmail.com>
 <fd5b6f4dd8d570d6d6d043dd9f03a6cc58440bcb.camel@joachim-breitner.de>
 <CAMgWh9uBqbFDEaAuv6xyn0LPRuYFdnAUDJ3H=BFGhN=5dSG1VA@mail.gmail.com>
Message-ID: <0aaa6319-bd8f-40f7-98c3-dc1380a6d0ca@joachim-breitner.de>

A simple composition of a pure [Type] -> Type function, fmap'ped and Control.Monad.sequence is not going to help, is it? At least the sequence might fuse with a producer, not sure if the fmap then gets in the way to fuse with the pure function though.

22.09.2022 20:14:20 David Feuer <david.feuer at gmail.com>:

> The recursion is the first barrier. The whole thing ends up a loop breaker. Using `fix` fixes that, but it still doesn't fuse for some reason. After I sent this, I realized that foldl' is really the wrong thing, since that builds up a large Q action that, when run, produces the expression. The nicer thing is to use foldM within Q, and wrap mfix around that. I'm still not seeing fusion with that, and I wonder if that's because of the complexity of the Q type with its higher-rank constrained polymorphism and such.
> 
> On Thu, Sep 22, 2022, 1:56 PM Joachim Breitner <mail at joachim-breitner.de> wrote:
>> Hi,
>> 
>> Am Sonntag, dem 11.09.2022 um 19:05 -0400 schrieb David Feuer:
>>> The template-haskell package has functions `tupE` and `tupP` for
>>> building tuple expressions and patterns, respectively, but nothing
>>> really similar for building tuple types. I came up with the version
>>> below the other day:
>>>
>>> -- | Given a list of types, produce the type of a tuple of
>>> -- those types. This is analogous to 'tupE' and 'tupP'.
>>> --
>>> -- @
>>> -- tupT [[t|Int|], [t|Char|], [t|Bool]] = [t| (Int, Char, Bool) |]
>>> -- @
>>> tupT :: [Q Type] -> Q Type
>>> tupT ts = n `seq` res
>>>   where
>>>     -- We build the expression with a thunk inside that will be filled in with
>>>     -- the length of the list once that's been determined. This works
>>>     -- efficiently (in one pass) because TH.Type is rather lazy.
>>>     (res, n) = foldl' (\(acc, !k) ty -> ([t| $acc $ty |], k + 1))
>>>                       (tupleT n, 0)
>>>                       ts
>>>
>>> I strongly suspect this is quite fast enough in practice, but it's a
>>> bit annoying that it won't participate in list fusion; tupT (map f xs)
>>> will (lazily) generate an intermediate list. I wasn't able to convince
>>> GHC to fuse it, short of a custom rewrite rule or two (tupT (build f)
>>> = ..., tupT (augment f r = ...). Does anyone know if it's possible?
>> 
>> Can you say why it would not fuse? It seems it could, if tupT inlines,
>> and then you have foldl' applied to (map f xs), and at this point I
>> would hope that fusion kicks in.
>> 
>> Cheers,
>> Joachim
>> 
>> -- 
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> 
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220922/60604eb8/attachment.html>

From olf at aatal-apotheke.de  Thu Sep 22 19:32:17 2022
From: olf at aatal-apotheke.de (Olaf Klinke)
Date: Thu, 22 Sep 2022 21:32:17 +0200
Subject: [Haskell-cafe] monoid homomorphism
Message-ID: <5f1c6b582439bc6fc67ef7ad4cdb9e9d381f6d47.camel@aatal-apotheke.de>

> Hello every one,
> I'm reading "Programming with Categories Brendan Fong Bartosz Milewski David I. Spivak"
> and here there's an example of monoid in Haskell:
> 
> Consider the monoids Z× � (Z, 1, ×) and BAND � (B, true, AND). Let
> is_odd : Z → B be the function that sends odd numbers to true and even numbers to
> false. This is a monoid homomorphism. It preserves identities because 1 is odd, and
> it preserves composition because the product of any two odd numbers is odd, but the
> product of anything with an even number is even.
> 
> 
> I'd like representing it graphically I mean the object Zx and arrows about is_odd function,
> but I do not know how can do it.
> 
> This is a valid example of monoid homomorphism and I'd like to know
> the Haskell implementation and the corresponding categorically view.
> 
> Thanks
> Co

Extending Li-yao's excellent answer, you could draw a single diagram
using the free monoid monad. Disregarding non-termination and infinite
lists, the free monoid is the list monad [*]. Every monoid has a
structure map, namely 
    mconcat :: Monoid m => [m] -> m
satisfying equations (2) and (3) below. A function h :: z -> b between
monoids is a monoid homomorphism iff it commutes with the structure
map: 
    h . mconcat = mconcat . fmap f               (1)
   
     mconcat
[Z] ---------> Z
 |             |
 | fmap h      | h
 |             |
 v             v
[B] ---------> B
     mconcat

This commutative square subsumes Li-yao's two squares. Instantiate the
equation (1) with empty and two-element lists to recover Li-yao's
squares, where 
    mconcat []    = mempty,
    mconcat [x,y] = x `mappend` y.
In "Programming with Categories" terminology: Monoid homomorphisms are
[]-Algebra homomorphisms (Definition 4.9). What is not contained in
"Programming with Categories" are the Eilenberg-Moore algebra laws.
Namely, 
    mconcat . pure   = id                        (2)
    mconcat . concat = mconcat . fmap mconcat    (3)

See also chapters in 6 and 7 in [1]. There, the example is linear
functions between vector spaces, which are algebra homomorphisms of the
monad of formal linear combinations. 

Olaf

[*] Mathematically, the free monoid over a set A is the set of finite
words in the alphabet A, with the empty word as 'mempty' and
concatenation of words as 'mappend'. E.g. the free monoid over Char is
Text. 
[1] https://hub.darcs.net/olf/haskell_for_mathematicians


From david.feuer at gmail.com  Thu Sep 22 20:09:51 2022
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 22 Sep 2022 16:09:51 -0400
Subject: [Haskell-cafe] Can this be made to fuse?
In-Reply-To: <0aaa6319-bd8f-40f7-98c3-dc1380a6d0ca@joachim-breitner.de>
References: <CAMgWh9vRJHW2VJMg2WnSw3UmXfzNwuMzm1taZXuoyb=EWD0vbw@mail.gmail.com>
 <fd5b6f4dd8d570d6d6d043dd9f03a6cc58440bcb.camel@joachim-breitner.de>
 <CAMgWh9uBqbFDEaAuv6xyn0LPRuYFdnAUDJ3H=BFGhN=5dSG1VA@mail.gmail.com>
 <0aaa6319-bd8f-40f7-98c3-dc1380a6d0ca@joachim-breitner.de>
Message-ID: <CAMgWh9tz89uDuLDuWASWitFTW88sVASy12QmYDGTZfD4f+9X2Q@mail.gmail.com>

sequence never helps anyone with anything, optimization-wise. I should
double check that I wasn't working in a weird compilation environment or
something when I checked the most recent version. GHC doesn't like to fire
rules that might duplicate work, and Q may well be too general on the
inside for the compiler to be able to tell. Do those Q things *ever* get
specialized? If so, to what, and when?

On Thu, Sep 22, 2022, 3:12 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> A simple composition of a pure [Type] -> Type function, fmap'ped and
> Control.Monad.sequence is not going to help, is it? At least the sequence
> might fuse with a producer, not sure if the fmap then gets in the way to
> fuse with the pure function though.
>
> 22.09.2022 20:14:20 David Feuer <david.feuer at gmail.com>:
>
> The recursion is the first barrier. The whole thing ends up a loop
> breaker. Using `fix` fixes that, but it still doesn't fuse for some reason.
> After I sent this, I realized that foldl' is really the wrong thing, since
> that builds up a large Q action that, when run, produces the expression.
> The nicer thing is to use foldM within Q, and wrap mfix around that. I'm
> still not seeing fusion with that, and I wonder if that's because of the
> complexity of the Q type with its higher-rank constrained polymorphism and
> such.
>
> On Thu, Sep 22, 2022, 1:56 PM Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Sonntag, dem 11.09.2022 um 19:05 -0400 schrieb David Feuer:
>> > The template-haskell package has functions `tupE` and `tupP` for
>> > building tuple expressions and patterns, respectively, but nothing
>> > really similar for building tuple types. I came up with the version
>> > below the other day:
>> >
>> > -- | Given a list of types, produce the type of a tuple of
>> > -- those types. This is analogous to 'tupE' and 'tupP'.
>> > --
>> > -- @
>> > -- tupT [[t|Int|], [t|Char|], [t|Bool]] = [t| (Int, Char, Bool) |]
>> > -- @
>> > tupT :: [Q Type] -> Q Type
>> > tupT ts = n `seq` res
>> >   where
>> >     -- We build the expression with a thunk inside that will be filled
>> in with
>> >     -- the length of the list once that's been determined. This works
>> >     -- efficiently (in one pass) because TH.Type is rather lazy.
>> >     (res, n) = foldl' (\(acc, !k) ty -> ([t| $acc $ty |], k + 1))
>> >                       (tupleT n, 0)
>> >                       ts
>> >
>> > I strongly suspect this is quite fast enough in practice, but it's a
>> > bit annoying that it won't participate in list fusion; tupT (map f xs)
>> > will (lazily) generate an intermediate list. I wasn't able to convince
>> > GHC to fuse it, short of a custom rewrite rule or two (tupT (build f)
>> > = ..., tupT (augment f r = ...). Does anyone know if it's possible?
>>
>> Can you say why it would not fuse? It seems it could, if tupT inlines,
>> and then you have foldl' applied to (map f xs), and at this point I
>> would hope that fusion kicks in.
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220922/b1f60d51/attachment.html>

From kbh at umn.edu  Fri Sep 23 16:00:00 2022
From: kbh at umn.edu (Favonia)
Date: Fri, 23 Sep 2022 11:00:00 -0500
Subject: [Haskell-cafe] PLMW@POPL 2023: Call For Scholarship Applications
	(DEADLINE: 10/14 AoE)
Message-ID: <CAH_+rvcaV=BxS2NQ+kaX2hqbjDhTNuxM1T_ap++PNuXY_o678Q@mail.gmail.com>

CALL FOR SCHOLARSHIP APPLICATIONS

*DEADLINE: 14 October 2022, 23:59 AoE* (Anywhere on Earth)


ACM SIGPLAN Programming Languages Mentoring Workshop

Location: Boston, Massachusetts, USA

Date: Tuesday, January 17, 2023

Web page: https://popl23.sigplan.org/home/PLMW-POPL-2023

Following the success of the first eleven Programming Languages Mentoring
Workshops at POPL 2012-2022, we are pleased to announce the 12th SIGPLAN
Programming Languages Mentoring Workshop (PLMW), co-located with POPL 2023
and organized by Hannah Gommerstadt, Michael Greenberg, Kuen-Bang Hou
(Favonia), and Robbert Krebbers. The workshop will take place *in person*
in Boston.

PLMW aims to encourage graduate students and senior undergraduate students
to pursue careers in programming language (PL) research. This workshop will
bring together world leaders in PL research and teaching from both academia
and industry to provide (a) technical sessions on cutting-edge PL research
and (b) mentoring sessions on how to prepare for a research career. The
workshop will help students imagine how they might contribute to our
vibrant and thriving research community.

We especially encourage women, members of underrepresented minorities, and
people with disabilities to attend PLMW.

This workshop is part of the activities surrounding POPL, the Symposium on
Principles of Programming Languages, and takes place the day before the
main conference. One goal of the workshop is to make the POPL conference
more accessible to newcomers. We hope that participants will stay for the
whole conference.

A number of sponsors (listed below) have generously donated scholarship
funds for qualified students to attend PLMW. These scholarships can cover
expenses (airfare, hotel, and registration fees) for attendance at both the
workshop and the POPL conference itself. The workshop registration is open
to all (with or without scholarships). Students with alternative sources of
funding are welcome as well.

APPLICATION FOR PLMW SCHOLARSHIP

The application form can be accessed at the following URL:

https://forms.gle/Ct19QcsKjSLoE38B9

The deadline for full consideration of funding is *14 October 2022, 23:59
AoE.*

Confirmed sponsors so far:

   -

   NSF
   -

   ACM SIGPLAN
   -

   Jane Street
   -

   Galois
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220923/36d82b27/attachment.html>

From jonathan.protzenko at gmail.com  Mon Sep 26 16:03:23 2022
From: jonathan.protzenko at gmail.com (Jonathan Protzenko)
Date: Mon, 26 Sep 2022 09:03:23 -0700
Subject: [Haskell-cafe] ProLaLa 2023 -- Programming Languages and the Law
 (Jan 15th 2023, Boston) : Deadline Oct 27th 2022
Message-ID: <ca0df68e-4086-b5e2-eaaa-8a3d31779e82@gmail.com>

-----------------------------------------------------------------------------------------

    ProLaLa 2023 -- 2nd Workshop on Programming Languages and the Law

                                              Sunday Jan 15th, 2022
                                                        Boston, MA
                                           co-located with POPL 2023

------------------------------------------------------------------------------------------

                   (please forward to anyone who might be interested!)


We are pleased to announce ProLaLa'23, the second edition of the 
workshop concerned with the intersection of PL (Programming Languages) 
techniques and the law. We are particularly concerned with the following 
topics:

- language design for legal matters;
- static analysis of legal texts;
- program synthesis and repair for legal software components;
- formal modeling of legal semantics;
- non-standard logics in support of legal reasoning;
- program verification for legal expert systems.

If you have explored any of these areas, we encourage you to submit a 
short abstract. We are hoping to solidify around this workshop what we 
believe is a nascent but growing community; last year we had 25 
submissions and 60 participants. As such, the workshop will be informal, 
and we strongly encourage you to submit ongoing or already-published 
work in the form of a brief 5-page submission for a long talk, or a 
2-page submission for a short talk.

Full details: 
https://popl23.sigplan.org/home/prolala-2023#Call-for-Papers 
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpopl23.sigplan.org%2Fhome%2Fprolala-2023%23Call-for-Papers&data=05%7C01%7Cprotz%40microsoft.com%7C5cf24d61b74c4a17e56c08da8e8a6115%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637979022249602967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NG2V3zL41wot9uwncAQh9v%2B5DtOTvU9r%2F6sr26whF2k%3D&reserved=0>


      Venue

ProLaLa will be colocated with POPL'23. We plan to coordinate with the 
POPL conference on remote participation. We would like to have remote 
participation even if the workshop happens in person. Our plan is to 
create an inclusive environment that does not demand traveling for 
COVID-19 (or other) reasons.


      Submission details

We accept two kinds of submissions.
- Long talks: 5 pages excluding references
- Short talks: 2 page excluding references

We require using SIGPLAN's one-column LaTeX format (acmsmall).

Submission site: https://prolala23.hotcrp.com 
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprolala23.hotcrp.com%2F&data=05%7C01%7Cprotz%40microsoft.com%7C5cf24d61b74c4a17e56c08da8e8a6115%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637979022249602967%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ni5y%2Fg82caYoCUNlUGF8uO9CGHMX5IwhOWNPVZlGDYU%3D&reserved=0>


      Important dates

- Thu 27 Oct 2022: Submission deadline
- Thu 10 Nov 2022: Notification of acceptance
- Sun 15 Jan 2023: Workshop


      Program committee

- Shrutarshi Basu (co-chair), Middlebury College, USA
- Denis Merigoux (co-chair), Inria, France
- Jonathan Protzenko (co-chair), Microsoft Research, USA
- Timos Antonopoulos, Yale, USA
- Joaquín Arias, Universidad Rey Juan Carlos, Spain
- James Grimmelman, Cornell, USA
- Ekaterina Komandantskaya, Herriot-Watts University, UK
- Emma Tosch, University of Michigan, USA
- Saeid Tizpaz-Niari, University of Texas at El Paso, USA
- Giovanni Sileno, University of Amsterdam, Netherlands
- Chris Bailey, University of Illinois, USA
- Laurence Diver, Vrije Universiteit Brussel, Belgium
- Sarah Lawsky, Northwestern Pritzker School of Law, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220926/57891b36/attachment.html>

From trupill at gmail.com  Mon Sep 26 17:19:31 2022
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 26 Sep 2022 10:19:31 -0700
Subject: [Haskell-cafe] Haskell courses @ 47 Degrees Academy
Message-ID: <CAHnFXOuyEj6npMziS_r99w=0jP7f6WEQUJyYuhD+MV-Q1Gs4gQ@mail.gmail.com>

Dear all,
I’m happy to announce that we’ve released four video courses about
different topics in Haskell, at
https://academy.47deg.com/collections/haskell

   - Introduction to optics (beginner)
   - Discovering functors, monads, and applicative (beginner)
   - Type level programming (intermediate)
   - Generic programming (advanced)


As far as I know, this is some of the first content in video about the more
advanced techniques in the language, like data type promotion or constraint
kinds.

I hope you all enjoy it! We're happy to hear any feedback from you :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220926/9002f184/attachment.html>

From leah at vuxu.org  Mon Sep 26 20:56:37 2022
From: leah at vuxu.org (Leah Neukirchen)
Date: Mon, 26 Sep 2022 22:56:37 +0200
Subject: [Haskell-cafe] Munich Haskell Meeting, 2022-09-29 @ 19:30
Message-ID: <87pmfhkg6y.fsf@vuxu.org>

Dear all,

This week, our monthly Munich Haskell Meeting will take place again on
Thursday, September 29 at Cafe Puck(!) at 19h30. For details see here:

http://muenchen.haskell.bayern/dates.html

If you plan to join, please add yourself to this nuudel so we can
reserve enough seats!  It is OK to add yourself to the nuddel
anonymously or pseudonymously.

https://nuudel.digitalcourage.de/AtDC1Gfm99791KZ8

Everybody is welcome!

cu,
-- 
Leah Neukirchen  <leah at vuxu.org>  https://leahneukirchen.org/

From ruben.astud at gmail.com  Tue Sep 27 16:36:36 2022
From: ruben.astud at gmail.com (Ruben Astudillo)
Date: Tue, 27 Sep 2022 13:36:36 -0300
Subject: [Haskell-cafe] Obtain cost-centers stacks from eventlog file
Message-ID: <0c741cd4-0bdf-345f-3c3b-c1c58352a953@gmail.com>

Hello -cafe!

I got some experience profiling memory leaks using -prof and the +RTS -hc
-L350 --RTS option. This gives me a .hp file with samples done at regular
intervals. I can feed this file to `hp2pretty`, get some nice graphs and
when I identify a suspicious band, I can grep the .hp file to get the
complete "cost-center stack" responsible for that band. Here is an example
of one:

    (18514)unsafeCreate/take/hexString/withText/parseOptionalFieldWith<...>

I have been trying to replicate this setup using the eventlog logging. I use
+RTS -l-aug -hc --RTS to get the eventlog with user and GC events. I use
`eventlog2html` to get better view of memory allocation per cost-center. The
normalized view presents me with cost-centers at the right side where I can
filter on them[1].

But those labels are just the "top" of the cost-center stack. In fact I
don't think the whole cost-center stack is represented anywhere on the
eventlog file. I can sort of get the structure of the cost-center stack from
the .hp file. The labels identifying the cost-center are different between
the two files.

Is there a way to recover the complete cost-center stack purely from the
eventlog file? Thanks in advance

[1]: https://imgur.com/a/nXyCEpG

-- 
Rubén. (pgp: 1E88 3AC4 89EB FA22)