BYU - Spring 2013 - CS 630 - 6/6 - Discussion
Andrew Kent
**summary
We began our discussion briefly talking about other (non-Racket) endeavors to try and create new and interesting programming languages by building on previously existing virtual machines/platforms to benefit from the libraries and facilities that already exist therein. These attempts, although being more efficient than building from “scratch,” are still limited by the environments they are built on.
We transitioned then to Typed Racket and discussing the various tools and methods that are needed to be able to embed the type system into Racket in such a way that it is simple and naturally fits in with what is already there.
One of the methods we discussed we syntax-properties - this was a property lookup/mapping you can use on a syntax object to store information. This allows the type information to be injected into the standard Racket syntax without mucking up every line. %module-begin we talked about and looked at an example of, how it is sort of a macro wrapper around the entire module that you are in that allows you to do module wide things (like checking type, etc..). Local expansion we discussed as well - this allows syntax to be expanded in just one local instance so it may be evaluated and worked with. This allows Typed Racket to never worry about what macros are being utilized, and only worry about the core representation of their expansion.
We had some examples (both in the paper and in Racket during class) of how contracts work and looked at how they are used by Type Racket to bridge the boundaries between typed and untyped modules. This led (or maybe the opposite order...) to talking about how to handle blame for contract violation when you are giving contracts to things you are importing from another module.
We discussed what optimizations can be done when using typed Racket. I had not realized that around 30% of execution time is spent checking tags for boxed (all dynamically typed) values, and this can be avoided in Typed Racket since the type checking itself validates the types of the operations which normally would be tag checked. We also talked a little about the use of unsafe operations as an optimization when you can make assumptions about your identifier types as well.
This led to our discussion and review of the various benchmarks Racket and Typed Racket were run against. We reviewed what languages they were comparing to Racket and talked a little about each.
**main things I learned and/or thought deeply about
I feel like I got a better understanding of the details that were a little fuzzy discussing them in class. Namely what %module-begin is and how it works (at a high level), some more of the features of syntax objects. I also better understood some of the details about how specifically typed and untyped programs can interoperate.
Blame was something I had seen from the TFP presentations and I thought was interesting, although during the presentation I didn’t appreciate the concept as much as I do now.
I really enjoyed the discussion about how Macro 2-way communication and the stuff Blake is going to start hacking away at could create or allow some of the optimizations that we saw in typed Racket but not with the constraints of typed Racket. Having a more robust way to do static analysis and observe/infer specific types and thus optimize the optimizations seems like a very cool idea and I’m very curious to see what kind of performance differences it would provide.
**lingering question
- Okay... so the work Jeremy Siek was doing in gradual typing (adding type annotations to some code and having other code remain dynamically typed - for those that didn’t see the talk)... that sounds (or at least my memories of it) really similar to the usages of Typed with regular Racket that we discussed today. What is similar and different about those two approaches?
Noonan
Summary: We started talking about the introduction of the paper and how racket had already been pursuing the current movements in the language community related to Java and Scala. You can add key, value pairs to syntax objects for fast look-up when expanding a syntax object. We talked about how local-expand works that it can fully expand something to look inside it. We then talked about two aspects of the module system. One is you can export value bindings as well as static bindings. That means you shouldn’t be able to tell how a piece of an abstraction was implemented. This aspect of the module system enforces that. We then talked about module-begin. It’s a macro that allows you to have an outermost macro about your module. This makes it easier to reason about your module. Then we started talking about typed racket. So typed racket uses a syntax-parse to modify define to include a type. Then we started talking about the optimizer for typed Racket. Jay showed the optimizer. We talked about the pair class optimizer. The macro basically grabs the optimized part of the pair expression using rewriting. Then we talked about the optimizer for floats. It breaks computation into the real and imaginary part and performs the computation separately. We then talked about box implementation. They’re pointers to pointers. We then talked about how JITs optimize operations on boxes (detect unboxing opportunities). We talked about Java array implementation. We talked about the add operation in C and how it’s really a dispatch to the CPU, the user has no control over what kind of add is performed. We talked about the example of performing an unsafe operation on a string type. We talked about how typed racket works when dealing with modules that are typed are imported into untyped modules and vice versa. We talked about clients defining contracts on untyped modules. Contracts should only be in provide statements, not required statements. This is because if it’s in a require statement, the client is forcing a contract on the server, but the server is unaware of that. In that case, the blame would technically point at the server, but that doesn’t show that it was a contract imposed on the client by the server. Jay said there should be another point of blame, the person who made the contract. Then Jay said there should be a fourth point of blame. We worked an example where it ended up blaming the contract instead of the user of the function. We then started talking about typechecking in racket. Module-begin was redefined so the check can take place. We started talking about the for macro in the context of types and the different approaches of handling it. It would be bad for the type checker to know about the for (Tight coupling between system and for, bad), other solution is for knowing about the type system, which is also bad. There needs to be a way of specifying type judgments for macros. Jay’s Solution: require this macro, give it this type.
Something I learned or thought deeply about: I learned how Racket’s optimization works. I found that interesting.
Lingering Questions: So I didn’t quite get the 3rd and fourth points of blame example. I didn’t quite catch the difference between them.
Jay McCarthy
--
Jay McCarthy <j...@cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
"The glory of God is Intelligence" - D&C 93
