aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJJ2023-10-26 11:07:15 +0000
committerJJ2023-10-26 20:57:56 +0000
commit292d4c2748e06a639545ae23c9ee31360c3b76f3 (patch)
tree113cfc1a2be6d5adf2318caa54d80e86cfb8f327
parent3a25fa06d2cd9d2b89b68622415d7168cf06c0da (diff)
docs: update README
-rw-r--r--README.md61
1 files changed, 25 insertions, 36 deletions
diff --git a/README.md b/README.md
index 5830918..d026a6a 100644
--- a/README.md
+++ b/README.md
@@ -3,46 +3,44 @@
A place where I can make some bad decisions.
Puck is an experimental, memory safe, structurally typed, imperative and functional programming language.
-It aims to be clean and succinct while performant: having the flexibility/metaprogramming of [Nim](https://nim-lang.org/) with the error handling of [Swift](https://www.swift.org/) and the performance/safety guarantees of [Rust](https://www.rust-lang.org/).
-
-You may judge for yourself if Puck meets these ideals.
+It aims to be clean and succinct while performant: inspired by the metaprogramming of [Nim](https://nim-lang.org/), the error handling of [Swift](https://www.swift.org/), and the performance/safety guarantees of [Rust](https://www.rust-lang.org/).
```nim
import std/tables
-module AST:
+mod Ast:
pub type Value = interface
func repr(self: Self): string
pub type Ident = string
pub type Expr = ref union
- Literal: Value
+ Literal: ref Value
Variable: Ident
Abstraction: struct[param: Ident, body: Expr]
Application: struct[body, arg: Expr]
Conditional: struct
- cond, then_case, else_case: Expr
+ cond, then_branch, else_branch: Expr
- pub func eval(expr: Expr, context: var HashTable[Ident, ref Value]): Result[ref Value]
+ pub func eval(expr: Expr, context: var HashTable[Ident, Value]): Result[Value]
match expr
- of Literal(value):
- Okay(value)
- of Variable(ident):
- context.get(ident)
- of Application{body, arg}:
- if body of Abstraction{param, body as inner_body}:
- context.set(param, eval(arg))
- inner_body.eval(context)
- else:
- Error(InvalidExpr)
- of Conditional{cond, then_case, else_case}:
- if eval(cond, context):
- then_case.eval(context)
- else:
- else_case.eval(context)
- of _:
+ of Literal(value):
+ Okay(value)
+ of Variable(ident):
+ context.get(ident)
+ of Application{body, arg}:
+ if body of Abstraction{param, body as inner_body}:
+ context.set(param, eval(arg))
+ inner_body.eval(context)
+ else:
Error(InvalidExpr)
-
-AST.eval((λx.x) 413)
+ of Conditional{cond, then_branch, else_branch}:
+ if eval(cond, context):
+ then_case.eval(context)
+ else:
+ else_case.eval(context)
+ of _:
+ Error(InvalidExpr)
+
+Ast.eval("(λx.x) 413".parse(), HashTable.init())
```
## Why Puck?
@@ -54,8 +52,8 @@ That said: in the future, once somewhat stabilized, reasons why you *would* use
- The **syntax**, aiming to be flexible, predictable, and succinct, through the use of *uniform function call syntax* and significant whitespace
- The **type system**, being modern and powerful with a strong emphasis on safety, optional and result types, algebraic data types, and interfaces
- The **memory management system**, implementing a model of strict ownership while allowing individual fallbacks to reference counts if so desired
-- The **metaprogramming**, providing flexible 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 popular languages
+- 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 **effect system**, being one of few languages with a proper effects system based on handlers -->
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.
@@ -70,18 +68,9 @@ This is the language I keep in my head. It sprung from a series of unstructured
- The [asynchronous](docs/ASYNC.md) document gives an overview of the intertwining of Puck's asynchronous support with other language features.
- The [interop](docs/INTEROP.md) document gives an overview of how the first-class language interop system works.
- The [modules](docs/MODULES.md) document provides a more detailed look at imports and how they relate to the type system.
-<!-- - The [effect system](docs/EFFECTS.md) document gives a description of how Puck's effect handler system works. -->
- The [standard library](docs/STDLIB.md) document provides an overview and examples of usage of the standard library.
- The [roadmap](docs/ROADMAP.md) provides a clear view of the current state and future plans of the language's development.
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.
-
-## Acknowledgements
-
-First and foremost, this language is *heavily* inspired by Nim. Many ideas - general syntax, UFCS, even the design of the compiler - were taken 1:1.
-The error handling model, and purity system, were essentially directly lifted from Swift (and to an extent, Nim).
-The underlying type system is mostly copied from Rust, with significant changes to the interface (trait) and module system.
-The memory model is based upon similar successful models in Lobster, Nim, and Rust. Performance annotations are somewhat inspired by Nim.
-<!-- The effects system is unique, with inspiration from the few languages successfully implementing effects systems, namely Koka and Unison. -->