-
Notifications
You must be signed in to change notification settings - Fork 4
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
Strict equivalence? #44
Comments
It's a definition supplied by the programming language of implementation, but the concept is very much grounded in mathematics and CS, and well defined. |
Actually now that I look at it, strict equivalence may be a bridge too far... For the binary format it can make sense because everything is typed and sized. But not so for the text format. Is the CTE And how useful is it anyway? Maybe it's just better to take strict equivalence out. |
As the term "strict equivalence" is never used in the spec (except to define what that term means), I would say it's not terribly useful right now! The only possible use I see for it is in conjunction with schemas, but CE schemas seem to still be a research project. CUE's concept of equality, for example, is very different from either of CE's two kinds: it appears to be both looser than CE strict (different types/sizes may be compared) and stricter than CE relaxed (container types are not comparable). |
Yeah, the problem is that there is no fully satisfactory schema technology out there yet. In my opinion, schema tech in general is still quite immature. |
The CE spec says: "Note: Equivalence is relaxed unless otherwise specified." and then goes on to define "relaxed equivalence" for each type, and then there's a very brief (one sentence) definition of "strict equivalence".
AFAICT, "strict equivalence" is not mentioned anywhere else in the CE, CBE, or CTE specs at all. Is this term meaningful? Is this something one needs to implement? For what purpose?
The text was updated successfully, but these errors were encountered: