Lambda the Ultimate

The new iPhone developer agreement as quoted at http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Now think about this. Basically, they have said "you can only use these PLs to originally write your code, use of any other PLs breaks this agreement." Now, assume iPhone continues to be widely successful and that...eventually PCs are replaced by iPad devices. And say everyone starts copying Apple's locked fortress model, where will PL innovation go?

I'm very disappointed at Apple over this.

Hoopl: A Modular, Reusable Library for Dataflow Analysis and Transformation, by Simon Peyton Jones, João Dias and Norman Ramsey (ICFP 2010.)

Abstract. Dataflow analysis and transformation of control-flow graphs is pervasive in optimizing compilers, but it is typically tightly interwoven with the details of a particular compiler. We describe Hoopl, a reusable Haskell library that makes it unusually easy to define new analyses and transformations for any compiler. Hoopl's interface is modular and polymorphic, and it offers unusually strong static guarantees. The implementation is also far from routine: it encapsulates state-of-the-art algorithms (interleaved analysis and rewriting, dynamic error isolation), and it cleanly separates their tricky elements so that they can be understood independently.

A vastly different paper than the last one by the same trio (available here,) this one is more of an example of how to write a client for the Hoopl optimization library, and describes some of Hoopl's innovative static guarantees for making sure the analysis is correct. It also describes the newer implementation of the Lerner/Grove/Chambers algorithm for interleaving analysis and transformations. There's even more good news: Hoopl is now on hackage, so you can get started writing your own optimizers!

Hello, I am trying to figure out a schema to implement
multithreading on multiple cores for an language that
I'd like to design. First of all I came to the
conclusion that you cannot use native threads. Using
native threads means that your language implementation
can interrupt at any time, making a single asm-insn
the unit of atomicy. You need tons of synchronication
and need to think about raceconditions etc. which
explodes code complexity. The benefits of native
threads can better be achieved using custom programmed
threads, meaning: simple stack switching with a few
assembler insn. I found that the latest google-go
gcc branch of Ian Tailor is working on gcc support
for variable size stacks and split stacks: that means
you can increase the stack size dynamicaly while
executing. The only need for native threads would be
for blocking i/o, therefore I'd partition by langauge
implementation in 2 native threads, one handling the
I/o and the other implementing the threading in
custom fashion. Implementing threading myself means:
I can implement cooperative threading.
I can define blocks of atomicy without need of synchronisation.
I can derive a garbage collection schema where I can
ignore stack references.
Now I was thinking quite a long time on how to handle
multicore. Having handled mutithreading the easy way
i dont want to start over with synchronication on insn
level. Up till now didnt came up with a enlighting solution

therefore I'd like to know weather someone can give
me a idea...

The only thing that I came up would be
cross calls: A object belongs to a CPU. Every CPU
has a worker-thread running on every other CPU. If a CPU
tries to modify a object that doesnt belong to himself
if has to do a crosscall: If need to wake up the worker-thread
on the owner's cpu....
With only a few global objects this scheme might be applicable,
however it will shurely kill the system if you have
a lot of global objects...
Is there some other way to avoid the synchronization
overkill in multicode mode....
-- Greetings Konrad