BYU - Spring 2013 - CS630 - 5/30 - Discussion

2 views
Skip to first unread message

Noonan

unread,
May 30, 2013, 11:34:56 PM5/30/13
to byu-cs-630-spring-2013

Summary: We first talked about the idea behind lisp design, that it was designed so that the programmer could write a language that fit the domain of the problem and then use that language to solve the problem. We also talked about what an eager language is. An eager language evaluates arguments at the time the function call takes place, a lazy langauge evaluates them when they are actually used. We also talked about the purpose of type systems. They’re a fast way of proving certain properties about a program, but are more restrictive than a formal proof (rejects valid programs). We also briefly discussed the purpose of a fender and how they were used and what made them impractical. We then talked about the purpose of blame prediction. We then discussed the contract system and ways that it fails and also how it differs from a type system (it does not check properties on parts of the program that aren’t run). We then discussed the restrictions of the paper. We discussed why we tag macros when we expand them (to stop the same expansion from happening twice). We then discussed the semantics reduction figure. We also stepped through the match and transcribe functions in the paper in order to demonstrate the semantics.


Something I Learned: Iearned the abstract definition of what a type system is. I also learned the real purpose behind the blame prediction paper, something I struggled with the first time I read it.


Lingering Questions: None, for now...


Yu Huang

unread,
May 31, 2013, 7:30:24 PM5/31/13
to byu-cs-630-...@googlegroups.com
Title: Taming Macros

Summary: We first compare the type system, static analysis and theorem proving. Type system is fast and automated, static analysis is slow but also automated. Theorem is however not automated. We then define the type system. It is a polynomial time decision procedure. We also compared macros with functions such that macros are more complex because it is not easy to say "what you want". We showed the division example in class. First we used functions to capture exceptions, but it was a pain. We then introduced contract system to fix the problems. Then we compared the type system and the contract system where contract system is lazily checking procedure. 

Things I understood: understood the purpose of the type system and how it is different from contract system. The example shown in class strengthened my understanding why functions sometimes does not satisfy our requirements. 

Things I have trouble understanding: still, the syntax is hard to read. 
Reply all
Reply to author
Forward
0 new messages