Merge pull request #8 from YouClid/Polygon-Post

Add post about polygons

_posts/2017-11-09-Polygon.md

@@ -0,0 +1,64 @@
+---
+layout: post
+title:  "Polygon Support"
+date:   2017-11-09 23:19:00-0400
+categories: jekyll update
+---
+#### 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.