Dynamic typing in OCaml

On many occasions on this site we've discussed embedding a dynamic type checking scheme in a statically typed language using a Univ type. On many of these occasions, it's been suggested that this is an in-principle solution that would never be usable in practice, Turing tar-pit, etc., etc. Well, someone decided to put their money where our mouths are, and now we have Dynaml.

I've only briefly looked at the tutorial, but this definitely goes a long way toward demonstrating a plausible Univ embedding of a dynamic type system. Of course, I'd be curious to hear what everyone else thinks...

(from the caml weekly news...) - CODeDOC 2002

CODeDOC 2002 was a collection of 'software art' projects. One work, W. Bradford Paley's [requires Java support in browser], is particularly interesting because it shows three different ways in which code is "read". The first, and simplest, is a linear scan through the source (the amber highlighting). Second is the sequence in which code was written (white). Third is the execution flow as the program executes.

It's striking how unrelated these three sequences are. Since temporal sequencing lies at the heart of programming, this struck me as worrying. But then, how should they be related? How should the program's structure and creation be related to its temporal flow? And, of course, how does this relate to the language chosen?

For example: if the code were purely declarative then why would there be any correlation between execution and layout? Is my intuition about the importance of any simple relationship between these flows misguided?

Anyway, it is certainly pretty.

Malbolge figured out?

Taken out of order:

From Ryan Kusnery's weird languages page:

The day that someone writes, in Malbolge, a program that simply copies its input to it's output, is the day my hair spontaneously turns green. It's the day that elephants are purple and camels fly, and a cow can fit through a needle's eye.


I've succeeded in writing a Malbolge program that copies its input to its output. Since some of it is non-printing, here it is uu-encoded...

In addition the page contains a proof of Turing Completeness (of a slight modification of the language), and suggestions on how it could be made harder.

The Underhanded C Contest

Inspired by Daniel Horn's Obfuscated V contest in the fall of 2004, we hereby announce an annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.

I wasn't aware of this contest. This concept sounds like fun, the idea being to write source code that easily passes visual inspection by other programmers.

The challenge for the first UCC is to write a simple program that performs some basic image-processing operation, for example smoothing or resampling, but manages to conceal a unique imperceptible fingerprint in each image it outputs.

Keep Blogging Worker Bee!

Jacob Matthews, of PLT fame, is writing a blog currently covering PLDI. It's an interesting and amusing read; check it out!

Happy Birthday, PHP...

As Slashdot observes, PHP was born 10 years ago on June 8th 1995.

It's had its knockers, but it's running this site...

Python Challenge

A well done set of Python challenges.

Some solutions can be found here, if you need help getting started...

Chris Coyne's Context Free Design Grammar, and SCIgen - Randomly generated CS papers.

Chris Coyne's Context Free Design Grammar was just mentioned by Perry Wagle on the #haskell irc channel. It's a beautiful use of simple concepts in a surprising manner. If you haven't seen the examples, you're missing out.

Chris mentions on the download page that's he's gotten a lot of hits because he's linked from SCIgen, the recently slashdotted automatic CS paper generation project at MIT. Even more amazing, One of their randomly generated papers was accepted.

Pugs, Practicing the Theories.

A lot of language theory goes past here on Lambda the Ultimate, but we rarely see that theory directly impacting commercial programmers.

I'm a great fan of theoretical concepts like arrows, but at the same time I'm a self-employed programmer interested in solving my clients' problems.

Pugs is notable in that it profitably uses recent developments such as GADTs and Template Haskell for an implementation of Perl6.

I recently became a regular on the #perl6 irc channel and soon after joined the list of committers.

In just a few days I've seen a lot. I've seen enthusiastic members of the Perl community learning Haskell. I've seen myself learning Perl. I've also seen how daily Perl programmers work with abstractions like monad transformers. I've seen how some structures are easy to extend for programmers new to both the Pugs codebase and Haskell.

The Pugs project was started 64 days ago by Autrijus Tang, as an exercise while reading TaPL. Pugs already includes network and threading primitives. New tests and code are add at an amazing rate, as evidenced by the smoke tests.

I don't know if I'll end up using Perl after Pugs is written, but I am learning how to practice the theory of programming language design and implementation.

Fold Must Fold!

The Fate Of LAMBDA in PLT Scheme v300
Lambda the Ultimate Design Flaw

About 30 years ago, Scheme had FILTER and MAP courtesy of Lisp hackers who missed them from their past experience. To this collection, Scheme added a lexically-scoped, properly-functioning LAMBDA. But, despite of the PR value of anything with Guy Steele's name associated with it, we think these features should be cut from PLT Scheme v300.

We think dropping FILTER and MAP is pretty uncontroversial; (filter P S) is almost always written clearer as a DO loop (plus the LAMBDA is slower than the loop). Even more so for (map F S). In all cases, writing the equivalent imperative program is clearly beneficial.

Why drop LAMBDA? Most Scheme users are unfamiliar with Alonzo Church (indeed, they don't even know that he was related to Guy Steele), so the name is confusing; also, there is a widespread misunderstanding that LAMBDA can do things that a nested function can't -- we still recall Dan Friedman's Aha! after we showed him that there was no difference! (However, he appears to have since lapsed in his ways.) Even with a better name, we think having the two choices side-by-side just requires programmers to think about their program; not having the choice streamlines the thought process, and Scheme is designed from the ground up to, as much as possible, keep programmers from thinking at all.

So now FOLD. This is actually the one we've always hated most, because, apart from a few examples involving + or *, almost every time we see a FOLD call with a non-trivial function argument, we have to grab pen and paper and imagine the *result* of a function flowing back in as the *argument* to a function. Plus, there are *more* arguments coming in on the side! This is all absurdly complicated. Because almost all the examples of FOLD we found in practice could be written as a simple loop with an accumulator, this style should be preferred, perhaps with us providing a simple helper function to abstract away the boilerplate code. At any rate, FOLD must fold.

--The PLT Scheme Team

This from the PLT Scheme mailing list. Clearly Guido's visionary thinking is having repercussions outside the world of Python. I, for one, welcome this change that can only benefit the Scheme language.

XML feed