Lambda the Ultimate

OpenSCAD is a software for creating solid 3D CAD objects... OpenSCAD is not an interactive modeller. Instead it is something like a 3D-compiler that reads in a script file that describes the object and renders the 3D model from this script file (see examples below). This gives you (the designer) full control over the modelling process and enables you to easily change any step in the modelling process or make designes that are defined by configurable parameters.

In days gone by I used to post examples demonstrating the power of DSLs over GUIs. This is a nice example I came across recently. The scripting approach may be useful, of course, to 2D CAD as well. Here is an amusing example.

Maybe the analog computing DSL I fantasized about should output SCAD scripts instead of compiling directly to g-code...

Intel Concurrent Collections...provides a mechanism for constructing [programs] that will execute in parallel while allowing the application developer to ignore issues of parallelism such as low-level threading constructs or the scheduling and distribution of computations. The model allows the programmer to specify high-level computational steps including inputs and outputs without imposing unnecessary ordering on their execution... Data is either local to a computational step or it is explicitly produced and consumed by them. An application in this programming model supports multiple styles of parallelism (e.g., data, task, pipeline parallel). While the interface between the computational steps and the runtime system remains unchanged, a wide range of runtime systems may target different architectures (e.g., shared memory, distributed) or support different scheduling methodologies (e.g., static or dynamic).

In short CnC purports to be a "a graph-based data-flow-esque deterministic parallel programming model". An open-source Haskell edition of the software was recently released on Hackage.

A series of blog posts describe the implementation: #1, #2, #3, #4, #5 (the last post links to a draft paper).

Personally, I would have preferred a more concise and down to earth description on the whole thing. If you have experiences to share, please do.

Why Undergraduates Should Learn the Principles of Programming Languages

The linked document is the first public release of a document discussing the value of programming languages principles for undergraduate CS majors. The intended audience is computer scientists who are not specialists in programming languages. Please leave comments on how well you believe it meets its goals and with suggestions for improvements.

Abstract: Undergraduate students obtain important knowledge and skills by studying the pragmatics of programming in multiple languages and the principles underlying programming language design and implementation. These topics strengthen students' grasp of the power of computation, help students choose the most appropriate programming model and language for a given problem, and improve their design skills. Understanding programming languages thus helps students in ways vital to many career paths and interests.

It would be nice if people interested in this as much as Kim Bruce could actively post such stuff to LtU as contributing editors, hint hint professors...

Edit: In case Kim Bruce is listening, I found this link today via Hacker News posting. There are some comments there, too.

This paper lists the most widely used languages on Red Hat Linux in 2001/2002. They were: C, C++, Shell, (Emacs) Lisp, and assembler (in that order).

It's generally agreed in the literature that language support for namespace management is important, but only one (C++) of the 5 most popular languages actually has that feature. The other four scrape by with manual prefixing of exported names, and have resulted in some of the largest and most widely used software systems in existence (Linux kernel, GNU, Emacs).

I don't want to go as far as saying that the lack of namespace management could be a cause for their success, but rather ask the question: Is it crazy to design a new language with a single, flat namespace, or could it actually be worthwhile?

For various reasons, I am looking for (or looking to develop) a lambda calculus and a semantics that I can use to structure set-theoretic calculations. In other words, I want to be able to write things like (set-filter p A), which returns the subset of A for which p is true, even when A is uncountable. I don't need to write set-filter in this lambda calculus, but I want to include it as a primitive operation (along with membership, cartesian product, etc.), and well-founded sets as primitive values.

My main question: am I going to run into foundational problems, specifically with the ZF axioms? Has someone already tried this and written about it?

I'm not concerned with whether the sets or set operations are computable. I'm not concerned with mathematical foundations, except for the possibility that they might pose difficulties. Having types isn't necessary, and neither is having every lambda denote a set-theoretic function. It doesn't matter whether any given set can be expressed in a finite or even countable number of symbols. I don't need to use only a minimal collection of primitives. (In fact, I'd be nice if I could import them on a whim.)

I want to use the syntax and structure of the lambda calculus, especially lambda abstraction, to express calculations that a particular group of applied mathematicians is interested in. After that, I can consider what subclass of these calculations is computable - but limiting the language to computable calculations right away feels like premature optimization.

It seems easy to do. I'm asking because I found a subtlety in a related lambda calculus + semantics, and there might be more. If someone has found them already, I'd like to know.

(The subtlety, which I half expected, came up when trying to interpret (lambda x in A . e) as a set-theoretic function; i.e. as the set of points in its graph. The simple rule I wrote requires unrestricted comprehension when an enclosing lambda is applied to itself. Denotational semantics provides a solution, but I don't want that kind of complexity. I also decided I didn't need to interpret certain lambda forms as set-theoretic functions, either, if it would make things simpler.)