There is another options: names from local modules (same package) shadow
names from external packages. But it is not obvious to me that this is
a good idea.
Edward
Excerpts from Herbert Valerio Riedel's message of 2016-10-04 13:50:58 +0200:
> Hi,
>
> On 2016-10-04 at 13:12:54 +0200, Yuras Shumo
On Tue, Oct 4, 2016 at 7:12 AM, Yuras Shumovich wrote:
> On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:
>
>> It makes additions of names to libraries far less brittle. You can
>> add a
>> new export with a mere minor version bump, and many of the situations
>> where
>> that causes breakage
I second Herbert's concern. Giving semantics to import order is one of the
greatest plagues of C, C++, Python, etc. It is worth avoiding at all costs.
Herbert's suggestion re: explicitly enumerated names seems to hold promise,
however.
On Tue, Oct 4, 2016 at 7:50 AM, Herbert Valerio Riedel
wrote:
Erik de Castro Lopo writes:
> Ben Gamari wrote:
>
>> It's a bit unclear how far we should extend test coverage. In the future
>> I think I will at very least add an i386 Ubuntu environment, but we
>> could go farther still. For instance these platforms immediately come to
>> mind,
>>
>> * x86_6
Hi Erik,
You're right that Template Haskell violates Safe Haskell guarantees, but that
should be independent of the Language.Haskell.TH.Syntax module. The problem is
the -XTemplateHaskell extension, not the module. So I think labeling the module
Trustworthy is OK.
Richard
> On Oct 4, 2016, at
Hi,
On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote:
> On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:
>
>> It makes additions of names to libraries far less brittle. You can
>> add a
>> new export with a mere minor version bump, and many of the situations
>> where
>> that causes bre
The easiest way I found to build stackage recently was to take the
cabal.config file [1] and then manipulate it to just install each
package in turn.
cabal install package-1
cabal install package-2
This was quite a bit easier than using stackage-curator if you just
want to build packages to check
On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:
> It makes additions of names to libraries far less brittle. You can
> add a
> new export with a mere minor version bump, and many of the situations
> where
> that causes breakage can be fixed by this simple rule change.
It would be true only
I for one would really like to see this go in. (I've commiserated with
Lennart in the past about the fact that the previous proposal just sort of
died.)
It makes additions of names to libraries far less brittle. You can add a
new export with a mere minor version bump, and many of the situations wh
Smoke-testing with Stackage would be a great idea. In the past Michael Snoyman
has kindly done that for us, but ultimately some automation would be good.
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Boespflug,
Mathieu
Sent: 04 October 2016 07:59
To: Ben Gamari
Cc: g
Hi all,
I tried to fix trac ticket #12511 (template-haskell's Language.Haskell.Syntax
module should be Trustworthy) but in doing so I began to think this is actually
a bad idea. Specifically, I suspect its actually possible to craft something
using TH that bypasses the guarantees that Safe is supp
On 10/ 4/16 09:18 AM, Erik de Castro Lopo wrote:
* AArch64 Linux
That would be awesome if we could get access to a decent (by which I mean
server grade, with at least 4 cores and 8 Gig of RAM).
Just ask for account on GNU GCC Compile Farm. They do have X-gene V1
machine in the farm, pretty
Ben Gamari wrote:
> It's a bit unclear how far we should extend test coverage. In the future
> I think I will at very least add an i386 Ubuntu environment, but we
> could go farther still. For instance these platforms immediately come to
> mind,
>
> * x86_64 FreeBSD
> * x86_64 Solaris
> * ARM
13 matches
Mail list logo
