Re: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available

[Carter Schonwald]

George can you share the generated settings file?

On Fri, Sep 22, 2023 at 8:34 PM Ben Gamari  wrote:

> George Colpitts  writes:
>
> > It seems unlikely that the current tests wouldn't find this bug. Is it
> the
> > case that the tests are never run on aarch64-darwin Macs?
> >
> The tests are certainly run; see, for instance, the 9.8.1-alpha4 release
> pipeline [1].
>
> The problem is that #21570 requires very particular (mis)configuration
> of the host toolchain (e.g. Richard had multiple, incompatible
> toolchains in PATH). We can usually side-step this sort of
> misconfiguration by disabling the `configure` script's ld-override
> logic, since we using anything but Apple's linker is generally a bad
> idea on Darwin. This measure (!8437) is present in the 9.8 branch so I can
> only
> guess that something else is wrong.
>
> Perhaps you could open a ticket and attach config.log?
>
> Cheers,
>
> - Ben
>
>
> [1]: https://gitlab.haskell.org/ghc/ghc/-/jobs/1668689
> ___
> 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.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.4.6 is now available

[Carter Schonwald]

you like to 9.4.6 instead of .7 ...

On Mon, Aug 7, 2023 at 11:58 AM Ben Gamari  wrote:

>
> The GHC developers are happy to announce the availability of GHC 9.4.6.
> Binary
> distributions, source distributions, and documentation are available at
>
> https://downloads.haskell.org/ghc/9.4.6
>
> This release is primarily a bugfix release addressing some issues
> found in 9.4.6. These include:
>
>  * Many bug fixes for the simplifier, preventing compiler panics, loops and
>incorrect code generation (#22761, #22549, #23208, #22761, #22272,
> #23146,
>#23012, #22547).
>  * Bug fixes for the typechecker involving newtype family instances, making
>type equalities more robust and bugs having to do with defaulting
> representation
>polymorphic type variables (#23329, #2, #23143, #23154, #23176).
>  * Some bug fixes for code generation, particularly on the aarch64 backend,
>including adding more memory barriers for array read operations
> (#23541, #23749).
>  * Some bug fixes for windows builds, ensuring the reliablility of IO
> manager shutdown
>and a bug fix for the RTS linker on windows (#23691, #22941).
>  * A bug fix for the non-moving GC ensuring mutator allocations are
> properly
>accounted for (#23312).
>  * A bug fix preventing some segfaults by ensuring that pinned allocations
> respect
>block size (#23400).
>  * Many bug fixes for the bytecode interpreter, allowing a greater subset
>of the language to be interpreted (#22376, #22840, #22051, #21945,
> #23068, #22958).
>  * ... and a few more. See the [release notes] for a full accounting.
>
> As some of the fixed issues do affect correctness users are encouraged to
> upgrade promptly.
>
> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and
> other anonymous contributors whose on-going financial and in-kind support
> has
> facilitated GHC maintenance and release management over the years. Finally,
> this release would not have been possible without the hundreds of
> open-source
> contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy compiling,
>
> - Zubin & Ben
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [release notes]:
> https://downloads.haskell.org/~ghc/9.4.6/docs/users_guide/9.4.6-notes.html
> ___
> 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.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Performance of small allocations via prim ops

[Carter Schonwald]

Great /fast experimentation!

I will admit I’m pleased that my dated intuition is still correct, but more
importantly we have more current data!

Thanks for the exploration and sharing what you found!

On Fri, Apr 7, 2023 at 7:35 AM Harendra Kumar 
wrote:

>
>
> On Fri, 7 Apr 2023 at 02:18, Carter Schonwald 
> wrote:
>
>> That sounds like a worthy experiment!
>>
>> I  guess that would look like having an inline macro’d up path that
>> checks if it can get the job done that falls back to the general code?
>>
>> Last I checked, the overhead for this sort of c call was on the order of
>> 10nanoseconds or less which seems like it’d be very unlikely to be a
>> bottleneck, but do you have any natural or artificial benchmark programs
>> that would show case this?
>>
>
> I converted my example code into a loop and ran it a million times with a
> 1 byte array size (would be 8 bytes after alignment). So roughly 3 words
> would be allocated per array, including the header and length. It took 5 ms
> using the statically known size optimization which inlines the alloc
> completely, and 10 ms using an unknown size (from program arg) which makes
> a call to newByteArray# . That turns out to be of the order of 5ns more per
> allocation. It does not sound like a big deal.
>
> -harendra
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Performance of small allocations via prim ops

[Carter Schonwald]

That sounds like a worthy experiment!

I  guess that would look like having an inline macro’d up path that checks
if it can get the job done that falls back to the general code?

Last I checked, the overhead for this sort of c call was on the order of
10nanoseconds or less which seems like it’d be very unlikely to be a
bottleneck, but do you have any natural or artificial benchmark programs
that would show case this?

For this sortah code, extra branching for that optimization could easily
have a larger performance impact than the known function call on modern
hardware.  (Though take my intuitions about these things with a grain of
salt. )

On Tue, Apr 4, 2023 at 9:50 PM Harendra Kumar 
wrote:

> I was looking at the RTS code for allocating small objects via prim ops
> e.g. newByteArray# . The code looks like:
>
> stg_newByteArrayzh ( W_ n )
> {
> MAYBE_GC_N(stg_newByteArrayzh, n);
>
> payload_words = ROUNDUP_BYTES_TO_WDS(n);
> words = BYTES_TO_WDS(SIZEOF_StgArrBytes) + payload_words;
> ("ptr" p) = ccall allocateMightFail(MyCapability() "ptr", words);
>
> We are making a foreign call here (ccall). I am wondering how much
> overhead a ccall adds? I guess it may have to save and restore registers.
> Would it be better to do the fast path case of allocating small objects
> from the nursery using cmm code like in stg_gc_noregs?
>
> -harendra
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Buy-in for technical proposal 47 which affect GHC devs

[Carter Schonwald]

this is actually a good point! In my head, i was thinking some of the
backpack module renaming and exporting machinery that cabal has would be
applicable to side stepping the problem you're alluding to

On Fri, Mar 24, 2023 at 3:48 AM Phyx  wrote:

>
> Hi,
>
> Though I'm no longer a very active GHC developer I do have some questions.
>
> Overall I'm in support of this but I think I'd rather see an outright
> split from the start rather than first having a forwarder library.
>
> The reason for this is that I'm afraid of the performance impact of having
> this intermediate layer.
>
> For statically linked programs this means at least an additional load and
> branch on every call to a standard library. This would for instance affect
> Windows quite heavily. I'm not sure the impact is mitigated by branch
> prediction and prefetching. At the least it'll polute your L2 cache much
> more than before.
>
> For dynamically linked we could potentially use symbol preemption to
> remove the forwarding or on Windows redirect using import libraries.
>
> Now maybe I'm overestimating the impact this would have, but I'd very much
> like to see some numbers on a small-ish experiment to see what impact (if
> any) there are and what mitigation we can do.
>
> Typically it's quite hard to optimize after the fact. Maybe I've missed it
> in there. Proposal, but can the compiler remove the forwarding? i.e. Can
> the calls be specialized directly to the definition one? If so it'll break
> having alternative standard libs at runtime?
>
> Kind regards,
> Tamar
>
> On Fri, Mar 24, 2023, 04:47 Ben Gamari  wrote:
>
>> "Adam Sandberg Eriksson"  writes:
>>
>> > I switched all the HADDOCK hide to not-home in base a couple of years
>> > ago, but I see a couple of new ones have snuck in in the meantime. I
>> > would suggest adding a lint against hiding in GHC CI.
>> >
>> Sounds reasonable to me.
>> Perhaps someone could open a ticket to track this?
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Buy-in for technical proposal 47 which affect GHC devs

[Carter Schonwald]

i mean exactly the hidden status which means you cant directly go to the
highlighted source.

My recollection is that the only justification for that was as a mechanism
for "foot cannons here," which itself predates the more modern *.Internal
module norms we hew to today.

On Tue, Mar 21, 2023 at 8:21 PM Ben Gamari  wrote:

> Carter Schonwald  writes:
>
> > Would this include making those modules not hidden in ghc base? There’s
> > been a few times where that status made it quite hard to build
> > documentation for those modules!
> >
> What do you mean concretely? In most cases modules would remain exposed
> (that is, importable). However, I doubt there will be any change in
> their Haddock status (e.g. not-home or hidden).
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Buy-in for technical proposal 47 which affect GHC devs

[Carter Schonwald]

Would this include making those modules not hidden in ghc base? There’s
been a few times where that status made it quite hard to build
documentation for those modules!

On Tue, Mar 21, 2023 at 1:16 PM Ben Gamari  wrote:

> Laurent P. René de Cotret  writes:
>
> > Dear GHC developers,
> >
> > In recent weeks, John Ericson has fine-tuned a Haskell Foundation
> > Technical Proposal to split `base` into two libraries: `ghc-base` and
> > `base`, the latter simply re-exporting everything for `ghc-base` (for
> > now). You can read about the rationale and specifics more in details
> > in the proposal itself:
> > https://github.com/haskellfoundation/tech-proposals/pull/47
> >
> > Note that this proposal has recently been streamlined into a form
> > which is more focused than its initial state, and might be worth a
> > re-read.
> >
> > The Haskell Foundation Technical Working Group has reached a consensus
> > that this work will benefit the Haskell community. Moreover, the
> > Haskell Foundation has agreed to spend some of its resources to
> > implement this proposal, which would start by ensuring the completion
> > of MR7898 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898).
> >
> > This work will affect GHC developers. Therefore, the Technical Working
> > Group would like to get buy-in from the GHC developers before formally
> > accepting this proposal.
> >
> Hi Laurent,
>
> In general I am quite supportive of this proposal. I have discussed the
> idea with John on several occassions and agree that separating the
> implementation of `base` from its user-facing interfaces with a package
> boundary would simplify life for both users and GHC's maintainers (c.f.
> [1]).
>
> I also threw together my own implementation of the idea in a few hours
> some weeks back (having forgotten about John's effort); this can be
> found in the wip/ghc-base branch [2]. From that experience I have no
> doubts that this idea is feasible. The only issues that I am slightly
> unsure of are:
>
>  * whether/how to prevent `ghc-base` references from seeping into error
>messages.
>
>  * which interfaces should be re-exposed from `base`. In [2] we propose
>that a fair number of interfaces be marked as GHC-internal.
>Those which are marked [3] as "hidden" should likely be
>exposed only via `ghc-base`. However, for compatibility reasons we
>may decide to continue exporting some subset of "internal" modules
>(with frozen export lists) from `base`.
>
> Regardless, I am very happy to see this split move forward and am
> grateful to John for his work in this direction.
>
> Cheers,
>
> - Ben
>
>
>
> [1] https://github.com/haskell/core-libraries-committee/issues/146
> [2] https://gitlab.haskell.org/ghc/ghc/-/tree/wip/ghc-base
> [3]
> https://docs.google.com/spreadsheets/d/1WmyYLbJIMk9Q-vK4No5qvKIIdIZwhhFFlw6iVWd1xNQ/edit#gid=1315971213
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: FFI changes?

[Carter Schonwald]

Hey domninick: what platform are you using?

Is this on an arm flavor mac?

On Thu, Jan 26, 2023 at 5:00 PM Ben Gamari  wrote:

> Dominick Samperi  writes:
>
> > Hello,
> >
> > I have been working with a program that uses FFI to communicate with R
> > for several years, but today there is a segmentation fault while
> > importing functions or data from R. Before giving up on this project,
> > I'm posting a few detail here, in case anybody has ideas...perhaps
> > something changed with FFI?
> >
> Hi Dominick,
>
> As far as I know nothing should have changed that would break
> previously-correct FFI programs.
>
> More information would be helpful: Which GHC version are you using?
> Which platform are you running on? Can you provide a reproducer?
> If so, please open a ticket [1].
>
> Cheers,
>
> - Ben
>
>
> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/new
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Deprecating Safe Haskell, or heavily investing in it?

[Carter Schonwald]

I think some flavor / iterations of lambda bot has used it for example.

On Fri, Jan 13, 2023 at 1:44 PM Jaro Reinders 
wrote:

> I do agree that Safe Haskell would be useful even if it was only used for
> enforcing type safety and avoiding accidental use of unsafe features, but
> the
> paper [1] makes it quite clear that one of the main goals is to safely
> execute
> untrusted code:
>
> "Safe Haskell makes it possible to confine and safely execute untrusted,
> possibly malicious code. By strictly enforcing types, Safe Haskell allows
> a
> variety of different policies from API sandboxing to information-flow
> control
> to be implemented easily as monads.
> [..]
> We use Safe Haskell to implement an online Haskell interpreter that can
> securely execute arbitrary untrusted code with no overhead."
>
> Cheers, Jaro
>
> [1] https://www.scs.stanford.edu/~dm/home/papers/terei:safe-haskell.pdf
>
> On 13-01-2023 18:06, Carter Schonwald wrote:
> > Indeed type safety is exactly what it’s for! The other notions of safety
> were
> > never part of the goals. And it was designed so that the end user could
> decide
> > which codes they deem trustworthy.
> >
> > On Wed, Dec 28, 2022 at 6:04 PM davean  > <mailto:dav...@xkcd.com>> wrote:
> >
> > The only part of Safe Haskell I ever really cared about was type
> safety.
> > That's what matters, I think.
> >
> > I've wanted to use it a number of times and played with it, but it's
> never
> > actually managed to become an important part of anything for me.
> > So take that as you will. I'd love it if it worked well, its issues
> have
> > limited what I attempt, but at the end of the day it's never hurt me
> too
> > bad to not have it.
> >
> >
> > -davean
> >
> > On Wed, Dec 28, 2022 at 7:14 AM Tom Ellis
> >  > <mailto:tom-lists-haskell-cafe-2...@jaguarpaw.co.uk>> wrote:
> >
> > On Tue, Dec 27, 2022 at 08:33:04PM -0700, Chris Smith wrote:
> >  > This conversation reminds me of a parable I encountered
> somewhere,
> > in which
> >  > someone declares "I don't understand why this decision was
> ever
> > made, and I
> >  > we should change it", and someone responds, "No, if you don't
> understand
> >  > the decision was made, then you don't know enough to change
> it.  If you
> >  > learn why it was decided that way in the first place, then
> you will have
> >  > the understanding to decide whether to change it."
> >
> > That parable is Chesterton's fence:
> >
> >
> https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
> > <
> https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence>
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> >
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Deprecating Safe Haskell, or heavily investing in it?

[Carter Schonwald]

Indeed type safety is exactly what it’s for! The other notions of safety
were never part of the goals. And it was designed so that the end user
could decide which codes they deem trustworthy.

On Wed, Dec 28, 2022 at 6:04 PM davean  wrote:

> The only part of Safe Haskell I ever really cared about was type safety.
> That's what matters, I think.
>
> I've wanted to use it a number of times and played with it, but it's never
> actually managed to become an important part of anything for me.
> So take that as you will. I'd love it if it worked well, its issues have
> limited what I attempt, but at the end of the day it's never hurt me too
> bad to not have it.
>
>
> -davean
>
> On Wed, Dec 28, 2022 at 7:14 AM Tom Ellis <
> tom-lists-haskell-cafe-2...@jaguarpaw.co.uk> wrote:
>
>> On Tue, Dec 27, 2022 at 08:33:04PM -0700, Chris Smith wrote:
>> > This conversation reminds me of a parable I encountered somewhere, in
>> which
>> > someone declares "I don't understand why this decision was ever made,
>> and I
>> > we should change it", and someone responds, "No, if you don't understand
>> > the decision was made, then you don't know enough to change it.  If you
>> > learn why it was decided that way in the first place, then you will have
>> > the understanding to decide whether to change it."
>>
>> That parable is Chesterton's fence:
>>
>> https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Serious bug in GHC 9.4 on basic math on aarch64

[Carter Schonwald]

agreed! This is a nasty one! (the only similar bug i remember in the past
is the double/float confusion in 7.6/7.8, but that was a much much harder
to trigger bug)

On Thu, Oct 13, 2022 at 1:37 PM Ian-Woo Kim  wrote:

> Thank you all very much for the quick actions.
> I see that the fix has been made and is under review!
>
> - Ian
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A macOS static linking mystery

[Carter Schonwald]

i think brandon is also referring to the Rosetta stuff on Arm Macs, are you
using one of those?

On Mon, Aug 8, 2022 at 8:00 PM Brandon Allbery  wrote:

> https://developer.apple.com/forums/thread/692383 is what I'm thinking
> of, but in this case there would still be library references shown by
> "otool -L", so I guess that's not what you're seeing.
>
> On Mon, Aug 8, 2022 at 7:49 PM Ryan Scott  wrote:
> >
> > Possibly? I'm not familiar with the system cache you're referring to,
> but it's a more solid lead than what I have currently. Do you know how one
> would confirm if this is the case or not?
> >
> > Ryan
>
>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: A macOS static linking mystery

[Carter Schonwald]

ahh, pkgconfig is what i was overlooking!

agreed with viktor, using the system provided one is definitely safer

On Mon, Aug 8, 2022 at 10:46 AM Viktor Dukhovni 
wrote:

> On Mon, Aug 08, 2022 at 09:59:48AM -0400, Viktor Dukhovni wrote:
>
> > On my MacOS laptop I get:
> >
> > $ /usr/local/bin/pkg-config --libs libffi
> > -lffi
> >
> > which does not use the "brew"-installed libffi.  Not surprising, since
> > /usr/local/lib/pkgconfig/ has no symlink to the "libffi.pc" file.
>
> When updating "libffi" HomeBrew reports:
>
> ==> libffi
> libffi is keg-only, which means it was not symlinked into /usr/local,
> because macOS already provides this software and installing another
> version in
> parallel can cause all kinds of trouble.
>
> For compilers to find libffi you may need to set:
>   export LDFLAGS="-L/usr/local/opt/libffi/lib"
>   export CPPFLAGS="-I/usr/local/opt/libffi/include"
>
> If the MacOS libffi works, it is probably safer to use it rather than
> the HomeBrew version.
>
> --
> Viktor.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: success on a slightly modified version of your suggestion for 21506

[Carter Schonwald]

that matches my experience, namely that i've successfully installed ghc
9.2.2 on osx 12.4 aka monterey a few times

On Sun, Jul 24, 2022 at 12:59 PM George Colpitts 
wrote:

> Hi Ben
>
> Thanks for the quick responses particularly on the weekend before your
> vacation.
>
> you wrote:
>
> What happens
> if you try to install to do something like (in the extracted binary
> distribution),
>
>
> $ ./configure --prefix=`pwd`/tmp
> $ make install# this will fail
> $ xattr -rc .
> $ make install# perhaps this will finish successfully?
> # tmp/bin/ghc --version   # GHC should be usable
>
>
> success on both my machines using a slightly modified version of your
> suggestion above for 21506:
>
>  ./configure --prefix=`pwd`/tmp# specifying ./tmp seems to be critical
>
> xattr -rc .# seems to be necessary
> also
>
> sudo make install   # seems to works , output ends
> with "recache"
>
> ./tmp/bin/ghc --version  # success , although admittedly
> the smallest smoke test possible
>
> You wrote:
>
> >
> Ultimately I think we may just need to bite the bullet and start
> properly notarising/codesigning releases (resolving #17418). At this point
> we have
> spent more time trying to avoid the notarisation requirement than
> it would likely take to satisfy it. Unfortunately, this will require
> that I find an Apple device somewhere which may take a few weeks.
>
>
> I'm afraid I am on holiday next week but I would quite grateful if we
> could arrange for a chat after I return such that we can debug this in
> realtime.
>
>
> Sure, we can chat when you return from your vacation.
>
> Not sure if it is worth trying to fix the release on the basis of what I
> write above. My opinion is: it is if we can get reports of at least one
> other person having this issue. I am fine with not doing this for 9.4.1
>
> I agree that we should raise the priority of "notarising/codesigning
> releases (resolving #17418)". My opinion is that it is not worth delaying
> 9.4.1 for this.
>
> Have a great vacation.
>
> Cheers
> George
>
>
>
>
>
>
> On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari  wrote:
>
>> George Colpitts  writes:
>>
>> > +Kazu Yamamoto 
>> >
>> > Hi Ben
>> >
>> > My 2 machines also have:
>> >
>> > $ spctl --status
>> > assessments enabled
>> >
>> Hmm, interesting. Then I am truly perplexed.
>>
>> > Speculations:
>> >
>> >
>> /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib
>> > is created after xattr -rc . was run so it doesn't have the necessary
>> > attributes. Is it possible that ghc developers and/or the test machines
>> > have this file on another of the paths in the error message and that is
>> why
>> > it works for them?
>> >
>> I'm not sure where this would be but at this point anything is possible.
>> What happens
>> if you try to install to do something like (in the extracted binary
>> distribution),
>>
>> $ ./configure --prefix=`pwd`/tmp
>> $ make install# this will fail
>> $ xattr -rc .
>> $ make install# perhaps this will finish successfully?
>> # tmp/bin/ghc --version   # GHC should be usable
>>
>> > I hope I didn't offend you by asking if the fix had been tested; I
>> assume
>> > it had been but I thought it was important to rule that out.
>> >
>> Not to worry; it's a very reasonable question to ask given the
>> circumstances.
>>
>> > More than happy to test. I really appreciate all the work you and others
>> > have put into GHC !
>> >
>> Ultimately I think we may just need to bite the bullet and start
>> properly notarising/codesigning releases (resolving #17418). At this
>> point we have
>> spent more time trying to avoid the notarisation requirement than
>> it would likely take to satisfy it. Unfortunately, this will require
>> that I find an Apple device somewhere which may take a few weeks.
>>
>> I'm afraid I am on holiday next week but I would quite grateful if we
>> could arrange for a chat after I return such that we can debug this in
>> realtime.
>>
>> Cheers,
>>
>> - Ben
>>
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Haddock needs help

[Carter Schonwald]

i might have some bandwidth to help out in small spurts if needed in the
second half of this summer,
lets catsup sometime soon on IRC or whatever and maybe i can help kick the
can  a smidge

On Mon, Jun 6, 2022 at 7:49 AM Hécate  wrote:

> Hi Mikolaj, you highlight something very interesting. Indeed there is no
> shame in disclosing technical debt.
>
> That being said the problem isn't entirely technical. The main
> challenges here are the consolidation of expertise, onboarding of
> newcomers, a sensible product roadmap, and a realistic path forward when
> it comes to the big features I'd like to ship in the future.
>
> At the moment I would be more comfortable with starting by onboarding a
> restricted group of people so that my attention can be properly focused
> on ramping up their skills, which is why I posted on the ghc-devs
> mailing-list, as GHC is our main (if not only) consumer, and GHC
> developers have already made contributions to Haddock.
>
> Cheers,
> Hécate
>
> Le 26/05/2022 à 17:12, Mikolaj Konarski a écrit :
> > Talking as a Haskell user, but also a cabal maintainer:
> > the Haddock work Hécate describes is crucial for the health
> > and efficiency of the whole ecosystem and the sooner
> > we can start it, the less drag it's going to have on the rest.
> >
> > Given that GHC expertise is not necessary for many
> > of the tasks involved, could we forward this message
> > to other media? I don't think there is shame in disclosing
> > technical debt (as opposed to hiding it) and I think the way
> > it's worded, it may be viewed as a challenge, not a turn-off.
> > Still, are there any suggestions on how to tweak the text
> > before an announcement on discourse, reddit, etc.?
> > Would, e.g., HF, like to chime in early in each of the ensuing
> > discussions? If so, how would we know where it gets posted to?
> >
> > Cheers,
> > Mikolaj
> >
> > On Thu, May 26, 2022 at 4:39 PM Hécate  wrote:
> >> Hi everyone,
> >>
> >> Haddock needs help.
> >>
> >> Since I joined the Haddock team to help triage the tickets and interact
> >> with the community, we lost all of our experts, and I didn't have time
> >> to level up quickly enough to handle the mass of incoming tickets, let
> >> alone actually reduce the number of tickets to number below two hundred.
> >>
> >> As things stand now, the Haddock code base is in a disastrous state,
> >> largely not understood and its CI is in shambles.
> >> There are things that we can improve on the short and longer term – see
> >> https://github.com/haskell/haddock/issues/1465 – but the greater lack
> of
> >> expertise means that any project involving some core business logic is
> >> bound to be utterly and unnecessarily painful. The Hi Haddock GSOC
> >> proposal, whilst fully implemented in GHC, cannot be brought in Haddock
> >> at this moment in a reasonable timeline without any help.
> >>
> >> At present time, I need:
> >>
> >> * People who can refactor the code base, following modern software
> >> engineering practices, like domain-driven design and test-driven
> >> development.
> >> * UI developers, proficient in CSS and web accessibility.
> >>
> >> If you feel like you fit some of these criteria, please do contact me at
> >> this address. If your company can spare some engineering hours for you
> >> to give a hand, you're most welcome to do so.
> >>
> >> Just so we are clear, I am immensely grateful to the people who have
> >> submitted fixes and patches these past months, but this situation is
> >> untenable.
> >>
> >> Hécate ✨
> >> : @TechnoEmpress
> >> IRC: Hecate
> >> WWW: https://glitchbra.in
> >> RUN: BSD
> >>
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> --
> Hécate ✨
> : @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialising NOINLINE functions

[Carter Schonwald]

There even was a ghc branch with partial work towards implementing this as
part of fgaz’s gsoc.

I’m happy to help out if any spare cycles are needed to work through the
details

On Fri, May 6, 2022 at 5:26 AM Simon Peyton Jones <
simon.peytonjo...@gmail.com> wrote:

> There is a (stale) ghc-proposal for that,
>> https://github.com/ghc-proposals/ghc-proposals/pull/357
>>
>
> So there is!  Thank you.
>
> Gergo: would you like to take over this proposal, revise it if necessary
> in the light of the comments, and submit it?
>
> Simon
>
> On Fri, 6 May 2022 at 10:08, Oleg Grenrus  wrote:
>
>> There is a (stale) ghc-proposal for that,
>> https://github.com/ghc-proposals/ghc-proposals/pull/357
>>
>> - Oleg
>>
>> On 6.5.2022 12.04, Simon Peyton Jones wrote:
>> > Dear devs
>> >
>> > At the moment the INLINEABLE pragma means "capture my right-hand side,
>> > regardless of how big it is, so that it can be type-class-specialised,
>> > including in other modules".  But it /also /says "feel free to inline
>> me".
>> >
>> > Some users (eg Gergo) want to say NOINLINE on some functions. But for
>> > these they'd still like to generate type-class-specialised versions.
>> > After all, if we aren't going to inline them, specialising is the next
>> > best thing.
>> >
>> > But we have no way to say both "specialise me" and "don't inline me",
>> > because you can't say both INLINEABLE and NOINLINE.  (That would look
>> > silly.)
>> >
>> > I think we should probably just bite the bullet and add a
>> > SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say
>> > "capture my right-hand side, regardless of how big it is, so that it
>> > can be type-class-specialised, including in other modules".  It
>> > behaves exactly like INLINEABLE except that  you can specify it along
>> > with INLINE/NOINLINE.
>> >
>> > Any thoughts?  Do you think this needs a GHC proposal?
>> >
>> > See #21036 <
>> https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930>
>> >
>> >
>> > Simon
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [EXTERNAL] Unexpected duplicate join points in "Core" output?

[Carter Schonwald]

In this example: why would it stop being a join point ?

Admittedly, my intuition might be skewed by my own ideas about how join
points are sortah a semantic special case of other constructs.

On Sat, Nov 20, 2021 at 4:17 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> There is absolutely no reason not to common-up those to join points.  But
> we can't common up some join points when we could if they were let's.
> Consider
>
> join j1 x = x+1
> in case v of
>   A -> f (join j2 x = x+1 in ...j2...)
>   B -> j1...
>   C -> j1...
>
> Even though j2 is identical to j1's, we can't eliminate j2 in favour of j1
> because then j1 wouldn't be a join point any more.
>
> GHC.Core.Opt.CSE is conservative at the moment, and never CSE's *any* join
> point.  It would not be hard to make it clever enough to CSE join points,
> but no one has yet done it.
>
> Do open a ticket!
>
> Simon
>
> PS: I am leaving Microsoft at the end of November 2021, at which point
> simo...@microsoft.com will cease to work.  Use simon.peytonjo...@gmail.com
> instead.  (For now, it just forwards to simo...@microsoft.com.)
>
> | -Original Message-
> | From: ghc-devs  On Behalf Of Viktor
> | Dukhovni
> | Sent: 20 November 2021 00:57
> | To: ghc-devs@haskell.org
> | Subject: [EXTERNAL] Unexpected duplicate join points in "Core" output?
> |
> | The below "Core" output from "ghc -O2" (9.2/8.10) for the attached
> | program shows seemingly rendundant join points:
> |
> |   join {
> | exit :: State# RealWorld -> (# State# RealWorld, () #)
> | exit (ipv :: State# RealWorld) = jump $s$j ipv } in
> |
> |   join {
> | exit1 :: State# RealWorld -> (# State# RealWorld, () #)
> | exit1 (ipv :: State# RealWorld) = jump $s$j ipv } in
> |
> | that are identical in all but name.  These correspond to fallthrough to
> | the "otherwise" case in:
> |
> |...
> || acc < q || (acc == q && d <= 5)
> |  -> loop (ptr `plusPtr` 1) (acc * 10 + d)
> || otherwise -> return Nothing
> |
> | but it seems that the generated X86_64 code (also below) ultimately
> | consolidates these into a single target... Is that why it is harmless
> | to leave these duplicated in the generated "Core"?
> |
> | [ Separately, in the generated machine code, it'd also be nice to avoid
> |   comparing the same "q" with the accumulator twice.  A single load and
> |   compare should I think be enough, as I'd expect the status flags to
> |   persist across the jump the second test.
> |
> |   This happens to not be performance critical in my case, because most
> |   calls should satisfy the first test, but generally I think that 3-way
> |   "a < b", "a == b", "a > b" branches ideally avoid comparing twice...
> | ]
> |
> |  Associated Core output
> |
> | -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}
> | main2 :: Addr#
> | main2 = "12345678901234567890 junk"#
> |
> | -- RHS size: {terms: 129, types: 114, coercions: 0, joins: 6/8}
> | main1 :: State# RealWorld -> (# State# RealWorld, () #)
> | main1
> |   = \ (eta :: State# RealWorld) ->
> |   let {
> | end :: Addr#
> | end = plusAddr# main2 25# } in
> |   join {
> | $s$j :: State# RealWorld -> (# State# RealWorld, () #)
> | $s$j _ = hPutStr2 stdout $fShowMaybe4 True eta } in
> |   join {
> | exit :: State# RealWorld -> (# State# RealWorld, () #)
> | exit (ipv :: State# RealWorld) = jump $s$j ipv } in
> |   join {
> | exit1 :: State# RealWorld -> (# State# RealWorld, () #)
> | exit1 (ipv :: State# RealWorld) = jump $s$j ipv } in
> |   join {
> | exit2
> |   :: Addr# -> Word# -> State# RealWorld -> (# State#
> | RealWorld, () #)
> | exit2 (ww :: Addr#) (ww1 :: Word#) (ipv :: State#
> | RealWorld)
> |   = case eqAddr# ww main2 of {
> |   __DEFAULT ->
> | hPutStr2
> |   stdout
> |   (++
> |  $fShowMaybe1
> |  (case $w$cshowsPrec3 11# (integerFromWord#
> | ww1) [] of
> |   { (# ww3, ww4 #) ->
> |   : ww3 ww4
> |   }))
> |   True
> |   eta;
> |   1# -> jump $s$j ipv
> | } } in
> |   joinrec {
> | $wloop
> |   :: Addr# -> Word# -> State# RealWorld -> (# State#
> | RealWorld, () #)
> | $wloop (ww :: Addr#) (ww1 :: Word#) (w :: State# RealWorld)
> |   = join {
> |   getDigit :: State# RealWorld -> (# State# RealWorld,
> | () #)
> |   getDigit (eta1 :: State# RealWorld)
> | = case eqAddr# ww end of {
> | 

Re: DWARF support

[Carter Schonwald]

My understanding is that the platform specific part of ghc dwarf support
atm is the stack walking to generate dwarf data in stack traces. This is
because the dwarf stack walking Libs that are relatively mature are mostly
centered around elf?

It should still be possible with some work to use perf and gdb style tools,
though the complications are

a) you have to make sure all the Libs are built with dwarf

b) there’s some complications around loading / placing the dwarf files
adjacent to the object code files on Darwin (at least last time I checked
which was years ago following the wiki entry johan tibbel wrote up I
think?)

C) scheduler yields make gdb stepping through a program a tad more
annoying, I think the “setting the yield timer to zero” is the work around

D) the “source” you step through is essentially the c— z-encoded code? So
you still need to do some puzzling out of stuff


On Wed, Nov 17, 2021 at 7:28 AM Moritz Angermann 
wrote:

> Hi Richard,
>
> I’m not sure using platform native AND  the term DWARF would help rather
> than add to confusion.  Let me still try to
> help a bit with context here.
>
> For Linux and most BSDs, we have settled on the Executable and Linking
> Format (ELF) as the container format for
> your machine code.  And you might see where the inspiration for DWARF
> might come from.
>
> For macOS, we have mach object (mach-o) as the container format. Its
> distinctly different to ELF, and also the
> reason why Linux/BSD and macOS are sometimes substantially different, wrt
> to executable packaging and linking.
>
> For windows we have Portable Executable (PE) as the container format.
>
> My recollection is that we implemented DWARF in the NCG only for ELF.
> I've always wanted to scratch an itch
> and try to make it work for mach-o as well, but never got around to it
> (yet?).  The NCGs have flags that specify
> if we want to emit debug info or not.  I believe most codegens except for
> x86_64/elf ignore that flag.
>
> This is a non-trivial engineering effort to get done properly, I believe.
> And we all spend time on many other things.
>
> Depending on how familiar you are with development on macOS, you might
> know the notion of dSYM folders,
> where macOS usually separate the application binary into the binary, and
> then stores the (d)ebug (SYM)bols in
> a separate folder. Those are iirc DWARF objects in the end.
>
> Hope this helps a bit; my recollection might be a bit rusty.
>
> Best,
>  Moritz
>
>
>
> On Wed 17. Nov 2021 at 20:02, Richard Eisenberg 
> wrote:
>
>> Hi devs,
>>
>> I was intrigued by Bodigrim's comment about HasCallStack in base (
>> https://github.com/haskell/core-libraries-committee/issues/5#issuecomment-970942580)
>> that there are other alternatives, such as DWARF. Over the years, I had
>> tuned out every time I saw the word DWARF: it was (and is!) an unknown
>> acronym and seems like a low-level detail. But Bodigrim's comment made me
>> want to re-think this stance.
>>
>> I found Ben's series of blog posts on DWARF, starting with
>> https://www.haskell.org/ghc/blog/20200403-dwarf-1.html. These are very
>> helpful! In particular, they taught me that DWARF = platform-native
>> debugging metadata. Is that translation accurate? If so, perhaps we should
>> use both names: if I see that GHC x.y.z has DWARF support, I quickly scroll
>> to the next bullet. If I see that GHC x.y.z has support for platform-native
>> debugging metadata and is now compatible with e.g. gdb, I'm interested.
>>
>> Going further, I have a key question for my use case: is this support
>> available on Mac? The first post in the series describes support for "Linux
>> and several BSDs" and the last post says that "Windows PDB support" is
>> future work. (Is "PDB" platform-native debugging metadata for Windows? I
>> don't know.) But I don't see any mention of Mac. What's the status here?
>>
>> It would be very cool if this conversation ends with me making a video on
>> how a few simple GHC flags can allow us to, say, get a stack trace on a
>> pattern-match failure in a Haskell program.
>>
>> Thanks!
>> Richard
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Interpreter thread in ghc-8.10.6 in macOS

[Carter Schonwald]

Hey Facundo: can you share a link to the underlying error ? I tried to find
the error output in the linked ticket, but I only see a failure message  at
the stack_build_tool level. Rather than a ghc or linker error

How would I replicate the build failure locally? Would cabal get haskellR ;
cd haskelR* ; cabal build ; cabal test suffice ?

On Tue, Nov 16, 2021 at 9:27 AM Domínguez, Facundo <
facundo.doming...@tweag.io> wrote:

> Dear devs,
>
> I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving
> differently than previous compilers when running Template Haskell code.
>
> When upgrading HaskellR to use a newer ghc I found that it would work fine
> with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R
> runtime in particular, is sensitive to local state in the threads that are
> used to execute the runtime. HaskellR is arranging to run the R runtime
> when running TemplateHaskell splices, and this stopped working in MacOS
> with ghc-8.10.6.
>
> The error I got is not new. It comes from R and we would get it in ghci if
> we try to use HaskellR without passing the command line flag
> -fno-ghci-sandbox. But this is the first time we get the error when using
> TemplateHaskell.
>
> Does anyone know if there have been changes to the threads in which the TH
> splices are run? And were there any changes specific to TH in MacOS?
>
> Thanks in advance,
> Facundo
>
> [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8-bit and 16-bit arithmetic

[Carter Schonwald]

yeah, like, currently the XOR for setting registers to zero trick / code
optimization (first implemented in ghc backend by reid barton) is done as
part of the pretty printer on X86/AMD_64 targets

this and a lot of other easy win peephole optimizations that are platform
/target dependent happen in the pretty printer atm I thnk

On Thu, Oct 28, 2021 at 5:38 PM Ben Gamari  wrote:

> Norman Ramsey  writes:
>
> > On x86, GHC can translate 8-bit and 16-bit operations directly
> > into the 8-bit and 16-bit machine instructions that the hardware
> > supports.  But there are other platforms on which the smallest
> > unit of arithmetic may be 32 or even 64 bits.  Is there a central
> > module in GHC that can take care of rewriting 8-bit and 16-bit operations
> > into 32-bit or 64-bit operations?  Or is each back end on its own
> > for this?
> >
> > (One of my students did some nice work on implementing this
> transformation
> > with a minimal set of sign-extension and zero-extension operations:
> > https://www.cs.tufts.edu/~nr/pubs/widen.pdf.)
> >
> As Carter indicated, this is currently done on a per-backend basis. This
> could indeed probably be consolidated, although we would want to make
> sure that in so doing we do not leave easy money on the table: It seems
> plausible to me that the backend may be able to generate better code
> than a naive lowering to wide arithmetic might otherwise generate.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8-bit and 16-bit arithmetic

[Carter Schonwald]

I think thats done on a per backend basis (though theres been a lot of
changes since i last looked at some of the relevent pieces). (i'm actually
based in Cambridge MA for the next 1-2 years if you wanna brain storm IRL
sometime)

On Thu, Oct 28, 2021 at 4:59 PM Norman Ramsey  wrote:

> On x86, GHC can translate 8-bit and 16-bit operations directly
> into the 8-bit and 16-bit machine instructions that the hardware
> supports.  But there are other platforms on which the smallest
> unit of arithmetic may be 32 or even 64 bits.  Is there a central
> module in GHC that can take care of rewriting 8-bit and 16-bit operations
> into 32-bit or 64-bit operations?  Or is each back end on its own
> for this?
>
> (One of my students did some nice work on implementing this transformation
> with a minimal set of sign-extension and zero-extension operations:
> https://www.cs.tufts.edu/~nr/pubs/widen.pdf.)
>
>
> Norman
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Meaning of -i and -hidir

[Carter Schonwald]

Could be!  I’m far from a computer much of this week

On Sat, Oct 23, 2021 at 2:36 PM Brandon Allbery  wrote:

> I would expect that to be -I and for -i to specify module paths (which
> might well mean .hi).
>
> On Sat, Oct 23, 2021 at 2:32 PM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> I would assume the -i is for include c header search paths but I could be
>> wrong
>>
>> On Sat, Oct 23, 2021 at 6:00 AM Oleg Grenrus  wrote:
>>
>>> This looks like a bug.
>>>
>>> -hidir documentation says
>>>
>>> > Redirects all generated interface files into ⟨dir⟩, instead of the
>>> default.
>>> > Please also note that when doing incremental compilation (by ghc
>>> --make or ghc -c), this directory is where GHC looks into to find interface
>>> files.
>>>
>>> And documentation for -i doesn't mention looking for interface files.
>>>
>>> So by doing
>>>
>>> % ghc -dynamic-too -c lib/Lib.hs -odir odir -hidir hidir_Lib
>>> % ghc -dynamic-too -c Main.hs -odir odir -hidir hidir_Main -ihidir_Lib
>>> 1
>>> % ghc odir/Lib.o odir/Main.o -o Demo
>>> % ./Demo
>>> True
>>>
>>> everything compiles, TH is run, and demo works. The result files are
>>>
>>> % find .
>>> .
>>> ./Demo
>>> ./Main.hs
>>> ./hidir_Main
>>> ./hidir_Main/Main.dyn_hi
>>> ./hidir_Main/Main.hi
>>> ./odir
>>> ./odir/Main.dyn_o
>>> ./odir/Main.o
>>> ./odir/Lib.dyn_o
>>> ./odir/Lib.o
>>> ./hidir_Lib
>>> ./hidir_Lib/Lib.dyn_hi
>>> ./hidir_Lib/Lib.hi
>>> ./lib
>>> ./lib/Lib.hs
>>>
>>> ---
>>>
>>> The confusing error is caused by Lib module in libiserv:
>>> https://hackage.haskell.org/package/libiserv
>>> which GHC picks!
>>>
>>> If we rename your Lib module to Library, the error is way better: Could
>>> not find module ‘Library’
>>>
>>> I also tried using same -hidir when compiling both modules, then GHC
>>> still cannot find the Library interface, even the documentation says it
>>> should.
>>>
>>> Please open a GHC issue at https://gitlab.haskell.org/ghc/ghc/-/issues
>>>
>>>
>>>
>>> - Oleg
>>> On 22.10.2021 19.16, Domínguez, Facundo wrote:
>>>
>>> Dear devs,
>>>
>>> I'm confused about the meaning of -hidir and -i. Here's my experiment
>>> with both ghc-9.2.0 and ghc-8.10.4.
>>>
>>> > $ find
>>> > ./Main.hs
>>> > ./lib/Lib.hs
>>> >
>>> > $ ghc -dynamic-too -c lib/Lib.hs -odir odir -hidir hidir_Lib
>>> >
>>> > $ ghc -dynamic-too -c Main.hs -odir odir -ihidir_Lib -hidir hidir_Main
>>> >
>>> > Main.hs:3:1: error:
>>> > Bad interface file: hidir_Main/Lib.hi
>>> > hidir_Main/Lib.hi: openBinaryFile: does not exist (No such
>>> file or directory)
>>> >   |
>>> > 3 | import Lib
>>> >   | ^^
>>>
>>> If I only use -hidir, it still fails with another error
>>>
>>> > $ ghc -dynamic-too -c Main.hs -odir odir -hidir hidir_Lib
>>> >
>>> > Main.hs:7:29: error: Variable not in scope: f
>>> >   |
>>> > 7 | main = print $(runIO (print f) >> [| True |])
>>> >   | ^
>>>
>>> If I use both -i and -hidir pointing to the same folder, then it works!
>>>
>>> > $ ghc -dynamic-too -c Main.hs -odir odir -ihidir_Lib -hidir hidir_Lib
>>>
>>> Now, is this behavior a bug or a feature? And if it is a bug, what is
>>> the expected behavior?
>>>
>>> Programs copied below.
>>>
>>> Thank you!
>>> Facundo
>>>
>>> > $ cat lib/Lib.hs
>>> > module Lib where
>>> >
>>> > f :: Int
>>> > f = 1
>>> >
>>> > $ cat Main.hs
>>> > {-# LANGUAGE TemplateHaskell #-}
>>> >
>>> > import Lib
>>> > import Language.Haskell.TH <http://language.haskell.th/>
>>> >
>>> > main :: IO ()
>>> > main = print $(runIO (print f) >> [| True |])
>>>
>>> ___
>>> ghc-devs mailing 
>>> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Meaning of -i and -hidir

[Carter Schonwald]

I would assume the -i is for include c header search paths but I could be
wrong

On Sat, Oct 23, 2021 at 6:00 AM Oleg Grenrus  wrote:

> This looks like a bug.
>
> -hidir documentation says
>
> > Redirects all generated interface files into ⟨dir⟩, instead of the
> default.
> > Please also note that when doing incremental compilation (by ghc --make
> or ghc -c), this directory is where GHC looks into to find interface files.
>
> And documentation for -i doesn't mention looking for interface files.
>
> So by doing
>
> % ghc -dynamic-too -c lib/Lib.hs -odir odir -hidir hidir_Lib
> % ghc -dynamic-too -c Main.hs -odir odir -hidir hidir_Main -ihidir_Lib
> 1
> % ghc odir/Lib.o odir/Main.o -o Demo
> % ./Demo
> True
>
> everything compiles, TH is run, and demo works. The result files are
>
> % find .
> .
> ./Demo
> ./Main.hs
> ./hidir_Main
> ./hidir_Main/Main.dyn_hi
> ./hidir_Main/Main.hi
> ./odir
> ./odir/Main.dyn_o
> ./odir/Main.o
> ./odir/Lib.dyn_o
> ./odir/Lib.o
> ./hidir_Lib
> ./hidir_Lib/Lib.dyn_hi
> ./hidir_Lib/Lib.hi
> ./lib
> ./lib/Lib.hs
>
> ---
>
> The confusing error is caused by Lib module in libiserv:
> https://hackage.haskell.org/package/libiserv
> which GHC picks!
>
> If we rename your Lib module to Library, the error is way better: Could
> not find module ‘Library’
>
> I also tried using same -hidir when compiling both modules, then GHC still
> cannot find the Library interface, even the documentation says it should.
>
> Please open a GHC issue at https://gitlab.haskell.org/ghc/ghc/-/issues
>
>
>
> - Oleg
> On 22.10.2021 19.16, Domínguez, Facundo wrote:
>
> Dear devs,
>
> I'm confused about the meaning of -hidir and -i. Here's my experiment with
> both ghc-9.2.0 and ghc-8.10.4.
>
> > $ find
> > ./Main.hs
> > ./lib/Lib.hs
> >
> > $ ghc -dynamic-too -c lib/Lib.hs -odir odir -hidir hidir_Lib
> >
> > $ ghc -dynamic-too -c Main.hs -odir odir -ihidir_Lib -hidir hidir_Main
> >
> > Main.hs:3:1: error:
> > Bad interface file: hidir_Main/Lib.hi
> > hidir_Main/Lib.hi: openBinaryFile: does not exist (No such file
> or directory)
> >   |
> > 3 | import Lib
> >   | ^^
>
> If I only use -hidir, it still fails with another error
>
> > $ ghc -dynamic-too -c Main.hs -odir odir -hidir hidir_Lib
> >
> > Main.hs:7:29: error: Variable not in scope: f
> >   |
> > 7 | main = print $(runIO (print f) >> [| True |])
> >   | ^
>
> If I use both -i and -hidir pointing to the same folder, then it works!
>
> > $ ghc -dynamic-too -c Main.hs -odir odir -ihidir_Lib -hidir hidir_Lib
>
> Now, is this behavior a bug or a feature? And if it is a bug, what is the
> expected behavior?
>
> Programs copied below.
>
> Thank you!
> Facundo
>
> > $ cat lib/Lib.hs
> > module Lib where
> >
> > f :: Int
> > f = 1
> >
> > $ cat Main.hs
> > {-# LANGUAGE TemplateHaskell #-}
> >
> > import Lib
> > import Language.Haskell.TH 
> >
> > main :: IO ()
> > main = print $(runIO (print f) >> [| True |])
>
> ___
> ghc-devs mailing 
> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Another hadrian option you might want to use

[Carter Schonwald]

A cheat sheet on the wiki linking to different build system tricks is a
great idea!

On Thu, Oct 21, 2021 at 2:23 AM Alfredo Di Napoli <
alfredo.dinap...@gmail.com> wrote:

> Hello Matthew,
>
> Perhaps it would be too niche of a resource, but what about collecting
> these options either in a Wiki page in GHC or maybe a short blog post on
> your website (if that's not the case already)? I personally use
> `--flavour=default+no_profiled_libs+omit_pragmas` all the time with Hadrian
> these days once you made me discover that magic incantation, but I am
> essentially relying on my bash history or my search capabilities within
> this mailing list.
>
> I could imagine how other people might have missed your original email,
> and it would be great if we could have this shared somewhere in a more
> discoverable way.
>
> Alfredo
>
>
> On Wed, 20 Oct 2021 at 12:59, Matthew Pickering <
> matthewtpicker...@gmail.com> wrote:
>
>> Hi,
>>
>> A recent change in the testsuite meant that we now running the haddock
>> tests with hadrian, this means that haddocks for ghc/base get rebuilt
>> if you modify anything in the compiler.
>>
>> This can decrease interaction speed. To disable the documentation
>> tests from running use
>>
>> --docs=none
>>
>> This is similar to the flag which already skips performance tests:
>>
>> --skip-perf
>>
>> Cheers,
>>
>> Matt
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Numerics (was: Re: Trouble with asinh)

[Carter Schonwald]

Hey David,
Create a tracking ticket on the ghc for the set of changes / issues you
wanna address and how, and @ me on it  (I’ll then make sure to at other
applicable Dolan )and I’ll try to help you get oriented and make sure it
has the right visibility so we can help you out!

On Sat, Sep 18, 2021 at 12:00 PM David James  wrote:

> Hi thanks for the comments. I actually have draft rewrites of the Haskell
> complex functions with (I think) the correct behaviour, including branch
> cuts. But I discovered the errors in the underlying real functions while
> testing them. I’d like to try fixing all of these, but will probably need
> some help.
>
> Are there instructions somewhere on the process to fix a bug (presumably
> forking in GitHub, fixing code, adding test cases, running some CI, both
> for Linux and Windows, etc)? (And is there something similar for fixing
> mingle-w64 bugs?)
>
> I’ve been developing more test cases (esp for infinities +/-0, etc), but
> if there are any ideas/references on how to thoroughly test real or complex
> functions, that would also be useful.
>
> I’m currently away (and struggling to type on a phone) but will send more
> details (and pictures based on those in Common Lisp The Language 2nd
> edition) when I’m back.
>
> Thanks! David.
>
>
>
> > On 17 Sep 2021, at 22:06, Barak A. Pearlmutter 
> wrote:
> >
> > I suspect that most implementations of Common Lisp just call the C
> > standard library catan(3) etc, which are well tuned.
> >
> > $ clisp
> > Welcome to GNU CLISP 2.49.92 (2018-02-18) 
> > [1]> (atan #c(0 1d-40))
> > #C(0 1.0d-40)
> >
> > In this particular case, the problem is that the Haskell Data.Complex
> > code has its own implementation of atan, which uses a log(1 + x) in
> > calculating the imaginary part. A foreign function call to the
> > appropriate libm routine would robustly address this, but that would
> > be difficult because it's trying to be generic over RealFloat a =>
> > Complex a, instead of special casing Complex Float / Complex Double.
> > Anyway, the Standard Prelude code for this is naïve: it should call
> > log1p, at the very least—which it actually goes to the trouble of
> > defining correctly, but not exporting.
> > ___
> > 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.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC development with VSCode

[Carter Schonwald]

For ghc dev I generally disable tools / plugins that do indexing.
Especially if I’m on a laptop. The non cabalized builds tend to create a
huge build/indexing overhead and some of these integrations have a blocking
semantics. Plus underdocumented caching so there’s no “prebuilt index” as a
warm start for a local indexing process.



On Mon, Sep 20, 2021 at 11:29 AM Richard Eisenberg 
wrote:

> Hi devs,
>
> I have migrated to use VSCode instead of emacs. There are the usual
> switchover pains, but I'm mostly pleased. One particular point of pleasure
> was that I had to do nothing, at all, to get VSCode working within the GHC
> code base. (Well, I had to switch to Hadrian, but perhaps that's for the
> best.)
>
> My problem: VSCode over GHC pins my processor at 100% if I edit anything.
> Any advice for fixing this?
>
> A little more detail: When VSCode starts up, it spends a while
> "processing" and "indexing" (no idea what these mean). OK. I can pay that
> one-time cost. But as I start editing, etc., it needs to process and index
> a lot more. Somewhat continuously. This slows my computer down generally,
> and -- more annoyingly -- slows down my builds (run in a separate terminal).
>
> I understand why VSCode wants to do this: it's checking my code for
> errors, etc. But is there a way to say "not now, please"? More
> specifically: I'd like to stop VSCode from detecting errors in my code
> while I'm actively editing. It's just too slow. On the other hand, it would
> be brilliant if VSCode could continue to allow me to, say, jump to
> definitions and gather references, using its latest knowledge of the code.
> As I edit, I understand this "latest knowledge" may become stale, if I'm
> stopping VSCode from reprocessing and reindexing. So, it would be nice to
> be able to tell VSCode to refresh, when I want that.
>
> Any pointers here?
> https://gitlab.haskell.org/ghc/ghc/-/wikis/Visual-Studio-Code would be a
> good place to put them!
>
> Thanks,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The future of Phabricator

[Carter Schonwald]

In one sense our migration was prescient, on the other hand i really wish
gitlab had a more performant code review ux.

Are there any performant for large code review tools? I find the reload
rendering latency and auto collapse defaults in gitlab pretty painful and
I’m pretty ignorant of the land scape these days.

On Fri, Sep 17, 2021 at 7:27 PM Niklas Hambüchen via ghc-devs <
ghc-devs@haskell.org> wrote:

> For those interested:
>
> Three years later, Phabricator shut down.
>
> May 29, 2021:
>
> https://admin.phacility.com/phame/post/view/11/phacility_is_winding_down_operations/
>
> On 10/30/18 5:54 AM, Ben Gamari wrote:
> > For one, at this point we have no options for support in the event that
> > something goes wrong as the company responsible for Phabricator,
> > Phacility, has closed their support channels to non-paying customers.
> > Furthermore, in the past year or two Phacility has been placing their
> > development resources in the parts their customers pay them for, which
> > appear to be much different that the parts that we actively use. For
> > this reason, some parts that we rely on seem oddly half-finished.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Haskell-cafe] Bundle patterns with type aliases

[Carter Schonwald]

These are great ideas! Could you please create a ghc tracker ticket with a
tiny examples or two?

There may be specific technical reasons we might not be able to do so for
type synonyms in ghc, but I don’t see any obvious barriers in the case of
David’s excellent idea, I’ve def seen lots of great code out there where
you’d really want either associated pattern synonyms or to bundle pattern
synonyms with the exported public interface for a type class.

I’m sure there’s some devil in the details but these sound lovely.  Step -1
is making up 1-2 toy examples and explaining what and why you want it on a
ghc ticket!

On Wed, Sep 8, 2021 at 1:25 PM David Feuer  wrote:

> I would like that, along with the ability to bundle patterns with classes.
>
> On Wed, Sep 8, 2021, 1:13 PM Keith  wrote:
>
>> Is there currently a way to 'bundle' a pattern with a type alias? And if
>> not, could that capability be added to the PatternSynonyms GHC extension?
>> (Is this the right place to ask, or should I be asking a GHC list?)
>>
>> --Keith
>> Sent from my phone with K-9 Mail.
>> ___
>> 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.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Email Threading (finally fixed)

[Carter Schonwald]

I was wondering about that!  Awesome
On Mon, Aug 2, 2021 at 6:01 AM Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> Hi all,
>
> If anyone received emails from gitlab you may have noticed that the
> comments to issues ended up in different threads to the original issue
> description.
>
> This was because of a custom patch on our gitlab instance which I
> think I have now fixed.
>
> For example issue #20192 now has the correct threading, the original
> issue and comment now appear in the same email thread (at least in my
> client).
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewriting plugins: request for feedback

[Carter Schonwald]

This sounds very cool!

FYI the Inria paper link in the readme seems to not be correct?

On Fri, Jul 9, 2021 at 6:56 PM Sam Derbyshire 
wrote:

> Hi all,
>
> I have now written a much more substantial type-checking plugin, which I
> used to typecheck an intrinsically typed implementation of System F. I've
> added the example to the repository (
> https://github.com/sheaf/ghc-tcplugin-api), see the readme.
>
> This uncovered several bugs in the implementation of the aforementioned
> compatibility layer for GHC 9.0 and 9.2, which have all been fixed. I can
> now in good conscience recommend that type-checking plugin authors try it
> out for themselves!
> There are slight inconsistencies in behaviour around emitting additional
> constraints when rewriting a type-family application (which I hope to iron
> out soon), but I expect the impact of this to be very minimal. Other than
> that, you can expect feature and behaviour parity with the native
> implementation.
>
> Please let me know how you get on, and which pain points you would like to
> see addressed. My current ideas for improvement are as follows:
>
>   - Functionality that would perform all the name resolution necessary in
> the plugin initialisation. The user would provide a record of the types to
> look up (a TyCon named ... in module ..., a Class named ... in module ...),
> and the library would look up everything. This would be quite
> straightforward with a library such as barbies, but I don't necessarily
> want to impose that cognitive overhead on users who are not familiar with
> it.
>   - An interface for handling type family rewritings that provides a type
> system that kind checks everything. For instance, instead of manually
> calling splitTyConAppMaybe, we could feasibly instead use a pattern with
> existential variables (matching on this pattern would introduce the kinds),
> and then use a smart constructor instead of mkTyConApp (which would
> kind-check the application). I certainly would have appreciated something
> like this when writing my System F plugin, as handling all the kinds
> explicitly was rather tiresome and error prone.
>   - Functionality for recognising that a type has a certain form, making
> use of Givens. For example, it can be quite annoying to find out whether a
> given type is a type family application, as one needs to look through the
> Givens to go through levels of indirection. For instance, one might come
> across a variable "x" (ostensibly not a type family application), but have
> Givens [G] y ~ x, [G] F a ~ y. (This happens often with flattening skolems.)
>
> Please let me know if you have any other ideas, or suggestions on how to
> tackle the above. Thanks.
>
> Best,
>
> Sam
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why base library changes are only discussed on GHC issue tracker and not on the libraries@ list?

[Carter Schonwald]

Agreed.  This is a problem.  I’ve tried to help make current clc folks
aware of this privately a time or two this past year :(

The only private part should be public coms on their discussion group to
record voting on stuff that isn’t unanimous. Anything beyond that fails to
align with healthy collaborative discourse norms

More concerningly, only ~2-3 members of the current clc seem to be actively
involved in public discussions on the library list or GitHub.  And a deep
misunderstanding that they need be maintainers of stuff that falls under
the umbrella of core libraries now.  Which is a fiction invented only on
the past two years.  Clc was formed to help guide decisions on base and be
a suport for core libraries authors/maintainers.  Not as an authority over
those maintainers.

There’s def problems with stuff and a lot of folks have privately expressed
a lot of frustration about this over the past 12 months.

On Wed, Jul 7, 2021 at 11:12 AM Oleg Grenrus  wrote:

> For example
>
> - https://gitlab.haskell.org/ghc/ghc/-/issues/20044 ByteArray migration
> from primitive to base
> - https://gitlab.haskell.org/ghc/ghc/-/issues/20027 Changing Show String
> behavior
>
> Why they are discussed "in private", I thought libraries@ list is where
> such changes should be discussed.
>
> - Oleg
>
> ___
> Libraries mailing list
> librar...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Breaking changes to the base library

[Carter Schonwald]

This is a good question / suggestion!

On Sun, Jun 20, 2021 at 11:09 AM Oleg Grenrus  wrote:

> What is the reason that -Wcompat flags are not enabled by -Wall? The
> unqualified Data.List import was warned by -Wcompat about since GHC-8.10,
> I'm surprised that it still surprise people.
>
> Should -Wcompat be implied by -Wall? Why not? I think that people who
> won't ever consider upgrading GHC to be a very very small minority, and
> they can suppress these warnings with `-Wall -Wno-compat`.
>
>
> - Oleg
>
> On 20.6.2021 17.57, Edward Kmett wrote:
>
> The breakage concern is why Data.List wound up in its limbo-like state of
> re-exporting the Foldable-polymorphic combinators since 7.10 -- while
> "weird", it was the only option that didn't have to choose between removing
> the names from Data.List exports entirely and breaking unqualified imports
> of Data.List.
>
> With the monomorphized combinators in place, Data.List should be
> considered a 'qualified' import like Data.Map. We definitely need to do
> more to communicate that this is changing and how users should adjust their
> code to suit. After all, by far the most common intended import from
> Data.List is the humble 'sort', which doesn't conflict.
>
> -Edward
>
> On Sun, Jun 20, 2021 at 4:45 AM Chris Smith  wrote:
>
>> Yikes, this is going to break nearly everything.  Definitely good to let
>> people know.
>>
>> On Sun, Jun 20, 2021 at 7:43 AM Ben Gamari  wrote:
>>
>>> Harendra Kumar  writes:
>>>
>>> > I see the following errors when compiling with ghc head version:
>>> >
>>> > $ ghc-stage2 --version
>>> > The Glorious Glasgow Haskell Compilation System, version 9.3.20210608
>>> >
>>> > $ cabal build --with-compiler ghc-stage2 --allow-newer
>>> >
>>> > Data/Colour/CIE.hs:80:12: error:
>>> > Ambiguous occurrence ‘sum’
>>> > It could refer to
>>> >either ‘Prelude.sum’,
>>> >   imported from ‘Prelude’ at Data/Colour/CIE.hs:25:8-22
>>> >   (and originally defined in ‘Data.Foldable’)
>>> >or ‘Data.List.sum’,
>>> >   imported from ‘Data.List’ at Data/Colour/CIE.hs:41:1-16
>>> >   (and originally defined in ‘GHC.List’)
>>> >|
>>> > 80 |total = sum $ map fst l
>>> >|^^^
>>> >
>>> > Can someone briefly describe this change and what's the recommended
>>> way of
>>> > fixing this? Just hide the Data.List definition? I do not see this
>>> > mentioned in the release notes of 9.2/9.4 here:
>>> > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html
>>> >
>>> Indeed, this is due to the monomorphic Data.List proposal, which the
>>> CLC decided would accompany the addition of Data.List.singleton. The
>>> correct fix here is to either qualify the import of `Data.List` or add
>>> an explicit import list. I'll try to remember to add a note about this
>>> to the release notes and migration guide.
>>>
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
> ___
> ghc-devs mailing 
> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

[Carter Schonwald]

Agreed and better articulated than what I likely would have said

On Thu, Jun 17, 2021 at 8:38 AM Sam Derbyshire 
wrote:

> Hi Christiaan,
>
> As far as I'm concerned that's a worrying regression, and I think you
> should file a ticket on the GHC tracker about it.
> I believe GHC already contains logic to avoid expanding type synonyms in
> error messages in certain situations, but it apparently doesn't apply here.
> Hopefully someone more knowledgeable about this can chime in.
>
> Sam
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: abstract interpreter for GHC Core or STG

[Carter Schonwald]

How would this be used to generate the rts automatically? I’m intrigued /
would like to understand what you’re envisioning design wise for that leg.

On Tue, Jun 8, 2021 at 5:34 PM Csaba Hruska  wrote:

> Cmm is too low level, I've implemented the primops in haskell in a high
> level way, including the out of line primops with the rts related parts
> (scheduler, io manager).
> see:
>
> https://github.com/grin-compiler/ghc-whole-program-compiler-project/blob/master/external-stg-interpreter/lib/Stg/Interpreter/ThreadScheduler.hs
>
> https://github.com/grin-compiler/ghc-whole-program-compiler-project/tree/master/external-stg-interpreter/lib/Stg/Interpreter/PrimOp
>
> STM is still missing though, but IMO it would be similar to
> concurrency/exception related primops.
> Regarding the ghcjs STM implementation, IMO the primops needs to be
> implemented at least in Haskell in a pure way with ADTs to be easy for
> reasoning.
> But thanks for the reference.
>
> Currently, I'm in the design phase. I.e. I need to design the abstract
> domain of the STG machine values.
>
> If this approach succeeds then it would be interesting to apply the
> calculating correct compilers method on the stg interpreter to get a
> compiler form it.
> With this level of automation it would be extremely easy to support new
> target platforms, because the RTS would be generated automatically.
>
> On Tue, Jun 8, 2021 at 10:51 PM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> The stm impl In ghcjs might be a helpful comparative example on that
>> front.
>>
>> Though I guess more broadly does this necessitate having a model of the
>> Cmm semantics for the out of line primops ?
>>
>> On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <
>> ghc-devs@haskell.org> wrote:
>>
>>> I wonder if there was an attempt in the past to create an abstract
>>> interpreter for GHC Core or STG to approximate the program runtime
>>> behaviour?
>>>
>>>
>>>
>>> No, not that I know of.   Because of all the primops, concurrency, STM,
>>> etc, it would be something of a challenge.  The AAM story could be
>>> interesting…
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-devs  *On Behalf Of *Csaba
>>> Hruska
>>> *Sent:* 07 June 2021 15:18
>>> *To:* GHC developers 
>>> *Subject:* abstract interpreter for GHC Core or STG
>>>
>>>
>>>
>>> Hello,
>>>
>>>
>>>
>>> I wonder if there was an attempt in the past to create an abstract
>>> interpreter for GHC Core or STG to approximate the program runtime
>>> behaviour?
>>>
>>> I'm curious because I'd like to turn my external STG interterpreter to
>>> an abstract interpreter using the AAM (Abstracting Abstract Machines)
>>> method.
>>>
>>> This approach seems promising to me because a single Haskell code base
>>> (ext STG interpreter) could be the specification of the Haskell operational
>>> semantics and also be a detailed static analyzer that could help
>>> optimization transformations.
>>>
>>> I'm interested in any attempt that happened during GHC/Haskell evolution.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Csaba Hruska
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: abstract interpreter for GHC Core or STG

[Carter Schonwald]

The stm impl In ghcjs might be a helpful comparative example on that front.

Though I guess more broadly does this necessitate having a model of the Cmm
semantics for the out of line primops ?

On Tue, Jun 8, 2021 at 5:10 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> I wonder if there was an attempt in the past to create an abstract
> interpreter for GHC Core or STG to approximate the program runtime
> behaviour?
>
>
>
> No, not that I know of.   Because of all the primops, concurrency, STM,
> etc, it would be something of a challenge.  The AAM story could be
> interesting…
>
>
>
> Simon
>
>
>
> *From:* ghc-devs  *On Behalf Of *Csaba
> Hruska
> *Sent:* 07 June 2021 15:18
> *To:* GHC developers 
> *Subject:* abstract interpreter for GHC Core or STG
>
>
>
> Hello,
>
>
>
> I wonder if there was an attempt in the past to create an abstract
> interpreter for GHC Core or STG to approximate the program runtime
> behaviour?
>
> I'm curious because I'd like to turn my external STG interterpreter to an
> abstract interpreter using the AAM (Abstracting Abstract Machines) method.
>
> This approach seems promising to me because a single Haskell code base
> (ext STG interpreter) could be the specification of the Haskell operational
> semantics and also be a detailed static analyzer that could help
> optimization transformations.
>
> I'm interested in any attempt that happened during GHC/Haskell evolution.
>
>
>
> Regards,
>
> Csaba Hruska
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: abstract interpreter for GHC Core or STG

[Carter Schonwald]

Correction it was Thomas schilling !!
And you can Google his Phd thesis trace based just in time compilation for
lazy functional programming languages

And the associated code is on his GitHub nominolo/ lambdachine though I
think it was last touched 7 years ago

On Mon, Jun 7, 2021 at 11:54 AM Carter Schonwald 
wrote:

> I’m not aware of any currently.
>
> I would be curious about the now relatively old work that Max bolingbroke
> did for his PhD (I think it was sortah a ghc to Lua JIT?!?)
>
> An important question is : what questions do you want the abstract
> interpreter to suport?
>
> On Mon, Jun 7, 2021 at 10:19 AM Csaba Hruska 
> wrote:
>
>> Hello,
>>
>> I wonder if there was an attempt in the past to create an abstract
>> interpreter for GHC Core or STG to approximate the program runtime
>> behaviour?
>> I'm curious because I'd like to turn my external STG interterpreter to an
>> abstract interpreter using the AAM (Abstracting Abstract Machines) method.
>> This approach seems promising to me because a single Haskell code base
>> (ext STG interpreter) could be the specification of the Haskell operational
>> semantics and also be a detailed static analyzer that could help
>> optimization transformations.
>> I'm interested in any attempt that happened during GHC/Haskell evolution.
>>
>> Regards,
>> Csaba Hruska
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: abstract interpreter for GHC Core or STG

[Carter Schonwald]

I’m not aware of any currently.

I would be curious about the now relatively old work that Max bolingbroke
did for his PhD (I think it was sortah a ghc to Lua JIT?!?)

An important question is : what questions do you want the abstract
interpreter to suport?

On Mon, Jun 7, 2021 at 10:19 AM Csaba Hruska  wrote:

> Hello,
>
> I wonder if there was an attempt in the past to create an abstract
> interpreter for GHC Core or STG to approximate the program runtime
> behaviour?
> I'm curious because I'd like to turn my external STG interterpreter to an
> abstract interpreter using the AAM (Abstracting Abstract Machines) method.
> This approach seems promising to me because a single Haskell code base
> (ext STG interpreter) could be the specification of the Haskell operational
> semantics and also be a detailed static analyzer that could help
> optimization transformations.
> I'm interested in any attempt that happened during GHC/Haskell evolution.
>
> Regards,
> Csaba Hruska
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: value of documenting error messages?

[Carter Schonwald]

Yes! Thanks for articulating it so nicely

On Thu, Jun 3, 2021 at 2:51 PM Alan & Kim Zimmerman 
wrote:

> I think in practical terms for IDE-based people, a short standardised
> alphanumeric identifier makes sense. These typically get displayed along
> with the full error text in the error pane, and it helps to be able to
> allocate a known, standard amount of real estate to them.  Fundamentally
> they are just an index into something else, you will either copy/paste it,
> or click on it.
>
> Alan
>
> On Wed, 2 Jun 2021 at 20:16, Jakob Brünker 
> wrote:
>
>> For what it's worth, there is an existing proposal about this topic,
>> maybe that's the right place to discuss it for a user-focused perspective.
>>
>> See https://github.com/ghc-proposals/ghc-proposals/pull/325
>>
>> Jakob
>>
>> On Wed, Jun 2, 2021 at 9:10 PM Tom Ellis <
>> tom-lists-haskell-cafe-2...@jaguarpaw.co.uk> wrote:
>>
>>> On Wed, Jun 02, 2021 at 07:03:25PM +, Richard Eisenberg wrote:
>>> > > To me this seems like a rare opportunity to do something where people
>>> > > will say "Hey look, that formidable Haskell compiler is doing
>>> > > something that's friendlier than the equivalent in any other
>>> > > compiler!".  For such an important user-facing feature I don't
>>> > > understand why we're not asking users what they prefer.
>>> >
>>> > I agree completely here! Let's ask! (Remember that this thread,
>>> > posted to ghc-devs, was originally about documenting the GHC source
>>> > code, something that would not affect users.)
>>>
>>> Yes indeed.  Let's one of us start a user-focused thread elsewhere
>>> (whoever gets round to it first) and post a link here so interested
>>> parties here can join in.
>>>
>>> Tom
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: value of documenting error messages?

[Carter Schonwald]

And just generally having a short code and descriptive name both, allows
useful toooling and human communication.

If we want to be careful / hedge against errors/ warnings  being slightly
different over time, these descriptive names / error codes should also be
documented with respect to the ghc version being used.

For example, I  remember in ghc 8.2 or so for example that for certain type
family uses that were actually fine that ghc would warn that allow
ambiguous types.  Richard may recall this better than I.  The important
piece is that in at least some cases, the full meaning and interpretation
of various warnings has definitely changed over ghc versions as various
analyses get fancier or simpler or bug fixed.

So in some respects, at least historically: for sufficiently fancy code,
the context of meaning for a given error code / message will only be
unambiguous if we interpret it knowing the specific ghc version.

I presume this will still be true? Should we always talk about error code
ghc version pairs rather than error codes? If so should the error rendering
be like ghc9_4_1:E2433 as a sortah URI ?

On Wed, Jun 2, 2021 at 11:24 AM Ruben Astudillo 
wrote:

> I am no GHC developer, so this is not my place to reply. Even though I
> humbly would like to put an argument in favor of numbers.
>
> On 02-06-21 06:46, Tom Ellis wrote:
> > On Tue, Jun 01, 2021 at 03:40:57PM -0700, Alec Theriault wrote:
> >> Rust has taken an interesting approach for this: every error message is
> >> given a unique number like "E0119"
> >
> > Is there a particularly strong reason to use numbers as codes when we
> > have the entire space human-readable strings available to us?  Even
> > the subset of case-insensitive strings formed from alphanumeric
> > characters plus underscore seems more suitable for the encoding than
> > positive integers.
> >
> > e.g. "conflicting_trait_implementations" seems better than "E0119"
>
> One is SEO-optimization. A number like #0119 on a search string like "ghc
> error #0119" ought to have as a first result the GHC user docs. This is a
> great user experience for students. A more general search string can have
> more results on other languages and is difficult to say we would be first
> result.
>
> Second one is that a number is shorter than a general string. That way we
> can highlight it on a error message on the terminal without occupying to
> much space. Current messages in GHC are already too big.
>
> --
> -- Rubén
> -- pgp: 4EE9 28F7 932E F4AD
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Coding style: Using StandaloneKindSignatures in GHC

[Carter Schonwald]

Yeah that’s roughly exactly it

On Mon, May 24, 2021 at 4:37 PM chessai  wrote:

> The CLC owns base, with final say coming down to listed maintainers.
> Though in practise, it ends up being a collective opinion of the CLC + GHC
> HQ that drives decisions, rather than one person.
>
>
> On Mon, May 24, 2021, 15:28 Oleg Grenrus  wrote:
>
>> To clarify, are you suggesting guidelines for GHC **and** base-library?
>>
>> I'm puzzled about ownership of base. Who have a final word about it?
>> ghc-devs, librar...@haskell.org, CLC, chessai alone, whoever is first?
>>
>> - Oleg
>> On 21.5.2021 23.21, Richard Eisenberg wrote:
>>
>> I agree with Chris here.
>>
>> Let me expand upon my counter-proposal:
>>
>> * A datatype declaration gets a standalone kind signature whenever at
>> least one of its type arguments has a kind other than Type.
>> * A class declaration gets a standalone kind signature whenever at least
>> one of its type arguments has a kind other than Type.(*)
>> * A closed type family always gets a standalone kind signature.
>> * A type synonym gets a standalone kind signature whenever either at
>> least one of its arguments has a kind other than Type or its result has a
>> kind other than Type.
>>
>> (*) The class rule has an exception: if a class has a superclass
>> constraint using Monad, Functor, Applicative, Foldable, or Traversable (or
>> some other class whose name textually includes one of those names, such as
>> MonadIO), we understand that the constrained variable must have kind Type
>> -> Type. If that type variable is the only one without kind Type -> Type,
>> then the standalone kind signature is optional.
>>
>> In cases other than those covered above, the standalone kind signature is
>> optional, at the discretion of the programmer.
>>
>> This suggests that Dict gets a signature, Eq does not, Fix does, and
>> Either does not.
>>
>> Richard
>>
>> On May 21, 2021, at 12:37 PM, Chris Smith  wrote:
>>
>> On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal 
>> wrote:
>>
>>> > encouraging the use of a standalone signature for type declarations
>>> where at least one parameter of the datatype does not have kind Type.
>>>
>>> So Dict, Eq both get a sig but Fix and Either do not?
>>>
>>>   type Dict :: Constraint -> Type
>>>   type Eq   :: Type -> Constraint
>>>   type Fix  :: (Type -> Type) -> Type
>>
>>
>>  That's not how I understand Richard's criteria.  Dict and Fix have
>> non-Type parameters (Dict has a Constraint parameter, and Fix has a (Type
>> -> Type) parameter.  On the other hand, Eq and Either have only Types as
>> parameters.  This seems to match my intuition about when a kind signature
>> might be helpful, as well as yours as far as I can tell from what you wrote.
>>
>> That's not to say I am advocating any kind of rule.  As I'm not really
>> involved in GHC development, I refrain from having any opinion.  I just
>> think you may have misread Richard's suggestion.
>>
>>
>>
>> ___
>> ghc-devs mailing 
>> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Coding style: Using StandaloneKindSignatures in GHC

[Carter Schonwald]

Silly question: when will stand alone kind sigs speed up type checking
phase of compilation?

Cause that would be an interesting argument in favor :)

On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal  wrote:

> > encouraging the use of a standalone signature for type declarations
> where at least one parameter of the datatype does not have kind Type.
>
> So Dict, Eq both get a sig but Fix and Either do not?
>
>   type Dict :: Constraint -> Type
>   type Eq   :: Type -> Constraint
>   type Fix  :: (Type -> Type) -> Type
>
> It's sensible to exclude tired tropes like `Type` and `Type -> Type`
> but higher-order functors (like Fix) warrant a signature.
>
> Caveat: The kind of type synonyms, type families and data families is
> not necessarily determined by counting the syntactic arguments of X
> like for a `data' declaration as Y could be a type, a functor, a
> bifunctor..
>
>   type X = Y
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC and the future of Freenode

[Carter Schonwald]

I’ll try again.

On Wed, May 19, 2021 at 10:26 PM Mario Carneiro 
wrote:

> Speaking as a *heavy* user of the Rust and Lean zulip instances, I find it
> a huge improvement over the alternatives of Gitter and Discord, and I think
> IRC although I have not used IRC much. It takes some getting used to, but
> the topic threading is absolutely essential once you reach a certain size.
> Looking at other chat platforms, overlapping conversations are a major
> problem when you have more than around 10 people online at once. Rust
> routinely has 50 or more online at once, and channels help but even then
> you will have multiple topics in a single channel, and that extra level of
> organization is absolutely warranted. It also helps when you want to look
> back at the discussion (or even just find it again!) or continue an old
> conversation from a year ago. Most of these activities I couldn't even
> imagine doing in a Gitter/Discord style chat platform.
>
> I have no stake in this discussion, but I thought I should balance out the
> Zulip downvotes with some positive experiences. (Also, I would definitely
> be more likely to participate on a haskell Zulip than an IRC or Matrix
> instance, FWIW.)
>
>
> Mario Carneiro
>
> On Wed, May 19, 2021 at 9:58 PM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> I definitely find Zulip confusing and have failed to use it every time
>> I’ve tried
>>
>> If normal threading is lasagna layers, Zulip threading is like trying to
>> hold cooked spaghetti in your ha d.
>>
>> On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn 
>> wrote:
>>
>>> (I'm a little ashamed that I lurk on this list but the thing that brings
>>> me out of lurking is a post on communication technologies)
>>>
>>> Not Zulip.
>>>
>>> Please not Zulip.
>>>
>>> I've used Zulip once many years ago, and once this year. Both times, its
>>> interface felt clunky, and it felt like it was trying to get the best of
>>> IRC, Slack, and a BBS and instead getting the worst of all the worlds.
>>> Synchronous communication was confusing, asynchronous communication was
>>> limited, and topics and channels didn't really do anything to organize
>>> things.
>>>
>>> I have two alternatives to add to consideration:
>>> * Mattermost: it's an open-source clone of Slack, which has its
>>> advantages and disadvantages, but at least it's familiar and heavily used UI
>>> * Discourse: it's an asynchronous communication tool, but that may
>>> acceptable or preferable, and there is already a Haskell Discourse set up (
>>> https://discourse.haskell.org/)
>>>
>>> On Wed, May 19, 2021 at 11:59 AM Ben Gamari  wrote:
>>>
>>>> Carter Schonwald  writes:
>>>>
>>>> > I personally vote for irc.  Perhaps via Libera.
>>>> >
>>>> > What are some example vibrant  technical communities on matrix? I’ve
>>>> > experienced such on irc but less so via more recent / newer platforms
>>>> >
>>>> I know that many subcommunities within the Rust community use Matrix. I
>>>> have had quite good interactions in this context. Frankly I think that
>>>> most of these newer options are technically much more conducive to
>>>> technical collaboration than IRC.
>>>>
>>>> Cheers,
>>>>
>>>> - Ben
>>>>
>>>> ___
>>>> ghc-devs mailing list
>>>> ghc-devs@haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC and the future of Freenode

[Carter Schonwald]

I definitely find Zulip confusing and have failed to use it every time I’ve
tried

If normal threading is lasagna layers, Zulip threading is like trying to
hold cooked spaghetti in your ha d.

On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn 
wrote:

> (I'm a little ashamed that I lurk on this list but the thing that brings
> me out of lurking is a post on communication technologies)
>
> Not Zulip.
>
> Please not Zulip.
>
> I've used Zulip once many years ago, and once this year. Both times, its
> interface felt clunky, and it felt like it was trying to get the best of
> IRC, Slack, and a BBS and instead getting the worst of all the worlds.
> Synchronous communication was confusing, asynchronous communication was
> limited, and topics and channels didn't really do anything to organize
> things.
>
> I have two alternatives to add to consideration:
> * Mattermost: it's an open-source clone of Slack, which has its advantages
> and disadvantages, but at least it's familiar and heavily used UI
> * Discourse: it's an asynchronous communication tool, but that may
> acceptable or preferable, and there is already a Haskell Discourse set up (
> https://discourse.haskell.org/)
>
> On Wed, May 19, 2021 at 11:59 AM Ben Gamari  wrote:
>
>> Carter Schonwald  writes:
>>
>> > I personally vote for irc.  Perhaps via Libera.
>> >
>> > What are some example vibrant  technical communities on matrix? I’ve
>> > experienced such on irc but less so via more recent / newer platforms
>> >
>> I know that many subcommunities within the Rust community use Matrix. I
>> have had quite good interactions in this context. Frankly I think that
>> most of these newer options are technically much more conducive to
>> technical collaboration than IRC.
>>
>> Cheers,
>>
>> - Ben
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC and the future of Freenode

[Carter Schonwald]

I personally vote for irc.  Perhaps via Libera.

What are some example vibrant  technical communities on matrix? I’ve
experienced such on irc but less so via more recent / newer platforms

On Wed, May 19, 2021 at 8:57 AM Ben Gamari  wrote:

> Hi all,
>
> As you may have heard the Freenode IRC network, long the home of #ghc
> and several other prominent Haskell channels, appears to be in the
> middle of a rather nasty hostile takeover [1,2,3,4]. As a consequence,
> it seems it will be necessary to migrate the #ghc community elsewhere.
>
> The next question is, of course, where will this be. One option is
> Liberachat, the spiritual successor of Freenode. However, in recent
> years I have also heard an increasingly loud choir of users,
> contributors, and potential-contributors note how archane IRC feels when
> compared to other modern chat platforms. Using IRC effectively in a
> collaborative environment essentially requires that all parties use a
> bouncer; however, this is (understandably) isn't something that most users
> are willing to do.
>
> Consequently, I think it would be wise to expand our search space to
> include other FOSS platforms. At the moment, I can see the following
> options:
>
>  1. Remain on IRC and move to Liberachat, the spiritual successor of
> Freenode
>
>  2. Remain on IRC and move to OFTC, another widely used network
>
>  3. Move to [Matrix]
>
>  4. Move to [Zulip]
>
> My sense is that of the non-IRC options Matrix is the truest successor
> to IRC, being a federated protocol with a wide array of (if somewhat
> immature) clients. I know some of our contributors already use it and in
> principle one could configure an IRC-to-Matrix bridge for those existing
> contributors who would rather continue using IRC.
>
> Zulip, while also being FOSS, is far more centralized than Matrix and
> appears to be more of a chat web application than an open protocol.
>
> Do you know of any other options? Thoughts?
>
> Cheers,
>
> - Ben
>
>
>
> [1]: https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
> [2]: https://fuchsnet.ch/freenode-resign-letter.txt
> [3]: https://gist.github.com/aaronmdjones/1a9a93ded5b7d162c3f58bdd66b8f491
> [4]: https://mniip.com/freenode.txt
> [Matrix]: https://www.matrix.org/
> [Zulip]:
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Compiling libraries

[Carter Schonwald]

Thanks for pulling that up! I was doing errands away from my desktop all
day

On Thu, Apr 29, 2021 at 5:43 PM Artem Pelenitsyn 
wrote:

> Yes, in particular, this:
> https://gitlab.haskell.org/ghc/head.hackage
>
> Readme there has some documentation…
>
> On Thu, Apr 29, 2021 at 3:19 PM Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> There’s hackage head, which has some docs on the gitlab instance. Though
>> I’m not up to date on how to use it.
>>
>> On Thu, Apr 29, 2021 at 4:24 AM Simon Peyton Jones via ghc-devs <
>> ghc-devs@haskell.org> wrote:
>>
>>> Ben and other friends
>>>
>>> What is the approved way to build libraries with (and for) a compiler
>>> that I’ve just built?
>>>
>>> I tried this:
>>>
>>> bash$ cabal v2-install
>>> --with-ghc=/home/simonpj/code/ghc-9.2-branch/inplace/bin/ghc-stage2
>>> streamly --allow-newer
>>>
>>> but it failed with
>>>
>>> Data/Primitive/Types.hs:273:844: error:
>>>
>>> • Couldn't match expected type ‘Word#’ with actual type ‘Word8#’
>>>
>>> • In the fourth argument of ‘shimmedSetWord8Array#’, namely ‘x#’
>>>
>>> (This was for a compiler built from the ghc-9.2 branch.)
>>>
>>> I’d like to be able to do the same for HEAD.
>>>
>>> I need to do this to help with the numerous tickets asking about library
>>> regressions.  For example, I want to be able repoduce @harendra’s
>>> example <https://gitlab.haskell.org/ghc/ghc/-/issues/19557#note_348969>,
>>> but I can’t because I can’t build streamly.
>>>
>>> Thanks!
>>>
>>> Simon
>>>
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Compiling libraries

[Carter Schonwald]

There’s hackage head, which has some docs on the gitlab instance. Though
I’m not up to date on how to use it.

On Thu, Apr 29, 2021 at 4:24 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Ben and other friends
>
> What is the approved way to build libraries with (and for) a compiler that
> I’ve just built?
>
> I tried this:
>
> bash$ cabal v2-install
> --with-ghc=/home/simonpj/code/ghc-9.2-branch/inplace/bin/ghc-stage2
> streamly --allow-newer
>
> but it failed with
>
> Data/Primitive/Types.hs:273:844: error:
>
> • Couldn't match expected type ‘Word#’ with actual type ‘Word8#’
>
> • In the fourth argument of ‘shimmedSetWord8Array#’, namely ‘x#’
>
> (This was for a compiler built from the ghc-9.2 branch.)
>
> I’d like to be able to do the same for HEAD.
>
> I need to do this to help with the numerous tickets asking about library
> regressions.  For example, I want to be able repoduce @harendra’s example
> , but I
> can’t because I can’t build streamly.
>
> Thanks!
>
> Simon
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: magicDict

[Carter Schonwald]

This makes sense to me, and provides a good explanation  for why I mix up
the terms.

So usual parlance is reify brings stuff back down/ reflect bounces it up?

On Fri, Apr 23, 2021 at 2:16 AM Spiwack, Arnaud 
wrote:

> While I do value consistency, let me pet-peeve for a minute here (sorry in
> advance Edward for the rant). The word “reify” comes from the latin “res”,
> which means object/thing. It should always mean something along the line of
> “making more concrete”. In normalisation by evaluation, for instance, you
> reify a semantic value as syntax (an object of the language of study), and
> you reflect values of the language into the semantic domain.
>
> To me, the reflection library uses the terms inconsistently. For instance
> you have the type ReifiedMonoid for the concrete type representing a
> monoid instance. This is, in my opinion, the right terminology. However, a
> ReifiedMonoid should be the product of reification, but in the reflection
> library it actually gets reify-d further. This doesn’t seem to work at
> the grammar level. I contend that the function should have been reflect
> all along: you reflect a concrete dictionary object into the nebulous,
> untouchable world of type class instances.
>
> It’s probably too late to fix the reflection library, hence me never
> complaining about it (in public :-) ). But I vote we don’t perpetuate this
> situation, and still call the function reflectDict.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does GHC implement layout?

[Carter Schonwald]

while not totally perfectly related, i have wondered if something like the
the recent pika parsing paper https://arxiv.org/abs/2005.06444 could be
used to provide better error recovery  from layout related errors in
haskell and similar languages.

On Sun, Apr 4, 2021 at 6:19 PM Alexis King  wrote:

> On 4/4/21 1:52 PM, Iavor Diatchki wrote:
>
> Hi Alexis,
>
> I wasn't sure what the "alternative layout" is either and did some
> googling, and it appears that it is something that was never really
> documented properly.   The following link contains pointers to the commit
> that introduced it (in 2009!)  (not the main ticket but some of the
> comments)
>
> Thanks, that’s a helpful pointer, though of course it still doesn’t
> explain very much. I’m still interested in understanding what the purpose
> of “alternative layout” is and how it operates, if anyone else has any idea.
>
> Overall, I do think that Haskell's layout rule is more complicated than it
> needs to be, and this is mostly because of the rule that requires the
> insertion of a "virtual close curly" on a parse error.
>
> Yes, this does seem to be by far the trickiest bit. But I’d be sad not to
> have it, as without it, even simple things like
>
> let x = 3 in e
>
> would not be grammatically valid.
>
> My feeling is that it'd be pretty tricky to do layout in the parser with
> grammar rules, but you may be able to do something with the parser state.
>
> Yes, I have some vague ideas, but none of them are particularly fleshed
> out. It’s entirely possible that I just don’t understand the relationship
> between the lexer and the parser (which seems somewhat obscured by the
> “alternative layout” stuff), and the ideas I have are what’s already
> implemented today. I’ll have to study the implementation more closely.
>
> In any case, thank you for your response! The ALR-related pointer
> certainly clarifies at least a little.
>
> Alexis
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type inference of singular matches on GADTs

[Carter Schonwald]

i like how you've boiled down this discussion, it makes it much clearer to
me at least :)

On Sun, Mar 28, 2021 at 10:19 PM Richard Eisenberg  wrote:

>
>
> On Mar 26, 2021, at 8:41 PM, Alexis King  wrote:
>
> If there’s a single principal type that makes my function well-typed *and
> exhaustive*, I’d really like GHC to pick it.
>
>
> I think this is the key part of Alexis's plea: that the type checker take
> into account exhaustivity in choosing how to proceed.
>
> Another way to think about this:
>
> f1 :: HList '[] -> ()
> f1 HNil = ()
>
> f2 :: HList as -> ()
> f2 HNil = ()
>
>
> Both f1 and f2 are well typed definitions. In any usage site where both
> are well-typed, they will behave the same. Yet f1 is exhaustive while f2 is
> not. This isn't really about an open-world assumption or the possibility of
> extra cases -- it has to do with what the runtime behaviors of the two
> functions are. f1 never fails, while f2 must check a constructor tag and
> perhaps throw an exception.
>
> If we just see \HNil -> (), Alexis seems to be suggesting we prefer the f1
> interpretation over the f2 interpretation. Why? Because f1 is exhaustive,
> and when we can choose an exhaustive interpretation, that's probably a good
> idea to pursue.
>
> I haven't thought about how to implement such a thing. At the least, it
> would probably require some annotation saying that we expect `\HNil -> ()`
> to be exhaustive (as GHC won't, in general, make that assumption). Even
> with that, could we get type inference to behave? Possibly.
>
> But first: does this match your understanding?
>
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Options for targeting Windows XP?

[Carter Schonwald]

In terms of net amount of work: I suspect ghcjs targeting either node or
some sort of browser plug-in may be the most humane assuming associated
browser / node suport on xp is turn key.  I think there were some genuine
changes to the io manager (the Haskell code in base for doing efficient
file system api stuff)  on windows plus a few other things.  There may have
also been changes elsewhere that andreask and Tamar and ben gamari can
speak to better.

More broadly, there’s so many bug fixes and improvements that you’d miss
out on if you don’t try to keep yourself current within the 3 most recent
ghc major version releases wrt associated libraries.

On Wed, Mar 24, 2021 at 10:09 AM Clinton Mead  wrote:

> I'm currently trying to bring my company around to using a bit of Haskell.
> One issue is that a number of our clients are based in South East Asia and
> need software that runs on Windows XP.
>
> Unfortunately it seems the last version of GHC that produces executables
> that run on Windows XP is GHC 7.10. Whilst this table
>  suggests
> the issue may only running GHC 8.0+ on Windows XP, I've confirmed that GHC
> 8.0 executables (even "Hello World") will not run on Windows XP, presumably
> because a non-XP WinAPI call in the runtime.
>
> My first thought would be to restrict myself to GHC 7.10 features (i.e.
> 2015). This would be a slight annoyance but GHC 7.10 still presents a
> reasonable language. But my concern would be that increasingly I'll run
> into issues with libraries that use extensions post GHC 7.10, particularly
> libraries with large dependency lists.
>
> So there's a few options I've considered at this point:
>
> 1. Use GHCJS to compile to Javascript, and then dig out a version of
> NodeJS that runs on Windows XP. GHCJS seems to at least have a compiler
> based on GHC 8.6.
> 2. Patch GHC with an additional command line argument to produce XP/Vista
> compatible executables, perhaps by looking at the changes between 7.10 ->
> 8.0, and re-introducing the XP approach as an option.
>
> The issue with 1 is that is that as well as being limited by how up to
> date GHCJS is, this will increase install size, memory usage and decrease
> performance on Windows XP machines, which are often in our environments
> quite old and resource and memory constrained.
>
> Approach 2 is something I'd be willing to put some work into if it was
> practical, but my thought is that XP support was removed for a reason,
> presumably by using newer WinAPI functions simplified things significantly.
> By re-adding in XP support I'd be complicating GHC once again, and GHC will
> effectively have to maintain two approaches. In addition, in the long term,
> whenever a new WinAPI call is added one would now have to check whether
> it's available in Windows XP, and if it's not produce a Windows XP
> equivalent. That might seem like just an extra burden of support for
> already busy GHC developers. But on the other hand, if the GHC devs would
> be happy to merge a patch and keep up XP support this would be the cleanest
> option.
>
> But then I had a thought. If GHC Core isn't supposed to change much
> between versions is it? Which made me come up with these approaches:
>
> 3. Hack up a script to compile programs using GHC 9 to Core, then feed
> that Core output into GHC 7.10. OR
> 4. Produce a chimera style GHC by importing the GHC 9.0 API and the GHC
> 7.10 API, and making a version of GHC that does Haskell -> Core in GHC 9.0
> and the rest of the code generation in GHC 7.10.
>
> One issue with 4 will be that presumably that because I'm importing GHC
> 9.0 API and the 7.10 API separately, all their data types will technically
> be separate, so I'll need to basically deep copy the GHC 9.0 core datatype
> (and perhaps others) to GHC 7.10 datatypes. But presuming their largely
> similar this should be fairly mechanical.
>
> So are any of these approaches (well, particularly 2 and 4) reasonable? Or
> am I going to run into big problems with either of them? Is there another
> approach I haven't thought of?
>
> Thanks,
> Clinton
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Running ghc-debug on ghc

[Carter Schonwald]

This looks really cool!
So it’s like a debugger that can also do heap introspection profiling as a
consequence of being able to inspect the state as part of debugging?

On Tue, Mar 9, 2021 at 10:23 AM Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> Hi,
>
> I now have some simple instructions for running ghc-debug on GHC.
>
> 1. Cherry-pick 4be70967f1f1ab70cbe31aad8ae69aea87c6f4c4
>
> commit 4be70967f1f1ab70cbe31aad8ae69aea87c6f4c4 (HEAD ->
> wip/ghc-with-debug)
> Author: Matthew Pickering 
> Date:   Fri Jan 8 11:26:17 2021 +
>
> Add support for ghc-debug to ghc executable
>
> 2. Build GHC
> * Add the following to _build/hadrian.settings
>
> ```
> stage1.*.ghc.hs.opts += -finfo-table-map -fdistinct-constructor-tables
> ```
>
> * Build GHC as normal
>
> ```
> ./hadrian/build -j8
> ```
>
> * The result is a ghc-debug enabled compiler
>
> # Building a debugger
>
> * Use the compiler you just built to build ghc-debug
>
> ```
> cd ghc-debug
> cabal update
> cabal new-build debugger -w ../_build/stage1/bin/ghc
> ```
>
> # Running the debugger
>
> Modify `test/Test.hs` to implement the debugging thing you want to do.
> Perhaps
> start with `p30`, which is a program to generate a profile.
>
>
> * Start the process you want to debug
> ```
> GHC_DEBUG_SOCKET=/tmp/ghc-debug build-cabal
> ```
>
> * Start the debugger
> ```
> cabal new-run debugger -w ...
> ```
>
> * Open a ticket about the memory issue you find.
>
> There is the start of some more documentation here -
> http://ghc.gitlab.haskell.org/ghc-debug/docs.html
>
> These instructions are also in the instructions.md file in the commit.
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Requesting help with unregisterized backend failure of !4717

[Carter Schonwald]

Isn’t the unregisterized backend a c compiler? You should check what gcc
and clang or whoever we use handles those issues

On Mon, Mar 8, 2021 at 6:56 PM John Ericson 
wrote:

> Hi everyone,
>
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717 fails some
> numerical boundary checking tests with the unregisterized backend. In
> particular, `minBound / (-1)` and `pred minBound` are *not* diverging as
> expected. This stumped me a few days ago, and no new ideas have struct
> me since. I would very much appreciate some help.
>
> This does seem like something that is very likely to be
> backend-dependent, as different instructions/arches handle such edge
> cases in different ways. What makes this so peculiar, however, is that
> the boundary condition checking/branching is done *in regular Haskell*.
> I'm thus quite baffled as to what could be going wrong.
>
> If anyone wants to dive in, see my last comment
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_329840,
> which has a minimization to declutter the code without doing enough
> constant folding that the problem is avoided entirely. (I went with a
> compilation unit trick, but in hindsight NOINLINE should also work and
> be simpler.)
>
> Finally, let my provide some context for why I am hoping to get this
> merged soon. To be clear, !4492 was the main MR relating to the numerics
> primops critical to get in for 9.2 and it thankfully already landed. But
> landing this MR too would be nice: It shrinks the intermediate
> representations of numerical code probably smaller than it was
> originally, whereas now it is perhaps larger than it was before due to
> more size<->native conversions. Also, I think this MR will help get
> !3658 over the finish line, which, while again not as critical for 9.2
> as !4492 was, would be awfully nice to do to fully realize the new
> simplicity of the plan set forth in
> https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics.
>
> Thanks,
>
> John
>
> N.B. I just rebased and repushed the MR, so CI might be still running or
> failing due to something else, but based on local testing this is still
> the an issue. https://gitlab.haskell.org/ghc/ghc/-/pipelines/31002 is an
> earlier pipeline run that one can look at until CI finishes again.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 9.1?

[Carter Schonwald]

As ben says, a lot of our tools have made choices over time that make
having the odd vs even convention super easy to support for compiler and
library devs doing experiments with ghc builds that are based off master.

No matter what, any naming scheme is a social construct for communicating
with tools and humans.  And I def agree that “how to interpret a ghc
version number” is a useful thing to make more readily explained, any
convention that changes the way cabal/library authors can experiments to
suport / evaluate how features in an unreleased ghc work for them has a
nontrivial engineering cost footprint.

On Tue, Mar 2, 2021 at 7:26 AM Ben Gamari  wrote:

> Sebastian Graf  writes:
>
> > Hi,
> >
> > I generally would like +0.1 steps, but mostly because it causes less
> > head-scratching to everyone new to Haskell. Basically the same argument
> as
> > Richard says.
> >
> > I can't comment on how far head.hackage (or any tool relies) on odd
> version
> > numbers, I certainly never have. Given that it's all overlays (over which
> > we have complete control), does it really matter anyway? When would we
> say
> > <=9.1 rather than <=9.2? Shouldn't 9.1 at one point become binary
> > compatible with 9.2, as if it really was "9.2.-1" (according to the PVP,
> > 9.2.0 is actually > 9.2, so that won't work)? I think there are multiple
> > ways in which we could avoid using 9.1 as the namespace for "somewhere
> > between 9.0 and 9.2 exclusively". We have alpha releases, so why don't we
> > name it 9.1.nightly?
> >
> One reason is that our versioning data model (as captured by Data.Version)
> now only admits numeric version components. Textual tags were previously
> admitted but deprecated in #2496 as there is no clear ordering for such
> versions.
>
>
> >> majormajor.odd.time stamp
> >
> > TBH, I found the fact that the *configure* date (I think?) is embedded in
> > the version rather annoying. I sometimes have two checkouts configured at
> > different dates but branching off from the same base commit, so I'm
> pretty
> > sure that interface files are compatible. Yet when I try to run one
> > compiler on the package database of the other (because I might have
> copied
> > a compiler invocation from stdout that contained an absolute path), I get
> > an error due to the interface file version mismatch. I'd rather have a
> > crash or undefined behavior than a check based on the configure date,
> > especially since I'm just debugging anyway.
>
> I disagree here. Personally, if I do something non-sensical I would much
> rather get predictable version error than be sent off on a wild-goose chase
> debugging ghosts. Fixing an incorrect command-line takes a few seconds;
> finding a bizarre runtime crash due to subtly wrong ABI may take days.
> This is why I generally plop any test command-line of non-trivial length
> into a shell script; it makes safely switching between compilers much
> easier.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 9.1?

[Carter Schonwald]

It makes determining if a ghc build was a dev build vs a tagged release
much easier.  Odd == I’m using a dev build because it reports a version
like majormajor.odd.time stamp right ? — we still donthat with dev /master
right?

At some level any versioning notation is a social convention, and this one
does have a good advantage of making dev builds apparent while letting
things like hackage head have coherent versioning for treating these
releases sanely?

Otoh. It’s all a social construct. So any approach that helps all relevant
communities is always welcome.  Though even numbers are nice ;)

On Mon, Mar 1, 2021 at 11:30 PM Richard Eisenberg  wrote:

> Hi devs,
>
> I understand that GHC uses the same version numbering system as the Linux
> kernel did until 2003(*), using odd numbers for unstable "releases" and
> even ones for stable ones. I have seen this become a point of confusion, as
> in: "Quick Look just missed the cutoff for GHC 9.0, so it will be out in
> GHC 9.2" "Um, what about 9.1?"
>
> Is there a reason to keep this practice? Linux moved away from it 18 years
> ago and seems to have thrived despite. Giving this convention up on a new
> first-number change (the change from 8 to 9) seems like a good time.
>
> I don't feel strongly about this, at all -- just asking a question that
> maybe no one has asked in a long time.
>
> Richard
>
> (*) I actually didn't know that Linux stopped doing this until writing
> this email, wondering why we needed to tie ourselves to Linux. I
> coincidentally stopped using Linux full-time (and thus administering my own
> installation) in 2003, when I graduated from university.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?

[Carter Schonwald]

Don’t forget ghc 9 is already out! :)

On Mon, Feb 15, 2021 at 2:10 PM Troels Henriksen  wrote:

> It is very likely that issue 17386 is the issue.  With
>
> {-# OPTIONS_GHC -Wno-overlapping-patterns -Wno-incomplete-patterns
> -Wno-incomplete-uni-patterns -Wno-incomplete-record-updates #-}
>
> my module(s) compile very quickly.  I'll wait and see if GHC 9 does
> better before I try to create a smaller case (and now I at least have a
> workaround).
>
> Sebastian Graf  writes:
>
> > Hi,
> >
> > I'm not sure I see all the context of the conversation, but it is
> entirely
> > possible that code with many local constraints regresses the
> pattern-match
> > checker (which is accounted to Desugaring in the profile emitted by -v2),
> > I'm afraid. That simply has to do with the fact that we now actually care
> > about them, previously they were mostly discarded.
> >
> > I'd be glad if you submitted a relatively isolated reproducer of what is
> > fast with 8.8 and slow with 8.10 (even better 9.0).
> > I hope that things have improved since we fixed
> > https://gitlab.haskell.org/ghc/ghc/-/issues/17836, which is part of 9.0
> but
> > not of 8.10.
> >
> > Cheers,
> > Sebastian
> >
> > Am Mo., 15. Feb. 2021 um 19:04 Uhr schrieb Troels Henriksen <
> > at...@sigkill.dk>:
> >
> >> Carter Schonwald  writes:
> >>
> >> > Ccing ghc devs since that’s a better forum perhaps
> >> > Crazy theory:
> >> >
> >> > this is a regression due the the partial changes to pattern matching
> >> > coverage checking in 8.10 that finished / landed in ghc 9
> >> >
> >> > Why:
> >> > Desugaring is when pattern/ case statement translation happens I
> think?
> >> > And the only obvious “big thing” is that you have some huge , albeit
> sane
> >> > for a compiler, pattern matching
> >> >
> >> > I’d first check if the new ghc 9 release doesn’t have that regression
> in
> >> > build time that you experienced.  And if it does file a ticket.
> >> >
> >> > I may be totally wrong, but that seems like a decent likelihood !
> >>
> >> You may be right!  Another module that regressed is also mainly
> >> characterised by large-but-not-insane case expressions:
> >>
> >>
> https://github.com/diku-dk/futhark/blob/d0839412bdd11884d75a1494dd5de5191833f39e/src/Futhark/Optimise/Simplify/Rules.hs
> >>
> >> I'll try to split these modules up a little bit (I should have done so a
> >> while ago anyway) and maybe that will make the picture even clearer.
> >>
> >> --
> >> \  Troels
> >> /\ Henriksen
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
>
> --
> \  Troels
> /\ Henriksen
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Pattern matching desugaring regression? Re: [Haskell-cafe] Why does my module take so long to compile?

[Carter Schonwald]

Ccing ghc devs since that’s a better forum perhaps
Crazy theory:

this is a regression due the the partial changes to pattern matching
coverage checking in 8.10 that finished / landed in ghc 9

Why:
Desugaring is when pattern/ case statement translation happens I think?
And the only obvious “big thing” is that you have some huge , albeit sane
for a compiler, pattern matching

I’d first check if the new ghc 9 release doesn’t have that regression in
build time that you experienced.  And if it does file a ticket.

I may be totally wrong, but that seems like a decent likelihood !


On Mon, Feb 15, 2021 at 12:20 PM Troels Henriksen  wrote:

> Carter Schonwald  writes:
>
> > How big are your data types in the file In question? Do you ghc generics
> or
> > deriving or template Haskell? Could you share a link to the file in
> > question ?
>
> The file does not define any large data types itself, but it operates on
> some fairly large data types (an AST, it's a compiler).  But so do many
> other modules that work just fine.  It uses no generics, nontrivial
> deriving, or Template Haskell.  It's this file:
>
> https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKernels/DistributeNests.hs
>
> I also found a handful of other modules in my project that are
> significantly slower to compile in GHC 8.10, and seemingly also because
> of the desugarer, but none of them have any obvious smoking guns like
> generics or TH.
>
> The only commonality I can find is that the affected modules contain
> functions with a relatively large typeclass context.  I use
> ConstraintKinds to make them more concise, and I guess unfolded there
> may be 30-40 equality/class constraints in total.  Like this:
>
> type DistLore lore =
>   ( Bindable lore,
> HasSegOp lore,
> BinderOps lore,
> LetDec lore ~ Type,
> ExpDec lore ~ (),
> BodyDec lore ~ ()
>   )
>
> where the 'Bindable' constraint in particular then implies a further
> handful of "~" constraints:
>
> class
>   ( ASTLore lore,
> FParamInfo lore ~ DeclType,
> LParamInfo lore ~ Type,
> RetType lore ~ DeclExtType,
> BranchType lore ~ ExtType,
> SetType (LetDec lore)
>   ) =>
>   Bindable lore
>   where
>   ...
>
> FParamInfo/LParamInfo/etc are type families.  Are such constraints
> particularly slow?
>
> --
> \  Troels
> /\ Henriksen
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: safe to upgrade my Mac?

[Carter Schonwald]

8.10.3 works on every more recent OS X.

That said, I’m waiting for cabal 3.4 Release, which 8.10 can build, before
I do the Big Sur update.

On Thu, Jan 28, 2021 at 2:35 AM Alfredo Di Napoli <
alfredo.dinap...@gmail.com> wrote:

> Hi Richard,
>
> I am running 10.15.7 and I think I upgraded to Catalina months ago (but I
> don't exactly recall when). From my experience, everything works just fine,
> at least for my current workflow (clients' projects, GHC development etc).
> At work I have successfully used GHC 8.6.5 and 8.10.2 for various projects,
> both with Cabal and Stack and didn't experience any major problems.
>
> In terms of performance, I cannot judge. If it got slower, I certainly
> didn't notice.
>
> I hope it helps! :)
>
> A.
>
> On Wed, 27 Jan 2021 at 22:29, Merijn Verstraaten 
> wrote:
>
>>
>> > On 27 Jan 2021, at 21:56, Richard Eisenberg  wrote:
>> > I'm currently running MacOS High Sierra, 10.13.6. Things are fine, but
>> I'd like to upgrade to get Dark Mode and (hopefully) to speed up Mail.
>> (That is, upgrading is nice, but not at all necessary.)
>>
>> I just (finally) upgraded to Catalina last week and the 8.10.2 bindist
>> works just fine (you have to fiddle with xattr after unzipping, there's an
>> issue on gitlab that has the right command in there). If you're going to
>> Mojave then there's 0 issues. Big Sur I haven't tried yet.
>>
>> > If I upgrade, will GHC hate me? That is, will GHC 8.10 continue to
>> work? Will I continue to be able to compile GHC? Will it be as performant?
>> (A few years ago, I had a strange issue on a secondary computer where any
>> binary built by GHC was horribly slow; we never got to the bottom of it.)
>>
>> I didn't notice any performance regressions, but I also haven't paid
>> close attention.
>>
>> - Merijn
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Debugging annotation machinery

[Carter Schonwald]

I don’t have good debugging wisdom, but I’d love to know what hash
functions you’re considering!

On Mon, Jan 4, 2021 at 2:22 AM Phyx  wrote:

> Hi,
>
> I am changing the hashing algorithm used to create Fingerprints but
> somehow the annrun01.hs test has started failing and I don't quite
> understand why.
>
> From what I can tell the failure happens during deserialization but the
> module itself is still found.
> The calls findGlobalAnns deserializeWithData target seem to return nothing.
>
> Calling ~/ghc/inplace/bin/ghc-stage2.exe --show-iface Annrun01_Help.hi
> shows that GHC itself understands the module fine though.
>
> Does someone have an idea why deserialization might be failing? but also
> how does one debug this? Almost none of the structures have a Show or
> Outputable instance...
>
> Thanks,
> Tamar
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Use of forall as a sigil

[Carter Schonwald]

I do think explaining it relative to the explicit vs implicit arg syntax of
agda function argument syntax.

f:  Forall a . B is used with f x. This relates to the new forall ->
syntax.

g: forall {c}. D is used either as f or f {x}, aka implicit or forcing it
to be explicit.  This maps to our usual Haskell forall with explicit {}
being the @ analogue

On Wed, Nov 18, 2020 at 12:09 PM Iavor Diatchki 
wrote:

> Semantically, `forall a -> a -> Int` is the same as `forall a. a -> Int`.
> The two only differ in how you use them:
>   * For the first one, you have to explicitly provide the type to use for
> `a` at every call site, while
>   * for the second one, you usually omit the type and let GHC infer it.
>
> So overall I think it's a pretty simple idea. For me it's hard to see that
> from the text in #281, but I think a lot of the complexity there
> is about a fancy notation for explicitly providing the type at call sites.
>
> -Iavor
>
>
>
> On Wed, Nov 18, 2020 at 9:51 AM Richard Eisenberg 
> wrote:
>
>> Hi Bryan,
>>
>> First off, sorry if my first response was a bit snippy -- it wasn't meant
>> to be, and I appreciate the angle you're taking in your question. I just
>> didn't understand it!
>>
>> This second question is easier to answer. I say "forall a arrow a arrow
>> Int".
>>
>> But I still think there may be a deeper question here left unanswered...
>>
>> Richard
>>
>> On Nov 18, 2020, at 6:11 AM, Bryan Richter  wrote:
>>
>> Yeah, sorry, I think I'm in a little over my head here. :) But I think I
>> can ask a more answerable question now: how does one pronounce "forall a ->
>> a -> Int"?
>>
>> Den tis 17 nov. 2020 16:27Richard Eisenberg  skrev:
>>
>>> Hi Bryan,
>>>
>>> I don't think I understand what you're getting at here. The difference
>>> between `forall b .` and `forall b ->` is only that the choice of b must be
>>> made explicit. Importantly, a function of type e.g. `forall b -> b -> b`
>>> can *not* pattern-match on the choice of type; it can bind a variable that
>>> will be aliased to b, but it cannot pattern-match (say, against Int). Given
>>> this, can you describe how `forall b ->` violates your intuition for the
>>> keyword "forall"?
>>>
>>> Thanks!
>>> Richard
>>>
>>> > On Nov 17, 2020, at 1:47 AM, Bryan Richter  wrote:
>>> >
>>> > Dear forall ghc-devs. ghc-devs,
>>> >
>>> > As I read through the "Visible 'forall' in types of terms"
>>> > proposal[1], I stumbled over something that isn't relevant to the
>>> > proposal itself, so I thought I would bring it here.
>>> >
>>> > Given
>>> >
>>> >f :: forall a. a -> a   (1)
>>> >
>>> > I intuitively understand the 'forall' in (1) to represent the phrase
>>> > "for all". I would read (1) as "For all objects a in Hask, f is some
>>> > relation from a to a."
>>> >
>>> > After reading the proposal, I think my intuition may be wrong, since I
>>> > discovered `forall a ->`. This means something similar to, but
>>> > practically different from, `forall a.`. Thus it seems like 'forall'
>>> > is now simply used as a sigil to represent "here is where some special
>>> > parameter goes". It could as well be an emoji.
>>> >
>>> > What's more, the practical difference between the two forms is *only*
>>> > distinguished by ` ->` versus `.`. That's putting quite a lot of
>>> > meaning into a rather small number of pixels, and further reduces any
>>> > original connection to meaning that 'forall' might have had.
>>> >
>>> > I won't object to #281 based only on existing syntax, but I *do*
>>> > object to the existing syntax. :) Is this a hopeless situation, or is
>>> > there any possibility of bringing back meaning to the syntax of
>>> > "dependent quantifiers"?
>>> >
>>> > -Bryan
>>> >
>>> > [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281
>>> > ___
>>> > ghc-devs mailing list
>>> > ghc-devs@haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC's internal confusion about Ints and Words

[Carter Schonwald]

... are you talking about Haskell Int and word? Those are always the same
size in bits and should match native point size. That is definitely an
assumption of ghc

It sounds like some information that is dropped after core is needed to
correctly do something in stg/cmm in the context of the ARM64 ncg that was
recently added to handle cint being 32bit in this context ?


On Tue, Oct 20, 2020 at 5:49 AM Moritz Angermann 
wrote:

> Alright, let me expand a bit.  I've been looking at aarch64 NCG for ghc.
> The Linux side of things is looking really good,
> so I've moved onto the macOS side (I'm afraid I don't have any Windows
> aarch64 hardware, nor much windows knowledge
> to even attempt a Windows version yet).
>
> When calling C functions, the usual approach is to pass the first few
> arguments in registers, and then arguments that exceed
> the argument passing slots on the stack.  The Arm AArch64 Procedure Call
> Standard (aapcs) for C does this by assigning 8byte
> slots to each overflow argument on the stack.  A company I won't name, has
> decided to implement a slightly different variation of
> the Procedure Call Standard, often referred to as darwinpcs.  This
> deviates from the aapcs for vargs, as well as for handling of
> spilled arguments on the stack.
>
> The aapcs allows us to generate calls to C functions without knowing the
> actual prototype of the function, as all arguments are
> simply spilled into 8byte slots on the stack.  The darwinpcs however
> requires us to know the size of the arguments, so we can
> properly pack them onto the stack.  Ints have 4 bytes, so we need to pack
> them into 4byte slots.
>
> In the process library we have this rather fun foreign import:
> foreign import ccall unsafe "runInteractiveProcess"
>   c_runInteractiveProcess
> ::  Ptr CString
> -> CString
> -> Ptr CString
> -> FD
> -> FD
> -> FD
> -> Ptr FD
> -> Ptr FD
> -> Ptr FD
> -> Ptr CGid
> -> Ptr CUid
> -> CInt -- reset child's SIGINT & SIGQUIT
> handlers
> -> CInt -- flags
> -> Ptr CString
> -> IO PHANDLE
>
> with the corresponding C declaration:
>
> extern ProcHandle runInteractiveProcess( char *const args[],
>  char *workingDirectory,
>  char **environment,
>  int fdStdIn,
>  int fdStdOut,
>  int fdStdErr,
>  int *pfdStdInput,
>  int *pfdStdOutput,
>  int *pfdStdError,
>  gid_t *childGroup,
>  uid_t *childUser,
>  int reset_int_quit_handlers,
>  int flags,
>  char **failed_doing);
> This function thus takes 14 arguments. We pass only the first 8 arguments
> in registers, and the others on the stack.
> Argument 12 and 13 are of type int.  On linux using the aapcs, we can pass
> those in 8byte slots on the stack. That is
> both of them are effectively 64bits wide when passed.  However for
> darwinpcs, it is expected that these adhere to their
> size and are packed as such. Therefore Argument 12 and 13 need to be
> passed as 4byte slots each on the stack.
>
> This yields a moderate 8byte saving on the stack for the same function
> call on darwinpcs compared to aapcs.
>
> Now onto GHC.  When we generate function calls for foreign C functions, we
> deal with something like:
>
> genCCall
> :: ForeignTarget  -- function to call
> -> [CmmFormal]-- where to put the result
> -> [CmmActual]-- arguments (of mixed type)
> -> BlockId-- The block we are in
> -> NatM (InstrBlock, Maybe BlockId)
>
> based on Cmm Nodes of the form CmmUnsafeForeignCall target result_regs
> args
>
> The CmmActual in the care of runInteractiveProcess hold the arguments for
> the function, however contrary to the function
> declaration, it contains I64 slots for Argument 12 and 13. Thus computing
> the space needed for them based on their Cmm
> Representations yields 8bytes, when they should really be 32bit and
> consume only 4 byte.
>
> To illustrate this a bit better: here is what we see in the pretty printed
> cmm:
>
> (_s6w3::I64) = call "ccall" arg hints:  [PtrHint, PtrHint, PtrHint,
> signed, signed, signed, PtrHint, PtrHint, PtrHint, PtrHint, PtrHint,
> signed, signed, PtrHint]  result hints:  [signed]
> _runInteractiveProcess(I64[Sp + 96], I64[Sp + 88], I64[Sp + 104], I64[Sp +
> 112], I64[Sp + 120], I64[Sp + 56], I64[Sp + 64], I64[Sp + 72], I64[Sp +
> 24], 0, 0, I64[Sp + 8], I64[Sp + 40] | I64[Sp + 48] | I64[Sp 

Re: Fwd: Restricted sums in BoxedRep

[Carter Schonwald]

Ryan: would an unboxed value Mvar, Eg to write StrictMvar (), avoid
creating extra gc pressure / traversal a?

On Thu, Oct 15, 2020 at 4:23 PM Ryan Yates  wrote:

> Ah yes.  In my research work I extended Mutable Constructor fields to
> allow a mutable array field to help with that problem.  This allowed me to
> have a Nil constructor in a sum type and a Node constructor with normal
> fields as well as an array of mutable fields.  Pointer tagging worked as
> expected so a case match on a dereference of a field would not need to
> follow the pointer and no intermediate objects were between Node objects.
>
>
>
> On Thu, Oct 15, 2020 at 4:08 PM David Feuer  wrote:
>
>> This might be lost in the noise for MVar and TVar, but for arrays, there
>> are tremendous advantages to cutting out the extra heap objects.
>>
>> On Thu, Oct 15, 2020, 1:10 PM Ryan Yates  wrote:
>>
>>> I haven't been following this discussion too closely, but in my research
>>> work I found that some of the benefits that I wanted in this direction were
>>> already there with pointer tagging.
>>>
>>> On Thu, Oct 15, 2020 at 12:59 PM David Feuer 
>>> wrote:
>>>
>>>> Yes, that's something quite different. We'd need a whole different heap
>>>> object type for such MVars and TVars. My approach covers the case where the
>>>> unboxed thing can only take on a few values, for some value of "a few"
>>>> which, depending on implementation, may or may not be very small. If the
>>>> nulls point to actual heap objects in pre-allocated pinned memory (say),
>>>> then up to 64 or so might be reasonable. If they point to "invalid" address
>>>> space, then the numbers could go up a good bit.
>>>>
>>>> On Thu, Oct 15, 2020, 12:50 PM Carter Schonwald <
>>>> carter.schonw...@gmail.com> wrote:
>>>>
>>>>> Indeed, I mean things that aren’t pointery, and could be represented
>>>>> by a tvar paired with a mutable byte array or mvar with mutable byte 
>>>>> array,
>>>>> but which we’d want considered as a single heap object from the rts/gc
>>>>> perspective.
>>>>>
>>>>> On Thu, Oct 15, 2020 at 11:58 AM David Feuer 
>>>>> wrote:
>>>>>
>>>>>> Sorry, unlifted, not unboxed...
>>>>>>
>>>>>> On Thu, Oct 15, 2020, 11:57 AM David Feuer 
>>>>>> wrote:
>>>>>>
>>>>>>> Putting unboxed things in TVar, MVar, etc., is part of Andrew
>>>>>>> Martin's accepted BoxedRep proposal.
>>>>>>>
>>>>>>> On Thu, Oct 15, 2020, 11:44 AM Carter Schonwald <
>>>>>>> carter.schonw...@gmail.com> wrote:
>>>>>>>
>>>>>>>> A related idea that came up recently and is perhaps simpler ties
>>>>>>>> into this via the lens of having unboxed Mvars/tvars (even if it’s
>>>>>>>> restricted to just things we can embed in a word64#)
>>>>>>>>
>>>>>>>> This came up in
>>>>>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/18798#note_307410,
>>>>>>>> where viktor had millions of independent mvars holding what’s 
>>>>>>>> essentially a
>>>>>>>> strict unit ()!
>>>>>>>>
>>>>>>>> The motivation in this later scenario is that in high concurrency
>>>>>>>> settings, the less trivial stuff the gc needs to trace under updates, 
>>>>>>>> the
>>>>>>>> better ghc scales.
>>>>>>>>
>>>>>>>> This may not be a use case david has in mind, but certainly seems
>>>>>>>> related.
>>>>>>>>
>>>>>>>> Phrased more succinctly: gc perf dominates large heap / many core
>>>>>>>> computation in Haskell via sensitivity to allocation volume / mutation
>>>>>>>> volume (to ensure generational hypothesis stays valid), and providing 
>>>>>>>> tools
>>>>>>>> to incrementally reduce the pressure with local changes would be good.
>>>>>>>>
>>>>>>>> So I’d propose / suggest that a baby step towards what david asks
>>>>>>>> would be for us to work out some manner of unboxed tvar/mvar ref 
>>>>>>>> 

Re: Fwd: Restricted sums in BoxedRep

[Carter Schonwald]

Indeed, I mean things that aren’t pointery, and could be represented by a
tvar paired with a mutable byte array or mvar with mutable byte array, but
which we’d want considered as a single heap object from the rts/gc
perspective.

On Thu, Oct 15, 2020 at 11:58 AM David Feuer  wrote:

> Sorry, unlifted, not unboxed...
>
> On Thu, Oct 15, 2020, 11:57 AM David Feuer  wrote:
>
>> Putting unboxed things in TVar, MVar, etc., is part of Andrew Martin's
>> accepted BoxedRep proposal.
>>
>> On Thu, Oct 15, 2020, 11:44 AM Carter Schonwald <
>> carter.schonw...@gmail.com> wrote:
>>
>>> A related idea that came up recently and is perhaps simpler ties into
>>> this via the lens of having unboxed Mvars/tvars (even if it’s restricted to
>>> just things we can embed in a word64#)
>>>
>>> This came up in
>>> https://gitlab.haskell.org/ghc/ghc/-/issues/18798#note_307410, where
>>> viktor had millions of independent mvars holding what’s essentially a
>>> strict unit ()!
>>>
>>> The motivation in this later scenario is that in high concurrency
>>> settings, the less trivial stuff the gc needs to trace under updates, the
>>> better ghc scales.
>>>
>>> This may not be a use case david has in mind, but certainly seems
>>> related.
>>>
>>> Phrased more succinctly: gc perf dominates large heap / many core
>>> computation in Haskell via sensitivity to allocation volume / mutation
>>> volume (to ensure generational hypothesis stays valid), and providing tools
>>> to incrementally reduce the pressure with local changes would be good.
>>>
>>> So I’d propose / suggest that a baby step towards what david asks would
>>> be for us to work out some manner of unboxed tvar/mvar ref machinery that
>>> supports unboxed values.
>>>
>>>
>>>
>>> On Thu, Oct 15, 2020 at 5:32 AM Andreas Klebinger <
>>> klebinger.andr...@gmx.at> wrote:
>>>
>>>> From a implementors perspective my main questions would be:
>>>>
>>>> * How big is the benefit in practice? How many use cases are there?
>>>> * How bad are the costs? (Runtime overhead, rts complexity, ...)
>>>>
>>>> The details of how this would be exposed to a user would are important.
>>>> But if the costs are too high for the drawbacks then it becomes a moot
>>>> point.
>>>>
>>>>
>>>> David Feuer schrieb am 14.10.2020 um 22:21:
>>>>
>>>> Forwarded from Andrew Martin below. I think we want more than just
>>>> Maybe (more than one null), but the nesting I described is certainly more
>>>> convenience than necessity.
>>>>
>>>> -- Forwarded message -
>>>> From: Andrew Martin 
>>>> Date: Wed, Oct 14, 2020, 4:14 PM
>>>> Subject: Re: Restricted sums in BoxedRep
>>>> To: David Feuer 
>>>>
>>>>
>>>> You'll have to forward this to the ghc-devs list to share it with
>>>> others since I'm not currently subscribed to it, but I've had this same
>>>> thought before. It is discussed at
>>>> https://github.com/andrewthad/impure-containers/issues/12. Here's the
>>>> relevant excerpt:
>>>>
>>>>> Relatedly, I was thinking the other day that after finishing
>>>>> implementing
>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0203-pointer-rep.rst,
>>>>> I should really look at seeing if it's possible to add this
>>>>> maybe-of-a-lifted value trick straight to GHC. I think that with:
>>>>>
>>>>> data RuntimpRep
>>>>>   = BoxedRep Levity
>>>>>   | MaybeBoxedRep Levity
>>>>>   | IntRep
>>>>>   | ...
>>>>>
>>>>> data BuiltinMaybe :: forall (v :: Levity). TYPE v -> TYPE ('MaybeBoxedRep 
>>>>> v)
>>>>>
>>>>> This doesn't have the nesting issues because the kind system prevents
>>>>> nesting. But anyway, back to the original question. I would recommend not
>>>>> using Maybe.Unsafe and using unpacked-maybe instead. The latter is
>>>>> definitely safe, and it only costs an extra machine word of space in each
>>>>> data constructor it gets used in, and it doesn't introduce more
>>>>> indirections.
>>>>>
>>>>
>>>> On Tue, Oct 13, 2020 at 5:47 PM David Feuer 

Re: Fwd: Restricted sums in BoxedRep

[Carter Schonwald]

A related idea that came up recently and is perhaps simpler ties into this
via the lens of having unboxed Mvars/tvars (even if it’s restricted to just
things we can embed in a word64#)

This came up in
https://gitlab.haskell.org/ghc/ghc/-/issues/18798#note_307410, where viktor
had millions of independent mvars holding what’s essentially a strict unit
()!

The motivation in this later scenario is that in high concurrency settings,
the less trivial stuff the gc needs to trace under updates, the better ghc
scales.

This may not be a use case david has in mind, but certainly seems related.

Phrased more succinctly: gc perf dominates large heap / many core
computation in Haskell via sensitivity to allocation volume / mutation
volume (to ensure generational hypothesis stays valid), and providing tools
to incrementally reduce the pressure with local changes would be good.

So I’d propose / suggest that a baby step towards what david asks would be
for us to work out some manner of unboxed tvar/mvar ref machinery that
supports unboxed values.



On Thu, Oct 15, 2020 at 5:32 AM Andreas Klebinger 
wrote:

> From a implementors perspective my main questions would be:
>
> * How big is the benefit in practice? How many use cases are there?
> * How bad are the costs? (Runtime overhead, rts complexity, ...)
>
> The details of how this would be exposed to a user would are important.
> But if the costs are too high for the drawbacks then it becomes a moot
> point.
>
>
> David Feuer schrieb am 14.10.2020 um 22:21:
>
> Forwarded from Andrew Martin below. I think we want more than just Maybe
> (more than one null), but the nesting I described is certainly more
> convenience than necessity.
>
> -- Forwarded message -
> From: Andrew Martin 
> Date: Wed, Oct 14, 2020, 4:14 PM
> Subject: Re: Restricted sums in BoxedRep
> To: David Feuer 
>
>
> You'll have to forward this to the ghc-devs list to share it with others
> since I'm not currently subscribed to it, but I've had this same thought
> before. It is discussed at
> https://github.com/andrewthad/impure-containers/issues/12. Here's the
> relevant excerpt:
>
>> Relatedly, I was thinking the other day that after finishing implementing
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0203-pointer-rep.rst,
>> I should really look at seeing if it's possible to add this
>> maybe-of-a-lifted value trick straight to GHC. I think that with:
>>
>> data RuntimpRep
>>   = BoxedRep Levity
>>   | MaybeBoxedRep Levity
>>   | IntRep
>>   | ...
>>
>> data BuiltinMaybe :: forall (v :: Levity). TYPE v -> TYPE ('MaybeBoxedRep v)
>>
>> This doesn't have the nesting issues because the kind system prevents
>> nesting. But anyway, back to the original question. I would recommend not
>> using Maybe.Unsafe and using unpacked-maybe instead. The latter is
>> definitely safe, and it only costs an extra machine word of space in each
>> data constructor it gets used in, and it doesn't introduce more
>> indirections.
>>
>
> On Tue, Oct 13, 2020 at 5:47 PM David Feuer  wrote:
>
>> Null pointers are widely known to be a lousy language feature in general,
>> but there are certain situations where they're *really* useful for compact
>> representation. For example, we define
>>
>> newtype TMVar a = TMVar (TVar (Maybe a))
>>
>> We don't, however, actually use the fact that (Maybe a) is lifted. So we
>> could represent this much more efficiently using something like
>>
>> newtype TMVar a = TMVar (TVar a)
>>
>> where Nothing is represented by a distinguished "null" pointer.
>>
>> While it's possible to implement this sort of thing in user code (with
>> lots of fuss and care), it's not very nice at all. What I'd really like to
>> be able to do is represent certain kinds of sums like this natively.
>>
>> Now that we're getting BoxedRep, I think we can probably make it happen.
>> The trick is to add a special Levity constructor representing sums of
>> particular shapes. Specifically, we can represent a type like this if it is
>> a possibly-nested sum which, when flattened into a single sum, consists of
>> some number of nullary tuples and at most one Lifted or Unlifted type.
>> Then we can have (inline) primops to convert between the BoxedRep and the
>> sum-of-sums representations.
>>
>> Anyone have thoughts on details for what the Levity constructor arguments
>> might look like?
>>
>
>
> --
> -Andrew Thaddeus Martin
>
>
> ___
> ghc-devs mailing 
> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: COMPLETE pragmas

[Carter Schonwald]

wonderful!

On Thu, Sep 3, 2020 at 12:22 PM Sebastian Graf  wrote:

> Hi folks,
>
> I implemented what I had in mind in
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3959. CI should turn
> green any hour now, so feel free to play with it if you want to.
> With the wonderful https://github.com/mpickering/ghc-artefact-nix it will
> just be `ghc-head-from 3959`.
>
> Cheers,
> Sebastian
>
> Am Di., 1. Sept. 2020 um 22:09 Uhr schrieb Joachim Breitner <
> m...@joachim-breitner.de>:
>
>> Am Dienstag, den 01.09.2020, 10:11 +0200 schrieb Sebastian Graf:
>> > > 2.) Another scenario that I'd really love to see supported with
>> > > COMPLETE pragmas is a way to use | notation with them like you can
>> > > with MINIMAL pragmas.
>> >
>> > (2) is a neat idea, but requires a GHC proposal I'm not currently
>> > willing to get into. I can also see a design discussion around
>> > allowing arbitrary "formulas" (e.g., not only what is effectively
>> > CNF).
>> >
>> > A big bonus of your design is that it's really easy to integrate into
>> > the current implementation, which is what I'd gladly do in case such
>> > a proposal would get accepted.
>>
>> in the original ticket where a COMPLETE pragma was suggested (
>> https://gitlab.haskell.org/ghc/ghc/-/issues/8779) the ability to
>> specify arbitrary boolean formulas was already present:
>>
>> “So here is what I think might work well, inspired by the new MINIMAL
>> pragma: … The syntax is essentially the same as for MINIMAL, i.e. a
>> boolean formula, with constructors and pattern synonyms as atoms. In
>> this case”
>>
>> So one _could_ say that this doesn’t need a proposal, because it would
>> just be the implementation finishing the original task ;-)
>>
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   m...@joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Logo

[Carter Schonwald]

I decided to look up the difference between tortoise and turtles, and
apparently the former are land critters. Plus have elephant style hind feet
to support their high load/ weight among the larger species due to being
land focused.
https://www.nationalgeographic.com/news/2017/12/shell-game--how-to-tell-a-turtle-from-a-tortoise/


So there’s a cute stable under load angle there ;) at least for a tortoise
/ land turtle angle

On Wed, Sep 2, 2020 at 12:08 PM John Cotton Ericson
 wrote:

>
>
>
>
>
>
>
>
>
>
> Yeah I think the old "functional programming is slow" memes died
>
> off about when the rest of the industry went on its JavaScript
>
> bender, so I am not really worried about the negative connotations
>
> of turtles.
>
>
> The positive connotations of turtles sounds very good to me.
>
> Besides safety,
>
>
>
>
>
>-  the longevity of at least giant tortoises also speaks to
>
>GHC's rare ability to stay at the vanguard of research while
>
>still being wildly used.
>
>- Their ability to walk and swim speaks to the diverse backends
>
>that can be attached to GHC (NCG, LLVM, GHCJS, Asterius,
>
>Clash's, etc.).
>
>- Even the fable, from which the slowness myth comes from I
>
>guess, goes well with "avoid success at all costs".
>
>
>
>
> Conversely I am not a fan of choosing a Cat. I like Cats fine in
>
> real life, don't get be wrong, but Cats are so popular on the
>
> internet that this would be the the unmarked animal choice, with
>
> no clear connotations or memorability. I think that would be the
>
> juvenile choice, per Ben's slippery slope.
>
>
>
>
> Foxes are nice, but I think Firefox has that for life.
>
>
> Octopuses are alright. GitHub's Octocat doesn't doesn't pose
>
> nearly as much of a problem as Firefox for foxes. Still, while
>
> Octopuses are smart, they are usually solitary and mischievous.
>
> GHC is very much a long-term group effort, belying the solitary
>
> connotation, and I certainly hope any compiler I use isn't
>
> mischievous!
>
>
>
>
> A turtle for a compiler is a bold choice that indicates our
>
> values, confidence that the performance of compiled code is immune
>
> to cheap derision, and humor.
>
>
> John
>
>
> P.S. The funny patterns on turtles' backs could be made of
>
> lambdas?...
>
>
> P.P.S. and yes, if it does compel us to fix rampant list
>
> appending just so we're fast on all fronts, that would be nice too
>
> :).
>
>
> On 9/2/20 11:47 AM, Ben Gamari wrote:
>
>
>
>
>
>
> Richard Eisenberg   writes:
>
>
>
>
>
>
>
> I'm oddly drawn to the idea of a turtle -- except that turtles are
>
> slow. But animals are cute. Maybe something involving a fox, given
>
> that foxes can be clever? Octopuses are also known to be very clever,
>
> but maybe GitHub has octopuses covered.
>
>
>
>
>
>
>
> In general I'm rather neutral on the logo question. There is a fine line
>
> between "juvenile" (which may detract from the project's credibility in
>
> the eyes of some) and "cute" (which I think is universally a Good
>
> Thing); the current rather boring logo was a quick attempt to satisfy
>
> the need for some logo while recognizing that I lack the artistic
>
> ability to walk that line. I don't think it's a bad logo but it's quite
>
> dull and far from being a *good* logo. I do hope someone steps up to do
>
> better.
>
>
>
> Logos aside, I do feel the need to correct the record here: you
>
> clearly have not seen how quickly a turtle can move when offered banana
>
> or shrimp. They can be quite quick when suitably incentivized!
>
>
>
> Cheers,
>
>
>
> - Ben
>
>
>
>
>
>
>
>
> ___
>
> ghc-devs mailing list
>
> ghc-devs@haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>
>
>
>
>
>
> ___
>
> ghc-devs mailing list
>
> ghc-devs@haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Logo

[Carter Schonwald]

Ghc is a turtle. So much super linearity in the code base and very much a
safety oriented tool ;)

On Wed, Sep 2, 2020 at 10:16 AM Richard Eisenberg  wrote:

> I'm oddly drawn to the idea of a turtle -- except that turtles are slow.
> But animals are cute. Maybe something involving a fox, given that foxes can
> be clever? Octopuses are also known to be very clever, but maybe GitHub has
> octopuses covered.
>
>
> On Sep 1, 2020, at 8:42 PM, Carter Schonwald 
> wrote:
>
> Ben, what if we have someone draw a cartoony version of your box turtle? i
> feel like that would be a pretty cute logo! totally ahistorical, but would
> certainly be cute!
>
> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov 
> wrote:
>
>> Hi,
>>
>> Is it a contest for picking up a new logo?
>> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
>> means Haskell.
>>
>> So logo should be GλC.
>>
>> Best Regards,
>> Daniil.
>>
>> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari  wrote:
>>
>>> Hi everyone,
>>>
>>>
>>>
>>>
>>>
>>> Recently a sponsor asked for a logo for our project. As far as I know,
>>>
>>>
>>> GHC doesn't really have a consistent logo; the closest that we have had
>>>
>>>
>>> is the stylized "GHC" on the top of ghc.haskell.org.
>>>
>>>
>>>
>>>
>>>
>>> To accomodate the request, I took a few minutes and reworked the
>>>
>>>
>>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>>>
>>>
>>> couldn't positively identify the typeface used for the "Haskell" text,
>>>
>>>
>>> but I believe that the extra-bold Cantarell face that I chose in the GHC
>>>
>>>
>>> variant has a similar feel to the Haskell logo and is free to use.
>>>
>>>
>>>
>>>
>>>
>>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>>>
>>>
>>> very much welcome.
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>>
>>> - Ben
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>>>
>>>
>>> ___
>>>
>>>
>>> ghc-devs mailing list
>>>
>>>
>>> ghc-devs@haskell.org
>>>
>>>
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>>
>>
>> ___
>>
>>
>> ghc-devs mailing list
>>
>>
>> ghc-devs@haskell.org
>>
>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Logo

[Carter Schonwald]

Mark lentzer (I’m almost certainly spelling his last name wrong)

On Wed, Sep 2, 2020 at 10:47 AM Bryan Richter  wrote:

> I have no idea who or where it came from, but I loved the owl from BayHac
> 2013. In my mind, it has always been the Haskell mascot (I was pretty new
> to the community in 2013).
>
> https://wiki.haskell.org/BayHac2013
>
> [image: image.png]
>
>
> On Wed, Sep 2, 2020 at 5:39 PM Ryan Yates  wrote:
>
>> Cats are warm and fuzzy.
>>
>> On Wed, Sep 2, 2020 at 10:38 AM Richard Eisenberg 
>> wrote:
>>
>>> On Sep 2, 2020, someone wrote to me privately saying:
>>>
>>> > I was thinking Cats for some reason.
>>>
>>> Ooh. I'm picturing a cat with its tail wrapped around a lambda, or
>>> something like that. And Simon PJ does have a cat named Haskell who could
>>> perhaps be the model. :)
>>>
>>> Richard
>>>
>>> On Sep 2, 2020, at 10:16 AM, Richard Eisenberg  wrote:
>>>
>>> I'm oddly drawn to the idea of a turtle -- except that turtles are slow.
>>> But animals are cute. Maybe something involving a fox, given that foxes can
>>> be clever? Octopuses are also known to be very clever, but maybe GitHub has
>>> octopuses covered.
>>>
>>> On Sep 1, 2020, at 8:42 PM, Carter Schonwald 
>>> wrote:
>>>
>>> Ben, what if we have someone draw a cartoony version of your box turtle?
>>> i feel like that would be a pretty cute logo! totally ahistorical, but
>>> would certainly be cute!
>>>
>>> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Is it a contest for picking up a new logo?
>>>> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ 
>>>> here
>>>> means Haskell.
>>>>
>>>> So logo should be GλC.
>>>>
>>>> Best Regards,
>>>> Daniil.
>>>>
>>>> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari  wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Recently a sponsor asked for a logo for our project. As far as I know,
>>>>>
>>>>>
>>>>> GHC doesn't really have a consistent logo; the closest that we have had
>>>>>
>>>>>
>>>>> is the stylized "GHC" on the top of ghc.haskell.org.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> To accomodate the request, I took a few minutes and reworked the
>>>>>
>>>>>
>>>>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>>>>>
>>>>>
>>>>> couldn't positively identify the typeface used for the "Haskell" text,
>>>>>
>>>>>
>>>>> but I believe that the extra-bold Cantarell face that I chose in the
>>>>> GHC
>>>>>
>>>>>
>>>>> variant has a similar feel to the Haskell logo and is free to use.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>>>>>
>>>>>
>>>>> very much welcome.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - Ben
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>>>>>
>>>>>
>>>>> ___
>>>>>
>>>>>
>>>>> ghc-devs mailing list
>>>>>
>>>>>
>>>>> ghc-devs@haskell.org
>>>>>
>>>>>
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>>
>>>>>
>>>>>
>>>>
>>>> ___
>>>>
>>>>
>>>> ghc-devs mailing list
>>>>
>>>>
>>>> ghc-devs@haskell.org
>>>>
>>>>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>>
>>>>
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>> ___
>>>
>>>
>>> ghc-devs mailing list
>>>
>>>
>>> ghc-devs@haskell.org
>>>
>>>
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>>
>>
>> ___
>>
>>
>> ghc-devs mailing list
>>
>>
>> ghc-devs@haskell.org
>>
>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>>
>
> ___
>
> ghc-devs mailing list
>
> ghc-devs@haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Logo

[Carter Schonwald]

Ben, what if we have someone draw a cartoony version of your box turtle? i
feel like that would be a pretty cute logo! totally ahistorical, but would
certainly be cute!

On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov  wrote:

> Hi,
>
> Is it a contest for picking up a new logo?
> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
> means Haskell.
>
> So logo should be GλC.
>
> Best Regards,
> Daniil.
>
> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari  wrote:
>
>> Hi everyone,
>>
>> Recently a sponsor asked for a logo for our project. As far as I know,
>> GHC doesn't really have a consistent logo; the closest that we have had
>> is the stylized "GHC" on the top of ghc.haskell.org.
>>
>> To accomodate the request, I took a few minutes and reworked the
>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>> couldn't positively identify the typeface used for the "Haskell" text,
>> but I believe that the extra-bold Cantarell face that I chose in the GHC
>> variant has a similar feel to the Haskell logo and is free to use.
>>
>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>> very much welcome.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>>
>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Implicit reboxing of unboxed tuple in let-patterns

[Carter Schonwald]

Have you tried using do notation for bindings you want to keep strict, with
Eg the identity monad?  That doesn’t address  the design critique but gives
you a path forward ?

I do agree that the semantics / default recursivity Of let bindings  can be
inappropriate for non recursive code , but would any other non uniform
semantics or optimization be safe?

On Fri, Aug 28, 2020 at 9:05 AM Spiwack, Arnaud 
wrote:

> Dear all,
>
>
> I discovered the hard way, yesterday, that lazy let pattern
> matching is allowed on unboxed tuples. And that it implicitly reboxes
> the pattern.
>
>
> Here is how the manual describes it, from the relevant section
> 
> :
>
>
>
>
> You can have an unboxed tuple in a pattern binding, thus
>
>
> f x = let (# p,q #) = h x in ..body..
>
>
>
> If the types of p and q are not unboxed, the resulting binding is lazy
> like any other Haskell pattern binding. The above example desugars like
> this:
>
>
> f x = let t = case h x of { (# p,q #) -> (p,q) }
>
>   p = fst t
>
>   q = snd t
>
>   in ..body..
>
>
>
> Indeed, the bindings can even be recursive.
>
>
>
>
> Notice how h x is lazily bound, hence won’t necessarily be run when
> body is forced. as opposed to if I had written, for instance,
>
>
> let u = hx
>
> in ..body..
>
>
>
> My question is: are we happy with this? I did find this extremely
> surprising. If I’m using unboxed tuples, it’s because I want to
> guarantee to myself a strict, unboxed behaviour. But a very subtle
> syntactic detail seems to break this expectation for me. My
> expectation would be that I would need to explicitly rebox things
> before they get lazy again.
>
>
> I find that this behaviour invites trouble. But you may disagree. Let
> me know!
>
>
>
>
> ___
>
> ghc-devs mailing list
>
> ghc-devs@haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Logo

[Carter Schonwald]

I def like the serif / times new Roman version

On Sat, Aug 15, 2020 at 11:42 AM Ben Gamari  wrote:

> Niklas Hambüchen  writes:
>
> > Hey Ben,
> >
> > it may make sense to make a copy of the SVG that has the font turned
> into paths;
> > for me it looks different in Firefox, Thunderbird, and eog, probably
> because I don't have the font installed.
> > (This is probably also why the logo is cut off for me in some of them).
>
> Sigh, of course. I've uploaded another version with path-ified text.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Decorating exceptions with backtrace information

[Carter Schonwald]

On Fri, May 8, 2020 at 9:32 AM Carter Schonwald 
wrote:

> ben, could you please email the libraries list with this too? This seems
> like a core libraries / base change rather than a ghc-the-compiler change
>
> On Thu, May 7, 2020 at 6:57 PM Michael Sloan  wrote:
>
>> Thanks so much for making a proposal for this, Ben!!  It's great to see
>> progress here.
>>
>> I'm also glad that there is now a proposal process.  I made a fairly
>> similar proposal almost exactly 5 years ago to the libraries list -
>> https://mail.haskell.org/pipermail/libraries/2015-April/025471.html -
>> but without the subtlety of particular backtrace representations.  Skimming
>> the ensuing thread may still be informative.
>>
>> In particular, there is one thing I would like to highlight from that old
>> proposal.  I think it'd be good to have a standard way to represent a chain
>> of exceptions, and build this into `catch` and `finally`.  Python and Java
>> both have a mechanism for this, and both refer to it as a "cause"
>> exception.  When an exception is thrown during exception handling, the
>> exception being handled is preserved as its "cause".  I find this mechanism
>> to be incredibly useful in Java, it has made the underlying issue much
>> clearer in many cases, and in other cases at least provides helpful
>> context.  I have no doubt such a mechanism would have saved me many hours
>> of debugging exceptions in Haskell systems I've worked on in the past.
>>
>> I considered commenting about that directly on the proposal, but I figure
>> this is a better place to suggest expanding the scope of the change :) .
>> Totally understandable if you want to keep this proposal focused on
>> stacktraces, but I think it'd be good to consider this as a potential
>> future improvement.
>>
>> -Michael
>>
>> On Thu, May 7, 2020 at 3:55 PM Ben Gamari  wrote:
>>
>>>
>>> Hi everyone,
>>>
>>> After a nice discussion on IRC about the unfortunate state of error
>>> reporting in Haskell, I felt compelled to write down some long-lingering
>>> thoughts regarding backtraces on exceptions. The result is GHC proposal
>>> #330 [1]. I think the approach is viable and perhaps even
>>> straightforward. I have the sketch of an implementation here [2].
>>>
>>> Please have a look at the proposal and leave your comments. If there is
>>> consensus it is possible that we could have this done for 8.12.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330
>>> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Decorating exceptions with backtrace information

[Carter Schonwald]

ben, could you please email the libraries list with this too? This seems
like a core libraries / base change rather than a ghc-the-compiler change

On Thu, May 7, 2020 at 6:57 PM Michael Sloan  wrote:

> Thanks so much for making a proposal for this, Ben!!  It's great to see
> progress here.
>
> I'm also glad that there is now a proposal process.  I made a fairly
> similar proposal almost exactly 5 years ago to the libraries list -
> https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but
> without the subtlety of particular backtrace representations.  Skimming the
> ensuing thread may still be informative.
>
> In particular, there is one thing I would like to highlight from that old
> proposal.  I think it'd be good to have a standard way to represent a chain
> of exceptions, and build this into `catch` and `finally`.  Python and Java
> both have a mechanism for this, and both refer to it as a "cause"
> exception.  When an exception is thrown during exception handling, the
> exception being handled is preserved as its "cause".  I find this mechanism
> to be incredibly useful in Java, it has made the underlying issue much
> clearer in many cases, and in other cases at least provides helpful
> context.  I have no doubt such a mechanism would have saved me many hours
> of debugging exceptions in Haskell systems I've worked on in the past.
>
> I considered commenting about that directly on the proposal, but I figure
> this is a better place to suggest expanding the scope of the change :) .
> Totally understandable if you want to keep this proposal focused on
> stacktraces, but I think it'd be good to consider this as a potential
> future improvement.
>
> -Michael
>
> On Thu, May 7, 2020 at 3:55 PM Ben Gamari  wrote:
>
>>
>> Hi everyone,
>>
>> After a nice discussion on IRC about the unfortunate state of error
>> reporting in Haskell, I felt compelled to write down some long-lingering
>> thoughts regarding backtraces on exceptions. The result is GHC proposal
>> #330 [1]. I think the approach is viable and perhaps even
>> straightforward. I have the sketch of an implementation here [2].
>>
>> Please have a look at the proposal and leave your comments. If there is
>> consensus it is possible that we could have this done for 8.12.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330
>> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: License for grammar

[Carter Schonwald]

Very cool!

Mit / bsd 3 or bsd 2 or Apache are all reasonable

On Tue, Mar 31, 2020 at 3:58 PM Евгений Слободкин 
wrote:

> Hi all!
>
> I implemented Haskell grammar for ANTLRv4 based on HaskellReport 2010
> and GHC source (Parser.y and Lexer.x files).
>
> Link: https://github.com/antlr/grammars-v4/blob/master/haskell/Haskell.g4
>
> Could someone please help me figuring out which license this grammar
> should be published on?
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: intent to enable 2fa requirement for github.com/haskell org

[Carter Schonwald]

Yeah, there’s def an incredible diversity of tools that are great in this
space.  And there’s at this point decent tools for almost every platform
constraint imaginable.

On Wed, Mar 25, 2020 at 1:30 PM Giorgio Marinelli 
wrote:

> I use the following 2fa tools. They offer also import/export
> functionalities.
>
> - andOTP (Android) https://github.com/andOTP/andOTP
> - OTPClient (Linux) https://github.com/paolostivanin/OTPClient
>
> Regards,
>
>
> Giorgio
>
> On Wed, 25 Mar 2020 at 17:48, Carter Schonwald
>  wrote:
> >
> > Duncan, David, please figure out 2fa tools that work for you  and enable
> them,
> >
> >
> > https://github.com/tadfisher/pass-otp
> >
> > https://github.com/solokeys/solo
> >
> > https://github.com/herrjemand/awesome-webauthn#hardware-authenticators
> >
> > https://1password.com/
> >
> > https://keepass.info/download.html
> >
> >
> > if you are having trouble figuring out tools you're comfortable using,
> please share with us those constraints we can help you!
> >
> > im here to help (and i'm delaying enabling another day or two to provide
> help to some active contributors who are having their own difficulties
> setitng up this stuff)
> >
> > On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts 
> wrote:
> >>
> >> On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> >> > hey everyone, because so much important stuff for the community, it
> >> > makes sense to add 2fa required for the org, are there any good
> >> > reasons to either wait to do this, or not do it? Feedback welcome!
> >>
> >> I think I might get cut off.
> >>
> >> Is it not still the case that github's 2fa needs a program running on a
> >> mobile phone, or an SMS-capable mobile phone? Is there any support for
> >> normal tools running on a normal Linux machine?
> >>
> >> (I think last time I tried to use the SMS route, it refused to send SMS
> >> messages to my landline, despite the fact that I can receive them)
> >>
> >>
> >> Duncan
> >>
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: intent to enable 2fa requirement for github.com/haskell org

[Carter Schonwald]

Duncan, David, please figure out 2fa tools that work for you  and enable
them,


https://github.com/tadfisher/pass-otp

https://github.com/solokeys/solo

https://github.com/herrjemand/awesome-webauthn#hardware-authenticators

https://1password.com/

https://keepass.info/download.html


if you are having trouble figuring out tools you're comfortable using,
please share with us those constraints we can help you!

im here to help (and i'm delaying enabling another day or two to provide
help to some active contributors who are having their own difficulties
setitng up this stuff)

On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts  wrote:

> On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> > hey everyone, because so much important stuff for the community, it
> > makes sense to add 2fa required for the org, are there any good
> > reasons to either wait to do this, or not do it? Feedback welcome!
>
> I think I might get cut off.
>
> Is it not still the case that github's 2fa needs a program running on a
> mobile phone, or an SMS-capable mobile phone? Is there any support for
> normal tools running on a normal Linux machine?
>
> (I think last time I tried to use the SMS route, it refused to send SMS
> messages to my landline, despite the fact that I can receive them)
>
>
> Duncan
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: intent to enable 2fa requirement for github.com/haskell org

[Carter Schonwald]

@ Simon: you already have 2fa enabled, youre not on the list of users who
do *not* have 2fa enabled. Its just an extra login prompt the first time
you login from a new device or do anything in the "are you sure you want to
do that change".

SO enabling 2fa is largely invisible to contributors aside from the 5
minutes to setup, and the message i sent out directly to every person who
would be impacted that hasn't already replied to this email thread listed a
number of options that could choose (though i should have also included a
url, but if anyones confused i hope they ask and I can help)

@richard  indeed, this is why i also directly and individually emailed
every member/contributor of the github haskell org individually (who
doesnt have 2fa setup).  Some of them dont have an easy to track down email
address!  Basically everyone who's been active in the past two years has
responded already or indicated they'll set it up this coming weekend.  (in
1-2 cases, it helped remind that they'd forgotten to setup 2fa even though
they had planned to )



On Thu, Mar 19, 2020 at 5:44 AM Richard Eisenberg  wrote:

>
>
> On Mar 18, 2020, at 11:52 PM, Carter Schonwald 
> wrote:
>
> After talking with several folks, feedback has been that best practices
> are to make sure the notice is a week before hand.
>
> So what I’ll do is personally reach out to those who aren’t 2fa enabled in
> the Haskell gh org (and haven’t commented on this thread )and ask them to
> enable 2fa on their GitHub account. Perhaps I should attach a 2fa options
> explainer !
>
> I’ll look at folks responses and if everyone active has made the switch
> over, I’ll look to do a transition next Monday or Tuesday.
>
>
> If best practices are to wait a week... shouldn't we wait a week? There's
> no fire here.
>
> Richard
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: intent to enable 2fa requirement for github.com/haskell org

[Carter Schonwald]

Awesome!

After talking with several folks, feedback has been that best practices are
to make sure the notice is a week before hand.

So what I’ll do is personally reach out to those who aren’t 2fa enabled in
the Haskell gh org (and haven’t commented on this thread )and ask them to
enable 2fa on their GitHub account. Perhaps I should attach a 2fa options
explainer !

I’ll look at folks responses and if everyone active has made the switch
over, I’ll look to do a transition next Monday or Tuesday.


Be well! (Nyc and many other places are pretty strange right now :/ )

-Carter

On Wed, Mar 18, 2020 at 7:42 PM Duncan Coutts  wrote:

> On Wed, 2020-03-18 at 19:05 -0400, Carter Schonwald wrote:
> > No. You don’t.  You can use a yubi key and or a totp tool like google
> > Authenticator or 1Password etc. no phones required
>
> It took me a while, but I have successfully managed to turn 2FA back
> into 1FA.
>
> In case it helps anyone else, generate your 2FA response with
>
> $ oathtool --totp -b $the-2fa-secret
>
> Where $the-2fa-secret is the code github gives you after the recovery
> codes (initially shown as a barcode, but they'll give you the actual
> code if you click the link).
>
> > On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts 
> wrote:
> > > On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> > > > hey everyone, because so much important stuff for the community, it
> > > > makes sense to add 2fa required for the org, are there any good
> > > > reasons to either wait to do this, or not do it? Feedback welcome!
> > >
> > > I think I might get cut off.
> > >
> > > Is it not still the case that github's 2fa needs a program running on a
> > > mobile phone, or an SMS-capable mobile phone? Is there any support for
> > > normal tools running on a normal Linux machine?
> > >
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: intent to enable 2fa requirement for github.com/haskell org

[Carter Schonwald]

No. You don’t.  You can use a yubi key and or a totp tool like google
Authenticator or 1Password etc. no phones required

On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts  wrote:

> On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote:
> > hey everyone, because so much important stuff for the community, it
> > makes sense to add 2fa required for the org, are there any good
> > reasons to either wait to do this, or not do it? Feedback welcome!
>
> I think I might get cut off.
>
> Is it not still the case that github's 2fa needs a program running on a
> mobile phone, or an SMS-capable mobile phone? Is there any support for
> normal tools running on a normal Linux machine?
>
> (I think last time I tried to use the SMS route, it refused to send SMS
> messages to my landline, despite the fact that I can receive them)
>
>
> Duncan
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: intent to enable 2fa requirement for github.com/haskell org

[Carter Schonwald]

true, otoh, 2fa in various usable forms has been widely available for
years, and we can reonboard people pretty easily. Its critical haskell
infra and to the best of my knowledge, current 2fa tooling is pretty
accessible to everyone globally. If someone has specific issues we can
address them as they arise!

On Wed, Mar 18, 2020 at 3:45 PM David Feuer  wrote:

> That's not a lot of lead time.
>
> On Wed, Mar 18, 2020, 2:47 PM Carter Schonwald 
> wrote:
>
>> hey everyone, because so much important stuff for the community, it makes
>> sense to add 2fa required for the org, are there any good reasons to either
>> wait to do this, or not do it? Feedback welcome!
>>
>> (if theres no objections i'll do it friday or this weekend, so theres
>> some lead time for anyone who's not setup for that yet)
>>
>> Best wishes and great health to all
>> -carter
>> ___
>> Libraries mailing list
>> librar...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

intent to enable 2fa requirement for github.com/haskell org

[Carter Schonwald]

hey everyone, because so much important stuff for the community, it makes
sense to add 2fa required for the org, are there any good reasons to either
wait to do this, or not do it? Feedback welcome!

(if theres no objections i'll do it friday or this weekend, so theres some
lead time for anyone who's not setup for that yet)

Best wishes and great health to all
-carter
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specializing functions with implicit parameters

[Carter Schonwald]

Hey Alexis,
ive been kicking around some ideas for a specializing lambda former for
various uses i've wanted to make tractable, I assume you dont care about
polymorphic recursion in the cases you want to specialize? (some of the
stuff i want to be able to express requires a sort of type/value binder
that needs to be "normalized" before desugaring, but where current meta
programming cant express the primops i want ghc to support! so roughly a
sortah binder thats like c+ templates, but for types/values  that lets me
guarantee compositions will specialize before core happens)

On Sat, Mar 14, 2020 at 10:47 PM Alexis King  wrote:

> On Mar 14, 2020, at 20:03, Sandy Maguire  wrote:
>
> What GHC are you testing against? I suspect
> https://gitlab.haskell.org/ghc/ghc/merge_requests/668 will fix this.
>
>
> I’ve tested against HEAD. I think the change you link is helpful, but it
> doesn’t *quite* get there: the usage gets dumped before specHeader even
> gets a chance to look at the call. The relevant bit of code is here:
>
>
> https://gitlab.haskell.org/ghc/ghc/blob/1de3ab4a147eeb0b34b24a3c0e91f174e6e5cb79/compiler/specialise/Specialise.hs#L2274-2302
>
> Specifically, this line seals the deal:
>
> ClassPred cls _ -> not (isIPClass cls)  -- Superclasses can't be IPs
>
> So maybe the right fix is just to change the role of type_determines_value
> so that it turns SpecDicts into UnspecArgs, and then with your change
> everything would just happily work out.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Class op rules

[Carter Schonwald]

so i did some poking around see eg
https://gitlab.haskell.org/ghc/ghc/blob/4898df1cc25132dc9e2599d4fa4e1bbc9423cda5/compiler/basicTypes/BasicTypes.hs#L1187-1207
, and at the moment, the simplifier phase number ordering  internally (in
order from first to last)

"Initial phase" --- essentially positive infinity
 -- currently we can add new phases here
2
1
0

---
This actually surprised me, as i've always (at least from how rules are
usually written in eg vector) thought it was counting UP!

@Christiaan  ... so we'd need a Pre initial phase count? that happens
before Initial phase?



On Fri, Mar 6, 2020 at 10:22 AM Christiaan Baaij 
wrote:

> Hello,
>
> The other day I was experimenting with RULES and got this warning:
>
> src/Clash/Sized/Vector.hs:2159:11: warning: [-Winline-rule-shadowing]
> Rule "map Pack" may never fire
>   because rule "Class op pack" for ‘pack’ might fire first
> Probable fix: add phase [n] or [~n] to the competing rule
>  |
> 2159 | {-# RULES "map Pack" map pack = id #-}
>
> The warning seems to suggests two things:
> 1. "Class op" -> "dictionary projection" are implemented as rewrite rules
> and executed the same way as other user-defined RULES
> 2. These rules run first, and you cannot run anything before them
>
> Now my question is, is 1. actually true? or is that warning just a (white)
> lie?
> If 1. is actually true, would there be any objections to adding a "-1"
> phase: where RULES specified to start from phase "-1" onward fire before
> any of the Class op rules.
> I'm quite willing to implement the above if A) Class op rules are actually
> implemented as builtin RULES; B) there a no objections to this "-1" phase.
>
> Thanks,
> Christiaan
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Blocking MVar# primops not performing stack checks?

[Carter Schonwald]

The simplest way to answer this is if you can help us construct a program,
whether as Haskell or cmm, which tickles the failure you suspect is there ?

The rts definitely gets less love overall.  And there’s fewer folks
involved in those layers overall.



On Wed, Feb 26, 2020 at 10:03 AM Shao, Cheng  wrote:

> Hi all,
>
> When an MVar# primop blocks, it jumps to a function in
> HeapStackCheck.cmm which pushes a RET_SMALL stack frame before
> returning to the scheduler (e.g. the takeMVar# primop jumps to
> stg_block_takemvar for stack adjustment). But these functions directly
> bump Sp without checking for possible stack overflow, I wonder if it
> is a bug?
>
> Cheers,
> Cheng
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I'm concerned about the affine-types extension and its impact on ghc and haskell at large

[Carter Schonwald]

https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583664586

https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_longterm_impact_of_the/

As current maintainer of vector, and a member of the CLC, both of which
roles really should be AFFIRMATIONAL stakeholders in this, I only see costs
and concerns.

As someone who's spent the past few years doing a LOT of modelling and
prototyping around marrying linear logic, formal methods, and functional
programming in an applied industrial setting, i should be an Affirmational
stakeholder. yet again I am not.

theres very real costs in the complexity and scope of impact that impact
EVERY single user and stakeholder of ghc and haskell. And I do not see any
concrete population that benefits.


cale even makes a very constructive and articulate point

> I don't know how much my opinion matters at this point, but I'd really
like to see the non-toy real-world use cases of this before I can even
consider thinking that it would be a good idea to merge to the main
compiler. It has such a huge potential impact on so many people in the
Haskell community:
>
> * Library maintainers who start getting PRs that make "improvements"
to linearity while making their libraries harder to maintain because their
interface becomes more rigid, and harder to understand because the types
are more complicated.
>
> * Beginners, or simply ordinary users of the language who have to pay
the mental overhead of living with the linear types and polymorphism
spreading everywhere as types are adjusted to make terms more usable in
places where one is concerned with linearity.
>
> * Commercial users of the language who pay for the additional time
taken by all their employees waiting for the compiler to run, regardless of
whether or not they're using the extension. If Carter's 6-7% slowdown is
real even in cases where one doesn't care about the extension, I can
imagine wanting to make a fork without the extension. The compiler is
already 2 orders of magnitude slower than I'd like. If that weren't the
case, maybe 6-7% wouldn't be a huge deal. While ghci is often helpful at
shortening the feedback loop, it's not always a viable solution.
>
>
> But really, I just want to know how anyone would put this to practical
use in a real setting -- it needs to be _really_ compelling to make up for
the social cost. It can't be that hard for Tweag, or someone enthusiastic,
to live on a fork until they have a decent case study to show the world, so
we can say "okay, that's actually really cool, maybe we actually want that
everywhere".
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Intree gmp builds using Hadrian use system gmp headers

[Carter Schonwald]

If folks can reproduce this issue on other platforms than OS X , id greatly
appreciate it. If only to confirm that it’s as reproducible as I believe it
is.

I should mention that at least on OS X, it’s slightly easier to trigger the
issue / stumble across it with gcc rather than clang (on OS X, clang was
picking up the o stalled system headers but gcc was failing. Without
installed headers both fail for me. )

On Mon, Jan 27, 2020 at 10:37 PM Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> Hey all,
> For those using Hadrian for platforms where intree gmp config is
> important, some sleuthing I’ve done over the past half  seems to indicate
> that currently it’s not correct via Hadrian, but only via make.
>
> https://gitlab.haskell.org/ghc/ghc/issues/17756
> I’m able to reproduce this on multiple OS X machines (though it took me a
> while to read apart that is Hadrian specific.)
>
> Punchline : at the moment, Hadrian intree gmp builds succeed because gmp
> headers in default include search paths of gcc/clang get picked up. In a
> properly isolated environment / one without the offending header leakage,
> I’m able at least on OS X to get Hadrian with intree gmp to consistently
> fail.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Intree gmp builds using Hadrian use system gmp headers

[Carter Schonwald]

Hey all,
For those using Hadrian for platforms where intree gmp config is important,
some sleuthing I’ve done over the past half  seems to indicate that
currently it’s not correct via Hadrian, but only via make.

https://gitlab.haskell.org/ghc/ghc/issues/17756
I’m able to reproduce this on multiple OS X machines (though it took me a
while to read apart that is Hadrian specific.)

Punchline : at the moment, Hadrian intree gmp builds succeed because gmp
headers in default include search paths of gcc/clang get picked up. In a
properly isolated environment / one without the offending header leakage,
I’m able at least on OS X to get Hadrian with intree gmp to consistently
fail.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.10.1-rc1 released

[Carter Schonwald]

Yeah, like how we removed x87 support from code gen except one tiny piece
in the abi, so 32bit x86 code gen is always -msse2 flavor so rounding now
acts sane :)

(A tiny step in a long running make floating point great effort of mine)

On Sat, Jan 25, 2020 at 7:39 AM Brandon Allbery  wrote:

>
>
> On Fri, Jan 24, 2020 at 11:58 PM Ben Gamari  wrote:
>
>>  * A number of improvements in code generation, including changes
>>
>
> This seems like it's missing some detail.
>
> --
> brandon s allbery kf8nh
> allber...@gmail.com
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Anyone able to build current master on OS X with GCC?

[Carter Schonwald]

I’m finding myself only able to successfully run a full validate build if I
set the build configuration to use clang rather than gcc.  Otherwise I get
a cpp error that makes it look like some #defines are missing in the Gmp
binding codes.

Anyone able to do a gcc flavored Mac build that survives validate recently ?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

lots of spam repos on gitlab

[Carter Schonwald]

theres a lot of spam repos on the gitlab :(

11:07 AM
 https://gitlab.haskell.org/wandaibson/oberton-paris

https://gitlab.haskell.org/explore/projects?utf8=%E2%9C%93=keto=latest_activity_desc
lots
of keto
11:10 AM
 two CBD
11:10 AM

https://gitlab.haskell.org/explore/projects?utf8=%E2%9C%93=CBD=latest_activity_desc
11:11 AM

https://gitlab.haskell.org/explore/projects?utf8=%E2%9C%93=pep=latest_activity_desc
11:13 AM

https://gitlab.haskell.org/explore/projects?utf8=%E2%9C%93=pill=latest_activity_desc
11:17 AM

https://gitlab.haskell.org/explore/projects?utf8=%E2%9C%93=vitality=latest_activity_desc
11:17 AM
 alp: ?
11:23 AM ⇐ zeta_0 quit (~z...@h78.48.155.207.dynamic.ip.windstream.net)
Quit: doing a rebuild switch
11:24 AM

https://gitlab.haskell.org/explore/projects?utf8=%E2%9C%93=suppl=latest_activity_desc
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

help understanding a ghc assert failure wrt coercions

[Carter Schonwald]

Hey all,
I've been spending a little bit of time hacking out my own little "erase
coercions"
branch, and with asserts enabled i'm seeing a very strange panic that seems
to be invalid?
namely: its stating that the types have changed,

BUT the error output indicates that the  types  are the same on both sides!



ghc: panic! (the 'impossible' happened)
  (GHC version 8.11.0.20200106:
ASSERT failed!
  optCoercion changed types!
  in_co:
Univ(representational Erased
 :: IO a_a2Pd, State# RealWorld -> (# State# RealWorld, a_a2Pd #))
  in_ty1: IO a_a2Pd
  in_ty2: State# RealWorld -> (# State# RealWorld, a_a2Pd #)
  out_co:
Univ(representational Erased
 :: IO a_a2Pd, State# RealWorld -> (# State# RealWorld, a_a2Pd #))
  out_ty1: IO a_a2Pd
  out_ty2: State# RealWorld -> (# State# RealWorld, a_a2Pd #)
  subst:
[TCvSubst
   In scope: InScope {wild_00 augment ++ build foldr eqString bindIO
  returnIO otherwise assert thenIO breakpoint
breakpointCond map $
  join f_a19W x_a19X x_a1hI s_a1hZ $c==_a2rD
$c/=_a2rM $cp1Ord_a2rY
  $ccompare_a2s0 $c<_a2se $c<=_a2ss $c>_a2sy
$c>=_a2sE $cmax_a2sL
  $cmin_a2sS $cp1Monoid_a2t4 $cmappend_a2tf
$cmconcat_a2tl $c>>=_a2tD
  $c>>_a2tS $creturn_a2u3 $cpure_a2uo $c<*>_a2uA
$cliftA2_a2uN
  $c*>_a2v0 $c<*_a2vb $c>>=_a2vw $c>>_a2vJ
$creturn_a2vU $cpure_a2wd
  $c<*>_a2wn $cliftA2_a2wy $c*>_a2wL $c<*_a2wW
$c>>=_a2xf $c>>_a2xq
  $creturn_a2xB $c<*>_a2y0 $cliftA2_a2y9 $c*>_a2yj
$c<*_a2yu
  $cmappend_a2yS $cmconcat_a2yY $cmappend_a2ze
$cmconcat_a2zk
  $cp1Monoid_a2zE $cmempty_a2zG $cmappend_a2zU
$cmconcat_a2A0
  $cp1Monoid_a2Ai $cmempty_a2Ak $cmappend_a2Aw
$cmconcat_a2AC
  $cp1Monoid_a2AS $cmempty_a2AU $cmappend_a2B4
$cmconcat_a2Ba
  $cp1Monoid_a2Bo $cmempty_a2Bq $cmappend_a2By
$cmconcat_a2BE
  $cmappend_a2BU $cmconcat_a2C0 $cp1Monoid_a2Cb
$cmappend_a2Cj
  $cmconcat_a2Cp $cmappend_a2CH $cmconcat_a2CN
$c<>_a2CX
  $csconcat_a2D8 $cstimes_a2De $c<>_a2Dt
$csconcat_a2DA $c<>_a2DV
  $csconcat_a2DZ $cstimes_a2E5 $c<>_a2Eu
$csconcat_a2EI $cstimes_a2EO
  $c<>_a2Fp $csconcat_a2FB $cstimes_a2FH $c<>_a2Gc
$csconcat_a2Gm
  $cstimes_a2Gs $c<>_a2GR $csconcat_a2GZ
$cstimes_a2H5 $c<>_a2Hm
  $csconcat_a2Hq $cstimes_a2Hu $c<>_a2HG
$csconcat_a2HM $cstimes_a2HS
  $c<>_a2I6 $csconcat_a2Id $cstimes_a2Ij
$csconcat_a2IC $cstimes_a2II
  $c>>=_a2J0 $c>>_a2JO $creturn_a2JZ $cpure_a2Ke
$c<*>_a2Kl
  $cliftA2_a2Kw $c*>_a2KJ $c<*_a2KU $cfmap_a2L7
$c<$_a2Lj
  $cmzero_a2LF $cmplus_a2LO $cmzero_a2M7
$cmplus_a2Mg $cmzero_a2Mz
  $cmplus_a2MI $csome_a2Na $cmany_a2Nj $csome_a2NK
$cmany_a2NT
  $c<|>_a2Oe $csome_a2Oj $cmany_a2Os $c>>_a2OP
$creturn_a2P0
  $cfmap_a2Pb $c<$_a2Ps a_a2Pu b_a2Pv $c>>=_a2PJ
$creturn_a2Q2
  $c>>=_a2Qh $creturn_a2Qz $c>>=_a2QP $c>>_a2QV
$creturn_a2R6
  $c<*>_a2Rr $cliftA2_a2RC $c<*_a2RX $cpure_a2Se
$c<*>_a2Sj
  $cliftA2_a2Sr $c*>_a2SA $c<*_a2SI $c<*>_a2T5
$cliftA2_a2Th
  $c*>_a2Tq $c<*_a2Tx $c<*>_a2TW $cliftA2_a2U2
$c*>_a2U9 $c<*_a2Uk
  $c<$_a2UF $cfmap_a2US $c<$_a2V0 $cfmap_a2Ve
$c<$_a2Vk $c<$_a2VH
  $cfmap_a2VX $c<$_a2W3 $cfmap_a2Wi $c<$_a2Wo
$krep_a37a $krep_a37b
  $krep_a37c $krep_a37d $krep_a37e $krep_a37f
$krep_a37g $krep_a37h
  $krep_a37i $krep_a37j $krep_a37k $krep_a37l
$krep_a37m $krep_a37n
  $krep_a37o $krep_a37p $krep_a37q $krep_a37r
$krep_a37s $sap_d3dm
  $sap_d3dn $sliftM5_d3ds $sliftM5_d3dt
$sliftM4_d3dy $sliftM4_d3dz
  $sliftM3_d3dE $sliftM3_d3dF $sliftM2_d3dK
$sliftM2_d3dL
  $sliftM_d3dQ $sliftM_d3dR $swhen_d3e3 $swhen_d3e4
$s=<<_d3e9
  $sliftA3_d3eh $sliftA3_d3ei $sliftA_d3em
$sliftA_d3en $tcMonoid
  $tcSemigroup $trModule <**> liftA liftA3 =<< when
sequence mapM
  liftM liftM2 liftM3 liftM4 liftM5 ap mapFB
unsafeChr ord minInt
  maxInt id const . flip $! until asTypeOf failIO
unIO getTag quotInt
  remInt divInt modInt quotRemInt divModInt
divModInt# shiftL#
  shiftRL# iShiftL# iShiftRA# iShiftRL# $tcFunctor
$dm<$ $fFunctor[]
  $fFunctorMaybe $fFunctor(,) $fFunctor->

Re: atomicModifyMutVar2

[Carter Schonwald]

 how do you type check it / what type would you plausibly given it thats
wired into very innards of ghc type system implementation? (by which i mean
that most / all primops currently are pretty conservative in terms of the
range of ghc type system features they use)


On Wed, Oct 16, 2019 at 1:51 PM David Feuer  wrote:

> What do you think about the version that takes a function as an argument,
> and is optimized for the case where that's a selector? That really feels
> like the platonic ideal here.
>
> On Mon, Oct 14, 2019, 6:35 PM Simon Peyton Jones 
> wrote:
>
>> OK.   I propose:
>>
>>
>>
>>- To give atomicModieyMutVarOf# its proper type, with a  pair, as in
>>the proposal.
>>- To do that I’ll fiddle with genprimopcode, to allow it to parse
>>tuples as well as unboxed tuples; not hard.
>>- This would disallow all this stuff about “any type that has a first
>>field looking like a”, restricting to pairs alone.  This didn’t form part
>>of the proposal, and was never documented.
>>- Add a bit more clarity to the documentation, so it’d clear what
>>must be forced.
>>
>>
>>
>> Any objections?
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* David Feuer 
>> *Sent:* 12 October 2019 00:00
>> *To:* Simon Peyton Jones 
>> *Cc:* ghc-devs 
>> *Subject:* Re: atomicModifyMutVar2
>>
>>
>>
>> I don't remember what documentation, if any, it has. You're right that
>> taking advantage of it is potentially risky. Here's what I think we really
>> want:
>>
>>
>>
>> atomicModifyMutVarQ# :: MutVar# s a -> (q -> a) -> (a -> q)  -> State#
>> s -> (# State# s, a, q #)
>>
>>
>>
>> where there's a special rule that (q -> a) is "obviously" a selector that
>> selects a pointer.
>>
>> On Fri, Oct 11, 2019, 12:56 PM Simon Peyton Jones 
>> wrote:
>>
>> The result doesn't have to be a pair. It can be a tuple of any size at
>> all. Indeed, it can even be an arbitrary record type whose first pointer
>> field has the appropriate type.
>>
>>
>>
>> I think that is 100.0% undocumented, in the code, or in the proposal.
>> Are you sure this is a settled consensus among the interested parties?
>>
>>
>>
>> Adopting it would impose new invariants on the representation of values
>> in GHC that I am deeply reluctant to impose.  I would much much prefer to
>> stick with the pair that is (somewhat) documented.
>>
>>
>>
>> About pair vs Unit, yes, I can see (just) your point about why a pair
>> might be useful.  Here’s a better example:
>>
>>
>>
>> Suppose mv :: MutVar# Int
>>
>>
>>
>> atomicModifyMutVar2# mv $ \a ->
>>
>>   let foo = f a
>>
>>   in (g foo, foo)
>>
>>
>>
>> Now, if f is expensive, *and g is not invertible*, then sharing foo
>> might be useful.  It’s hard to think of a credible example, though.
>> Regardless, we should document it.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* David Feuer 
>> *Sent:* 11 October 2019 17:03
>> *To:* Simon Peyton Jones 
>> *Cc:* ghc-devs 
>> *Subject:* Re: atomicModifyMutVar2
>>
>>
>>
>> On Fri, Oct 11, 2019, 11:08 AM Simon Peyton Jones 
>> wrote:
>>
>> David
>>
>> I’m deeply puzzled atomicModifyMutVar2#.  I have read the proposal
>> ,
>> and the comments in primops.txt.pp (reproduced below).
>> Question 1
>>
>> I think the “real” type of atomicModifyMutVar2 is
>>
>> atomicModifyMutVar2# :: MutVar# s a
>>
>>  -> (a -> (a,b))
>>
>>  -> State# s
>>
>>  -> (# State# s, a, (a, b) #)
>>
>>
>>
>> Close, but not quite. The result doesn't have to be a pair. It can be a
>> tuple of any size at all. Indeed, it can even be an arbitrary record type
>> whose first pointer field has the appropriate type.
>>
>>
>>
>> Nowhere is this explicitly stated, but I believe that the intended
>> semantics of a call
>>
>> case (atomicModifyMutVar2# mv f s) of (# s’, x, r #) -> blah
>>
>> Then, suppose the old value of the MutVar was ‘*old’*
>>
>>- The primop builds a thunk  *t *= *f old*
>>- The new value of the mutable variable is *(fst t)*
>>- The result *r* is t
>>- The result *x* is *old*
>>
>> Question: is that correct?   We should state it explicitly.
>>
>> Yes, that sounds right.
>>
>> Question 2
>>
>> Next question: Why does f have to return a pair?  So far as I can tell,
>> it’s only so that a client can force it.   The ‘b’ part never seems to play
>> a useful role.   So we could equally well have had
>>
>> atomicModifyMutVar2# :: MutVar# s a
>>
>>  -> (a -> Box a)
>>
>>  -> State# s
>>
>>  -> (# State# s, a, Unit a #)
>>
>> where Unit is defined in Data.Tuple
>>
>> data Unit a = Unit a
>>
>> Now you can force the result of (f 

Re: validate-x86_64-darwin failing

[Carter Schonwald]

We are in slow process of reprovisioning 1-2 new builders.  One of our
active builders had pretty bad hardware issues so for near term we’re down
in mac builder capacity

On Mon, Oct 14, 2019 at 8:41 AM Brandon Allbery  wrote:

> Apple makes that annoyingly difficult; someone has to in effect donate a
> Mac to the cause, preferably one with enough memory and fast CPU. (Not
> literally: one can keep the Mac physically, but would more or less lose use
> of it for any other purpose.)
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: atomicModifyMutVar2

[Carter Schonwald]

that additional representation invariant requirement is why i ultimately
chose not to include the user space version of davids work in primitive

https://github.com/haskell/primitive/pull/194

theres some really clever ideas, but i couldnt tease apart a natural
example of where i'd want to use it

On Fri, Oct 11, 2019 at 12:56 PM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> The result doesn't have to be a pair. It can be a tuple of any size at
> all. Indeed, it can even be an arbitrary record type whose first pointer
> field has the appropriate type.
>
>
>
> I think that is 100.0% undocumented, in the code, or in the proposal.  Are
> you sure this is a settled consensus among the interested parties?
>
>
>
> Adopting it would impose new invariants on the representation of values in
> GHC that I am deeply reluctant to impose.  I would much much prefer to
> stick with the pair that is (somewhat) documented.
>
>
>
> About pair vs Unit, yes, I can see (just) your point about why a pair
> might be useful.  Here’s a better example:
>
>
>
> Suppose mv :: MutVar# Int
>
>
>
> atomicModifyMutVar2# mv $ \a ->
>
>   let foo = f a
>
>   in (g foo, foo)
>
>
>
> Now, if f is expensive, *and g is not invertible*, then sharing foo might
> be useful.  It’s hard to think of a credible example, though.  Regardless,
> we should document it.
>
>
>
> Simon
>
>
>
> *From:* David Feuer 
> *Sent:* 11 October 2019 17:03
> *To:* Simon Peyton Jones 
> *Cc:* ghc-devs 
> *Subject:* Re: atomicModifyMutVar2
>
>
>
> On Fri, Oct 11, 2019, 11:08 AM Simon Peyton Jones 
> wrote:
>
> David
>
> I’m deeply puzzled atomicModifyMutVar2#.  I have read the proposal
> ,
> and the comments in primops.txt.pp (reproduced below).
> Question 1
>
> I think the “real” type of atomicModifyMutVar2 is
>
> atomicModifyMutVar2# :: MutVar# s a
>
>  -> (a -> (a,b))
>
>  -> State# s
>
>  -> (# State# s, a, (a, b) #)
>
>
>
> Close, but not quite. The result doesn't have to be a pair. It can be a
> tuple of any size at all. Indeed, it can even be an arbitrary record type
> whose first pointer field has the appropriate type.
>
>
>
> Nowhere is this explicitly stated, but I believe that the intended
> semantics of a call
>
> case (atomicModifyMutVar2# mv f s) of (# s’, x, r #) -> blah
>
> Then, suppose the old value of the MutVar was ‘*old’*
>
>- The primop builds a thunk  *t *= *f old*
>- The new value of the mutable variable is *(fst t)*
>- The result *r* is t
>- The result *x* is *old*
>
> Question: is that correct?   We should state it explicitly.
>
> Yes, that sounds right.
>
> Question 2
>
> Next question: Why does f have to return a pair?  So far as I can tell,
> it’s only so that a client can force it.   The ‘b’ part never seems to play
> a useful role.   So we could equally well have had
>
> atomicModifyMutVar2# :: MutVar# s a
>
>  -> (a -> Box a)
>
>  -> State# s
>
>  -> (# State# s, a, Unit a #)
>
> where Unit is defined in Data.Tuple
>
> data Unit a = Unit a
>
> Now you can force the result of (f old), just as with a pair.  But the ‘b’
> would no longer complicate matters.
>
> Question: is the ‘b’ in the pair significant?   Or could we use Unit?
>
> Yes, it's somewhat significant. You actually can use Unit with the new
> primop (it's a tuple of arity 1), so that option is free. But using a pair
> gets you a bit more: you can build a thunk that's *shared* between the
> value installed in the MutVar and the one returned to the outside. Consider
>
>
>
> atomicModifyMutVar2# mv $ \a ->
>
>   let foo = expensive_computation a
>
>   in ([3,foo], foo)
>
> Question 3
>
> In the comments below you say "but we don't know about pairs here”.   Are
> you sure?  What stops you importing Data.Tuple into GHC.Prim?   This fancy
> footwork is one more complication, if it could be avoided.
>
> That whole regime came before my time, but since we win a bit by *not*
> fixing it, o wouldn't jump on it too quick.
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.8.1 and cabal-install version

[Carter Schonwald]

V1 or v2 install?

On Mon, Sep 2, 2019 at 11:42 AM George Colpitts 
wrote:

> https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says
>
> cabal-install users should note that cabal-install-3.0 or later is
> required for use with GHC 8.8.
>
> but this seems wrong or have I done something wrong?
>
> $ cabal install cabal-install
> cabal install cabal-install
> ...
>
> Resolving dependencies...
> cabal: Could not resolve dependencies:
> [__0] trying: cabal-install-3.0.0.0 (user goal)
> [__1] next goal: time (dependency of cabal-install)
> [__1] rejecting: time-1.9.3/installed-1.9... (conflict: cabal-install =>
> base>=4.8 && <4.13, time => base==4.13.0.0/installed-4.1...)
> [__1] trying: time-1.9.3
> [__2] next goal: stm (dependency of cabal-install)
> [__2] rejecting: stm-2.5.0.0/installed-2.5... (conflict: cabal-install =>
> base>=4.8 && <4.13, stm => base==4.13.0.0/installed-4.1...)
> [__2] trying: stm-2.5.0.0
> [__3] next goal: process (dependency of cabal-install)
> [__3] rejecting: process-1.6.5.1/installed-1.6... (conflict: cabal-install
> =>
> base>=4.8 && <4.13, process => base==4.13.0.0/installed-4.1...)
> [__3] trying: process-1.6.5.1
> [__4] next goal: pretty (dependency of cabal-install)
> [__4] rejecting: pretty-1.1.3.6/installed-1.1... (conflict: cabal-install
> =>
> base>=4.8 && <4.13, pretty => base==4.13.0.0/installed-4.1...)
> [__4] trying: pretty-1.1.3.6
> [__5] next goal: network (dependency of cabal-install)
> [__5] rejecting: network-3.1.0.1/installed-CeX... (conflict: cabal-install
> =>
> base>=4.8 && <4.13, network => base==4.13.0.0/installed-4.1...)
> [__5] trying: network-3.1.0.1
> [__6] trying: hackage-security-0.5.3.0 (dependency of cabal-install)
> [__7] next goal: template-haskell (dependency of hackage-security)
> [__7] rejecting: template-haskell-2.15.0.0/installed-2.1... (conflict:
> cabal-install => base>=4.8 && <4.13, template-haskell =>
> base==4.13.0.0/installed-4.1...)
> [__7] rejecting: template-haskell-2.15.0.0, template-haskell-2.14.0.0,
> template-haskell-2.13.0.0, template-haskell-2.12.0.0,
> template-haskell-2.11.1.0, template-haskell-2.11.0.0,
> template-haskell-2.10.0.0, template-haskell-2.9.0.0,
> template-haskell-2.8.0.0,
> template-haskell-2.7.0.0, template-haskell-2.6.0.0,
> template-haskell-2.5.0.0,
> template-haskell-2.4.0.1, template-haskell-2.4.0.0,
> template-haskell-2.3.0.1,
> template-haskell-2.3.0.0, template-haskell-2.2.0.0 (constraint from
> non-upgradeable package requires installed instance)
> [__7] fail (backjumping, conflict set: cabal-install, hackage-security,
> template-haskell)
> After searching the rest of the dependency tree exhaustively, these were
> the
> goals I've had most trouble fulfilling: base, cabal-install, directory,
> template-haskell, process, time, network, pretty, hackage-security,
> deepseq,
> HTTP, stm, cabal-install:lib
>
>
> On Mon, Aug 26, 2019 at 6:25 AM Ben Gamari  wrote:
>
>>
>> Hello everyone,
>>
>> The GHC team is pleased to announce the release candidate for GHC 8.8.1.
>> The source distribution, binary distributions, and documentation are
>> available at
>>
>> https://downloads.haskell.org/ghc/8.8.1
>>
>> This release is the culmination of over 3000 commits by over one hundred
>> contributors and has several new features and numerous bug fixes
>> relative to GHC 8.6:
>>
>>  * Visible kind applications are now supported (GHC Proposal #15)
>>
>>  * Profiling now works correctly on 64-bit Windows (although still may
>>be problematic on 32-bit Windows due to platform limitations; see
>>#15934)
>>
>>  * A new code layout algorithm for amd64's native code generator
>>significantly improving the runtime performance of some kernels
>>
>>  * The introduction of a late lambda-lifting pass which may reduce
>>allocations significantly for some programs.
>>
>>  * Further work on Trees That Grow, enabling improved code re-use of the
>>Haskell AST in tooling
>>
>>  * Users can write `forall` in more contexts (GHC Proposal #7)
>>
>>  * The pattern-match checker is now more precise in the presence of
>>strict fields with uninhabited types.
>>
>>  * A comprehensive audit of GHC's memory ordering barriers has been
>>performed, resulting in a number of fixes that should significantly
>>improve the reliability of programs on architectures with
>>weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64
>>implementations).
>>
>>  * A long-standing linker limitation rendering GHCi unusable with
>>projects with cyclic symbol dependencies has been fixed (#13786)
>>
>>  * Further work on the Hadrian build system
>>
>>  * Countless miscellaneous bug-fixes
>>
>> Unfortunately, due to a build issue (#17108) found late in the release
>> process
>> i386 Windows builds are currently unavailable. These will be provided in
>> the coming weeks.
>>
>> As always, if anything looks amiss do let us know.
>>
>> Happy compiling!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1]
>> 

Re: Missing library in Mac OS X instructions?

[Carter Schonwald]

heres what you need to do
cp mk/build.mk.sample mk/build.mk

then uncomment the line about GMP

On Wed, Aug 21, 2019 at 11:19 AM Alejandro Serrano Mena 
wrote:

> Thanks for the reply!
> In my case, it was a clean installation of Mac OS X, with only Xcode
> command line tools and after executing the corresponding 'brew' command
> from the wiki.
>
> El lun., 19 ago. 2019 11:09, Shayne Fletcher 
> escribió:
>
>> Hi Alejandro,
>>
>> On Mon, Aug 19, 2019 at 2:11 AM Alejandro Serrano Mena 
>> wrote:
>>
>>> Hi,
>>> I tried to get GHC working from the repo in Mac OS X following the
>>> instructions in
>>> https://gitlab.haskell.org/ghc/ghc/wikis/building/preparation/mac-osx.
>>> At first I got the "error __GNU_MP_VERSION not defined" problem, for
>>> which the guide recommends to prepend "CC=clang"  to "./configure" , which
>>> I did. But even then, I also had to install "gmp" using "brew install gmp".
>>> 1. Is it right that I need to install gmp using brew or did I miss some
>>> previous step?
>>> 2. If (1) is affirmative, how can I help update the docs for building in
>>> Mac OS X?
>>>
>>>
>> I've encountered this problem. In my case it turned out that I had a
>> rogue `cc` executable in my path. See
>> https://gitlab.haskell.org/ghc/ghc/issues/16904 for details.
>>
>> --
>> *Shayne Fletcher*
>> Language Engineer */* +1 917 699 7663
>> *Digital Asset* , creators of *DAML
>> *
>>
>> This message, and any attachments, is for the intended recipient(s) only,
>> may contain information that is privileged, confidential and/or proprietary
>> and subject to important terms and conditions available at
>> http://www.digitalasset.com/emaildisclaimer.html. If you are not the
>> intended recipient, please delete this message.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Most recent happy and Alex releases can’t build ghc 8.6.x

[Carter Schonwald]

Hey everyone :
Is this a known issue / deliberate breaking change / other ?

This is also the same Alex and happy that’s needed to build current ghc
master


Thx!
-Carter
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: can't checkout ghc 8.6 branch correctly -- something wrong with transformers mirror repo?

[Carter Schonwald]

git clone --recursive git://git.haskell.org/ghc.git ghc-8.6.5-series -b
ghc-8.6
--- not using gitlab to clone seems to be the culprit ..


On Fri, Jul 26, 2019 at 2:18 PM Carter Schonwald 
wrote:

> Hey everyone, whats wrong with the 8.6 branch?
>
> when i do a fresh clone, i wind up with this error :
> $
> git submodule update  --init --recursive
> error: Server does not allow request for unadvertised object
> def8c55d0c47c1c40de985d83f052f3659b40cfd
> Fetched in submodule path 'libraries/transformers', but it did not contain
> def8c55d0c47c1c40de985d83f052f3659b40cfd. Direct fetching of that commit
> failed.
> 14:17:43 ~/D/r/ghc-8.6.5-series (ghc-8.6|✚6) $
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

can't checkout ghc 8.6 branch correctly -- something wrong with transformers mirror repo?

[Carter Schonwald]

Hey everyone, whats wrong with the 8.6 branch?

when i do a fresh clone, i wind up with this error :
$
git submodule update  --init --recursive
error: Server does not allow request for unadvertised object
def8c55d0c47c1c40de985d83f052f3659b40cfd
Fetched in submodule path 'libraries/transformers', but it did not contain
def8c55d0c47c1c40de985d83f052f3659b40cfd. Direct fetching of that commit
failed.
14:17:43 ~/D/r/ghc-8.6.5-series (ghc-8.6|✚6) $
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: a better workflow?

[Carter Schonwald]

also: depending on the time scales of havingt these machines, it sometimes
makes sense to just have a mini itx/ micro tower/etc at home!  I dont have
any build recommendations but im sure folks like Ben have suggestions :)

On Tue, Jul 23, 2019 at 10:59 PM Steven Shaw  wrote:

> Hi Richard,
>
> I'd second Hetzner. They are in Europe so latency should be pretty good
> from England. I don't build GHC regularly but I have just purchased a
> machine similar to this one from Hetnzer
>  (with only a
> single 500GB Samsung 500GB 970 EVO Plus) and it makes a meal of my client's
> application with many dependencies. We use a Hetzner machine at work as a
> CI server and it hasn't let us down yet.
>
> Note that I used to use GCP because my MacBook Air wasn't really up to the
> task. I'd use tmux and emacs so things were pretty good (on a free trial
> with preemptible — shut down your machine when you're not using it and it
> can be pretty cheap). However, SSD speeds are not like those you get with a
> dedicated server. IIRC 300Gbps vs 1000Gbps.
>
> Cheers,
> Steve.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why is NoExt inhabited?

[Carter Schonwald]

Phrased differently is a magic stand in for 0 ary sum and products ?

Or do you mean how n-ary sum and product are the same structure when n=1?

Forgot to cc list. Pardon the double send :)

On Mon, Jun 24, 2019 at 11:22 PM Richard Eisenberg  wrote:

> I forget if I'm the contributor Ben mentions below, but regardless: NoExt
> is used in two separate ways within GHC. It's used both as the extension of
> a sum (new constructor) and the extension of a product (new field in a
> constructor). But the identity for sum is different than the identity for
> products. To me, it makes good sense for the NoExt used as a product
> extension (new field) to have the 1 trivial inhabitant (thus forming the
> identity for products), but the NoExt used as a sum extension (new
> constructor) to have 0 inhabitants (thus forming the identity for sums).
> Clearly, one of these will need a new name.
>
> Thanks,
> Richard
>
> > On Jun 24, 2019, at 4:57 PM, Ben Gamari  wrote:
> >
> > Hi Shayan,
> >
> > During code review a contributor asked about a TTG extension point.
> > While answering his question I realized I didn't have a good explanation
> > for why NoExt is inhabited; as far as I can tell it should rather be
> > unhabited.
> >
> > If there is a reason for this then can you:
> >
> > 1. describe why this is so in #16863 [1]
> > 2. open an MR documenting the reason in Note [Trees that Grow].
> >
> > If not, perhaps we should consider changing it; the current state of
> > things is a bit awkward.
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://gitlab.haskell.org/ghc/ghc/issues/16863
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs