-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
exploiting colon for custom infix operators #6946
Comments
I think this is very clever. I'd really like to have this ability, too, but the fact that it defines a fourth meaning for |
Nice. I'm reminded of: |
I don't think there is likely to be confusion with the use of colon for ranges I don't see much potential for conflict: it is not really reasonable to have an |
I don't think this is such a good idea. Something as primitive as a The Datetime package actually makes use of colons with a function argument |
Another way to look at this is that given an expression
|
Having once myself suggested [x op y] for this kind of thing I also think |
Maybe a unicode character could fill in for colon there?
if we make it |
Yes, that could be a possibility. But I'm not sure about ‖, it looks to me like we are taking the norm of the operator b. On Sat, May 24, 2014 at 10:38 AM, Keno Fischer notifications@github.comwrote:
|
Yeah, I noticed that too, but another character. |
Inlining etc. could be fixed by eventually implementing special handling for |
Maybe |
Any character other than |
My two cents FWIW. If at all infixed functions are a go, I'd like to recommend back ticks.
Edit: Oh, I missed the part about doing this without parser changes. |
It's not so much that parser changes are particularly hard as that they are potentially very disruptive. The fact that colon-based infixing can be done with 3 lines of user-level code is an indication that the change will have little impact on the rest of Julia. (You might eventually want parser changes even for colon infixing for the reasons Jeff mentioned, but these will mainly be optimizations.) |
As for colon, I think it's better to let this remain possible, as it is, than to make a documented base feature out of it just because it is possible. |
Clever as it is, syntax punning with the colon/range construction is a bad idea. We've very carefully kept the meanings of each generic function quite consistent so far. Let's not squander that. |
Okay, it seems like the consensus is against this; good to air the discussion, though. |
Glen O made a very interesting proposal on the mailing list: if we simply add definitions
then any function can be used as an infix operator simply by surrounding it with colons. e.g.
17 :mod: 5
works (and gives2
).Possibly modulo some minor cleanups (
:+:
and:-:
appear to be parsed specially, and it's not clear if we want to keep this behavior which is apparently(?) undocumented), this would give a very clean way to define arbitrary infix operators (see also #4498, #2703, and #552), similar in spirit to Haskell's17
mod5
but without any parser changes.cc: @StefanKarpinski, @JeffBezanson
The text was updated successfully, but these errors were encountered: