Design Notes for the Fine Language

This language is being designed as I go, because the main thing I'm interested in is building something that's fun and productive for me personally. That means, rather than being super careful, I'm just building the thing that pleases me at any given moment.

Here are some notes. The notes are for me in the future, in case I'm wondering why the language is one way instead of another way.

The `new` keyword

I really like rust's "just use a type name with curly braces to construct new values". It's really clean! Unfortunately it leads to an ambiguity in the syntax that I don't like:

if something { ...

In the code above, after I have parsed something and I see {, am I:

Parsing an object construction expression for the type something?
Parsing something as a boolean value reference and { as the start of the block?

Naively you would expect the latter, but if I scan ahead a little more:

if something { foo: true }.foo { }

Rust does not allow struct literals in the condition of the if, which is correct, but that's more work than I want to do here. There's just a lot of context flowing around about whether or not I can parse a structure literal in any particular situation.

The new keyword is a compromise: we know that the context immediately following the new keyword is always a type expression, so we know that e.g. < or whatever means "generic type parameter" and not "less than".

Patterns and Alternate Types

Instead of enums or inheritance, we're using an alternate type like in Typescript, with or between types. See the alternates.fine test for a work-up of the types and syntax and whatnot. I think it works pretty well.

Actually using alternate types involves pattern matching, either one at a time, with the is operator, or in bulk, with the match expression. match can check for completeness, but if/is cannot.

Patterns are VERY simple, and are explicitly not destructuring right now. (Destructuring brings up a whole lot of complexity that I don't want to deal with.)

Patterns are basically:

(identifier ":")? type_expression ("and" <expression>)?

The identifier at the front represents a binding of the value being considered as if it were of the same type as the type expression; the identifier is in scope for the optional predicate after the "and" and so you can use it as if it were the type because, well, that part of the pattern already matched.

As a special case, the identifier is also in scope for the body of an if expression when an is expression is used as the condition.

  if b is c:Foo {
    result = result + c.a; // c should still be in scope!
  }

match is the multi-value pattern matching expression, like this:

  match b {
    c:Foo -> c.a,
    _ -> 0,
  }

The special pattern _ always evaluates to true.

Note that unlike rust we do not allow variable binding, e.g., in rust you can write:

  match b {
    d -> ...,
  }

but in fine you need to write:

  match b {
    d:_ -> ...,
  }

The reason is that the rust version is ambiguous: if d matches some value already in scope (e.g., an enum arm) then the arm is matching if b == d, but if d is unbound then d becomes a variable declaration. This is a spooky action-at-a-distance and I don't approve of it.

Complete Garbage

Lambdas/Closures/Anonymous Functions

Looking for a syntax here; I want to keep fun as a declaration like let and not let it enter the expression space. I don't like fat-arrow syntax because it makes expression parsing very ambiguous, potentially requiring a lot of lookahead. (TODO: Is that true?)

Maybe a leading character like \x => x+1 or \(x,y) => x+y?

Interfaces/Traits/Whatever

These are incomplete structural types. Methods are easier to make compatible than members, but members should also work so long as they are strict prefixes of the thing.

What about sound casting with narrowing? That's union types baby, do we really want those? It could be neat if we're doing otherwise structural-compatibility.

On Objects and Classes

Sometimes I think it should all be structural types.

Maybe later there can be anonymous types that match shapes.

4.2 KiB Raw Blame History