Variable Arguments

This draft supports calling functions with variable arguments.
It is mainly designed for calling 'var args' methods from Java libraries.

These are called as regular functions:

run myMethod(1, 2, 3) from MyClass

Full Changelog: 1.0.37...1.0.39

References

This release adds (tentative) support for references via functions.
References can be used to indicate an object without preventing it from being garbage collected by the virtual machine.

Two types of reference are supported in this version:

weak_reference(object)
soft_reference(object)

Weak references point to an object but do not prevent it from being garbage-collected. If there are no other (strong) references to it, the object will be cleared during garbage collection and the reference's value will be null.
Weak references are useful for pointing to information provided by something else, without having to keep track of when it needs to be disposed (e.g. a reference to a Minecraft Player.)

Soft references also do not prevent garbage-collection, but encourage the virtual machine to hold on to the object where possible (e.g. until memory needs to be freed.)
The implementation differs between machines: client java distributions typically hold on to soft references for as long as possible, whereas server distributions will dispose of them more readily.
Soft references are useful for caching information that can be re-created but is inexpensive to hold on to, (e.g. a parsed configuration file or json structure.) The value can disappear without warning but typically only when the machine needs to free up space.

The (potential) value can be extracted using:

reference_value(reference)

References may be supported at a language level in the future. There is a (tentative) plan to support them when variables V2 is finished.

Script Unloading

This release adds the ability to load a script with the same namespace as a previously-unloaded script.

What's Changed

• Fix reloading by @bluelhf in #15

Full Changelog: 1.0.35...1.0.36

Event Task Feedback

This release includes a slew of small quality-of-life adjustments (thank you @bluelhf) and little fixes.

Dispatching an event will now give back a data object with some information and the available futures for all tasks it spawned (suggestion from @kiip1) as well as a way to do something after all have finished.

There is also a fix for a minor race condition that was preventing some Futures from being marked as finished correctly, if the script managed to complete faster than the event was finished being dispatched by the controller.

From now on, most work will be towards fixes, quality and speed improvements rather than new features, preparing for a version 1.1 major release.

What's Changed

• Change ExprFunctionProperty to use 'of' instead of 'from' by @bluelhf in #7
• Fix all the things by @bluelhf in #9
• Fix pattern matching for optional groups by @bluelhf in #10
• Don't throw unchecked exception in unsafe.set_java_field by @bluelhf in #11

New Contributors

• @bluelhf made their first contribution in #7

Full Changelog: 1.0.34...1.0.35

Pattern Backtracking

This draft supports pattern backtracking.
This will slow down parsing slightly, but it prevents errors where one syntax includes another.
An example of this would be maths expressions inside strings like "hello + " + "there".

If the first (wrong) match fails (e.g. "hello and " + "there") then it will backtrack to the last successful pattern and attempt another variant (e.g. "hello + " and "there".)

There may be some potential errors when using the Divide / expression with brackets. Fixing this will require renegotiating how patterns work.

Class Naming Scheme

This draft updates all syntax to use a consistent naming scheme Effect/Expr/Member/Entry...

Some addons that interact directly with syntax may need to update.

A minor addition for addon creators is the ability to register an operator overload (e.g. String + MyType.) This is registered to the library or the runtime like a converter.

Wait For

This draft contains a new wait for %Executable% effect. This is not to be confused with the existing wait %Duration% effect.

The wait for ... effect is designed for creating advanced multi-process code.
It runs an executable on a background thread but waits for its completion, preserving the execution order.

wait for a new runnable:
  print "1"
  wait 1 second
  print "2"
print "3"

This behaviour is semi-equivalent to a regular run.

run a new runnable:
  print "1"
  wait 1 second
  print "2"
print "3"

The key difference between these two is that the background process can be branched off by cancelling the wait with a wake effect.

set {thread} to the current thread
wait for a new runnable:
  print "1"
  wake {thread} // the wait ends here
  wait 1 second
  print "3"
print "2"

This is a lot safer than using sleep/wake with a regular run ... in the background since a hidden monitor preserves the happens-before relationship and makes sure the code executes in the expected order.

This draft also covers a minor inconsistency that recycled background processes could keep the thread variables that were previously set.

Improved Literals

This draft improves handling for literals and contains some internal updates.
It should have very little impact on normal users but will make life easier for library developers.

Full Changelog: 1.0.28...1.0.30

Bridge Compiler Improvements and Unsafe

This draft contains a significant improvement to the bridge compiler, a new function entry and a change to the development model.

1. Feature-previews in Unsafe

A new unsafe function namespace has been added to ByteSkript.
This is unstable by design and is guaranteed to change between versions. It is designed to contain first-pass features that may be developed into syntax eventually, or may be moved to the stable and reliable skript namespace instead. Equally, these features may be removed without warning if they do not make it past the trial phase.

Features will now primarily be added to unsafe for one minor version before becoming a syntax.

The unsafe namespace will also contain some dangerous functions for manipulating internals that will live there long-term and will never be developed into syntax due to their native unreliability. (E.g. monitoring all script processes, locking and unlocking the fence on objects.)

2. Explicit Function Parameters

Functions may now have explicit parameter types. This is designed primarily for people interacting with third-party Java libraries, who need to match an exact method signature in order to override it.

function blob(name, age):
    parameters: string, integer
    return: boolean
    trigger:
        print {name} +"'s age is " + {age}
        return {age} > 31

In this example, the parameters will accept only a string and an integer argument. See section 3 for more information about type conformity.

It is acceptable to under-provide or over-provide parameter types, in which case the extras will be ignored.

This is currently incompatible with atomic parameters, which must accept atomic variables.

3. Type Conformity in the Bridge Compiler

ByteSkript's bridge compiler is now capable of automatically conforming a type when required.
This is part of an effort to seamlessly correct common mistakes without causing trouble for the user.

If a function or Java method requires non-object parameters, rather than simply casting or boxing the arguments, the metafactory will rewrite the code on-the-fly to include the correct call to the type converter.
Because the bridge compilation is done on-the-fly with direct insights to the types being used, it will only insert converters where they are needed to maximise the speed of the code.

function blob(name, age):
    parameters: string, integer
    trigger:
        assert {name} is a string
        assert {age} is a number

function test:
    trigger:
        run blob("hello", "3") // converts "3" to 3
        run blob(1, 3) // converts 1 to "1"

Full Changelog: 1.0.27...1.0.28

Improved Inline Section Handling

This draft improves the handling of some inline sections and section headers that store values.

Both catch ... and loop ... in ... can now accept any settable expression instead of just local variables.

try:
    assert false
catch {@error}:
    print "hello"

loop {@item} in {list}:
    print {@item}

These two sections now properly support being inlined, although their inline mode is slightly different from usual.
Instead of affecting the remainder of their current block, both the inline loop and the catch will now only affect their current line.

print "start"
loop {item} in {list}
print "end"
// {item} will be the final iterated item

To compensate for this, the function expression now supports a special set mode, where the first provided argument shall be replaced by the set value.
This allows a function to be used in both of these inline headers.

print "start"
loop function(null) in {list} // the `null` value is replaced by the iterator value
// function(...) will be run for each item in the list
print "end"

Full Changelog: 1.0.26...1.0.27