Soumya Kundu, Drew Monroe, Sailesh Simhadri

Updates

We’ve made some minor feature additions this week that bring us close to our goal of a minimum viable product. We added the ability to highlight the text by hovering over a shape on the frontend. We also support a new syntax for specifying circles. These two goals were the only two features that we had not yet supported that we wanted to be a part of our minimum viable product. We also restructured some of our code to support polygons, as opposed to specific shapes. This should make it easier for the user to create arbitrary shapes, and makes it easier for us to parse the shapes We talked about many design features this week, and we have documented the discussions and decisions that we’ve made below.

Case insensitivity

One of the minor problems that we’ve encountered is case sensitivity. One of our design goals is to keep our markup as unintrusive as possible. This means that we want to markup arbitrary text, without needing to worry about minor details, like case sensitivity. Furthermore, since we are presenting the unmarked text to the user, it is important to keep the case sensitivity of the original text. As such, we decided that our keywords should work if they have capital as well as lowercase letters.

Polygons

As we start to develop more advanced syntax, we realize that we’re going to need to support more than just circles and triangles. However, it becomes difficult for us to write the parser the more shapes that we support. For example, we would need a way to parse rectangles, squares, pentagons, as well as other shapes. Rather than implement all of this, we decided that we would support a generic “polygon” object. The user can supply the points that he or she wishes to be in the polygon, and we will implicitly create lines between adjacent points, making the polygon. This greatly simplifies the process that we have for parsing these shapes, and should not require too much extra effort from the user.

Circle Types

Geometrically speaking, there are two ways to specify a circle: either by giving three points on the circle, or by giving a center and a radius. Prior to this week, we only supported giving three points to define a circle, but it is natural to assume that the user also would want to specify a circle the other way. In order to implement this, we are diving into the realm of keyword arguments. Now, a user can specify a circle as follows:

[circle center=F radius=10 name=ABC]

to create a circle, centered at point F, with a radius of 10, and called ABC. We believe this syntax to not only be clean, but also to be quite intuitive and easy to read. We are utilizing spaces to delimit different keyword arguments, as it makes the markup read much more like English, which is one of our design goals. We considered doing positional arguments, for example forcing the user to enter the name first, then the center, then the radius, as follows:

[circle ABC F 10]

however, we did not feel that this syntax was clear. The user would need to remember the order they would need to provide the arguments in, and it becomes harder to read. Furthermore, the keyword argument approach cleanly allows for some arguments to be omitted. For example, if the user did not want to specify a radius, for example if one of the points on the circle already existed, they can simply omit the radius keyword. In the future, our parser will hopefully be smart enough to realize that the radius is implicitly defined.

Hidden Objects

We also discussed providing the ability for the user to create objects that are not necessarily displayed on the screen. Perhaps, in the future, our compiler will be able to implicitly determine the location of points automatically, and the user wants to confine points to a shape, but does not want the shape displayed. In order to support this, we need a way to specify that an object should be hidden. There were two syntaxes that we considered for this. The first was to use the * character at the start of object type to indicate that it was hidden. One of the pluses of this approach is that it is not intrusive. By only adding one character, it does not alter the core text very much. However, one of the problems with this is that it is not clear exactly what the * character would mean just by looking at the markup. As such, we decided that we would use a hidden keyword instead, to specify an object that should not be displayed. While it is somewhat more intrusive, it is much more clear what the keyword is actually doing.