Re: GHC support for the new record package

On 2015-01-21 17:01, Johan Tibell wrote: My thoughts mostly mirror those of Adam and Edward. [--snip--] 3) I don't think it's a good idea to have lots of functions be polymorphic in the record types of their arguments. If that falls out for free (like it does both in ORF and Nikita's

Re: Deprecating functions

On 2015-01-09 11:25, Herbert Valerio Riedel wrote: On 2015-01-09 at 11:18:02 +0100, Jan Stolarek wrote: The reall question is how to remember that we should remove this at some point? This affects all exposed libraries; I think it's enough to simply make this part of the

Re: wither the Platform

On 25-03-2015 15:24, Mark Lentczner wrote: Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a

Re: Delaying 7.10?

On 01/29/2015 08:54 PM, Austin Seipp wrote: After thinking about it a little, I'm fine with pushing the release out to March. I think #9858 is the more serious of our concerns vs a raging debate, too. My only concern really is dealing with the merging of such a patch. For example, if the

Re: [Haskell-cafe] RFC: Native -XCPP Proposal

On 06-05-2015 16:32, Sven Panne wrote: 2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net: +1, I'll wager that the vast majority of usages are just for version range checks. The OpenGL-related packages used macros to generate some binding magic (a foreign import plus some

Re: RFC: Native -XCPP Proposal

On 05/19/2015 07:31 AM, Carter Schonwald wrote: I imagine your ghc build uses gcc to invoke the system assembler and linker on your Linux servers, :-) and that's gplv3! That is of no consequence licensing-wise since those are a) separate programs/executables, thus derived work doesn't enter

Re: RFC: Native -XCPP Proposal

On 05/19/2015 08:26 AM, Bardur Arantsson wrote: On 05/19/2015 07:31 AM, Carter Schonwald wrote: I imagine your ghc build uses gcc to invoke the system assembler and linker on your Linux servers, :-) and that's gplv3! That is of no consequence licensing-wise since those are a) separate

Re: RFC: Native -XCPP Proposal

On 05/19/2015 11:04 AM, Boespflug, Mathieu wrote: On 19 May 2015 at 08:26, Bardur Arantsson s...@scientician.net wrote: On 05/19/2015 07:31 AM, Carter Schonwald wrote: I imagine your ghc build uses gcc to invoke the system assembler and linker on your Linux servers, :-) and that's gplv3

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

On 05/20/2015 03:39 PM, Yitzchak Gale wrote: [--snip--] Keeping the license as is seems to be important to Malcolm. So could we have an option to build GHC without cpphs and instead use it as a stand-alone external program? That would make the situation no worse than GMP. I don't see any need

Re: SV: Abstract FilePath Proposal

On 06/27/2015 11:33 AM, Niklas Larsson wrote: Hi! Instead of trying to minimally patch the existing API and still breaking loads of code, why not make a new API that doesn't have to compromise and depreciate the old one? This is a good idea in theory, but it's how we end up in situations

Re: Abstract FilePath Proposal

On 06/26/2015 06:08 PM, Herbert Valerio Riedel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello *, What? = [--snip--] I am *entirely* behind this in priciple and if it doesn't break too much of Hackage, also in practice, but... ... how much of Hackage *does* this break?

Re: Abstract FilePath Proposal

On 07/04/2015 09:38 PM, Brandon Allbery wrote: On Sat, Jul 4, 2015 at 3:26 PM, Sven Panne svenpa...@gmail.com wrote: To me the fundamental question which should be answered before any detail question is: Should we go on and continuously break minor things (i.e. basically give up any

Re: Abstract FilePath Proposal

On 07/05/2015 12:27 AM, Brandon Allbery wrote: On Sat, Jul 4, 2015 at 6:17 PM, Bardur Arantsson s...@scientician.net wrote: Yes, the rest of the ecosystem may move along and use the latest new shiny, but then you can always use the packages that worked with GHC 7.8.x thanks to version

Re: Abstract FilePath Proposal

On 07/05/2015 08:40 PM, Brandon Allbery wrote: On Sun, Jul 5, 2015 at 2:25 PM, Bardur Arantsson s...@scientician.net wrote: How often have security issues with GHC (or the base libraries) itself been a problem? (In practice, I mean.) Not that often, but consider one real example: aeson

Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

On 05/21/2015 12:31 PM, Herbert Valerio Riedel wrote: Hi Yitzchak, On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: [...] Bardur Arantsson wrote: I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has

Re: [Haskell-cafe] RFC: Native -XCPP Proposal

On 05/21/2015 05:36 PM, Malcolm Wallace wrote: On 21 May 2015, at 15:54, Bardur Arantsson wrote: fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter. Don't count on it. On our Windows

Re: "Excuse me, I think this i my stop..." - Resigning from the Platform

On 10/13/2015 05:08 AM, Mark Lentczner wrote: > I think this is the right time for me to exit: > I'm pretty sure that there are many things that we could agree or disagree on, but *THANK YOU* for your efforts on improving the Haskell ecosystem and your efforts to spread the word! Regards,

Re: Planning for the 7.12 release

On 08/28/2015 07:33 PM, Ben Gamari wrote: Simon Peyton Jones simo...@microsoft.com writes: Actually that’s a good idea. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Greg Weber Sent: 28 August 2015 16:43 To: Ben Gamari Cc: GHC developers Subject: Re: Planning

Re: more releases

On 09/07/2015 04:57 PM, Simon Peyton Jones wrote: > Merging and releasing a fix to the stable branch always carries a cost: > it might break something else. There is a real cost to merging, which > is why we've followed the lazy strategy that Ben describes. > A valid point, but the upside is

Re: Proposal: accept pull requests on GitHub

On 09/03/2015 09:18 AM, Joe Hillenbrand wrote: >> As a wild idea -- did anyone look at /Gitlab/ instead? > > My personal experience with Gitlab at a previous job is that it is > extremely unstable. I'd say even more unstable than trac and > phabricator. It's especially bad when dealing with long

Re: Moving ArgumentsDo forward

On 06/01/2016 01:48 PM, Akio Takano wrote: > Hi, > > Ticket #10843 [0] proposes an extension, ArgumentsDo, which I would > love to see in GHC. It's a small syntactic extension that allows do, > case, if and lambda blocks as function arguments, without parentheses. > However, its differential

Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)

On 02/06/2016 03:55 PM, Roman Cheplyaka wrote: > But despite all the negativity in this thread, I want to say that your > work on this and other aspects of GHC is very much appreciated. Keep it up! > +1000 ___ ghc-devs mailing list

Re: perf.haskell.org’s list of branches got more useful

On 04/26/2016 11:11 PM, Joachim Breitner wrote: > Hi, > > Am Dienstag, den 26.04.2016, 16:57 +0200 schrieb Bardur Arantsson: >> On 04/26/2016 01:09 PM, Joachim Breitner wrote: >>> * What does "2 days ago" mean? >>> The age of the latest commit to th

Re: perf.haskell.org’s list of branches got more useful

On 04/26/2016 01:09 PM, Joachim Breitner wrote: > Hi, > > >> * What does "2 days ago" mean? > > The age of the latest commit to the branch. > FWIW, I think adding a few simple table headings might help enormously. "Last commit", "?", "Branch", "Last commit message", "Diffstat". (or

Re: Proposal process status

On 07/21/2016 08:38 PM, Richard Eisenberg wrote: > >> On Jul 21, 2016, at 2:25 PM, Yuras Shumovich wrote: >> [--snip--] >> Haskell Prime committee will never catch up if GHC will continue >> adding new extensions. > > Of course not. But I believe some libraries also

Re: Request for feedback: deriving strategies syntax

On 2016-08-04 02:50, Ryan Scott wrote: > I'm > holding out hope that the work in > https://github.com/shayan-najd/NativeMetaprogramming makes things > nicer soon, and then we can revisit this idea. Are there any papers on this? (Or even just blog posts and such.) Sounds really intriguing, but

Re: Is Safe Haskell intended to allow segfaults?

On 2016-08-12 20:37, Edward Kmett wrote: > What about consuming Storable Vectors carefully, or simply working > parameterized over vector type, where Storable vectors are one of the > options? > There was actually a great paper about a very similar thing (i.e. "here's the usual interface" vs.

Re: Request for feedback: deriving strategies syntax

On 2016-08-05 11:06, Ben Gamari wrote: > Ryan Scott writes: > >> Sorry for not including the full context on that link. It's part of a >> Summer of Haskell 2016 project called Native Metaprogramming in >> Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to

Re: Request for feedback: deriving strategies syntax

On 2016-08-18 07:44, Malcolm Wallace wrote: > > On 18 Aug 2016, at 06:34, Bardur Arantsson wrote: > >> Not a native (British) English speaker, but I've consumed a *lot* of UK >> media over the last ~25-30 years and I can literally only recall having >>

Re: Request for feedback: deriving strategies syntax

On 2016-08-18 20:46, Ryan Scott wrote: > Bardur, > > Since you don't like "bespoke", would you mind suggesting an > alternative, or advocating for a previously mentioned idea? From [1], > the ideas I've seen tossed around are: > > * builtin > * standard (Elliot Cameron suggested it here [2]) > *

Re: Request for feedback: deriving strategies syntax

On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote: >> Honestly, I don't care particularly much which exact word it becomes >> just as long at isn't some 'cute' or obscurse[1] word. >> >> 'magic' belongs in the 'cute' category, I think and 'bespoke' belongs in >> the latter. > I'm native German.

Re: Request for feedback: deriving strategies syntax

(Sorry if anybody receives this twice, I think I flubbed my 'send'.) On 2016-08-19 08:34, monkleyon--- via ghc-devs wrote: > Yet my vote is with "bespoke". Short, informative, recognizable, and a > nice balance of quirky and reasonable, just like so much else here. > ... oh, and might I submit

Re: Request for feedback: deriving strategies syntax

On 2016-08-19 03:45, Baldur Blöndal wrote: > I haven't followed the thread but do we actually need a name for it, > can't it be indicated by omission? > ‘default’ or ‘builtin’ sounds okay 'default' is good too, IMO. ___ ghc-devs mailing list

Re: Request for feedback: deriving strategies syntax

On 2016-08-12 20:31, Ryan Scott wrote: > On the subject of alternative names, you may be interested in reading > this section of the DerivingSyntax wiki page [2], which lists other > names besides "bespoke" and "builtin" that have been tossed around as > ideas. They include: > > * magic > *

Re: How, precisely, can we improve?

On 2016-09-30 19:26, Carter Schonwald wrote: > We all do!. I dont. (Sorry, just had to put that Monty Python joke in there. At least I *think* it was MP?) Obviously, yes, we all *really* *REALLY* like Haskell, otherwise we wouldn't be arguing about it, would we? ;) Regards,

Re: Attempt at a real world benchmark

On 2016-12-09 08:31, Bardur Arantsson wrote: > Actually, now that I think about it: What about if this were integrated > into the Cabal infrastructure? If I specify "upload-perf-numbers: True" > in my .cabal file, any project on (e.g.) GitHub that wanted to opt-in > could d

Re: Attempt at a real world benchmark

On 2016-12-08 17:04, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 08.12.2016, 01:03 -0500 schrieb Joachim Breitner: >> I am not sure how useful this is going to be: >> + Tests lots of common and important real-world libraries. >> − Takes a lot of time to compile, includes CPP macros and

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 w

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: Which stable GHC release is expected to have support for linear types?

On 2017-07-14 01:26, Mike Ledger wrote: > How about: -+ > > It almost looks arrow like if you squint, and have a font that lines up > the horizontal lines. > This may play havoc with programming fonts with ligatures where it might be rendered as a single ± symbol. (I haven't tested any of the

Re: Which stable GHC release is expected to have support for linear types?

On 2017-07-14 21:59, Wolfgang Jeltsch wrote: > Am Freitag, den 14.07.2017, 06:42 +0200 schrieb Bardur Arantsson: >> On 2017-07-14 01:26, Mike Ledger wrote: >>> How about: -+ >>> >>> It almost looks arrow like if you squint, and have a font that lines >>

Re: RTS changes affect runtime when they shouldn’t

On 2017-09-23 20:45, Sven Panne wrote: > 2017-09-21 0:34 GMT+02:00 Sebastian Graf >: > > [...] The only real drawback I see is that instruction count might > skew results, because AFAIK it doesn't properly take the > architecture

Re: Proposal: Don't read environment files by default

On 28/03/2019 14.58, Oleg Grenrus wrote: > There is. Add > >     write-ghc-environment-files: never > > to your ~/.cabal/config assuming you have cabal-insall-2.4.1.0 or later. > That doesn't really work if you actually want to be able to use both ways of working, does it? That same thing

Re: Gitlab workflow

On 11/07/2019 17.47, Ben Gamari wrote: [--snip--] I'm just going to snip all of that because that was an almost perfect summary of why rebase-always is best. I'm *not* talking about rebasing willy-nilly, but I agree that rebasing private branches and rebasing-with-agreement is superior in every

Re: GHC Logo

On 02/09/2020 00.36, Richard Eisenberg wrote: > Late to the party here, but I'm wondering whether we can enlist someone with > graphic design experience to create a more iconic logo for the compiler. I > use the word "iconic" deliberately: it should both be recognizable, and in > the shape of