dotty-cps-async VS iron

Now in scala we have direct mode transformers: dotty-cps-async [https://github.com/rssh/dotty-cps-async] with cps-async-connect [https://github.com/rssh/cps-async-connect ] supports all well-knowm monad stacks, for ZIO also exists ZIO-direct [https://github.com/zio/zio-direct ] , for IO - cats-effect-cps [https://github.com/typelevel/cats-effect-cps ], for kyo [https://github.com/fwbrasil/kyo ] - kyo-direct.

dotty-cps-async: https://github.com/rssh/dotty-cps-async

Hmm, you can write direct-style code with monad: https://github.com/rssh/dotty-cps-async allows this, exists support libraries exist for near all well-known effect systems: https://github.com/rssh/cps-async-connect, so you can use async/await with IO/ZIO the same as with Future. Although in IO style, any operation that mutates state is async, it's hard to write code where you should place `await` near each line. And it looks like automatic coloring is a too radical change of concepts for most functional programmers. The option to allow using <- in the direct style may be more popular, but this requires changes to the scala core. Another question - are we need effective systems to be present in each program in industrial-style development? Here I agree that mostly no.

This is a generic async/await transformer for scala3 which allows using effectful monads in the direct style. URL: (https://github.com/rssh/dotty-cps-async )

dotty-cps-async [rssh/dotty-cps-async ] with automatic coloring do something very similar in two steps. Automatic coloring defines implicit conversion F[A] => A as x => await(x)(m). The compiler inserts those awaits inside async blocks and then eliminates them later via cps-transform. Exists some limitations which we need to add for effect monads like IO (we don't want run effect twice and don't want to screw semantics of effects by extra memoizing). So, if your language has a possibility to implement effect monads, then you need a possibility to restrict using Flattenable.

Scala has quite good support for refined types across multiple libraries. A solution using the refined library might look something like

> The output you see is not generated by python.

Obviously, as running the code generates a very different output…

> It's generated by an external type checker.

I know.

But again, you didn't say that.

You said the above code "generates" this…

Maybe you've heard that by now somewhere: Words matter… ;-)

> The context is python. We're talking about python. I'm making a statement about python.

No, you made a statement about type checking. Here the full quote once again:

> The contents of a string can't be type checked and if all methods are defined this way on a class none of it can be checked.

Nothing in this statement is about Python.

All I did was just proving your words once again to be nonsense: You can statically dispatch (which involves static type checking!) just fine on strings. My (Scala) code is prove of this fact.

> There is literally nothing in my statement to indicate I'm making a general statement about type checking.

LOL. Do you actually know what you're writing? Once more:

> The contents of a string can't be type checked and if all methods are defined this way on a class none of it can be checked.

That's a general statement… It couldn't be even more general, actually.

> But I will say checking for the contents of a string is rare for a type checker to do. That is a general statement that is generally true.

Once again complete nonsense.

There are whole libraries doing more or less nothing else than handling singleton types.

Whole software layers utilize that! But I guess you never heard of static data validation…

https://github.com/Iltotore/iron

You have so little clue, but such a big mouth… That's so embarrassing.

A helpful tip: Stop spiting out maximally general claims (because these are almost always wrong!), and think about what you're actually writing.

What's in your fantasy, or what you "may have meant" is irrelevant!

> The guy made factually incorrect statements and so did you.

That's exactly what I'm talking about: You're a severe DK victim as it seems…

> It's just true that he's wrong.

No, actually you are wrong with almost every claim, like I've proven now several times. And this nonsense still didn't stop… Oh, boy!

> people shouldn't get worked up about someone else identifying a mistake.

Think about that once again. Especially in the context that it's you who is wrong here with almost everything you say.

And no, nobody is "pedantic". It only gets quite unrealistic that someone who doesn't even get banal prose straight would be able to write any code. Because the computer is actually very pedantic. And after production is on fire you can't just come to your boss and excuse yourself with "but I've meant this differently, just the stupid computer did again not understand what I've meant".

But to be honest this would actually explain:

> I've likely worked for more companies then you in the last 5 years or so due to my personality. I don't stay at one place for long.

I have some suspicions to why you don't stay anywhere for long… And yes, that would be indeed related to personality…

You might want to check out Iron.

And there is a beginner-friendly ticket: Add alias for True constraint and IronType[A, True]

Annotation is not the only way (and probably not the best IMHO) to do refined types. You might be interested in Iron in Scala 3 or Refined in Scala 2/3.

The second major version of Iron is out, featuring a complete rewrite on top of better foundations.