-
Notifications
You must be signed in to change notification settings - Fork 10
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
Write option max_depth/1 differences #56
Comments
A common issue seems to be counting depth for lists vs other compound terms. |
Results for LVM 6.3.0:
Interesting difference between SICStus and LVM: |
Here is another view to understand some of the assumptions present. After all, a list is kind of a right-associative structure. So let's compare them (here Ciao) with
While |
The closer I look, the uglier it gets. And also the fewer the systems
4-1 is problematic in SICStus, not because of 5-1 but because of 4-2. |
Indeed we should see |
Both CxProlog and LVM output |
A general remark: this option is to help the user to limit large term display by giving it "an idea" of what the term is. The ellipsis meaning "followed by something I suppose you can guess more or less (else increase the depth)". Keeping this in mind, as I user I prefer [...] to [...|...] which is just more cumbersome and add no information (basically I understand that my term is a list). Similarly, I find [1,...] more intuitive than [1|...] (basically I understand my term is a list whose the first element is 1). |
Agree. E.g. I use it in the Logtalk debugger which allows the user to set the max term depth.
Both tell the user that it's a list whose the first element is 1. I have no strong preference here other that consistency and ideally a common output for common case among systems. |
I don't find SICStus coherent (with itself) between 0-1,0-2,0-3 and 1-1,1-2,1-3. It seems variables are treated differently (why not all atomics also ?). This seems confirmed by 2-1,2-2,2-3 wrt 3-1,3-2,3-3. |
Yes, variables are treated differently! A 0-1,0-2,0-3 is quite coherent if you count the operators. In 0-3 there are already variables that do not need to be abbreviated. What is really important is that the abbreviated term can be used to reconstruct (partially) the original term. Think of 4-1 in GNU. This |
Or see this from another level: Before printing, replace some non-variable subterms by |
Interesting ? Do you have a reference for this definition ?
On which systems (other than Sicstus) is it the case ?
Variable names can also be rather large, most of the time (in particular in debugging session) they are written as '_addr
IMHO |
When a variable is replaced by a non-variable term this is called a substitution. See any textbook.
See above Ciao and XSB. If you find another system, try:
You need some consistency in behavior. And, just to reiterate: substitution is a well known operation on variables. So if you are replacing a variable by And printing a very longish variable like the one you mention is a problem with this system. Also note that printing unnamed variables is a problem in itself. To my knowledge, only SICStus has found a way to handle this. But let's leave that out of the discussion here, since you do not have GC.
What do you prefer: a term like |
Maybe printing atomic terms that are shorter or equal to |
To be precise, repeated printing of terms with the same variables is a problem in itself. As for ISO, naming of unnamed shared variables is consistent only within a single invocation of |
My question is not about substitution (which we all know obviously). My question is about " |
That it is used here is Prolog lore. One purpose of standardization is to make these things explicit. |
In very old systems, this feature is only available with the debugger and the option is called |
Thanks for these pointers and for the test-set you provided. It helped me to improve my implementation on the emission of
As mentioned by both of you, 4-1 is not consistent in sicstus thus the "shift" in displays between both systems (which does not appear with vars which are treated differently in sisctus). |
I hope you reconsider your decision to go against this treatment of variables. This simply only means that your systems gets tested less. Like for cases you did not consider
|
What is the output of the following goal (try to reply before testing any system):
All systems I have tried (including ciao, sisctus, ... exception is swi) show |
I agree with your view. Yes, I think that |
So maybe replace such very large terms earlier than the indicated depth. But what is most crucial is that all of it is somewhat testable. That is, replace the dots by variables and then subsumes_term(Generalized, Original) must hold. |
NB: But it allows to shorten large arity terms. In that case, an additional possibility is to limit the number of arguments of a structure displayed (as done for lists) as follows:
|
SICStus:
|
Why not? |
|
Ah, sorry. I misunderstood you. No, exactly because of this, I think these wrongly abbreviated terms do not serve much purpose. And as you have seen for SICStus, its use is quite inconsequential. |
Fixed.
|
(After looking at other systems, it seems evident, that only SICStus, Ciao, XSB have a consistent way of handling this option and handling it the same way (modulo variable names and spaces). )
The text was updated successfully, but these errors were encountered: