soc.me

Language Design: Implicit Numeric Conversions

Fri, 12 May 2017 10:00:00 +0000

TL;DR: The desire to make unrelated types act as if they were in a sub-typing relationship, which neither exists nor should exist, combined with syntax sugar that makes static dispatch look like dynamic dispatch creates a perfect storm of unintended, harmful consequences.

Implicit numeric conversions¹ are a special compiler feature in Scala that adds “convenience” conversions between number types, for instance:

val num: Double = 123 // num = 123.0

It is a feature that

is described as a mistake by the designers of Java²³
silently destroys data, loses numeric precision and changes semantics of overflow and division-by-zero
is inconsistently applied, and will become more inconsistent as new numeric types are introduced in future versions of Java
breaks all methods defined on numbers
cannot be defended against
cannot be deactivated

The Good: Intentions

Inferring the type of List(1, 2.3) to the useless common supertype of List[AnyVal] (as Int and Double do not have any interface in common) was deemed to be too confusing for beginners coming from Java.

Instead, compiler magic in the shape of “implicit numeric conversions” was added to convert “smaller” number types to “larger” ones, thus inferring List[Double] in the example above.

While the mechanism looks quite innocent, it rears its ugly hand in many unintuitive and unexpected circumstances, as these kinds of numeric conversions not only convert smaller integer types to larger integer types and smaller floating point number types to larger floating point number types, but also integers to floating point numbers:

val long:   Long   = 123        // Int -> Long
val double: Double = 123.45f    // Float -> Double
val wat: Float     = 123456789L // Long -> Float
//           result: 123456792.0f

The Bad: Type Inference

Scala’s type inference makes the behavior a lot more confusing compared to languages with mandatory type annotations.

Creating a list with two numbers triggers the conversion, concatenating two lists with one number each does not:

List(1, 2.3)            // List[Double]
List(1) ++ List(2.3)    // List[AnyVal]

Numbers of type Int are implicitly converted to Long, but not to BigInt:

List(1, 2L)        // List[Long]
List(1, BigInt(2)) // List[Any]

Although conversion only happens when there isn’t another unrelated type involved:

List(1.2f, 3.4d)        // List[Double]
List(1.2f, 3.4d, "abc") // List[Any]

Assigning a list of integers to a list of doubles works if done in a single line, but fails when done in two:

val nums1: List[Double] = List(1, 2, 3) // compiles

val nums2a = List(1, 2, 3)
val nums2b: List[Double] = nums5a       // fails to compile

On top of that, implicit numeric conversions also interact with type parameters. Consider this change in type inference due to a binary compatible “widening” of types in the method signature of Stream’s #:: method between Scala 2.12.1 and 2.12.2:

def fibonacci: Stream[Double] =
  0 #:: 1 #:: (fibonacci zip fibonacci.tail).map {t => t._1 + t._2}
// Compiles         in Scala 2.12.1 with def #::(hd: A): Stream[A].
// Fails to compile in Scala 2.12.2 with def #::[B >: A](hd: B): Stream[B]:
// error: type mismatch; found Stream[AnyVal], required Stream[Double]

Experienced developers understand the reasons that cause these differences, but it turns out to be quite baffling for users new to Scala.

The Ugly: Extension Methods

Another feature of Scala, extension methods, makes implicit numeric conversions much worse.

Java’s primitive types come without any methods, only operations like +, -, %, <<. Scala’s idea of minimizing the distinction between unboxed and boxed numbers means that numeric types receive “convenience” extension methods like round, floor, toBinaryString or toDegrees.

This gives rise to another set of puzzlers like the following:

123456789.round == 123456792

The reason for this behavior is that the extension methods are not consistently defined on all number types. As the compiler fails to find methods on some type (like round on Int), implicit numeric conversions are kicking in, silently converting and mangling numbers to another type that has them.

In response, another band-aid was applied. round was added to every number implicitly convertible to Float to avoid triggering the implicit conversion.

But even if all the missing methods on numbers were filled in, these efforts are easily defeated, as extension methods are statically dispatched. (Extension methods only look like instance methods, but act like static methods.) Thus the issue is just pushed down another layer:

123456789.round == 123456789 // fixed
def round(value: Float) = value.round
round(123456789) == 123456792 // unfixable

Also, this issue does not require conversions to floating point numbers. Conversions between integer types suffer from the same problem:

val bits: Byte = -1
bits.toBinaryString == "11111111111111111111111111111111" // a byte with 32 bits?

This is a design failure that cannot be fixed without abandoning implicit numeric conversions altogether.

The Worst: Having a Way Out, but not Choosing It

The far-reaching damage of implicit numeric conversions far outweighs the purported benefit of reducing beginner confusion and increasing convenience, considering how inconsistent the conversions are applied in the first place from the point of view of the target audience, new users.

Union types would have been one way out of this mess. They naturally address the concern of beginner-unfriendly type inference by removing implicit numeric conversions and simply letting type inference do its job:

List(1, 2.3) // should be List[Int|Double]

From an operational point of view, inferring List[Int|Double] is hardly more useful than List[AnyVal] before. That’s not the point, though: List[Int|Double] pinpoints the issue (mixing different number types) in a way new users can understand, whereas the old List[AnyVal] does not.

Union types enable the compiler to implement a more direct “what you see is what you get” approach instead of silently sprinkling magic over users’ code.

Disappointingly, Dotty, the next version of Scala which adds union types, barely addresses any of these issues⁴ and worsens the situation in some cases.

The common approach of explicitly specifying the expected supertype stopped working in Dotty:

List[Any](1, 2.3) // List[Any] = List(1.0, 2.3)

Even explicitly specifying union types does not prevent these conversions:

List[Int|Double](1, 2.3) // List[Int|Double] = List(1.0, 2.3)

Adding an unrelated type prevents the conversion though:

List(1, 2.3, "abc") // List[Any] = List(1, 2.3, abc)

Scala users that have settled on adding the imperfect Ywarn-numeric-widen to their list of compiler flags will be hit the hardest, as the warning is not implemented in Dotty and even if it were, they are now left with fewer options to address the warning in Dotty.

Bonus Quirk

Regardless of whether this problem is fixed, the implementation of round on Float and Double is still wrong and broken for unrelated reasons.

Scala repeats another mistake from Java that was originating from C. Interestingly, while the .NET team copied a lot of design decisions from Java, they considered the issue to be so egregious that they fixed it before their first release of .NET.

Implicit numeric conversion is used as a term to describe the general concept in this document. In practice, various approaches have been tried to implement the concept: a) literal implicit defs in the source code which exist only for “educational purposes” and are not actually used by the compiler anymore, b) the non-implicit methods that the compiler uses instead, c) the notion of weak conformance and d) the notion of “numeric harmonization” ↩
It would be totally delightful to go through [Java] Puzzlers, another book that I wrote with Neal Gafter, which contains all the traps and pitfalls in the language and just excise them – one by one. Simply remove them.
There are things that were just mistakes, so for example … [misspeaks] … int to float, is a primitive widening conversion and happens silently, but is lossy if you go from int to float and back to int. You often won’t get the same int that you started with.
Because, you know, floats, some of the bits are used for the exponent rather then the mantissa, so you loose precision. When you go to float and back to int you’ll find that you didn’t have the int you started with.
So, you know, it was a mistake, it should corrected, it would break existing programs. So I do like the idea of essentially writing a new language which is very similar to Java which sort of fixes all these bad things. And if someone’s to call it ‘Java’, that would be great, too. Just so long as traditional Java source code can still be compiled and run against the latest VMs. […]
Joshua Bloch, Devoxx 2008

↩
OSCON Java 2011: Josh Bloch, “Java: The Good, Bad, and Ugly Parts” ↩
Numbers are not implicitly converted to allow extension methods calls defined on larger numbers anymore, because Dotty invented another slightly different language concept, “numeric harmonization”, which only works on a small predefined set of language constructs like if, match, try and in arguments to repeated parameters. ↩

Language Design: Fixing Rust's mistakes – Syntax

Thu, 20 Jul 2017 00:00:00 +0000

As Rust 2.0 is not going to happen, Rust users will never get these language design fixes:¹²³⁴

A note on the lower bar of a hypothetical Rust 2.0

An article touching on "Rust 2.0" and its reactionary reception made it apparent that language evolution has two boundaries, not one:

Boundary 1 (upper bar of change): Things a hypothetical language "v2.0" is not allowed to improve for compatibility reasons.
Boundary 2 (lower bar of change): Things that a hypothetical language "v2.0" needs to improve for such an effort to be worthwhile to contributors and users.

For Rust, we know the exact coordinates of the first boundary, but very little about the second boundary, as such "critical" engagement is poorly received by the community.

Nevertheless, only a cursory look is needed to conclude that "Rust 2.0" is very unlikely:
The lower bar is above the upper one, i. e. the required changes to make it worthwhile are larger than Rust leadership's acceptance for change.

This doesn't mean that we can't explore the second boundary, and collect these "unacceptable fixes" as a learning opportunity for future language designers!

Drop `{}` struct initialization syntax

There is little reason why invoking functions, initializing structs and enums, and initializing tupled structs and enums have to follow different rules.⁵

Instead, do away with the distinction between tupled vs. non-tupled structs/enums and standardize on () for function invocation and struct/enum initialization.

See this article for more details.

Named parameters using `=`

After dropping the special syntax for struct literal initialization, use = to name parameters for any kind of invocations in Rust.

This allows restoring the intuition that = is followed by a value and : is followed by a type, and that every value can receive a type ascription.

See this article’s appendix for an evaluation of available design options.

Use `[]` instead of `<>`/`::<>` for generics

Turns out “trying to preserve the strangeness budget”⁶ can’t fix a broken design.

Drop range syntax

It takes up way too much language footprint for very little actual benefit, is a source of language expansion proposals and the actual implementation in Rust suffers from quite a few other problems.

Drop array and slice syntax

This frees up the [] bracket pair for more useful purposes, like type parameters/arguments.

Fold `Index` and `IndexMut` into `Fn` trait family

Providing traits to let people decide how round they want their function call parentheses to be is not a useful feature.

Replace `impl` with purpose-focused alternatives

There are roughly three different purposes for which impl is used. Disentangle these purposes, drop the impl keyword, and make the replacements feel more cohesive with the rest of the language:

Replace impl definitions that add methods to a struct/enum/... with methods in the struct/enum/... body.
Replace
```
struct Foo { bar: Bar }
impl Foo { fn qux() -> Qux { ... } }
```
with
```
struct Foo(bar: Bar) {
  fn qux() -> Qux { ... }
}
```
Replace impl with trait in definitions that implement a trait for a given struct/enum/... type.
Replace
```
impl SomeTrait for Type
```
with
```
trait SomeTrait for Type
```

Replace impl in definitions that hold "extension" methods.

Replace

impl<T> Option<Option<T>> { ... }

with

trait OptionExt<T> for Option<Option<T>> { ... }

Stop using macros to emulate varargs

Macros are largely used to work around the lack of varargs in Rust.⁷

Instead, extend Rust’s vararg support from extern functions to all functions.

Drop `::`

The distinction between path navigation (::) and member access (.) is not important enough to bother users at every single occasion.

Instead, let the IDE use some syntax coloring and be done with it.

Drop `as`

… or at least make it make sense: it should either do type conversions or value conversions, but not both.

Not to mention that as caused security vulnerabilities already.⁸

Drop `if-let`

You know a feature is not well-thought-out if it has spawned 4 extensions proposals already.

Instead, use the vastly superior is design.

Drop procedure syntax

Functions that return no useful value enjoy special syntax privileges over functions that return a value.

Drop this syntax sugar and require -> () to be written down explicitly, like for every other type.

Drop `->` in function signatures

No reason to have two different ways to attach a type to the preceding program element. Just use :.

Remove significance of semicola

Varying the meaning of a piece of code based on the presence of a ; at a specific line is bad user interface design.

Remove it and implement automatic semicolon inference, such that IDEs can show them, but no user has to ever type them.⁹

“Does Rust have any design mistakes?” ↩
label:rust-2-breakage-wishlist ↩
Broken and un-fixable parts of Rust ↩
An Analysis of Rust’s Language Design Flaws ↩
Especially considering that half the people immediately define a ::new() functions to avoid struct initialization syntax.
Having the choice between both is already a net-negative on its own. ↩
The language strangeness budget ↩
All language designers hate varargs, but handing out macros as a replacement is considerably worse. ↩
Using u16::max instead of u16::MAX potentially allows very long certificates ↩
If your sole wisdom on “leaving semicolons out” is JavaScript’s ASI, then you are not qualified to have an opinion on this topic, sorry. ↩

Language Design: Generics

Fri, 21 Jul 2017 00:00:00 +0000

Two interconnected design decisions achieve a particularly interesting sweet-spot in language design:

The ident: Type syntax allows consistent and straight-forward placement of generics, compared to languages which use Type ident¹:

Generics ([T]) always follow the name of a class or a method, both at the definition-site and at the use-site.
A clearly defined use of brackets results in a more regular, easier to understand syntax that has superior readability compared to languages that use < and > for generics as well as for comparisons and bitshifts, or use [] to stand for operations on arrays²:

[] encloses type parameters or type arguments
() groups expressions, parameter/argument lists or tuples
{} sequences statements or definitions

This means that generics do not need to be treated as an “advanced” language concept.

Instead, the mental model becomes so simple that every class or method can be thought of having …

zero or one parameter lists for types, followed by
zero or more parameter lists for values.

class Foo[T](let bar: String)
  fun foo[U] = ???

fun main()
  let instance = Foo[String]("abc")
  instance.foo[Int64]

And that’s all there is to it!

Language Design: Use `ident: Type`, not `Type ident`

Fri, 21 Jul 2017 00:00:00 +0000

In expressive languages, developers generally need to use fewer temporary variables. This means that in a typical piece of code there are fewer names defined, but those names carry higher importance.

The ident: Type syntax lets developers focus on the name by placing it ahead of its type annotation. This means that the vertical offset of names stays consistent, regardless of a type annotation’s presence or absence¹:

let x: String = "hello"
let y: Float = 23.42
let z = 11
// vs. (hypothetical syntax)
String x = "hello"
Float y = 23.42
var z = 11

In addition to this, there are three technical reasons why ident: Type is superior:

1. Input before output

The i: Int syntax naturally leads to a method syntax where the inputs (parameters) are defined before the output (result type), which in turn leads to more consistency with lambda syntax (whose inputs are also defined before its output).

2. Consistency between definition and usage

The way a class or method is defined should mirror the way it can be used. (See Stop using <> for generics.)

3. Definition before usage

A generic type parameter should be declared before it is used. Otherwise it’s hard to tell to what a type argument refers to:

class Id<T>() {
  // Does the result type T refer to the class' <T> in scope,
  // or to the method's <T> that comes after it?
  T id<T>(T x) { ... }
}                            

Language Comparison

As languages have explored various designs², we can check whether they satisfy the three properties mentioned above:

Java

<T> T id(T x) { ... }

T id<T>(T x) { ... }

Kotlin

fun <T> id(x: T): T { ... }

Ceylon

T id<T>(T x) { ... }

Core

fun id[T](x: T): T = ...

Only the last approach delivers all three desirable properties:

	Input before output	Definition/usage consistency	Definition before usage
*Java*	❌	❌	✅
C#	❌	✅	❌
*Kotlin*	✅	❌	✅
*Ceylon*	❌	✅	❌
*Core*	✅	✅	✅

type inference means that the compiler can figure out types without having a developer writing them down explicitly ↩
focusing on curly-brace languages here, as languages like Haskell, ML and OCaml, Idris have slightly different design optima ↩

Language Design: (More) Mistakes of Rust

Sun, 30 Jul 2017 00:00:00 +0000

(A random grabbag of things that I haven’t managed to include into the main article yet.)

Strings don’t offer indexing, because it doesn’t make sense for UTF-8. Correct! But Strings offer slicing … WAT?
Inconsistent naming. str and String, Path and PathBuf etc.
Closures could be made to look much closer to functions, but somehow aren’t.
“associated” functions in trait impls. I’d prefer separating them from normal functions and drop the self where possible.
Arbitrary abbreviations all over the place. It’s 2017, your computer won’t run out of memory just because your compiler’s symbol table stores Buffer instead of Buf.
Can someone decide on a casing rule for types, please, instead of mixing lowercase and uppercase names? Some types being “primitive” is an incredibly poor excuse.
Also, having both CamelCase and methods_with_underscores?
Single-use packages like std::option::Option, std::result::Result, std::default::Default.
iter(), iter_mut(), into_iter() … decide prefix or postfix style and stick with it.
Forward and backward annotations: #[foo] struct Foo {} vs struct Foo { #![foo] }.
Type bounds are Sized by default, with some weird special syntax to opt out (?Sized).
/// for normal documentation, //! for module level documentation. Documentation already uses Markdown, so maybe just let people drop a markdown file in the module dir? That would make documentation much more accessible when browsing through GitHub repositories.
Also, documentation can cause compiler errors … that’s especially fun if you just commented a piece of code for testing/prototyping.
Type alias misuse: In e.g. io crate: type Result<T> = Result<T, io::Error> … just call it IoResult.
Compared to languages where macro invocation do not require special syntax (the !), the “obviousness” of invoking macros seems to have encouraged Rust developers to go completely over board in terms of magic.

Language Design: Equality & Identity – Part 1: Overview

Tue, 31 Oct 2017 00:00:00 +0000

Most languages have a notion of equality comparisons based on value equality. Many of them also provide a more restricted equality comparison that works only on references, often called reference equality. Here are a few examples:

Java

== implements reference equality on reference types.
Object.equals and Objects.equals implement reference equality by default, but can be overridden to implement value equality on reference types.
Arrays.deepEquals implements value equality on arrays (equals does reference equality on arrays).
== implements value equality on primitive types.
- Primitive types can be implicitly converted to special wrapper classes, which implement equals slightly differently.
- As these wrapper classes are reference types, == checks for reference equality of the wrapper classes.

JavaScript

== uses “loose equality”.
=== uses “strict equality”.
Object.is uses “same-value equality”.
Specific methods like Array#includes, Set#has, Map#has, Map#get use “same-value-zero equality”.

Rust

eq (defined on PartialEq) implements value equality. It does not require that x eq x is true.
== (defined on Eq) implements value equality and requires that x eq x is true. Eq implies PartialEq.
Reference equality can only be implemented by casting references to pointers and comparing them.

C#

Object.Equals implements reference equality be default, but can be overridden to implement value equality on reference types.
ValueType.Equals calls Equals on each field contained within a value types.
Object.ReferenceEquality implements reference equality. The method always returns false for value types.
== implements reference equality on reference types, but can be overloaded to implement value equality (as done on System.String).
== can be overloaded to implement value equality for value types.
Numeric types use an extended version of value equality in which different numeric types are equal if they represent the same value.
IEquatable.Equals can be implemented to reduce boxing for value types, but should return the same results as overridden Equals methods on that type.

Scala

== (defined on Any) implements value equality.
- An extended version of value equality is used in which different numeric types can be equal if they represent the same value.
- This does not extend to arrays, which are plain Java arrays underneath.
eq (defined on AnyRef) implements reference equality.
The artifacts of Java’s wrapper classes for primitive types are significantly reduced.

Language Design: Equality & Identity – Part 2: Problems

Tue, 31 Oct 2017 00:00:00 +0000

Containment

The core issue is that equality on its own is insufficient to implement some, rather mundane, algorithms.

Asking the simple question “is some element contained in this data structure” in different languages demonstrates the problem:

Java:       List.of(Float.NaN).contains(Float.NaN);          // true
JavaScript: [NaN].includes(NaN)                              // true
Rust:       &[0.0/0.0].contains(0.0/0.0)                     // false
C#:         ((List<float>) [float.NaN]).Contains(float.NaN)  // true
Haskell:    elem (0.0/0.0) [0.0/0.0]                         // false
Scala:      List(Float.NaN).contains(Float.NaN)              // false

Only Java and C# get this right, and the reason why it works in Java is quite incidental:

Methods like equals or contains box the arguments before comparison, first check for reference equality, then call equals. Without boxing, it would not be possible to find a NaN value in a data structure in Java.

Complexity

The design decisions made by languages also come with a large footprint in language complexity. For instance:

There are many, often confusing options which equals method should be overridden or how == should be overloaded.
It is hard to know which of the many methods to use, and which semantics have been implemented by the author of the type.
Value types are often unnecessarily boxed for equality operations.
Generic code has to decide at declaration-site whether it requires arguments to be reference or value types.
- Java works around this by only supporting reference types in generics.
- Scala requires explicit bounds (<: AnyRef) to mark types that require reference equality.
- C# provides class (reference type) and struct (value type) constraints on generic types.
Language creators (Java) or users (Scala) need to decide whether interfaces support value types, or require that all subtypes are reference types.

Language Design: Equality & Identity – Part 3: Solution

Tue, 31 Oct 2017 00:00:00 +0000

Let’s take a step back and think about what these equality operations do:

Reference equality acts as a built-in, hard-coded comparison of the references themselves.
Value equality compares equality according to a user-defined implementation.

Is it possible to re-interpret reference equality that retains the existing behavior for reference types, but adds intuitive and useful behavior for value types (Int, Float etc.)?

Yes! There is a very useful reinterpretation of reference equality that addresses the mentioned issues and solves a few other problems along the way.

The core insight is that there are two –not one– useful, fundamental questions to ask:

“Is A identical to B?”
“Is A equal to B?”

Defining Equality and Identity

An identity comparison asks if two things are identical, based on a language-defined, fixed definition of identity.
An equality comparison asks if two things are equal, based on a user- or library-defined definition of equality.

This definition of an identity comparison extends the concept of reference comparisons to value types, by comparing the bits (and the type) of the value at hand:

reference types compare the bits of the reference itself.
value types compare the bits of themselves, e. g. the bits of an Int, a Float, or a Complex value.

This means that an instance of a reference type is only identical to another instance if they are the same reference, and an instance of a value types is only identical to another instance if their values match up exactly.

Having one operation, which is well-defined on both value types and reference types, also simplifies things in generic contexts.

How do equality and identity comparisons work?

Compared to the rather complicated, indirect approaches shown earlier, the concept of identity and equality provides a simple and consistent design.

The following table shows how this definition of identity and equality could work in practice:

	type	∘ means “is identical to”	∘ means “is equal to”
true ∘ true	value	true	true
1 ∘ 1	value	true	true
1.0 ∘ 1.0	value	true	true
Float.NaN ∘ Float.NaN	value	true	false
+0.0 ∘ -0.0	value	false	true
BigInt(1) ∘ BigInt(1)	reference	false	true
“abc” ∘ “abc”	reference	false	true

Conclusion

Languages should provide two, distinct operations that provide equality comparisons and identity comparisons.

Ideally, these operations do not exist on the languages’ top type, but are only available when the type is constrained appropriately (e. g. fun same[E : Identity](a: E, b: E) = a === b).

Assuming a language with traits/interfaces, code defining these two concepts would look like this:

trait Identity
  fun ===(other: Self): Bool
  fun !==(other: Self): Bool

trait Equality
  fun == (other: Self): Bool
  fun != (other: Self): Bool

Language Design: Package Objects in Scala

Wed, 20 Dec 2017 00:00:00 +0000

Scala has the concept of package objects which allow the declaration of methods, classes etc. that appear as if they existed directly inside a package, not enclosed in an object or a class.

Given the definition of a method qux for a package foo.bar, the method can be called with foo.bar.qux().

The Issue

Package objects are useful, but the way they are defined is pretty weird, and one of the obscure, inconsistent and hard to explain decisions of the language:

The package clause is foo, not foo.bar.
Given the package clause, the file package.scala is placed outside of the directory for which it defines members, further obscuring what it does.
The file name (package.scala) is not in sync with the name of the package object defined (bar).
There is some special syntax, package object, that is not self-explanatory.
It is hard to quickly identify package objects, as IDEs tend to show the name of the object and not the name of the file in the outline.
It also means it is unnecessarily hard to find package objects: To see whether foo.bar has a package object, you have to scour the parent package foo for an object with the same name as the package (bar).

The Solution

Here is a design that addresses these issues and is intuitive enough to not require a separate, explicit explanation of what package objects are, which rules need to be followed and how they work:

// file: foo/bar/package.scala
package foo.bar

object package {
  def qux = ???
}

The Workaround

As is it unlikely that this will ever be fixed, the best approach to package objects is to ignore the confusing syntax completely.

Instead, directly define them this way:

Coincidentally, this is exactly the transformation the compiler already does when compiling package objects. It side-steps all the unnecessary language complexity that was put on top of the concept of package objects.

Language Design: Unified Condition Expressions – Introduction

Sun, 21 Jan 2018 00:00:00 +0000

Idea

Replace the different syntactic forms of

if statements/expressions
switch on values
match on patterns and pattern guards
if-let constructs

with a single, unified condition expression that scales from simple one-liners to complex pattern matches.

Motivation

Cut the different syntax options down to a single one that is still easily recognizable by users.
Allow the design to scale seamlessly from simple cases to complicated ones.

Minimizing the number of keywords or turning condition syntax into method calls (like Smalltalk) are non-goals.

Observations

Ternary expressions and if statements can be fully subsumed by if expressions.
switch has a fixed part whose value is compared using an equality relation against a set of branch-specific values.
if supports arbitrary conditions, but allows more than two branches only by chaining if to an else.
Splitting conditions into a shared, common part and individual condition continuations conflicts with mandatory parentheses around conditions.
To ensure unambiguous parsing …
- the place where the shared part of condition ends and the individual continuations starts requires either braces around the branch, or a start keyword like then.
- the place where a branch ends and the next individual condition starts requires either braces around the branch, a keyword like end, or punctuation like , or ;.
- Indentation-sensitive syntax can be an alternative to both, but may or may not fit into the target language’s desired overall look and feel.

Considerations

Alternative keyword choices to if are match, switch, or when.
The keyword choice has no impact on the ideas presented.
Though not strictly required, ... may be used to make the division between the shared part of the condition and the individual condition continuation more apparent to the reader.

Examples

For the code examples, a hypothetical language with indentation-sensitive syntax and the keywords if and then has been chosen.

simple if expression

if x == 1.0                         /* same as */
then "a"                            if x == 1.0 then "a" else "z"
else "z"

a shared comparison operator for multiple condition continuations

if x ==       /* same as */    if x             /* same as */       
  1.0 then "a"                   == 1.0 then "a"        if x == 1.0      then "a"
  2.0 then "b"                   == 2.0 then "b"        else if x == 2.0 then "b"
      else "z"                          else "z"        else                  "z"

different comparison operators for each condition continuation

if x                                /* same as */
  ==  1.0 then "a"                  if x == 1.0       then "a"
  === NaN then "n"                  else if x === NaN then "b"
          else "z"                  else                   "z"

method calls

if xs                               /* same as */
  .isEmpty       then "e"           if xs.isEmpty            then "e"
  .contains(0.0) then "n"           else if xs.contains(0.0) then "n"      
                 else "z"           else                          "z"

pattern matching (`is`)

While is (being “just another” binary operator) is not strictly related to unified condition expressions, its use in unified condition expressions unlocks support for additional functionality often found in languages with switch or match keywords, such as binding values, wildcards (_) and guards.

binding values

if person
  .age < 18                 then 18
  is Person("Alice", _)     then person.age
  is Person("Bob", let age) then age
                            else -1

flow typing

if pet                              /* same as */       if pet is
  is Cat(_) then cat.meow()                               Cat(_) then cat.meow()
  is Dog(_) then dog.bark()                               Dog(_) then dog.bark()

pattern guards

if person
  is Person("Alice", _)              then "alice"
  is Person(_, let age) && age >= 18 then "adult"
                                     else "minor"

replacement for “if-let”

if person is Person("Alice", let age) then age else -1

PL/I: select-when statement

SQL (SQL:2003): "extended case" of case-when expression

CommonLisp: cond macro and case macro

Haskell (language extension): multi-way if-expressions

Rust: if-let syntax

Swift: Optional chaining

Language Design: Rust's Into in Scala

Tue, 27 Mar 2018 00:00:00 +0000

Rust’s Into

Rust’s std::convert::Into let’s you define conversion functions for structs like Person:

pub struct Person { name: String }

impl Into<String> for Person {
    fn into(self: Person) -> String { self.name }
}

This way functions can be defined that don’t e. g. require a String, but accept anything that can be converted into a string. The conversion then happens with an explicit call to into():

fn string<S: Into<String>>(s: S) -> String { s.into() }

let person = Person { name: "Joe".to_string() };
string(person); // works

Translation into Scala

View Bounds

Interestingly, Scala has view bounds which embody the same concept. They require an implicit function in scope which takes a given type and returns a String (in our case). View bounds (<%) look like this:

def string[S <% String](s: S): String = s

Let’s define Person as we did above:

case class Person(name: String)

And define our implicit method:

object Person {
  implicit def view(self: Person): String = self.name
}

We can now call

val person = Person("Joe")
string(person) // works

Note that there is no explicit call to some conversion method unlike in Rust.

Context Bounds

As I deprecated view bounds a few years ago, let’s look for an alternative approach to implement Rust’s Into in Scala! One possibility is to use path-dependent types and context bounds ( : ) instead of view bounds (the view method from above is kept unchanged):

class Has[O] { type Conversion[I] = I => O }
def string[S : Has[String]#Conversion](s: S) = s

Again, no explicit call to into is necessary, but the type signature starts to look quite bulky!

Scala’s Into

Talking all of this into account, what other alternatives are there, which don’t rely on deprecated features or require long, ugly type signatures?

It turns out, it’s possible to pick an approach that is quite close to Rust’s design!

Let’s define an Into trait, and the strings method using it:

trait Into[+O] { def into(): O }
def strings(s: Into[String]) = s.into

Now we define Into[String] for our Person, and it turns out, we can supply the implementation either internally or externally! (Which might be quite useful: we can make the decision whether we want to allow or disallow someone else to provide an alternative conversion function.)

// Approach 1:
case class Person(name: String) extends Into[String] {
  def into = name
}
// Approach 2:
case class Person(name: String)
object Person {
  implicit def Into(self: Person): Into[String] = () => self.name
}

strings(Person("Joe")) // works with both approaches

The only drawback is that, similar to Rust, the conversion method into needs to be called explicitly.

Java’s Supplier

Perhaps amusingly, it’s also possible to completely forgo the definition of our own Into type in favor of using Java 8’s Supplier interface (adjusting the types in the approaches above from Into to Supplier accordingly):

def strings(s: Supplier[String]) = s.get

… and that’s it!

Summary

We saw how Rust’s very useful Into type can be implemented in a different language, in four different ways, all with interesting benefits and drawbacks!

Language Design: Unified Condition Expressions – Exceptions

Sat, 28 Apr 2018 00:00:00 +0000

A reasonable question that might be asked is whether this design can be extended to also handle thrown exceptions, and whether such an extension could completely replace the try-catch-finally idiom.

One language that has done something similar is Ocaml, which has extended its pattern matching syntax/semantics.

One option might be something along the lines of

if readColorFromUri(location)
  // type-based pattern
  throws[IOException](let ex)        then "file error due to \{ex}"
  // value-based pattern
  throws(NetException(let msg))      then "network error with message \{msg}"
  // regular cases as usual
  == Color.RED                       then "red"
                                     else "other color"

This might require adding some amount of language magic to deal with the throws construct though, depending on the expressiveness of the core language.

Considering the costs and the complexity involved, it may be a better approach to simply drop exceptions from the design of the language and do without this additional layer of control flow.

Library Design: Naming Conventions – Part 1: Creation

Tue, 19 Jun 2018 00:00:00 +0000

Function Name	Code Example	Explanation
–	List(1, 2, 3) Array(12.3, 45.6) Set("a", "b", "c")	primary way of construction resulting instance contains provided arguments verbatim
`of(val1, ...)`	Person.of(name, age)	secondary way of construction resulting instance contains provided arguments verbatim result type might use `Option` or `Result` types to encode failures
`from(val)`	Person.from(personEntity) Person.from(family)	tertiary way of construction arguments are extracted, adapted, and/or converted the value of the instance is derived from the provided arguments result type is likely to use `Option` or `Result` types to encode failures
`parse(string)`	Person.parse(string) Int64.parse(string)	quaternary way of construction argument is parsed from a less structured representation, such as strings result type is highly likely to use `Option` or `Result` types to encode failures

Modification

Function Name	Code Example	Explanation
`with(val)`	person.withAge(23) person.with(age = 23)	returns a copy of a value with parts replaced by the provided argument

Library Design: Naming Conventions – Part 2: Conversion

Wed, 20 Jun 2018 00:00:00 +0000

Function Name	Code Example	Explanation
`to`	array.toList int32Value.toFloat64 dictionary.to[Queue]	implies a (potentially lossy) conversion of a value result type might use `Option` or `Result` types to encode failures
`as`	int64Value.asFloat64 int64Value.as[Float64] stringBuffer.asByteBuffer map.asSetOfEntries setOfEntries.asMap	implies a verbatim reinterpretation/wrapping/viewing of a value replacement for numeric "casts"

Language Design: Use Consistent Keyword Length

Fri, 07 Sep 2018 00:00:00 +0000

6 letters namespacing – declaring and managing namespaces:

module (unifies “object” and “package”)
import
export

5 letters “big” definitions (types):

class (reference type)
value (value type, alternative to struct)
union (alternative to enum)
trait (interface/typeclass)
alias (type alias)
mixin

4 letters control flow:

case/then/else or when/then/else
loop (alternative to while)
skip (alternative to continue)
exit (alternative to return)
yeet (alternative to throw)

3 letters “small” definitions (members):

fun (function)
let (immutable binding)
var (mutable binding)

Unused alternatives:

6 letters “invasive” control flow:

return
throws

2 letters control flow:

if/do/or

Language Design: Comparing and Sorting

Wed, 31 Oct 2018 00:00:00 +0000

Similarly to equality and identity, most languages have severely restricted facilities to handle distinct ordering relationships like comparison and sorting.

Languages usually provide only a single operation/protocol, often requiring workarounds for some data types in which the comparison operation and the sorting operation return distinct results.

Consider the following Comparable trait as it frequently exists across many languages (like Haskell, Rust, Swift, …):

trait Comparable[T]
  fun < (that: T): Bool
  fun > (that: T): Bool
  ...

… and an IEEE754-conformant comparison implementation for floating point values, i. e. -0.0 < +0.0, and Float.NaN < Float.PositiveInfinity are both false.

As it becomes obvious, such an implementation of partial order can be used to compare values, but cannot be used to correctly sort values (total order).¹

The reason is that the implementation of comparison operations for floating point values (a partial order, IEEE754 §5.11) cannot be used as a stand-in for sorting operations on floating point values.

Conveniently, IEEE754 standardizes a totalOrder relation in §5.10, defining how floating point numbers are sorted. The only requirement language-wise is to introduce a distinct trait² which represents total ordering, enabling a clean separation of comparison operations from sorting operations:

trait Sortable[T]
  fun sortsBefore(that: T): Bool
  fun sortsAfter (that: T): Bool
  ...

This enables the use of each individual trait for its specific purpose, without conflating different concerns:

// example of comparing values using Comparable
fun compareReversed[T : Comparable](x: T, y: T) = y < x

// example of sorting values using Sortable
fun sort[T : Sortable](values: Array[T]) =
  ...
  if values(i).sortsBefore(values(j)) { ... }
  ...

See also Comparison in C++. ↩
Rust is a good example of a language suffering from the problems caused by intermingling partial order with total order. ↩

Language Design: Equality & Identity – Part 4: Fixing Haskell

Thu, 14 Mar 2019 00:00:00 +0000

Basic goals, as mentioned in the previous parts:

You should not lose values inside a data structure.

Here is the simple example again, demonstrating the issue:

elem (0.0/0.0) [0.0/0.0] -- False

To be clear, elem is picked as the simplest example possible.¹

Status Quo

Why is Eq not doing its job, or rather – what is its job description in the first place? According to Data.Eq, not much:

The Haskell Report defines no laws for Eq. However, instances are encouraged to follow these properties: […]

Why does Eq provide no laws, compared to many other typeclasses that state them strongly and explicitly?

The reason becomes obvious if one scrolls though the list of typeclass instances. If the “encouraged properties” were upgraded to “laws”, Haskell would have law-breaking typeclass instances in one of its most central modules.

The fault of Haskell’s Eq is that it lives in a world in which there is only a single definition of equality per type, which is incorrect in general. Case in point: floating point numbers, which have multiple definitions (see IEE754 §5.10 and §5.11).

There can be multiple useful definitions of equality per type, and – depending on the use-case – having only one to pick is not sufficient. Even simple functions like list’s elem might require both equality and identity operations to work correctly, which means the frequently suggested newtype hack to swap one implementation of Eq for another one is insufficient.

Available Options

The key point is that only two of the three properties can be satisfied:

correct data structures
abstraction/polymorphism
a single “universal” equality function

The status quo is discarding property 1.:

Data structures which lose values, example: elem (0.0/0.0) [0.0/0.0] returns False.
Polymorphic data structures like Lists and Vectors.
A single equality function == on Eq.

Discarding property 2. would give you:

(Some) correctly working data structures, example: elem (0.0/0.0) someFloatList returns True.
Specialized data structures like FloatLists or DoubleVectors (likely in addition to polymorphic variants), which implement functions like elem using both Eq’s == and functions specific to Floats or Doubles. Semantics would differ between polymorphic and specialized variants.
A single equality function == on Eq, and type-specific functions in specialized data structures.

Discarding property 3. would give you:

Correctly working data structures, example: elem (0.0/0.0) [0.0/0.0] returns True.
Polymorphic data structures like Lists and Vectors.
An identity function (===), in addition to Eqs existing equality function (==).

Here is how the last approach can be implemented:

A Solution

The simplest fix (instead of introducing a new typeclass for identity) is to extend Eq as follows:

class  Eq a  where
  (==), (/=), (===), (/==) :: a -> a -> Bool

  x ==  y              = not (x /= y)
  x /=  y              = not (x == y)
  x === y              = x == y         -- new
  x /== y              = not (x === y)  -- new

Nothing would change for 99% of Eq’s instances, but the typeclass instances for Float, Double, … would now be defined as:

instance Eq Float where
  (==)  = eqFloat
  (===) = Numeric.IEEE.identicalIEEE  -- new

Then change the documentation replacing the “expected properties” of == and /= with “laws” of === and /==.

As a last exercise, adjust usages of x == y with x == y || x === y where appropriate (e. g. list’s elem).

And there you have it:

strong assurances instead of “it would be nice”
lawful instances where there were none before
more reliable behavior of data structures
no need to spin new types for things which should work out-of-the-box, because deriving Eq just works

Even arguing that False is the correct result of the code example does not detract from the points being made, as there are plenty of other examples. Taking Ord’s issues into account, which are very similar, would add even more examples. ↩

Language Design: Binary Operators are Overused

Sat, 21 Sep 2019 00:00:00 +0000

TL;DR: Use methods.

Many languages provide binary operators, usually for operations on numbers (addition, multiplication), bits (shifts) and boolean values. In general, this language facility has been overused, forcing users to learn and recall precedence and associativity of dozens of operators.

Additionally, some popular operators have additional problems:

The problem with `&`

Many older language that were influenced by C also inherited its incorrect operator precedence.

Newer languages like Go or Swift avoided copying this mistake.

The problem with `<<`, `>>`, `>>>`

Languages (like Java or JavaScript) that decided against providing both signed and unsigned number types often offer two operators for shifting bits to the right: one that preserves the sign bit and one that doesn’t.

The operators in question – >> and >>> – don’t indicate their respective semantics, forcing users to remember the rules.

The problem with `%`

In most languages the `%` operator implements a remainder operation, not a modulo operation

remainder: has the same sign as the dividend
modulo: has the same sign as the divisor

	remainder	modulo
+4 % +3	1	1
-4 % +3	-1	1
+4 % -3	1	-1
-4 % -3	-1	-1

There are multiple possible implementations of remainder and modulo, with no clear winner

At least five approaches are known¹²:

Remainder of truncated division
Remainder of floored division
Remainder of ceiling division
Remainder of euclidean division
Remainder of rounded division

A sensible, small set of operators

Precedence level	Operator	Description
1	`=`	Assignment
2	`\|\|`	Boolean Or
3	`&&`	Boolean And
4	`==`, `!=`, `<`, `<=`, `>`, `>=`, `===`, `!==`	Comparisons
5	`+`, `-`, `\|`, `^`	Addition, Subtraction, Bitwise Or, Bitwise Xor
6	`*`, `/`, `&`	Multiplication, Division, Bitwise And

Language Design: Unary Operators are Unnecessary

Sat, 21 Sep 2019 00:00:00 +0000

TL;DR: Unary operators are a waste of a language’s complexity budget. Replace them with methods.

Many languages provide unary prefix operators – symbols placed in front of the value they apply to – such as:

!: Logical complement (on booleans)
~: Bitwise complement (on numbers)
-: Numeric complement (on numbers)
+: useless (on numbers)

Except for reasons of tradition and familiarity, their privileged position in many languages is unnecessary.
They provide rather limited benefits – while adding complexity to the core language.

An alternative is to define methods on the respective types, dropping unary operators altogether:

not replaces ! on booleans: someBool.not instead of !someBool
not replaces ~ on integers: 1.not instead of ~1
negate replaces - on numbers: 1.negate instead of -1

There are three benefits to replace unary prefix operators with methods:

It moves the negation closer to the thing being negated

if language.users.map(_.lastName).contains("Smith").not then ... else ... can be read from the left to the right, while the more traditional if !language.users.map(_.lastName).contains("Smith") then ... else ... requires users to read the negation first, then read the condition to the end of the line to figure out what is being negated.¹

It allows the use of more elaborate result types

While a negate operation may always succeed on arbitrary-precision numbers (BigInt, BigDec, …), the same operation on the more common fixed-size types (Int, Long, …) could benefit from returning an optional result to indicate that a negative value may lack a positive counterpart.

It is completely unambiguous

Code mixing unary prefix operators with other operations can be confusing to readers, for instance whether -1.abs evaluates to 1 and -1, and if the precedence only applies to literals or also code like let x = 1; -x.abs.
With methods, the code is unambiguous: x.negate.abs.

Appendix

Incomplete list of languages and their interpretation of -1.abs:

	-1.abs	let x = 1; -x.abs
C#	-1	-1
Core	1	1
D	-1	-1
Dart	-1	-1
Fantom	-1	-1
Groovy	-1	-1
Kitten	1	n.a.
JavaScript	-1	-1
Nim	-1	-1
Raku	-1	-1
Ruby	1	-1
Rust	-1	-1
Scala	1	-1
Smalltalk	1	n.a.

The Rust community had a similar discussion about this topic. ↩

Language Design: Unified Condition Expressions – Implementation

Sat, 21 Sep 2019 00:00:00 +0000

As a first approximation – especially if an existing language shall be adapted – it makes sense to build a feature-reduced version of unified condition expressions using a different keyword, in parallel to existing syntax.

After unified condition expressions have gained sufficient maturity and functionality, they can then be switched over to the “real” keyword, old implementations of ternary operators, switch-cases or if-expressions can be removed and their uses migrated to unified condition expressions.

Level 1: Basics

if person
  // `...` to indicate start of individual condition fragment
  ... == john { true }
  ... == jane { true }
else false

From a semantic point of view, the crucial requirement is that the common fragment is only evaluated once during execution.

This means that during typechecking, the combined expression of the common fragment with each individual branch has to be taken into account, but the common fragment has to be retained until code-generation.

Level 2: Pattern Matching

The core insight is that pattern matching occurs either always (switch&case, match&case) or never (if&then&else, ?&:) with “legacy” approaches.

With unified condition expressions, this choice can be made for each branch individually, using the is keyword:

if person
  ... is Person("john", _, 42) { true }  // paternn match
  ... .age > 23                { false } // no pattern match 
else false

Level 3: Bindings

The main design task is picking a convention/rule that decides whether an identifier inside a pattern match introduces a new binding with that name, or refers to an existing binding of that name in scope.

Possible design options include …

… using a keyword or symbol (for instance let or @) to introduce bindings in patterns:

let age = 43
if person
      // refers to the `age` binding defined earlier
  ... is Person("john",     "miller", age) { age.toString }
      // `let` introduces a new binding for jane's last name
  ... is Person("jane", let lastName,  23) { lastName     }
else false

… using a keyword or symbol (for instance $) to reference existing bindings in scope:

let age = 43
if person
      // `$` refers to the `age` binding defined earlier
  ... is Person("john", "miller", $age) { age.toString }
      // introduces a new binding for jane's last name
  ... is Person("jane", lastName,   23) { lastName     }
else false

… using casing rules to distinguish bindings from references:

let Age = 43
if person
      // uppercase refers to the `Age` binding defined earlier
  ... is Person("john", "miller", Age) { age.toString }
      // lowercase introduce a new binding for jane's last name 
  ... is Person("jane", lastName,  23) { lastName     }
else false

Optional: Partial Conditions

The notion of the condition’s common fragment can be made more flexible:

The common fragment can be partial; i. e. the common fragment may not be a valid expression on its own:

if person == // partial common condition fragment
  ... john { true }
  ... jane { true }
else false

The challenge here is how such code can be expressed best in the AST.

Optional: Indentation-based syntax

Introducing an indentation-based syntax allows dropping ... from the unified condition syntax without introducing problems in other places.

Similarly, {} could be replaced with then.

if person == // no `...` needed to indicate end of common condition fragment
  john then true  // optional: replace `{}` with `then`
  jane then true
else false

Language Design: Modern and Minimal

Tue, 05 Nov 2019 00:00:00 +0000

A smaller language, not a bigger one
- namespaces: types, terms, ~~packages~~, ~~fields~~, ~~methods~~, ~~labels~~
- modifiers: ~~keywords~~, annotations
- nesting: ~~packages~~, modules, ~~static~~
- members: fields, methods, ~~properties~~
- control flow: if-then-else, return, while, ~~break~~, ~~continue~~, ~~loop~~, ~~exceptions~~, ~~throw~~, ~~catch~~
- constructors: primary, ~~secondary~~
- literals: ~~octal number literals~~, ~~class literals~~, …
Correctness
- separate types for identity/equality, ordering/comparing
Fewer special-cases, not more
- operators: ~~unary operators~~, fewer binary operators
- ~~magic methods on all types~~
- ~~collection literals~~, ~~array syntax~~
- ~~instance-of-syntax~~, ~~cast-syntax~~
- types have consistent casing (uppercase)
Simplicity, not familiarity
- ~~generics with <>~~
- member definition syntax differs only by fun, let or var
Higher Standards
- simple to specify
- simple to implement
- simple to understand

Language Design: Stop Using `<>` for Generics

Sat, 04 Apr 2020 00:00:00 +0000

TL;DR: Use [] instead of <> for generics. It will save you a lot of avoidable trouble down the road.

1. `<>` is hard to read for humans

< and > are usually already used as comparison and bitshift operators, which (as binary operators) conform to a completely different grammatical structure compared to their use as brackets.
This, often in combination with other design mistakes – like the use of both () and [] for function calls, or literal syntax to construct lists, sets and maps – leads to a confusing and inconsistent use of brackets in many languages.

On top of that, imagine a programming font that in which the height of parentheses (()), curly braces ({}) or square brackets ([]) were capped to the height of a lower-case letter.
This is of course ridiculous – but exactly what happens with the (ab)use of the <> symbols for brackets.

2. `<>` is hard to parse for compilers

Many languages that were created without generics in mind had trouble adding generics later on, as all pairs of brackets – ( and ), { and }, [ and ] – were already put to use.

< and >, used in binary operators for comparisons and bitshifts, were usually the only symbols left in the grammar that are practical to overload with a new, different meaning.

That’s pretty much the only reason why <> started to be used as generics in the first place.

Unfortunately, using < and > for generics caused parsing problems in every language that tried use them for this purpose, forcing language designers to indulge in various ugly workarounds:¹

Java approached these issues by making the syntax less consistent (before function return types, but after class names) and limiting where generics can be used (for instance not with statically imported methods).²

C# and Kotlin tried to retain a more consistent syntax by introducing unlimited look-ahead: Their parsers keep reading input after the < until a decision can be made.³

C++ suffers from a plethora of <>-related issues.⁴ The only issue addressed by the C++ committee after decades was the requirement to add spaces to nested closing generics to allow the compiler to distinguish between the right-shift operator >> and the end of a nested generic type definition.⁵ All other issues appear to be unfixable.

Rust is forced to use the hideous “turbofish” operator ::<> to distinguish between the left side of a comparison and the start of a generic type, introducing syntactic inconsistency between generics in a type context and generics in a term context:

let vec: Vec<u32> = Vec::<u32>::new();
            /*or*/ <Vec::<u32>>::new();
            /*or*/ <Vec<u32>>::new();

A better design

Instead of repeating the mistakes of the past, imagine each bracket has a clearly-defined use:

[] encloses type parameters or type arguments
() groups expressions, parameter/argument lists or tuples
{} sequences statements or definitions

</> is only used as a comparison operator, and not misused as a makeshift bracket.

This substantially simplifies the mental model beginners need to adopt before writing their first program (”() is for values, [] is for types”), and encourages the elimination of syntactic special cases like collection literals …

Array(1, 2, 3)         /* instead of */   [ 1, 2, 3 ]
Set("a", "b", "c")     /* instead of */   { "a", "b", "c" }

… and array indexing in favor of standard function call syntax⁶:

someList.get(0)        /* instead of */   someList[0]
array.set(0, 23.42)    /* instead of */   array[0] = 23.42
map.set("name", "Joe") /* instead of */   map["name"] = "Joe"

A small amount of syntax sugar can be considered, leading to the following code:⁷

someList(0)            /* instead of */   someList[0]
array(0) = 23.42       /* instead of */   array[0] = 23.42
map("name") = "Joe"    /* instead of */   map["name"] = "Joe"

Coda

Thankfully, the number of languages using [] for generics seems to increase lately – with Scala, Python, and Nim joining Eiffel, which was pretty much the sole user of [] for decades.

~~It remains to be seen whether this turns into tidal change similar to the widespread adoption of ident: Type over Type ident in modern languages.~~ With the recent adoption of [] for generics by Go and Carbon this seems to be the likely outcome.

Parsing Ambiguity: Type Argument vs. Less Than is a similar article focusing on some of these issues in more depth. ↩
Java: The syntax inconsistency is due to the difficulty a compiler would have to tell whether some token stream of instance . foo < is the left side of a comparison (with < being the “less-than” operator) or the start of a generic type argument within a method call. ↩
C#: See ECMA-334, 4th Edition, §9.2.3 – Grammar Ambiguities ↩
C++: See What are all the syntax problems introduced by the usage of angle brackets in C++ templates? ↩
C++: See Wikipedia – C++11 right angle bracket ↩
Nim uses [] for generics, but employs a hack to also use [] for lookup. ↩
Pyt hon and Scala demonstrate that this approach works incredibly well. ↩

Language Design: Popular, but Wrong

Tue, 20 Oct 2020 00:00:00 +0000

static members
properties (see)
<> for generics (see)
[] for arrays (see)
Type ident instead of ident: Type (see)
having if-then-else and switch/case and a ternary operator (see)
having both modifiers and annotations (see)
async/await
separate namespaces for methods and fields
method overloading
namespace declarations doubling as imports
special syntax for casting
using cast syntax for things that are not casts
requiring () for methods without parameters

Language Design: Four Kinds of Unions

Thu, 26 Aug 2021 00:00:00 +0000

Overview

	Syntactic Wrapping	No Syntactic Wrapping
No Runtime Tags	untagged union (C union, C++ union, Rust union)	union type (TypeScript union type)
Runtime Tags	discriminated union/tagged union (Rust enum, F# discriminated union)	? (Algol united mode, Core union, C# nominal type union)

Upper Left: Untagged Unions

Some languages like C, C++ or Rust provide untagged unions, where the chosen variant has to be specified on creation:

union Pet {
  cat: Cat,
  dog: Dog
}
let pet = Pet { cat: Cat("Molly", 9) }

Values of untagged unions do not contain metadata (runtime tags) to distinguish variants (though such information can be manually included as an additional field).

This approach usually requires that the expected variant is assumed/asserted when accessing it from the union value.

Upper Right: Union Types

Other languages provide union types where the definition of the union type (Pet) refers to existing types in scope for its variants (Cat and Dog).¹

type Pet = Cat | Dog
let pet: Pet = Cat("Molly", 9)

A value of such a union does not contain metadata (runtime tags) to tell its variants apart.

Lower Left: Discriminated Unions

A “traditional” discriminated union definition as it exists in various languages defines both the enum itself (Pet), as well as its variants (Cat and Dog).

enum Pet {
  Cat(name: String, lives: Int),
  Dog(name: String, age: Int)
}
let pet: Pet = Cat("Molly", 9)

A discriminated union value contains a tag to allow telling its variants apart – even in cases where the types are them same (such as in Result[String, String]).

Lower Right: ?

The combination of unions with runtime tag but without syntactic wrapping has existed in various languages, though no common, language-spanning name has been established for this concept.

“United modes” in Algol 68:

STRUCT Cat (STRING name, INT lives);
STRUCT Dog (STRING name, INT years);
MODE Pet = UNION (Cat, Dog);

Unions in core:

class Cat(name: String, lives: Int)
class Dog(name: String, years: Int)
union Pet of Cat, Dog

“Nominal union types” as proposed for C# 15:

public record Cat(string Name, long lives);
public record Dog(string Name, long years);
public union Pet(Cat, Dog);

All these define a union Pet that refers to existing types Cat and Dog.

An instance of Cat can be directly assigned to pet (of union type Pet) – without syntactic wrapping:

// core
let pet: Pet = Cat("Molly", 9)

Intuitively, this works similarly to permits clauses of sealed interfaces in Java in the sense that

sealed interface Pet permits Cat, Dog { ... }

does not define Cat or Dog, but refers to existing Cat and Dog types in scope.²

Benefits of such unions

Union variants have types, because they have a “real” class/struct/… declaration.
(This fixes a mistake that some languages like Rust or Haskell made with their enum/data types.³⁴)
Variants can be reference types or value types (as they refer to “real” class or value definitions).
No “stutter”, where variant names have to be invented to wrap existing types. (Rust has this issue.)
Union values can be passed/created more easily, as no syntactic wrapping is required.
Variants can be re-used in different unions.
The ability to build ad-hoc unions out of existing types obviates the need for a separate type alias feature.

Example for 1., 2., 3.

enum Option[T] { Some(value: T), None }

… would receive little benefit from being written as …

union Option[T] of Some[T], None
value Some[T](value: T)
module None

…, but even trivial types like a JSON representation would benefit.

Instead of …

enum JsonValue {
  JsonObject(Map[String, JsonValue])
  JsonArray (Array[JsonValue]),
  JsonString(String),
  JsonNumber(Float64),
  JsonBool  (Bool),
  JsonNull,
  ...
}

… one would write (with Array, Float64 and String being existing types in the language):

union JsonValue of
  Map[String, JsonValue]
  Array[JsonValue],
  String,
  Float64
  Bool,
  JsonNull,
  ...

module JsonNull

Example for 4.

No wrapping required when passing arguments (unlike “traditional” enum approaches):

fun someValue(value: JsonValue) = ...
someValue(JsonString("test")) // "traditional" approach
someValue("test")             // proposed union design

Example for 5.

Consider this class definition:

class Name(name: String)

With the proposed union design, Name can be used multiple times – in different unions (and elsewhere):

union PersonIdentifier of
  Name,
  ... // other identifiers like TaxId, Description, PhoneNumber etc.

union DogTag of
  Name,
  ... // other identifiers like RegId, ...

This kind of union design reduce indirection at use-sites and can be used in more scenarios (compared to more “traditional” enums), while not changing their runtime costs or representation.

type Num = Int | Int does not allow detecting whether an Int instance is the first or the second variant; the definition is equivalent to type Num = Int ↩
Unlike sealed interfaces in Java though, in the proposed union design Cat and Dog are not subtypes of Pet. ↩
Types for enum variants ↩
Enum variant types ↩

Language Design: Annotations Obsolete Modifiers

Wed, 15 Dec 2021 00:00:00 +0000

TL;DR: If your language has annotations¹, it doesn’t need modifiers. Drop modifiers.

Modifiers (such as public, static or abstract) were traditionally built into languages; as keywords, they were part of the core language syntax.

Annotations (such as @deprecated, @test, @derive) are usually defined in libraries; similar to a class or interface, there exists a source file that defines each annotation.

Motivating Example

Consider this code example containing a variety of annotations – some of which would have been modifiers in older languages:

@open @deprecatedOpen("stop extending this class!", "1.2")
@derive[Stringable] // a person can be converted to a string
class Person(let firstName: String, let lastName: String, let age: Int32)
  @final
  fun isAdult: Bool = age >= 18

  @deprecated("use `!isAdult` instead", "1.0")
  fun isKid: Bool = age < 18

  @inline(ALWAYS)
  fun name: String = "$firstName $lastName"

Benefits

Increased language hygiene

Dropping modifiers and only using annotations avoids having two language constructs (modifiers and annotations) that serve largely the same purpose: refining the semantics of language building blocks like type or function definitions.

This also obviates having to think which behaviors deserve (or need) to be modifiers and which can exist as an annotation “only”.

Improved compatibility through namespacing

As annotations are defined as code in regular source files, they are namespaced.

This means that – unlike keywords that exist “globally”² – introducing a new annotation does not break existing code.

Paths for language evolution & migration

Annotations are easier to evolve than modifiers. Example: the implementation of @private visibility had a bug? Fix it, then add a default parameter to the annotation, such that developers can opt into the old behavior:

-- annotation private
++ annotation private(check = Strict) // Strict fixes bug
...
...
-- @private
++ @private(Lenient) // fix this later
   fun foo ...

For larger changes, it is also possible to leverage the namespaced nature of annotations:

An older language version may import its annotations from a lang.v1 namespace, while a newer language version might use the lang.v2 namespace in which the behavior of some annotations has changed.

This preserves the semantics of existing compiled artifacts and allow mixing new and old artifacts.

Language future-proofing

Even if the language compiler/runtime makes a distinction between “language-powered” annotations (that originated as modifiers) and user-supplied annotations, putting modifiers and annotations on equal footing syntactically allows extension of their capabilities later on, for instance by carefully exposing compiler APIs for annotations to hook into.

Drawbacks

Harder bootstrapping

Bootstrapping the language and the compiler requires more attention:

As annotations crucial to language semantics have an immediate effect on the interpretation of source code (such as “static”-ness, or the visibility of types and members), handling annotations as early as possible in the compilation pipeline is important.

Introducing a keyword to define annotations (e. g. annotation, similar to class for classes or trait for traits) is strongly recommended.³

High syntax requirements

Lightweight use-site syntax (like @) is required, as even moderate syntax costs (like #[...] in Rust) may feel “too much” for its intended use as a replacement for modifier syntax.

Some languages like C, C++, C# and Rust use the name “attribute” for annotations. ↩
Except “contextual” keywords, that are only considered keywords in certain contexts (and identifiers in all other places). ↩
As a cautionary tale, annotations in Scala were classes that implemented scala.annotation.Annotation, forcing the compiler to traverse and resolve the parent types of a type definition to determine whether some class was actually an annotation. ↩

Language Design: Annotations Obsolete Modifiers – Failed Attempts

Wed, 15 Dec 2021 12:00:00 +0000

Kotlin

Kotlin gave up on it, as they couldn’t figure out how to recognize annotation usages as early in the compiler pipeline as modifiers previously.

This lead to the determination that modifiers (without the prefix @) had to stay, but annotations would not always be able to omit the prefix @, leading to inconsistencies.

Ceylon

Ceylon tried the route in which everything is an annotation, but looks like a modifier (i. e. without prefix @).

This made it hard to distinguish between important keywords, and less important annotations.

Language Design: Against Mixed-cased Type Names

Sun, 05 Jun 2022 10:00:00 +0000

There is no good reason¹ why some type names need to start with a lower-case letter (int, float, str, …) and others with an upper-case letter (String, BigInt, Array, …).

Instead: Pick one naming rule, and stick to it while building your language.

¹Stupid Reasons

fAmiLiAriTy
But types with lower-cased names are “primitives”!!1!
Akkkchually, they aren’t lower-cased type names, they are keywords for types!

Library Design: Naming Conventions – Part 4: Lookup

Tue, 07 Jun 2022 00:00:00 +0000

Function Name	Code Example	Explanation
–	List(12.3, 45.6)(0) --> Some(12.3) Map("key", "val")("key") --> Some("val")	retrieves the value at the given index/key
`at(idx)`	Array(12.3, 45.6).at(1) --> Some(Ref(arr, 1))	returns a reference to the given position in the array
`contains(val)`	List(1.0, -0.0, NaN).contains(0.0) --> true List(1.0, -0.0, NaN).contains(NaN) --> true Map("key", "val").contains("key") --> true	checks whether container contains a value, as determined by either equality (`==`) or identity (`===`)
`includes(val)`	List(1.0, -0.0, NaN).includes(0.0) --> true List(1.0, -0.0, NaN).includes(NaN) --> false Map("key", "val").includes("key") --> true	checks whether container includes a value, as determined by equality (`==`)
`has(val)`	List(1.0, -0.0, NaN).has(0.0) --> false List(1.0, -0.0, NaN).has(NaN) --> true Map("key", "val").includes("key") --> true	checks whether container has a value, as determined by identity (`===`)
`findFirst(pred)`	List(3, 1, 2, 3).findFirst(_ < 3) --> Some(1)	find first value in container that satisfies the provided predicate
`findLast(pred)`	List(3, 1, 2, 3).findLast(_ < 3) --> Some(2)	find last value in container that satisfies the provided predicate

Library Design: Naming Conventions – Part 5: Streaming

Wed, 08 Jun 2022 00:00:00 +0000

Projections

Function Name Code Example Explanation

map(<fun>) List(1, 2, 3).map(_ + 1) --> List(2, 3, 4) Returns a stream in which fun is applied to each element.

Function Name	Code Example	Explanation
`map(<fun>)`	List(1, 2, 3).map(_ + 1) --> List(2, 3, 4)	Returns a stream in which `fun` is applied to each element.
`mapMany(<fun>)` ~~`mapMulti`~~ ~~`flatMap`~~ ~~`mapFlat`~~ ~~`mapAndFlatten`~~	List(1, 2).mapMany(x -> List(x, x)) --> List(1, 1, 2, 2) List(1, 2).mapMany(x -> Some(x)) --> List(1, 2) List(1, 2).mapMany(x -> None) --> List()	Returns a stream in which `fun` is applied to each element, producing a sequence of elements that is subsequently flattened.

mapMany(<fun>)

~~mapMulti~~

~~flatMap~~

~~mapFlat~~

~~mapAndFlatten~~

List(1, 2).mapMany(x -> List(x, x)) --> List(1, 1, 2, 2) List(1, 2).mapMany(x -> Some(x)) --> List(1, 2) List(1, 2).mapMany(x -> None) --> List()

Returns a stream in which fun is applied to each element, producing a sequence of elements that is subsequently flattened.

Filters

Function Name	Code Example	Explanation
`first`	List(1, 2, 3).first --> Option(1)	Returns the first element of the stream.
`last`	List(1, 2, 3).last --> Option(3)	Returns the last element of the stream.
`retainFirst(<num>)` ~~`take`~~ ~~`keep`~~ ~~`pick`~~	List(1, 2, 3, 4).retainFirst(2) --> List(1, 2)	Returns a stream that produces the first `num` elements of the input stream.
`retain(<pred>)` ~~`accept`~~ ~~`select`~~ ~~`filter`~~	List(1, 2, 3, 1).retain(_ < 2) --> List(1, 2, 1)	Returns a stream that produces only elements for which `pred` evaluates to `true`. Alternatives considered: `filter` is a poor name as it's unclear (especially for non-native speakers) whether "filtered elements" are those retained, or those "filtered out". `accept` is not ideal, as the visitor pattern also makes use of this name. `select` is even less ideal, as SQL uses the name for a completely different purpose.
`retainIndex(<pred>)`	List("a", "b", "c").retainIndex(_ % 2 == 0) --> List("a", "c")	Returns a stream that produces only elements for which `pred` evaluates to `true`.
`retainWhile(<pred>)` ~~`takeWhile`~~ ~~`keepWhile`~~ ~~`pickWhile`~~	List(1, 2, 3, 1).retainWhile(_ < 3) --> List(1, 2)	Returns a stream that produces elements of the input stream until the `pred` evaluates to `false`.
~~`retainUntil(<pred>)`~~ ~~`takeUntil`~~ ~~`keepUntil`~~ ~~`pickUntil`~~	List(4, 3, 2, 4).retainUntil(_ < 3) --> List(4, 3)	Returns a stream that produces elements of the input stream until the `pred` evaluates to `true`. Redundant, equivalent to `retainWhile(pred.not)`.
`rejectFirst(<num>)` ~~`skip`~~ ~~`drop`~~	List(1, 2, 3, 4).rejectFirst(1) --> List(2, 3, 4)	Returns a stream without the first `num` elements of the input stream.
`reject(<pred>)` ~~`filterNot`~~	List(1, 2, 3, 1).reject(_ < 2) --> List(3)	Returns a stream that produces only elements for which `pred` evaluates to `false`. Alternatives considered: `filterNot` is a poor name as it's unclear (especially for non-native speakers) whether "filtered elements" are those retained, or those "filtered out".
`rejectIndex(<pred>)`	List("a", "b", "c").rejectIndex(_ % 2 == 0) --> List("b")	Returns a stream that produces only elements for which `pred` evaluates to `false`.
`rejectWhile(<pred>)` ~~`skipWhile`~~ ~~`dropWhile`~~	List(2, 3, 4, 1).rejectWhile(_ < 2) --> List(3, 4, 1)	Returns a stream that skips elements of the input stream until `pred` evaluates to `false`.
~~`rejectUntil(<pred>)`~~ ~~`skipUntil`~~ ~~`dropUntil`~~	List(3, 2, 1, 4).rejectUntil(_ < 2) --> List(1, 4)	Returns a stream that skips elements of the input stream until `pred` evaluates to `true`. Alternatives considered: Redundant, equivalent to `rejectWhile(pred.not)`.
`distinct`	List(1, 2, 3, 1).distinct --> List(1, 2, 3)	Returns a stream that produces only the first occurrence of elements occurring multiple times.

Folds

Function Name	Code Example	Explanation
`fold(<num>, <start>)`
`reduce(<fun>)`
`combine[Monoid]`
`sum[Numeric]`	List(1.0, 2.0, 3.0, 4.0).sum --> 10.0	Computes the sum of the list of numbers.
`product[Numeric]`	List(1.0, 2.0, 3.0, 4.0).product --> 24.0	Computes the product of the list of numbers.
`average[Numeric]`	List(1.0, 2.0, 3.0, 4.0).average --> 2.5	Computes the average of the list of numbers.
`all(<pred>)` ~~`forAll`~~		Returns `true` if `pred` returns `true` for all elements.
`any(<pred>)` ~~`forAny`~~		Returns `true` if `pred` returns `true` for any element.
`none(<pred>)` ~~`forNone`~~		Returns `true` if `pred` returns `false` for all elements.

Injects

Function Name	Code Example	Explanation
`joinInner[Record]`
`joinLeft[Record]`
`joinRight[Record]`
`joinFull[Record]`
`groupBy(<fun>)`
`partitionBy(<fun>)`

Fan-Ins

Function Name	Code Example	Explanation
`concat`		Returns a stream that produces the values from the first stream and then the values of the second stream.
`interleave`		Returns a stream that produces a value, alternating between the first and second stream. Likely requires multiple method variants that handle streams of different lengths in different ways.
`zip`		Returns a stream that produces a tuple value, where the first element is from the first stream and the second element is from the second stream. Likely requires multiple method variants that handle streams of different lengths in different ways.
`zipWithIndex`		Returns a stream that produces a tuple value, where the first element is from the stream and the second element is the index at which the value was produced.

Language Design: Equality & Identity – Part 6: Fixing Rust

Thu, 09 Jun 2022 00:00:00 +0000

Rust designers recognized the issues with Haskell’s approach, but were not able to address the issues with Rust’s Eq and PartialEq traits.

The main cause of this failure is the sub-typing relationship between PartialEq and Eq:

It requires that an implementation of partial order is consistent with an implementation of total order.

This works for many types, but not for floating point types, for which the IEEE754 standard specifies a partial order as well as a total order.

The easiest solution for Rust would have been to not introduce the sub-typing relationship between PartialEq and Eq (as well as between PartialOrd and Ord).

Language Design: Familiarity – Familiarity is a tie-breaker, not a self-sufficient argument

Fri, 10 Jun 2022 00:00:00 +0000

In the past, many languages did not pick up easily adoptable language design improvements and opted for familiarity instead, often in a misguided attempt to keep perceived language complexity down.

Examples include¹:

C’s broken operator precedence² spread to many other languages, most of whom have little in common with C.
C++’s use of <> for generics, which was adopted by languages that – unlike C++ – had better options available.³
C#’s design of properties, picked up by languages that did not suffer from C#’s legacy of fields and methods.⁴

The benefits of familiarity (“it is easy, because I have seen it before”) are limited to those who “have seen it before”, while the benefits of simplicity (“it is easy, because it was designed this way”) apply to everyone, regardless of experience, schooling or development history.⁵

Therefore, it’s best to treat familiarity as a tie-breaker: to be used sparingly, only when the pros and cons of different design options have been fully explored, and it has been determined that no design has an edge above the other.

But if one design has arguments for it, and another design has only familiarity on its side, language designers of the future are implored to pick the former to stop propagating the same language design mistakes further and further into the future.⁶

see also Popular, but Wrong ↩
see Hundred year mistakes ↩
see Stop Using <> for Generics ↩
see Fields & Methods & Properties? – Pick Two! ↩
confusing them is an easy, but dangerous mistake to make, example ↩
The target audience of this footnote probably hasn’t made it this far before losing their mind, but to clarify: Nobody is planning on making you code in GIMP, all I’m saying is that some language decisions made in the 1970ies (with little thought on design) could perhaps benefit from some scrutiny before copying them into new languages verbatim. ↩

Language Design: Fields & Methods & Properties? – Pick Two!

Thu, 07 Jul 2022 00:00:00 +0000

TL;DR: Properties are a hack employed to retrofit “nice” syntax into languages that already shipped with fields and methods. Instead, design the language to deliver the same (or more) benefits with fields!

Why do properties exist?

The core feature of properties, in rough terms, is that (unlike getters and setters) property invocations look like field access, but retain the possibility to add logic that is executed on access at a later date (unlike fields).

Examples of Languages with properties

C#

C# popularized properties when it shipped them in version 1, and extended their feature set in subsequent versions (auto-implemented properties in C# 3, initializers in C# 6, expression-bodied members in C# 7).

public class Person {
  public string firstName { get; set; }
}

This means that – instead of e. g. person.getFirstName() – users can write person.firstName.

In C#, this is not perfect: changing a field to a property is source compatible, but not binary compatible; and changing a getter/setter pair to a property is neither.

Kotlin

TODO: fields vs. properties vs. methods

poorly copied from C#
large regression from Scala

Swift

TODO: stored properties vs. computed properties vs. methods

slightly better syntax than C#
still a large language complexity footprint

The problem with properties

Conceptually, it’s a bit icky that languages feature three constructs to define members that fundamentally only express two categories: members that store (“fields”) and members that compute (“methods”).

All three (fields, methods, properties) compete for the same syntactic sweet-spot and pollute the mental model – as they can be thin wrappers around their storage (“auto-implemented properties” in C#, “stored properties” in Swift), or contain complex custom logic (non-“auto-implemented properties” in C#, “computed properties” in Swift).

Which desirable characteristics should fields/methods/properties language provide?

“Nice” syntax at use- and declaration-site.
Evolving access should be source- and binary-compatible.
Users should be able to see whether they are accessing a value directly, or whether computation will occur during access.

How to deliver these characteristics without needing fields, methods and properties?

Use keyword-based syntax to distinguish between fields and methods.
- This means that methods without parameters do not need to require () to distinguish them from fields.
Define that members live in the same namespace.
- This prohibits a type containing a field and a method with the same name.
Implement late(-enough) binding of member invocations.
- This avoids encoding field/method invocation differences into call sites.
Expose the difference between a field and a method invocation through the use of colors in the IDE.
- This preserves important information (compared to properties or explicit getter/setter calls).

How to replace property getters with fields and methods?

Consider a class definition with one field (name) and two methods (firstName and lastName) …

class Person(let name: String)
  fun firstName: String = this.name.split(" ").get(0)
  fun lastName:  String = this.name.split(" ").get(1)

… and its usage:

let person = Person("Jane Doe")
person.name       // "Jane Doe"
person.firstName  // "Jane"
person.lastName   // "Doe"

As a mental model, a desugared encoding of Person’s name value could look like this:

class Person(name: String)
  @private
  let _name: String = name
  fun name: String = self._name
  ... /* other methods, as in the last example */

If the Person class definition was now changed to contain two fields and one method …

class Person(let firstName: String, let lastName: String)
  fun name: String = this.firstName + " " + this.lastName

… code using the class should not require changes, except adjusting the constructor call:

let person = Person("Jane", "Doe")
person.name       // "Jane Doe"
person.firstName  // "Jane"
person.lastName   // "Doe"

Still, users of the class can see what’s happening when they access Person’s members, because the IDE can use different colors to mark fields (keyword let) and methods (keyword fun).

How to replace property setters with fields and methods?

While mutability is on its way out, and the benefits of this approach are less pronounced for property setters, let’s review an example that demonstrates how property setters can also be replaced with fields and functions:

class Wine(let name: String, var rating: In64)

As a mental model, a desugared encoding of Wine’s rating variable could look like this:

class Wine(let name: String, rating: Int64)
  @private
  var _rating: Int64 = rating
  fun rating: Int64 = self._rating
  fun setRating(newRating: Int64) = self._rating = newRating

Instead of a special property syntax like set; or a @setter("rating") annotation, it’s possible to define some slight syntactic sugar for methods starting with set:

x.setY(z) can be written as x.y = z

This is very similar to the desugaring rules used for indexing operations (x.get(y) can be written as x(y), and x.set(y, z) can be written as x(y) = z).

It is used like this:

let wine = Wine("Schatoh-la Fid", 96)
wine.rating       // 96
wine.rating = 97  /* same as `wine.setRating(97)` */

To add additional checks when setting a new value (which is a popular use-case for property setters), we explicitly define a setRating method:

class Wine(let name: String, var rating: Int64)
  fun setRating(newRating: Int64) =
    require(newRating >= 0 && newRating <= 100, s"rating must be between 0 and 100, but was $newRating")
    self.rating = newRating

It is used like this:

let wine = Wine("Schatoh-la Fid", 96)
wine.rating       // 96
wine.rating = 97
wine.rating = -1  /* fails */

But now we realize, that – to protect our new invariant – we also want to run this check on construction, so we refactor:

class Wine(let name: String, var rating: Int64)
  checkRating(rating)

  @override
  fun setRating(newRating: Int64) =
    checkRating(newRating)
    this.rating = newRating

  fun checkRating(newRating: Int64) =
    require(newRating >= 0 && newRating <= 100, s"rating must be between 0 and 100, but was $newRating")

At this point, the use of (property) setters becomes questionable, as more mutable members mean more checks that we need to be called at all the right places. Instead, consider this:

value Rating(let value: Int64)
  require(value >= 0 && value <= 100, s"rating must be between 0 and 100, but was $value")

class Wine(let name: String, var rating: Rating)

let wine = Wine("Schatoh-la Fid", Rating(96))
wine.rating               // Rating(96)
wine.rating = Rating(97)
wine.rating = Rating(-1)  /* fails */

This preserves the simplicity of the Wine class definition, and moves the verification of the rating to its own type, making it easier to ensure all invariants are preserved.

What about method references?

Allowing method definitions/invocation without () poses the question of “how to handle method references?”.

There are three options:

Type inference

The meaning of person.firstName depends on the expected type, i. e.
```
 fun foo(s: String) = ...
 foo(person.firstName)
```
evaluates person.firstName, while
```
 fun bar(f: () => String) = ...
 bar(person.firstName)
```
passes a method reference to bar. This approach likely requires picking one choice as a default if there is no expected type, as well as type annotations if the type is ambiguous.
Explicit lambda syntax

Instead of dealing with type inference and ambiguity, person.firstName could be specified to always evaluate, requiring the use of a lambda for bar.
```
 fun bar(f: () => String) = ...
 bar(() => person.firstName)
```
Reference syntax

Special syntax could be introduced to create references from methods:
```
 fun bar(f: () => String) = ...
 bar(person::firstName)
```
This approach is especially interesting if the language has other program elements for which a “reference” syntax could also be beneficial, as it could replace special constructs like Java’s String.class or C#’s typeof(String).

Coda

With this design, we have accomplished more than languages with properties, while also avoiding the complexity of having fields and methods and properties.

Language Design: The Cost of Everything

Thu, 07 Jul 2022 11:00:00 +0000

Merit Points	Item
-100	Adding a language feature to do something that can already be done
-90	Adding a language feature to do something that can be implemented in a library
-80	Adding a language feature to do something that can be achieved by fixing a compiler bug
-70	Adding a new element to the global namespace
-60	Adding a new element to a `util` namespace
-20	Adding a new element to the standard library

Language Design: Useful Syntax Sugar

Sun, 10 Jul 2022 00:00:00 +0000

`get` sugar

Rule

x.get(y) can be written as x(y)

Explanation

Instead of special-purpose syntax that is used for indexing operations (reading) in many languages, like

int firstValue = someArray[0];

one can write

let firstValue = someArray(0)
/* same as */
let firstValue = someArray.get(0)

assuming a definition like

class Array[T]
  fun get(idx: Int64): T = ...

In combination with varargs, it can also replace special-purpose syntax used to construct various data structures.

Instead of e. g.

int[] someArray = int[] { 1, 2, 3 };

one can write

let someArray = Array(1, 2, 3)
/* same as */
let someArray = Array.get(1, 2, 3)

assuming a definition like

module Array
  fun get[T](vals: T*): Array[T] = ...

Of course Array is just one example; this rule applies to other data structures and use-cases equally:

let countriesAndCapitals =
  Map("France" -> "Paris", "Germany" -> "Berlin", ...)
countriesAndCapitals("France") // "Paris"

let baroqueComposers = Set("Bach", "Händel", "Vivaldi", ...)
baroqueComposers("Rammstein")  // false 

`set` sugar

Rule

x.set(y, z) can be written as x(y) = z

Explanation

Instead of special-purpose syntax that is used for indexing operations (writing) in many languages, like

someArray[0] = 23;

one can write

someArray(0) = 23
/* same as */
someArray.set(0, 23)

assuming a definition like

class Array[T]
  fun set(idx: Int64, val: T): Unit = ...

Of course Array is just one example; this rule applies to other data structures and use-cases equally:

let countriesAndCapitals =
  Map("France" -> "Paris", "Germany" -> "Berlin", ...)
countriesAndCapitals("England") = "London" // new entry added

let baroqueComposers = Set("Bach", "Händel", "Vivaldi", ...)
baroqueComposers("Monteverdi") = true      // new entry added

`set...` sugar

Rule

x.setY(z) can be written as x.y = z

Explanation

Instead of special-purpose syntax for properties and their setters, like

struct Rating {
  int value {
    get { return value; }
    set {
      if (value < 0 || value > 100)
        throw new ArgumentOutOfRangeException();
      this.value = value;
    }
  }
}

someRating.value = 97;

one can keep writing

someRating.value = 97

assuming a definition like

struct Rating(var value: Int32)
  fun setValue(val: Int32) = ...

but does not have to pay the complexity cost of adding properties to the language.

Language Design: Schemas as Source Code

Sat, 06 Aug 2022 00:00:00 +0000

TLD;DR: Your compiler should treat schema definitions as a valid (alternate) source syntax of your programming language.

What’s the goal

Failed Alternatives

poorly integrated source generation
compiler plugins
macros/type providers
annotating program texts

Language Design: Typing Terminology

Sat, 06 Aug 2022 00:00:00 +0000

Most people think only in terms of the dichotomy between Nominal-Manifest-Static-Strong and Structural-Inferred-Dynamic-Weak in any given discussion of programming language type system design. And it is exhausting.

(from what does strong and weak typing mean to you)

Most individual distinction are a scale, not a strict yes/no checkbox. (inspiration)

Typed ⟷ Untyped (Typing Modality/Presence)

A typed language allows analysis of the program text and rejection of certain programs, without executing them. Untyped (sometimes also called “dynamic”) programming languages lack this facility.

More Static: Haskell, CommonLisp
More Untyped: SmallTalk, Scheme, JavaScript

Manifest ⟷ Inferred (Typing Apparency)

It describes the degree to which types need to mentioned in the program text.

More Manifest: Java, C
More Inferred: OCaml, Haskell.

Nominal ⟷ Structural (Typing Morphology)

It pertains to how types are described and referred to and when they are judged equal.

More Nominal: Rust, D
More Structural: Ruby, OCaml.

→ Mention Java SAM types.

Reified ⟷ Erased (Typing Preservation)

A reified type system means that type information is preserved during compilation and available at run-time.

This enables runtimes to execute code more effectively and/or allows user-provided code to query type information as part of the program code.

Java: java.lang.reflect package, Object#getClass()
C#: Object#GetType()

Compile-time vs. Run-time Reflection?

~~ compile-time: required info is stored at call-site vs. run-time: required info is stored at declaration-site

Not directly typing related, but typing preservation choices have a direct impact on what’s possible. (Maybe as sub-point of reified vs. erased?)

vv Draft Space vv

Untyped Languages

Tagged ⟷ Untagged

→ cite Benjamin Pierce → cite Bob Harper: https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-are-static-languages/

Not really typing:

Strong ⟷ Weak (Typing Discipline/Value Convertibility)

which I think should be called Typing discipline because it pertains to the number of type errors you get (compile time or runtime, doesn’t matter.) Stronger: SML, Python, Weaker: JavaScript, C.

Language Design: `Result` naming

Mon, 31 Oct 2022 00:00:00 +0000

I was never too happy with the existing naming approaches for the Result type:

Success/Failure

pro: both names have the same length, like Option’s Some/None
con: quite long, concern that people may use Option over Result

Ok/Err

pro: short
con: names don’t have the same length, leading to inconsistent indentation when pattern matching
con: Err is not a word

The new naming ticks all the boxes:

Pass/Fail

pro: both names have the same length
pro: same length as Some/None
pro: real words

It’s a minor thing, but it’s nice to have found a good design even where it doesn’t matter that much!

The only concern I have is that I might find a type in a testing-related context where Pass/Fail would fit even better!

Language Design: Unified Condition Expressions – Comparison with Rust

Mon, 07 Nov 2022 00:00:00 +0000

simple if expression

if x == 1.0 { "a" }
else        { "z" }

This translates straight-forward to Rust:

if x == 1.0 { "a" }
else        { "z" }

multiple cases, equality relation

if x
... == 1.0 { "a" }
... == 2.0 { "b" }
else       { "z" }

In Rust, using match is idiomatic:

match x {
  1.0 => "a",
  2.0 => "b",
  _   => "z"
}

multiple cases, any other relation

if x
... == 1.0 { "a" }
... != 2.0 { "b" }
else       { "z" }

Rust requires the use match with guards (match on its own only supports equality relations), or an if expression:

match x {
  1.0 => "a"                           if x == 1.0      { "a" }
  x if x != 2.0 => "b"                 else if x != 2.0 { "b" }
  _ => "z"                             else             { "z" }

multiple cases, method calls

if x
... .isInfinite { "a" }
... .isNaN      { "b" }
else            { "z" }

In Rust one would use match with guards, or an if expression:

match x {
  x if x.is_infinite() => "a"          if x.is_infinite() { "a" }
  x if x.is_nan() => "b"               else if x.is_nan() { "b" }
  _ => "z"                             else               { "z" }
}

“if-let”, statement¹²

if opt_number is Some(i) { /* use `i` */ }

Rust requires a special construct to pattern match or introduce bindings:

if let Some(i) = opt_number { /* use `i` */ }

“if-let”, expression¹²

let result = if opt_number
  is Some(i) { i }
  else       { 0 }

Rust uses the let-equals-if-let-equals pattern:

let result = if let Some(i) = opt_number {
  i
} else {
  0
}

“if-let” chains³

let result = if opt_number.contains(1.0) { 1.0 } else { 0 }

Rust proposes the if-let chains syntax:

let result = if let Some(i) && i == 1.0 = opt_number {
  i
} else {
  0
}

“let-else”⁴⁵

let i = if opt_number
  is Some(i) { i }
  else       { return 0 }

Rust’s let-else allows binding a fallible pattern without introducing nesting:

let Some(i) = opt_number else {
    return 0;
};

Rust if-let – https://doc.rust-lang.org/book/second-edition/ch06-03-if-let.html ↩ ↩²
Swift if-let – https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html ↩ ↩²
Rust if-let chains – https://github.com/rust-lang/rust/issues/53667 ↩
Rust let-else – https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#let-else-statements ↩
Swift guard-let – https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html ↩

Language Design: Drop `break` and `continue`

Sat, 10 Dec 2022 00:00:00 +0000

TL;DR: Optimize for the common case, not the exotic ones.

First of all: The argument is not that break and continue in loops aren’t …

useful
convenient
sometimes the best option
…

That’s not the argument being made. The argument that is being made is that break and continue are …

… optimizing for an infrequent special case …

Consider a codebase that contains 1000 loops.

Out of those 1000, 900 loops aren’t using break or continue.

Of the remaining 100 loops, perhaps 90 loops use break, and 10 loops use continue.

Of those 90 loops with breaks, 80 are easily convertible to equivalent code not using break.

Of the 10 loops with continues maybe 5 are easily convertible.

.------------------------------------------------.
| all loops                                      |
|                                                |
|                                            +---+
|                                            |   |
|                        loops with break--->|   |
|                                            +---+
|                     loops with continue--->|   |
'--------------------------------------------+---'

This means that out of 1000 loops, supporting break and continue focuses on making 1.5% of the loops more convenient, to the detriment of the other 98.5% of the loops.

… while worsening the general case!

What’s the detriment? The loss of the ability to read the head of the loop and know what’s going on (e. g. when the loop terminates), as the body of every loop could contain a break or continue:

while true { // is it really an endless loop? only way to find out is reading the whole loop body!
  ...
  if shouldBreak() {
    break;
  }
}

This inability is so ingrained in people, that they cannot fathom the mental load that gets removed when they do not have to keep “this loop may contain a break or continue” in the back of their head:

let continue = true
while continue { // loop head shows immediately when the loop terminates
  ...
  continue = shouldBreak().not
}

Conclusion

Dropping break and continue removes mental load from 98.5% of the loops that don’t use them, with the disadvantage that a few loops are now more painful to write.

That’s a good trade-off.

Time to wind down Rust feature development

Fri, 16 Dec 2022 00:00:00 +0000

TL;DR: Regardless on where you stand on the “Rust 2.0”, Rust’s current approach to language evolution is not sustainable.

Whenever a language considers adding a feature, the cost of having to remove the feature (for any reasons) should be factored in from the start.

In Rust case, where fixing pretty much any anything after release is close to impossible – that cost function goes toward infinity.

Looking at the last few years of feature additions I have issues coming up with a feature whose benefits are larger than its costs.

async/await: too early to tell whether it was actually worth it
if let: growing extensions proposals at an impressive rate

Language Design: Rust's Struct Initializer Syntax Was a Mistake

Wed, 20 Sep 2023 00:00:00 +0000

Rust has distinct syntactic facilities for …

invoking functions
initializing structs and enums
initializing tupled structs and enums

… that provide different affordances and features:

method arguments are positional and cannot be named
initializer arguments are named, and what looks like positional arguments is a special shorthand notation
initializer arguments for tuple structs and enums look like method arguments, but are initializer arguments without shorthand notation

The following example shows all three:

struct User {
  username: String,
  email: String,
  active: State,
  sign_in_count: u64,
}

struct State(bool); // tuple struct

fn user(username: String, email: String) -> User {
  User {
    username,
    email,
    active: State(true), 
    sign_in_count: 0,
  }
}

fn main() {
  user("Jane Example".into(), "jane@example.com".into());
}

The Problems

Some of the issues caused by Rust implementing “most features, half the time”:

Diverging Code Styles and Best Practices

The unwieldiness of struct initialization combined with the lack of named/default parameters has lead to diverging code styles and best practices – like constructor pattern, builders, option structs, default hacks) – for dealing with issues like “this thing has grown and is taking way too many parameters now”.

Every future language improvement/addition will change the scale slightly, causing churn due to another technique becoming the next “best practice”. (And most likely only apply to either struct/enum initializers or method calls, but not both.)

Needless Ambiguity

Using { for struct initialization also means that something as trivial as if foo { appears to be syntactically ambiguous.

(In Rust such code is always treated as a condition body, a struct initialization in this position would need to be enclosed in parentheses.)

Lack of Consistent Rules for Type Ascriptions

Using : for struct initialization means that it’s not possible to use : Foo as a type ascription. Languages from the 70ies managed to get this right, Rust somehow regressed on that, failing to ship type ascriptions and giving up on it after 8 years.

A Solution

What Rust should have done instead is to decide upon one ruleset that all those invocation follow, such as:

Function calls and struct/enum initializers use (), not a mix of {} and ().
Use = for passing actual values as named arguments, such that everything “just works” if default parameters were added in the future. (See the Appendix for an evaluation of available options.)
Use : only for type ascriptions.
Shorthand notation or positional arguments? Pick one.

Adapting the example code from above, the code would look like this:

struct User(
  username: String,
  email: String,
  active: State,
  sign_in_count: u64 = 0) // default parameter value

struct State(active: bool)

fn user(username: String, email: String) -> User {
  User(username, email, active = State(true)) // named parameter
}

fn main() {
  user("Jane Example".into(), "jane@example.com".into());
}

Appendix: A Detailed Look at the Role of `=`

How to distinguish between a variable assigment and a named parameter use inside a function invocation?

    fn someFunction(a: i64) { ... }
    let mut a = 12;
    someFunction(a = 23) // what does this mean?

Two points have to be considered here:

Reducing chances of mix-ups:
- Frequency: Are variable assignments within function calls or function calls with named parameters projected to be used more often?
- Intuitivity: How can the syntax be distributed to those two use-cases such that the choice makes intuitively sense from a user point-of-view?
Reducing the harm from mix-ups:
- Can code change meaning unexpectedly, e. g. when function parameters are renamed?

Option 1: Try to use the same syntax for both variable assigments and named parameters

This means that named parameters simply act like another scope in which identifiers are looked up.

The danger with this approach is that changing the name of a named parameter can silently change the meaning of callsites if a variable with the previously used parameter name happens to be in scope.

// named parameter, but if someFunction's parameter name changes,
// without the callsite being updated, it silently becomes an
// assignment instead of a compilation failure:
someFunction(a = 23)

It also means that variables with the same name as a parameter name cannot be assigned within a function call.

Option 2: Let variable assignments use the “good” syntax and give named parameters some “workaround” syntax

In this example, the workaround syntax for named parameters is a ., prefixed to the parameter name.

// variable assigment inside a function argument list,
// only works if assignment returns the assigned value
// (which is generally a bad idea):
someFunction(a = 23)

// named parameter, and if someFunction's parameter name changes,
// without the callsite being updated, it becomes a compilation failure:
someFunction(.a = 23)

Option 3: Let named parameters use the “good” syntax and give variable assignments some “workaround” syntax

Inside a functions argument list, the first level of = use is always a named parameter and never a variable assignment, even if some variable a would be in scope.

// named parameter, and if someFunction's parameter name changes,
// without the callsite being updated, it becomes a compilation failure:
someFunction(a = 23)

// variable assigment inside a function argument list,
// only works if assignment returns the assigned value
// (which is generally a bad idea):
someFunction(a = { a = 23 })

Library Design: Naming Conventions – Part 3: Option & Result

Fri, 05 Jul 2024 00:00:00 +0000

Many languages’ Option and Result types suffer from an organically-grown and therefore inconsistently named set of functions.

To avoid this, a simple naming scheme can be used to derive a full set of useful methods with predictable names for these types.

The examples below use variant names Some and None for Option, and variant names Pass and Fail for Result.¹

Naming Scheme

Given a function operating on Option[T] or Result[T, E] …

get... indicates a result type of T,
its lack indicates a result type of Option[T]/Result[T, E]
...Else indicates a closure argument,
its lack indicates an eagerly evaluated value
...Panic indicates a possibly panicking function,
its lack indicates a total function
additional combinator function names are adopted from Naming Conventions – Streaming as appropriate
where ...None or ...Fail variants indicate working on the error value instead of on the success value

Function Name	Code Example
`or`	Some(1).or(Some(2)) --> Some(1) None.or(Some(2)) --> Some(2) Pass(1).or(Pass(2)) --> Pass(1) Fail(1).or(Pass(2)) --> Pass(2)
`orElse`	Some(1).orElse(() -> Some(2)) --> Some(1) None.orElse(() -> Some(2)) --> Some(2) None.orElse(() -> None) --> None Pass(1).orElse(() -> Pass(2)) --> Pass(1) Fail(1).orElse(() -> Pass(2)) --> Pass(2)
`getOr`	Some(1).getOr(2) --> 1 None.getOr(2) --> 2 Pass(1).getOr(2) --> 1 Fail(1).getOr(2) --> 2
`getOrElse`	Some(1).getOrElse(() -> 2) --> 1 None.getOrElse(() -> 2) --> 2 Pass(1).getOrElse(() -> 2) --> 1 Fail(1).getOrElse(() -> 2) --> 2
`getOrPanic`	Some(1).getOrPanic() --> 1 None.getOrPanic() # program aborts Pass(1).getOrPanic() --> 1 Fail(1).getOrPanic() # program aborts
`getOrPanicWith`	Some(1).getOrPanicWith("expected some") --> 1 None.getOrPanicWith("expected some") # program aborts with message "expected some" Pass(1).getOrPanicWith("expected some") --> 1 Fail(1).getOrPanicWith("expected pass") # program aborts with message "expected pass"

Having variant names with the same length avoids pointless debates and diverging code style decisions on whether the arms of matches should be lined up or not. ↩

Language Design: Rust's Almost-Rules

Mon, 05 Aug 2024 00:00:00 +0000

(Inspired by Almost Rules.)

Syntax

`:` is followed by a type

except inside struct initializers, where it is followed by a value
except function result types, which are preceded by ->

generics use `<>`

except in expression contexts, which uses ::<>

invocations use `()`

except where {} or [] is used, because “they convey important information”
- except for macro invocations, where (), {}, [] are equivalent and interchangeable

`T {}` initializes a struct

except inside an if, where { starts a branch (see Rust’s Struct Initializer Syntax Was a Mistake)

types are uppercase

except “primitive” types
- except the primitive types array, slice, tuple and unit

Rust has no varargs

except for extern functions
except for macros

patterns introduce bindings

except in macro pattern matching, where the same syntax matches identifiers verbatim

Semantics

types with a total order implement `Eq` and `Ord`

except f64 and f32, which do not

struct initializers use temporary lifetime extension

except tuple structs
- except when using curly braces to initialize tuple structs

Language Design: Equality & Identity – Part 5: Fixing Java

Fri, 07 Mar 2025 00:00:00 +0000

The recent development of Java is an interesting case, as it faces these questions more acutely with the introduction of value types in Project Valhalla.

Recap

Java-before-value-types worked like this:

	==	Object#equals
primitive types (`int`, `float`, `byte`, …)	primitive equality	not available
reference types (`java.lang.Integer`, `java.lang.Float`, `java.lang.Byte`, …)	reference equality	value equality

Note that every primitive type has a reference-based “wrapper type” to which it can be converted.
When the compiler injects this conversion implicitly, it is called “auto-boxing”.

double d = 1.0;            // primitive value
1.0 == 1.0;                // primitive equality → true
Double D = d;              // auto-boxing the primitive value into its wrapper type
D == D                     // reference equality, same reference → true
D == new Double(1.0)       // reference equality, different reference → false
D.equals(new Double(1.0))  // value equality → true

Primitive equality of primitives behaves largely the same as the value equality of its wrappers, except for floating point values, where behavior differs for zero and not-a-number values:

0.0 == -0.0                               // true
new Double(0.0).equals(new Double(-0.0))  // false

Double.NaN == Double.NaN                               // false
new Double(Double.NaN).equals(new Double(Double.NaN))  // true

A (side-)effect of this is that a HashMap<Double> can reliably find entries, including ones with a NaN key.

What’s new

With Valhalla, Java …

allows programmers to define their own value types,
migrates primitive wrapper types into value types, and
defines == on value types to be a member-wise check for “sameness”.¹

This means that comparison between two wrapper values with the same wrapped value now always return true, including NaN values:²

	before Valhalla	after Valhalla
`new Double(Double.NaN) == new Double(Double.NaN)`	false	true
`new Double(Double.NaN).equals(new Double(Double.NaN))`	true	true

This allows a more efficient representation of previously boxed wrapper types, without introducing breaking changes.

“Two value objects are the same if they are instances of the same class and the values of their instance fields are the same.” (draft spec) ↩
“If a and b are variables storing the results of any two boxing conversions of p, then it is always the case that a.equals(b) and a == b.” (draft spec) ↩

Language Design: Multi-Color Number Literals

Sun, 08 Jun 2025 00:00:00 +0000

TLDR: Use multiple colors to make the various components of your number literals easily distinguishable.

Different colors for:

base prefix
type suffix
float exponent
digits value

Instead of:

Do:

soc.me

Language Design: Implicit Numeric Conversions

The Good: Intentions

The Bad: Type Inference

The Ugly: Extension Methods

The Worst: Having a Way Out, but not Choosing It

Bonus Quirk

Language Design: Fixing Rust's mistakes – Syntax

Drop {} struct initialization syntax

Named parameters using =

Use [] instead of <>/::<> for generics

Drop range syntax

Drop array and slice syntax

Fold Index and IndexMut into Fn trait family

Replace impl with purpose-focused alternatives

Stop using macros to emulate varargs

Drop ::

Drop as

Drop if-let

Drop procedure syntax

Drop -> in function signatures

Remove significance of semicola

Language Design: Generics

Language Design: Use `ident: Type`, not `Type ident`

1. Input before output

2. Consistency between definition and usage

3. Definition before usage

Language Comparison

Language Design: (More) Mistakes of Rust

Language Design: Equality & Identity – Part 1: Overview

Java

JavaScript

Rust

C#

Scala

Language Design: Equality & Identity – Part 2: Problems

Containment

Complexity

Language Design: Equality & Identity – Part 3: Solution

Defining Equality and Identity

How do equality and identity comparisons work?

Conclusion

Language Design: Package Objects in Scala

The Issue

The Solution

The Workaround

Language Design: Unified Condition Expressions – Introduction

Idea

Motivation

Observations

Considerations

Examples

simple if expression

a shared comparison operator for multiple condition continuations

different comparison operators for each condition continuation

method calls

pattern matching (is)

binding values

flow typing

pattern guards

replacement for “if-let”

Related Work

Language Design: Rust's Into in Scala

Rust’s Into

Translation into Scala

View Bounds

Context Bounds

Scala’s Into

Java’s Supplier

Summary

Language Design: Unified Condition Expressions – Exceptions

Library Design: Naming Conventions – Part 1: Creation

Modification

Library Design: Naming Conventions – Part 2: Conversion

Language Design: Use Consistent Keyword Length

Language Design: Comparing and Sorting

Language Design: Equality & Identity – Part 4: Fixing Haskell

Status Quo

Available Options

A Solution

Drop `{}` struct initialization syntax

Named parameters using `=`

Use `[]` instead of `<>`/`::<>` for generics

Fold `Index` and `IndexMut` into `Fn` trait family

Replace `impl` with purpose-focused alternatives

Drop `::`

Drop `as`

Drop `if-let`

Drop `->` in function signatures

pattern matching (`is`)

The problem with `&`

The problem with `<<`, `>>`, `>>>`

The problem with `%`

In most languages the `%` operator implements a remainder operation, not a modulo operation

1. `<>` is hard to read for humans

2. `<>` is hard to parse for compilers

Language Design: Fields & Methods & Properties? – Pick Two!