iron VS dotty

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.

Dotty? Was it still the name later?

http://dotty.epfl.ch/

I think this might be related to this issue.

You can look (and EPFL collect feedback) about EPFL implementation of async/await: https://github.com/lampepfl/async. Also you can look at dotty ticket about this: https://github.com/lampepfl/dotty/pull/16739

The reason I’m not currently an opaque type user as they do not play well with the tagless final style we use, though I am patiently awaiting some attention on my bug report: https://github.com/lampepfl/dotty/issues/17281

Links: - https://dotty.epfl.ch/ - https://scala-native.org/en/stable/ - https://www.scala-js.org/ - https://typelevel.org/ - https://zio.dev/ - https://github.com/scala-native/scala-native/pull/3120 - https://github.com/lampepfl/dotty/pull/16517 - https://dotty.epfl.ch/docs/reference/experimental/index.html - https://scala-cli.virtuslab.org/ - https://scalameta.org/metals/ - https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html - https://www.scala-lang.org/blog/2023/04/18/faster-scalajs-development-with-frontend-tooling.html - https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html

Scala Native has much more control on how the Scala AST is compiled, and can easier workaround platform limitations, eg. lazy vals in Scala 3 required reflection config for Native Image (see this and that), while in Scala Native we could mitigate problems with unsupported usage inside in other ways within the compiler plugin.

By the way, you might be interested in this recent PR which overhauls the scala 3 macro docs: https://github.com/lampepfl/dotty/pull/17060.

For example, this issue (https://github.com/lampepfl/dotty/issues/12840) was blocking the migration, it was reported more than a year ago and the fix was finally released a month ago (https://github.com/lampepfl/dotty/releases/tag/3.3.0-RC2).

For the record, there is an implementation of :javap which is close to being done but might need a volunteer to get it over the finish line: https://github.com/lampepfl/dotty/pull/12210

im glad to tell you that in 3.3.0 a lot of these -Wunused lints will be supported: see https://github.com/lampepfl/dotty/pull/16157