Define some broad goals/use cases about dyon

[bvssvni]

The primary domain I had in mind was game scripting. However, I did not have some large idea or vision when starting on it. It was just fun to work on. Here are some other thoughts I've had:

1. Make it ordinary first - in the sense of not having weird or fancy features
2. Tooling will be important - the language is not the only thing that makes it useful
3. Don't excuse the language - figure out what is the job of language design

Ordinary

I tried to think of language ideas where I had the feeling "oh, this was nice" but not be overwhelmed by new ideas. It should look familiar if you have used Rust, Go and Javascript. For example, Lua tables are nice but I like the distinction between arrays and objects in Javascript. Ordinary is also another way of looking at features that are comfortable in other languages. A language for doing stuff, not proving theorems.

Rust is a good language, but it is a bit heavy. I want something that integrates well with Rust, without being Rust. Dynamical types is very nice for reflection, where you can write code that operates on any object. For example, sending data across the network, or a property editor widget.

The lifetime checker is a separated step requiring some extra syntax, so if this idea gets in the way later we could try garbage collection instead. Maybe type checking also could be made this way.

Tooling

• By changing the meta syntax you can choose how the language looks like
• Saving the state of a running program, exiting and then reopening and continue where you were
• A way to use share data across multi-threads or multi-machine?
• Built-in support for meta parsing, since it can be used with many text formats

We need a way to organize the built-in functions so you can customize it for various game engines.

One idea I've had: A kind of browser, but with a game loop instead of HTML. Large standard library with game related features. Hyperlinks and ways to share and connect what other people make. You could open up stuff made with another syntax by sending the meta syntax with the code.

However, the browser idea might take a lot of work, so my goal now is to write a few small games with it.

Don't excuse the language

It seems very easy to try to find the easiest way to change a language in order to get a new feature. This could lead to some problems where you figure out a simple but flexible way of covering a lot of features. Then the language ends up with a meta language on top. I do not want a super flexible language, but practical and convenient for most common tasks (ordinary).

There are probably some tradeoffs to make, but I don't want to excuse the language and try to convince other people that some idea is the right way. It is either in the language or not, and if it is not then I don't want to take shortcuts.

[Aatch]

Hmm, that helps. I have some ideas I'll write up in separate issues.

I don't think allowing the syntax to be drastically altered is a good idea though. While it sounds appealing, I can't see it being anything but trouble. A language's syntax is an important aspect of the language, features can live or die depending on the syntax used to express them. I also don't think it's worth supporting, I can't see how it really adds anything except confusion.

The last part confuses me. I'm not sure what you're trying to say. I think you mean that you want the language to be focused, and that you don't want to add in features that don't support the language as a whole.

[bvssvni]

Hmm... good points. An added feature in one syntax might conflict with another.

You got the last part right.

[bvssvni]

Closing for now.