Interesting -- thanks for taking the time to do this.
>
> Full build + test: Near identical
> Testsuite run: Near identical
> Recompile: Near identical - (2) is slower
> Build Cabal: 167s vs 259s
I assume from your statement that (2) is 167s and (1) is 259s?
These results surprise me, in a few
Both the current workflow and the one Joachim proposes here make sense to me,
with different pros and cons. But I think now is not the time for this debate:
what we have currently isn't working well enough to consider design changes.
That is, CI frequently has spurious failures, and it remains
I think you just unassign yourself using the widget on the right: Click on the
reviewers button, and you should see yourself highlighted. Click your own icon,
and that should remove you from the ticket.
Richard
> On Feb 9, 2022, at 10:35 AM, Norman Ramsey wrote:
>
> I've been assigned a few
Hi devs,
Can we please, please not have the linters stop more useful output during CI?
Over the past few months, I've lost several days of productivity due to the
current design. Why several days? Because I typically end up with only 1.5-2
hours for GHC work in a day, and when I have to spend
ote:
>
> Richard Eisenberg mailto:li...@richarde.dev>> writes:
>
>> Hi devs,
>>
> Hi Richard,
>
>> Can we please, please not have the linters stop more useful output
>> during CI? Over the past few months, I've lost several days of
>>
My recommendation: ./hadrian/ghci. The first time you run it, it may spin for a
little while, but it will eventually deliver you to a GHCi prompt, with all of
GHC loaded. (You can e.g. `:type splitTyConApp_maybe`, after `import
GHC.Core.Type`.) At that point, :reload will be your dear friend.
> On Jan 25, 2022, at 2:15 PM, Norman Ramsey wrote:
>
> Cool! Supposing I wanted to run just a little code that uses the GHC API.
> Would there be a way to load the Prelude and similar things into that GHCi,
> so it could know about Bool and IO and such things?
The GHCi that runs is your
I've been a bit under water of late, so I haven't gotten to respond to this.
But is this superseded by your later email? If not, I'm happy to take a stab at
an answer.
Thanks,
Richard
> On Jan 15, 2022, at 2:09 PM, Benjamin Redelings
> wrote:
>
> Hi,
>
> 1. I'm reading "A Static semantics
Modulo the backward-compatibility piece around today's type-level numbers, I'm
in support of this direction. No new type machinery is needed, other than a new
interpretation for literals, because type families can already infer a kind
argument from the return kind. This is almost entirely a
Hi devs,
I just wanted to call your attention to
https://gitlab.haskell.org/ghc/ghc/-/issues/21684, which will add a little more
bureaucracy to adding error messages in the future, but all for a good cause.
Please take a look and offer any feedback!
Thanks,
Richard
Hi all,
On a project I'm working on, I wish to declare something like
data Rec = MkRec { field :: forall a. SomeConstraint a => ... }
where the ... contains no mention of `a`.
Even with https://github.com/ghc-proposals/ghc-proposals/pull/448
> On May 16, 2022, at 3:45 PM, Sebastian Graf wrote:
>
> MkRec { field = \@a -> ... }
Hm -- perhaps you're right. I may have gotten myself all worked up over
nothing. I was worried that unification would get confused, not sure that the
`a`s match up. But I now think I was wrong -- it should
> On Jul 25, 2022, at 6:04 AM, ÉRDI Gergő wrote:
>
> 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
e definition*,
> but rather, using `tcLHsType` as the function that creates fresh metas
> for each wildcard.
>
> On Mon, Jul 25, 2022 at 8:58 PM Richard Eisenberg wrote:
>>
>>
>>
>>> On Jul 25, 2022, at 6:04 AM, ÉRDI Gergő wrote:
>>>
>>> On
> On Jul 22, 2022, at 4:53 AM, Simon Peyton Jones
> wrote:
>
> expand them during
> typechecking,
Just to expand on this point (haha): your new type macros (distinct from type
synonyms) would have to be eagerly expanded during type checking. You say this
(quoted above), but I wanted to
> On Aug 5, 2022, at 6:17 AM, ÉRDI Gergő wrote:
>
> 1. Defining partial type synonyms
>
This makes some sense to me. You're introducing a new form of invisible
(implicit) parameter, adding to the two we already have. Today, we have
A. invisible parameters that are filled in via
> On Dec 17, 2022, at 10:17 AM, Benjamin Redelings
> wrote:
>
> But supposing I do get there, I'm curious if there are some papers on
> term-rewriting that would be helpful to set the context? The OutsideIn paper
> mentions Kapur (1997) "Shostak's congruence closure as completion" in
> On Nov 30, 2022, at 9:42 PM, Benjamin Redelings
> wrote:
>
> (Q1) Did GHC evolve to this point starting from something fairly close to the
> OutsideIn paper?
Yes.
>
> (Q2) Is the new approach (i.e. eager type family rewriting) mostly to making
> rewriting faster?
No. Simpler, not
I think this is an excellent idea! So excellent, that we've already done it. :)
When I try to compile with GHC 9.6.2 (what I have lying around), GHC2021 is in
effect.
Is there something different you were thinking of?
Thanks,
Richard
> On Dec 7, 2023, at 4:39 AM, Arnaud Spiwack wrote:
>
>
801 - 819 of 819 matches
Mail list logo
