When using Clojure require as a function, what are the scoping rules, and can they be changed ?
For instance, when require is inside a function, or is there a with-scope or something similar to control require behaviour ? Can a require shadow another ?
Calling require more than once will not have any effect unless you force it with something like :reload, so there's no shadowing that goes on. I believe you can call it anywhere (just like any other function) and it will have no special behaviour relative to the call site.
Related
If it's an ordinary local object, its scope begins when it's declared, and things before its declaration can't access it. However, if it's a member variable, then anything in this class, even written before the declaration of that member, has access to it.
What happens under the hood? Why is it designed this way?
I tried to google about it but only got the rule itself instead of the mechanism or the motive.
There's nothing to answer here. It is just that way.
Under the hood happens that the compiler tracks the scope as specified by the language.
Why that language is that way: I'd say it is intuitive, but you seem to disagree, so the only argument I could come up with has been devalued by the very question you're asking. 🤷🏼.
In C++ it is possible to declare that a function is const, which means, as far as I understand, that the compiler ensures the function does not modify the object. Is there something analogous in C++ where I can require that a function is pure? If not in C++, is there a language where one can make this requirement?
If this is not possible, why is it possible to require functions to be const but not require them to be pure? What makes these requirements different?
For clarity, by pure I want there to be no side effects and no use of variables other than those passed into the function. As a result there should be no file reading or system calls etc.
Here is a clearer definition of side effects:
No modification to files on the computer that the program is run on and no modification to variables with scope outside the function. No information is used to compute the function other than variables passed into it. Running the function should return the same thing every time it is run.
NOTE: I did some more research and encountered pure script
(Thanks for jarod42's comment)
Based on a quick read of the wikipedia article I am under the impression you can require functions be pure in pure script, however I am not completely sure.
Short answer: No. There is no equivalent keyword called pure that constrains a function like const does.
However, if you have a specific global variable you'd like to remain untouched, you do have the option of static type myVar. This will require that only functions in that file will be able to use it, and nothing outside of that file. That means any function outside that file will be constrained to leave it alone.
As to "side effects", I will break each of them down so you know what options you have:
No modification to files on the computer that the program is run on.
You can't constrain a function to do this that I'm aware. C++ just doesn't offer a way to constrain a function like this. You can, however, design a function to not modify any files, if you like.
No modification to variables with scope outside the function.
Globals are the only variables you can modify outside a function's scope that I'm aware of, besides anything passed by pointer or reference as a parameter. Globals have the option of being constant or static, which will keep you from modifying them, but, beyond that, there's really nothing you can do that I'm aware.
No information is used to compute the function other than variables passed into it.
Again, you can't constrain it to do so that I'm aware. However, you can design the function to work like this if you want.
Running the function should return the same thing every time it is run.
I'm not sure I understand why you want to constrain a function like this, but no. Not that I'm aware. Again, you can design it like this if you like, though.
As to why C++ doesn't offer an option like this? I'm guessing reusability. It appears that you have a specific list of things you don't want your function to do. However, the likelihood that a lot of other C++ users as a whole will need this particular set of constraints often is very small. Maybe they need one or two at a time, but not all at once. It doesn't seem like it would be worth the trouble to add it.
The same, however, cannot be said about const. const is used all the time, especially in parameter lists. This is to keep data from getting modified if it's passed by reference, or something. Thus, the compiler needs to know what functions modify the object. It uses const in the function declaration to keep track of this. Otherwise, it would have no way of knowing. However, with using const, it's quite simple. It can just constrain the object to only use functions that guarantee that it remains constant, or uses the const keyword in the declaration if the function.
Thus, const get's a lot of reuse.
Currently, C++ does not have a mechanism to ensure that a function has "no side effects and no use of variables other than those passed into the function." You can only force yourself to write pure functions, as mentioned by Jack Bashford. The compiler can't check this for you.
There is a proposal (N3744 Proposing [[pure]]). Here you can see that GCC and Clang already support __attribute__((pure)). Maybe it will be standardized in some form in the future revisions of C++.
In C++ it is possible to declare that a function is const, which means, as far as I understand, that the compiler ensures the function does not modify the object.
Not quite. The compiler will allow the object to be modified by (potentially ill-advised) use of const_cast. So the compiler only ensures that the function does not accidentally modify the object.
What makes these requirements [constant and pure] different?
They are different because one affects correct functionality while the other does not.
Suppose C is a container and you are iterating over its contents. At some point within the loop, perhaps you need to call a function that takes C as a parameter. If that function were to clear() the container, your loop will likely crash. Sure, you could build a loop that can handle that, but the point is that there are times when a caller needs assurance that the rug will not be pulled out from under it. Hence the ability to mark things const. If you pass C as a constant reference to a function, that function is promising to not modify C. This promise provides the needed assurance (even though, as I mentioned above, the promise can be broken).
I am not aware of a case where use of a non-pure function could similarly cause a program to crash. If there is no use for something, why complicate the language with it? If you can come up with a good use-case, maybe it is something to consider for a future revision of the language.
(Knowing that a function is pure could help a compiler optimize code. As far as I know, it's been left up to each compiler to define how to flag that, as it does not affect functionality.)
One thing I really dislike in programming is ambiguity with variables names. I'd like to always use the this keyword to access class members, but I often forget to use it in some cases, which leads to some inconsistency.
So I'd like to be forced to use the this keyword when accessing a class member. Would this be a bad idea? I'm thinking there might be a compiler option for that, but I can't find anything about it. I'm using the g++ compiler.
This is a circular problem. You want the compiler to error out and inform you when you're accessing a class member without prefixing this->, so that you cannot be accidentally referring to a local variable or function argument instead … but for that exact same reason, how is the compiler supposed to know that you really intended to access the member? And, if you didn't, how would you access the local variables or function arguments?
C++ is simply not designed this way. Some languages, such as PHP, require that you must use this to access members and any other access is treated as an attempt to read local-scope variables (whether they exist or not), but C++ does not have that. And there is no compiler switch to make it happen. If this worries you, avoid re-using the names of variables!
In short, this is a non-problem that cannot be solved.
Every so often I run into a bit of clojure code where a function name either begins with "-" or ends with "*" and while I can make some guesses from the context, I haven't been able to find any exact definitions of what they indicate. Could someone give me a quick explanation or point me somewhere that has one?
Conventions for functions are...conventions. There no mandatory naming but some habits whom sometime came from lisps.
-function is used by some programmers for private functions declared by defn-. But also
.-function for attribute access for objects from ClojureScript.
function? are generally boolean test function (even?, list?, ...)
function! are functions that involve side effect.
function name embedding -> are conversion functions.
*var* are dynamic variables.
And a lot more from programming group conventions.
And the last part: foo* is often used for the underlying function of a convenience macro foo. E.g., log vs log*
"-" and "*" are just part of a valid Clojure symbol. They do not indicate anything special per se, and the Clojure compiler will treat them just like any other symbol.
Conventionally, *'s are used to surround the name of a dynamic var. You can make a var dynamic without the *'s, but it might cause confusion for someone dealing with your code when the value of the var unexpectedly changes out from under them due to a binding call somewhere up the stack. By including the *'s, you are reminding any users of that var that it is dynamic everytime they write/read its name.
Symbols that begin with "-" are typically used in connection with Clojure's gen-class construct. That is because "-" is the default prefix to append to method names when mapping a class's method to a function. However, there are other things it could mean as well.
As Ivan points out, there are other conventions that might be worth knowing as well. However, they're just conventions -- like camelCasing in other languages.
Here's something I know is probably possible but I've never managed to do
In VS2005(C++), While debugging, to be able to invoke a function from the code which I'm debugging.
This feature is sometimes essential when debugging complex data structures which can't be explored easily using just the normal capabilities of the watch window.
The watch window seem to allow writing function calls but every time I try it it gives me one error or another.
Error: symbol "func" not found
Error: argument list does not match function
Error: member function not present
Did anyone ever succeed in making this work properly?
What am I missing here?
Edit: clearly, the function called should be a symbol that exists in the current scope the debugger is in.
Ok, Here's what I found
CXX0040 means that "The C expression evaluator does not support implicit conversions involving constructor calls."
CXX0047 means that "Overloaded functions can be called only if there is an exact parameter match or a match that does not require the construction of an object."
So combined it means that If I want to call a function none of the arguments should have an implicit conversion and none of the arguments should need a construction.
"implicit conversion" in this context seem to include trivial things like converting 'String' to 'const String&'.
"construction" seem to include trivial copy-construction. so passing by value anything that is not a primitive type will result in an error.
So this basically leaves functions that take only primitive types or pointers.
I have just tested this theory successfully.
So if you want to be able to call a method from the watch window, add an overload which takes only pointers and primitives and in the watch window pass the arguments appropriately. To pass an object that is not a primitive pass its address.
The watch window is limited by the context wherein your current code is, e.g., when your code enters a function and you try to access another function that is hidden from the scope of your current function, it won't work.
If you invoke a function in the watch window, make sure that it is visible and accessible from the current scope.
To my knowledge, you can't execute code from the Watch window while debugging unmanaged C++. This does work for C# (and probably VB.NET and managed C++, but I'm not positive on that). So likely it allows it because it works for some languages, but not others.
We find this works in a very hit and miss manner. Some very simple functions (incl. member functions) work, typically simple property getters. Other more complex functions don't work and give an error.
I've never been able to discern the precise rules ...
I haven't tested this, but I always thought that was what the immediate window was for (executing code)
Cameron
It's the "Immediate" window that you want. And you're limited to what's visible from where your current breakpoint is. Local variables, and functions on that class (or globals)
In my experience, there are some shortcomings with the immediate window. You can't call your classes' member functions if the classes come from a different DLL, but get misleading error messages. If anything is in the same DLL (e.g. by statically linking in all other stuff), calling members is fairly reliable. But complex stuff may or may not work, as mentioned by others.