I've been searching around a bit for way to store variables as a list for future use in different methods. So say one method produces X, another method has one produces Y and so on, I don't know if there is a way to declare a list, append each variable to that list and than call it at the to output everything I've saved in it.
Hope this makes sense. Any help would be great, thanks
You can use assert/1 to store things, like
assert(data(100))
then you can just say
data(X)
later to get X = 100
It sounds like what you want is to have each module call assert with a different predicate.
You can use lists also, but it will probably not be better in any way.
Addition: it is customary in this situation to use predicate names that are unlikely to be used in the interpreter, e.g. ones containing spaces, as in
assert('My Data from Module X'(100,200,300))
Related
I read that it's a good convention to name functions that return a bool like IsChecksumCorrect(Packet), but I also read that it's a good convention to name boolean variables like IsAvailable = True
But the two rules are incompatible: I can't write:
IsChecksumCorrect = IsChecksumCorrect(Packet)
So what's the best way to name vars that store boolean values returned by such functions?
PS: Extra points if you can think of a way that doesn't depend on changing the case (some languages--like Delphi--are case-insensitive).
First of all, there can be difficulties only with functions that don't require arguments, in your example instead the variable should just be called IsPacketChecksumCorrect.
Even with functions with no arguments I think you would only have problems if you were just caching the result of the function, for performance's sake, and you could safely replace all instances of the variables with calls to the function if it weren't for the performance. In all other cases I think that you could always come up with a more specific name for the variable.
If you were indeed just caching, why not just call the variable Functionname_cache? It seems quite clear to me.
If you needed to use a lot this "technique" in your project and _cache seemed too long or you did not like it you could well settle on a convention of your own; as long as you are consistent you can adopt whatever works best for you, people new to the project just need to be explained the convention once and they will easily recognize it ever after.
By the way, there are various opinions on the conventions for the naming of booleans. Personally I prefer to put the subject first, which makes the Ifs more readable, e.g. ChecksumIsCorrect, ChecksumCorrect or ChecksumCorrectness. I actually prefer not to put the Is altogether, the name usually remains clear even if you omit it.
In ruby, Array#delete(obj) will search and remove the specified object from the array. However, may be I'm missing something here but I found the returning value --- the obj itself --- is quite strange and a even a little bit useless.
My humble opinion is that in consistent with methods like sort/sort! and map/map! there should be two methods, e.g. delete/delete!, where
ary.delete(obj) -> new array, with obj removed
ary.delete!(obj) -> ary (after removing obj from ary)
For several reasons, first being that current delete is non-pure, and it should warn the programmer about that just like many other methods in Array (in fact the entire delete_??? family has this issue, they are quite dangerous methods!), second being that returning the obj is much less chainable than returning the new array, for example, if delete were like the above one I described, then I can do multiple deletions in one statement, or I can do something else after deletion:
ary = [1,2,2,2,3,3,3,4]
ary.delete(2).delete(3) #=> [1,4], equivalent to "ary - [2,3]"
ary.delete(2).map{|x|x**2"} #=> [1,9,9,9,16]
which is elegant and easy to read.
So I guess my question is: is this a deliberate design out of some reason, or is it just a heritage of the language?
If you already know that delete is always dangerous, there is no need to add a bang ! to further notice that it is dangerous. That is why it does not have it. Other methods like map may or may not be dangerous; that is why they have versions with and without the bang.
As for why it returns the extracted element, it provides access to information that is cumbersome to refer to if it were not designed like that. The original array after modification can easily be referred to by accessing the receiver, but the extracted element is not easily accessible.
Perhaps, you might be comparing this to methods that add elements, like push or unshift. These methods add elements irrespective of what elements the receiver array has, so returning the added element would be always the same as the argument passed, and you know it, so it is not helpful to return the added elements. Therefore, the modified array is returned, which is more helpful. For delete, whether the element is extracted depends on whether the receiver array has it, and you don't know that, so it is useful to have it as a return value.
For anyone who might be asking the same question, I think I understand it a little bit more now so I might as well share my approach to this question.
So the short answer is that ruby is not a language originally designed for functional programming, neither does it put purity of methods to its priority.
On the other hand, for my particular applications described in my question, we do have alternatives. The - method can be used as a pure alternative of delete in most situations, for example, the code in my question can be implemented like this:
ary = [1,2,2,2,3,3,3,4]
ary.-([2]).-([3]) #=> [1,4], or simply ary.-([2,3])
ary.-([2]).map{|x|x**2"} #=> [1,9,9,9,16]
and you can happily get all the benefits from the purity of -. For delete_if, I guess in most situations select (with return value negated) could be a not-so-great pure candidate.
As for why delete family was designed like this, I think it's more of a difference in point of view. They are supposed to be more of shorthands for commonly needed non-pure procedures than to be juxtaposed with functional-flavored select, map, etc.
I’ve wondered some of these same things myself. What I’ve largely concluded is that the method simply has a misleading name that carries with it false expectations. Those false expectations are what trigger our curiosity as to why the method works like it does. Bottom line—I think it’s a super useful method that we wouldn’t be questioning if it had a name like “swipe_at” or “steal_at”.
Anyway, another alternative we have is values_at(*args) which is functionally the opposite of delete_at in that you specify what you want to keep and then you get the modified array (as opposed to specifying what you want to remove and then getting the removed item).
I am writing a small program using Prolog. There is a data structure that I want to reuse, so I tried assigning it to a variable:
CitizenProfile = voter_profile(citizen,not_in_prison).
Then I used it like this:
state(alabama, [CitizenProfile]).
However, I am encountering this error when I compile my file from the console:
**[No permission to modify static_procedure `(=)/2'][1]**
==
I even tried declaring the equal sign dynamic, but that didn't solve anything. :(
:- dynamic (=)/2.
The reason for the error is that it looks to Prolog like you're trying to do this:
=(CitizenProfile, voter_profile(citizen,not_in_prison)).
This looks just like any other fact definition. =/2 could just as easily be foobar/2:
foobar(CitizenProfile, voter_profile(citizen,not_in_prison)).
Now, if we were in the middle of some rule body, this might be a legitimate way to establish a variable binding. Then everything would be culminating in this:
foo :- ...,
CitizenProfile = voter_profile(citizen,not_in_prison),
state(alabama, [CitizenProfile]).
That would be the same as saying this:
foo :- ...,
state(alabama, [voter_profile(citizen,not_in_prison)]).
If this expansion is what you're trying to accomplish, there is unfortunately no way to create shorthand in a fact database like this. You could, as #hardmath says, use assertz/1 to accomplish it, which would look like this:
make_database :-
CitizenProfile = voter_profile(citizen,not_in_prison),
assertz(state(alabama, [CitizenProfile])).
This would be kind of sketchy behavior though, because you're putting static information into the dynamic store. In my experience, one doesn't usually want to build up large structures in the database. It's usually cleaner and easier to build several relations and "join" across them in a relational manner. I'm not sure what all you're going to want here, so this is just a sketch, but this is kind of what I'd expect to see:
voter_profile(voter1, alabama, citizen, not_in_prison).
voter_profile(voter2, alabama, citizen, in_prison).
voter_profile(voter3, new_mexico, citizen, not_in_prison).
rather than what I presume you'd be building (eventually), which I picture more like this:
state(alabama, [voter_profile(citizen,not_in_prison), voter_profile(citizen, in_prison)]).
state(new_mexico,[voter_profile(citizen,not_in_prison)]).
The temptation to create a bunch of lists is understandable, but Prolog's database can't really help you with processing them. You'll wind up resorting to a lot of member/2 and O(N) searching which will add up to pretty bad performance. By default, Prolog will index on the first argument, but each implementation defines some indexing declarations you can use to make it index the second or Nth arguments in addition or instead. You can then use bagof/3 or findall/3 to reconstitute the lists if you need all the results.
Probably what you want is to define a dynamic predicate voter_profile/2 and assertz new facts "dynamically" to be remembered by that predicate store (the clause database). I say "probably" because you haven't made it clear how a state (e.g. Alabama) should be related to a particular citizen profile.
See here for the SWI-Prolog builtin assertz/1 documentation and much more on database mechanisms of SWI-Prolog.
I'm trying to make an array-like data structure in Scheme, and since I need to refer to it (and alter it!) often, I want to give it a name. But from what I've read on various tutorial sites, it looks like the only way to name the list for later reference is with define. That would be fine, except it also looks like once I initialize a list with define, it becomes more complicated altering or adding to said list. For example, it seems like I wouldn't be able to do just (append wordlist (element)), I'd need some manner of ! bang.
Basically my questions boil down to: Is define my only hope of naming a list? And if so, am I stuck jumping through hoops changing its elements? Thanks.
Yes, define is the way for naming things in Scheme. A normal list in Scheme won't allow you to change its elements, because it's immutable - that's one of the things you'll have to learn to live with when working with a functional data structure. Of course you can add elements to it or remove elements to it, but those operations will produce new lists, you can't change the elements in-place.
The other option is to use mutable lists instead of normal lists, but if you're just learning to use Scheme, it's better to stick to the immutable lists first and learn the Scheme way to do things in terms of immutable data.
Yes, define is the way to do "assignment" (really naming) in Scheme. Though, if you're writing some kind of package, you might consider wrapping the whole thing inside of a function and then using let to define something you refer to.
Then, of course, you have to have some sort of abstraction to unwrap the functions inside of your "package."
See SICP 2.5 Building Systems with Generic Operations
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-18.html#%_sec_2.5
(append wordlist (element)) is creating a new list. What you might want is to use set! to redirect a reference to the new list, or define a reference to the new list using the same symbol's name.
it seems a trivial point, until you realize that you need consistency. Not being a native English speaker, I prefer to ask both for grammar and for style. Which one must be preferred among these method names, returning a list of URIs, each one associated to an object?
objectUriList()
objectsUriList()
objectUrisList()
objectsUrisList()
Also, do you consider good style to make explicit that the returned object is a list in the method name. Maybe something like objectUris() (or its correct form) would be fine and intuitive in any case.
I am not a native English speaker either. Correct form is either objectUriList or objectUris. Regardless of the number of objects and uris.
Car park = park of cars.
PC storage = storage of PCs.
oak forest
etc.
I would call is objectUriList(), it's just easier to say and essentially correct. It's clear that it returns a List which is a set of Uris, so you don't really need the plural there.
However, your final suggestion of objectUris() is also good, depending on how easy it is to see that it returns a List in your IDE.
objectUriList should be the correct answer.
(Unless the function runs on more than one object and then objectsUriList would be preferable).
I like to specify the returned object in the function name but because this is how I worked for my entire life (ever since crappier programming languages). Nowadays, I believe it's not necessary.
I would definitely go with the objectUris() alternative, omitting the "List" suffix. As you say, tidy and intuitive.
It's better to use ObjectUriList.
It is recommended in some circles not to include type names in member/parameter names, so you should drop the List part, but I find that "ObjectUriList" is much more explicit and meaningful than "ObjectUris", especially when you are likely to also have "ObjectUri" as a name nearby.
I think to differentiate between Array and List, It's good to append Array with 's' and List with 'list'.
I usually try to go with singular namespaces but sometimes and contextually plural namespaces as well. For e.g. if your return is always plural such as some keywords, I go with plural but if it can be singular often times, I stick to singular naming convention.