D120.de/forum

Ohh... Of course the function application is inside the scope of the leftmost binding, so the substitution is done in the scope of the inner binding instance. Then it makes sense... I mistakenly assumed that the function to which the argument is applied was the whole left side of it. Thank you for y...

Hello, in Exercise 5, where the Y-Operator is applied for obtaining a recursive function application, the expression is reduced as follows in the solution: Y-Operator_lambdas.png The "n" in the "f(n+1)" is replaced by the "n+1" argument of the function application. However, I don't quite understand ...

Okay, thank you for the good explanation!

According to what I found here the non-Scala syntax seems to be the concrete syntax and the Scala representation the abstract one. (That also roughly matches the definition slide in the lecture, except for the example being in the wrong place.) But I would really appreciate an official statement on ...

Hello, I noticed that in the slides the terms "abstract" and "concrete syntax" are used inconsistently... On the definition slide (p. 4) of V02, Abstract syntax seems to refer to the <AE> ::= ... notation: VL02_Abstract_Concrete_Syntax.png However, in V03 e.g. on p. 8 the same notation is named "con...

I guess that for forwarding semantics it is class OtherClassForwarding extends Base { ... def m() { callee.m() } } because the object tells callee just to do something and callee does it for itself, without caring about the OtherClassForwarding object anymore. And for delegation class OtherClassDele...

Okay, thank you for the explanations.

Okay, thank you very much, I think I've got it now! :) No. The implementation of the visit calls the accept methods of the contained elements. Maybe my wording was not precise enough here: Ah okay. So, what we achieve by doing this (instead of calling the accept() methods in Project's accept() direc...

Okay, thank you for the answer! The visit method of a aggregate element defines the iteration order on the sub elements in this case. You mean the accept(...) method in this case, right? In addition, it can be the case that a DependentTask wraps around a BillableTask. Ok, at this point there is some...

Hello, I have another two questions regarding the exercise: 1.) If I understand correctly, Project (which is also a Visitable) should just call the accept(...) methods of all contained tasks in its own accept(...) method. In the Visitor pattern as introduced in the lecture, however, the ConcreteElem...

just as a heads up: in this exercise you will most likely produce code that is not accepted by the parses of IDEs(at least IntelliJ), but by the scala compiler. So maybe you should try compiling your solution with sbt or scalac directly before dismissing it. Thank you for this hint, I was quite con...

Hello, I have some questions regarding the new exercise. The exercise description says "If a class violates the LSP because it does not (re)define a method, add an LSP annotation (...)". Does this mean that every subclass must (re)define the methods of the superclass in general? (I cannot remember t...

Hello, the task description says "For all top-level interfaces and abstract classes (Expression, UnaryOperator, BinaryOperator) assess whether the ISP is violated or not." Does this mean that only those three classes have to be assessed? Is not ExpressionVisitor a top-level interface, too? Best rega...

Hello, I have another question regarding this subtask. According to the lecture, higher-level modules should depend on "service interfaces" on the same layer rather than directly on lower modules. However, it is not quite clear to me which are the layers in the exercise. I would consider something l...

From what I understand, the [_>: TestResult] is similar to Java's <? extends TestResult> which means that the generic type can be any subtype of TestResult. You cannot pass "Student#TestResult" as a parameter, but you can use it to specify the generic type to be used in a variable/value definition, ...