Possible Fix - Update on Atom Implementation

[Stubeans]

Sorry for the wait, I've got a lot of studying/assignments. I will hopefully implement new features as a part of the homework sometime tomorrow, ( or really today, now, Wednesday )

[Stubeans]

Is there a list of things I could implement to complete this homework, or should I just find something that exists in Python we don't already have and try to make it work?

[Tientuine]

@Stubeans We had an issue with the for-merging branch, and apparently it has corrupted your branch. I'm going to fix your branch, but then I will need you to delete your local branch and then pull your branch again.

After that, please fix one last error... you can't have your implementation for valueOf preceding its type declaration. That causes a problem. You should always stack build to make sure it compiles, then you would discover that there's an issue here.

[Stubeans]

@Tientuine I'm not sure what I just did to my repo, I thought i was working with a clean new version of my branch and then when I went to push my changes it asked to marge. I'm not sure If I merged it correctly however, could you take a look?

[Stubeans]

I have also attempted to add elif and else to the current if statement to complete the homework. I commented it out, but does that look right?

[Tientuine]

I'll take a look and see if I can figure out what happened. In the meantime, either hold off on other work or just make a new branch (e.g., Smith-morework) from for-merging and do any additional work on there.

[Tientuine]

I have also attempted to add elif and else to the current if statement to complete the homework. I commented it out, but does that look right?

Max is already working on those, but we had some branch issues tonight. Some of that work-in-progress was inadvertently merged before it was ready, which is why you may have seen snippets of that code get pulled into your branch earlier.

[Stubeans]

@Tientuine I see that my Atom implementation was commented out of the Interp.hs file in for_merging. Should I stop working on the Atom component, and focus on a second implementation per the homework?

Which leads me to my second question, to avoid working on something that's already being done could you give me something to focus on trying to implement in this final day? I am very busy trying to complete another final project and I'm finding myself running out of time.

Edit: And should I still try to comment on other pull requests per the homework as well?

[Tientuine]

It's only commented out because it got merged prematurely but doesn't compile yet. Please make the last remaining for for the binary operations and then we can merge that in.

As for additional work, no one ever went back to fix the parse issue for integer and float literals, see Issue #32 . I expected that Cole might do it because he was the one who initially added support for literals, but if he's not taking it then that would be a good one to knock out.

[Stubeans]

Now I know I have to work with the lines underlined in red, I'm just not exactly sure how to write the lines. i can see that the way the two lines 'talk' to each other is through the value that must represent an empty BinaryOp. Does this mean I have to write another line here with a different value than , and set it equal to what? A BinaryExpr op exp1 exp2?

And then when I change the bottom portion, how do I implement another case for that? Am I writing the code that takes the resulting St1 and St2, putting them into an Answer?

[Tientuine]

Now I know I have to work with the lines underlined in red, I'm just not exactly sure how to write the lines. i can see that the way the two lines 'talk' to each other is through the value that must represent an empty BinaryOp. Does this mean I have to write another line here with a different value than , and set it equal to what? A BinaryExpr op exp1 exp2?

And then when I change the bottom portion, how do I implement another case for that? Am I writing the code that takes the resulting St1 and St2, putting them into an Answer?

Here's the problem - once you define a function, you can't re-define it. The first line where you declare either the type of a function or define an implementation of the function (even just one case) effectively declares the function. Then, if you declare the type again, it's an error, think of it as a "split function definition." Consider the following example:

-- This is okay
f :: Int -> Float -> Float
f 0 x = 0
f _ x = x

-- This is not okay
g 0 x = 0
g :: Int -> Float -> Float
g _ x = x

[Stubeans]

migrating to Smith_morework, this branch won't build properly