cwells / franz Goto Github PK

fibonacci-sequence = fn (n: int) {
    a = b = 1
    for i in 3 to n + 2 {
        yield a
        (a, b) = (b, a + b)
    }
}

doesn't parse, but,

fibonacci-sequence = fn (n: int) {
    a = b = 1
    for i in 3 to n + 2 {
        yield (a)
        (a, b) = (b, a + b)
    }
}

is fine. It appears that yield a(a, b) is what is being evaluated. Not sure if this is "fixable" or if the ambiguity will need to be resolved by the user.

The current form ( name: type ("," name: type)* ) doesn't allow for default values.

Proposed solution: ( type name ("=" default)* ("," type name ("=" default)*)* )

e.g. (int i, int j=10)

Will need to trap this to prevent assignment from taking over (or continue using ":" rather than "=").

a[i] = j doesn't work.

Given the following three functions

a = fn (n: int)
    for i in 1 to n 
        yield i;

b = fn (iter: any)
    for j in iter 
        yield j;

c = fn (iter: any)
    for k in iter 
        yield k;

evaluating [ a(5) ] works as expected:
[1, 2, 3, 4, 5].

Conversely, result of evaluating [ c(b(a(5)) ]:
[1, 2, (), (), (), 3, (), (), (), 4, (), (), (), 5, (), (), (), 5, (), ()]

When nesting the functions, [ c(b(a(5))) ], instead of seeing the call chain a->b->c->a->b->c we see a->b->c->a->c. Further testing has shown that whatever number of functions is nested, it always jumps from first function to last function on the second iteration. As such, [ a(5) ] works because this is the special case where first == last. It "works" due to accidentally switching back to the correct coroutine.

Further, when this happens, the last function has its loop variable (i, j, k) set to the empty tuple (). This happens to coincide with the value returned from greenlet.switch() when it is called on a dead coroutine (it may also indicate other conditions, I'm not certain) 🤔.