41 lines
1.5 KiB
Markdown
41 lines
1.5 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".
|