aboutsummaryrefslogtreecommitdiff
path: root/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'README.md')
-rw-r--r--README.md13
1 files changed, 7 insertions, 6 deletions
diff --git a/README.md b/README.md
index d3e9757..19283ac 100644
--- a/README.md
+++ b/README.md
@@ -129,11 +129,11 @@ Puck is primarily a testing ground and should not be used in any important capac
Don't use it. Everything is unimplemented and it will break underneath your feet.
That said: in the future, once somewhat stabilized, reasons why you *would* use it would be for:
-- The **syntax**, aiming to be flexible, predictable, and succinct, through the use of *uniform function call syntax* and significant whitespace
+- The **syntax**, aiming to be flexible, predictable, and succinct, through the use of *uniform function call syntax*, significant whitespace, and consistent scoping rules
- The **type system**, being modern and powerful with a strong emphasis on safety, algebraic data types, optional and result types, first-class functions, generics, interfaces, and modules
- The **memory management system**, implementing a model of strict ownership with an optimized reference counting escape hatch
- The **metaprogramming**, providing integrated macros capable of rewriting the abstract syntax tree before or after typechecking
-- The **interop system**, allowing foreign functions to be usable with native semantics from a bevy of languages
+- The **interop system**, allowing foreign functions to be usable with native syntax/semantics from a bevy of other languages
This is the language I keep in my head. It sprung from a series of unstructured notes I kept on language design, that finally became something more comprehensive in early 2023. The overarching goal is to provide a language capable of elegantly expressing any problem, and explore ownership and interop along the way.
@@ -141,10 +141,11 @@ This is the language I keep in my head. It sprung from a series of unstructured
- The [basic usage](docs/BASIC.md) document lays out the fundamental semantics of Puck.
- The [syntax](docs/SYNTAX.md) document provides a deeper and formal look into the grammar of Puck.
-- The [type system](docs/TYPES.md) document gives an in-depth analysis of Puck's extensive type system. <!-- and its relationship to classes and other abstractions. -->
+- The [type system](docs/TYPES.md) document gives an in-depth analysis of Puck's extensive type system.
- The [modules](docs/MODULES.md) document provides a more detailed look at the first-class module system.
-- The [memory management](docs/MEMORY_MANAGEMENT.md) document gives an overview of Puck's memory model. <!-- which is considered a mashup of the models pioneered by Lobster, Rust, and Nim. -->
-- The [metaprogramming](docs/METAPROGRAMMING.md) document explains how using metaprogramming to extend the language works. <!-- and write more powerful code works. -->
+- The [error handling](docs/ERRORS.md) document gives a look at the various kinds of error handling available.
+- The [memory management](docs/MEMORY_MANAGEMENT.md) document gives an overview of Puck's memory model.
+- The [metaprogramming](docs/METAPROGRAMMING.md) document explains how using metaprogramming to extend the language works.
- The [asynchronous](docs/ASYNC.md) document gives an overview of Puck's colourless asynchronous support.
- The [interop](docs/INTEROP.md) document gives an overview of how the first-class language interop system works.
- The [standard library](docs/STDLIB.md) document provides an overview and examples of usage of the standard library.
@@ -154,7 +155,7 @@ These are best read in order.
Note that all of these documents (and parts of this README) are written as if everything already exists. Nothing already exists! You can see the [roadmap](docs/ROADMAP.md) for an actual sense as to the state of the language. I simply found writing in the present tense to be an easier way to collect my thoughts.
-This language does not currently integrate ideas from the following areas of active research: effects systems, refinement types, and dependent types. It plans to integrate refinement types in the future as a basis for `range[]` types, and to explore safety and optimizations surrounding integer overflow.
+This language does not currently integrate ideas from the following areas of active research: effects systems, refinement types, and dependent types. It plans to base (un)safety tracking, exception handling, and async/await on a future effects system. It plans to integrate refinement types in the future as a basis for `range[]` types, and to explore safety and optimizations surrounding integer overflow.
## Primary References
- [The Rust I wanted had no future](https://graydon2.dreamwidth.org/307291.html)