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
In #33 we added elem and notelem operators to test for list membership, for example:
from e in emps
where e.deptno elem [10, 30]
andalso e.job notelem ["CLERK", "MANAGER"]
At the time, we chose not to use in because we thought it would conflict with the use of in in the from and join clauses. But since #202, the above example can be expanded to
from e
where e elem emps
andalso e.deptno elem [10, 30]
andalso e.job notelem ["CLERK", "MANAGER"]
and doesn't make much sense that e in emps changes to e elem emps.
I now believe that if we obsoleted elem and used in for both cases it would not make the grammar ambiguous, or the ambiguity could be easily resolved using parentheses, e.g.
# Expression with 'elem'
val f = from e in emps, i elem []
# ...becomes ambiguous when using `in`
val b = from e in emps, i in []
# ...but can be resolved with parentheses
val b = (from e in emps, i) in []
# ...and besides, was invalid because 'i' is not safe (has no deducible range)
The ambiguity only arises if in occurs after the from expression (and any join clauses).
from a in b in c
is unambiguously equivalent to
from a in (b in c)
because a is syntactically a pattern, not an expression, and must not contain in. The expression
let
val b = [1]
val c = [[0], [2]]
in
from a in b in c
end;
should return val it = [false]: boolean list.
There is potential ambiguity due to in in the let <decls> in <expr> construct. For example, the following contains in 3 times:
let
val administrators =
from e in emps
where e.job in ["MANAGER", "CLERK"]
in
List.length administrators
end;
If we do this, we should also replace notelem with notin. (Not notIn, for reasons noted in commit 9566f8b.)
The text was updated successfully, but these errors were encountered:
In #33 we added
elem
andnotelem
operators to test for list membership, for example:At the time, we chose not to use
in
because we thought it would conflict with the use ofin
in thefrom
andjoin
clauses. But since #202, the above example can be expanded toand doesn't make much sense that
e in emps
changes toe elem emps
.I now believe that if we obsoleted
elem
and usedin
for both cases it would not make the grammar ambiguous, or the ambiguity could be easily resolved using parentheses, e.g.The ambiguity only arises if
in
occurs after thefrom
expression (and anyjoin
clauses).is unambiguously equivalent to
because
a
is syntactically a pattern, not an expression, and must not containin
. The expressionshould return
val it = [false]: boolean list
.There is potential ambiguity due to
in
in thelet <decls> in <expr>
construct. For example, the following containsin
3 times:If we do this, we should also replace
notelem
withnotin
. (NotnotIn
, for reasons noted in commit 9566f8b.)The text was updated successfully, but these errors were encountered: