Lambda the Ultimate

Olin Shivers and David Fisher. Multi-return Function Call. In Proceedings of ICFP '04.

It is possible to extend the basic notion of "function call" to allow functions to have multiple return points. This turns out to be a surprisingly useful mechanism. [...] We conclude that multiple-return function call is not only a useful and expressive mechanism, both at the source-code and intermediate-representation level, but is also quite inexpensive to implement.

Especially interesting are the cases where a tail call can actually shrink the stack.

A thought-provoking article in the ACM Queue (linked to by Slashdot, so it may be a bit slow).

  Natural Programming Languages and Environments

There some good ideas in there, especially with regards to debugging. However, I've always thought of "natural" programming languages as something that the "average" user would want to use for everyday tasks in some system. I think it's hard to avoid getting into the nitty-gritty details when building large systems that you want to be time and/or space efficient in terms of runtime resources (not necessarily development time).

It was interesting to note that rule-based and event-based structure was deemed to be the most common way people naturally expressed the way to solve a problem. Yet, logic-based languages (that use rules) seem to be the hardest for a lot programmers/students to pick up on. (That's been my experience, anyway.)

For some more discussion that is considerably older (showing that the topic is certainly not new...), you can check out something Dijkstra and Sammet had to say (with slightly differing opinions).

  On the foolishness of "natural language processing" (Dijkstra)

  The use of English as a programming language (Sammet, requires ACM membership to view)

Recently there were a few discussion on some MS blogs about the design of the "switch" statement. I'm curios what readers of LtU have to say about it.

See: Links to blog discussions about "switch".

Not a terribly new paper, but things are slow and I don't think we've discussed it before:

Parameterized modules in Erlang

This is neat stuff, and it's actually been included in recent versions of Erlang. I once toyed with the idea of a language which emphasized an OO style with stateless objects (relying on Erlang-style concurrency patterns for management of state). It seems like Erlang has just made a huge leap toward being that language.

The caveat, though, is that I'm not actually an Erlang programmer, only an interested observer. Do any of the local Erlang folks have any thoughts on this?

Hello everyone.

During my PhD I encountered a nice problem.

The system I was working on (an object-oriented database) evolved over time to use 4 different languages. Each language was tailored to one specific activity (querying, operations, data, meta-data).
They also are based on different programming paradigms: functional and imperative.

Over time I realized that the system could benefit from a merge of all these langauges in a single one.

I managed to do it and the result is interesting, but I could not find any material on such a procedure.

Does anyone of you know of some references/papers/articles related to the merging of programming languages?

A short news item about micro-rebooting courtesy of an ACM mail. Giving Bugs the Boot. Erlang anyone?

Another quiet time post...

I am considering a language comparison experiment that will take a bit of time, and would be interested in any comments or suggestions that might make the results more interesting/significant. This is primarily for my own interest.

There don't seem to be any studies where the same piece of software has been implemented twice, in two different languages and paradigms by the same person/people. I plan to do this, writing a smallish, but non-trivial program twice from scratch.

Such a comparison will of course quite subjective. My intention is to keep a journal tracking how easily various features are added. In order to be more even handed, I will build the software according to a staged plan, and will do each stage in both implementations, alternating which I do first. Other than trivial metrics (line counts, time taken etc), the main results will be my opinions and judgements: on such things as the relative effort required for each stage, and the my perceived quality of the results. Nevertheless, I'm quite interested in what conclusions, if any, I reach.

I'm primarily interested in a functional versus objected-oriented comparison. Hence, I probably should choose two implementations where this is the only difference. (two implementations in ocaml would be a possibility). However, another driver is that the experiment remain interesting long enough to actually achieve something! Hence, I plan to do an implementation in my two preferred languages, python and haskell. These two languages differ in many other aspects: dynamic versus static typing; interpreted versus compiled; etc.

Finally, specific languages are better suited to certain types of tasks. I've got a couple of ideas here, and don't want to select a task whose implementation is obvious from the the description/plan. I'm tempted by a GUI application using the wxWidgets framework, since it is supported in both languages.

another language for plotting, looks to be especially good for/focused on climate visualizations (as is to be expected being maintained by the national center for atmosperic research, one of their visualization and enabling technologies http://www.vets.ucar.edu/software/index.shtml). supports working with netCDF, HDF, Grib, and CCM History Tape data formats.
Has some nice features regarding variables, including call-implicit instantiation and undefinition of variables, although I can't see how these features per se help them in the language's ostensible analysis and visualization of data goals (as opposed to just being aesthetically pleasing features and generally helpful)

Well, its been really quiet around here, and I have been working on the design of my own programming language(like probably half the rest of the people here...), and so I figured I would bounce some of my ideas off people here and find out why they're wrong :)

The type system is mostly what I'm curious about opinions for. It starts with records or structures(however you want to look at). The programmer can make a type like so:

type complex {
	a as real;
	b as real;
}

Now, when it comes to functions, they determine type compatibility by a pattern matching mechanism. This pretty much means functions can be overloaded, and matching is on all arguments, which could be as simple as a type name, or it can merely look for a member of the record to match on, or any other number of patterns.

I'm not sure how creative this is, but a couple of my motiviations, I like pattern matching and I think type inferencing stuff is cool too, but for me, coming up with the entities I want to manipulate is part of how I write code and think of the design. So the idea of maybe "naming" the patterns, and calling that a type has appeal to me, and then overloading functions with different type signatures/patterns seems like a lot of what I want.

One other slightly oddball feature is that in an argument declaration, a function can delcare "with coercion", in which case if an argument doesn't match any pattern, a single parameter function is sought out that starts with the character '!' which denotes that it can be used for conversions between types. This may be a bad feature or hard to implement, but I like the idea of being able to selectively allow something like it(at the programmers request of course).

As to object oriented programming, I'm going to have lexical closures and hashes, which may not make the OO people happy, but it seems to get a lot of cases.

The rest of the language is a bit imperative feeling, but even the control constructs return values, and it has anonymous functions. For algebraic expressions, the language allows functions of two parameters to be called in an infix notation, and since function names are allowed to range over about anything you want, this makes it easy to do operator overloading(without making it a special case), but it also means that I don't really have precedence(although I'm still thinking about that), which also adds a little uniformity with the built-in types, since several of them will have some operators meant to be used in infix form.

Here's a couple of more examples:

type phasor {
	r as real;
	theta as real;
}

function * phasor:(a as phasor, b as phasor)
{
	return (phasor:[a.r * b.r, a.theta + b.theta]);
}

Now, a function that wanted complex numbers(but didn't care whether they were in polar or rectangular form might be declared like so:

function dosomething '[phasor, complex]:(a as '[phasor, complex], b as '[phasor, complex])
{
    ... do something ...
}

A function that wanted a structure with a specific member might go like this:

function getnext 'typevar:(a as 'typevar:[next as ref 'typevar])
{
	return (a.next);
}

Okay, bad example maybe(lists are a primitive type), but still. The quote is used to denote that the type is allowed to range over anything that matches the partial pattern to follow. In cases like this where it shows up multiple times, the same value must be substituted throughout. In fact, the use of the same "variable"(type or otherwise) even in different arguments in the pattern declaration requires the values match. I guess these are more like "logic" variables than anything.

I'm still working on syntax, especially for the pattern matching, but this is just to give you an idea of my current state of mind.

Any feedback on this is appreciated. This language is just me doing it for fun and the experience of designing a language. I'm using things on the edge of my understanding, but I'm also trying things that I think I would like to solve problems that bug me. So be harsh :).

Mark Pilgrim has written an excellent book on Python.
It is available on line and is in the book shops.

The section on introspection is likely to be of interest
to us.
http://diveintopython.org/power_of_introspection/index.html