Scp5 #3115
Scp5 #3115
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3115 +/- ##
============================================
+ Coverage 76.16% 78.11% +1.94%
- Complexity 13170 13744 +574
============================================
Files 1085 1023 -62
Lines 65189 59970 -5219
Branches 7289 7004 -285
============================================
- Hits 49651 46845 -2806
+ Misses 12830 10775 -2055
+ Partials 2708 2350 -358 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Cole-Greer
left a comment
Cole-Greer
left a comment
There was a problem hiding this comment.
Thanks @mschmidt00, I completely agree here. The gremlin semantics docs are really intended to clear up any ambiguity as to what is a defined gremlin semantic, and what is an implementation detail. This is remains an incomplete project today. I agree that the lack of guarantees about evaluation order is currently a key missing section in there, and providing users standardized patterns to force specific semantics in any system is a nice addition.
VOTE +1
|
|
||
| In this proposal we argue that guarantees for and control over lazy vs. eager evaluation order should be a well-defined aspect of the Gremlin language that has to strike the right balance between (a) imposing a minimal set of constraints by default, as to leave implementers the freedom to apply optimizations for the general cases (and account for the variety of approaches that Gremlin engines implement today) while (b) providing Gremlin users the freedom to specify and constrain flow control whenever they depend on it. With these goals in mind, our proposal is as follows. | ||
|
|
||
| ===== Proposal 1: By default, the Gremlin semantics shall NOT prescribe lazy vs. eager evaluation order ===== |
There was a problem hiding this comment.
100% agree. Gremlin tends to be overly prescriptive, and would benefit from explicitly allowing more implementation defined behaviour in certain places. It's even worse in this example as it's currently ambiguous if lazy evaluation order is actually a defined gremlin semantic, or merely an implementation detail of the reference implementation (I believe it's the latter but that needs to be made explicit).
|
VOTE +1 |
1 similar comment
|
VOTE +1 |
|
I have cherry-picked the proposal down to the 3.8-dev branch in commit 25c25c3. Closing this PR. |
5 participants
This is an updated version of #2898