Snipped and backdated from a Reddit comment of mine.

Functional programming is fundamentally very simple, but we do a great job at over complicating things without providing the proper abstractions.

On a side note: as horrible as MUMPS is, I still think it’s interesting having a key-value store built into the language.

Example from Wikipedia showing how to persist values to disk:

SET ^Car("Door","Color")="BLUE"

It’s almost as if Redis was invented in the 90s and integrated into some horrible language.

Click to view on seperate page…

/u/jaxrtech

True, the proposal is very abstract. To be a bit more concrete, here’s what trying to create a hypothetical implementation might look like running down pipeline from the diagram:

• Clients: Just about any IDE or editor has an API for code completion, rename refactoring, etc. Given your favorite editor, we would just need >to write a shim for to talk over platform’s protocol to interface the API.

• Protocol: There are tons of libraries already for writing protocols (e.g. ProtoBufs, msgpack, zmq). Messages can be sent over IPC or plain >old TCP sockets. You would just have to design an API.

• Compilation Server: This could be a typical CLI program which controls the compilation process. Maybe you would run something like:

  proton compile main.foo --lang jaxrtech/foolang
  

  It could then read a language.json I wrote to determine which libraries my Foolang depends on and start each of them up as a service to start >compiling.

• Syntax Library: This can be written in anything you want (it could be Java, node.js, it doesn’t matter) as long as it talks over the >protocol, can properly parse text into a syntax tree (and can do the reverse as well), and can translate everything into the core language.

• Semantic Libraries: Has more or less the same as building a syntax library except you’re just only translating between different grammars. >Any language can do this.

• Core Language Service: The core language can be abstraction layer on top of LLVM, could compile to JS or C, the JVM or the CLR.

Snipped and backdated from a Reddit comment of mine.

Using intersection with primitive types not make any sense since there is no common type.
(In type theory, this is called the bottom type.)

Now, an example of where intersection types would actually be useful is with struct or record types that you can combine togeather (i.e. “I want a type that has all properties in type A and all properties in type B”.)
This allows for sort of strongly typed duck typing so to speak. (Aside: you could also apply this same concept with OOP interfaces or something like Haskell’s typeclasses too.)

Elm’s “extensible records” gives you an idea of how this would work. It wouldn’t call these actual intersection types, so I’ve changed the syntax and semantics a bit for demo purposes.

So let’s say you’re writing a game in said modified Elm syntax and define the following record types:

type Positioned = { x: Float, y: Float }

type Named = { name: String }

type Moving = { velocity: Float, angle: Float }

And let’s say you define some entities as:

sword : Named & { damage: Int }
sword =
  { name = "Excalibur"
  , damage = 9001
  }

player : Named & Positioned & Moving
player =
  { name = "Sir Lancelot",
  , x = 0
  , y = 0
  , velocity = 42
  , angle = degrees 30
  }

In other words…

The type of sword is the intersection of:

• record type Named
• (and) an anonymous record type of { damage: Int }.

The type of player is the intersection of:

• record type Named
• (and) record type Moving
• (and) record type Positioned.
  

If we combine the intersections, the “evaluated” or “absolute” types could be written as:

sword : { name: String, damage: Int }

player : { name: String
         , x: Float
         , y: Float
         , velocity: Float
         , angle: Float
         }

Hopefully, this contrived example illustrates how intersection types could prove to be useful…

Snipped and backdated from a previous Reddit comment of mine.

Implementing union and intersection types could allow for interesting things. I know that at least Typescript and Ceylon implement them.

One major annoyance this alleviates is strongly typed collections with mixed types.

Now, this shouldn’t be confused with regular algebraic data types (ADTs) a la Haskell or F#’s “discriminated unions”, for example. ADTs kind of solve the problem but in a less powerful way. You have to define a new ADT type upfront and you can’t “mix” ADTs togeather. You only can compose them.

For example, if I wanted to define a list that contains either an int, string, or “nothing” in F#, I would do:

type Option<'a> =
     | Some of 'a
     | None

type Element =
     | EInt of int
     | EString of string

let xs: list<Option<Element>> = [Some(EInt 1); Some(EString "hello"); None]    

In F#, the type inferencer would infer that the type of xs without me writing the type out, but I had to still specify a new ADT upfront. And I can’t properly mix the types in the Option ADT with the types in Element ADT and have to wrap around the other.

Instead, in a type system with union and intersection types, you could make a union of the different types you want like:

let xs: list<int | string | null> = [1; "hello"; null]

And ideally, you would have type inference so you could have it still be statically typed without having to type out all possibilities:

let xs = [1; "hello world"; null];

You would then need to narrow the type down in order to safely use a value. This could be accomplished by using either pattern matching or by using control flow analysis “as a language construct” (Typescript has “type guards”, Kotlin has “smart casts”).

The funny similarity is that both do the same thing, but the former is usually implemented in a functional-style language while the latter in an imperative-style language.

Of course, this is just one feature and I haven’t even bothered discussing intersection types…