Re: New primitive types?

On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald wrote: > One issue with packed fields is that on many architectures you can't quite do subword reads or > writes. So it might not always be a win. Could you give any examples? Note that we're still going to do aligned

Re: GHC release timing and future build infrastructure

On 2017-08-02 21:26, Bardur Arantsson wrote: > I'd like to add a few thoughs (or just to underscore the ones you've > already brought forth, as the case may be): > [--snip--] > reasons -- I wouldn't presume to know. Also note that this is > *basically* how Rust also works, it's just that they

Re: New primitive types?

Hi, I also think we should do this but it has a lot of ramifications: contant folding in Core, codegen, TH, etc. Also it will break codes that use primitive types directly, so maybe it's worth a ghc proposal. Sylvain On 01/08/2017 15:37, Michal Terepeta wrote: Hi all, I'm working on

Re: GHC release timing and future build infrastructure

Bardur Arantsson writes: > On 2017-08-02 21:26, Bardur Arantsson wrote: > >> I'd like to add a few thoughs (or just to underscore the ones you've >> already brought forth, as the case may be): >> > [--snip--] >> reasons -- I wouldn't presume to know. Also note that this is

Limited availability next week

Hello everyone, I will be travelling starting tomorrow through next week. During this time I'll still try to check in on things once a day to make sure nothing is burning down. However, I will be a bit less available. Still feel free to ping me via email or IRC, however. I'll try to get back to

RE: dataToTag# documentation

Based on memory rather that investigation: - yes it works on any data type - The reason that the primop dataToTag# is dangerous is that it does not evaluate its argument; it relies on the wrapper getTag to do so.Caveat emptor! It would be good to document this. Simon | -Original

Re: GHC release timing and future build infrastructure

On Tue, Aug 1, 2017 at 4:19 AM Ben Gamari wrote: > > Hello everyone, > > I just posted a pair of posts on the GHC blog [1,2] laying out some > thoughts on the GHC release cycle timing [1] and how this relates to the > in-progress Jenkins build infrastructure [2]. When you

Re: GHC release timing and future build infrastructure

On 2017-08-01 15:05, Ara Adkins wrote: > Heya, > > I very much agree with the thoughts on the variability of the release > cadence. The following is somewhat of a stream of consciousness as I > read, so please excuse any lack of coherence. > > When you talk about the bugs being significant

RE: Restructuring hsSyn

I don’t object. (They’d be orphan instances, so the interface file will always be loaded; but that’s probably ok. From: Shayan Najd [mailto:sh.n...@gmail.com] Sent: 02 August 2017 11:50 To: ghc-devs@haskell.org Cc: Simon Peyton Jones ; Alan & Kim Zimmerman

RE: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy (6a50466)

Joachim Aha! I think my comment on Phab is redundant. You are simply avoiding name capture, which is obviously right; you are not restricting the applicability of the transformation. Needless to say, a Note would help in due course. S | -Original Message- | From: ghc-commits

Restructuring hsSyn

Currently AST declarations, their relate utilities, and `Outputable` instances are defined in the same files. Does anyone object to moving `Outputable` instances to separate files? The purpose is to gradually identify reusable functionalities, group them together, polish them (e.g., remove some

RE: Occurrence info on binders and STG

Can you be more specific? I don’t think occurrence info is used at all in STG. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor | Greif | Sent: 01 August 2017 16:02 | To: ghc-devs | Subject: Occurrence info on

Re: Restructuring hsSyn

Shayan Najd writes: > Currently AST declarations, their relate utilities, and `Outputable` > instances are defined in the same files. > Does anyone object to moving `Outputable` instances to separate files? > The purpose is to gradually identify reusable functionalities, group

Re: GHC release timing and future build infrastructure

Ara Adkins writes: > Heya, > > I very much agree with the thoughts on the variability of the release > cadence. The following is somewhat of a stream of consciousness as I > read, so please excuse any lack of coherence. > > When you talk about the bugs being significant blockers to