Logs: liberachat/#haskell
| 2021-08-19 02:53:55 | <dzdcnfzd> | No, you're correct now that I think. To be honest with you, I'm actually thinking about a Java-library, not haskell |
| 2021-08-19 02:54:13 | → | keutoi joins (~keutoi@157.48.212.99) |
| 2021-08-19 02:54:52 | × | alx741 quits (~alx741@181.196.69.234) (Quit: alx741) |
| 2021-08-19 02:55:20 | <dzdcnfzd> | A java futures library that has an andThen(Promise<T>...) call overloaded on the nunber of promises |
| 2021-08-19 02:56:11 | <dzdcnfzd> | frequently you run into a situation where one or two of your parameters is just a T, and not a Promise<T> |
| 2021-08-19 02:56:59 | <dzdcnfzd> | So I was trying to think about what would be required in a language to make this simpler |
| 2021-08-19 02:58:43 | <Cale> | Shouldn't there be an easy way to make a promise that's immediately satisfied? |
| 2021-08-19 02:59:23 | <dzdcnfzd> | There is, but it is disfavored for reasons I actually do not understand |
| 2021-08-19 02:59:50 | <Cale> | Well, also... |
| 2021-08-19 02:59:52 | <dzdcnfzd> | People say it screws up refactors or something |
| 2021-08-19 02:59:56 | <Cale> | If I understand what andThen is |
| 2021-08-19 03:00:01 | <Cale> | Is that bind? |
| 2021-08-19 03:00:01 | × | haasn quits (~nand@haasn.dev) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2021-08-19 03:00:12 | <Axman6> | Anyone ever wish that type equality had its own language extension? Needuing TypeFamilies or GADTs to do foo ~ bar seems like overkill |
| 2021-08-19 03:00:12 | <dzdcnfzd> | It is precisely bind |
| 2021-08-19 03:00:30 | <dzdcnfzd> | but with more than 1 argument |
| 2021-08-19 03:00:39 | <dzdcnfzd> | Because there's no nice do-notation |
| 2021-08-19 03:00:43 | <Cale> | hmm |
| 2021-08-19 03:00:47 | <dzdcnfzd> | Because Java |
| 2021-08-19 03:01:03 | <dzdcnfzd> | So the let- strategy doesn't work |
| 2021-08-19 03:01:05 | <Cale> | Axman6: Maybe, though you kind of need one of those extensions to make it useful, don't you? |
| 2021-08-19 03:01:21 | <Cale> | dzdcnfzd: Just applying the function doesn't work? |
| 2021-08-19 03:01:37 | <Axman6> | it's also useful when doing type class based type nonsense too |
| 2021-08-19 03:01:48 | <Cale> | Maybe I don't understand what the multiple-arguments version means |
| 2021-08-19 03:02:04 | <joeyh> | one way you can make overloading scale is with a helper function. start with class Conv a b where conv :: a -> b and then use that to make the helper function x & y = x (conv y) and that allows writing eg: foo & a & b & c & d |
| 2021-08-19 03:02:04 | → | haasn joins (~nand@haasn.dev) |
| 2021-08-19 03:02:18 | <Cale> | Axman6: ahhh... yeah, to make instances that commit early and then complain if the type doesn't match |
| 2021-08-19 03:02:31 | <dzdcnfzd> | you mean andThen(promiseValue1, Promise.of(barValue1))... |
| 2021-08-19 03:03:07 | <dzdcnfzd> | joeyh: ooh, clever |
| 2021-08-19 03:03:32 | <Cale> | dzdcnfzd: Like, let's say you have some known value v, and you wanted to write mkPromise(v).andThen(foo), couldn't you always just write foo(v) ? |
| 2021-08-19 03:04:01 | <monochrom> | But foo will not have a function type. Because Java. |
| 2021-08-19 03:04:01 | <Cale> | dzdcnfzd: I'm not sure what the next argument to andThen might mean though... |
| 2021-08-19 03:04:15 | <Cale> | monochrom: Surely it's got to be something callable? |
| 2021-08-19 03:04:16 | <joeyh> | you will need FlexibleInstances to implement the Conv type class. Also all the good punctuation is taken :P |
| 2021-08-19 03:04:32 | <Cale> | Someone link the documentation :D |
| 2021-08-19 03:05:23 | <Cale> | foo.apply(v)? |
| 2021-08-19 03:05:24 | <dzdcnfzd> | Cale: Sorry, the full API is: antThen(Promise<T1> x1, Promise<T2> x2, ..., Function<T1, T2, ...., Promise<S> transform) |
| 2021-08-19 03:05:37 | <dzdcnfzd> | Missed a bracket there |
| 2021-08-19 03:05:44 | <dzdcnfzd> | Function<T1, T2, ...., Promise<S>> transform |
| 2021-08-19 03:05:53 | <Cale> | ahh, it's like liftMn |
| 2021-08-19 03:06:02 | <Cale> | Or <$> and <*> |
| 2021-08-19 03:06:13 | <dzdcnfzd> | Yes, exactly |
| 2021-08-19 03:06:38 | <dzdcnfzd> | And it produces a Promise<S> |
| 2021-08-19 03:06:47 | <dzdcnfzd> | so you chain the calls |
| 2021-08-19 03:07:02 | × | cheater quits (~Username@user/cheater) (Remote host closed the connection) |
| 2021-08-19 03:07:21 | → | adam1 joins (~adam@220-136-101-125.dynamic-ip.hinet.net) |
| 2021-08-19 03:09:30 | <Cale> | I guess the trick is that the function which is the last argument is annoying to partially apply to the known values |
| 2021-08-19 03:09:31 | <monochrom> | I would seriously just write like "andThen(x1, unit(10), x3, ..., callback)", or s/unit/whatever the monadic unit of Promise is called in Java/ |
| 2021-08-19 03:10:05 | → | cheater joins (~Username@user/cheater) |
| 2021-08-19 03:10:52 | <Cale> | Yeah, that's not too bad if you have a known function, the other option being like andThen (x1, x3, ..., (v1,v3,...) -> callback(v1,10,v3,...)) |
| 2021-08-19 03:11:55 | <Cale> | If you're writing the continuation inline, then just inlining the known parameter might be easiest |
| 2021-08-19 03:12:32 | <monochrom> | Inlining the known parameter would be what I call "bad for refactoring". |
| 2021-08-19 03:13:17 | <Cale> | Maybe sometimes |
| 2021-08-19 03:13:25 | <monochrom> | "andThen(x1, unit(10), x3, ..., callback)" is good for refactoring because it is a trivial sed to replace "unit(10)" by x2, when one day you have a non-trivial x2. |
| 2021-08-19 03:13:32 | <Cale> | Other times it would be a good refactoring to do |
| 2021-08-19 03:14:06 | <monochrom> | or alternatively if one day x3 needs to be trivialized to unit("hello") |
| 2021-08-19 03:14:10 | <Cale> | Like, if the callback is a thing that only really gets used once and is maybe already written as an inline lambda |
| 2021-08-19 03:14:24 | <Cale> | Then maybe it just has a parameter it shouldn't have |
| 2021-08-19 03:14:44 | <monochrom> | But generally and meta-ly I wouldn't be surprised if the Java community hates the algebraic POV. |
| 2021-08-19 03:15:12 | × | venuex quits (~venue@user/venue) (Quit: was tired) |
| 2021-08-19 03:15:47 | <monochrom> | The algebraic POV says that where you have a >>= you also have a unit, where you have <|> you also have empty, where you have <> you also have mempty. The identity element of the binary operator you care about. |
| 2021-08-19 03:17:40 | × | vysn quits (~vysn@user/vysn) (Ping timeout: 240 seconds) |
| 2021-08-19 03:17:52 | <monochrom> | The identity element looks useless, algebra haters will say "why would you even give it a name? it does nothing, you will never use it". |
| 2021-08-19 03:18:12 | <monochrom> | Ah but one day you find yourself needing "if x>0 then identity element else non-trivial thing". |
| 2021-08-19 03:18:40 | × | bgamari quits (~bgamari@72.65.101.163) (Ping timeout: 240 seconds) |
| 2021-08-19 03:18:56 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-08-19 03:18:59 | <Cale> | I can see where if the unit is sufficiently expensive, then people start having a decent reason to avoid it, but that's something that should probably be fixed. |
| 2021-08-19 03:19:02 | <monochrom> | And it arises from refactoring "if x>0 then last thing else non-trivial thing <> last thing" |
| 2021-08-19 03:19:40 | → | bgamari joins (~bgamari@2001:470:e438::1) |
| 2021-08-19 03:20:40 | × | shapr quits (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2021-08-19 03:21:56 | <monochrom> | Java enjoys JIT. There are a lot of more inefficient code people embrace and never question. |
| 2021-08-19 03:28:22 | <dzdcnfzd> | Inlining is what we currently do but I hate it because it makes code 3 times as long |
| 2021-08-19 03:28:37 | <Cale> | Wait, why? |
| 2021-08-19 03:29:10 | <dzdcnfzd> | andThen(promise1, ...., promiseN, (var1, ...., varN) -> nextFunction(var1, ...., varN)) |
| 2021-08-19 03:29:20 | <Cale> | Oh, I guess |
| 2021-08-19 03:29:29 | <dzdcnfzd> | vs. andThen (promise1, ... promiseN, this::nextFunction) |
| 2021-08-19 03:29:56 | <dzdcnfzd> | This adds up when you've got 8-15 parameters |
| 2021-08-19 03:30:33 | <Cale> | Yeah, if there's already a fixed function which you could just name, then definitely, I would go with monochrom's approach of applying the unit for your promise monad. |
| 2021-08-19 03:31:52 | <Cale> | If the argument against it is efficiency, it's the difference of constructing a trivial promise vs. constructing a lambda that you otherwise don't need. |
| 2021-08-19 03:32:40 | <Cale> | Both of those should typically be ignorable in terms of cost |
| 2021-08-19 03:32:46 | <dzdcnfzd> | Cale: That's what I wanted to do. Unfortunately, I work at a big shop, and so *gestures at the style guide* is a fairly ironclad argument. |
| 2021-08-19 03:32:58 | <dzdcnfzd> | Style-guide says don't do it so we don't. |
| 2021-08-19 03:33:32 | <dzdcnfzd> | I was more interested in what it would take not to have to make this tradeoff at all |
| 2021-08-19 03:33:49 | <dzdcnfzd> | It's a sort of dynamic operator overloading |
| 2021-08-19 03:33:59 | <dzdcnfzd> | I assumed there was some name for what I was thinking about |
| 2021-08-19 03:51:24 | × | hnOsmium0001 quits (uid453710@id-453710.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-08-19 03:53:05 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 248 seconds) |
| 2021-08-19 03:54:40 | × | adam1 quits (~adam@220-136-101-125.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2021-08-19 04:14:26 | → | zmt01 joins (~zmt00@user/zmt00) |
| 2021-08-19 04:15:30 | → | hnOsmium0001 joins (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-08-19 04:18:42 | × | zmt00 quits (~zmt00@user/zmt00) (Ping timeout: 272 seconds) |
| 2021-08-19 04:23:17 | × | jpds quits (~jpds@gateway/tor-sasl/jpds) (Remote host closed the connection) |
| 2021-08-19 04:24:07 | → | jpds joins (~jpds@gateway/tor-sasl/jpds) |
| 2021-08-19 04:25:10 | × | sim590 quits (~simon@modemcable090.207-203-24.mc.videotron.ca) (Ping timeout: 268 seconds) |
| 2021-08-19 04:33:33 | × | gethuen quits (uid502979@id-502979.stonehaven.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-08-19 04:35:49 | × | Erutuon quits (~Erutuon@71-34-3-64.mpls.qwest.net) (Changing host) |
| 2021-08-19 04:35:49 | → | Erutuon joins (~Erutuon@user/erutuon) |
| 2021-08-19 04:36:07 | × | Erutuon quits (~Erutuon@user/erutuon) (Quit: WeeChat 2.8) |
| 2021-08-19 04:36:20 | → | Erutuon joins (~Erutuon@user/erutuon) |
| 2021-08-19 04:40:40 | → | adam1 joins (~adam@220-136-103-36.dynamic-ip.hinet.net) |
All times are in UTC.