Often there's no need to pay any attention to implicit arguments in Scala, but sometimes it's very helpful to understand how the compiler is automatically providing them. Unfortunately, this understanding seems to be hard to obtain!
Is there a general method to discover how an implicit parameter has been provided, in a given piece of code?
Ideally, one day IDE integration would provide this information in some way, but I expect for now I'll have to dig deeper. Is there some way to ask the compiler to explain exactly which implicit definition it chooses at any given point? Can this be deciphered indirectly from other compiler output?
As an example, I'd like to know how to work out on my own where the implicit bf: CanBuildFrom[Repr, B, That] argument to TraversableLike.map comes from, without reading questions like this one on Stack Overflow!
Add the option -Xprint:typer to the scalac command line. This prints the program tree just after the typer compiler phase. This works best with a short, self contained example. You can also pass this to scalac. This is a really huge step towards self-reliance in Scala!
As mentioned by Randall, IntelliJ shows in-scope and the selected Implicit View with CTRL-ALT-SHIFT-I. Wait a month or two and implicit arguments are likely to have similar support.
Ideally, one day IDE integration would provide this information in some way, ...
That day is today in with JetBrains' IDEA. If you run the latest EAP of IDEA version 9 (9.0.3 EA #95.289) with a recent nightly release of the Scala plug-in, this capability is present. Every value expression may be selected and a command issued that displays a pop-up showing all applicable implicit conversions with the one the compiler will select highlighted.
And since there are apparently a few out there who don't yet know it, there is a free and open-source Community Edition of IDEA and it does support the Scala plug-in.
Related
Generally speaking, when writing a llvm frontend, one will take an AST and first check that its semantics is well-defined. After this, one will take the AST and perform the IR build phase.
I was wondering, how realistic is to perform directly the IR build phase onto the AST, and if errors are found during the build process, revert any partial changes to the module object?
I assume something like this would be required:
remove defined Types
remove defined Globals
anything else i'm missing?
Any ideas about this? what are the general guidelines of what needs to done for a clean revert of module changes after a failed build phase?
Now, this is thinking in terms of optimistically compiling, and failing gracefully it somethings goes wrong. It might very well be that this is completely impossible or discouraged under the current LLVM model. A clear and well-documented answer in this regard is also completely acceptable
Edit In the end, I just want a reasonable way to add functions incrementally but revert gracefully to previous state of module and/or LLVMContext if a function build fails. Whatever is the preferred approach for that will be entirely satisfactory.
thanks!
Many compilers (not necessarily LLVM-related) mix semantic analysis with code generation, so it can definitely be done. However, I'm puzzled by your reference to "revert any partial changes to the module object". When you start building an IR module and encounter a semantic error in the AST, what is your plan? Do you want to spit an incomplete module? Why? Thinking about the way any regular compiler works, if there are semantic errors in the code (i.e. reference to an undefined variable), no output is created. Would you like something different?
(Mathematica version: 8.0.4)
lst = Names["Internal`*"];
Length[lst]
Pick[lst, StringMatchQ[lst, "*Bag*"]]
gives
293
{"Internal`Bag", "Internal`BagLength", "Internal`BagPart", "Internal`StuffBag"}
The Mathematica guidebook for programming By Michael Trott, page 494 says on the Internal context
"But similar to Experimental` context, no guarantee exists that the behavior and syntax of the functions will still be available in later versions of Mathematica"
Also, here is a mention of Bag functions:
Implementing a Quadtree in Mathematica
But since I've seen number of Mathematica experts here suggest Internal`Bag functions and use them themselves, I am assuming it would be sort of safe to use them in actual code? and if so, I have the following question:
Where can I find a more official description of these functions (the API, etc..) like one finds in documenation center? There is nothing now about them now
??Internal`Bag
Internal`Bag
Attributes[Internal`Bag]={Protected}
If I am to start using them, I find it hard to learn about new functions by just looking at some examples and trial and error to see what they do. I wonder if someone here might have a more complete and self contained document on the use of these, describe the API and such more than what is out there already or a link to such place.
The Internal context is exactly what its name says: Meant for internal use by Wolfram developers.
This means, among other things, the following things hold about anything you might find in there:
You most likely won't be able to find any official documentation on it, as it's not meant to be used by the public.
It's not necessarily as robust about invalid arguments. (Crashing the kernel can easily happen on some of them.)
The API may change without notice.
The function may disappear completely without notice.
Now, in practice some of them may be reasonably stable, but I would strongly advise you to steer away from them. Using undocumented APIs can easily leave you in for a lot of pain and a nasty surprise in the future.
I understand that over a thousand built-in rewrite rules in Mathematica populate the global rules table by default. Is there any way to get Mathematica to give a full or even partial list of those rules?
The best way is to get a job at Wolfram Research.
Failing that, I think that for things not completely compiled into the kernel you can recover most of the rules/definitions. Look at
Attributes[fn]
where fn is the command that you're interested in. If it returns
{Protected, ReadProtected}
then there's something you can get a look at (although often it's just a MakeBoxes (formatting) definition or a AutoLoad/Stub type definition). To see what's there run
Unprotect[fn];
ClearAttributes[fn, ReadProtected];
??fn
Quite often you'll have to run an example of the command to load it if it was a stub. You'll also have to dig down from the user-facing commands to the back-end implementations.
Eventually you'll most likely reach a core command that is compiled into the kernel that you can not see the details of.
I previously mentioned this in tips for creating Graph diagrams and it got a mention in What is in your Mathematica tool bag?.
An good example, with a nice bite-sized and digestible bit of code is Experimental`AngularSlider[] mentioned in Circular/Angular slider. I'll leave it up to you to look at the code produced.
Another example is something like BoxWhiskerChart, where you need to call it once in order to load all of the code. Then you see that BoxWhiskerChart proceeds to call Charting`iBoxWhiskerChart which you'll have to unprotect to look at, etc...
Why didn't C++0x deprecate implicit conversions for user defined types a.k.a. objects? Is there any project which actually uses this (mis)feature? Whenever I see a single argument constructor in a code I get to review or modify I treat it as bug and make it explicit. So far it worked well and nobody complained.
Thank you.
EDIT: Let me quote Alex Stepanov, the creator of STL:
Open your C++ book and read about the
explicit keyword! Also petition your
neighborhood C++ standard committee
member to finally abolish implicit
conversions. There is a common
misconception, often propagated by
people who should know better, that
STL depends on implicit conversions.
Not so!
Reference: A. Stepanov. C++ notes
EDIT AGAIN: No, no debate plz. I am just curious whether anyone uses implicit conversions in their work. I never seen any project which would allow implicit conversion for objects. I thought hard and couldn't come with any hypothetical scenario where implicit conversion wouldn't become a minefield. I mean C++ single argument conversions, not float->double or similar conversions inherited from C.
The obvious answer is that code written and working in C++03 is supposed to continue working with C++0x compilers.
For one thing, it would be a hugely breaking change to remove implicit conversion from the language - even if it were made optional and off-by-default with an implicit keyword.
I've done a search of comp.std.c++ and it doesn't seem to have been discussed at all in that group - though there have been some questions on the subject, no-one seems to have suggested going so far as removing it. I would certainly not go so far either: it's a feature I happily use on occasion and I do not subscribe to making all possibly-converting constructors explicit either - unless it causes real bugs.
I'm considering how to do automatic bug tracking and as part of that I'm wondering what is available to match source code line numbers (or more accurate numbers mapped from instruction pointers via something like addr2line) in one version of a program to the same line in another. (Assume everything is in some kind of source control and is available to my code)
The simplest approach would be to use a diff tool/lib on the files and do some math on the line number spans, however this has some limitations:
It doesn't handle cross file motion.
It might not play well with lines that get changed
It doesn't look at the information available in the intermediate versions.
It provides no way to manually patch up lines when the diff tool gets things wrong.
It's kinda clunky
Before I start diving into developing something better:
What already exists to do this?
What features do similar system have that I've not thought of?
Why do you need to do this? If you use decent source version control, you should have access to old versions of the code, you can simply provide a link to that so people can see the bug in its original place. In fact the main problem I see with this system is that the bug may have already been fixed, but your automatic line tracking code will point to a line and say there's a bug there. Seems this system would be a pain to build, and not provide a whole lot of help in practice.
My suggestion is: instead of trying to track line numbers, which as you observed can quickly get out of sync as software changes, you should decorate each assertion (or other line of interest) with a unique identifier.
Assuming you're using C, in the case of assertions, this could be as simple as changing something like assert(x == 42); to assert(("check_x", x == 42)); -- this is functionally identical, due to the semantics of the comma operator in C and the fact that a string literal will always evaluate to true.
Of course this means that you need to identify a priori those items that you wish to track. But given that there's no generally reliable way to match up source line numbers across versions (by which I mean that for any mechanism you could propose, I believe I could propose a situation in which that mechanism does the wrong thing) I would argue that this is the best you can do.
Another idea: If you're using C++, you can make use of RAII to track dynamic scopes very elegantly. Basically, you have a Track class whose constructor takes a string describing the scope and adds this to a global stack of currently active scopes. The Track destructor pops the top element off the stack. The final ingredient is a static function Track::getState(), which simply returns a list of all currently active scopes -- this can be called from an exception handler or other error-handling mechanism.