Lambda the Ultimate

Where the word "Call" stands for phone call, not procedure call.

Call Processing Language (CPL): A Language for User Control of Internet Telephony Services

This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs.

When I saw the requirement to have no loops I thought about Epigram immediately... If it only was edited easily by graphical clients ;-)

On a serious side - here is a nice example of real life requirement to be NOT Turing complete!

The November 2004 edition of the biannual Haskell Communities and Activities Report has been published. Lots of new stuff in the last six months, and some old stuff updated as well. The HC&AR has been steadily growing over the last three years, showing that FP is gaining users both professional and private.

Several of the HC&AR items are interesting enough to have their own LtU stories, which may appear shortly.

A more remrkable example of a Wiki backed by a Wiki specific DSL.

The guided tours on Jotspot's website aren't very useful. I recommend viewing Jon Udell's discussion cum demo with the Jotspot guys.

The most important point for PL types is the notion of programmability. The world is going in that direction, and this should work to our advantage guys... Language design is becoming more mainstream, but it's still hard work that requires good linguistic intuition.

It seems that the Jotspot guys are aware of this trend, seeing as they talk about "part time programmers".

WikiTalk is the new FlexWiki behavior language. WikiTalk is a simple object-oriented language that advanced users can use to add dynamic behavior to their FlexWiki topics. Additionally, administrators can use WikiTalk to customize the web user-interface for FlexWiki.

A Wiki DSL for FlexWiki (now shared source). What a lovely idea...

But see here for comments from people who are not in love with DSLs as I am...

From the University of Waterloo Computer Graphics Lab comes Sh:

Writing programs for these GPUs can be a tedious task, as it generally has to be done in assembly. A high-level language allows programming GPUs with familiar constructs and syntax, without worrying about the details of the hardware. A high-level language is also important for portability across different hardware and graphics API platforms. Sh is such a high-level language. It offers the convenient syntax of C++ and takes the burden of register allocation and other low-level issues away from the programmer. This allows GPU programs to be written much quicker and makes porting such programs extremely simple.

See also this recent article on Gamasutra (requires login, free)

The scripting in MzTake is done in the FrTime language. This connection is based on the observation that the program being monitored is a source of events, and FrTime is designed well to receive events from the outside world. Therefore, the script programmer has the full power of FrTime (which includes almost all of Scheme, graphical routines and some rudimentary GUI support, in addition to several event-based programming primitives) for automating program monitoring.

The site includes several examples that are worth checking even if you aren't planning on installing MzTake.

I like the idea of program monitoring. It is related to the notion of instrumentation, which is of course a well known sofware design technique.

This is yet another example of how language design can help handle software engineering issues.

Slideshow: Functional Presentations. Findler, Flatt. ICFP 2004.

Nothing earth shattering, but a nice example of DSL design none the less.

Might be useful for teaching (as well as for creating slideshows...)

Snowball is a small string processing language designed for creating stemming algorithms for use in Information Retrieval.

And here's a sample program.

I am not sure just how exciting this language is, but it has been a while since we discussed a DSL.

Simon Johnston (IBM/Rational) on Domain Specific Languages and refinement:

My position is that the creation of domain specific languages that do not seamlessly support the ability to transform information along the refinement scale are not helpful to us. So, for example, a component designer that is a stand alone tool unconnected to the class designer that provides the next logical level of refinement (classes being used to construct components) is a pot hole in the road from concept to actual implementation. Now, this is not as I have said to indicate that domain specific languages are bad, just that many of us in this industry love to create new languages be they graphical, textual or conceptual. We have to beware of the tendency to build these disjoint languages that force the user to keep stopping and jumping across another gap.

I am not sure I want to go back to the argument between IBM and Microsoft about this stuff, but I think the notion of refinement is important from a linguistic point of view (e.g., embedding, language evolution, type systems, reasoning etc.)

But can refinement of the sort discussed here work in practice, or does it depend on language-design savvy architects? Maybe the difference between IBM and Microsoft is that the IBM approach assumes all modelling knowledge will come pre-packaged, being designed by modelling professionals and embedded in tools, where as the Microsoft approach assumes more design expertise from users?

Feel free to correct me, I am really unsure where all this is heading anyway...