-
Notifications
You must be signed in to change notification settings - Fork 0
functions
This module introduces lightweight, Java-compatible lambda expressions for Skript, backed by real Java functional interfaces. Lambdas are compiled into proxy instances and can be passed directly into Java APIs, streams, or stored for deferred execution.
-
Skript
-
singlelinesection.sk
- Must be loaded before this module
- Recommended: rename to
!singlelinesection.skto ensure alphabetical load order
-
skript-reflect
Lambdas are mapped to the following Java interfaces:
Supplier<T>Function<T, R>BiFunction<T, U, R>RunnableConsumer<T>BiConsumer<T, U>
All generated lambdas are real Java proxy instances.
lambda [<variables>]: <expression>
- Returns a value
- Automatically mapped to a Java functional interface
- Return vs effect behavior is auto-detected
lambda [<variables>]:- <effect>
- Used for side effects only
- Produces no return value
lambda [<variables>]:+ <expression>
- Forces returning behavior
- Useful when the body might otherwise be parsed as an effect
Lambdas may also be written as multiline sections. These allow more complex logic while still compiling into Java functional interfaces.
Multiline lambdas are created using typed aliases (new runnable:, new function {_x}:, etc.).
Maps to:
RunnableConsumer<T>BiConsumer<T, U>
depending on arity.
set {_task} to new runnable:
broadcast "working"
broadcast "still working"
Rules:
- Produces no return value
- All lines must be effects
-
returnis not allowed
Multiline returning lambdas must use the return effect.
The lambda does not infer a return value from the last line.
set {_double} to new function {_x}:
broadcast "doubling %{_x}%"
return {_x} * 2
Rules:
-
return <expression>is mandatory - The final line does not need to be an expression
- Effects may appear anywhere before
return - Multiple control-flow paths may use
return
Maps to:
Supplier<T>Function<T, R>BiFunction<T, U, R>
based on arity.
The target Java interface is selected based on parameter count and return behavior.
| Behavior | Interface |
|---|---|
| Returning | Supplier<T> |
| Non-returning | Runnable |
| Behavior | Interface |
|---|---|
| Returning | Function<T, R> |
| Non-returning | Consumer<T> |
| Behavior | Interface |
|---|---|
| Returning | BiFunction<T, U, R> |
| Non-returning | BiConsumer<T, U> |
Lambdas with more than 2 parameters are not supported.
Pass a single composite object instead:
maplist- custom object
set {_supplier} to lambda: "hello"
broadcast {_supplier}.get()
set {_sum} to lambda: 2 + 3
broadcast {_sum}.get()
set {_double} to lambda {_x}: {_x} * 2
broadcast {_double}.apply(5) # 10
set {_format} to lambda {_x}: "%{_x}%_ok"
broadcast {_format}.apply("abc") # abc_ok
set {_add} to lambda {_a}, {_b}: {_a} + {_b}
broadcast {_add}.apply(3, 4) # 7
set {_task} to lambda:- broadcast "ran"
{_task}.run()
set {_printer} to lambda {_x}:- broadcast {_x}
{_printer}.accept(42)
set {_pair} to lambda {_a}, {_b}:- broadcast "%{_a}%, %{_b}%"
{_pair}.accept("x", "y")
In addition to the generic lambda syntax, explicit aliases are available.
These enforce arity and return behavior at parse time.
supplier:
getter:
function {_x}:
applier {_x}:
bifunction {_a}, {_b}:
biapplier {_a}, {_b}:
runnable:
runner:
consumer {_x}:
accepter {_x}:
biconsumer {_a}, {_b}:
biaccepter {_a}, {_b}:
set {_f} to function {_x}: {_x} * 2
set {_r} to runnable:
broadcast "hello"
Lambdas can be invoked directly via Java methods or using the helper syntax:
run lambda <lambda> [with <arguments>]
The correct method (get, apply, accept, run) is resolved automatically.
run lambda {_supplier}
run lambda {_double} with 5
run lambda {_pair} with "a", "b"
set {_map} to new HashMap()
{_map}.put(1, 2)
{_map}.put(2, 3)
set {-total} to 0
set {_inlineforeach} to lambda {_v}:- add {_v} to {-total}
set {_adder} to lambda {_m}:- {_m}.values().stream().forEach({_inlineforeach})
{_adder}.accept({_map})
-
Lambdas may be single-line or multiline
-
Single-line lambdas infer return vs effect behavior
-
Multiline returning lambdas require
return -
Multiline non-returning lambdas must not return
-
Lambdas are limited to 0–2 parameters
-
Variable lists as parameters are not supported
-
Arrays are unreliable inside lambdas:
- Indexing (
[n]) does not work - Use
spread(...)before passing arrays
- Indexing (
-
Imported classes or complex expressions may fail inline
- Prefer multiline lambdas
- Or wrap logic in a normal Skript function
-
Single-line lambdas auto-detect return vs effect
-
Multiline lambdas require explicit intent
-
Lambdas are real Java proxy objects and fully compatible with:
- Java streams
- Java APIs
- skript-reflect usage
-
Experimentally, local values are passed into lambda sections. Use with care.
- Additional utility expressions (e.g.,
for eachhelpers) - These will be introduced in separate files