Lambda the Ultimate

Discussed here.

We discussed Hibernate, and O/R mapping in general, a couple of times so I thought this might be of interest.

A Type System Equivalent to Flow Analysis

Flow-based safety analysis of higher-order languages has been studied by Shivers, and Palsberg and Schwartzbach. Open until now is the problem of finding a type system that accepts exactly the same programs as safety analysis. In this paper we prove that Amadio and Cardelli's type system with subtyping and recursive types accepts the same programs as a certain safety analysis. The proof involves mappings from types to flow information and back. As a result, we obtain an inference algorithm for the type system, thereby solving an open problem.

I believe it's instructive to see type systems in this light. Did we discuss something like this recently?

The pi-Calculus in Direct Style

We introduce a calculus which is a direct extension of both the
lambda and the pi calculi. We give a simple type system for it, that
encompasses both Curry's type inference for the lambda-calculus,
and Milner's sorting for the pi-calculus as particular cases of
typing. We observe that the various continuation passing style
transformations for lambda-terms, written in our calculus, actually
correspond to encodings already given by Milner and others
for evaluation strategies of lambda-terms into the pi-calculus. Furthermore,
the associated sortings correspond to well-known
double negation translations on types. Finally we provide an
adequate cps transform from our calculus to the pi-calculus.

This shows that the latter may be regarded as an "assembly
language", while our calculus seems to provide a better
programming
notation for higher-order concurrency.

a.k.a. Blue Calculus

The official Microsoft statement,

Microsoft has decided not to ship a client-side XQuery implementation in the final version of .NET 2.0 Framework ("Whidbey")....

However, we will be shipping a subset of XQuery in SQL Server ("Yukon") 2005. The reason for this is the new native XML datatype in SQL Server 2005. Microsoft recommends XQuery as the way to re-shape, query, and modify XML data within SQL Server 2005.

Reminds me of this discussion ;-)

This article isn't really about programming languages, but some of the claims made should be scrutinized by PL mavens,

The idea of programming-language determinism has some truth to it, but is overrated. Because we are often tackling the same problems in C, Perl, Scheme, Smalltalk, and so on, we can usually find a way to analyze them and code solutions using common designs. Sometimes the features of a particular language make a particular solution much more elegant and comprehensible, and in that case form influences content. But these languages have enough common ground that they can share many designs. C may have pre-increment and post-increment operators, but you can still add 1 to a variable in any language that supports variables.

I agree with some of the style tips the author gives, but I think understanding the different abstraction facilities different languages offer is even more important for writing readable and maintainable code.

Poly* is a novel retargetable meta type system for various process and mobility calculi. Poly* is a direct descendant of PolyA, a type system for Mobile Ambients by Amtoft, Makholm, and Wells. Meta* is a generic process calculus that can be instantiated to specific process calculi like the Pi-calculus and Mobile Ambients by supplying reduction rules.

A web interface is available for experimentation after you can read the technical report and ESOP 2005 paper.

The list of common questions and answers about Poly* may be a good place to start if you are merely curious.

BitC language specification, version 0.4. Out of the new Coyotos project, successor of Eros and KeyOS, comes this new language:

BitC is conceptually derived in various measure from Standard ML, Scheme, and C. Like Standard ML [CITE], BitC has a formal semantics, static typing, a type inference mechanism, and type variables. Like Scheme [CITE], BitC uses a surface syntax that is readily represented as BitC data. Like C [CITE], BitC provides full control over data structure representation, which is necessary for high-performance systems programming. The BitC language is a direct expression of the typed lambda calculus with side effects, extended to be able to reflect the semantics of explicit representation.

(via Slashdot)

This discussion over on the Haskell Mailing List might interest those readers following the debates on concurrency issues in the discussion group...

Forwarded message from Timothy J Hickey
-----

Cc: peter@norvig.com, Geoffrey Knauth ,
Kathleen Huber
From: Timothy J Hickey
To: JScheme Developers ,
Jscheme Users
Subject: [Jscheme-user] Sad News about Ken Anderson
Date: Sat, 22 Jan 2005 09:37:37 -0500

Dear JScheme community,

I'm sorry to bring you the very sad news that Ken Anderson,
one of the co-developers of JScheme, died last night at the Spam
conference
in Cambridge. He was in great spirits, talking about JScheme, when
he collapsed mid-sentence.

Ken was one of the three main developers of JScheme.
JScheme had two parent languages -- Peter Norvig's SILK
and Tim Hickey's Jscheme applet. Ken came onto the project
in the beginning (1997) and built the Scheme-Java interface that became
the javadot notation. He was responsible for the beautifully designed
cache techniques that make javadot so efficient. He also
was a tireless developer, chasing down bugs, dreaming up and
seriously analyzing proposed new optimizations. He was a
talented software engineer who loved building an elegant
and simultaneously practical language. He was also a really
nice guy. Kind, generous, thoughtful. The world is a poorer
place for his passing.

Ken touched many lives and brought many communities together.
I worked with him on JScheme for 2-3 years (publishing two papers)
before I met him in person (or even knew what he looked like!)
We've met regularly since to plot the future of JScheme and to
share our war stories of JScheme in the world. He has played
a major role in the Lightweight Language conferences and was
also an active player in the anti-Spam effort. I will miss him,
as I'm sure many other will as well.

JScheme will remain an active project and is very much part
of what Ken has given to the world. I am honored to have been
his friend and codeveloper.

Sincerely,

---Tim Hickey---

We mentioned O'Haskell previously on LtU, but a recent discussion of OOP vs. FP vs. everything made be to believe that it's worth to remember this (unfortunately unsupported) programming language.

It's instructive to read the rationale for this PL, as it helps to see how OOP and FP solve similar tasks in orthogonal (or just different) ways.

Note that the author of O'Haskell abandoned it in favor of Timber.