Repository navigation
feat(emit): two unnamed forms compare by their parts (#295) - #357
Merged
Merged
Conversation
`==` and `!=` over a list, a map, a set, a tuple and an array were
E9057, on the ground that a container has no declaration to derive
an `Eq` on. It needs none: docs/core/types.md gives an unnamed form
what every one of its parts has.
- a list and an array compare in order, a tuple part by part, a map
and a set whatever order they were filled in
- a part is compared by the `==` a program would write between two
of them, so a str, a declared type's `eq` and a form inside a
form are each decided where they already were
- an operand the expression made is held and given back; one
somebody else holds is read where it stands
- `T: Eq` asks the same predicate, so a `list[int]` meets the bound
- what is refused is the part that cannot be compared, named beside
the form, under the code that part already had
E9057 retires. Its three `refuse` cases go with it; what they asked
is built now.
- reject: a list, a nested map and a derived `Eq` over a part with
no `Eq`; a list of carriers; a tuple holding a channel; the bound
a `list[N]` does not meet; a literal of another element type and
an empty one; an ordering over two lists
- mem-check: both operands of every form are read and given back,
whichever way the answer went. Red with the left operand's
give-back removed: 5070 a round
- strings_test: the comment said two lists cannot be compared
The collections, specs, types, format and package chapters each
said `==` over a container was E9057. They say what compares now,
and the two things beside it that do not: a literal is typed by its
own elements, and `assert xs == ys` over two lists still has to
render them (E4011).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #295. Last task of #285.
What changes
==and!=over two values of one unnamed form are built: alistand an array compare in order, a tuplepart by part, and a
mapor asetwhatever order they were filled in.E9057retires.The rule is the one
docs/core/types.mdalready had — an unnamed form hasEqexactly when every part hasit — so one predicate (
c_eq_legal) answers the operator and theT: Eqbound alike.==a program would write between two of them. The two parts are bound astwo names and the operator is handed back to
c_expr, so astr, a declared type'seq(with the copiesthat call owes) and a form inside a form are each decided where they already were.
!=is the negation. An unnamed form wrote noneto dispatch to.E4020==on a list[N], which compares its N: a N has noEq``,E4038for a carrier, `E4034` for anidentity.
Decided here, and worth a second look
list,mapandset;E9057also covered tuples, the typeschapter gives a tuple
Eqby the same rule, and the code cannot retire with a tuple still under it.bs == [1, 2]over alist[byte]isE3046, andxs == []isE3034. Both were already what the checker said; the collections chapter nowsays so.
Not in this PR
x in xssover a list of containers is stillE9061, and over a list of a declared type with anEq.assert xs == ysover two lists isE4011: the comparison builds, and the message has to render bothsides, which
strover a list does not. A map, a set, a tuple and a declared type are claimed directly.The package chapter says so and gives
assert (xs == ys).E3044, while the types chapter gives a tupleOrdby its parts. Nottouched, not filed.
Measured
Each gate run alone, its own status read:
buildfixpointlintfmt-selferror-codes-checkseed-gapsrefuserejectmem-checkoraclecorpussanitize-corpusmem-peakexamplesdocs-mirrordocs-linksdocs-zergdocs-refuseddocs-repeatmarker-codeschapter-codesdeviation-checkrefusal-citesmethod-gapsgatestreesitterdead-codestdlib-testcompiler-testcheck-equalreject-fuzzfmt-corpusbehaviourconformanceproductionssuitesdesugar— all OK.refuse-check,reject-checkandmem-checkalso under/bin/bash3.2.mem-checkcasecontainer_equality: RED with the left operand's give-back removed(
5070 per round unfreed), green with it.lsp: FAIL throughmake lspon this machine, OK through a copy of the script that keeps its fixturesin an empty directory. The server lists the directory above the buffer,
zrt_listdirsortsquadratically, and this machine's temp directory holds forty thousand entries. Not this change, and not
filed.
make test) was not run.The seed compares no container, so the corpus case is an oracle skip.
🤖 Generated with Claude Code
https://claude.ai/code/session_01N8jd1oK2orM6diHxhvWhC7