Here's an interesting (counter)example. The following (get, set) pair satisfies laws #1 and #2 of Data.Lens.Lens, and the WEAKENED form of #3, but not the strongest form.
As such, it provides an example of why the stronger form of law #3 is necessary
As such, it provides an example of why the stronger form of law #3 is necessary
February 25, 2025 at 3:13 AM
Here's an interesting (counter)example. The following (get, set) pair satisfies laws #1 and #2 of Data.Lens.Lens, and the WEAKENED form of #3, but not the strongest form.
As such, it provides an example of why the stronger form of law #3 is necessary
As such, it provides an example of why the stronger form of law #3 is necessary
gotta make sure it's beginner-friendly
February 25, 2025 at 2:34 AM
gotta make sure it's beginner-friendly
this single 6-line comment is one of the pieces of code i am most proud of
took quite a time to get to that type signature, and it's so simple, and it just works.
took quite a time to get to that type signature, and it's so simple, and it just works.
February 13, 2025 at 4:22 AM
this single 6-line comment is one of the pieces of code i am most proud of
took quite a time to get to that type signature, and it's so simple, and it just works.
took quite a time to get to that type signature, and it's so simple, and it just works.
Actually 🤔 I suppose we can identify emitter-combinators with emitters via `const`
this is kind of horrible but it works
this is kind of horrible but it works
February 9, 2025 at 2:45 AM
Actually 🤔 I suppose we can identify emitter-combinators with emitters via `const`
this is kind of horrible but it works
this is kind of horrible but it works
also really enjoying using "wiring diagrams" to explain event-based code
altho tbh I feel like i should learn the actual semantics of wiring diagrams. last i recall a diag like pic below just indicates that a ⊗ b ≤ F(a, b) in some monoidal category (which I am assuming we can relax to "monoid")
altho tbh I feel like i should learn the actual semantics of wiring diagrams. last i recall a diag like pic below just indicates that a ⊗ b ≤ F(a, b) in some monoidal category (which I am assuming we can relax to "monoid")
February 9, 2025 at 1:27 AM
also really enjoying using "wiring diagrams" to explain event-based code
altho tbh I feel like i should learn the actual semantics of wiring diagrams. last i recall a diag like pic below just indicates that a ⊗ b ≤ F(a, b) in some monoidal category (which I am assuming we can relax to "monoid")
altho tbh I feel like i should learn the actual semantics of wiring diagrams. last i recall a diag like pic below just indicates that a ⊗ b ≤ F(a, b) in some monoidal category (which I am assuming we can relax to "monoid")
really enjoying sticking diagrams in my code
February 9, 2025 at 1:27 AM
really enjoying sticking diagrams in my code
here is an operation I needed which, to my surprise, I could not find in the FRP libraries I looked at
(though I didn't look super duper hard)
(though I didn't look super duper hard)
February 2, 2025 at 3:37 AM
here is an operation I needed which, to my surprise, I could not find in the FRP libraries I looked at
(though I didn't look super duper hard)
(though I didn't look super duper hard)
i have unexpectedly entered the land of FRP
February 2, 2025 at 1:43 AM
i have unexpectedly entered the land of FRP
you could add a new agent—here I call it PaymentMaker—whose role is to encapsulate this action-at-a-distance, and maybe that would be okay
January 30, 2025 at 8:48 AM
you could add a new agent—here I call it PaymentMaker—whose role is to encapsulate this action-at-a-distance, and maybe that would be okay
what comes to mind to me is to have the button callback register a listener with the webhook, and await the incoming confirmation
January 30, 2025 at 8:37 AM
what comes to mind to me is to have the button callback register a listener with the webhook, and await the incoming confirmation
for a specific instance, consider a straightforward event-based implementation for a "buy credit" button
the button callback handles initiating the purchase, but a *completely separate* piece of code handles finishing it (updating the UI). this is terrible code locality
the button callback handles initiating the purchase, but a *completely separate* piece of code handles finishing it (updating the UI). this is terrible code locality
January 30, 2025 at 8:37 AM
for a specific instance, consider a straightforward event-based implementation for a "buy credit" button
the button callback handles initiating the purchase, but a *completely separate* piece of code handles finishing it (updating the UI). this is terrible code locality
the button callback handles initiating the purchase, but a *completely separate* piece of code handles finishing it (updating the UI). this is terrible code locality
this is why you should hire me
January 30, 2025 at 5:18 AM
this is why you should hire me
this feels like what the rest of the world think californians are all like
January 24, 2025 at 7:03 PM
this feels like what the rest of the world think californians are all like
![Two consoles.
On the left console, code reading as follows.
main :: IO ()
main = run do
withReturn \return ->
void $ withFork \fork -> do
word <- withTell \tell -> do
tell "under"
suffix <- fork ["stand", "state", "estimate"]
tell suffix
lift $ print word
when ("e" `isSuffixOf` word) do
void $ return ()
pure ()
On the right, output reading as follows.
"understand"
"understate"](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:wekqhxrlbt6yhzihf23bmxmy/bafkreihuudqhvy2mg4hemfwtwt3tofp5i5wajcgnssza5gcgwkhcnnqlv4@jpeg)
![Two terminals
The right terminal reads as follows.
[1,1]
[1,2]
[1,3]
[1,4]
[1,5]
The left terminal reads as follows.
main :: Effect Unit
main = do
_ <- withFork \fork -> do
told <- withTell \tell -> do
tell [1]
n <- lift $ fork [1, 2, 3, 4, 5]
tell [n]
lift $ Console.log (show told)
pure unit
pure unit
where
run :: forall m a. Monad m => ContT a m a -> m a
run c = runContT c pure
withTell :: forall m w. Monad m => Monoid w => ((w -> ContT w m Unit) -> ContT w m Unit) -> m w
withTell block =
run do mempty <$ block \w -> ContT \k -> append w <$> k unit
withFork :: forall m a b. Monad m => ((Array a -> ContT (Array b) m a) -> ContT (Array b) m b) -> m (Array b)
withFork block =
run do singleton <$> block \choices -> ContT \k -> choices # traverse k # map join
singleton :: forall a. a -> Array a
singleton x = [x]](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:wekqhxrlbt6yhzihf23bmxmy/bafkreifsmwxk4no4a3jz24td5vznarvqcsujjwviqg2vzserbr4dugppsa@jpeg)
so satisfying to watch code that i forgot i made robust
January 7, 2025 at 7:25 AM
so satisfying to watch code that i forgot i made robust
I think this is how I've been doing it ^^
January 6, 2025 at 8:16 PM
I think this is how I've been doing it ^^
here's what I believe to be the desugared form of the above
in order for the inner 'fork' to capture up to 'useFork', we need that 'k2' include the 'print'
but getting to the 'print' requires finishing the computation of 'told', which requires running the 'fork'!
in order for the inner 'fork' to capture up to 'useFork', we need that 'k2' include the 'print'
but getting to the 'print' requires finishing the computation of 'told', which requires running the 'fork'!
![A screenshot of the following code:
useFork \p1 k1 ->
(useTell \p2 k2 ->
tell p2 [1] \() ->
fork p1 [1 .. 5] \n ->
tell p2 [n] \() ->
k2 ()
) \told ->
print told \() ->
k1 ()](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:wekqhxrlbt6yhzihf23bmxmy/bafkreibfzqgtr7fxqw7zed4no6alze6n5fqdf76ao5vq6dxwwr6743ctre@jpeg)
January 6, 2025 at 10:48 AM
here's what I believe to be the desugared form of the above
in order for the inner 'fork' to capture up to 'useFork', we need that 'k2' include the 'print'
but getting to the 'print' requires finishing the computation of 'told', which requires running the 'fork'!
in order for the inner 'fork' to capture up to 'useFork', we need that 'k2' include the 'print'
but getting to the 'print' requires finishing the computation of 'told', which requires running the 'fork'!