3 ms·

On your last point I’ve been toying with the idea of having even the function it self folded into that struct the struct defines the unbound inputs ad well as

On your last point I’ve been toying with the idea of having even the function it self folded into that struct the struct defines the unbound inputs ad well as mapping those to different named outputs one interesting aspect to play around with is to then have commutative, and associative, application/evaluation operation where structs (or environments really) are merged and evaluated by binding what can be bound say (a,b:1+a)(b,a:1,c:a+b,d:2) would evaluate to (a:1,b:2,c:3,d:2) not saying its a good idea - kind of falls down on scoping - bu could be an interesting toy.

ianbicking 5y ago
This makes me think about some sort of exec-with-dynamic-scope approach to functions, like: func = { b = 1 + a } result = func { a = 1 c = a + b d = 3 } Where func {...} (two adjacent blocks) is like a composition and merges the two blocks. "=" has the mathematical meaning, not assignment but a statement of equality. The parameters are just the free variables, e.g. func has a parameter of a. Are external routines or functions also parameters? I'm inclined to say yes, and that it's interesting to treat them as such. This is all very Mathematica/Wolfram-like, with concrete expressions with undefined terms, different than functions that are executed. The result has no real sense of order, and so it implicitly has to be purely functional. I can imagine using this to build things-that-execute, where this code doesn't execute but defines an execution (like tensorflow). Or there's some outside layer that creates streams of input, and the "execution" is how it responds to those streams. That outside layer is where all the system integration happens. It would work well with React-style unidirectional data flow. But I think for any practical program you'd have to live in both worlds.

ianbicking 5y ago

This makes me think about some sort of exec-with-dynamic-scope approach to functions, like: func = { b = 1 + a } result = func { a = 1 c = a + b d = 3 } Where func {...} (two adjacent blocks) is like a composition and merges the two blocks. "=" has the mathematical meaning, not assignment but a statement of equality. The parameters are just the free variables, e.g. func has a parameter of a. Are external routines or functions also parameters? I'm inclined to say yes, and that it's interesting to treat them as such. This is all very Mathematica/Wolfram-like, with concrete expressions with undefined terms, different than functions that are executed. The result has no real sense of order, and so it implicitly has to be purely functional. I can imagine using this to build things-that-execute, where this code doesn't execute but defines an execution (like tensorflow). Or there's some outside layer that creates streams of input, and the "execution" is how it responds to those streams. That outside layer is where all the system integration happens. It would work well with React-style unidirectional data flow. But I think for any practical program you'd have to live in both worlds.