I wanted to figure out the possibility to convert the following statement into terms (not relations) but without the warning of Singleton variables: PERSON while compiling.
Alex likes everyone who likes icecreams.
My following logic gets the Singleton Warning which I want it to remove. The code works fine though.
likes(alex,likes(Person,icecreams)).
The following gives you the same as your try without the warning :
likes(alex,likes(_,icecreams)).
Related
I'm currently working on an Elixir project, compiled with Mix, that as a lot of clauses with the same name and arity (number of arguments) should be grouped together warnings. The problem is that it is a choice to not group it together (for logical reasons), so I try to find a way to silent this type of warning.I did some research, and I learned about the #compile attribute which allows to silent some warnings like :nowarn_unused_vars for example, but since the "same name and arity group" warn seams to be an Elixir warning, it can't be silent this way, so I'm looking for another solution without having to move the functions.Thanks for your help.
I believe the answer is that you can't.
Recalling a discussion from 2015 in the Elixir Google Group: How do you disable specific warnings.
Per José:
Honestly, releasing/deploying code with warnings is not an option in
my book. The reason we emit warnings instead of errors is because
there is no reason to make your compilation fail right out of the box,
better to collect the warnings and show them for all files, instead of
have the frustrating process of fixing one error just for another one
to show up. That's also why we don't plan to provide options for
disabling warnings: they should be fixed, even if they don't error out
upfront.
There was a suggested compromise in the thread that may work for you and simultaneously keep the functions you wanted grouped:
def event(:x, var), do: one_thing(var)
def event(:y, var), do: another_thing(var)
def event(:z, var), do: something_else_entirely(var)
Good luck!
I added sorbet to a pet project of mine: https://github.com/Trevoke/SGFParser
When I run the tests, I get a lot of the following warning (here's a link to a travis-ci build):
/Users/trevoke/.rbenv/versions/2.6.0/lib/ruby/gems/2.6.0/gems/sorbet-runtime-0.4.4314/lib/types/private/methods/call_validation.rb:807:
warning: method redefined; discarding old add_error
/Users/trevoke/.rbenv/versions/2.6.0/lib/ruby/gems/2.6.0/gems/sorbet-runtime-0.4.4314/lib/types/private/methods/_methods.rb:127:
warning: previous definition of add_error was here
Where "add_error" is a method of mine -- the other warnings show different method names.
I'd like to know if this is something which belongs entirely on the sorbet side or whether I can do something to get rid of them.
There doesn't seem like you can do anything on your side right now. It might be related to Sorbet#1150: "sorbet-runtime causes many warnings with Ruby $VERBOSE mode".
There's an open PR (Sorbet#1266) that could help.
I'm going through the book Programming for Artificial Intelligence by Ivan Bratko, I'm stuck on a basic problem and running into an error and the previous answers on stack overflow don't seem to be helping.
I'm stuck trying to write a rule using a previous fact as an argument and getting the error
Single variables: [Y]
the code I'm trying to run is this
parent(myfather,me).
parent(mymother,me).
happy(X) :-
parent(X,Y).
I've managed to make rules like this in the past and I think i'm just missing something very obvious as to why this isn't working. I think that when this compiles and I run
happy(myfather).
It will return true as it will replace X in the happy rule with myfather, then check parent(X,Y) with parent(myfather,Y). and try to then see if there is a fact that says parent(myfather,somethingelse....).
I'm also using swipl on macOS if that is relevant, thanks.
EDIT:
I hadn't checked but the program actaully works as it should but still gives the warning, it makes sense however is there any way of getting rid of the error or an understanding of why the error is there?
Singleton variables is a warning, not an error.
It is meant to remind you that you have a named variable occurring only once within a rule.
If you want to suppress the warning for that particular variable, rename it to a name beginning with underscore (e.g. _Y), e.g.:
happy(X) :- parent(X, _Y).
or rename it to _ (anonymous variable), e.g.:
happy(X) :- parent(X, _).
This type of warning is very useful for spotting typos, such a mistyped variable name:
happy(Child) :- parent(Chidl, Parent), happy(Parent).
Warning: Singleton variables: [Child,Chidl]
or other kind of typos, such as a period typed in place of a comma:
happy(Child) :- parent(Child, Parent). happy(Parent).
Warning: Singleton variables: [Parent]
Warning: Singleton variables: [Parent]
or other logical errors.
Without the singleton variable warning, these errors would go unnoticed and would be more difficult to track down.
So, seeing this warning usually rings a bell for looking for other type of errors as well. If there are no other errors, then just fix the singleton variable by making it anonymous.
If you know what you are doing, you can globally disable the warning with:
:- style_check(-singleton).
I know this is an old question, but i get the solution for that, if you got Singleton variables: [Y] error message, please check your code and your Queries is it mixed with upper-case, lower-case or not. Because Prolog is case sensitive.
I am trying to learn how to use the DrRacket debugger's annotate function. My ultimate aim is to build a REPL that you can execute from within a closure and have access to everything that's in scope. (see my previous question on that topic and Greg Hendershott's well-researched answer) For the time being, I'm just trying to explore how the annotate function works. You can see my first exploratory attempt at using it, and the results, here.
The error, which is happing inside of the annotator, seems to arise when it tries to match he application of string-append. The matcher is looking for a #%plain-app and the expanded syntax I'm presenting to it contains an #%app. I'm unsure if I should be expanding the syntax differently so it comes out as a #%plain-app or if there's something else I'm doing wrong to produce the syntax I'm feeding into the annotator. Does anybody see where my error is?
This revision to my previous pasterack post is swallowed without complaint. It seems that the syntax match must take place on a top-level syntax object (ruling out anything that could happen in an expansion phase, like a macro), and expansion must take place with a current namespace attached. There are some more subtleties in the syntax match, particularly around the fact that the syntax object needs to be free-identifier=? to #%plain-app. For all the gory details, refer to the mailing list thread I started.
After playing with Code Analysis for a small project I am working on, I am wondering just how severe I should be when resolving code to be analytically compliant.
I know I can suppress warnings for this, but to me, suppressing a warning to some extent is a Cop-out (no pun intended..."FXCop").
Example warning:
Do not raise exceptions in unexpected
locations 'CustomObject.Equals(object)' creates an exception of type
'ArgumentException'. Exceptions should not be raised in this type of
method. If this exception instance might be raised, change this
method's logic so it no longer raises an exception.
Reason for throwing this...
CustomObject.Equals(object) might try and compare CustomObject to FooBarObject...which aren't even of the same type, so in this instance, should I throw an exception, or just return false?
In general, should I be really anal (for want of a better word) in making my code absolutely compliant, or will I come across situations where warning suppression will become necessary?
FxCop warnings are just warnings, they don't flag invalid code. That's the job of the compiler. The rules FxCop uses were collected from years of experience writing .NET code. They represent "best practices" and in general are there to remind you of unintended consequences and the more obscure parts of .NET programming, like CAS.
Always refer back to the documentation to see why the rule exists. For CA1065 you'll see:
An Equals method should return true or false instead of throwing an exception. For example, if Equals is passed two mismatched types it should just return false instead of throwing an ArgumentException.
Which exactly matches your usage, you'll have no trouble adopting the advice. Unfortunately it is a bit short on the exact reason the rule was created. Which really doesn't go beyond the "don't throw in unexpected places" guidance. The unintended consequence here is that another programmer that uses your class won't realize that a try/catch would be needed if he doesn't want the code to fail. Feel free to put a Debug.Assert() in your Equals method. There are plenty of cases where you'll want to ignore the advice, CA2000 is particularly prone to false warnings for example. Apply the [SuppressMessage] attribute if necessary to not have to look at it again.