oden/fine/design.md

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

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.