[Haskell] post-doctoral research position - Effect Handler Oriented Programming - Edinburgh

Hi, I have an opening for a post-doctoral research position at The University of Edinburgh on Effect Handler Oriented Programming (EHOP) funded by a UKRI Future Leaders Fellowship. Candidates should have a background in programming languages with experience of functional programming, formal

[Haskell] Online seminars in Tensor Computation, October to December

Department of Computer Science, University of Oxford Seminar Series on Tensor Computation http://www.cs.ox.ac.uk/seminars/Programming%20Languages/ The following seminars on tensor computation will take place at 4pm UK time on Fridays

Re: Pattern synonym constraints :: Ord a => () => ...

On Tue, 5 Oct 2021, David Feuer wrote: To be clear, the proposal to allow different constraints was accepted, but integrating it into the current, incredibly complex, code was well beyond the limited abilities of the one person who made an attempt. Totally severing pattern synonyms from

RE: Pattern synonym constraints :: Ord a => () => ...

must be the union of the constraints required to match the pattern, _plus_ required to build with the pattern -- if it is bidirectional. I think that is confusing too! How about this: * ⟨CReq⟩ are the constraints required to match the pattern, in a pattern match. * ⟨CProv⟩ are the

Re: Pattern synonym constraints :: Ord a => () => ...

On Wed, 6 Oct 2021 at 21:24, Simon Peyton Jones wrote: > > > I suggest the User Guide needs an example where a constraint needed for > matching (presumably via a View pattern) is not amongst the > constraints carried inside the data constructor, nor amongst those needed > for building. Then the

RE: Pattern synonym constraints :: Ord a => () => ...

Perhaps I'm just stupid, and should be disqualified from using such features. Only as a result of this thread (not from the User Guide nor from the paper) do I discover "use" means match-on. You are not stupid. And since you misunderstood despite effort, the presentation is - by definition -

Re: Pattern synonym constraints :: Ord a => () => ...

Thanks Gergö, I've read that paper many times (and the User Guide). Nowhere does it make the distinction between required-for-building vs required-for-matching. And since most of the syntax for PatSyns (the `where` equations) is taken up with building, I'd taken it that "required" means

Re: Pattern synonym constraints :: Ord a => () => ...

> I'm afraid none of this is apparent from the User Guide -- and I even > contributed some material to the Guide, without ever understanding that. > Before this thread, I took it that 'Required' means for building -- as in for > smart constructors. No, that's not what the required/provided

Re: Pattern synonym constraints :: Ord a => () => ...

If you haven't yet, it is probably a good idea to read section 6 of https://gergo.erdi.hu/papers/patsyns/2016-hs-patsyns-ext.pdf On Wed, Oct 6, 2021 at 10:23 AM Gergő Érdi wrote: > > > I'm afraid none of this is apparent from the User Guide -- and I even > > contributed some material to the

Re: Pattern synonym constraints :: Ord a => () => ...

Thank you. Yes that proposal seems in 'the same ball park'. As Richard's already noted, a H98 data constructor can't _Provide_ any constraints, because it has no dictionaries wrapped up inside. But I'm not asking it to! The current PatSyn signatures don't distinguish between Required-for-building

Re: Pattern synonym constraints :: Ord a => () => ...

Thank you Richard (and for the reply to a similar topic on the cafe). What I meant by the comparison to 'stupid theta' is that GHC's implementation of datatype contexts used to be mildly useful and moderately sensible. Then it went stupid, following this 'Contexts on datatype declarations'

Re: Pattern synonym constraints :: Ord a => () => ...

You're right -- my apologies. Here is the accepted proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0042-bidir-constr-sigs.rst Richard > On Oct 5, 2021, at 12:38 PM, David Feuer wrote: > > To be clear, the proposal to allow different constraints was accepted, but

[Haskell] Second and Final Call for Submissions: Programming Languages and the Law (ProLaLa)

---    ProLaLa 2022 -- 1st Workshop on Programming Languages and the Law    Sunday Jan 16th, 2022 Philadelphia, PA co-located with POPL 2022

[Haskell] Second and Final Call for Presentations: PriSC 2022 @ POPL 2022

All details are on the PriSC site . Call for Presentations: PriSC 2022 @ POPL 2022 The emerging field of secure compilation aims to preserve security

Re: Pattern synonym constraints :: Ord a => () => ...

I meant my own brief attempt. Severing them absolutely wouldn't make them less useful. pattern Foo :: ... pattern Foo x <- constructor Foo :: ... constructor Foo x = ... Separate namespaces, so you can have both, and both can be bundled with a type. On Tue, Oct 5, 2021, 1:11 PM Edward

Re: Pattern synonym constraints :: Ord a => () => ...

On Tue, Oct 5, 2021 at 12:39 PM David Feuer wrote: > To be clear, the proposal to allow different constraints was accepted, but > integrating it into the current, incredibly complex, code was well beyond > the limited abilities of the one person who made an attempt. Totally > severing pattern

Re: Pattern synonym constraints :: Ord a => () => ...

To be clear, the proposal to allow different constraints was accepted, but integrating it into the current, incredibly complex, code was well beyond the limited abilities of the one person who made an attempt. Totally severing pattern synonyms from constructor synonyms (giving them separate

Re: Pattern synonym constraints :: Ord a => () => ...

> On Oct 3, 2021, at 5:38 AM, Anthony Clayden > wrote: > > >pattern SmartConstr :: Ord a => () => ... > > Seems to mean: > > * Required constraint is Ord a -- fine, for building Yes. > * Provided constraint is Ord a -- why? for matching/consuming No. Your signature specified that

[Haskell] ETAPS 2022 final call for papers

Paper submission deadline: 14 Oct 2021 23:59 AoE ** JOINT CALL FOR PAPERS 25th European Joint Conferences on Theory and Practice of Software ETAPS 2022 Munich,

[Haskell] FM 2021 - Call for Participation

[Please distribute, apologies for multiple postings.] FM 2021 is the 24th international symposium in a series organized by Institute of Software, Chinese Academy of Sciences, under the auspices of Formal Methods Europe (FME), held on-line during November 20-26, 2021. -- ABOUT FM FM 2021 is the

Pattern synonym constraints :: Ord a => () => ...

Thank you to Richard for the Tweag tutorials on Pattern Synonyms. That third one on Matchers was heavy going. I didn't find an answer (or did I miss it?) to something that's bugging me: >pattern SmartConstr :: Ord a => () => ... Seems to mean: * Required constraint is Ord a -- fine, for

[Haskell] [TFP'22] first call for papers: Trends in Functional Programming 2022, 10-11 February (with Lambda Days 2022 & TFPIE 2022)

== TFP 2022 == 23rd Symposium on Trends in Functional Programming 10-11 February, 2022 Krakow, Poland https://trendsfp.github.io/index.html == Important Dates == Submission deadline for pre-symposium review    Wednesday 1st December, 2021 Submission deadline for draft papers 

[Haskell] Call for Papers: FLOPS 2022

Call For Papers FLOPS 2022: 16th International Symposium on Functional and Logic Programming

[Haskell] ETAPS 2022 2nd joint call for papers

Why choose ETAPS? - ETAPS is one of the world's leading fora for research on software science, with a history of more than 25 years. - The proceedings of ETAPS appear in gold open access, with no article processing charge for the authors specifically. - ETAPS has low participation fees for

[Haskell] Second Call for Papers: 24th International Symposium on Practical Aspects of Declarative Languages (PADL 2022)

=== Second Call for Papers === 24th International Symposium on Practical Aspects of Declarative Languages (PADL 2022) Philadelphia, Pennsylvania, United States 17-18th January 2022 https://popl22.sigplan.org/home/PADL-2022 Co-located with POPL 2022 Conference Description

[Haskell] PEPM 2022 - Second Call for Papers

-- CALL FOR PAPERS -- ACM SIGPLAN Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM) 2022 === * Website : https://popl22.sigplan.org/home/pepm-2022 * Time: 17th--18th

Re: InstanceSigs -- rationale for the "must be more polymorphic than"

> On 18 Sep 2021, at 04:29, Anthony Clayden wrote: > "InstanceSigs is a mis-feature. Don't use it. It is less confusing to just > give no signature at all. If you really, really want to bind tyvars, use > PatternSignatures." I would strongly disagree with this statement. I think instance

Re: Was: [Haskell-cafe] Haskell reference documentation, laws first or laws last?

Another example are non-empty containers, e.g. for `NonEmpty`  one cannot have a total `fromList :: [a] -> NonEmpty a`. Regards, Marcin Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, September 19th, 2021 at 08:49, David Feuer wrote: > No, fromList is too

Re: Was: [Haskell-cafe] Haskell reference documentation, laws first or laws last?

No, fromList is too much. Consider data Foo a = Foo (IORef String) [a] deriving Foldable What IORef should fromList use? On Sun, Sep 19, 2021, 2:44 AM Anthony Clayden wrote: > (Moving this discussion to glasgow-users. It's just not appropriate on the > cafe.) > > > > I am no longer a

Was: [Haskell-cafe] Haskell reference documentation, laws first or laws last?

(Moving this discussion to glasgow-users. It's just not appropriate on the cafe.) > I am no longer a novice, and yet would still have a hard time making any use of the laws as written in constructing instances. Instead, I'd ignore the laws and write a natural intuitive instance, and it would

Re: InstanceSigs -- rationale for the "must be more polymorphic than"

> If you would like to offer a patch for the user manual to explain this better, that would be great. Thank you Simon for the invitation. On further investigation https://gitlab.haskell.org/ghc/ghc/-/issues/20357, what I'd like the user manual to say is: "InstanceSigs is a mis-feature. Don't

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

Here's a class example: class (MFoldable t, Monoid t) => Sequence t where singleton :: Elem t -> t One might wish to write pattern synonyms for viewing the ends of a sequence, like the ones in Data.Sequence, and bundle them with this class. On Thu, Sep 16, 2021, 2:22 PM Carter

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

Here's an example: pattern State :: (s -> (a, s)) -> State s a pattern State f <- (coerce . runStateT -> f) where State = state This would be very nice to bundle with the State type synonym. On Thu, Sep 16, 2021, 2:22 PM Carter Schonwald wrote: > These are great ideas! Could you please

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

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

[Haskell] Doctoral Symposium at FM 2021: Call for Research Abstracts

Doctoral Symposium at FM 2021 Call for Research Abstracts --- (See also: https://lcs.ios.ac.cn/fm2021/doctoral-symposim/) A Doctoral Symposium will be held in conjunction with the 24th International Symposium on Formal Methods (FM 2021), 20-26

[Haskell] Call for Presentations: PriSC 2022 @ POPL 2022

Apologies if you're getting this email multiple times. All details are on the PriSC site . Call for Presentations: PriSC 2022 @ POPL 2022 The emerging

[Haskell] [EDI40-2022] Call for workshop proposals: Conference on Emerging Data and Industry 4.0. Porto, Portugal (March 22-25, 2022)

*** The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22-25, 2022 *** Conference Website:

Re: [Haskell] The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22-25, 2022

Can we please unsubscribe this person? Cheers, Ivan On Mon, 13 Sept 2021 at 23:02, Shashank Swarup wrote: > *** > The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) > Porto, Portugal > March 22-25,

[Haskell] The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22-25, 2022

*** The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22-25, 2022 *** Conference Website:

[Haskell] CFP: The 6th International Workshop on Agent-based Modeling and Applications with SARL (SARL-22)

Call For Papers CFP: The 6th International Workshop on Agent-based Modeling and Applications with SARL (SARL-22) --- In conjunction with the 13th International Conference on Ambient Systems, Networks,

[Haskell] CFW: The 13th International Conference on Ambient Systems, Networks and Technologies (ANT-2022)

Call For Workshops CFW: The 13th International Conference on Ambient Systems, Networks and Technologies (ANT-2022) Porto, Portugal March 22 - 25, 2022 http://cs-conferences.acadiau.ca/ant-22/ Important Dates - Workshops Proposals Due: October 1, 2021 ANT-2022 organizing committee

[Haskell] CFW: The 5th International Conference on Emerging Data and Industry 4.0 (EDI40)

Call For Workshops The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22 - 25, 2022 http://cs-conferences.acadiau.ca/edi40-22/ Important Dates - Workshops Proposals Due: October 1, 2021 EDI40-2022 organizing committee invites proposals for

[ANN] Cabal-3.6.1.0 and cabal-install-3.6.0.0

Hello all, The Cabal team is excited to announce the release of both `Cabal-3.6.1.0`, and `cabal-install-3.6.0.0`! ## Changelog for `Cabal-3.6.1.0` This release of `Cabal` is a point release that allowed us to get some important features out into the ecosystem that just couldn't wait: -

[Haskell] [CfP]: 13th International Conference on Ambient Systems, Networks and Technologies (ANT) Porto, Portugal, March 22-25, 2022

*** The 13th International Conference on Ambient Systems, Networks and Technologies (ANT) Porto, Portugal March 22-25, 2022 *** Conference Website:

[Haskell] [CfP]: 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal, March 22-25, 2022

*** The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22-25, 2022 *** Conference Website:

[Haskell] [CFP]11th Int. Conf. on Sensor Networks :: Submission Deadline - 14th of September

CALL FOR PAPERS 11th International Conference on Sensor Networks **Submission Deadline: September 14, 2021** http://www.sensornets.org February 07 - 08, 2022 Online Streaming Dear Colleagues, Given the uncertainties of the current international situation, including constraints

[Haskell] 30 months postdoctoral research position at University of Sheffield involving proof-assistant-based verification -- application deadline 23 Sept. 2021

Greetings, A postdoctoral research position (Grade 7) is available at the University of Sheffield. The goal is to perform research in one of the following areas: 1. Formal modelling and verification of security properties for digital twins. This involves the design and development of theoretical

[Haskell] Call for Contributions: WITS 2022

-- CALL FOR CONTRIBUTIONS 1st Workshop on the Implementation of Type Systems WITS 2022 January 22, 2022

[Haskell] IFL'21 final call for participation

IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September

[Haskell] [ANNOUNCE] GHC 8.10.7 released

The GHC team is very pleased to announce the availability of GHC 8.10.7. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.7/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_7.html Blog Post:

[Haskell] Research Assistant/Associate at Department of Computing, Imperial College London

Department of Computing, Imperial College London Research Assistant/Associate Position (Full Time) 36,394 GBP to 49,210 GBP per annum Reference: Fixed-term: 3 years Starting date: as soon as possible Closing Date: 16th September 2021 The Research Assistant will work under the EPSRC Established

[Haskell] Research Assistant/Associate at Department of Computing, Imperial College London

Department of Computing, Imperial College London Research Assistant/Associate Position (Full Time) 36,394 GBP to 49,210 GBP per annum Reference: Fixed-term: 3 years Starting date: as soon as possible Closing Date: 16th September 2021 The Research Assistant will work under the EPSRC Established

[Haskell] IFL'21 call for participation

IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September

Re: [ANNOUNCE] GHC 9.2.1-rc1 now available

I mean GHC.Tuple, of course. On Sun, Aug 22, 2021, 8:14 PM David Feuer wrote: > One more question: is Solo exported from Data.Tuple yet, or do we still > have to depend on ghc-prim and import it from GHC.Magic? It would be really > nice to have that fixed by release, and it's so tiny. > > On

Re: [ANNOUNCE] GHC 9.2.1-rc1 now available

One more question: is Solo exported from Data.Tuple yet, or do we still have to depend on ghc-prim and import it from GHC.Magic? It would be really nice to have that fixed by release, and it's so tiny. On Sun, Aug 22, 2021, 6:01 PM Ben Gamari wrote: > > Hi all, > > The GHC developers are very

Re: [ANNOUNCE] GHC 9.2.1-rc1 now available

Have array and reference types and primos been updated to be BoxedRep-polymorphic, or is it still just expensive scaffolding? On Sun, Aug 22, 2021, 6:01 PM Ben Gamari wrote: > > Hi all, > > The GHC developers are very happy to announce the availability of the > release cadidate of the 9.2.1

[ANNOUNCE] GHC 9.2.1-rc1 now available

Hi all, The GHC developers are very happy to announce the availability of the release cadidate of the 9.2.1 release. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1-rc1 GHC 9.2 will bring a number of exciting features

The State of GHC 8.10

Hi all, GHC 8.10.6 was released last week, with high hopes of finally putting an end to the long running saga of the GHC 8.10 series. Unfortunately, this was not to be the case as we soon discovered #19950, an issue that we claimed to have fixed in the 8.10.6 release, was still affecting the

[Haskell] Call for Participation: Haskell Implementors' Workshop 2021

Call for Participation ACM SIGPLAN Haskell Implementors' Workshop Sunday 22 Aug 20:00-05:00 (Seoul) https://icfp21.sigplan.org/home/hiw-2021 We are happy to announce that Haskell Implementors' Workshop is taking place this

RE: -dinline-check for symbolic names?

| First, reading the ghc source code suggests I can only have one -ddinline- | check. Correct? Yes. The last one wins. This should be in the user manual. Would anyone like to offer a PR? | Also, I'm guessing that the inlining I didn't see reported by -dinline-check | happened inside the

[Haskell] Certified Programs and Proofs (CPP) 2022: Final Call for Papers

Certified Programs and Proofs (CPP) is an international conference on practical and theoretical topics in all areas that consider formal verification and certification as an essential paradigm for their work. CPP spans areas of computer science, mathematics, logic, and education. CPP 2022

Re: -dinline-check for symbolic names?

On Tue, Aug 10 2021, Simon Peyton Jones wrote: > It's hard to tell what is happening without a repro case. Can you share one? Haven't been able to do that with <10MB of output, I'm afraid ... > You suggested that it might have something to do with using an > operator. Does the same thing

Re: Avoiding construction of dead dictionaries

On Thu, Aug 12 2021, Simon Peyton Jones wrote: > Repro case is something like > * Here is a source or files > * Compile like this > * Look at the generated Core...observe silly thing happening Tried my best here: https://gitlab.haskell.org/ghc/ghc/-/issues/20237 Any help on this would be

[Haskell] Assistant/Associate Professorships in Nottingham

Dear all, As part of a strategic expansion, the School of Computer Science at the University of Nottingham is seeking to make multiple new appointments at the Assistant or Associate Professor level: https://tinyurl.com/wruwpnpt https://tinyurl.com/284svw4y Applications in the area of the

Re: [ANN] Cabal-3.6.0.0

Ah - i didn't even notice the confusion: Cabal (the library) and cabal-install (the tool) are not released in lockstep. The cabal-install-3.6.0.0 release is coming next week, and is currently in review. On Sun, Aug 15, 2021 at 11:05 AM, Tom Smeding < x...@tomsmeding.com > wrote: > > > >

Re: [ANN] Cabal-3.6.0.0

Cabal-3.6.0.0 is there, but cabal-install-3.6.0.0 is not. :) - Tom On 15/08/2021 18:40, Emily Pillmore wrote: > This may be a local problem with your browser cache. Here's what I see: > > Cabal-3.2.1.0/ >

Re: [ANN] Cabal-3.6.0.0

This may be a local problem with your browser cache. Here's what I see: > > Cabal-3.2.1.0/ ( https://downloads.haskell.org/~cabal/Cabal-3.2.1.0/ ) > 01-Mar-2021 19:27 - > Cabal-3.4.0.0/ ( https://downloads.haskell.org/~cabal/Cabal-3.4.0.0/ ) > 28-Feb-2021 21:59

Re: [ANN] Cabal-3.6.0.0

Sorry, I still do not see 3.6.0.0 on the downloads site. Here’s the tail of what I see at https://downloads.haskell.org/~cabal/ … > cabal-install-3.2.0.0/ 16-May-2020 07:42 > - > cabal-install-3.4.0.0/ 23-Feb-2021 23:00

Re: [ANN] Cabal-3.6.0.0

There, we've purged the cache and I'm seeing everything up to date :) On Sat, Aug 14, 2021 at 8:17 PM, Emily Pillmore < emil...@cohomolo.gy > wrote: > > It already exists on the site, but it looks like the old dirs are cached > > > > > > > > On Sat, Aug 14, 2021 at 7:56 PM, Steven Smith

Re: [ANN] Cabal-3.6.0.0

It already exists on the site, but it looks like the old dirs are cached On Sat, Aug 14, 2021 at 7:56 PM, Steven Smith < steve.t.sm...@gmail.com > wrote: > > Thank you! Will the release be posted to the haskell downloads site? > > > https:/ / downloads. haskell. org/ ~cabal/ ( >

Re: [ANN] Cabal-3.6.0.0

Thank you! Will the release be posted to the haskell downloads site? https://downloads.haskell.org/~cabal/ Several package managers (e.g. MacPorts) build using this site. > On Aug 5, 2021, at 5:27 PM, Emily Pillmore wrote: > > Hello All, > > The Cabal team is excited to announce the release

[Haskell] [ANNOUNCE] GHC 8.10.6 released

The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.6/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html Blog Post:

RE: Avoiding construction of dead dictionaries

Hi Mike Repro case is something like * Here is a source or files * Compile like this * Look at the generated Core...observe silly thing happening Evidence of importance could be as simple as "in my application I'm seeing a lot of these redundant dictionaries being built for no reason". Or,

[Haskell] PEPM 2022 - First Call for Papers

-- CALL FOR PAPERS -- ACM SIGPLAN Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM) 2022 === * Website : https://popl22.sigplan.org/home/pepm-2022 * Time: 17th--18th

Re: Avoiding construction of dead dictionaries

On Mon, Aug 09 2021, Simon Peyton Jones wrote: > Could you offer a small repro case, with a pointer to evidence that it > matters in practice, and open a ticket? I'll try my best, but I'm unsure how I would generate evidence. Could you give me a hint? Is there any way to see how far

Re: InstanceSigs -- rationale for the "must be more polymorphic than"

On Tue, 10 Aug 2021 at 21:15, Simon Peyton Jones wrote: > > > I think you see why the instance sig must be at least as polymorphic ... > Thanks Simon, I do now see, but I'd have to say there's a heck of lot of questions on StackOverflow (most not from me) being surprised/asking why. See more

Re: InstanceSigs -- rationale for the "must be more polymorphic than"

Ah, I see. Yes, you're right. Sorry. On Tue, Aug 10, 2021, 3:15 PM Simon Peyton Jones wrote: > Do you have a concrete example? > > > > I think that the recursive calls will all go via the original class method > with its original type – we can’t know that it’s calling **this** > instance till

RE: InstanceSigs -- rationale for the "must be more polymorphic than"

Do you have a concrete example? I think that the recursive calls will all go via the original class method with its original type - we can't know that it's calling *this* instance till much later. So I still don't get it. An example would clear it up. Simon From: David Feuer Sent: 10

Re: InstanceSigs -- rationale for the "must be more polymorphic than"

Simon, there are times when a function has to be generalized to be made polymorphic recursive. Perhaps the method takes an argument of type x (not a class parameter), but to call itself, it needs to be able to take types x, T x, T (T x), etc. That additional polymorphism can be introduced in the

RE: -dinline-check for symbolic names?

It's hard to tell what is happening without a repro case. Can you share one? You suggested that it might have something to do with using an operator. Does the same thing happen if you replace the operator with an alpha-numeric name? Simon | -Original Message- | From:

RE: InstanceSigs -- rationale for the "must be more polymorphic than"

AntC, I think you see why the instance sig must be at least as polymorphic than the instantiated signature from the class - because that's what the client is going to expect. We are building a record of functions, and they must conform to the class signature. I agree with David's (1) and (2)

RE: Avoiding construction of dead dictionaries

Hi Mike | The right-hand argument of <+ leads to a dictionary construction that is a | proof of a certain property, but the dictionary itself ends up being dead, | like so: | |case $w$dOpCon_r2kGJ ... |of |{ (# ww1_s27L3 #) -> ... } | ^ |

Re: Avoiding construction of dead dictionaries

Hi all, On 09/08/2021 16:31, Brandon Allbery wrote: We haven't figured out what they did, but the other day we had someone in #haskell with an infinite loop evaluating a dictionary. So apparently it is possible for a dictionary to be bottom somehow. I managed to do something like this once:

Re: Avoiding construction of dead dictionaries

They didn't show code (this is sadly common), so we had only speculation. :( On Mon, Aug 9, 2021 at 11:56 AM Simon Peyton Jones wrote: > > . So apparently it is possible for a dictionary to be bottom somehow. > > That should not happen. > > > > Except in the case of single-method dictionaries

RE: Avoiding construction of dead dictionaries

> . So apparently it is possible for a dictionary to be bottom somehow. That should not happen. Except in the case of single-method dictionaries like class C a where op :: a -> a In these cases the "dictionary" is represented by a newtype, like this newtype C a =

Re: Avoiding construction of dead dictionaries

We haven't figured out what they did, but the other day we had someone in #haskell with an infinite loop evaluating a dictionary. So apparently it is possible for a dictionary to be bottom somehow. On Mon, Aug 9, 2021 at 11:27 AM Tom Smeding wrote: > Hi Mike, > > > > But wouldn't that imply

Re: Avoiding construction of dead dictionaries

Hi Mike, > But wouldn't that imply that ghc can build dictionary-construction code > that evaluates to bottom? Can that happen? I assume no, but here the dictionary is embedded as a field in the GADT, right? So if the data value is bottom, there is not even a dictionary to be found, let alone

Re: Avoiding construction of dead dictionaries

Thanks for thinking about this one! On Fri, Aug 06 2021, Tom Smeding wrote: > Would it not be unsound for ghc to elide dictionary construction here? > After all, the right-hand side might actually be a bottom > (e.g. undefined) at run-time, in which case the pattern match cannot > succeed

Re: InstanceSigs -- rationale for the "must be more polymorphic than"

To the best of my knowledge, `InstanceSigs` are never strictly necessary. They can, however, be useful for at least four purposes: 1. To provide a compiler-checked reminder of the type. 2. To bind type variables with `ScopedTypeVariables`. 3. To generalize the type so you can use polymorphic

InstanceSigs -- rationale for the "must be more polymorphic than"

I can't help but feel InstanceSigs are either superfluous or upside-down. It's this bit in the User Guide: > The type signature in the instance declaration must be > more polymorphic than (or the same as) the one in the class declaration, > instantiated with the instance type. Usually if you

Re: Avoiding construction of dead dictionaries

Would it not be unsound for ghc to elide dictionary construction here? After all, the right-hand side might actually be a bottom (e.g. undefined) at run-time, in which case the pattern match cannot succeed according to the semantics of Haskell. I suspect that if you make the pattern match lazy

Avoiding construction of dead dictionaries

I have another optimization problem. ConCat includes this definition: (<+) :: Con a => (Con b => r) -> (a |- b) -> r r <+ Entail (Sub Dict) = r The right-hand argument of <+ leads to a dictionary construction that is a proof of a certain property, but the dictionary itself ends up being dead,

[Haskell] Preliminary Call for Papers: FLOPS 2022

Preliminary Call For Papers FLOPS 2022: 16th International Symposium on Functional and Logic Programming May 10-12, 2022, Kyoto, Japan

[Haskell] Call for Workshops - FLoC 2022

Second Call for Workshops- FLoC 2022 — The 2022 Federated Logic Conference July 31 - August 12, 2022 Haifa, Israel http://www.floc2022.org/ CALL FOR WORKSHOPS The Eighth Federated Logic Conference (FLoC 2022) will host the following ten conferences and affiliated workshops. LICS (37th Annual

Re: -dinline-check for symbolic names?

On Fri, Aug 06 2021, Michael Sperber wrote: > On Wed, Aug 04 2021, Carter Schonwald wrote: > >> I’m not sure about the pragma debugging, but are you using it in point free >> style? Cause I’m that case it may not be inclined because it’s not being >> fully applied on the left hand side? > >

Re: -dinline-check for symbolic names?

On Wed, Aug 04 2021, Carter Schonwald wrote: > I’m not sure about the pragma debugging, but are you using it in point free > style? Cause I’m that case it may not be inclined because it’s not being > fully applied on the left hand side? Good point, but I checked, and it's fully applied. :-( I

Re: [ANN] Cabal-3.6.0.0

Hi Thomas, > The changelog (and the 3.6 branch) does not include > https://github.com/haskell/cabal/pull/7493. This is just as well since HEAD > (with this merge) doesn't fix the related issue in my testing, but I'm > curious if such a fix can be part of a point release or if it must be 3.8?

[Haskell] Call for Lightning Talks: Haskell Implementors' Workshop @ ICFP'21

Call for Lightning Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021

Re: [ANN] Cabal-3.6.0.0

Hey Tom, The 3.6 branch was feature frozen by early Summer, so 7493 didn't go in to it afaict. However, if there's a reasonable fix, I see no reason why we can't backport it to a point release for the 3.6 series. I'll discuss with Mikolaj and we'll see what we can do :) Cheers, Emily On

[Haskell] Call for Participation: ICFP 2021

= Call for Participation ICFP 2021 26th ACM SIGPLAN International Conference on Functional Programming and affiliated events

<    1   2   3   4   5   6   7   8   9   10   >