-
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
from
should not have a singleton record type unless it ends with a singleton record yield
#159
Comments
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Jul 28, 2022
…ds with a singleton record yield If a `from` expression has one variable named `i` of type `int`, should the type of the returned elements be `int` or `{i: int}`? (We call `int` a scalar, `{i: int}` a singleton record type, `yield {i = i}` a singleton record yield, and `yield {i = j, j = k}` a renaming yield.) After this change, `from` will have a singleton record type only it ends with a singleton record yield. If it does not end in yield, the type depends on N, the number of pipeline variables, and will be a scalar if N = 1 and a record with N fields if N != 1. As part of this change, we introduce a new `class FromBuilder` to safely build `Core.From` pipelines. It performs micro-optimizations as it goes, such as removing `where true`, empty `order` and trivial `yield` steps. `FromBuilder` can also inline nested from expressions: from i in (from j in [1, 2, 3] where j > 1) where i < 3 becomes from j in [1, 2, 3] where j > 1 yield {i = j} where i < 3 Note the use of `yield {i = j}` to handle the variable name change caused by inlining. Ensure that `from d in scott.depts` is not printed as '<relation>' even if it is optimized to `scott.depts`. If we write `scott.depts` in the shell, the shell prints '<relation>' because `depts` may be a large table. `FromBuilder` now simplies `from d in scott.depts` to `scott.depts`, but we want the shell to print the rows, not '<relation>'. Therefore the shell now calls `Code.wrap` to tag whether an expression would be treated as a relation or as a query. Fixes hydromatic#159
julianhyde
added a commit
to julianhyde/morel
that referenced
this issue
Sep 25, 2022
…ds with a singleton record yield If a `from` expression has one variable named `i` of type `int`, should the type of the returned elements be `int` or `{i: int}`? (We call `int` a scalar, `{i: int}` a singleton record type, `yield {i = i}` a singleton record yield, and `yield {i = j, j = k}` a renaming yield.) After this change, `from` will have a singleton record type only it ends with a singleton record yield. If it does not end in yield, the type depends on N, the number of pipeline variables, and will be a scalar if N = 1 and a record with N fields if N != 1. As part of this change, we introduce a new `class FromBuilder` to safely build `Core.From` pipelines. It performs micro-optimizations as it goes, such as removing `where true`, empty `order` and trivial `yield` steps. `FromBuilder` can also inline nested from expressions: from i in (from j in [1, 2, 3] where j > 1) where i < 3 becomes from j in [1, 2, 3] where j > 1 yield {i = j} where i < 3 Note the use of `yield {i = j}` to handle the variable name change caused by inlining. Ensure that `from d in scott.depts` is not printed as '<relation>' even if it is optimized to `scott.depts`. If we write `scott.depts` in the shell, the shell prints '<relation>' because `depts` may be a large table. `FromBuilder` now simplies `from d in scott.depts` to `scott.depts`, but we want the shell to print the rows, not '<relation>'. Therefore the shell now calls `Code.wrap` to tag whether an expression would be treated as a relation or as a query. Fixes hydromatic#159
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If a
from
expression has one variable namedi
of typeint
, should the type of the returned elements beint
or{i: int}
? (We callint
a scalar,{i: int}
a singleton record type,yield {i = i}
a singleton record yield, andyield {i = j, j = k}
a renaming yield.)After this change,
from
will have a singleton record type only it ends with a singleton recordyield
. If it does not end inyield
, the type depends on N, the number of pipeline variables, and will be a scalar if N = 1 and a record with N fields if N != 1.Before this change, that would depend on whether there was a singleton record yield (such as
yield {i}
oryield {i = i}
oryield {i = j}
oryield {i = j + 2}
) somewhere in the pipeline, as follows:This behavior is unsatisfactory. It requires that a pipeline remember whether there is a singleton record yield somewhere in the pipeline.
After this change, the only thing that counts is whether the last step is a yield. To return singleton records, the last step must be a singleton yield, for example
yield {i = i}
(or the shorthandyield {i}
), or a renameyield {j = i}
, or an expressionyield {k = i + j + 3}
.If the last step is not a
yield
, the result is scalar if there is one variable, a record otherwise. Here are the above expressions after the change:The pipelines whose types have changed (6, 8, 10) are those that contain a
yield
but do not end inyield
.As example 8 shows, you can now use a singleton yield (
yield {j = i}
) to rename the variable without forcing the result to be a record type. You would not want to use a singleton yield as the last step, because there are no downstream steps to use the new variable name.As part of this change, we introduce a new
class FromBuilder
to safely buildCore.From
pipelines. It performs micro-optimizations as it goes, such as removingwhere true
steps.FromBuilder
can also inline nestedfrom
expressions:becomes
Note the use of
yield {i = j}
to handle the variable name change caused by inlining.The text was updated successfully, but these errors were encountered: