Lambda the Ultimate

I've just begun reading Whitehead and Russell's "Principia Mathematica" available here and was surprised to find on page 9 a nice readable alternative to parentheses for grouping.

Each operator is preceded and/or succeeded by some dots written as colons and periods. The more dots an operator has, the lower precedence it has. To take one of their examples (page 10),
p -> q .->. q -> r :->. p -> r
means
((p -> q) -> (q -> r)) -> (p -> r)

I find the dot version more readable and easier to type than the parentheses version. I'm curious if anyone here knows of other alternatives to parentheses for grouping. Prefix and postfix we've all heard of here, but do you have less well known ones? Hideous or beautiful I'd love to see them! Have any been tried in programming languages?

I am looking for any papers that analyze the design of cascading stylesheets with respect to bounded times. I could derive this myself, but it would be nice to have a peer reviewed authority. It would also be cool if anyone ever bothered to do this for Hakon Wum-Lie's original CHSS (Cascading HTML Style Sheets) and Bert Bos's original SSP (Stream-based Style Sheet Proposal) prior to them being merged into CSS 1.0. Also, Dynamic Properties that were in Internet Explorer from 5.0 through 7.0, but deprecated in 8.0.

The only thing I found so far was a webpage: CSS, selectors and computational complexity. However, this doesn't communicate the complexity on how selectors place solving constraints on the layout engine to update each widget's CSS box model.

I'm also interested in knowing if anybody has done anything to model compatibilities across browsers. All I found was this (mindblowing) Comparison of layout engines and their support for CSS.

I don't think anyone has actually done anything to formally investigate the most widely used DSL in the world and the affect it has on clockcycles as well as programmer man-hours...

Thanks.

Lunascript, our in-house language for writing great web apps:

Inspired by incremental computing, we're building Lunascript as a simple way to write modern web applications. Lunascript has a syntax and easy of use reminiscent of JavaScript, but a powerful pure-functional lazily-evaluated semantics historically confined to academic languages.

A Lunascript application specifes a data model and a function from the model to the view or user interface, annotated with handler functions from user inputs to model mutations. From this the Lunascript compiler produces a functioning Web2.0 application -- the client-side JavaScript, the server-side SQL, and everything in between -- complete with real-time bidirectional data synchronization.

I'll have to wait for more info on this definitely interesting project, but right now I'm a bit sceptical, as this seems to throw REST out the window.

As I started learning category methods, I noticed that my prior attitude dismissing it as "abstract nonsense" was based upon ignorance. As somebody with physics background I begin to appreciate shifting emphasis from objects onto symmetry, invariance (err morphisms). So in order to understand structure one has to master morphisms. Fine.

Let's compare this with algebraic perspective. There we study objects and operations between them. When we constrain those operations with some axioms we get an algebraic system. A significant part of studying a concrete algebra would be discovering its axiom system. For example, Relation Algebra has been discovered by Pierce, but hasn't been fully axiomatized until Tarski.

Now, how would I study Relation Algebra with methods of category theory? As discovery is significant element of algebraic method and category theory is in a sense dual perspective, I'd guess drawing arrows wouldn't advance me too much, and I would have to discover some important morphisms... Perhaps, a helpful analogy would be how is it done in other categories (preferably, from elementary mathematical fields:-)?

Is anybody aware of university courses (or textbooks) with a focus on the design of just-in-time compilers (JITs)? (Basically, as alternative to a standard compiler construction course)

In the last few years there has been some interesting research on the topic of JITs, (many being mentioned here on LtU), e.g., the Javascript JITs (TraceMonkey, Google V8), the PyPy JIT, LuaJIT, the recent story about verified JITs, Factor's compilation strategy might also be of interest, etc..

So far, I have not found any course focusing on JITs. At most, some compiler construction courses mention JIT technology (usually Java's) in passing. The textbook situation seems to be equally bland.

As a mathematician who's quite new to type theory, I have only vaguely internalised the fact that forall a.a and Pi a.a (or whatever the appropriate ASCII-isations are) mean the same thing. Thus, although it seems obvious to me that forall a.a is empty (or does one say uninhabited?), I was nonetheless quite startled to read the following in Barendregt's "Introduction to generalised type systems", p. 132:

… write \bot \equiv (\Pi \alpha : *. \alpha), which is the second-order definition of falsum.

I tried to re-cast this in language more familiar to me, and wound up with the statement that the product of all sets is empty.

Now, I know that type theories tend (understandably) to be biased more towards constructivist than traditional ZFC-based axiomatisations; but it seems to me that, beyond just saying that we don't assume the Axiom of Choice, this statement is saying that we take that axiom as the definition of ‘false’! Is the rejection of choosiness really so definitive, or am I just skipping over some point (like, say, that some sets are empty, so that including them in the product will naturally make it, too, empty)?

We're familiar with the notion of function composition which is essentially sticking functions end-to-end:

(a -> b) -> (b -> c) -> (a -> c)

However, is there any formal treatment of function "concatenation" for functions that operate on n-tuples that would be essentially sticking functions "side-by-side"? The type would be something like this (where a, b, c, and d are n-tuples and ++ is the concatenation operator):

(a -> b) -> (c -> d) -> (a ++ c) -> (b ++ d)

I think a visual example allows a good intuition for what I'm talking about. If F is a function from a 1-tuple to a 2-tuple, and G is a function from a 2-tuple to a 1-tuple, then their composition would be this:

     IN
      |
   .--o--------.
   |     F     |
   |--o-----o--|
      |     |
   .--o-----o--.
   |     G     |
   |--o--------|
      |
     OUT

and their concatenation would be this:

     IN          IN    IN
      |           |     |
   .--o--------.--o-----o--.
   |     F     |     G     |
   |--o-----o--|--o--------|
      |     |     |
     OUT   OUT   OUT

Composition indicates a dependence (e.g. G is dependent on the output of F) that requires sequential evaluation whereas concatenation indicates an independence (e.g. F and G do not share inputs) that allows for parallel evaluation. Both operations are associative.

There exist operations with a similar spirit to the concatenation expressed above: the functional form of construction in Backus's FP, the *** operator for the -> arrow in Haskell, and the family of spread combinators in Factor to name a few. However, none of these deal with concatenated inputs/outputs and none of these are associative, so they're not quite what I'm after.

Any pointers towards related mathematical notions or languages with a similar feature would be much appreciated.

Apparently Qi4J has been released (Qi4J was previously noted very briefly on LtU here).

Qi4j is a significant step forward for the Java platform, with its focus on Domain Driven Design and support for the Data-Context-Interactionexternal link paradigm that is currently being worked on by Trygve Reenskaug as a way to revive object-orientation.

See the tutorials to get a feel for it, I guess.

So, with the understanding that algorithms should define roles for collaborating objects, and objects should then implement these in order to participate in these algorithms, it should be trivial to realize that what has passed for OOP so far, in terms of "class oriented programming", where this role-focus of objects is difficult to achieve, if not even impossible, is just plain wrong. I mean seriously, catastrophically, terminally wrong.

While PHP deservedly gets a terrible rep around programming language folks, this is still an interesting announcement: HipHop compiles PHP down to C++ and gets about a 2x speedup. HipHop will be released as open source, and is currently in production use, serving 90% of Facebook's traffic. It makes me wish Facebook used Python: a large-scale deployment like this would be a great boon to the PyPy project.

I'm just now learning Lisp. It is really sort of fun, but I am thinking that the parentheses issue is probably going to end up being the thing that keeps biting me on the butt. It seems to me that they really shouldn't be much different than managing braces in C, say. Indenting helps. But even if I try to keep that all in order, I get fouled up when I revise or insert code, and waste a lot of time checking the parens and looking for their matches and whatnot.

Has anyone some suggestions on how to approach this issue with Lisp? A good IDE that looks after us poor devils, for example? Or some good habits to get into?

Budsy