Java, C# and Prolog reflection mechanisms [closed] - c#

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
i am preparing for my finals and came across this question:
Learn about the reflection mechanisms of Java, C# and Prolog, all of
which allow
a program to inspect and reason about its own symbol table at run time. How
complete are these mechanisms? (For example, can a program inspect symbols that
aren’t currently in scope?) What is reflection good for? What uses should be
considered good or bad programming practice?
Why is this question asked in terms of symbol table? Can i write the same solution that i write in terms of classes and objects like mentioned in this SO question:
What is reflection and why is it useful?

I think of reflection as the basic tool to do metaprogramming.
This turns out to be a declarative way to solve (a kind of) problems.
Sometime, instead of building a solution, can be useful to write something that allow to describe the problem space. That is, see if your problem can be restated in a more practical language.
You see, we treat languages as components of algorithms, like data. Then we can exchange components between languages.
Practically, an example of interesting Java/Prolog reflection is JPL
Some time ago I found useful - and performant - C# reflection. United to emit package allows to produce compiled code.
Prolog use reflection in seamless ways: for instance DCGs are really a 'simple' rewrite of declared rules.
I've started a project that I hope I will take me to Prolog controlling Qt interface,
of course Qt reflection plays a fundamental role.
edit About your question on symbol tables: symbol is an extremely general term. Also all languages have a concept of symbols, (maybe) differently aggregated. That's the core of languages. Then the question is perfectly posed in very general terms, just to check your understanding of these basic language concepts.

The "symbol table" is just an internal concept that is needed for "reflection" to do what it does: the ability of a program to examine itself at runtime and do something dynamically with that. (be aware about the diff between - introspection vs. reflection).
So if you understand what reflection is good for, how it is implemented in your target platform (Java, C# etc.), and what might be the limitations, you should be able to answer all those questions I suppose.
Think about the symbol table as just an "implementation detail" of a platform/runtime. According to the question above I don't think they expect you to know exactly how this is implemented.

I'd suggest you to read the following pages to get an idea of reflection in the corresponding language:
JAVA
C#
Prolog - Search for 'Reflection'
After Reading those you shold see similarities of the methods.
To be honest, I've never worked with reflection in Prolog, but the docs should guide you through.
The symobl table is used by the reflection mechanisms to look the things up.
See here for a description of symbol tables.
Those resources should give you an idea on how to answer your questions

Related

What's Easy in F# That's Hard in C#? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
In what areas might the use of F# be more appropriate than C#?
I'm anticipating giving a presentation at the local .Net user group about F#. And I'm anticipating the "Why should I look into F#?" question from the audience. I know most of the stuff that can be done in F# can be done in C# too--so I'm looking for things that can be done easily in F# that are really hard to do in C# (e. g. pattern matching). And if there are already good answers to this question, please just link them in comments and I'll close this up. I did see a few things but if there's already a question that addresses this I didn't find it.
By the way, if any of the moderators want to mark this community wiki please feel free; this seems more like a survey question to me anyway.
Since F# is a functional language, it should be far easier to implement a domain-specific language in it.
One of a main concept is asyncrounus calls in F#, also F# uses immutable variables so concurrency is easy.
see http://research.microsoft.com/apps/pubs/default.aspx?id=147194
and http://research.microsoft.com/apps/pubs/default.aspx?id=79947 and other Don Syme articles. may be there are other differences, but I think gathering them here is just doing your homework.
i would say
Asynchronous programming.
Units of measure

Looking for a C# code parser [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I'm looking for a set of classes (preferably in the .net framework) that will parse C# code and return a list of functions with parameters, classes with their methods, properties etc. Ideally it would provide all that's needed to build my own intellisense.
I have a feeling something like this should be in the .net framework, given all the reflection stuff they offer, but if not then an open source alternative is good enough.
What I'm trying to build is basically something like Snippet Compiler, but with a twist. I'm trying to figure out how to get the code dom first.
I tried googling for this but I'm not sure what the correct term for this is so I came up empty.
Edit: Since I'm looking to use this for intellisense-like processing, actually compiling the code won't work since it will most likely be incomplete. Sorry I should have mentioned that first.
While .NET's CodeDom namespace provides the basic API for code language parsers, they are not implemented. Visual Studio does this through its own language services. These are not available in the redistributable framework.
You could either...
Compile the code then use reflection on the resulting assembly
Look at something like the Mono C# compiler which creates these syntax trees. It won't be a high-level API like CodeDom but maybe you can work with it.
There may be something on CodePlex or a similar site.
UPDATE
See this related post. Parser for C#
If you need it to work on incomplete code, or code with errors in it, then I believe you're pretty much on your own (that is, you won't be able to use the CSharpCodeCompiler class or anything like that).
There's tools like ReSharper which does its own parsing, but that's prorietary. You might be able to start with the Mono compiler, but in my experience, writing a parser that works on incomplete code is a whole different ballgame to writing one that's just supposed to spit out errors on incomplete code.
If you just need the names of classes and methods (metadata, basically) then you might be able to do the parsing "by hand", but I guess it depends on how accurate you need the results to be.
Mono project GMCS compiler contains a pretty reusable parser for C#4.0. And, it is relatively easy to write your own parser which will suite your specific needs. For example, you can reuse this: http://antlrcsharp.codeplex.com/
Have a look at CSharpCodeCompiler in Microsoft.CSharp namespace. You can compile using CSharpCodeCompiler and access the result assembly using CompilerResults.CompiledAssembly. Off that assembly you will be able to get the types and off the type you can get all property and method information using reflection.
The performance will be pretty average as you will need to compile all the source code whenever something changes. I am not aware of any methods that will let you incrementatlly compile snippets of code.
Have you tried using the Microsoft.CSharp.CSharpCodeProvider class? This is a full C# code provider that supports CodeDom. You would simply need to call .Parse() on a text stream, and you get a CodeCompileUnit back.
var codeStream = new StringReader(code);
var codeProvider = new CSharpCodeProvider();
var compileUnit = codeProvider.Parse(codeStream);
// compileUnit contains your code dom
Well, seeing as the above does not work (I just tested it), the following article might be of interest. I bookmarked it a good long time ago, so I believe it only supports C# 2.0, but it might still be worth it:
Generate Code-DOMs directly from C# or VB.NET
It might be a bit late for Blindy, but I recently released a C# parser that would be perfect for this sort of thing, as it's designed to handle code fragments and retains comments:
C# Parser and CodeDOM
It handles C# 4.0 and also the new 'async' feature. It's commercial, but is a small fraction of the cost of other commercial compilers.
I really think few people realize just how difficult parsing C# has become, especially if you need to resolve symbolic references properly (which is usually required, unless maybe you're just doing formatting). Just try to read and fully understand the Type Inference section of the 500+ page language specification. Then, meditate on the fact that the spec is not actually fully correct (as mentioned by Eric Lippert himself).

Looking for patterns/best practices for calculating complex discounts [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm developing a price calculation engine. I've looked all over and there's nothing that really fits what we need. However, I'm now looking how to implement specific prices and/or discounts. I don't want to introduce a rule based engine to my end-users, because they won't get it.
For example, when you order an ItemX the price is $30. But in combination with ItemY the price of ItemX is $20. Or when ordering five of ItemX, each after it will be only $15.
Any ideas on where to start? How to take this on? Perhaps some (open source) example applications that contain practices like these? Any (technical) patterns I could use? Preferably in C#.
Thanks in advance!
There are many ways you can achieve this, but I think the one which might be most useful for you would be to define a DSL that you can use to express your discounts in such a way where they can be easily explained and rationalised with business users. An example from one of ayende's articles on DSLs in boo is:
apply_discount_of 5.percent:
when order.Total > 1000 and customer.IsPreferred
when order.Total > 10000
suggest_registered_to_preferred:
when order.Total > 100 and not customer.IsPreferred
As you can see you can see, this is the kind of thing you can print out and show to a client and they will immediately understand what's going on.
Of course developing something like this is time consuming, expensive and fraught with funky edge cases. However it has the benefit of being code which can be unit tested, executed and debugged.
If boo isn't your thing, then maybe you could look at defining something similar in ironruby, ironpython or F#. I would however suggest staying away from XML for defining these rules unless you really enjoy a world of pain.
This is however the kind of thing that products like Biztalk were designed to handle. Which rules engines have you evaluated and found lacking?
We use a Rule Engine for this type of complex calculation. Our platform is Java and we use Drools (which we're happy with). Drools is also available for .Net. Here's a list of open source Rules Engines for .NET.
I am sorry to have to say this, but this would seem like you would have to apply some Pricing Rule Engine to achive what you are after.
Would seem like you have to
Store the available items, and their
discounts on per pruchase.
Store which items in combination
would discount each other.
Also maybe thinking of per
unit/quantity purchased per unit, or
maybe per package/special.
Might want to look at keeping a
archive/storage of these
specials/packages, just incase the
customer wants a reprint of the
original invoice.
In general there is a lot of possible rules/combinations that can be thought of, and you as developer can implement these and hide them from the user, or allow the user to create them, but somebody has to do so.
And then, when you dont feel like implementing your own, GOOGLE shold provide some:
Open Source Rule Engines

What C# knowledge should I have? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
A very open question. I've been programming in C# for the
past 5 months doing small projects that I completed
successfully.
Today I went to an interview for a C# role. The 1st question
was 'Tell me about boxing'. Given my experience I had no
idea what the guy meant. Needless to say the interview
didn't go that well. Others questions were 'why isn't it
recommended to use an ArrayList of int', 'tell me what you
know about threading', etc.
I don't really want this to happen again so I'm planning to
spend some time reading (and practising) more on C#. I
understand that the best way of learning is by coding but
coding wouldn't have really helped me answer the question
about 'boxing' for example.
I'm not asking you to answer the above technical questions.
In fact, I know now their answer as I went straight to
Google after the interview and it's how I realised that my
C# knowledge is somewhat limited.
My question is: in your opinion, which knowledge should any
C# developer have? Ideally it would be better if you could
categorize it (Basic knowledge anyone should have without
exception, Advanced knowledge, Expert knowledge etc). No need
to go into details. Doing research on whatever you list will
be a good exercise for me.
I would expect someone going for a professional C# job to know about:
Generics and generic collections
Interfaces (general)
Interfaces (specific), namely -
IDisposable: how it's integrated into the language and why
IEnumerable: including common extension methods, iterator blocks, and deferred execution
Overview of serialization in .Net (maybe not have done it, but understand what it is and know where to look in the namespace heirarchy and documentation)
Overview of Xml in .Net (same as serialization)
Overview of threading concepts (same as xml/serialization). Bonus points for understanding why most thread-safe collections aren't.
Have used anonymous delegates / lambdas in at least one project, and therefore also have a basic idea about closures.
Comfortable explaining some basic concepts from at least one of winforms, wpf, webforms, or MVC
Be able to answer some easy questions on specific common classes in the .Net BCL: namely from System.Data (think parameterized queries!) and System.IO (filestreams, path).
Garbage collection: when should you call GC.Collect (hint: pretty much never) and why
Here is a good list: What Great .NET Developers Ought To Know.
My personal experience from a long time ago when I was in school.
I went to see my father at work in a bank. At that time, most of his day was taking care of accounts and making sure every thing worked. What I saw was he was trying to tally/calculate large numbers and calculating(basic additions/multiplications...).
After noticing him, I asked him: Dad, if all you have to do is basic additions and multiplications, why bother to study till graduation?
His response was : While you don't have to use all the knowledge you have acquired, that knowledge would help you make learned decisions.
Coming to your question: While you dont have to use the entire set of concepts, knowing that they exist would help you make good decisions while you code.
My suggestion along with the others posted would be to try and spend some time on stackoverflow every day.
Good luck.
A good interviewer isn't going to grill you on trivia. That's why we have Google. A good interviewer is going to find areas you don't know, and ask you questions there, as that's the best place to find out how you react when confronted with something you don't have down pat.
The best advice I can give for interviews is to not worry about the technical trivia too much. Instead, in an interview, focus on problem-solving skills. If you don't know something, don't try to hide it, just admit it. If you think you know, it's okay to say "I'm not sure, but I think it's this." And don't get flummoxed either - at that point, usually the interviewer will give you a hint. This is not just giving you the answer, it's another part of the test - to see if, given a nudge in the right direction, you can extrapolate from there.
For the boxing/ArrayList/int questions, if I was interviewing and you didn't understand boxing, I'd give you a basic description of what boxing did. Then I'd ask you, knowing what I just told you, why you might think using ints in an ArrayList might be a bad idea.
One thing that will go far in any interview is focusing on the requirements, the desired result, and boundary conditions or edge cases. As most programming interview questions fall into the "write this method" category, make sure you get the following correct:
1) The inputs to the method
2) The expected output of the method
3) Boundary and edge cases.
This sounds ridiculously basic, but it's amazing how many developers, even ones with experience, don't bother thinking through these things. Code solves a problem - if you don't understand the problem correctly, you can't solve it correctly.
I would have to say that if an interviewer can be fooled into thinking someone has more .NET / C# experience by he or she visiting a webpage, then the interviewer is failing. I've interviewed a number of people myself, and I really like the approach of giving them some easy to understand problem to solve, and asking them to write some code on a white board. Even if they've memorized the answers to every question on Scott Hanselman's blog, I would learn a lot about how comfortable they are in the language, as well as how they go about problem solving. I'm looking for a developer, not a partner for Trivial Pursuit, .NET Developer Edition.
That said, keeping up with blogs like Hanselman's is a fantastic way to keep up with the jargon. You could code C# in a vacuum for years, fully understand the advantage of a strongly-typed List<int> over ArrayList, but never actually use the term "boxing". But it's much more time consuming in an interview to ask, "Describe the advantage of iterating through a List<int> instead of an ArrayList of int," than it is to ask, "Tell me about boxing." Plus, actually researching the answers to Hanselman's .NET interview questions (especially if you explore the details and ask "Why?") will make you a better developer. So by all means, keeping reading Hanselman.
And one more note... If I ask someone whether a String is a reference type or a value type, and they simply say "Hmmm... Reference type," I'm not going to be nearly as happy as I would if the response was, "Hmmm... Reference type, but that's an interesting question." "Why is that?", I say... "Because string is implemented so that the string is immutable, allowing you to do things with it like safely use it as a hash key. Or pass it to a method, knowing the value cannot be changed. So in a way, strings can act a lot like value types..." And that would be a great conversation, leading me to ask, "So tell me more about why hash keys should be immutable..."
It's not just the difference between answering a 50/50 question correctly and all the additional information in the second answer. Having an intelligent conversation with a interviewee leads me to think I'll have intelligent conversations like that on a regular basis once the interviewee becomes my coworker. And that's something I'm definitely looking for.
Also depends on the role. If this was advertised as a jnr role then a threading question is a little tough...sometimes agencies/employers have unrealistic expectations.
A similar thing happened to my significant other taking a driving test. The state trooper said, "make a roundabout" and she didn't know what he was talking about. Both of us think a roundabout is a type of road layout with a big circle, not a u-turn as the instructor meant. So I know what you mean.
Programming job interviews vary wildly. Some people think you can't really judge a programmer well in an interview and are willing to give anyone who makes a good impression a chance. Others are grueling things which only those overqualified for the position would pass, and you will probably be suprised how often you get a call back from those.
This is something I have been pondering myself a lot lately. Using C# plenty but not sure what I am missing.
I ordered
Microsoft® .NET Framework Application Development Foundation
Which covers a lot of ground related to C#
Also looking at C# in Depth
Read some of this already. Has some great information from a high quality author.
In depth is on sale too via Jon Skeet's blog

What should I know about C# before walking into an interview for a .NET job? [duplicate]

This question already has answers here:
Questions every good .NET developer should be able to answer? [closed]
(25 answers)
Closed 2 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Sure, we all have written tons of C# code. So walking into an interview for a .NET job should be a no-brainer, right? And then you read some stackoverflow posts and it hits you: You don't know squat!
Remember that site with the cram sessions to go through, before taking an exam? I think stackoverflow could be used to make a sorted (voting) list of topics to know about.
Please only put one topic per post.
Please also add some information about the topic. Links, reference material etc.
EDIT: I guess some of you misunderstood the reason for the post - I'm hoping to generate a list of stuff to know about .NET, a sort of cram session that can be reviewed by everyone on the planet to regularly review. This should help us all remember arcane stuff we never really use.
They are likely going to ask you questions that are based more on Object Oriented Design and Programming more than questions that are explicitly geared towards C#. So if you can explain abstraction, polymorphism, interfaces, etc. You should be good to go.
Reference vs value types.
Know your delegates. Every .Net interview I've been on has asked me about delegates. Know why they exist, know how to declare them, and how to consume them, understand what multicast delegate is. Understand how to use a multicast delegate when one of the handlers throws an exception. Know what the compiler does with a delegate. Understand how delegates can give you "automatic" asynchronous APIs. Get familiar with the newer more convenient generic delegates - Action and Func.
Bonus: delegates vs events. What are the differences? When would you use one over the other?
Generics.
(also - don't try to cram and pass yourself off as an expert on something. A good interviewer will figure that out very, very quickly.)
I don't see how this question is valuable to your situation. The result of this question is going to be 30 posts listing features of the C# language.
I think you need to refine your question by giving us a hint about what type of job you are applying for. Or your skill set level or what areas your familiar with. Otherwise this post won't really contain a valuable answer.
EDIT
[OP] That (30 posts listing features of the C# language) is precisely what I am after
Then I suggest the C# language spec. http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx
ScottHa has two great lists of interview questions:
ASP.NET Interview Questions
What Great .NET Developers Ought To Know
Reflection. and the power of custom attributes in reflection.
Stack vs Heap: What goes where, what caused a StackOverflowException and what causes an OutOfMemoryException.
Generics, why generic lists are prefered rather then arraylist or hashtable. Performance issues and strongly typed added by the way.
Bonus: benefits of generic non-collection types. Why would one use these? How?
I hope the job interview is about coding itself. c# is just a syntax of programming. To be sure read about some specific C# things like reference vs value types
I'd start by looking at the latest c# enhancements. Also, it really depends on what type of job it is as there are a lot of things an ASP.Net developer won't know about Winforms and vice versa.
Assuming asp.net, I've been asked the following in interviews over the past 18 months:
Page Life Cycle
Generics
Interfaces / basic OO design
SQL; e.g. joins, updates, inserts,
etc. Also, how to use DataReader and
sqlcommand.
LINQ syntax; not because anyone is really using this, rather because they read about it.
Web Services ( asmx and wcf )
basic html / css
Session strategies for single server
/ load balanced
Differences between gridview,
repeater, etc.
What I've found is that most .net "web" dev's don't know diddly about sql or html. If you can prove you know more than just how to "drag and drop" controls on a web form then you're already better than 90% of the guys you'll run into.
If you've been writing code in one discipline (.NET in this case) that long, you should have a pretty standard answer to the technical questions that you don't know:
Q: So, what do you know about [technobabble]
A: Well, I haven't used that particular aspect in my previous projects, however, I have a small Volkswagen full of on-line resources that I check for answers like that. In other words, if I don't know it, I know where I can learn about it.
Optional addendum: "And here's an example of me dooing just that when I had a project that required [technobabble-2]..."
You know, if you just plummet through the ECMA-334 specification you should be all set. That's the language... but in away, you'll still be limited by your knowledge of the framework and that's experience. Hard earned experience.
OOPS Concepts
ADO.NET
Session mgmt and Caching
SQL Server distributed transactions
management
New features in .NET 2.0

Categories

Resources