I’m planning on doing a release sometime this year, probably around Christmas. There have been some suggestions for language features and syntax changes that may be desirable, but might have a significant impact on how Kitten code is written. I don’t want to generate a lot of changes right now because we need to ensure the tooling and documentation deal adequately with the language as-is. So what I propose is that features like these be rolled out behind feature gates, under the name “language experiments”.
The plan is to voluntarily collect analytics about which language experiments are in popular use, and use that to democratically guide the design of the language and standard libraries; after some period of time, we may promote experiments with positive results to the core language, and do a deprecation and removal cycle for those with negative results.
Experiments affecting syntax and language semantics will be enabled by language pragmas, in the form of an about { … } block: as soon as the lexer reaches such a block, the feature will be enabled in that file for the remainder of compilation. This needs to be done as early as possible in the compiler pipeline, because language features may affect any stage of compilation.
Experiments in the common vocabulary will be enabled by importing features from a standard experimental namespace. For convenience, we might allow wildcard imports of experimental library features so they behave as if they were defined in the common vocab, even though wildcards will not be allowed for any other import.
I’m planning on doing a release sometime this year, probably around Christmas. There have been some suggestions for language features and syntax changes that may be desirable, but might have a significant impact on how Kitten code is written. I don’t want to generate a lot of changes right now because we need to ensure the tooling and documentation deal adequately with the language as-is. So what I propose is that features like these be rolled out behind feature gates, under the name “language experiments”.
The plan is to voluntarily collect analytics about which language experiments are in popular use, and use that to democratically guide the design of the language and standard libraries; after some period of time, we may promote experiments with positive results to the core language, and do a deprecation and removal cycle for those with negative results.
Experiments affecting syntax and language semantics will be enabled by language pragmas, in the form of an
about { … }block: as soon as the lexer reaches such a block, the feature will be enabled in that file for the remainder of compilation. This needs to be done as early as possible in the compiler pipeline, because language features may affect any stage of compilation.Experiments in the common vocabulary will be enabled by importing features from a standard
experimentalnamespace. For convenience, we might allow wildcard imports of experimental library features so they behave as if they were defined in the common vocab, even though wildcards will not be allowed for any other import.