how to pass a method but not activate it in io language

Question

I want to implement a method dim(x,y) which will assign spaces for a matrix(y rows, x cols).

I want to make "dim(x,y)" more powerful by passing an optional function 'filler' to it and then 'dim' will set the element located at (x,y) to filler(x,y)

my code goes as below:

List2D dim := method(x, y, z,
    target := list()
    filler := if(z == nil, 
        method(return nil),
        z)
    for(i, 1, y, 
        subTarget := list()
        for(j, 1, x,
            subTarget append( filler(i,j) ))
            target append(subTarget) )
    return target)

it worked well when 'dim' is called with 2 arguments, but failed with

List2D dim(3,2, method(x,y, 10*x+y))

which throwed an exception at line filler := if(z == nil The exception said nil does not respond to '*'

I realized the argument 'z' got activated undesirably when comparing with nil.

So I'm wondering how to get my 'List2D dim' work properly?

score 6 · Accepted Answer · answered Jan 13 '13 at 15:51

Alright so basically, you'll want something like this:

List2D dim := method(x, y,
    target := list
    blk := call evalArgAt(2) # Get the third argument, and evaluate it in the context of the sender
    if(blk isNil, blk := block setScope(call sender))

    for(i, 1, y,
        subTarget := list
        for(j, 1, x,
            subTarget append(blk call(i, j))
            target append(subTarget)
        )
    )
    target
)

Basically, what's going on here is since your filler, you want to give it arguments, the easiest method is just to pass in a Block. You can do this with messages, but you in effect, end up setting up your own duplicate of Block anyway if you introduce a new scope, which you should. If the third argument evaluates to nil, then we'll just create a new function and set its scope to the calling context; as if the user had passed in an empty function, which has no argument arty and as such, you can pass arguments to it even if it doesn't define any parameters. The fact we scope it to the caller isn't really needed, but you should always scope blocks to the calling context if you're creating the blocks inside your method call. This will give access to the lexical scope of the calling context inside that block; which you're probably shoving some message the user has supplied in it. When ready, just call that method explicitly using the call method.

If your filler method didn't require any arguments, I'd just grab the raw message argument at the 2nd index, instead of evaluating it. This would yield some major performance improvements for some large matrices.

So the idea here is to use `call evalArgAt` to make the argument evaluated in the context of where the argument was created(and the 3rd argument of `dim` should be a `block` rather than a `method`), and pass a message `call` to activate it. To improve performance, I'll let the 3rd argument of `dim` be either `block` or a default value, test if `blk type =="Block"` and come up with difference strategies to initialize elements in the matrix. Helps a lot, thank you! :) — Javran, Jan 14 '13 at 05:16
You should never compare against the `type` slot. Rather, compare the receiver like this: blk isKindOf(Block). — jer, Jan 14 '13 at 14:45

how to pass a method but not activate it in io language

1 Answers1