Maybe due to language barrier, I am not quite sure about how/when to use callNextMethod even after reading documents. I think it is for passing arguments, but sometimes I see a R script with only one method still uses callNextMethod. I am confused.
Can anyone explain it in a more explicit way? Better with examples.
Related
I would like to intercept the behavior of read to give some control over the interning of symbols. I might, for example, wish for read to throw an error if a previously uninterned symbol shows up in the input stream. Or perhaps I want to limit the packages in which new symbols can be interned.
Is there a way to hook the interning process without rewriting the reader from scratch?
I am ok with alternate reader implementations. Using read itself is not a must.
You can't do this with the reader defined by the standard without jumping through huge hoops: you'd have to implement the process of accumulating and parsing tokens (including all the number parsing stuff) and then provide suitable ways of intervening. The standard tells you enough that you should be able to do that, but it's a lot of work: I suspect that most of any reader implementation is that stuff.
Of course specific implementations might provide convenient points at which you can intervene.
The other approach would be to use a portable, extensible reader. There is at least one thing which may be such a thing: Eclector, and there may well be others. I don't know anything about it, unfortunately.
I am new to creating my own packages and I am using roxygen2.
I am creating a package with a lot of internal helper functions and I was wondering if I have to document all of them. I understand the importance of documentation but some functions are fairly simple and are just wrapper around other functions for convenience. I have done a basic search of the web but I don't seem to be able to find a definitive answer.
Any help is appreciated.
It depends what you mean by "have to". One interpretation is, "Do I have to document these functions to pass checks?" The answer to that question is no. As long as the function isn't exported from the package, R CMD check won't require that you document it.
Another interpretation is "Do I have to document it to help myself in maintaining this package?" That question is harder to answer. Some functions are so obvious that they don't really need any documentation beyond their name, e.g. a print method with no extra arguments beyond those of the generic.
Other functions aren't so obvious, or have arguments whose meaning isn't obvious. It's a good idea to document those if you plan to maintain your package for a long time, because you might forget the details between now and whenever a problem arises. And if you are releasing your package to others, you should plan on long term maintenance, because if it is useful, people will use it.
I have recently been reading the SBCL User Manual and started wondering about the title question.
Obviously some lisps, for example clojure, ban all side effects so they can easily parallelize the code. Common Lisp allows side effects and so I was wondering if the fact a given function is 'dirty' or 'clean' affects it's compilation.
For example in the CMUCL compiler manual let optimizations show how, in many casesm the use of 'let' to bind a new variable will be more efficient than modifying with 'setq'. I guess I'm asking if something similar is done for function calls.
I have read the relevant sections of the sbcl manual and poured through the question on stackoverflow but could not find an answer to this.
short:
Not faster. Sometimes actually slower.
long:
According to Stas Boukarev from SBCL-devel,
SBCL doesn't even know that a function has no side effects, so, no.
Besides, most of the time having side effects is the most optimal
way.
I am aware of the fact that functions such as nreverse, which are destructive, tend to be faster than nondestructive functions (in this case reverse is the nondestructive version). They also come with many setbacks. As Peter Siebel put it:
Each recycling function is a loaded gun pointed footward.
My questions is basically all in the title. I have no real application in mind, I'm just trying to make sure I use generally accepted good coding practices, and I remember my CS professor saying that breaks are generally avoided when possible, but he never told us why.
I would ask him myself, but he's out of his office this summer.
This is a theological issue. People who are opposed to the use of break (or continue for that matter) say that it makes the control flow of the program harder to follow and thus makes the program less readable. But an easier way to make readable code is simply to make shorter functions, use meaningful variable names, comment appropriately, etc.
Sometimes professors are wrong.
He may object to skipping out of a loop right in the middle of it. This is akin to using a return statement in the middle of a function...some consider that blasphemy.
What ever is the simplest, and produces the most easily maintainable code, is what should be used.
Generally speaking, you will use 'break' to get out of cycles when a certain condition is met (for instance, when you've found what you're looking for, etc.); I don't consider it 'evil' such as the infamous GOTO statement, but reasonable people will differ.
What Dijkstra said was harmful about goto statements - http://drdobbs.com/blogs/cpp/228700940
and https://softwareengineering.stackexchange.com/questions/58237/are-break-and-continue-bad-programming-practices
Your professor was saying "breaks should be avoided" because they are similar to the now-taboo goto statement. However to say "breaks should be avoided whenever possible" is just wrong.
Break exists for readability. You can do anything without break that you can with it, but that doesn't mean you should. Sometimes it just makes sense to make a statement like "In this condition, break out of this loop." or "In this condition, return from this function."
It's a bad idea to use break for program flow in a nested for loops in a way that might give a casual reader some confusion.
Simple rule of thumb: Does using break here (instead of additional if/thens, another boolean, etc.) make this easier to understand or harder to understand? It's that simple.
Ask your professor to try writing a switch statement in any C-style language without break. It can be done I'm sure, but the resulting code is not going to be any more readable.
switch (someExpression) {
case enumVar.CaseA:
// do things here, but don't you dare break!
case enumVar.CaseB:
// do other things - possibly unrelated or contradictory to CaseA
// ... and so on
}
How do I declare the types of the parameters in order to circumvent type checking?
How do I optimize the speed to tell the compiler to run the function as fast as possible like (optimize speed (safety 0))?
How do I make an inline function in Scheme?
How do I use an unboxed representation of a data object?
And finally are any of these important or necessary? Can I depend on my compiler to make these optimizations?
thanks,
kunjaan.
You can't do any of these in any portable way.
You can get a "sort of" inlining using macros, but it's almost always to try to do that. People who write Scheme (or any other language) compilers are usually much better than you in deciding when it is best to inline a function.
You can't make values unboxed; some Scheme compilers will do that as an optimization, but not in any way that is visible (because it is an optimization -- so it should preserve the semantics).
As for your last question, an answer is very subjective. Some people cannot sleep at night without knowing exactly how many CPU cycles some function uses. Some people don't care and are fine with trusting the compiler to optimize things reasonably well. At least at the stages where you're more of a student of the language and less of an implementor, it is better to stick to the latter group.
If you want to help out the compiler, consider reducing top level definitions where possible.
If the compiler sees a function at top-level, it's very hard for it to guess how that function might be used or modified by the program.
If a function is defined within the scope of a function that uses it, the compiler's job becomes much simpler.
There is a section about this in the Chez Scheme manual:
http://www.scheme.com/csug7/use.html#./use:h4
Apparently Chez is one of the fastest Scheme implementations there is. If it needs this sort of "guidance" to make good optimizations, I suspect other implementations can't live without it either (or they just ignore it all together).