how SIC will probably change this month

$ ./yapsi --target=sic -e 'my $a = 3; while --$a { say my $b; say $a; $b = 42 }'

== BEFORE

This is SIC v2010.07

environment:
    main:
        $a: {"n" => 0, "type" => "container"}
    main_1:
        $b: {"n" => 1, "type" => "container"}
    containers: ["Any()", "Any()"]

block 'main':
    $0 = 3
    store '$a', $0
    `label L0
    $1 = fetch '$a'
    dec $1
    store '$a', $1
    jf $1, L1
    $2 = fetch-block 'main_1'
    call $2
    jmp L0
    `label L1

block 'main_1':
    $0 = fetch '$b'
    say $0
    $1 = fetch '$a'
    say $1
    $2 = 42
    store '$b', $2


== AFTER

This is SIC v2010.08

block 'B0':
    `lexvar '$a'
    $0 = 3
    store [0, 0], $0
    `label L0
    $1 = fetch [0, 0]
    dec $1
    store [0, 0], $1
    jf $1, L1
    $2 = fetch-block 'B1'
    call $2
    jmp L0
    `label L1

block 'B1':
    `inside 'B0'
    `lexvar '$b'
    $0 = fetch [0, 0]
    say $0
    $1 = fetch [-1, 0]
    say $1
    $2 = 42
    store [0, 0], $2

== CHANGES in SIC

* 'environment' header goes away completely.

* Blocks can still be named anything, but the automatic naming is no longer /main[_\d+]*/,
but /B\d+/.

* `fetch '$var'` and `store '$var', <value>` are temporarily deprecated in favor of
indexed lookups. [0, 0] means "current block, zero-th variable", whereas [-1, 0] means
"this block's outer block, zero-th variable".

== CHANGES in the runtime

* Nesting relationship is no longer extracted through string nomming, but through (1)
constructing real lexpad objects at compile time/run time, and (2) following the .outer
attributes upwards during lookup.

* Lexical variables are stored and accessed in arrays, as above. This will need to fall
back to hash access when we do indirect lookup ($::'$a'), but we don't yet. Uhm, but
we'll need to keep a hash around at runtime, because of clients such as Tardis that
inquire about variable names. Question remains whether to make the hashes refer only to
the current block's lexical vars (and incur a bigger lookup cost) or to current-and-all-
outer blocks (and require more memory).

* Individual containers end up not all in one array, but referenced from each variable.
They'll then have the chance to be GC'd.

* A new lexpad will be created during block entry, so the above code will output
"Any()\nAny()\n" as expected.