From leavens@larch.cs.iastate.edu Sun Nov 27 21:12:56 2005 Date: Sun, 27 Nov 2005 21:12:56 -0600 (CST) From: Gary T. Leavens To: Kristina Boysen Cc: Ru He Subject: Re: Homework 5 (non-content) questions Hi Kristina, On Sun, 27 Nov 2005, Kristina Boysen wrote: > In doing homework 5, I noticed a couple of things: > > Near the end of page 1, you have "aspectjhw.fib.FobonacciTest" misspelled. Oops, I'll fix that. > In the file FibonacciTest, you have a lot of tests in testFib() but most of them > are commented out. When we run our tests and print out our results, do you want > us to run all of the tests there or just the uncommented ones? Just the uncommented ones, because if you run all limit produces a large amount of paper. Gary T. Leavens Department of Computer Science, Iowa State University 229 Atanasoff Hall, Ames, Iowa 50011-1041 USA http://www.cs.iastate.edu/~leavens phone: +1-515-294-1580 From leavens@larch.cs.iastate.edu Sun Dec 4 15:02:29 2005 Date: Sun, 4 Dec 2005 15:02:29 -0600 (CST) From: Gary T. Leavens To: yecui@cs.iastate.edu Cc: Ru He Subject: Re: problem 8 in hw5 Hi Cui, On Sun, 4 Dec 2005 yecui@cs.iastate.edu wrote: > I think the output you gave in problem 8 is a little bit strange. > The second term is (((\ x -> (x x)) (\ z -> z)) q) originally. > So the t.reduce1Step actually invokes reduce1Step() 2 times. > One is itself. The other is the call inside reduce1Step()'s method > body. So there are actually 2 calls on Applicaiton.recduce1Step(). > I think the output for t.reduce1Step() should be, > Reducing ((\ x -> (x x)) (\ z -> z)) --> ((\ z -> z) (\ z -> z)) > Reducing (((\ x -> (x x)) (\ z -> z)) q) --> (((\ z -> z) (\ z -> z)) q), > if we catch all the call pointcut. The 1st one is for the call inside > reduce1Step() body, and the 2nd one is for the call outside, in main() > of ExerciseBeta. > > Am I understanding it correctly? I don't think so. I only wanted to see beta reduction steps, not recursive calls, that result from calls to Application's reduce1Step method. SO I believe that the output is right. In other words, the problem is not just to trace reduce1Step, but only calls to that method that result in beta reductions. Gary T. Leavens Department of Computer Science, Iowa State University 229 Atanasoff Hall, Ames, Iowa 50011-1041 USA http://www.cs.iastate.edu/~leavens phone: +1-515-294-1580 ------------------------- From leavens@larch.cs.iastate.edu Tue Dec 13 17:33:27 2005 Date: Tue, 13 Dec 2005 17:33:27 -0600 (CST) From: Gary T. Leavens To: yecui@cs.iastate.edu Cc: Ru He Subject: Re: Questions on AspectJ related to previous exams Hi Cui, On Tue, 13 Dec 2005 yecui@cs.iastate.edu wrote: > There are several questions that I'm not sure about in the old exams. > > 1. In the exam of Fall02, there is a question asking whether it's possible > to write a pointcut declaration that describes read or write access to a > protected field from code that is not in a subclass but is within the same > package as the declaration of the field being accessed. > I have not come up with a way to do this. So basically, I would say no. > Because the set and get pointcuts in AspectJ only deal with the accesses > inside the class/subclass. Is this correct? Yes, this is correct. There have been proposals to use something like logical variable binding to strengthen the pointcut language in AspectJ, which would make such things possible. But so far it is not part of the langauge. > 2. In Fall03's, the question whether AspectJ can be used to enforce the rule > that code in package b may not call code in package a. > I would say yes. In AspectJ, we can specify a pointcut : > within(b..*) && call(* a..*.*(..)), > which I think does what the question asks. > Am I right? Yes. > 3. In Fall04's, the question whether it would be useful to extend AspectJ's > ModifiersPattern syntax to matching attributes (in java 1.5), what is the > ModifiersPattern? I did not read about that. See the AspectJ programmers guide. It's part of the syntax that is used to specify modifiers. > 4. Also in Fall04's, the one about AspectJ's type system, this is just for fun. > Although I haven't read much about AspectJ's type system, I would guess > the code in the question should be considered as a type error. Although > dynamically it could work correctly, I don't think the compiler does any > work of program analysis to decide what type of exceptions can be thrown > according to the body of an advice. Yes, that's right. > These are what I got so far. Thank you! You're welcome. Gary T. Leavens Department of Computer Science, Iowa State University 229 Atanasoff Hall, Ames, Iowa 50011-1041 USA http://www.cs.iastate.edu/~leavens phone: +1-515-294-1580 ------------------------------