Change the way destructuring works

[Feliix42]

Currently, the sequence

let (house3, humans2) = move_in_one(house2, humans);

generates a stateful function with two output ports with ids 1 and 2.
But the new implementation requires sfns to only have output port(s) with id -1. So the above should be transformed into:

let r = move_in_one(house2, humans);
let house3 = ohua.lang/nth(0, r);
let humans2 = ohua.lang/nth(1, r);

[sertel]

It is this recurring issue with destructuring. I think we should solve this now once and for all. I believe everything is already in place in the compiler to make this a fairly quick and easy change.

[JustusAdam]

Generating this kind of code is not the problem. I think the only reason we held off is because we wanted to wait until fusion was ready, so that we can optiomize the nth functions away

[sertel]

We are putting this in now, so it is a good time to resolve this issue.

[JustusAdam]

I have a few things to remark that I feel we must consider in this case

Operator

We must decide on how the operator(s) themselves work. Either we have a universal index operator, such as ohua.lang/nth and pass in the index, or we have specialized operators for each index, like ohua.lang/1 and ohua.lang/0.

In the former case we need some kind of mechanism for generating the index. In the latter the backend needs to recognize the special operator and handle it accordingly.
Alternatively we can demand the backend support certain types of literals, in this case only integer literals.

Graph structure

If we implement this to be the general destructuring mechanism this means every operator only has one output port. Which certainly makes the graph easier. This could potentially also mean changes (simplification) for ALang.

However some operators need the multiple ports, or at least @sertel said tail recursion needs it. Which means nth needs some mechanism for recognizing when a value is to be dropped and not sent on.

Extensibility

What I would like very much about this is that it would make it much easier to implement other kinds of destructuring in the future, if we so desire.

[sertel]

These are very good points, especially the aspects under "Operator", we need to discuss.

With this in place, the backend becomes simpler (because an sf can have only a single output port) and I can remove some rather complicated code from the JVM integration and the ALang becomes simpler because we can even consider removing the Destructure binding type.

I did not get the point with multiple output ports because what we describe here was meant to address only stateful functions. Operators are still dataflow operators and can have any number of input and output ports.

I agree with the extensibility point too.

We should iterate the first part to make sure, we have a clever design. Let me start:
I believe that nth is not an operator, it is a (stateful) function. Now, how do we go about integrating integers?
Note at this point that we recently already introduced boolean values. When I say this, I actually mean that we introduced a mapping (functions) that use the boolean representation of the target language.
I disagreed to introduce booleans via Env because I wanted to have functions. (This is what Haskell does too.)
Maybe for integers though it makes sense because the representation does not vary across languages, i.e., 1 is the value 1 in all (I hope this is true) languages.

[JustusAdam]

We (@sertel and me) propose/commit to the following road map:

Necessary changes

• Support for creating integer env constants
• Generate nth calls instead of Destructure bindings

Optional, later changes

• Support env expressions in frontend
• Completely remove destructuring from ALang

[sertel]

@JustusAdam in Ohua.Internal.Monad the following type class is defined:

class HasEnvExpr m =>
      MonadRecordEnvExpr m
    where
    addEnvExpression :: EnvExpr m -> m HostExpr
    default addEnvExpression :: ( MonadTrans t
                                , Monad n
                                , MonadRecordEnvExpr n
                                , t n ~ m
                                , EnvExpr m ~ EnvExpr n
                                ) =>
        EnvExpr m -> m HostExpr
    addEnvExpression = lift . addEnvExpression

Can we use this addEnvExpression function to create Env args for the purposes of this issue?

[sertel]

Just as a comment to be considered for this: In the new generic backend, an integer literal is part of almost every syntax for the languages that we target.

[sertel]

I thought about this again and think that we should go with the proposal from @JustusAdam to introduce IntegerLiterals (and thereby Literals in general) into the compiler. These have to be propagated to the backend which then implements them.

[sertel]

I think we addressed all the points in the above list and therefore I'm closing this issue. Please open separate ones for the tasks that may still be pending.