On Wed, Jan 21, 2015 at 1:06 PM, Adam Gundry a...@well-typed.com wrote:
Also, I'd add fields with higher-rank types to the list of missing
features. From a user's perspective, it might seem a bit odd if
data T = MkT { foo :: forall a . a }
was fine but
data T = MkT {| foo ::
[I should say, in case it wasn't clear from my previous email, that I'm
impressed by Nikita's work, excited to see this discussion revived, and
very keen to find the best solution, whether that builds on ORF or not.
Anyway, back down the rabbit hole...]
On 21/01/15 16:48, Simon Marlow wrote:
On
On 2015-01-21 at 16:51:55 +0100, Alexander V Vershilov wrote:
[...]
As transformers usage are quite limited in ghc, and it's really relevant
in ghc-bin, it's possible to duplicate the code, and provide required
fixes in ghc-bin.cabal. As a result ghc uses it's own MonadIO, MonadControl
and
On 21/01/2015 16:01, Johan Tibell wrote:
My thoughts mostly mirror those of Adam and Edward.
1) I want something that is backwards compatible.
Backwards compatible in what sense? Extension flags provide backwards
compatibility, because you just don't turn on the extension until you
want to
On Wed, Jan 21, 2015 at 11:48 AM, Simon Marlow marlo...@gmail.com wrote:
2) Anonymous records are nice to have, but I don't want to have all
records be anonymous (and have to jump through newtype hoops to get back
non-anonymous records.)
So right now you have to say
data T = R { a :: Int
Hi,
Am Mittwoch, den 21.01.2015, 19:51 +0400 schrieb Alexander V Vershilov:
Should I continue doing this?
with my Debian packaging maintainer hat on: Yes, please do!
Greetings,
Joachim
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de • http://www.joachim-breitner.de/
Jabber:
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
Hello.
I'm coming with a proposal for removing transformers dependency
from ghc library. The reason for this proposal that it's not possible
to build consistent environment where a modern libraries (that depend
on a newer transformers or mtl-2.2) and libraries that use ghc API
are used together.
My thoughts mostly mirror those of Adam and Edward.
1) I want something that is backwards compatible.
2) Anonymous records are nice to have, but I don't want to have all records
be anonymous (and have to jump through newtype hoops to get back
non-anonymous records.)
3) I don't think it's a good
I thought about providing package ghc-transformers-instances, that will
provide instances for transformers's type classes for user. So
ghc-tf-instances will depend on current ghc, and current transformers that
could be provided by user environment.
On Jan 21, 2015 7:15 PM, Herbert Valerio Riedel
Huge +1 from a Stackage standpoint. The transformers dependency (and other
such dependencies) causes me a huge amount of pain.
On Wed Jan 21 2015 at 8:52:57 AM Joachim Breitner m...@joachim-breitner.de
wrote:
Hi,
Am Mittwoch, den 21.01.2015, 19:51 +0400 schrieb Alexander V Vershilov:
Should
I’ve had a chat to Manuel. He is content for us to remove DPH code altogether
(not just CPP/comment it out), provided we are careful to signpost what has
gone and how to get it back.
I am no Git expert, so can I leave it to you guys to work out what to do? The
specification is:
·It
On 21/01/15 18:14, Edward Kmett wrote:
5) I don't know if I want to commit the *language* to a particular lens
type.
Agreed, but I don't think this need be an issue for either proposal. We
know from ORF that we can make fields sufficiently polymorphic to be
treated as
Adam, do you have any measurements for how much code gets generated for
a record declaration with ORF, compared with a record declaration in GHC
right now? That's one thing that has been a nagging worry for me with
ORF, but I just don't have any idea if it's a real problem or not.
Under
I'm sorry I'm a bit late to the game here, but there is also the option
of reconnecting DPH to the build.
When I patched DPH for the new version of the vector library, I did not
perform this step---now I'm sorry I didn't.
I am willing to get DPH in working order again---I believe the required
Hi,
I also hope that this is integrated into GHC 7.10.
--Kazu
Hello.
I'm coming with a proposal for removing transformers dependency
from ghc library. The reason for this proposal that it's not possible
to build consistent environment where a modern libraries (that depend
on a newer
Alexander,
I'm coming with a proposal for removing transformers dependency
from ghc library.
Big +1 from me.
doctest is suffering from dependency hell because ghc lib depends on
transformers.
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
On Wed, Jan 21, 2015 at 4:34 PM, Adam Gundry a...@well-typed.com wrote:
I'm surprised and interested that you view this as a major source of
complexity. From my point of view, I quite liked how the ability to
overload fields as both selector functions and arbitrary lenses turned
out. Compared
Thanks for the offer, Geoff.
Under these circumstances, I would also very much prefer for Geoff getting the
code in order and leaving it in GHC.
Manuel
Geoffrey Mainland mainl...@apeiron.net:
I'm sorry I'm a bit late to the game here, but there is also the option
of reconnecting DPH to
Ok. In this case, I'm interested in main users of ghc library,
as I have to make sure that they will not be broken by
any changes that I'm introduce? I can take few from hackage
but maybe there are ones that users care about. So I can
validate my solution.
--
Alexander
On 22 January 2015 at
Don't worry, we've never given any promise about GHC API
stability across major versions (or minor versions, for that
matter.)
Edward
Excerpts from Alexander V Vershilov's message of 2015-01-21 22:16:11 -0800:
Ok. In this case, I'm interested in main users of ghc library,
as I have to make
On 2015-01-21 at 17:19:42 +0100, Alexander V Vershilov wrote:
I thought about providing package ghc-transformers-instances, that will
provide instances for transformers's type classes for user. So
ghc-tf-instances will depend on current ghc, and current transformers that
could be provided by
As someone with quite a lot of skin in this game, I thought it might be
useful to give my perspective on how this relates to ORF. Apologies that
this drags on a bit...
Both approaches use essentially the same mechanism for resolving
overloaded field names (typeclasses indexed by type-level
On 20/01/2015 23:07, Edward Kmett wrote:
It is a long trek from this is plausible to hey, let's bet the
future of records and bunch of syntax in the language on this.
Absolutely. On the other hand, this is the first proposal I've seen
that really hits (for me) a point in the design space
Personally, I think the two proposals, ORF and Nikita's record approach
address largely differing needs.
The ORF proposal has the benefit that it doesn't require GHC itself to know
anything about lenses in order to work and is mostly compatible with the
existing field accessor combinators.
On Wed, Jan 21, 2015 at 4:36 AM, Simon Marlow marlo...@gmail.com wrote:
On 20/01/2015 23:07, Edward Kmett wrote:
It is a long trek from this is plausible to hey, let's bet the
future of records and bunch of syntax in the language on this.
Absolutely. On the other hand, this is the first
26 matches
Mail list logo
