Third assignment now available

Benutzeravatar
sewe
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 295
Registriert: 16. Jan 2009 14:53
Kontaktdaten:

Third assignment now available

Beitrag von sewe »

The third assignment (3 larger Scheme tasks, 3 small Haskell tasks) is now available. Please update your SVN working copy.

Benutzeravatar
Maradatscha
Computerversteher
Computerversteher
Beiträge: 353
Registriert: 2. Okt 2006 18:53

Re: Third assignment now available

Beitrag von Maradatscha »

in this assignment no stub for the subst procedure is given. Does this mean, that we should not use such a procedure? I don't think that I can do without one so I'm using one right now.

The other problem I have is that I do not take care of removing any keys I inserted into the hash but my code passes all tests. I might have built in something without knowing it.

edit: I'm having problems with the interp function in assignment-3. I think my preproc function does what the assignment asks for but the parse and interp functions where not changed to reflect that empty arguments for fun are allowed now. I'm getting strange errors for the other tests too, did someone already complete this task with these tests?

Benutzeravatar
mantra
Computerversteher
Computerversteher
Beiträge: 385
Registriert: 23. Okt 2005 23:56
Wohnort: Wiesbaden

Re: Third assignment now available

Beitrag von mantra »

Since we are asked to implement deferred substitution, substition does not take place in advance but right where/when it is needed. Note the initially unimplemented "lookup"-function. If you used a "preprocessing" subst-function, this would explain why your tests pass.

I tried the tests without removing keys and some of them failed.

Benutzeravatar
sewe
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 295
Registriert: 16. Jan 2009 14:53
Kontaktdaten:

Re: Third assignment now available

Beitrag von sewe »

@Maradatscha: mantra is right; subst is only required when performing immediate substitution which in this case we do not. Instead, we are using deferred substitution (implementing static scoping). Have a look at https://cage.st.informatik.tu-darmstadt ... 009-04-23/ for the interpreters as found in the book.

Regarding task 3, empty argument functions are indeed tricky. By-the-book currying won't work. But the key observation here is that an expression like {c} is essentially a constant. Now with expressions were originally introduced to handle named constants, but having the pre-processor insert them here has a couple of issues. (Can you think of any?) Instead, the observation that a function which ignores its arguments acts like a constant (we don't have side-effects yet) is more useful. You can use _ (underscore) to name any dummy arguments you may need.

Benutzeravatar
mantra
Computerversteher
Computerversteher
Beiträge: 385
Registriert: 23. Okt 2005 23:56
Wohnort: Wiesbaden

Re: Third assignment now available

Beitrag von mantra »

But how can a function that ignores its argument be the same as a function without arguments?
Of course, evaluating the functions will have the same effect. Yet, the parse trees look different. There is one confusing test, which expects the result of (interp (parse ((preproc (..))) to yield a function without arguments.

In short: Are we asked/free to change other functions besides preproc? If not, is the test the way it was meant to be?

Benutzeravatar
sewe
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 295
Registriert: 16. Jan 2009 14:53
Kontaktdaten:

Re: Third assignment now available

Beitrag von sewe »


kde
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 123
Registriert: 19. Dez 2006 10:29
Kontaktdaten:

Re: Third assignment now available

Beitrag von kde »

Regarding task 6.
Is the generating of a list of numbers ([1..n]) already a list comprehension or may we use it in this task?
Tutor in SE: Design (& Construction) SS 2011

Benutzeravatar
sewe
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 295
Registriert: 16. Jan 2009 14:53
Kontaktdaten:

Re: Third assignment now available

Beitrag von sewe »

No, according to the Haskell 98 Report (http://www.haskell.org/onlinereport/exps.html, the Haskell standard), [1..n] is not a list comprehension, but an arithmetic sequence: if there is no vertical bar in there, it is not a list comprehension, but simply some kind of list literal.

Nori
Erstie
Erstie
Beiträge: 22
Registriert: 15. Nov 2006 17:40
Kontaktdaten:

Re: Third assignment now available

Beitrag von Nori »

I'm struggling with Task 3.

As far as I understand, the preproc not just has to nest function definitions, but also their calls.
So

Code: Alles auswählen

{{f {x y} {+x y}} 2 3}
expands to

Code: Alles auswählen

{{{f {x} {fun {y} {+ x y}}} 2} 3}
I find this difficult to implement, since preproc has to recognize not just function definitions, but also their calls, which could be initiated by about every symbol.

Any help?

Benutzeravatar
sewe
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 295
Registriert: 16. Jan 2009 14:53
Kontaktdaten:

Re: Third assignment now available

Beitrag von sewe »

Yes, you are right. The preprocessor also has to transform function applications. But identifying function applications is not too hard; have a look at the parser's source, as it does precisely that. I hope this helps.

Nori
Erstie
Erstie
Beiträge: 22
Registriert: 15. Nov 2006 17:40
Kontaktdaten:

Re: Third assignment now available

Beitrag von Nori »

Thanks, it's solved now.

Now, a question for task 1 remains: Should the function definitions also be stored in the environment? The evaluate function seems to distinguish between the fun-defs as a list, and the environment as a hash-table. So it seems like only variables should get stored in the hash-table.
And if it is ok to keep the fun-defs stored as the list, is it also ok just to reinterpret a function call as a "with" statement?

Benutzeravatar
sewe
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 295
Registriert: 16. Jan 2009 14:53
Kontaktdaten:

Re: Third assignment now available

Beitrag von sewe »

About task 1: No, function definitions need not be stored in the environment. In fact, they must not as we implement distinct namespaces for functions and variables/parameters (cf. Section 4.2 of the PLAI book). So, yes, it is OK to keep the fun-defs in a list.

In fact, this exercise is supposed to teach you about the use of a call stack, which is where variables/parameters reside. Functions are (in F1WAE) external to that. (In a compiler for this language they wouldn't be looked up at runtime at all, but rather looked up once at compile-time.)

Gesperrt

Zurück zu „Archiv“