Lambda the Ultimate

Paul McJones has been curating ALGOL section of Software Preservation Group. He notes:

I recently created an ALGOL section at the Computer History Museum’s Software Preservation Group web site, covering the language standardization efforts — for ALGOL 58 (also known as the International Algebraic Language), ALGOL 60, and ALGOL 68 — and also covering many implementations, dialects, and offshoots, complete with source code, manuals, and papers for many of these. The history of ALGOL has attracted many writers, and the final section of the web site links to many of their papers.

Also see his follow up blog about Whetstone ALGOL.

In recent weeks the volume of new spammer accounts has grown considerably. These accounts are sometimes used to post spam messages to the discussion group, but more often are simply used to game google by including spam urls in the user profile.

Due to the high volume of new spammer accounts I have implemented a new policy regarding new accounts. Given how things play out, it may become permanent:

1. New accounts are bocked by default, until released by an administrator. The user receives an email explaining this. While blocked, the user profile is invisible to anyone but the site administrators. They are also, of course, unable to sign in.

2. Accounts that seem legitimate, are released, while accounts that are clearly spam (e.g., from know spammers, include spam urls) are either deleted or put in the spammer category.

3. Accounts that we can't be sure about may be put in the "on probation" category. Members of this class can post, but their posts will appear only after being reviewed by an administrator. If the user turns out to be legitimate, it will be moved to the regular category, allowing the member to post directly.

4. Note that the "on probation" category is also used for members who are not spammers, but are considered or tend to post messages that are off topic. The messages posted by users that are on probation are in general reviewed by me before being allowed to appear.

New users are advised that by putting a short sentence or two about their specific interests relating to PL in their user profile, they will help us allow them to post sooner.

David MacIver is doing a bit of a sociological study on how programmers pick The Right Tool for the job. Programmers select all the languages they know from a fairly mainstream and popular list and then rank those languages according to statements like "I find it easy to write efficient code in this language" and "When I write code in this language I can be very sure it is correct". At the end of the process the survey taker can see how languages ranked overall under each statement and what statements have been most strongly associated with each language.

Obviously this isn't a formal study and, as with all online surveys, there are going to be challenges with selection bias and with people trying to game the system. None-the-less, it is pretty interesting and fun as is. Perhaps something similar would be worth doing under more controlled circumstances (although it beats me how to feasibly get a large sample size of programmers without introducing selection bias).

On Iteration, by Andrei Alexandrescu.

Lisp pioneered forward iteration using singly-linked lists. Later object-oriented container designs often used the Iterator design pattern to offer sequential access using iterators. Though iterators are safe and sensible, their interface prevents definition of flexible, general, and efficient container-independent algorithms. For example, you can't reasonably expect to sort, organize as a binary heap, or even reverse a container by just using its Iterator. At about the same time, C++'s Standard Template Library (STL) defines its own conceptual hierarchy of iterators and shows that container-independent algorithms are possible using that hierarchy. However, STL iterators are marred by lack of safety, difficulty of usage, difficulty of definition, and a very close relationship to C++ that limits adoption by other languages. I propose an API that combines the advantages of Iterator and STL, and I bring evidence that the proposed abstraction is sensible by implementing a superset of STL's algorithms in the D language's standard library.

Previously: Iterators Must Go.

One goal in a public release is influence by example. I'd like future software to sport nice measurement units.

A review sequence by depth of interest: overview, worked examples, backgrounder, unit catalogs, QuickStart.nb, and finally DesignerUnits.nb which houses code. Core sections are "Unit Algebra - Productions - Main Algebra" and "Quantity Analysis."

This will probably interest many LtU readers:

Code Quarterly is a new publication [edited by Peter Seibel] that intends to publish in-depth articles of interest to hackers...

Here are some of the kinds of articles we hope to publish:

* Technical explanations – Pieces that explain a concept and why we should care...
* Code reads – guided tours through code that demonstrates interesting programming techniques or which is simply well-put-together, beautiful code.
* Q&A interviews – in-depth interviews with notable programmers.
* Think pieces – pieces about not-entirely-technical issues hackers would care about...
* Computer history – articles that take a look back at where our ideas about computers came from.
* Book reviews

If this sounds interesting and you can see yourself as either a a reader or a potential contributor hop over to the site and let them know.

The Monad Zipper by Bruno Oliveira and Tom Schrijvers

Limitations of monad stacks get in the way of developing highly
modular programs with effects. This pearl demonstrates that Functional
Programming’s abstraction tools are up to the challenge. Of
course, abstraction must be followed by clever instantiation: Huet’s
zipper for the monad stack makes components jump through unanticipated
hoops.

The monad zipper gives us new ways to compose monadic code operating with different transformer stacks. To put it another way, it extends our ability to compose systems using different ranges of effects.

The Structure of Authority: Why security is not a separable concern, by Mark S. Miller, Bill Tulloh, and Jonathan Shapiro:

Common programming practice grants excess authority for the sake of functionality; programming principles require least authority for the sake of security. If we practice our principles, we could have both security and functionality. Treating security as a separate concern has not succeeded in bridging the gap between principle and practice, because it operates without knowledge of what constitutes least authority. Only when requests are made -- whether by humans acting through a user interface, or by one object invoking another -- can we determine how much authority is adequate. Without this knowledge, we must provide programs with enough authority to do anything they might be requested to do.

We examine the practice of least authority at four major layers of abstraction -- from humans in an organization down to individual objects within a programming language. We explain the special role of object-capability languages -- such as E or the proposed Oz-E -- in supporting practical least authority.

An important overview of why security properties cannot be an after-thought for any platform, languages and operating systems included. To this end, the paper covers security properties at various granularities from desktop down to object-level granularity, and how object-capabilities provide security properties that are compositional, and permit safely composing mutually suspicious programs.

A recent LtU discussion on achieving security by built-in object-capabilities vs. building security frameworks as libraries reminded me of this paper. Ultimately, the library approach can work assuming side-effects are properly controlled via some mechanism, ie. effect types or monads, but any solution should conform to object capability principles to maintain safe composition.

An example of a capability-secure legacy/library approach is Plash (Principle of Least Authority SHell), which provides object-specific file system name spaces. Any library interface to the file system should mimic this file system virtualization, which effectively pushes side-effect control down to OS-level objects, and which is essential to safely composing mutually suspicious programs that access the file system.

VMKit: a Substrate for Managed Runtime Environments, VEE '10

Managed Runtime Environments (MREs), such as the JVM and the CLI, form an attractive environment for program execution, by providing portability and safety, via the use of a bytecode language and automatic memory management, as well as good performance, via just-in-time (JIT) compilation. Nevertheless, developing a fully featured MRE, including e.g. a garbage collector and JIT compiler, is a herculean task. As a result, new languages cannot easily take advantage of the benefits of MREs, and it is difficult to experiment with extensions of existing MRE based languages.

This paper describes and evaluates VMKit, a first attempt to build a common substrate that eases the development of high-level MREs. We have successfully used VMKit to build two MREs: a Java Virtual Machine and a Common Language Runtime. We provide an extensive study of the lessons learned in developing this infrastructure, and assess the ease of implementing new MREs or MRE extensions and the resulting performance. In particular, it took one of the authors only one month to develop a Common Language Runtime using VMKit. VMKit furthermore has performance comparable to the well established open source MREs Cacao, Apache Harmony and Mono, and is 1.2 to 3 times slower than JikesRVM on most of the DaCapo benchmarks.

So... One person built a CLR using VMKit in one month. One consequence of such faster development speeds is that language designers do not have to feel so restricted when targeting a Managed Runtime Environment for their language. If the MRE they want to target has restrictions, they can fork it. If the MRE specification has a gray area, then they can quickly prototype a solution to clarify what the behavior should be for that gray area of the specification. If you are a researcher/student and want to experiment with a new language design and implementation, then you can do so incrementally by first augmenting the MRE and then targeting your language to that new MRE; you can then benchmark the improvements by using the original MRE as a baseline.

Last week, the SEC put out a 667 page proposal regarding disclosures for asset backed securities. What I found exciting was this:

We are proposing to require that most ABS issuers file a computer program that gives effect to the flow of funds, or “waterfall,” provisions of the transaction. We are proposing that the computer program be filed on EDGAR in the form of downloadable source code in Python. … (page 205)

http://jrvarma.wordpress.com/2010/04/16/the-sec-and-the-python/

I don't have more time to comment on this, so the post is a bit scrappy. Sorry!