66 lines
2.3 KiB
Markdown
66 lines
2.3 KiB
Markdown
# 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.
|