-
Notifications
You must be signed in to change notification settings - Fork 9
Add draft of standard definitions of list operators to user manual and as a regression #152
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be great to have some tests that test that the builtin operators are equivalent to the definition.
… into listDefStdReg
|
@hansjoergschurr this is now updated to contain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great. However, I think it would be better to not repeat the definitions in the manual and in the test file.
Maybe we need to make the testing infrastructure more general to not have everything in test/?
| definition `$eo_X` in the following signature. | ||
| Including this signature and modifying a Eunoia | ||
| file to use `$eo_` instead of `eo::` should | ||
| have no impact on behavior (apart from performance), unless otherwise noted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should refer to the encoding file here instead of including the definitions. Otherwise, the files will inadvertently diverge.
I think that the comments about the lists operators that only show up after a long list of definitions will be missed by many readers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I agree. I'll refactor this.
| ; Returns true if t and s are equivalent values (ground and fully evaluated). | ||
| ; define: $eo_is_eq | ||
| ; implements: eo::is_eq | ||
| (define $eo_is_eq ((T Type :implicit) (S Type :implicit) (t T) (s S)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one small thing: the documentation says these are Eunoia programs, but most here are define i.e., macros. Maybe the documentation should say that it's either.
tests/eo-definitions.eo
Outdated
|
|
||
| ;;; $eo_cmp | ||
|
|
||
| ; An arbitrary deterministic comparison of terms. Returns true if a > b based |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should be very precise about the assumptions here.
IIRC this ordering can be different from run to run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This definition is accurate, but the documentation indeed is a bit misleading. Saying "arbitrary" here summarizes the behavior, but indeed it isn't arbitrary: it is determined by eo::hash. I'll update the doc.
|
I've addressed the review, PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great 📑
Also adds a test to confirm that the builtin operators behave as the builtin ones, based on the examples from the user manual.
It also makes the contents of this regression part of the user manual.