Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 24 2020 23:19
    dsilvasc synchronize #66
  • Oct 31 2020 22:35

    fwbrasil on master

    fix an typo in a type parameter Merge pull request #59 from joh… (compare)

  • Oct 31 2020 22:35
    fwbrasil closed #59
  • Oct 26 2020 22:55
    dsilvasc commented #44
  • Oct 26 2020 22:54
    dsilvasc opened #66
  • Oct 19 2020 21:08
    scala-steward closed #60
  • Oct 19 2020 21:08
    scala-steward closed #64
  • Oct 19 2020 21:08
    scala-steward opened #65
  • Oct 05 2020 01:58
    scala-steward opened #64
  • Sep 09 2020 11:04
    scala-steward opened #63
  • Jul 27 2020 16:07
    scala-steward opened #62
  • Jul 25 2020 15:39
    fwbrasil closed #61
  • Jul 25 2020 15:39
    fwbrasil commented #61
  • Jun 29 2020 05:21
    retronym edited #61
  • Jun 29 2020 05:13
    retronym opened #61
  • Jun 28 2020 00:02
    scala-steward opened #60
  • Jun 26 2020 19:46
    johnynek opened #59
  • Jun 26 2020 17:47
    fwbrasil closed #32
  • Jun 26 2020 17:47
    fwbrasil closed #31
  • Jun 26 2020 17:47
    fwbrasil closed #30
aappddeevv
@aappddeevv
they are separating out fs2 Task to cats.effects.IO...I'll put together the IO version and get a PR in.
Flavio W. Brasil
@fwbrasil
@aappddeevv great!
Felix Dietze
@fdietze
Hi, great project! While experimenting I found, that side-effecting functions inside a lift-block are not executed. Is this by design?
Flavio W. Brasil
@fwbrasil
@fdietze could you provide an example?
Felix Dietze
@fdietze
var x = 0; lift { x = 1; unlift(a) }
While writing this, I realize that this is probably a problem on my side... ;)
I have to investigate further
Flavio W. Brasil
@fwbrasil
:+1:
Felix Dietze
@fdietze

Ok, these two do not behave in the same way:

val b = Rx.MonadlessRx.map(a){a => changes += "b"; a + 1}
val b = lift {changes += "b"; unlift(a) + 1}

How exactly is the lift-version transformed?

aappddeevv
@aappddeevv
I just posted a typecheck error when using scala-js. Can someone take a look? monadless/monadless#5
Flavio W. Brasil
@fwbrasil
@aappddeevv I’ll take a look
Flavio W. Brasil
@fwbrasil
@aappddeevv just replied on the issue
aappddeevv
@aappddeevv
You have to use the Undef thing. That’s the issue. It’s trying to pull in evidence but fails. I’ll try scastie.
Flavio W. Brasil
@fwbrasil
@aappddeevv I tried but don't even know how to have js in scope. My scala.js experience is pretty limited
aappddeevv
@aappddeevv
It looks like I’ll have to make a project instead since scastie can’t do the latest scala-js
aappddeevv
@aappddeevv
I posted a github project that demonstrates the issue. I know that scaaljs is only at 1.0.0-RC2 but I think whatever is going on is related to the change in Undef that the macro cannot work through. BTW, monadless is very helpful to reduce the syntax complexity of my code.
Flavio W. Brasil
@fwbrasil
@aappddeevv I don't think the monadless artifacts on sjs 0.6 are compatible with sjs 1.0. Many things have changed
thanks for the feedback btw :)
aappddeevv
@aappddeevv
is there specific scalajs support in monadless that is the problem?
Flavio W. Brasil
@fwbrasil
@aappddeevv yes, it's compiled against sjs 0.6. It should be easy to generate an artifact for 1.0.0-RC2, though
Flavio W. Brasil
@fwbrasil
test
Ben Hutchison
@benhutchison

Hi @fwbrasil,

Thanks for creating this tool. Im quite interested in sort of the "monad syntax inversion" that Monadless provides.

I write alot of heavily monadic code, mainly using Eff and are pretty dissatisfied with for {} yield () as a syntax for monad logic.

For me, the biggest pain-point is actually verbose duplication in for expressions, between the terms on the right and the left. I seem to write an increasing number of fors that look like:

for {
  a <- something.a
  b <- a.b
  c <- b.c
} yield c

and a little voice in my head keeps nagging me whenever I grind out another of these overly-redudant structures. What I want to write is something.a!.b!.c! (where ! is basically yourunlift). Im convinced that is the future.

ATM I'm trialling @Atry's DSL but I also intend to give Monadless a try to compare.

One thing that's held me back from Monadless is the lack of a global "opt-in", as provided by the reseteverywhere plugin in DSL. When monads are 80% of your methods, having to write lift {...} everywhere will get boring.

Would you be open to considering a similar compiler plugin for Monadless?

Flavio W. Brasil
@fwbrasil
@benhutchison sorry for the delay to reply. I don’t think we’d need a compiler plugin for that. It should be possible to implement implicit macros that makes lift/unlift unnecessary. I wouldn’t use it because I think it’d be too much magic imo
Ben Hutchison
@benhutchison

Hi @fwbrasil

What do you envisage would trigger the implicit macros to transform the code in a method into "monadless" form?

The way DSL works is: a reseteverywhere plugin traverses all the defs and vals in the code and annotates them with a @reset annotation, which then causes a second compiler plugin to transform them to CPS style
=============== ============== ============

Re: your concern's about "too much magic": thats a reasonable, sensible concern.

However, in truth, I dont share the concern. And thats because I'm convinced this monadless representation will become very popular/influential in future programming.

if you imagine living in 1975, alot of things we do in programming, eg type inference, references instead of pointers, GC, dynamic linking, Futures, for expressions, would look like magic. But it turned out they could be made usable and predictable, and when things are useful, people will accept huge amounts of magic.

Somehow, by embracing Eff early Ive ended up writing much more pervasively monadic code than the wider population of programmers. And Ive tasted some problems that aren't yet widely recognized.

When most of your code is monadic, the economics change. The costs and limitations of our current-generation clunky monad syntax goes from annoyance to a major pain in ass. Calling a chain of methods that all return their result inside an M wrapper is much harder than it should be.

I feel like you and @Atry and @peletom (with Effectful ) have built implementations of a powerful new idiom for effectful programming, and the world hasn't "caught up" and realized how much potential it has.

In Haskell-land they are still coming to terms with this idea too.

Im curious, did you take the idea from Idris .. or another source.. or has it evolved concurrently?

Matthias Berndt
@mberndt123
Hey there, I'm currently wondering whether to use monadless in my projects. The thing that I'm concerned about it Scala 3. Apparently macros will be much more limited in Scala 3 and I wonder if monadless can still be implemented with these new macros
It would be a real blunder to write a lot of monadic code now and having to rewrite it two years from now
Philippe Derome
@phderome
Can we use if in monadless that are essentially withFilter?
Flavio W. Brasil
@fwbrasil
@phderome yes, but match guards can’t use unlift