-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generalize fan following DMap #318
Conversation
Awesome! This all looks great; maybe we could rename it to |
That's fine by me. I don't really like that name either, but ... whatever.
Do you have any suggestions for tackling that for merge? It looks a lot
hairier, and I don't even know where to start.
…On Thu, Jul 4, 2019, 12:57 PM Ryan Trinkle ***@***.***> wrote:
Awesome! This all looks great; maybe we could rename it to fanG and merge?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#318?email_source=notifications&email_token=AAOOF7LZ5HUAEXH3CI6SINTP5YTWJA5CNFSM4H55EP7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZH3DFQ#issuecomment-508539286>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOOF7MKKL7NGAQYQAZ6CO3P5YTWJANCNFSM4H55EP7A>
.
|
Renamed. Should be ready to merge. |
src/Reflex/Class.hs
Outdated
fan :: forall t k. (Reflex t, GCompare k) | ||
=> Event t (DMap k Identity) -> EventSelector t k | ||
--TODO: Can we help enforce the partial application discipline here? The combinator is worthless without it | ||
fan e = EventSelector (fixup (selectg (fanG e) :: k a -> Event t (Identity a)) :: forall a. k a -> Event t a) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we match on the Coercion
and then produce a lambda, or something like that, to make sure there's only one eventCoercion
call per Reflex
instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It probably doesn't actually matter...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about such things and opened #319
If we're going with fanG, probably best to have it be selectG for
consistency.
Also, it's worth thinking about whether it wouldn't be a more reasonable
option to just make this generalisation just be fan itself -- the number of
occurrences of the fully general 'fan' in the wild is pretty small, and
this is a straightforward generalisation.
…On Thu, 4 Jul 2019 at 16:34, John Ericson ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/Reflex/Class.hs
<#318 (comment)>:
> @@ -298,6 +302,18 @@ class ( MonadHold t (PushM t)
mergeIntIncremental :: Incremental t (PatchIntMap (Event t a)) -> Event t (IntMap a)
fanInt :: Event t (IntMap a) -> EventSelectorInt t a
+-- | Efficiently fan-out an event to many destinations. You should save the
+-- result in a @***@***.***, and then repeatedly 'select' on the result to
+-- create child events
+fan :: forall t k. (Reflex t, GCompare k)
+ => Event t (DMap k Identity) -> EventSelector t k
+ --TODO: Can we help enforce the partial application discipline here? The combinator is worthless without it
+fan e = EventSelector (fixup (selectg (fanG e) :: k a -> Event t (Identity a)) :: forall a. k a -> Event t a)
I was thinking about such things and opened #319
<#319>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#318?email_source=notifications&email_token=ABVVE3G2ANDEIDFNLJA3IPTP5ZNE7A5CNFSM4H55EP7KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB5RUXLA#discussion_r300495623>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABVVE3HXBHVVF23XLC4QAQ3P5ZNE7ANCNFSM4H55EP7A>
.
|
The deprecation plan shouldn't burn our more hardcore users, but it might
make sense to eventually come around to fan=fanG
…On Thu, Jul 4, 2019, 16:38 cgibbard ***@***.***> wrote:
If we're going with fanG, probably best to have it be selectG for
consistency.
Also, it's worth thinking about whether it wouldn't be a more reasonable
option to just make this generalisation just be fan itself -- the number of
occurrences of the fully general 'fan' in the wild is pretty small, and
this is a straightforward generalisation.
On Thu, 4 Jul 2019 at 16:34, John Ericson ***@***.***>
wrote:
> ***@***.**** commented on this pull request.
> ------------------------------
>
> In src/Reflex/Class.hs
> <#318 (comment)>:
>
> > @@ -298,6 +302,18 @@ class ( MonadHold t (PushM t)
> mergeIntIncremental :: Incremental t (PatchIntMap (Event t a)) -> Event
t (IntMap a)
> fanInt :: Event t (IntMap a) -> EventSelectorInt t a
>
> +-- | Efficiently fan-out an event to many destinations. You should save
the
> +-- result in a @***@***.***, and then repeatedly 'select' on the
result to
> +-- create child events
> +fan :: forall t k. (Reflex t, GCompare k)
> + => Event t (DMap k Identity) -> EventSelector t k
> + --TODO: Can we help enforce the partial application discipline here?
The combinator is worthless without it
> +fan e = EventSelector (fixup (selectg (fanG e) :: k a -> Event t
(Identity a)) :: forall a. k a -> Event t a)
>
> I was thinking about such things and opened #319
> <#319>
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <
#318?email_source=notifications&email_token=ABVVE3G2ANDEIDFNLJA3IPTP5ZNE7A5CNFSM4H55EP7KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB5RUXLA#discussion_r300495623
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ABVVE3HXBHVVF23XLC4QAQ3P5ZNE7ANCNFSM4H55EP7A
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#318?email_source=notifications&email_token=AAI2KYHEHYUUVP3VSYBMUJ3P5ZNUJA5CNFSM4H55EP7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZIDHIY#issuecomment-508572579>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAI2KYHPPSHQ2KMEV5SUZNLP5ZNUJANCNFSM4H55EP7A>
.
|
We'll have the same thing again with NonEmptyDMap for fan and merge, so I'd say new name for now, and replace |
Could you please update the changelog? |
@ali-abrar, updated. |
Fix merge
Remove duplicate
* 'release/0.6.2.1' of github.com:ryantrinkle/reflex: (30 commits) Loosen monoidal-containers version bounds Update CONTRIBUTING.md Update CONTRIBUTING.md Use unsafePerformIO better (#325) Generalize fan following DMap (#318) Distribute more generally Generalize merge Drop *Tag classes Fix deprecation warnings related to updated Data.Some Bump dependent-sum to latest version fan: Rewrite haddock Replace hackage link with badge Use Some for more existential types (which should be efficient now that it is a newtype) Bump upper bounds Typo DRY conditional compilation Bump 'these' upper bound Typo Update changelog for holdDyn fix Make holdDyn lazy in its Event again ...
This reverts commit 13e76bb.
Generalize
fan
tofang
(yeah, that's a horrible name) allowing fanningDMap
s with arbitrary targets (not justIdentity
). I haven't yet dug down enough to work out how to do the same formerge
, but it would be useful.