#265 Docs are still missing but I will add later. Note: After Ellipsis space is allowed in this implementation not to break compatibility. Note: Any expression is allowed after ellipsis but it can return an error at parser level but I want to hear your ideas.

array define : [1,2,3,4,5] range define: [1..5]

This syntax is useful in an inline environment to effectively shorten script lengths.

Some language support it like kotlin, groovy...etc

vm.Compile() Error {"error": "[uno.mshk]Compile Error: module file read error: open due.tengo: no such file or directory\n\tat (main):1:8"}

vm.Compile() Error {"error": "[due.mshk]Compile Error: module file read error: open tre.tengo: no such file or directory\n\tat (main):1:8"}

• After feedback from #297 (spread in arrays, maps, call args), I removed spread for array and map, only last call argument can be spread.
• Ellipsis must come after the argument, not before (like Go).
• Only last argument can be spread (like Go).
• Call Args and function params match is not mandatory, OpCall takes whatever in the stack after spread and use it as before, no major OpCall changes.
• Docs are missing, will be added after PR approval.
• Cost of this is not calculated in terms of performance. Simple benchmarks #265 show +~1% delta.
• Major version change is not required.
• This is a draft PR.

After considering what could be effective, I came up with this implementation. Docs and some tests are missing and will be added if it is accepted. It closes #280 . Implementation is based on @d5 comment Notes:

• checkCyclicImport call removed which was called before compileModule in Compiler for file imports. It is already called in compileModule.
• I added testdata folder and bunch of tengo scripts under cmd/tengo for testing relative imports with CI (testdata folder may be moved to lib root folder).
• At Go side, user can set import dir to search importable tengo files which is updated for each module compiler based on file's dir.
• Absolute paths are used to ensure detecting cyclic imports.
• Physical file modules can be a symbolic link, they are resolved as well but following symbolic links is limited to max 2 levels (who needs more?).
• Tengo CLI compiles and runs both compiled and module files without any problem.
• I have only Linux machine, I dont know if this implementation works well on windows/mac (TODO).

Comments please @d5 @geseq

Importing a module tre.tengo

fun := func(a) {
  return a
}

tre := {
  fun: fun
}
export tre

in another tengo script due.tengo (both files are in the same folder)

tre := import(`tre`)

funcy := func(a) {
  return tre.fun(a)
}

due := {
  funcy: funcy
}
export due

throws an error, when tengo is invoked as CLI from another directory, e.g. the parent folder :

Compile Error: module file read error: open tre.tengo: no such file or directory at due.tengo:2:8

It works fine however when tengo is invoked from within the folder. This leads me to suspect the import is done relative to the working directory. Relative imports feel more intuitive though, or am I wrong. Is there already a way to import relative to another file?

builtin delete is ready. It works like Go's delete for maps but also works for array types. delete function returns only undefined value or raises runtime error. It mutates given map or array. doc and tests are added.

Hi,

I encountered following behavior at v2.6

f := undefined
if true {
    a := 10
    f = func() {
        a = 20
    }
}
b := 5
f()
fmt := import("fmt")
fmt.println(b)

Output

20

Expected

5

Symbol table is forked before If statement and symbols next index is reset to the state before forking after If statement finished in compiler, because of that variable a and variable b has same symbol index and captured variable in f refers to wrong variable. What do you think?

The following Tengo code:

func1 := func(a, b) {
    return a * b
}

func2 := func() {
    test := test(1, 2)
}

func2()

While completely bonkers (re-assigning a function), produces a SIGSEGV, which should not happen.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0x52eb39]

goroutine 1 [running]:
github.com/d5/tengo/v2.(*VM).run(0xc000180000)
	/home/runner/work/tengo/tengo/vm.go:542 +0x2ac9
github.com/d5/tengo/v2.(*VM).Run(0xc000180000, 0xc000180000, 0x400)
	/home/runner/work/tengo/tengo/vm.go:77 +0xcf
main.CompileAndRun(0xc0001026f0, 0xc000152000, 0x5e, 0x25e, 0xc0001163d0, 0xc, 0x0, 0xc000104120)
	/home/runner/work/tengo/tengo/cmd/tengo/main.go:144 +0x1d0
main.main()
	/home/runner/work/tengo/tengo/cmd/tengo/main.go:83 +0x420

I stumbled upon this by happenstance as a result of a typo in my code.

To use tengo as scripting language in the terminal, support for shebang (#!) would be beneficial.

Additional question, what is the proposed file extension for tengo files?

Spread Syntax

Now that the language has variadic functions, it would make sense to add something like Go's spread operator (...) to allow using the contents of arrays as variadic arguments.

However, Tengo uses a stack-based vm. Implementing a spread-like operator would create a re-usable mechanism for "exploding" arrays onto the stack. We can take advantage of this by allowing "exploding" in array literals and at other positions in a function call besides the last.

I've got most of an implementation complete in the explosions branch of my fork. For syntax and uses, see below.

Syntax

Array Literals

insert/delete:

x := [1, 2, 3, 4]
x = [x[:2]..., "hi", x[2:]...] // [1, 2, "hi", 4, 5]
x = [x[:2]..., x[3:]...] // [1, 2, 4, 5]

concatenate:

a := [1, 2]
b := [3, 4]
c := [5, 6]
d := [a..., b..., c...] // [1, 2, 3, 4, 5, 6]

mix & match:

a := [2, 3]
b := [5, 6]
c := [1, a..., 4, b...] // [1, 2, 3, 4, 5, 6]

explode custom Iterable implementations:

iter := make_go_channel_iterator()
list := [iter...] // [ (all values from the iterator) ]

explode any value of an explodable type (including literals):

x := [[1, 2]..., 3, [4, 5, 6]...] // [1, 2, 3, 4, 5, 6]

Function Calls

our example funcs:

variadic_fn := func(a, b, c, ...args) { /* ... */ }
normal_fn := func(a, b, c, d) { /* ... */ } 

variadic function calls:

variadic_fn(1, 2, 3) // a=1 b=2 c=3 args=[]
variadic_fn(1, 2, 3, [4, 5]...) // a=1 b=2 c=3 args=[4, 5]
variadic_fn(1, [2, 3]..., [4, 5]..., 6) // a=1 b=2 c=3 args=[4, 5, 6]

normal function calls:

normal_fn(1, 2, 3) // illegal, missing arguments
normal_fn(1, 2, 3, [4, 5]...) // illegal, total # of arguments > # of function parameters
normal_fn(1, [2, 3]..., [4]...) // a=1 b=2 c=3 d=4
normal_fn([1, 2, 3, 4]...) // a=1, b=2, c=3, d=4

example:

apply := func(fn, ...applied) {
    return func(...args) {
        return fn(applied..., args...)
    }
}

apply(normal_fn, 1, 2)(3, 4) // a=1 b=2 c=3 d=4

I would like sort an array of objects based on a supplied function. Something like sort.Slice()

sorting := import("sorting") myList := [{x:1}, {x:2},{x:3}] sorting.sort( myList, func( i, j ){ return myList[i].x < myList[j].x }

The problem is, you can run a CompiledFunc for your UserFunc.

My workaround was to pass the name of a field to the UserFunc...

sorting.sort( myList, "x")

I've added a location parameter to times.date to allow for creating a timestamp in a specific location. The call now works the same as the equivalent Go function. This parameter is optional so as not to break existing code.

Along with this I've also added times.in_location(t time, l string), which works similar to func (t Time) In(loc *Location) Time

Rationale:

Compared to other scripting solutions for golang, tengo has a capability to execute bytecode. However:

1. Currently, Encode/Decode is implemented only in Bytecode and global variables are not saved. In order to run a script, it needs to be compiled first.
2. Because of (1), it's not possible to deliver/embed compiled script with host application, if it contains global variable(s).

Improves BinaryOp performance significantly

Before:

-------------------------------------
fibonacci(35)
-------------------------------------
Result:  9227465
Go:      42.388955ms
Parser:  36.718µs
Compile: 109.024µs
VM:      2.787647146s
-------------------------------------
fibonacci(35) (tail-call #1)
-------------------------------------
Result:  9227465
Go:      42.789713ms
Parser:  21.297µs
Compile: 70.948µs
VM:      2.894222823s
-------------------------------------
fibonacci(35) (tail-call #2)
-------------------------------------
Result:  9227465
Go:      256ns
Parser:  17.864µs
Compile: 60.804µs
VM:      14.668µs 

After:

-------------------------------------
fibonacci(35)
-------------------------------------
Result:  9227465
Go:      41.610339ms
Parser:  33.751µs
Compile: 98.728µs
VM:      2.252044656s
-------------------------------------
fibonacci(35) (tail-call #1)
-------------------------------------
Result:  9227465
Go:      41.661108ms
Parser:  18.044µs
Compile: 59.931µs
VM:      2.700379139s
-------------------------------------
fibonacci(35) (tail-call #2)
-------------------------------------
Result:  9227465
Go:      240ns
Parser:  22.475µs
Compile: 70.738µs
VM:      22.121µs