Skip to content

Commit 69b13dd

Browse files
committed
Update docs
1 parent 8e4fa13 commit 69b13dd

1 file changed

Lines changed: 94 additions & 0 deletions

File tree

docs/blog.md

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
1+
---
2+
layout: default
3+
title: "GluonScript 0.4.0 released"
4+
nav_order: 4
5+
has_children: true
6+
---
7+
8+
# GluonScript 0.4.0
9+
10+
GluonScript 0.4.0 introduces several important improvements to the language and runtime. This release focuses on making error handling more ergonomic, expanding the standard functionality available to programs and improving interpreter performance and closure semantics internally.
11+
12+
## `?=` Error Propagation Operator
13+
14+
One of the biggest additions in this release is the new `?=` operator.
15+
16+
Functions that may fail in GluonScript commonly return a record in the following format:
17+
18+
```python
19+
{ error: Bool, value: Any }
20+
```
21+
22+
Checking these records manually quickly becomes repetitive. The new `?=` operator simplifies this pattern by automatically propagating errors.
23+
24+
Before:
25+
26+
```python
27+
result = http.get("https://example.com")
28+
29+
if result.error {
30+
return result
31+
}
32+
33+
content = result.value
34+
```
35+
36+
Now:
37+
38+
```python
39+
content ?= http.get("https://example.com")
40+
```
41+
42+
If `error` is `false`, the value in `value` is unwrapped and assigned to the variable on the left.
43+
44+
If `error` is `true`, the current function immediately returns the full error record, making error propagation concise and easy to read.
45+
46+
This feature was heavily inspired by Rust's `?` operator while still fitting naturally into GluonScript's existing conventions and simpler "Result" record.
47+
48+
## New `math` Module
49+
50+
Version 0.4.0 also introduces a new built-in `math` module containing common mathematical functionality:
51+
52+
`fn abs(number: Int | Float): Int | Float`
53+
`fn ceil(number: Float): Float`
54+
`fn cos(number: Int | Float): Float`
55+
`fn clamp(value: Int | Float, min: Int | Float, max: Int | Float): Int | Float`
56+
`fn floor(number: Float): Float`
57+
`fn max(a: Int | Float, b: Int | Float): Int | Float`
58+
`fn min(a: Int | Float, b: Int | Float): Int | Float`
59+
`fn round(number: Float): Float`
60+
`fn sin(number: Int | Float): Float`
61+
62+
The goal of this module is to provide convenient access to frequently used mathematical operations without requiring external dependencies.
63+
64+
The module will continue expanding in future releases.
65+
66+
## Runtime Improvements with `Rc<RefCell<Env>>`
67+
68+
Internally, the interpreter previously relied heavily on cloning scope environments during function calls and closure creation. While simple, this approach became undesired as the language evolved and gained more advanced closure support.
69+
70+
In 0.4.0 the runtime now uses:
71+
72+
```rust
73+
Rc<RefCell<Env>>
74+
```
75+
76+
This change significantly improves performance and lowers memory usage by reducing unnecessary environment cloning. All that is cloned now are references to parent scopes, instead of cloning the data structure holding the variables and functions (HashMaps).
77+
78+
In addition to this, closures now capture their surrounding environment by reference, instead of copying a snapshot like previously. This means that if a variable in a parent scope changes its value, this will now be seen by the closure. You can think of it like a live view to its parent scopes.
79+
80+
However, contrary to what you might expect coming from mainstream languages, closures cannot mutate the captured variables. This is a hybrid approach in line with the immutability philosophy followed by GluonScript. This makes sure closures cannot have side effects outside their scope, preventing a whole class of bugs and unexpected results.
81+
82+
## Looking Ahead
83+
84+
GluonScript continues evolving toward a small but expressive scripting language with a strong focus on simplicity, immutable data structures and pragmatic functional programming ideas, while equally supporting imperative styles.
85+
86+
Future work will likely focus on:
87+
88+
- Expanding the standard library
89+
- Refining module support
90+
- Improving interpreter performance
91+
- Additional language ergonomics
92+
- Documentation improvements
93+
94+
Thank you for following the project.

0 commit comments

Comments
 (0)