archives

Expressions vs Statements

While trying to generalize the structure of a program and its source code, I came across this fundamental question, that I still don't manage to answer properly : "what is the difference between expressions and statements".

I am pretty sure that there are many folks here with a different answer from "42" ;)

new GUI paradigm

The latest alert box from UI guru Jakob Nielsen would be rather fascinating if it wasn't so darned obvious: the latest paradigm in UI is no longer OO (WYSIWYG is fundamentally a stateful OO paradigm) but is declarative -- they call it results-oriented. But read the alert box, and it will be astoundingly clear that, instead of issuing commands to modify state (ie OO), the new thing is to instead specify your goals. There must be a good PL angle to this story!

Ah well, back to doing some good old command-line stuff for me -- since at least that is based on a functional paradigm!

Syntactic Abstraction in Component Interfaces

Culpepper, Owens, Flatt. Syntactic Abstraction in Component Interfaces. GPCE 2005.

In this paper, we show how to combine a component system and a macro system. A component system separates the definition of a program fragment from the statements that link it, enabling indepen­dent compilation of the fragment. A macro system, in contrast, relies on explicit links among fragments that import macros, since macro ex­pansion must happen at compile time. Our combination places macro definitions inside component signatures, thereby permitting macro ex­pansion at compile time, while still allowing independent compilation and linking for the run-­time part of components.

Implementing Higher Order Messages

My colleage Nat Pryce has recently posted a challenge which given the recent discussion about 'expressions vs statements' I thought might interest the LtU crowd.

In this post: http://nat.truemesh.com/archives/000535.html he talks what he calls Higher Order Messages. This is basically a way to use higher order functions to abstract away complex traversal code in favour of a series of chained method calls.

So instead of selecting all the elements that match a predicate and then calling a method on them you do this:

elements.where.somePredicate.do.aMethod

Ordinarily this wouldn't be relevant to LtU but his post: http://nat.truemesh.com/archives/000537.html on implementing this idea in Ruby has led to alternative implementations in Java and Scala: https://lampblogs.epfl.ch/b2evolution/blogs/index.php?blog=7&title=higher_order_messages_in_scala&more=1&c=1&tb=1&pb=1