Support defaction setting(var) for actions

[0joshuaolson1]

This includes something like a return value for defactions. We have a concrete need now to return new pico information, where the pico is created by a function called in a defaction. (but may change with https://huboard.com/Picolab/pico-engine#/issues/229690097)

Another use case is making http actions actually actions instead of functions. https://picolabs.atlassian.net/wiki/display/docs/HTTP refers to setting.

[0joshuaolson1]

Sorry, Bruce tells me the setting behavior is already implemented for HTTP specifically, not necessarily user-defined actions.

[farskipper]

Available as of [email protected] and works for all actions (if the action doesn't return anything it's just null)

[0joshuaolson1]

Neat! How do user-defined actions return something? If there's documention, I missed it.

[farskipper]

There is not a way to return something right now. But I think there should be. Since there can be multiple sub-actions you might want to gather that data and return some value based on them.

For example: return <expr>

foo = defaction(){
    every {
        bar() setting(r1);
        baz() setting(r2);
    }
    return {"some": r1, "thing": r2}
}

[cgrimm013]

I agree. Consider creating a new pico... We have to make multiple "engine:" calls and then compile the information together before saving it in an entity variable. Not having a setting ability prevents us from effectively doing that.

[farskipper]

Cool. @windley @b1conrad Any opinions/objections to this concept, or return <expr> syntax for defaction?

I think we need a return keyword to distinguish the expression from just another action call. i.e.

foo = defaction(){
    some_action()
    return somefn()
}

if the return isn't there, somefn() will look like an action call and the programmer might think they just called two actions.

[0joshuaolson1]

I like return, but we'll need to document that it can only appear at the end?

[windley]

Let me make sure I'm understanding the example you give above (for foo()). The parameters in a setting are positional (and it's the only place we support multiple assignment).

The return would return a single value (which happens to be a map), so if I did this:

foo() setting(a)

a would get the value {"some": r1, "thing": r2}. Correct?

foo() setting (a, b)

would result in a getting the map value and b being null. Correct?

I don't mind the return syntax. I can't think of anything I like better.

[farskipper]

@0joshuaolson1 yes, I think return should be last b/c you'll call the actions first, then shape the data to be returned.

@windley correct and correct, that's what I was thinking. But I forgot that in other places setting allows multiple assignment. We could do return <expr1>, <expr2>, ... to take advantage of it.

[windley]

Good on multiple return.

BTW, I've often ran into situations in the prelude where a mutliple assignment would be handy in general. For example:

   (x, y) = a => (b, c) | (d, e)

This is hard to do without repeating a with single binding.

  x = a => b | d
  y = a => c | e 

[farskipper]

Cool, I'll add that multiple assignment example to issue #5

[farskipper]

Available, as of pico-engine 0.12.x

More details/help here:
https://github.com/Picolab/node-pico-engine/blob/master/CHANGELOG.md#0120---may-25-2017