Comments (4)
Prompted by the discussion in JuliaGraphs/Graphs.jl#249, I'm reconsidering the implementation of this feature.
Before delving into the specifics of annotations, I want to discuss a higher-level approach to implementation. As it stands, the current JET hasn't yet been integrated with JuliaSyntax, hence it seems more convenient to first adopt a macro-based approach, e.g.:
JET.@promise_correct function myfunc(args...)
[...]
end
Using a macro would necessitate adding a dependency on JET.jl (or a lightweight helper package solely for annotation) on user package side. This would enable us to convey information about user code to JET more simply and reliably. Adding JET.jl to user package dependencies purely for annotation feels excessive, so I propose creating a helper package (let's tentatively call it JETAnnotations.jl) that only defines macros for annotation.
Of course, the comment-based approach is attractive in that it doesn't need any dependencies at all, and I would like to give it a shot in the future. However, I'm a little apprehensive due to concerns about the implementation cost.
Nonetheless, I believe we can maintain compatibility (in most respects) between the macro-based and comment-based features. Therefore, I'm considering starting with a macro-based approach, letting users to experimentally use this feature. Do you have any thoughts or insights on this idea?
/cc @jlapeyre
from jet.jl.
As it stands, the current JET hasn't yet been integrated with JuliaSyntax, hence it seems more convenient to first adopt a macro-based approach...Using a macro would necessitate adding a dependency on JET.jl (or a lightweight helper package solely for annotation) on user package side
Since JuliaSyntax has landed in master
, personally I would just make 1.10 a requirement for next-generation JET features. It seems more painful and less readable to putative JET contributors (besides yourself meta
expressions than an if
statement checking a comment. (EDIT: the original version, due to an incomplete edit, gave the opposite impression of what I intended.)
Of course, there is one huge advantage to making packages dependent on a lightweight annotation package: you can declare [compat]
bounds. That would give you a mechanism to change the annotations you offer and/or how you name them. That might itself be enough to tip the balance in favor of your macro idea.
Your comments about my specific proposals seem very reasonable. I think this is a case where a mix of "what might a JET-naive developer want?" and "someone who knows what an actual implementation might look like" favors modifying my proposals into a form that gives developers most of what we want while also fitting in naturally with JET's internals.
from jet.jl.
Thank you for your comment. Indeed, the ability to use the [compat]
could be a substantial advantage. In the case of a comment-based approach, I anticipate we would need to pay attention to the JET version used for analysis. But it would be more reliable if we can manage the versions of annotations explicitly. Given the challenges associated with the implementation, it seems reasonable to initially adopt a macro-based approach.
As for the features that would be realized after integrating with JuliaSyntax, it seems best to target the v1.10 timeline. This seems like a suitable plan both in terms of code management and my personal bandwidth.
from jet.jl.
- A very simple approach might be to add a comment
# JET_PROMISE_CORRECT
, and JET will avoid analyzing any calls made at this source line. There's a risk, though, that this is overly broad; as packages undergo further development, this might hide errors different from what prompted adding that annotation in the first place- Rewording the above as
# JET_IGNORE_ERRORS
or# JET_NOT_MY_PROBLEM
😆 might be a way to indicate that one wishes to ignore errors from code that one does not plan to fix (e.g., errors from dependencies). Still dangerous, but signals a different intent to readers compared toPROMISE_CORRECT
.
Perhaps it would be effective to distinguish between "global" and "local"? That is, imagine using something like # JET_GLOBALLY_IGNORE
or # JET_LOCALLY_IGNORE
. JET_GLOBALLY_IGNORE
would dismiss all errors within the annotated block or method, including those within dependencies, while JET_LOCALLY_IGNORE
would ignore errors only within the annotated block or method.
# JET_WONTCALL push!(::Tuple{}, ::Any)
could be used to head off reporting a MethodError that matches the stated signature from any callee of this line. This requires parsing and aneval
. Slightly briefer might be to allow dropping the::
but then it's not really Julia syntax🤔 .# JET_HASELEMENT
might be used to avoid reporting spurious bounds-checking errors as in False positive for indexing Union{Tuple{},Vector{T}} #509. However, I suspect there might be a more systematic fix (my impression from the documentation is that false positives in bounds-checking are not supposed to happen)
What do you think about making JET_[GLOBALLY|LOCALLY]_IGNORE
capable of accepting a list of report names as options, and then only those specified reports would be ignored? For example, # JET_WONTCALL
could be expressed as # JET_LOCALLY_IGNORE MethodErrorReport
, and # JET_HASELEMENT
as # JET_GLOBALLY_IGNORE UncaughtExceptionReport
. This would indeed require users to have some understanding of JET's report types, but it seems there would be a comparable learning cost even if we prepare individual annotations. Imposing more specific constraints on MethodErrorReport
(like method signatures) could be a bit tricky, but it should be possible to create a syntax like MethodErrorReport(t=Tuple{typeof(push!),Tuple{},Any})
.
from jet.jl.
Related Issues (20)
- Line numbers do not Revise HOT 2
- False positive: accessing variables from other, possibly undefined modules HOT 1
- Branches that restrict a type HOT 14
- Support "import Module as" syntax HOT 1
- Possible false positive with sort! HOT 4
- Support package extensions HOT 3
- main_uuid not defined HOT 10
- Misattributed instability due to recursion
- Feature request: Catch atomic errors
- JET doesn't find available method? HOT 1
- Weird error involving potential `Missing` in union split HOT 11
- Add a configuration to ignore the case when `x == y` return `missing`? HOT 1
- Reconsider the necessity of `ReportPass`
- Handle version of JET when testing on several versions of Julia HOT 1
- `target_defined_module` does not work when `report_config` is given
- Configure printing during `test_package` HOT 2
- JET.jl false positive "possible error" reported on Union{Bool, Nohing} HOT 2
- JET macros don't show up in VSCode problems when they end with a semicolon
- JET breaking on "using Module: SubModule.Constant"
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jet.jl.