# 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:

``` rust
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:

``` rust
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".

## 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.
