From 2bd3c46d8ba2d12372451b515a948046c8d70f2f Mon Sep 17 00:00:00 2001 From: Drew Monroe Date: Thu, 9 Nov 2017 23:51:19 -0500 Subject: [PATCH] Add post about polygons --- _posts/2017-11-09-Polygon.md | 64 ++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 _posts/2017-11-09-Polygon.md diff --git a/_posts/2017-11-09-Polygon.md b/_posts/2017-11-09-Polygon.md new file mode 100644 index 0000000..3cba492 --- /dev/null +++ b/_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.