-
-
Notifications
You must be signed in to change notification settings - Fork 60
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
refactor based on overloading Base.show
.
#163
base: master
Are you sure you want to change the base?
Conversation
show
.Base.show
.
One potential problem with this approach is that Latexify.jl does not own |
refactor_show_prototype.jl
Outdated
|
||
show(io::IO, ::MIME"text/latexify", x) = print(io, x) | ||
|
||
compare_precedence(a, b) = Base.operator_precedence(a) > Base.operator_precedence(b) |
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'm not entirely sure this will do the right thing for things like 1 - (2 + 3 + 4)
-- here the precedence is equal, but compare_precedences
will return false
. Perhaps that is solved by changing the >
to >=
, but will it then do the right thing for 1 - (2 - 3 - 4)
?
I guess the show
method for :-
could give :+
as precedence for left and :-
for right.
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 agree, this will not always do the right thing
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'm not even convinced that operator_precedence
is reliably good for latex purposes. I think one might find plenty of cases where code would need parentheses while latex would not.
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.
If there exists such an ordering, it's pretty simple to implement your own operator_precedence
. Otherwise one might need individual compare_precedence(::Val, ::Val)
functions.
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.
individual comparisons is pretty much what I have been doing before (not saying that this it the way to go). It turned out not to be needed too frequently though. -
and ^
turned out to be the ones which needed the most care in figureing out where parentheses are needed.
Codecov Report
@@ Coverage Diff @@
## master #163 +/- ##
=======================================
Coverage 60.21% 60.21%
=======================================
Files 23 23
Lines 734 734
=======================================
Hits 442 442
Misses 292 292 Continue to review full report at Codecov.
|
I haven't worked with precompilation, but don't you just need to own the methods? |
One advantage of #161 over this approach is that it would be possible to let the list of matching functions be passed in as a Here, all extensions are global and the overloads created in one package might bleed over and affect others. If a user wanted to, for example, strip away all macro call annotations they could overload In #161 it might be possible to let extending packages do what they want while keeping the effects confined to only apply when the top-level call takes their own types. There could then be two modes of extension - local or global (for things like UnitfulLatexify.jl). Here, only global is possible. |
This is a competing refactorisation to #161
It overloads
Base.show
withMIME"text/latexify"
. This could allow others to extend latexify's functionality without ever even loading Latexify.jl itself.It's based on suggestions by @gustaphe #110