This repository has been archived by the owner on Aug 21, 2018. It is now read-only.
forked from hmc-cs111-fall2014/piconot
-
Notifications
You must be signed in to change notification settings - Fork 0
/
evaluation.txt
90 lines (72 loc) · 4.73 KB
/
evaluation.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
================================================================================
September 22, 2014
================================================================================
We found that there was no easy way to create an ‘=‘ function. Any other symbol
similar to the equal sign was also difficult to implement. The best we could do
is ‘->’.
When we originally created our language, we didn’t realize there was a stay put
direction for Picobot. In order to implement this option, we switched the order
of the transition state and the new direction on the rhs of the equation. That
way, the first argument will always be a state and the second argument will be
a direction, but if the direction is not there, then it will default to staying
still. This made it so that we didn’t have to add an extra ‘x’ case for
directions, which would then be something we need to check for on the lhs of
the equation.
We also added a lot of defaults and made it so that the user could put it
something vaguely math-y and it would still come out as a proper Picobot rule.
For example, “42 -> 3” would evaluate to “42 **** => x 3” in the original
Picobot language. Also, if the user put in something like
“42 + e * e - e -> 4 + n”, it would evaluate to “42 *E** => N 4”. If the user
puts in multiple definitions for the same direction, the last one will be the
only one that will become a part of the rule.
================================================================================
September 26, 2014
================================================================================
We experienced difficulty in specifying directions when making a rule without
saying something like 'ruleClass.s'. We got around this by making 'dir' a trait,
and then n, e, w, and s were classes that extended dir with a companion object
for each.
We realized that not everyone in the group was thrilled about having spaces
between arithmetic operators and directions, which was our original design.
Because the person who was writing code today is the one who was the most
vehemently opposed to spaces, they managed to tweak the language so that spaces
were not required.
We also had problems with the '*' operator binding closer than the '+' or '-'
operator, which made it so rules were not evaluated in the correct order. At
the moment, we have changed everything to mathbotRules, including the dirs.
Though this does not currently give us any errors, we worry about this giving
our users too much flexibility to the user, allowing something like 'w' to be
a rule by itself.
================================================================================
September 27, 2014
================================================================================
We are having difficulties with our case statements. We have many different
levels of inheritance involving the classes for picobot directions and we are
not pattern-matching to them correctly. The error messages can be cryptic
sometimes and we have to carefully examine what Scala thinks the types of each
object is in a line of code to debug it.
We resolved the previous problem by redesigning our inheritance structures and using
the Eclipse-recommended tick-marks around the classes we're matching against.
We think we would have had a really hard time discovering this convention if
Eclipse warnings have not suggested it.
We are now working on elimiting the List() syntax around our Mathbot rules. We
find it difficult to incorporate additional syntax structures without re-
thinking existing code/architecture and possibly modifying them.
We added the "Proof" keyword to hide underlaying syntax such as
"val emptyMaze = Maze("resources" + File.separator + "empty.txt")"
But currently, "emptyRoom.txt" is hardcoded into our implementation and syntax.
We are working on separating it out as a new argument.
We implemented some top-level syntactic sugar to make a set of mathbot rules
look like a proof for a given picobot environment. Now our grammar begins the
program with "Proof.", reads in a picobot environment with the keyword Begin(),
lists the picobot rules using the keyword Consider, and the program is ran by
the keyword QED.
Finally, the "*" operator broke again due to our previous changes. We could not
find a satisfying solution that make it work on either side of the "->"
operator, so we decided to eliminate the use of "*" from our grammar. Our
syntax is equally expressive without it, because any direction left unspecified
will default to the state "Anything".
We're very sad that we could not find a solution to fix this and support "*".
Our main issues is that pattern-matching is extremely powerful but poorly-
documented. The slightest change in scala syntax can completely change the
meaning of our code.