with regard to Hadrian-building
vs. GHC-bootstrapping Haskell compilers. I've filed this as
https://gitlab.haskell.org/ghc/ghc/-/issues/25076.
On Wed, 10 Jul 2024, ÉRDI Gergő wrote:
By playing around with GHC versions, Stack resolvers, and trying
`hadrian/build` instead of `hadrian/build-stack`, I now
itself, right? So it's
not an unresolved external dependency.
It's very much possible that this is all because of some local
configuration problem on my machine, but I'm still going to need some
hints on where to even start looking.
Thanks,
Gerg
On Mon, 8 Jul 2024, ÉRDI Gergő wrote
Hi,
I'm trying to build GHC 5b1aefb70edbd54ac899896df39d8f3d6c579518 but I'm
running into a weird problem. Using `hadrian/build-stack`, it fails quite
early on with:
| Run Ghc CompileCWithGhc (Stage0 GlobalLibs): utils/hsc2hs/cbits/utils.c
=>
I know this is not exactly what you're asking, but in similar situations
I've had very good results from implementing my type family as a type
checker plugin. Unfortunately it's not code that I can share, but it
roughly goes like this:
1. Declare a closed type family without defining any
Hi,
I was under the impression that the Prep'd Core is still in reverse
dependency order, i.e. if definition A refers to intra-module definition
B, then A's binding will always be preceding B's binding. I've been
exploiting this (hopefully not made-up and accidental!) property in my
work so
Hi,
Is there a way to have GHC reduce all (reducable) type familiy
applications? For example, if I have
```
type family Id x where
Id x = x
foo :: Bool -> Id Bool
foo x = x
```
then I would like the `Id` of `foo` to have type `Bool -> Bool`, and the
generated Core should be either `foo =
On Tue, 18 Oct 2022, Matthew Pickering wrote:
* 9.4.3 (End of October)
- Critical correctness fix for AArch64 code generation
- Fixes to performance regressions introduced in 9.4.2.
- Fix to interface file determinism
How about https://gitlab.haskell.org/ghc/ghc/-/issues/22272, a
Hi Richard,
Thanks for getting back to me! My replies are inline below.
On Thu, 11 Aug 2022, Richard Eisenberg wrote:
You want a third:
C. invisible parameters that are filled in with a fresh wildcard.
We would need to have some way of writing out the type of such a thing
(i.e. what kind
As I mentioned at the end of the original thread (but probably no one
was interested in this enough to read that far), after a breakthrough
idea I have now started working on partial type synonyms that are NOT
just defined using macro expansion semantics, and indeed can be a
first-class
In case anyone's still interested, Atze Dijkstra and I have come up with
an alternative approach to implementing this which requires changing much
fewer moving parts.
The idea is to internally regard `type MySyn a = T[_, a, _]` as
`type MySyn w1 w2 a = T[w1, a, w2]`, recording in `SynTyCon`
On Thu, 28 Jul 2022, Simon Peyton Jones wrote:
You need to be super-careful about the *level* of wildcards. That is a tricky
bit
about the whole wildcard implementation.
Indeed! Ensuring the fresh metavars are at `topTcLevel` seems to have
fixed my problem. My goal doesn't include support
On Thu, 28 Jul 2022, Simon Peyton Jones wrote:
Wild guess: you aren't instantiating the kinds of the meta-tyvars to something
sensible, so kinds don't line up. Eg. where are k_ax9 and k_awW bound?
`a_auu :: k_ax9` is the result of typechecking my type argument (the `a`
in the source type
?
Thanks,
Gergo
On Mon, 25 Jul 2022, Simon Peyton Jones wrote:
I'm afraid I don't understand, but it sounds delicate. By all means try!
Simon
On Mon, 25 Jul 2022 at 11:04, ÉRDI Gergő wrote:
On Mon, 25 Jul 2022, Simon Peyton Jones wrote:
> Do w
On Mon, 25 Jul 2022, Richard Eisenberg wrote:
I see this substitution as happening before any type-checking, so zonking
shouldn't be an issue. That is, I would expect a
substHsTy :: UniqFM Name (HsType GhcRn) -> HsType GhcRn -> HsType GhcRn
to do the work, entirely before type-checking.
If
On Mon, 25 Jul 2022, Simon Peyton Jones wrote:
Do we have an existing way of substituting types over type variables, *in
HsType instead of Core Type*?
I'm afraid not. Currently HsType is not processed much -- just renamed and
typechecked
into a Type.
I wonder if, instead, I
On Fri, 22 Jul 2022, Simon Peyton Jones wrote:
So it seems that instead of shoehorning it into the existing type
synonyms, a better bet would be to branch off to a separate path quite
early (maybe as soon as during renaming), expand them during
typechecking, and *not*
On Fri, 22 Jul 2022, Iavor Diatchki wrote:
I've implemented such a feature in Cryptol, not GHC, so it is quite doable, but
I
think the implementation would be easier if you decided on the overall design
of the
feature first.
I'm hoping the details pretty much fall out from what it would
Hi,
I'd like to implement type synonyms containing wildcards. The idea is
that if you have `type MySyn a = MyType a _ Int`, then during
typechecking, every occurrence of `MySyn T` would be expanded into
`MyType T w123 Int`, with a fresh type (meta)variable `w123`.
One worrying thing I noticed
On Thu, 16 Jun 2022, Erdi, Gergo via ghc-devs wrote:
Is there a migration guide for GHC API clients for the new “multiple home units”
feature?
OK so in concrete terms, please see my attached program which is a heavily
cut-down, standalone version of my real program. On commit
On Mon, 2 May 2022, Simon Peyton Jones wrote:
This is really a GHC bug already, albeit one that is hard to provoke. Would
you like
to open a ticket and add the fix?
I'm happy to provide a patch (and also fix the comment referencing
GHC.Core.Unfold.specUnfolding), but I don't think I'll be
Hi,
In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC
extends the call_args with dummy UnspecArg elements, to make it trivially
fully saturated. There's a Note describing this behaviour:
"""
Note [Specialising DFuns]
~
DFuns have a special sort
On Thu, 7 Apr 2022, Simon Peyton Jones wrote:
Gergo might you offer a patch?
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7964
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
On Thu, 7 Apr 2022, Simon Peyton Jones wrote:
If you can repro this with GHC, can you open a ticket for it.
https://gitlab.haskell.org/ghc/ghc/-/issues/21363
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
I'm trying to save (Prep'd) Core bindings right next to the serialized
`ModIface` (so basically `put_`ing them into the same bytestream, after the
`ModIface`), and that's exactly what the functions in `GHC.CoreToIface`
seem to be for, so I expected it to Just Work. However, I noticed that
On Fri, 1 Apr 2022, Sylvain Henry wrote:
The unfolding is present if you add `-fno-omit-interface-pragmas` and dump
with `-ddump-simpl`. CorePrep drops unfoldings, see Note [Drop unfoldings and
rules] in GHC.CoreToStg.Prep.
Thanks, I forgot to mention that I am already using
Just (MkCore.mkAbsentErrorApp (Var.varType _id) noUnfoldingErr)
_ -> Nothing
_ -> Nothing
i.e. when we encounter a NoUnfolding with a bottoming demand signature, we
conjure an
absentError out of thin air.
On Fri, 1 Apr 2022 at 10:05, ÉRDI Gergő wrote:
Hi,
Hi,
I'm CC-ing the Clash mailing list because I believe they should have
encountered the same problem (and perhaps have found a solution to it
already!).
I'm trying to use `.hi` files compiled with `ExposeAllUnfoldings` set to
reconstruct full Core bindings for further processing. By and
On Fri, 11 Feb 2022, ÉRDI Gergő wrote:
Presumably you must also be generating these bindings (in a `ModGuts`
perhaps?) and
generating code for them that will ultimately be linked into the program to
run.
BTW, I thought that linking is done on the object file level, i.e. I
thought
On Fri, 11 Feb 2022, Simon Peyton Jones wrote:
A `ModDetails` gives the type signatures for everything, but no actual code.
For
example if you have `f :: Int -> Int` in the `md_types`, the `ModDetails`
doesn't
include the binding `f = rhs` for `f`.
Yes, this on its own makes sense.
On Fri, 22 Oct 2021, Matthew Pickering wrote:
If there is a ticket then I can look into it next week.
Thanks! I've added it as https://gitlab.haskell.org/ghc/ghc/-/issues/20556
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
I'm seeing three build failures in CI:
1. On perf-nofib, it fails with:
== make boot -j --jobserver-fds=3,4 --no-print-directory;
in /builds/cactus/ghc/nofib/real/smallpt
/builds/cactus/ghc/ghc/bin/ghc -M
On Fri, 16 Jul 2021, Simon Peyton Jones via ghc-devs wrote:
Yes, it would be much better to use the extension field. That would stop the
(GHC-independent) Language.Haskell.Syntax needing to talk about “witnesses”.
Here it is:
On Fri, 25 Jun 2021, Matthew Pickering wrote:
Hi Gergo,
Please see a minimal example in this gist.
https://gist.github.com/mpickering/5029c7f244c484c91d665bcbc6bc6406
Thanks for the quick reply! Unfortunately, I won't be able to try it out
until Monday.
On Fri, 12 Mar 2021, Simon Peyton Jones wrote:
I'm not sure... you could investigate, but I'm inclined just to declare victory!
That's easy for you to say, but here I am stuck with Stack not supporting
GHC 9.0... https://github.com/commercialhaskell/stack/issues/5486
On Fri, 12 Mar 2021, ÉRDI Gergő wrote:
I wonder why that is? What changed between GHC 8.10.3 and 9.0.1? Was the
definition of `elem` changed in `base`?
Oh, I've found this commit:
```
commit f10d11fa49fa9a7a506c4fdbdf86521c2a8d3495
Author: Andreas Klebinger
Date: Wed Jan 29 15:25:07 2020
On Thu, 11 Mar 2021, Simon Peyton Jones wrote:
With HEAD, and -O, I get the exact same (good code) for these two functions:
f x = any (x ==) [1, 5, 7::Int]
g x = elem x [2, 6, 9 :: Int]
Maybe this is fixed? If you think not, maybe open a ticket?
OK, so initially I tried it
where
you can
begin to understand some more.
Julian
On 4 Mar 2021, at 10:55 pm, ÉRDI Gergő wrote:
Hi,
I'm trying to figure out a Clash problem and managed to track it down to a GHC
upgrade; specifically, a given Clash version, when based on GHC 8.8, has no
problem synthesizing one module
Hi,
The inlining behaviour of `any @[]` and `elem @[]` differs in a way that I
am not sure is intentional, and it is affecting Clash (see
https://github.com/clash-lang/clash-compiler/issues/1691). I would think
that if it is a good idea to inline `any` then inlining `elem` would be
just as
Hi,
I'm trying to figure out a Clash problem and managed to track it down to
a GHC upgrade; specifically, a given Clash version, when based on GHC
8.8, has no problem synthesizing one module after another from one
process; but the same Clash version with GHC 8.10 fails with link-time
errors
The Cat's name should be Hask.
On Wed, Sep 2, 2020, 22:39 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
As a workaround, can you try this?
https://stackoverflow.com/a/32133083/477476
On Fri, Mar 6, 2020, 23:23 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
Record field updates via patsyns looks very weird to me (and, as just a
user, it would be unexpected). Can't we do just matchers and builders for
now, and add field updaters as a second step, if there's concensus that
it's a Good Idea?
Bye,
Gergo
On 11 Aug 2015 07:11, Matthew Pickering
Thanks!
On Dec 22, 2014 11:53 PM, Austin Seipp aus...@well-typed.com wrote:
Bah, this is some bunk permission error. I'll try to fix it shortly.
In the mean time, I ran it for you:
https://phabricator.haskell.org/B2742
On Mon, Dec 22, 2014 at 9:44 AM, Dr. ERDI Gergo ge...@erdi.hu wrote:
It is clear to everyone that all it would change is the *output* of GHCi's
:info and Haddock-generated docs, right? There's no change whatsoever to
what programs are accepted by GHC, or what they mean.
On Dec 2, 2014 5:44 AM, Simon Peyton Jones simo...@microsoft.com wrote:
The issue is not so
With enough intellectual dishonesty, sure...
On Dec 2, 2014 7:29 AM, Gabor Greif ggr...@gmail.com wrote:
So it could be regarded as a bugfix?
Em terça-feira, 2 de dezembro de 2014, Dr. ÉRDI Gergő ge...@erdi.hu
escreveu:
It is clear to everyone that all it would change is the *output
It... fixes the bug of... a missing feature? ...
I'll take that as a no. :)
On Jul 8, 2014 10:40 PM, Carter Schonwald carter.schonw...@gmail.com
wrote:
7.8.3 is a bug fix release, is this a bug fix? :-)
On Tuesday, July 8, 2014, Dr. ERDI Gergo ge...@erdi.hu wrote:
Hi,
I've spent the last
OK I've uploaded the code to wip/T9023
It's pushed to wip/T9023 on the GHC git repo.
On Jul 3, 2014 2:32 AM, Simon Peyton Jones simo...@microsoft.com wrote:
How can I reproduce? Is this on your wip/pattern-synonyms branch?
Simon
| -Original Message-
| From: Dr. ERDI Gergo
Hi,
I'm getting it done later today.
Bye,
Gergo
On Mar 19, 2014 1:36 AM, Simon Peyton Jones simo...@microsoft.com wrote:
Gergo
I'm a bit out of date... did you update those test results etc to get to
clean validate?
S
___
ghc-devs mailing list
Exactly, the problem is precisely that $foo is regarded as an infix
operator in that code path, so with my change, it would be classified as
prefix.
On Mar 17, 2014 10:10 PM, Simon Peyton Jones simo...@microsoft.com
wrote:
Do they show up in -ddump-simpl? It would be nice to keep that output
Yes:-(
I'll unbreak them later today.
On Mar 14, 2014 4:16 AM, Johan Tibell johan.tib...@gmail.com wrote:
Could these changes be related to the validate failures I just posted
about on the mailing list?
On Thu, Mar 13, 2014 at 2:21 PM, g...@git.haskell.org wrote:
Repository :
Hi,
Sorry, I wasn't aware running validate was not enough. I'll check out the
problems in ~10 hours.
Bye,
Gergo
On Jan 30, 2014 7:41 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:
On 05/01/14 12:16, Dr. ERDI Gergo wrote:
Hi,
When I started working on pattern synonyms (#5144) back
Hi,
How do I get permissions to push to my wip branch?
Thanks,
Gergo
-- Forwarded message --
From: Dr. ERDI Gergo ge...@erdi.hu
Date: Jan 13, 2014 8:12 PM
Subject: Re: Pattern synonyms for 7.8?
To: aus...@well-typed.com
Cc: Gabor Greif ggr...@gmail.com
(removing Mateusz and
Hi,
please don't commit it just yet, I'd like the eventual single commit to
also include the user documentation.
Thanks,
Gergo
On Jan 8, 2014 10:46 PM, Austin Seipp ase...@pobox.com wrote:
Oh, to be honest, I was just going to squash it into a single Big
Commit, with you set as the author,
Hi,
Wow, so, I thought there would be some back-and-forth, then a decision,
then I would go and walk the last mile and then formally submit the patch
for review - and now I see that in 2 days all that has passed...
Of course I'll make validate pass, I just didn't even know about it.
Likewise, I
Of course. That's how I've been keeping up with GHC proper all along.
On Jan 8, 2014 7:09 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote:
On 07/01/14 23:05, Dr. ÉRDI Gergő wrote:
Hi,
Wow, so, I thought there would be some back-and-forth, then a decision,
then I would go and walk
I've updated the Wiki page to better match what I'm implementing. Apart
from reorganizing the page slightly, all I really had to change was the
paragraph on exporting/importing.
Should I explicitly mark parts of the page that are not yet implemented?
I'd think the page should stay to be about
On Aug 21, 2013 1:05 AM, Austin Seipp ase...@pobox.com wrote:
* ERDI was working on pattern synonyms. I believe you were having some
trouble with the implementation. Can someone help him if necessary?
Hi,
I've updated the Trac ticket with the latest status of my work. There are
only two loose
Hi Simon,
Here's what I wrote earlier about this to someone who contacted me in
private (name withheld because I don't know why he contacted me off-list):
So the code in question is this:
https://github.com/gergoerdi/ghc/commit/f874f8#L5R749
and the part that feels fishy to me is tcInstTypes,
58 matches
Mail list logo
