SergeychWorks/lyng
1
0 Fork 0
Code Issues 2 Pull Requests Actions Packages Projects 1 Releases 21 Wiki Activity

1.1.1-SNPASHOT some serious bugs in initilazation fixed. They were revealed by delegation real world usage

Browse Source
This commit is contained in:
sergeych committed 2026-01-05 21:13:42 +01:00
1 parent 20f777f9f6
commit f792c73b8f
17 files changed
+283 -48
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/development/String.md
-28
View File
@@ -1,28 +0,0 @@
[//]: # (excludeFromIndex)
# String
# This document is for developer notes only
--------------------------
## Interpolation proposal
"""no $iterpolation"""
val inpterpolation1 = "foo"
"${interpolation1}"
>>> "foo"
"$interpolation2"
"no $$ interpolatino"
## Regexp vs div / ?
```EBNF
regex_literal = "/", { regchar }, "/", [ flag ]
foag = "i" | "n"....
regchar = x`x`
```
docs/development/including_modules.md
-45
View File
@@ -1,45 +0,0 @@
# Modules inclusion
[//]: # (excludeFromIndex)
Module is, at the low level, a statement that modifies a given context by adding
here local and exported symbols, performing some tasks and even returning some value
we don't need for now.
The compiled module is therefore a statement. When we execute it on some context,
it wills it with all it symbols, private too.
If we call it on another context, it will do it once more, no caching. This is unnecessary
if not dangerous repetition.
## What is inclusion?
The _goal_ of the inclusion is to make _exported symbols_ available in a given context,
without re-executing included module initialization code. So, when we hit the `import foo`,
we should check that foo module was executed, execute it if not on special context we store in the library, then copy all public symbols from fooContext into current one.
## Class pseudo-module
Mostly same we can do with a class
## Module initialization
We can just put the code into the module code:
module lying.samples.module
// or package?
val startuptTime = Instant.now()
// private: not available from outside
private fun moduleInitialization() {
// long code
}
// this will be called only once
moduleInitialization()
## class initialization
already done using `ObjInstance` class and instance-bound context with local
context stored in ObjInstance and class constructor statement in ObjClass.
docs/development/scope_resolution.md
-15
View File
@@ -1,15 +0,0 @@
[//]: # (excludeFromIndex)
Provide:
fun outer(a1)
// a1 is caller.a1:arg
val a1_local = a1 + 1
// we return lambda:
{ it ->
// a1_local
a1_lcoal + it
}
}
docs/proposals/map_literal.md
-95
View File
@@ -1,95 +0,0 @@
# Map literals — refined proposal
[//]: # (excludeFromIndex)
Implement JavaScript-like literals for maps. The syntax and semantics align with named arguments in function calls, but map literals are expressions that construct `Map` values.
Keys can be either:
- string literals: `{ "some key": value }`, or
- identifiers: `{ name: expr }`, where the key becomes the string `"name"`.
Identifier shorthand inside map literals is supported:
- `{ name: }` desugars to `{ "name": name }`.
Property access sugar is not provided for maps: use bracket access only, e.g. `m["a"]`, not `m.a`.
Examples:
```lyng
val x = 2
val m = { "a": 1, x: x*10, y: }
assertEquals(1, m["a"]) // string-literal key
assertEquals(20, m["x"]) // identifier key
assertEquals(2, m["y"]) // identifier shorthand
```
Spreads (splats) in map literals are allowed and merged left-to-right with “rightmost wins” semantics:
```lyng
val base = { a: 1, b: 2 }
val m = { a: 0, ...base, b: 3, c: 4 }
assertEquals(1, m["a"]) // base overwrites a:0
assertEquals(3, m["b"]) // literal overwrites spread
assertEquals(4, m["c"]) // new key
```
Trailing commas are allowed (optional):
```lyng
val m = {
"a": 1,
b: 2,
...other,
}
```
Duplicate keys among literal entries (including identifier shorthand) are a compile-time error:
```lyng
{ foo: 1, "foo": 2 } // error: duplicate key "foo"
{ foo:, foo: 2 } // error: duplicate key "foo"
```
Spreads are evaluated at runtime. Overlaps from spreads are resolved by last write wins. If a spread is not a map, or yields a map with non-string keys, it’s a runtime error.
Merging with `+`/`+=` and entries:
```lyng
("1" => 10) + ("2" => 20) // Map("1"=>10, "2"=>20)
{ "1": 10 } + ("2" => 20) // same
{ "1": 10 } + { "2": 20 } // same
var m = { "a": 1 }
m += ("b" => 2) // m = { "a":1, "b":2 }
```
Rightmost wins on duplicates consistently across spreads and merges. All map merging operations require string keys; encountering a non-string key during merge is a runtime error.
Empty map literal `{}` is not supported to avoid ambiguity with blocks/lambdas. Use `Map()` for an empty map.
Lambda disambiguation
- A `{ ... }` with typed lambda parameters must have a top-level `->` in its header. The compiler disambiguates by looking for a top-level `->`. If none is found, it attempts to parse a map literal; if that fails, it is parsed as a lambda or block.
Grammar (EBNF)
```
ws = zero or more whitespace (incl. newline/comments)
map_literal = '{' ws map_entries ws '}'
map_entries = map_entry ( ws ',' ws map_entry )* ( ws ',' )?
map_entry = map_key ws ':' ws map_value_opt
| '...' ws expression
map_key = string_literal | ID
map_value_opt = expression | ε // ε allowed only if map_key is ID
```
Notes:
- Identifier shorthand (`id:`) is allowed only for identifiers, not string-literal keys.
- Spreads accept any expression; at runtime it must yield a `Map` with string keys.
- Duplicate keys are detected at compile time among literal keys; spreads are merged at runtime with last-wins.
Rationale
- The `{ name: value }` style is familiar and ergonomic.
- Disambiguation with lambdas leverages the required `->` in typed lambda headers.
- Avoiding `m.a` sidesteps method/field shadowing and keeps semantics clear.
docs/proposals/named_args.md
-70
View File
@@ -1,70 +0,0 @@
# Named arguments in calls
[//]: # (excludeFromIndex)
Extend function/method calls to allow setting arguments by name using colon syntax at call sites. This is especially convenient with many parameters and default values.
Examples:
```lyng
fun test(a="foo", b="bar", c="bazz") { [a, b, c] }
assertEquals(test(b: "b"), ["foo", "b", "bazz"])
assertEquals(test("a", c: "c"), ["a", "bar", "c"])
```
Rules:
- Named arguments are optional. If named arguments are present, their order is not important.
- Named arguments must follow positional arguments; positional arguments cannot follow named ones (the only exception is the syntactic trailing block outside parentheses, see below).
- A named argument cannot reassign a parameter already set positionally.
- If the last parameter is already assigned by a named argument (or named splat), the trailing-lambda rule must NOT apply: a following `{ ... }` after the call is an error.
Rationale for using `:` instead of `=` in calls: in Lyng, assignment `=` is an expression; using `:` avoids ambiguity and keeps declarations (`name: Type`) distinct from call sites, where casting uses `as` / `as?`.
Migration note: earlier drafts/examples used `name = value`. The final syntax is `name: value` at call sites.
## Extended call argument splats: named splats
With named arguments, splats (`...`) are extended to support maps as named splats. When a splat evaluates to a Map, its entries provide name→value assignments:
```lyng
fun test(a="a", b="b", c="c", d="d") { [a, b, c, d] }
assertEquals(test("A?", ...Map("d" => "D!", "b" => "B!")), ["A?", "B!", "c", "D!"])
```
Constraints for named splats:
- Only string keys are allowed in map splats; otherwise, a clean error is thrown.
- Named splats cannot reassign parameters already set (positionally or by earlier named arguments/splats).
- Named splats follow the same ordering as named arguments: they must appear after all positional arguments and positional splats.
## Trailing-lambda interaction
Lyng supports a syntactic trailing block after a call: `f(args) { ... }`. With named args/splats, if the last parameter is already assigned by name, the trailing block must not apply and the call is an error:
```lyng
fun f(x, onDone) { onDone(x) }
f(x: 1) { 42 } // ERROR: last parameter already assigned by name
f(1) { 42 } // OK
```
## Errors (non-exhaustive)
- Positional argument after any named argument inside parentheses: error.
- Positional splat after any named argument: error.
- Duplicate named assignment (directly or via map splats): error.
- Unknown parameter name in a named argument/splat: error.
- Map splat with non-string keys: error.
- Attempt to target the ellipsis parameter by name: error.
## Notes
- Declarations continue to use `:` for types, while call sites use `:` for named arguments and `as` / `as?` for type casts/checks.
docs/tutorial.md
+1 -1
View File
@@ -1546,7 +1546,7 @@ Lambda avoid unnecessary execution if assertion is not failed. for example:
[Range]: Range.md
[String]: development/String.md
[String]: ../archived/development/String.md
[string formatting]: https://github.com/sergeych/mp_stools?tab=readme-ov-file#sprintf-syntax-summary