Kosyrev Serge <_deepf...@feelingofgreen.ru> writes:
> How much of this derivation machinery could NOT be implemented by means of
> some kind of a (hypothetical) type-backed metaprogramming facility?
>
> The beauty of an open implementation[1] allowed by such a thing is that:
I
Ryan Scott writes:
> That is a good question. Weirdly enough, the current behavior for how
> a deriving strategy is resolved (without explicit keywords) isn't
> really documented anywhere, so I attempted to figure out what GHC
> currently does and documented it here [1]. I'll reproduce the
> algor
Joachim Breitner writes:
>> FWIW, I think adding a few simple table headings might help
>> enormously.
>>
>> "Last commit", "?", "Branch", "Last commit message", "Diffstat".
>>
>> (or something like that.)
>
> good idea; although often with tables space is thight, and narrow
> columns don’t allo
Good day folks,
Here is a test case that exposes a certain weakness in PolyKinds
error messaging. In the following snippet (T W) :: * is malkinded:
> {-# LANGUAGE PolyKinds #-}
> {-# LANGUAGE UnicodeSyntax #-}
>
> class Eq a ⇒ EqSyn a where
> data T w
> data W f
>
> x = (undefined ∷ EqSyn w ⇒
Ben Gamari writes:
> Kosyrev Serge <_deepf...@feelingofgreen.ru> writes:
>
> Thanks for reporting this. Have you opened a Trac ticket for this issue?
> If not could you do so?
Just done so:
https://ghc.haskell.org/trac/ghc/ticket/11762#ticket
--
с уважени
Good day!
It seems that GHC 8 regresses with regard to GHC 7.10, when it tries to
satisfy the constraints, implied by instance context.
The following does not build on GHC 8.0.1 RC2, but does on 7.10.3:
> {-# LANGUAGE FlexibleInstances #-}
> {-# LANGUAGE UndecidableInstances #-}
> --{-# LANGUAGE
Good day!
I realise that ImpredicativeTypes is a problematic extension, but I have
found something that looks like an outright bug -- no polymorphism involved:
,
| {-# LANGUAGE ImpredicativeTypes #-}
|
| module Foo where
|
| foo :: IO (Maybe Int)
| foo = do
| pure $ case undefined :: Maybe
Ben Gamari writes:
> It would be great if we could get users to submit their
> computationally-heavy, toy projects. Unfortunately, the best testcases
> for us are those with no dependencies outside of the core libraries and
> these projects aren't terribly common.
This appears extremely unfortun
Joe Hillenbrand writes:
>> 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 files.
Curiously, for t
Simon Marlow writes:
> On 01/09/2015 11:34, Thomas Miedema wrote:
>> Hello all,
>>
>> my arguments against Phabricator are here:
>> https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator.
>
> Thanks for taking the time to summarize all the issues.
>
> Personally, I think github's support for code
Levent Erkok writes:
> Hello all,
>
> I've been having a lot of trouble installing the binary-distro's on a
> SuSE machine. Unfortunately, I don't have root privileges and thus my
> options are rather limited.
>
> The problem seem to boil down to the use of the function
> pthread_setname_np. It ap
Ben Gamari writes:
> These items are a bit less certain but may make it in if the authors
> push forward quickly enough,
[..]
> * A (possible) overhaul of GHC's build system to use Shake instead
> of Make.
Is there a breakdown of what remains to be done on this front?
--
с уважениeм
Greg Weber writes:
> The main reason I am using stack is for its support for building a project
> containing multiple packages. There aren't any other tools that make this a
> first-class concept that is easy to use and not buggy.
> In addition, stack has a first-class concept of curated package s
Stephen Paul Weber writes:
>>As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
>>currently relies on the system's C-compiler bundled `cpp` program to
>>provide a "traditional mode" c-preprocessor.
>
> Yes. This is one of my favourite things in GHC-land -- that an existing,
> go
Sven Panne writes:
> 2015-05-06 16:21 GMT+02:00 Bardur Arantsson :
>> +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 helper functions for each API entry
15 matches
Mail list logo
