Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 31 2019 16:41
    etorreborre closed #162
  • Jan 31 2019 16:41
    etorreborre commented #162
  • Jan 31 2019 14:33
    vitold commented #162
  • Jan 30 2019 22:34
    benhutchison commented #162
  • Jan 30 2019 14:53
    vitold opened #162
  • Jan 26 2019 23:38
    robertbutacu starred atnos-org/eff
  • Jan 23 2019 09:30
    Navneet-gupta01 starred atnos-org/eff
  • Dec 27 2018 04:31
    jugalps starred atnos-org/eff
  • Dec 26 2018 16:07

    etorreborre on master

    Simpler implementation of appli… (compare)

  • Dec 26 2018 16:07
    etorreborre closed #161
  • Dec 26 2018 16:07
    etorreborre commented #161
  • Dec 24 2018 12:36
    kencyke starred atnos-org/eff
  • Dec 24 2018 05:18
    buzden synchronize #161
  • Dec 24 2018 02:36
    TakashiOshikawa starred atnos-org/eff
  • Dec 23 2018 13:59
    crossroad0201 starred atnos-org/eff
  • Dec 23 2018 08:17
    Nymphium starred atnos-org/eff
  • Dec 21 2018 15:05
    buzden synchronize #161
  • Dec 21 2018 14:28
    mflis starred atnos-org/eff
  • Dec 21 2018 11:58
    buzden synchronize #161
  • Dec 21 2018 06:00
    wangpengwen starred atnos-org/eff
Eric Torreborre
@etorreborre
I think that choice n.1 is generally not that bad but in you example I would probably put _Option in the return type directly, like get(id: Long): Eff[R, Option[String]]
kusamakura
@kusamakura
Thanks for the feedback, @etorreborre. I've settled on something like that as well. I suppose I was too excited to move all effects from the return type into the effects stack :p
kaichao
@kaichaosun
Is the Eff[ConnectionIO] still maintain the transaction provided by doobie?
Eric Torreborre
@etorreborre
@dashengSun Eff[R, A] where ConnectionIO |= R is a program having some ConnectionIO effects which means having a ConnectionIO “program” which itself is a set of instructions requiring a database connection to be executed. This is why when you run that effect with runConnectionIO you need to pass a Transactor which contains that connection to the database (actually a connection from a pool of connections)
Dan Di Spaltro
@dispalt
Pushed a pr to support Monix 3.0.0-RC2, let me know what you think.
Dan Di Spaltro
@dispalt
@etorreborre any chance you are going to cut a new eff release soon?
Eric Torreborre
@etorreborre
Dan Di Spaltro
@dispalt
@etorreborre thanks!
Flavio W. Brasil
@fwbrasil
Hi folks! I'm working on an effect mechanism similar to Eff called Lst. I've heard that Eff has some usability issues and was wondering if this new approach addresses them. The main differences from Eff are that Lst preserves the order in which the effects are applied and doesn't use interpreters so it has less boilerplate and probably better performance. I'd love to hear your thoughts on it: https://scastie.scala-lang.org/redHVonuQHy3P3l0Og7WMA
Eric Torreborre
@etorreborre
Hi @fwbrasil! In my experience it is actually important to be able to interpret effects in any order. My current project at work is using freer where the order is constrained and that leads to refactoring issues because an interpreter for a given effect imposes a constraint on where the effect shoud live in the stack of effects. But you say you don’t use interpreters! Doesn’t that defeats the point of effects where we want to have an “abstract language” and then provide different implementations? The other thing that Eff supports is “extensible effects” meaning that a given expression using some effects can be embedded in another expression using more effects. And this is quite important to compose programs without having to know the whole context of the application. This leads to quite a lot of complexity in Eff, I agree, and this is why I have been stepping away from effects recently. I still find effects interesting though :-). I am in the process of translating Sandy Mac Guire’s example with simple records-of-functions and it is interesting to see that this cannot be done with simple modules! The reason is that he is using a “generator” effect which in a way can only be interpreted globally, once you have the full program. However in that case I would rather use a streaming library in my code because this is effectively what we want to do in his example.
In a way we lose the ideal program he describes at the beginning, in another way his ideal program is effectively a series of stream transformations where we want to abstract some of the steps (where the inputs come from, how to process them, how to output them). Once we can use a stream data structure, we can still abstract over all these components without using effects. Anyway that’s probably not very understandable at this stage but I hope to put this in a blog post soon :-)
Ben Hutchison
@benhutchison

Hi @etorreborre Im wondering if you ever tried compiling Eff code with the Dotty compiler?

Dotty is supposed to support the semantics of implicits in Scala 2, but Im finding that Eff code that compiles OK in Scala 2 doesn't compile under dotty.

Perhaps predictably, the problem seems in the interpretation, when the Eff machinery has to strip off effects from the stack, eg runReader. That's powered by that giant implicit "rube-goldberg machine" and perhaps some minor deviation in semantics between the two compilers has thrown it out..

Thinking to make a pair of Scasties, one scala 2.12 & working, same code in dotty failing...

Ben Hutchison
@benhutchison
Eric Torreborre
@etorreborre
@benhutchison no I haven’t tried Dotty and the original set of rules for implicit member resolution were largely experimental. One thing which would be worth trying with Dotty would be to simplify the structure of the Union of effects to come back to a simple list instead of a Tree. The tree structure was adopted because the implicit resolution compilation times were really bad with around 10 effects in the stack. Maybe this has improved?
Eric Torreborre
@etorreborre
Also Member1 is indeed the implicit which should be found but the effect type is inferred to be Nothing instead of `Reader[String, ?]. It would be worth trying to see if you can reproduce this on a very small example
Ben Hutchison
@benhutchison
So there was a bug in Dotty which is now fixed. I'll keep testing Eff with Dotty and report back my experiences..
Eric Torreborre
@etorreborre
Nice!
Jugal Shah
@jugalps
Hello everyone! I have newbie question. I have a program that returns and Eff[ProgramStack, Double].
I was just wondering if there is a way to chain the effects similar to Option.orElse behavior so that
I can replace with another Eff[ProgramStack, Double].
Jugal Shah
@jugalps
When I try to use orElse on the returned Eff[ProgramStack, Double], I get the following error:
No instance found for Member[org.atnos.eff.ErrorEffect.ErrorOrOk, ProgramStack].
The effect org.atnos.eff.ErrorEffect.ErrorOrOk is not part of the stack DealSizeTransformer.this.DealSizeStack
or it was not possible to determine the stack that would result from removing org.atnos.eff.ErrorEffect.ErrorOrOk
Ben Hutchison
@benhutchison

@jugalps late breaking reply...

orElse relates to the meaning of Option. In general, an Eff-expression has no pre-existing meaning, only the meaning you set by the type of ProgramStack. Thats why orElse can't be offered for a just any arbitrary Eff-expr.

Ben Hutchison
@benhutchison
If you want help to try to resolve that error :point_up: , I'd suggest creating a reproducible scastie to share
Eric Torreborre
@etorreborre
@/all I am thinking of donating this project to anyone who has enough skin in the game to be motivated to maintain it, probably the people at REA. I am not using Eff anymore and not even programming much in Scala these days so it might make more sense for someone else to take the lead on maintaining it. Note that @xuwei-k has been super nice in sending lots of small PRs to keep the project up to date but maybe someone wants to take it further in terms of updates and integrations. I will still be around of course to do my best to explain the various corner cases. A migration to Dotty would be super interesting by the way. The various effects of a stack are currently kept in a type-level tree because a type-level list was too slow in terms of compilation times after 6 or seven effects. But that makes the implicits for the Member typeclass a lot more complex than necessary. So it would be cool to see if this has improved with Dotty and the new implicit rules + implementation.
Ben Hutchison
@benhutchison

Hi @etorreborre ,

Im still using Eff and would be willing to take the lead to maintain it. I envisage a basic level of maintenance, keeping releases flowing and eventually migrating to dotty, rather than any major new initiatives. Some extensions might get deprecated if they dont have active user communities

I continue to see value in Effectful FP, and Eff is a very nice solution for that. To me, the challenge to Eff is whether other approaches (eg Cats MTL ) are a simpler way to achieve comparable benefits.

(apologies for the slow reply, I havent been checking Gitter frequently and when I do it usually to seek help with a question.)

Eric Torreborre
@etorreborre

I knew you would step up @benhutchison! I realize that you already are an admin on the project so the only thing left to me is to make an official announcement and whatever else you need from me (for publishing you will need to create an account on oss.sonatype.org and I can create an issue to give you access to the org.atnos group at issues.sonatype.org).

To me, the challenge to Eff is whether other approaches (eg Cats MTL ) are a simpler way to achieve comparable benefits.

This is an excellent remark and I am leaning towards that conclusion: https://medium.com/barely-functional/do-we-need-effects-to-get-abstraction-7d5dc0edfbef. In Haskell-land I see people doubling up on effect libraries (https://github.com/fused-effects/fused-effects, https://github.com/polysemy-research/polysemy). While those libraries are impressive I think the cases where they would bring a competitive advantage are very few. In the end I managed to recover one cool feature of effect libraries which is the ability to compose / recompose interpreters by using my own DI library (https://github.com/etorreborre/registry).

(apologies for the slow reply, I havent been checking Gitter frequently and when I do it usually to seek help with a question.)

You can set email notifications, I just realized that recently :-)

BTW I am still at your disposal if you get lost in the somewhat convoluted implementation of Eff :-)
Ben Hutchison
@benhutchison

Hi Eric, thanks for your confidence in me, much appreciated :)

If you could give me a day or so to review the repo, release process and collect any questions I have around routine maintenance tasks, I'll get back to you.

As a maintainer, my goals will be primarily to issue releases against scala and library releases, review PRs and to investigate bug reports, so existing users of Eff (like REA) can proceed with confidence. Probably little new features from here on.

As mentioned in atnos-org/eff#184, I'll probably look to limit the set of supported integrations (eg Doobie, ZIO etc), and encourage future integrators to self-publish, offering a list of links in README.

Yes, I'll probably tap your knowledge and skills from time to time if I get stuck.

Ben Hutchison
@benhutchison

If you use Eff AddOn integrations with Twitter, Scalaz, Monix or Doobie, please register your use case at atnos-org/eff#186

Im reviewing which AddOns are supported, and understanding the user base for each is key.

tanaka takaya
@takayahilton
Scala 2.13 support