Reducer dev

[umuro]

// Multiple statements and variables

describe("assignment", () => {
testEvalToBe("x=1; x", "Ok(1)")
testEvalToBe("x=1+1; x+1", "Ok(3)")
testEvalToBe("x=1; y=x+1; y+1", "Ok(3)")
testEvalToBe("1; x=1", "Error(Assignment expected)")
testEvalToBe("1; 1", "Error(Assignment expected)") //No position info from MathJs parse...
testEvalToBe("x=1; x=1", "Error(Expression expected)")
})

[netlify]

✅ Deploy Preview for squiggle-documentation canceled.

Name	Link
🔨 Latest commit	fea990d
🔍 Latest deploy log	https://app.netlify.com/sites/squiggle-documentation/deploys/62560c794535cb0008c7ad5f

[netlify]

❌ Deploy Preview for squiggle-components failed.

Name	Link
🔨 Latest commit	fea990d
🔍 Latest deploy log	https://app.netlify.com/sites/squiggle-components/deploys/62560c79475e460008cca42c

[quinn-dougherty]

Some preliminary comments, may come back for a more substantial pass.

[quinn-dougherty]

testEvalToBe("1; x=1", "Error(Assignment expected)")

This is not par with old squiggle, I think? we allow the evaluation of expressions in a non-bottom-of-file spot. It's not an important feature, but we should think twice about removing it. @OAGr

[OAGr]

This is not par with old squiggle, I think? we allow the evaluation of expressions in a non-bottom-of-file spot. It's not an important feature, but we should think twice about removing it. @OAGr

I think I don't care too much about this case. However, this might break the functionality we currently have of showing each item that's rendered, no matter what the output is. However, my guess is that that's not going to work with the Reducer set up, as is, anyway, so it doesn't matter much. (I'd think)

[umuro]

It is assignment; ... assignment; expr. Because assignments return bindings as a result. If you simply insert an expression then that expression's result passes up as bindings. Oops. To simulate statements in the middle, one has to convert them to "fake" assignments. Your feature is possible. But I need to count the array index and prepend a "_ = " assignment to every statement if they are not the last one. Could be handled as a feature. However, I don't see a use for it in a functional language. There are other ways of creating side effects in the middle. (to be discussed).

[umuro]

This is not par with old squiggle, I think? we allow the evaluation of expressions in a non-bottom-of-file spot. It's not an important feature, but we should think twice about removing it. @OAGr

I think I don't care too much about this case. However, this might break the functionality we currently have of showing each item that's rendered, no matter what the output is. However, my guess is that that's not going to work with the Reducer set up, as is, anyway, so it doesn't matter much. (I'd think)

{1; 2} => {_ = 1; 2} //feasible feature
{1; y=2} // y is unused variable. This is a functional programming mistake

umuro#52

[umuro]

testEvalToBe("1; x=1", "Error(Assignment expected)")

This is not par with old squiggle, I think? we allow the evaluation of expressions in a non-bottom-of-file spot. It's not an important feature, but we should think twice about removing it. @OAGr

Additional note. The philosophy of reducer is connecting a parser with the reducer using "functional semantics". Not implementing it per grammar. The semantic definition assignments is really a function that return bindings. But eventually any grammar is possible. Of course as long as it is a functional language. Not functionalish.

Semantic definitions are how you define the meaning of the parsed grammar.

{1; 2;} can become {_ = 1; 2;} via an additional semantic definition and it can work.
You can even make {1; y=2;} to work. In this case the semantic conversion would be
{_ = 1; y=2; $currentBindings['y'] }

[quinn-dougherty]

Sorry, Components lint and Website lint shouldn't be triggering. I don't know why they're running. I know why it's because of the rebasey MC resolve push. It shouldn't happen on subsequent pushes.

[Hazelfire]

I think I'd like to see a couple of critical features that might require you to give up on the concept of lisp like purity within the reducer:

• I think it's critical that calls to evaluate also return the bindings that were created during that expression. This is because I want to share these variables between different executions. I think evalWBindings will be the main part of the API. But to get the bindings object from previous executions it needs to return the bindings at some point
• It should be possible to return nothing in an execution and give only variables, or return multiple things in an execution. Both of these features would prove useful in practice.

Other than that. I really can't wait to see this in! I'm super excited about this work. Thank you!

[umuro]

• Bindings

Ok. I am adding this as a feature to do. eval will return just an answer but evalWBindings will return the bindings as well
umuro#58

[OAGr]

I think I'd like to see a couple of critical features that might require you to give up on the concept of lisp like purity within the reducer:

I think it's critical that calls to evaluate also return the bindings that were created during that expression. This is because I want to share these variables between different executions. I think evalWBindings will be the main part of the API. But to get the bindings object from previous executions it needs to return the bindings at some point
It should be possible to return nothing in an execution and give only variables, or return multiple things in an execution. Both of these features would prove useful in practice.

@umuro I think it's fine for us to punt these to later, they don't have to be part of this PR. (Especially given that they weren't part of the previous version anyway)

[Hazelfire]

I'd be cool to see this merged, and punt returning the environment down the line. Would love to see that somewhat soon though considering it's the last step needed to get Squiggle notebooks

[umuro]

I think I'd like to see a couple of critical features that might require you to give up on the concept of lisp like purity within the reducer:

I think it's critical that calls to evaluate also return the bindings that were created during that expression. This is because I want to share these variables between different executions. I think evalWBindings will be the main part of the API. But to get the bindings object from previous executions it needs to return the bindings at some point
It should be possible to return nothing in an execution and give only variables, or return multiple things in an execution. Both of these features would prove useful in practice.

@umuro I think it's fine for us to punt these to later, they don't have to be part of this PR. (Especially given that they weren't part of the previous version anyway)

I think I'd like to see a couple of critical features that might require you to give up on the concept of lisp like purity within the reducer:

I think it's critical that calls to evaluate also return the bindings that were created during that expression. This is because I want to share these variables between different executions. I think evalWBindings will be the main part of the API. But to get the bindings object from previous executions it needs to return the bindings at some point
It should be possible to return nothing in an execution and give only variables, or return multiple things in an execution. Both of these features would prove useful in practice.

@umuro I think it's fine for us to punt these to later, they don't have to be part of this PR. (Especially given that they weren't part of the previous version anyway)

umuro#58 Added as a feature. I will provide bindings as a return from evalWBindings.

Changes could be done in future PRs

[umuro]

I think I'd like to see a couple of critical features that might require you to give up on the concept of lisp like purity within the reducer:

* I think it's critical that calls to evaluate also return the bindings that were created during that expression. This is because I want to share these variables between different executions. I think evalWBindings will be the main part of the API. But to get the bindings object from previous executions it needs to return the bindings at some point

* It should be possible to return nothing in an execution and give only variables, or return multiple things in an execution. Both of these features would prove useful in practice.

Other than that. I really can't wait to see this in! I'm super excited about this work. Thank you!

A) Return multiple things. Just build a record or array We have records. Instead of relying on internal structures of resolver. Don't create a script with invisible assumptions.
B) I would rather explicitly return void. Or better a record of the variables.

Instead of hunting variables in the bindings, why don't you write
{a = 1
b = 2
%{a: 1, b: 2}
}

Moreover, we can add the semantic rule that returning nothing is auto constructing a record of variables and returnint it :)

[umuro]

I think I'd like to see a couple of critical features that might require you to give up on the concept of lisp like purity within the reducer:

I think it's critical that calls to evaluate also return the bindings that were created during that expression. This is because I want to share these variables between different executions. I think evalWBindings will be the main part of the API. But to get the bindings object from previous executions it needs to return the bindings at some point
It should be possible to return nothing in an execution and give only variables, or return multiple things in an execution. Both of these features would prove useful in practice.

@umuro I think it's fine for us to punt these to later, they don't have to be part of this PR. (Especially given that they weren't part of the previous version anyway)

I think I'd like to see a couple of critical features that might require you to give up on the concept of lisp like purity within the reducer:

I think it's critical that calls to evaluate also return the bindings that were created during that expression. This is because I want to share these variables between different executions. I think evalWBindings will be the main part of the API. But to get the bindings object from previous executions it needs to return the bindings at some point
It should be possible to return nothing in an execution and give only variables, or return multiple things in an execution. Both of these features would prove useful in practice.

@umuro I think it's fine for us to punt these to later, they don't have to be part of this PR. (Especially given that they weren't part of the previous version anyway)

umuro#58 Added as a feature. I will provide bindings as a return from evalWBindings.

Instead of hunting variables in the bindings, why don't you write
{a = 1
b = 2
%{a: 1, b: 2}
}

[Hazelfire]

Hey! Sorry about the review earlier, I realised that I probably didn't give enough context and it could have seemed overly harsh. I'm very new to coding with other people.

I'd love to see this merged soon, the bindings thing can be done later. I'll put more context as to why bindings is important in #234. But basically the reason I put that review in is because I looked into the future a tad (by merging this on my local machine), saw variables working, but only needed the environment to be returned to recreate a Squiggle Notebook. Because I thought it was a minor change (although I might be wrong), and is to me the most important feature (because it gets us back to the Squiggle Notebook milestone) I thought it would be nice to include it here.

[Hazelfire]

However, that can easily be another story

[Hazelfire]

Hey @umuro , here's your patch for the JS tests to pass

diff --git a/packages/squiggle-lang/src/js/index.ts b/packages/squiggle-lang/src/js/index.ts
index 1a53aa6..4b8cdda 100644
--- a/packages/squiggle-lang/src/js/index.ts
+++ b/packages/squiggle-lang/src/js/index.ts
@@ -88,6 +88,7 @@ function tag<a, b>(x: a, y: b): tagged<a, b> {
 export type squiggleExpression =
   | tagged<"symbol", string>
   | tagged<"string", string>
+  | tagged<"call", string>
   | tagged<"array", squiggleExpression[]>
   | tagged<"boolean", boolean>
   | tagged<"distribution", Distribution>