binding, IO is not run; it is just a way of composing values, like you'd do using flatMap. IO will be run when you invoke any of the unsafeRun methods, so depending on what you choose, that operation will be synchronous or asynchronous. That is, if you invoke myProgram().unsafeRunAsync(on: queue) { ... } and pass the appropriate queue, it will return immediately while doing the operation on the queue that you passed. Be aware that, if you don't send a queue, the main one will be used, and it could lead to a deadlock.
I understand that
binding() is syntactic sugar for a bunch of flatMap()s and the resulting IO needs to be executed using one of the unsafeRun functions.So I guess, if I want to 'fire and forget' some side effect I just need to call
unsafeRunAsync() on it. And if I want to do it within a binding I need to wrap it in an IO. E.g. UIO.invoke { loadData.unsafeRunAsync() }.In Arrow there is syntactic sugar for this:
!effect { }. That's why I was under the impression the same thing could be achieved in Bow using less code.
handle: (Input) -> Void function to notify actions to Bow Arch whenever an event is triggered in the observer. If you have some sample code we can discuss around a concrete example.
hey channel,
I recently started looking at Bow and it looks absolutely awesome. Kudos to the maintainers for putting it together. I have a question about pattern matching data types in Bow. I'd like to apologize in advance for it, as the question is very basic.
let's say I have a simple Option<String>. How do I pattern match it? The following code:
let myObject: Option<String> = .some("42")
switch myObject {
case let .some(c):
// ...
}produces the following compilation error Pattern variable binding cannot appear in an expression
Is there a way to use pattern matching with Options and other data types in Bow?
Hi Kyrill! Thanks for your nice words, it helps us be motivated to continue moving this project forward!
Regarding your question, it is not possible to use pattern matching on the types provided in Bow. The reason is the emulation of Higher Kinded Types we do; we need our types to be classes in order to be able to use them as HKTs. Only enums can be used in pattern matching. Nevertheless, all types provide a method fold, where you can pass closures to handle each of the cases:
let myObject: Option<String> = .some("42")
myObject.fold(
{ /* Handle none case */ },
{ c in /* Handle some case */ }
)This is possible with any other data type in Bow, like Either:
let myObject: Either<Int, String> = .right("42")
myObject.fold(
{ left in /* Handle left case */ },
{ right in /* Handle right case */ }
)You can read more about HKTs and how they are emulated in Bow here, and feel free to ask any questions you may have!
If you decide to use our recently released library Bow Lite, we got rid of the emulation of HKTs. With this, we lost a lot of abstraction power, but one of the things we got back is pattern matching. Therefore, if you use Bow Lite, you can still use fold on all types, but you can also pattern match:
import BowLite
let myObject: Either<Int, String> = .right("42")
switch myObject {
case let .left(l): /* Handle left case */
case let .right(r): /* Handle right case */
}I hope this clarifies your question!
Hi @dsabanin! Thanks for your kind words! We made Bow Lite in order to ease the learning process for newcomers to FP. It takes a while until you fully grasp HKTs, and since they are not native to the language (yet), we have observed many people have issues understanding and using the library. It is also a big commitment to add HKT emulation into your project, especially if you are working with others and they are not very familiar with FP.
Having said that, of course, Bow is much more versatile thanks to HKTs. You can see how much we could save being able to use more powerful abstractions by checking the implementations we had to make in Bow Lite, where there is plenty of duplication that cannot be abstracted out. We were even able to implement Bow Arch on top of the HKT emulation, which lets us replace a few types and get a whole new architecture with different properties. My recommendation is that, if you and your team are familiar with FP and HKTs, go ahead with Bow, and only choose Bow Lite if you want a lightweight library to practice FP without the heavy features.
Regarding benchmarking, I unfortunately haven't been able to do anything about it, but it is definitely something interesting to measure. I'd be interested in measuring which parts of the library are less performant and improving them. Hacktoberfest is coming, so if you are interested in doing this type of project, you are really welcome!
