ould be based on
> >> > > everything but the NameU int, but 'Eq' would still follow it
> >> > >
> >> > > A few ideas for different approaches to resolving this:
> >> > >
> >> > > 1) Document it. Less appealing than
> > really handle these well. In that case, the ordering would be based on
>>> > > everything but the NameU int, but 'Eq' would still follow it
>>> > >
>>> > > A few ideas for different approaches to resolving this:
>>> > >
>>>
gt; > >
>> > > 1) Document it. Less appealing than fixing it in the API, but still
>> > would
>> > > be good.
>> > >
>> > > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
>> > &g
Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
> > > newtype (partial ord on the non-unique info), or 'UnstableNameOrd'
> > newtype
> > > (current behavior). A trickyness of this approach is that you&#x
vior). A trickyness of this approach is that you'd need
> > containers that can handle (PartialOrd k, Eq k) keys. In lots of cases
> > people are using the 'Ord' instance with 'Name's that are not 'NameU', so
> > this would break a lot of c
containers that can handle (PartialOrd k, Eq k) keys. In lots of cases
> people are using the 'Ord' instance with 'Name's that are not 'NameU', so
> this would break a lot of code that was already deterministic.
>
> 3) Some approaches like this ordering key, but I'm
re using the 'Ord' instance with 'Name's that are not 'NameU', so
this would break a lot of code that was already deterministic.
3) Some approaches like this ordering key, but I'm not sure how it will
help when comparing NameUs from different modules?
> S
On Jun 2, 2016, at 7:12 AM, Simon Peyton Jones wrote:
>
> But why is NameU exposed to clients? GHC needs to know, but clients don’t.
> What use are these packages making of it?
>
singletons uses NameU in two places:
1. To generate unique numbers. It would be easy enough for me to put this
at use are these packages making of it?
S
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michael Sloan
Sent: 02 June 2016 02:07
To: Bartosz Nitka
Cc: ghc-devs Devs
Subject: Re: Template Haskell determinism
+1 to solving this. Not sure about the approach, but assuming th
+1 to solving this. Not sure about the approach, but assuming the
following concerns are addressed, I'm (+1) on it too:
This solution is clever! However, I think there is some difficulty to
determining this ordering key. Namely, what happens when I construct the
(Set Name) using results from mu
On May 31, 2016, at 9:54 AM, Bartosz Nitka wrote:
> I'd like to get feedback if this is an acceptable solution and if the problem
> is worth solving.
I don't have an opinion about "worth solving". While I understand your
description of the problem and believe you that it crops up in practice,
Template Haskell with its ability to do arbitrary IO is non-deterministic by
design. You could for example embed the current date in a file. There is
however one kind of non-deterministic behavior that you can trigger
accidentally. It has to do with how Names are reified. If you take a look
at
the
12 matches
Mail list logo
