Skip to content
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

Closed
julianhyde opened this issue Dec 7, 2023 · 0 comments
Closed

Comments

@julianhyde
Copy link
Collaborator

FromBuilder should remove trivial yield between two scans. For example, the query

from i in [1, 2] yield {i} join j in [3, 4]

has a yield after a scan that defines i and before a scan that defines j. The yield is trivial because it returns a record with all variables in scope (just i) and therefore it should simplify to

from i in [1, 2] yield {i} join j in [3, 4]

But it does not remove the yield. At the point where it checks whether the yield is trivial, FromBuilder has already (wrongly) added j to the scope and therefore does not think yield {i} is trivial.

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant