On Fri, Feb 24, 2012 at 11:40 PM, Johan Tibell wrote:
> Hi Barney,
>
> On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken wrote:
>> Every one of your messages about records stresses your dislike for
>> polymorphic projections, and your insistence that the Has class should be
>> hidden from the user
On Fri, Feb 24, 2012 at 4:15 PM, Johan Tibell wrote:
> Aside: It is possible to have no scalar fields in records of course.
> data R = C { compare :: (a -> a -> Ordering) }
Has x f has no semantic content besides type x having an f field; Ord
has (at least in the programmer's mind, even if the la
On Fri, Feb 24, 2012 at 3:07 PM, Barney Hilken wrote:
> But the difference is that <= is (potentially) an arbitrary function, so we
> need to be careful that the instances make sense. A formally correct system
> would insist that all instances are (at least) reflexive and transitive. But
> in t
Sorry for getting offended!
I agree with your sentiment, which is why I thought having to write an
extra word in a Record declaration to get automatic abstraction over
fields was a good solution to the problem.
But now I am in the position of being the lone dissenter on automatic
abstraction over
> I share Greg's concerns about polymorphic projections. For example,
> given a function
>
>sort :: Ord a => ...
>
> we don't allow any 'a' that happens to export a operator that's
> spelled <= to be passed to 'sort'. We have the user explicitly create
> an instance and thereby defining that
Hi Barney,
On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken wrote:
> Every one of your messages about records stresses your dislike for
> polymorphic projections, and your insistence that the Has class should be
> hidden from the user. I've read all of your explanations, but I'm still
> totally
I'm sorry Greg, I didn't mean to be offensive. I just feel that all your
arguments in favour of this restriction are based on one particular application
of records, rather than a general notion of what records are. Obviously this
application is what motivates you to do all the valuable work you
>
> No, I don't think anybody has a satisfactory approach to
> updating polymorphic/higher-ranked fields. (DORF mentions
> one, but it's a ghastly hack.
So are the proposals dead until this is tackled, or should SORF/DORF
propose not to allow that?
>
> What on earth do you mean by "not automatica
On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken wrote:
>
>
>> This should be used to generate
>> internal constraints and not be exposed to the end user and not
>> automatically abstract over fields.
>
> Every one of your messages about records stresses your dislike for
> polymorphic projections,
> This should be used to generate
> internal constraints and not be exposed to the end user and not
> automatically abstract over fields.
Every one of your messages about records stresses your dislike for polymorphic
projections, and your insistence that the Has class should be hidden from the
> Actually, I looked at the SORF page again:
>
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
> There is now an 'Alternative Proposal' section that claims
> to solve polymorphic update.
> If anyone has comments on this please let us know!
Yes, Greg the quasifunctor stuff h
Actually, I looked at the SORF page again:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
There is now an 'Alternative Proposal' section that claims to solve
polymorphic update.
If anyone has comments on this please let us know!
So my proposal would be to somehow use the S
I looked at the DORF implementers view
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/ImplementorsView
It appears that we still have no solution for record updates that
change the type of a polymorphic field.
I think this means we need to look to ways to solve this
By the way, it looks like the documentation for createDirectoryIfMissing
doesn't mention anything about its safety under concurrent invocation.
Looking at the code, it looks like it is safe (it handles the already exist
exception):
http://www.haskell.org/ghc/docs/latest/html/libraries/directory/
Hi,
recently we've been tweaking our internal build system at Tsuru to
handle parallel builds of both cabal packages via 'cabal-sort
--makefile' and our local code tree via 'ghc -M'. In addition to the
recompilation checker fixes of #5878, the following would be great to
have in 7.4.2:
1) http://
15 matches
Mail list logo
