Skip to content
Snippets Groups Projects
Commit afb7df2e authored by David Söderberg's avatar David Söderberg
Browse files

Update HOME_EXAM.md

parent a11bf866
No related branches found
No related tags found
No related merge requests found
# Home Exam D7050E
- Fork this repo and put your answers (or links to answers) in THIS file.
## Your repo
- Link to your repo here:
## Your syntax
- Give an as complete as possible EBNF grammar for your language.
> - Give an as complete as possible EBNF grammar for your language.
Program
```ebnf
......@@ -90,7 +88,7 @@ Expr1
```
Expr2
```ebnf
: Expr2 FactoreCode Lit
: Expr2 FactorCode Lit
| Lit
;
```
......@@ -103,7 +101,7 @@ Lit
| Num
| Id
| "&" Lit
| "&" "mut" Lit
| "&mut" Lit
| "*" Lit
| "(" Expr ")"
;
......@@ -111,7 +109,7 @@ Lit
Exprs
```ebnf
: "()"
| "(" [ "," ], Expr1 ")"
| "(" (Expr1 "," )+ ")"
;
```
ArCode
......@@ -144,7 +142,7 @@ Type
| "i32"
| "()"
| "&" Type
| "&" "mut" Type
| "&mut" Type
;
```
Bool
......@@ -159,10 +157,10 @@ Num
```
Id
```ebnf
: (LetterLower | LetterUpper | "_")(LetterLower | LetterUpper | Num | "_")*
: (LowerL | UpperL | "_")+ (LetterLower | LetterUpper | Num | "_")*
;
```
LetterLower
LowerL
```ebnf
: "a" | "b" | "c" | "d" | "e" | "f" | "g"
| "h" | "i" | "j" | "k" | "l" | "m" | "n"
......@@ -170,7 +168,7 @@ LetterLower
| "v" | "w" | "x" | "y" | "z"
```
LetterUpper
UpperL
```ebnf
: "A" | "B" | "C" | "D" | "E" | "F" | "G"
| "H" | "I" | "J" | "K" | "L" | "M" | "N"
......@@ -179,24 +177,22 @@ LetterUpper
```
- Give an example that showcases all rules of your EBNF. The program should "do" something as used in the next exercise.
> - Give an example that showcases all rules of your EBNF. The program should "do" something as used in the next exercise.
> - For your implementation, show that your compiler successfully accepts the input program.
Showcase of EBNF:
### Accpeted code
```rust
fn example(x: i32, y: bool) -> i32 {
let mut z : i32 = 1 + x;
if y {
z = z + -2
}
z
fn func(x:i32, y:i32) -> i32 {
x+y
}
fn test() -> bool {
let mut a = 3;
let b = &mut a;
*b = 1;
*b = 0;
while a <= 3 {
*b = example(*b, false);
while a < 10 {
*b = func(*b, 1);
}
let c = a / 3;
......@@ -207,26 +203,57 @@ Showcase of EBNF:
}
```
- For your implementation, show that your compiler successfully accepts the input program.
> - Give a set of examples that are syntactically illegal, and rejected by your compiler.
Run the input program
### Bad code
- Give a set of examples that are syntactically illegal, and rejected by your compiler.
Different kinds of misstypes
``` rust
f func(x:i32, y:i32) -> i32 {
x-y
}
```
``` rust
illegal stuff;
lte a = 1;
```
- Compare your solution to the requirements (as stated in the README.md). What are your contributions to the implementation.
Mixed positions
``` rust
let x mut = false;
```
##### Future implementation
Not yet implemented
``` rust
fn func(){
fn func2(){
fn func3(){
//...
}
}
}
```
> - Compare your solution to the requirements (as stated in the README.md). What are your contributions to the implementation.
##### Our syntax support the most basic subset of rust, including
- Primitive types such as i32 and boolean
- Functions with the primitive return types
- let, if, if else, while, assign, return
- Precedence of operands by dividing them into arithmetic, conditional and logical operands.
- Possbility for ArCode (addition and subtraction) to have precedence over FactorCode(multiplication and division) by parenthesized precedence
##### Future implementation
- Better error handling with location information
- More types
- Nestled functions
- Global variables
- Pretty printing
## Your semantics
```
- Give a (simplified) Structural Operational Semantics (SOS) for your language. You don't need to detail rules that are similar (follow the same pattern). Regarding variable environment (store) you may omit details as long as the presentation is easy to follow.
- Explain (in text) what an interpretation of your example should produce, do that by dry running your given example step by step. Relate back to the SOS rules. You may skip repetitions to avoid cluttering.
```
> - Give a (simplified) Structural Operational Semantics (SOS) for your language. You don't need to detail rules that are similar (follow the same pattern). Regarding variable environment (store) you may omit details as long as the presentation is easy to follow.
> - Explain (in text) what an interpretation of your example should produce, do that by dry running your given example step by step. Relate back to the SOS rules. You may skip repetitions
##### Symbols:
- σ, state
......@@ -371,20 +398,40 @@ while a < 10 {
a = a + 1;
}
```
```
- For your implementation, give a program (or set of test programs) that cover all the semantics of your language that you have successfully implemented. (Maybe a subset of the input language accepted by the grammar.)
- Compare your solution to the requirements (as stated in the README.md). What are your contributions to the implementation.
> - For your implementation, give a program (or set of test programs) that cover all the semantics of your language that you have successfully implemented. (Maybe a subset of the input language accepted by the grammar.)
```rust
fn func(x:i32, y:i32) -> i32 {
x+y
}
fn test() -> bool {
let mut a = 3;
let b = &mut a;
*b = 0;
while a < 10 {
*b = func(*b, 1);
}
let c = a / 3;
}
fn main() {
test();
}
```
## Your type checker
- Give a simplified set of Type Checking Rules for your language (those rules look very much like the SOS rules, but over types not values). Also here you don't need to detail rules that are similar (follow the same pattern).
> - Give a simplified set of Type Checking Rules for your language (those rules look very much like the SOS rules, but over types not values). Also here you don't need to detail rules that are similar (follow the same pattern).
- Demonstrate each "type rule" by an example. You may use one or several "programs" to showcase where rules successfully apply.
> - Demonstrate each "type rule" by an example. You may use one or several "programs" to showcase where rules successfully apply.
- For your implementation, give a set of programs demonstrating that ill-typed programs are rejected, connect back to the Type Checking Rules to argue why these are illegal and thus should be rejected.
> - For your implementation, give a set of programs demonstrating that ill-typed programs are rejected, connect back to the Type Checking Rules to argue why these are illegal and thus should be rejected.
- Compare your solution to the requirements (as stated in the README.md). What are your contributions to the implementation.
> - Compare your solution to the requirements (as stated in the README.md). What are your contributions to the implementation.
## Your borrrow checker
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment