-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FromBuilder
should remove trivial yield
step between two scan
steps
#208
Comments
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Dec 7, 2023
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Jan 11, 2024
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Jan 13, 2024
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Jan 14, 2024
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Jan 18, 2024
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Jan 19, 2024
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Jan 19, 2024
…), and remove `suchthat` keyword We remove `suchthat` because it is superfluous. Previously, `from e suchthat condition1 where condition2` would allow you to define a variable `v` and infer its bounded extent based on conditions, but after this change you can accomplish the same with `from e where condition1 andalso condition2`, and there may be even be intervening clauses. Following hydromatic#208 `FromBuilder` should flatten nested `from` with tuple. Change type of `TuplePat.type` to `RecordLikeType`, because it is always `PrimitiveType.UNIT` or a `TupleType`. In `SuchThatShuttle`, infer extent of `x` from `where x = y.field`, and move `from y` forward if necessary. In `from x where condition`, `x` must be an identifier, or a list of identifiers such as `from x, y where condition`. With `suchthat` we allowed patterns such as `(x, y)`, `{x, y}`, but this makes no sense because we are doing no assignment, and the variables have no intrinsic order (except when composed into a record in the final `yield`). `FromBuilder` now checks that the type of the scan variable and extent are consistent. For example, in `from e in emps`, `emps` must be have a list type, and `e` must have the same type as an element of the list. Remove `suchthat` from parser and documentation, remove Op.SUCH_THAT, and remove dead code. Fixes hydromatic#202
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
FromBuilder should remove trivial yield between two scans. For example, the query
has a
yield
after a scan that definesi
and before a scan that definesj
. The yield is trivial because it returns a record with all variables in scope (justi
) and therefore it should simplify toBut it does not remove the yield. At the point where it checks whether the yield is trivial,
FromBuilder
has already (wrongly) addedj
to the scope and therefore does not thinkyield {i}
is trivial.The text was updated successfully, but these errors were encountered: