Lambda the Ultimate

In
this paper, we present a typeful approach to implementing objects that makes use of a recently introduced notion of guarded datatypes. In particular, we demonstrate how the feature of multiple inheritance can be supported with this approach, presenting a simple and general account for multiple inheritance in a typeful manner.

[snip]

We refer the reader to [XCC03,Xi02] for further details on this typeful approach to OOP (with single inheritance). The treatment of multiple inheritance in this paper bears a great deal of similarity to the treatment of single inheritance in [XCC03,Xi02], though there are also some substantial differences involved. In order to handle multiple inheritance, we are to treat a path from a (super) class to a (sub)class as a first-class value.

I was thinking of possibly making all functions in the Heron programming language into classes with a single public field named "result". I was wondering what other languages do similar things to this, and what the advantages / disadvantages might be of such as approach.

I have posted an example of Heron code which would model this apporach at http://www.artima.com/weblogs/viewpost.jsp?thread=116558

Thanks in advance!

I'm trying to write a denotational semantics and I'm having a problem. I seem to only be able to express what I want by writing code that generates code, rather than just writing code. By "code" I mean my lambda-calculus-like definitional language. (Actually I plan to use Haskell for this and thus get a semantics and a reference implementation "for free" but I digress.)

Anyway, I could give specifics, and perhaps the question doesn't make sense without specifics (if so, I'll be glad to post what I have) but I wonder if anyone has some high-level comments on this type of problem.

It seems like a general problem in programming not specific to denotational semantics, actually. It seems like the idea of generative programming accomodates the need to generate code at compile-time, but I'm not as familiar with efforts to accomodate run-time ("dynamic") code generation. LISP macros? For one thing this style of programming requires the language to have an "eval" function or similar, or requires the program to ship with a compiler.

Before I saw C++ templates, I generally considered generating code to be a sign of weakness of the programmer and/or the language, because my primary example was C with the C preprocessor. Now I've changed my mind, and I wonder whether we try to put too much into languages whereas we could somehow have simpler languages with more powerful code generation facilities.

Oh well, I'm kind of rambling at this point, so I'll stop since I've probably provided plenty of fodder for feedback.

Epigram system, being invented by Conor McBride, is an implementation of dependently typed functional programming language Epigram, designed by Conor McBride himself and James McKinna. (See their paper The View From The Left). Good Epigram tutorial you can find here. Also see Wikipedia.

Being not fully content with editing capabilities of currently available version of Epigram system, a.k.a. Durham Epigram, I decided to develop my own editor for Epigram language using a tool called MPS. I named my editor MPgram.

At the moment, I've already written something of MPgram which is able to be played with, and I created a page for MPgram, where MPgram is available for everyone to download.
http://www.jetbrains.net/confluence/display/MPS/Epigram

The best place to feed back is MPS EAP forum, I think.

Here's a question I've promoted from another thread (sorry for the multiple postings).

What's the difference between static type inference (like in Haskell) and a latent (tagged) type system (think Scheme) with a real good partial evaluator? In the type-inference situation, we're using unification to solve a set of constraints. If there's no solution, we give up and say the program was ill-typed. On the other hand, it seems like tag checking code in a latently typed lanugage would be a good candidate to get partially evaluated away at compile time. For example it seems like...

;; typed values are really pairs of values and types
;; e.g. (123 . 'number)
;;      ("abc" . 'string)
(define (isnumber n) (eq? (cdr n) 'number))
(define (add arg1 arg2)
    (if (and (isnumber arg1) (isnumber arg2))
        (machine-add (car arg1) (car arg2))
        (error "not a number")))

(add '(4 . number) '(5 . number))

...should be easily changed into...

(machind-add 4 5)

... And after we're done partially evaluating our source, if we still have left over type-check predicates like 'isnumber' in the code then we again declare that the program is ill-typed. Are the two methods comparable in any way? Is one method more powerful than the other, or are they somehow duals of each other? Are there any papers available discussing this?

Anton van Straaten recommends looking at a previous typing thread, and the paper Types as Abstract Interpretations, as well as a posting of his to the LL mailing list. Any futher thoughts?

Is there any difference between the terms "applicative" and "functional" when applied to programming languages?

As far as I can see from googling a bit, the answer is no, they are used interchangeably, although perhaps applicative is used less frequently. Does applicative reduction order imply strictness? If so, wouldn't it be sensible to have "applicative" to mean "strict functional"? And perhaps "normative" for "nonstrict functional" (assuming normal reduction order implies non-strictness)? Oh well, even if that were a sensible distinction, I guess the ship has sailed.

This Excel file (contains a viewable and editable macro) does the minimal sudoku in a second or so. - and it's not by brute force! - any comments welcomed.

www.brightonandhove.org/sudoku/solver5c.xls
Of course, you need Excel to run it- and OpenOffice won't do it. ;0)...... yet.

I just posted a new article for imperative-loving people about why recursive programming is better than imperative programming.

Here's the article: Mastering Recursive Programming

I thought you all might be interested, and I am interested in any comments, criticisms, additions, subtractions you all have.

A Call to Arms - Jim Gray, ACM Queue

"The really big news here is that these languages have also been fully integrated into the current crop of object-relational databases. The runtimes have actually been added to the database engines themselves such that one can now write database stored procedures (modules), while at the same time defining database objects as classes within these languages."

Big-time language lock-in.

JavaScript 2.0: Evolving a Language for Evolving Systems (pdf) Waldemar Horwat

JavaScript 2.0 is the next major revision of the JavaScript language. Also known as ECMAScript Edition 4, it is being standardized by the ECMA organization.