isn’t that the textbook definition of ambiguity
ambiguity
the quality of being open to more than one interpretation; inexactness.
1 Like
It’s close, hence the confusion.
If a statement has one meaning in circumstance A, and a different meaning in circumstance B, and you cannot determine which meaning is the correct one (that is, you cannot determine whether this is circumstance A or B), then you have an ambiguity on your hands. You don’t know, or maybe cannot know which meaning is the correct one.
If A and B can clearly be determined, that resolves the ambiguity, and that is the case here (you can always tell if the input is a type, or not–well, that is what I assume.)
Sorry that this has now turned into a lot of nitpicking, but I genuinely thought there was a real ambiguity here, and wanted to understand it.
1 Like
This is a logically, well, trivial statement since if A and B are the two sets that were ambiguous (i.e. they intersects), you can always make two new sets A’ and B’ by assign the intersection of A and B to A.
In another word, (repeat almost exactly what I’ve said above) just because you can make an unambiguous definition on top of an ambiguous one does not means the ambiguity is not there. If it is allowed to add arbitrary qualifiers to the condition (i.e. adding non-type condition of fieldnames on values) then ambiguity will never be a valid argument for anything, ever. Since this doesn’t seem to be what you suggest, you have to use the original definition of A and B (that do not have arbitrary qualifier applied) and in that case they are clearly ambiguous.
I would add that this is indeed not the definition of ambiguity for dispatch, which is narrower (since we also define specifity there) but it exists at all also because we don’t want to add arbitrary qualifiers to resolve it.
1 Like
Well, I don’t agree with with this, but that isn’t really very important or interesting for the actual discussion here. I thought you were referring to some completely different and unresolvable ambiguity, now I see that you were not. I will simply agree that the previous behaviour could be confusing, and that the change is fine.
A key difference is the “Do what I want” (give me the most reasonable field names, if I don’t give you a type, apply typeof first) versus “Do what I say” (give me the fieldnames of the type, if the input is not a type, error). The more fundamental a function is (for example I believe this applies to all functions in Julia Base), the more it should be on the “Do what I say” side, as it makes it easier to build more complex things on top of it. The “Do what I want” approach is nicer for the user, but less so when used to develop more complex code on top of it. For example in Plots.jl (which is mostly targeted at users) there are a lot of cases of “Do what I want” to simplify the users life, but Julia Base has to go with “Do what I say”.
3 Likes
That theoritically can’t possibly exist so I couldn’t have been referring to one.
Although propertynames(x) defaults to fieldnames(typeof(x)), because it is is designed to be overloaded you cannot rely on this.
Note that propertynames(x) only works on instances, not on types, and its return value is intenddd to correspond to the “dot overloading” in Julia 0.7. Since you overload getproperty per instance, not per type, so too with propertynames.
For example, once Julia 0.7 is out, I plan to have a new release of PyCall in which you can do o.foo in Julia for o.foo in Python (instead of o[:foo] as you do in PyCall now). Here, o is of type PyObject, and which property names (corresponding to Python attributes) it has must be determined dynamically based on the instance o.
4 Likes
I don’t like your tone. Please be more polite.
4 Likes
The longer version was given above, in at least two different ways including examples Why will we have to say fieldnames(typeof(v)) instead of fieldnames(v)? - #43 by yuyichao. You simply said you did not agree, followed by claiming that I was talking about something that cannot exist at all without explanatioin. This is therefore the shortest form I can think of that emphasize on the important part of the argument in case the longer form was not clearly pointing to what was not possible to exist.
Feel free to suggest edit as I can’t see which part of it you don’t like as a non-native speaker.
I was reacting to your reply being snarky. I don’t know how to edit out this type of snark. I am not a native English speaker either. I also put it in context with your previous remark (“good to know”) that had a similar tone.
I have consistently been trying to understand what you were talking about with respect to this ambiguity. Since I disagree (and have explained why) that what you describe is an ambiguity, I thought that you were referring to some other ambiguity that I failed to grasp (e.g. relating to deciding whether something is a type or not), but then concluded, finally, that I understood that you were not.
As far as I understand you now, you are saying that something can be ambiguous, even when the ambiguity can be resolved. I would prefer to just agree to disagree on that point, and stop.
1 Like