BYU - Spring 2013 - CS 630 - 6/13 - Discussion
Andrew Kent
We discussed Honu today, beginning with the Honu Overview potion of the paper. We reviewed here some simple examples of what Honu looks like in general as well as what basic macros look like. As we reviewed the macros and started looking at some more of the less trivial examples a little bit of the power and expressibility of the macros here, vs other macro systems, started to show through. For instance, the derivative macro was defined in such a way that without parentheses or other more verbose delimiting, it can tell to take the derivative of a math expressions that is defined naturally, right there on the same line as the call to derivative. This allows the macro to look almost exactly like the mathematical statement of the desired operation (“D x, x*x - 5*x + c”) instead of some more complicated syntax. This was pretty cool and novel for an infix macro.
We moved on and reviewed syntax classes a little and then started talking about operators in Honu - and this led to a very interesting discussion. These operators, being infix and not prefix, have to have a precedence (and associativity) defined for. Jay mentioned that when he is working in an environment where associativity must be defined he struggles to get at what makes the most “sense” for the operator - after thinking about this as well I find this notion of the “associativity” is a rather foggy idea in my head. After, for example, looking at the C++ associativity of operators I can see why some are the way they are, but I would be hard pressed to, on the fly without preparation, intelligently talk about the associativity of various operators in depth. I like to spend my time thinking about other things. Similarly, and actually perhaps even worse, the decision for what “associativity” to assign an operator is entirely arbitrary (almost) - you have to choose a number that makes sense (likely you look at operators you are aware of or concerned about interoperability with) but there is no way to know if it in fact the “right” value because it’s just a number to allow it to participating in a total ordering - it has no “real” meaning.
The above ideas kind of revolves around a feeling I had and that we touched on during the discussion as well. Although at certain times the traditional infix notation may seem more appealing than the parentheses-plethora we see in Racket, as you really bear down into the details most of the reasons to favor infix entirely fall apart. The amount of overhead involved with reasoning about infix is drastically higher than parentheses (as articulated above). Most of the difficult to understand Racket you see is either because (a) you a n00blet still and your eyes are adjusting to see the code and not the parentheses or (b) the code is written poorly. The former dissipates in time... and so does the latter! (ideally...). And poorly written, difficult to read code is found all over the place in the land of infix toys. So really, except perhaps for clarity for some operations in very specific contexts I feel there is no logical basis to favor infix over prefix (array indexing we mentioned is rather short/elegant, and I personally feel like the period or arrow method for accessing fields/functions is very visually satisfying and far less verbose that the fruit-rollup of parenthesized function calls that can accrue, but I concede perhaps a let* or other appropriate methods in Racket I simply have not used as much would alleviate the rollup as well).
We dug into enforestation, parsing, and reading as well. The big cool take away from this after all the fun details was that because of how this is done, Honu doesn’t need to be “its own language” but really can just be a macro inside of a Racket program, boxed in a (honu-block ) expression. This led to some discussion over whether or not a simple, elegant way for making a small infix block might be useful (rather than the lengthy “honu-block”). Interesting.
Anyway, after all that, my thoughts are that I’m rather satisfied coding in Racket - or in other words I think the parentheses as syntax of Racket and other Scheme/Lisp languages is a strength and wish more people would learn about why they prefer infix or parans, instead of having an unfounded bias. Honu is pretty cool (it’s amazing that it’s just another thing you can build in Racket), but for me personally, it is a solution to a problem I don’t consider a problem. However, there are some little tasty morsels from infix I think could enrich Racket... it will be interesting to see if and how these make it into the language over time.
I don’t really have any questions, we talked a lot and I felt like I threw out all the relevant thoughts I wanted answers to.
Noonan
Summary: We discussed the problems with macros in C. We discussed how it’s hard to see how things are a single unit in lisp because it uses parenthesis to show this. We talked about why semicolons aren’t needed in Honu, but they can be used to force certain results. Honu has C-like syntax, but it’s still functional. It’s racket semantics with C syntax. To be honest right here is when I had to use the bathroom really bad and it took a while, so I missed about 20-30 minutes of lecture. We talked about the dollar sign in Honu vs. the back tick in Racket. Jay believes the the dollar sign isn’t primitive enough and eventually will not be what Honu needs. We then started reading parts of the paper. We talked about function calls in objective C. In objective C, it’s like you’re adding a primitive to the function when using internal colons and it’s handled by another function call. We then went over the operator form. Jay didn’t like the way that operators were done and the numbers that were assigned to operands when defining an operator in Honu. The ending argument was that it was too low-level for the users of the language. Jay also said it won’t really be obvious if it’s good or not until we use this pattern for operator definition for a while. We talked about how what you learn first is easily what you like. Jay made the comment that Honu looks like math. If that’s your first programming-like language, then you might actually want to see programs in a language that look like math. Jay then said something about how someone didn’t like his language proposal because it was a parenthesis heavy language. Then we started talking about parenthesis use in C and racket. Jay said that he uses parenthesis anyway in C. Then we talked about how braces and parenthesis are interchangable in Racket as long as they match. Then we did some examples in Racket using ellipses and how putting them in certain places made things ambiguous, Then we worked the quadratic function in Racket. We discusses how the usage of appropriate newlines and naming things can help make Racket more clear. It keeps the parenthesis from getting too nested. One of the problems with Racket and parenthesis is people don’t know how to make the code look better, they just see all of the parenthesis very quickly. Jay then discussed that people in the Racket community want to get rid of parenthesis, but is scared that if people can write Racket code like other languages, then they’ll just write the language like that and it will make the Racket language less popular because then people will just think Racket is a clone of another language. Jay then talked about how users don’t see the language that they use. Jay then talked about how a company used this to their advantage by using a better language and beating their competition in implementing new features after they were announced. We started discussing the limitations of the parsing done for Honu. If-else macros run into problems.
Something I learned: Basically, C-like syntax isn’t that big of a deal. Parenthesis are fine. I actually want to get more into Racket, I just need to find out how.
Lingering Questions: None
Matthew Ashcraft
Honu
This last discussion involved a lot more tangents than any other this semester. It seemed like they all revolved around how Honu is not a very good solution to the issue of lots of parenthesis in Racket. We did manage to finish the paper, though we did skip a decent amount. That which we did skip was basically the attempt by the author to show that things that could be done in Racket could still be done in Honu. We started off actually talking about the authors statement that parentheses are restrictive, and they are keeping other from coming to Racket. A interesting point was made I think by Andrew sometime during the discussion, that when writing mathematical operations in C, than he uses lots of parentheses because he is not always sure about the precedence of the operators. I know there have been plenty of times in the past where I have assumed the wrong precedence of mathematical operators, and it has been a nightmare to debug. Point being that I too use a lot of parentheses in C, so it really is not that much different than Racket. Additionally, it was mentioned that Racket is only really nasty when the code is not structured properly. When the code is laid out in a nice format, it is fairly easy to understand. I mentioned that this is the same with writing code in C with lots of classes and pointers, if the code isn't properly indented and spaced, then it can be extremely difficult to follow.
We then talked a little about infix, unary, and binary operators. It turns out the true meaning of infix is an operator which is placed not at the beginning or end of an expression in contrast to pre-fix and post-fix operators. For example (+ 1 2) is an pre-fix operator, (1 + 2) is an infix operator, and (1 2 +) is a post-fix operator (assuming these all preformed the addition of 1 and 2. After this little discussion we moved on to the overview of Honu. The example in section 2.1 was used to show some of the new features available with Honu. The main new features available are: the last expression evaluated acts as a return statement, semicolons are not needed but rather used to force grammar to act a certain way, and most important of all, Honu adds the ability to wrap blocks of code in curly braces instead of each section being wrapped in parentheses. The Honu macros were then discussed. A simple example was shown which found the derivative of a given function. This allowed a variable to be assigned a function, then the function could be passed a variable through the variable it was assigned to. The example we discussed, the function derivative(f) was transformed into var df = derivative(f), where the function could be passed a value by df(10). This could then be wrapped in a macro which took pattern variables and syntax classes.
The syntax classes of Honu were then brought up. We discussed what literals were again, as we had in past discussions, because I just wasn't quite sure I understood them. The patterns of the syntax classes without explicit syntax objects were then mentioned. These types of patterns take a default class of the raw term that was passed in. At this point we went on a big tangent regarding the uselessness of Honu. We talked about the desire many Racket users have to expand the user base of Racket, and how that should be done. Honu is obviously one attempt to expand the user base by making Racket accept syntax more similar to C and Javascript, but we all agreed that it probably wasn't the best idea. We talked about how making Racket more like Javascript might actually make it less popular because people will just associate it with Javascript. Then the discussion switched to what type of people do we want to use Racket. Currently there are many very talented users of Racket, but expanding the user base wouldn't necessarily improve Racket. In all reality it would probably make it worse because people would create poorly written and useless extensions to Racket, polluting the full version. This then turned into the secret weapon discussion, how the secret weapons are all that really matter. They are the people who truly understand the language and provide large contributions to the language or program. An example was given of a company that created a creator for online retail stores. Because they used Lisp, they were able to take press releases from their competition and implement them in their creator before their competitors release date. This is quite amazing because their competitor was probably working on it for an extended period of time before they even announced it.
After our long tangent, we took a break, then moved onto the
parsing of Honu. Almost everything in this section was the same for
Racket, so we spent all of our time on the enforestation information.
Jay went over the formal model of enforest, which I was able to
follow at the time. The enforest example made it much clearer. The
example transformed 1+2*3-f(10) into an enforest operator with tree
terms. This example really showed the core of their work. We talked a
little about the parsing of Honu, that enforest repeatedly is applies
to the top-level sequence of terms, and the bindings are detected and
recorded along the way. The parser handles mutually recursive
functions by delaying the parsing of blocks of code until all of the
declarations in the enclosing scope have been registered. Because of
this, macros can be declared after the function in which they are
used. This is actually the same as in Racket, so this was just to
show that Honu has not restricted Racket in any way. Since Honu is
actually just like a library, it probably is beneficial that it
exists since it allows blocks to be used without affecting Racket in
any other way.
Regarding the related work we had a small
discussion on the ZL language extension. From what I understood, ZL
is a C library that allows cross compilation. At this point there
were a bunch of random questions brought up, of which I don't
remember much about.
Overall I learned a great deal about functional programming and macro languages in general this semester, which hopefully I will be able to bring into some of my research. Thanks for offering this class Jay, and for all those who attended for your though-provoking questions and insights.
