Lambda the Ultimate

[Chicken-users] macro systems and chicken (long), Alex Shinn, Apr 2008.

There seems to be a lot of confusion in the Chicken
community, and the Lisp community in general, about the
different macro systems, so I thought provide some
background information and discussion of the eggs available
in Chicken and their uses.

A very nice post that provides a historical overview and implementations of a hygienic (swap! a b) macro in different macro systems: syntactic closures, reverse syntactic closures, explicit renaming, syntax-case, and syntax-rules.

I didn't know syntactic closures before, and find their interface and implementation simple and easy to understand. Any reasons why they aren't used more in Scheme?

After reading about like and wrap in Ecmascript I began thinking about possibility of at compile time checking that parameters passed to functions are a duck for that method. For example say you had:

def quack(duck):
duck.aMethod()
duck.anotherMethod()


It would see that duck requires aMethod and anotherMethod methods, and then check that all calls to quack pass in types that have these methods. Is something like this possible? Or am I failing to see something important that prevents having static analysis for duck typing languages.

If, for example, I have three functions (X a), (Y b), (Z c); and suppose that each has been complied and proven correct somehow. Now if I compose the three functions (X (Y (Z c))) is the answer proven also given the types match. I remember a paper posted on the home page that seemed to prove this, but can't seem to find it.

Simply efficient functional reactivity. Conal Elliott.

Functional reactive programming (FRP) has simple and powerful semantics, but has resisted efficient implementation. In particular, most past implementations have used demand-driven sampling, which accommodates FRP's continuous time semantics and fits well with the nature of functional programming. Consequently, values are wastefully recomputed even when inputs don't change, and reaction latency can be as high as the sampling period.

This paper presents a way to implement FRP that combines data- and demand-driven evaluation, in which values are recomputed only when necessary, and reactions are nearly instantaneous. The implementation is rooted in a new simple formulation of FRP and its semantics and so is easy to understand and reason about.

On the road to efficiency and simplicity, we'll meet some old friends (monoids, functors, applicative functors, monads, morphisms, and improving values) and make some new friends (functional future values, reactive normal form, and concurrent “unambiguous choice”).

I'm not sure exactly where to classify this submission to ICFP 2008, but I think many here will be interested in it.