Adam-Vandervorst

import language.implicitConversions
import compiletime.ops.int.*
import compiletime.ops.string.*


object Relationships:
  protected sealed trait Theorem
  protected class ==>[P, Q]

  type Has[T <: Theorem]

quelgar

Every Argument for Static Typing Applies to Typed Errors

Think of all the arguments you've heard as to why static typing is desirable — every single one of those arguments applies equally well to using types to represent error conditions.

An odd thing I’ve observed about the Scala community is how many of its members believe that a) a language with a sophisticated static type system is very valuable; and b) that using types for error handling is basically a waste of time. If static types are useful—and if you like Scala, presumably you think they are—then using them to represent error conditions is also useful.

Here's a little secret of functional programming: errors aren't some special thing that operate under a different set of rules to everything else. Yes, there are a set of common patterns we group under the loose heading "error handling", but fundamentally we're just dealing with more values. Values that can have types associated with them. There's absolutely no reason why the benefits of static ty

luciopaiva

CORS issues when running via Webstorm

Jetbrains had a Chrome extension where you could configure Webstorm to include CORS headers just fine, but it seems to not be working anymore (setting the field and hitting the apply button has no effect - reloading the extension configuration page shows that the field is still empty).

This comment was what helped me, but it was not enough. I reply to that comment with the extra instructions needed. Here's the full conversation in case that page goes down:

---

Ekaterina Prigara says:

smarter

Generalized Algebraic Data Types in Scala

Basic GADTs

Here's an ADT which is not a GADT, in Haskell:

data Expr = IntExpr Int | BoolExpr Bool