You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The conversion from Source to Core can be simplified a bit.
Lets are currently converted to a tuple of the input value and the let-bound expression. This was necessary in the original Core language because the streaming operations (Map, Filter) explicitly specified their input streams.
With the new Core, there are no explicit streams, and the body of folds and filter expressions can just refer to previously bound names. That means the let can be simplified to just the let-bound expression, and each reference just needs to refer to its name, rather than "first of input stream of blah".
I don't think this is resulting in worse end-result code right now, but it might be making flatten and melt a bit slower.
The text was updated successfully, but these errors were encountered:
This is a bit more effort than I thought because the tupled version is still used by (latest x ~> fold f) (perhaps other things?).
In latest x ~> fold f, we store the whole tuple of everything that is in scope in the buffer, and then fold over it at the end.
We will need to modify latest to only store a tuple of what's actually used.
This is totally doable but I suspect there are lower-hanging fruit.
The conversion from Source to Core can be simplified a bit.
Lets are currently converted to a tuple of the input value and the let-bound expression. This was necessary in the original Core language because the streaming operations (Map, Filter) explicitly specified their input streams.
With the new Core, there are no explicit streams, and the body of folds and filter expressions can just refer to previously bound names. That means the let can be simplified to just the let-bound expression, and each reference just needs to refer to its name, rather than "first of input stream of blah".
I don't think this is resulting in worse end-result code right now, but it might be making flatten and melt a bit slower.
The text was updated successfully, but these errors were encountered: