Lambda the Ultimate

Q (a functional PL based on term rewriting) has been mentioned on LtU a few times before, so I thought I should point out that there is a new tutorial available, which is supposed to provide a quick and informal introduction to the language.

From the preface: "In a nutshell, Q is a kind of functional programming language with a syntax similar to Miranda and Haskell, but with general term rewriting instead of the lambda calculus as the underlying computational model. [...] Q has some fairly unique features, in particular its user-definable special forms and algebraic types with inheritance, which makes it a somewhat exotic but powerful member of the FP language zoo."

You can download the tutorial here (PDF): Q in a Nutshell

More information about Q can be found here: http://q-lang.sf.net/

Message deleted, see thread below for explanation.

I decided to leave the thread here, because I think the discussion may help orient new members.

The original poster is not banned, and is invited to repost a more appropriate message - per the suggestions below - if he so wishes.

-- Ehud

Registration for the 10th ICFP Programming Contest is now open.

You can register via the homepage of the contest:

http://www.icfpcontest.org/

-- The organisation team

I work for a vendor of an application for the management of trades. We would like to extend an application with a simple scripting language for batch processing. The idea being that someone non-technical could use a script to schedule processor intensive tasks, such as pricing a portfolio, to run over night. What we have in mind is something very simple just a few verbs and noun pairs, i.e.

import "fixing.dat"
price "portfolio a"

The script would then be run by a scheduler.

However, I vaguely remember a discussion on ltu about "ant" starting off like this with relatively simple objectives, but getting a bit bogged down because people inevitably used it for more complex scripting tasks. I think the designers of the language ended up saying they’d have been better off applying good language design principals up front. So my question is what sort of good language design principals should be applying to a litte scripting language like this? Or would it better to use an existing scripting language? Part of the application is written in caml so this would probably the scripting language of choice, but I’m a bit worried would be over kill.

Apparently Intellasys is alive and kicking out Forth-based CPUs, some of which have a rather Transputer like smell to them. I wonder what their VentureForth language is like? Apparently there are freebies to play with.

(I have zero to do with the company, I'm just curious about little languages and multi-core-ness.)

I know stack based languages are perhaps not always considered the height of PLT (interesting to read 'I remain adamant that local variables are not only useless, they are harmful'), but maybe there is a time and a place even for Forth?

So we all know its possible to write a Scheme interpreter in Haskell.

Now how about writing a Haskell interpreter in Scheme, are there technical hurdles that prevent Scheme from hosting Haskell?

[this is perhaps mostly a social/marketing thought, please let me know if it is too far afield from LtU policies. I'm not trying to start a flame war, i'm only trying to study history and extract some lessons for it which might be useful to other language advocates.]

(I care about "success" of a language in the sense that a larger community might bring improvements to that language's ecosystem. Even just having the core system exercised by more people in more different ways is a benefit, for shaking out bugs.)

I think Java jumped the shark a long time ago. But people are bought into it enough that it keeps on chugging, even though it has clearly lost its "simple" origins. I think a similar thing happened with C to C++ because there were folks who were into the (relative) simplicity of C, and then moved along into C++ (just like people moved along into Java 1.4, .5, ... with all the complexity and incompatibilities introduced therein).

So I think one way (of many possibilities) to have a language "succeed" is to do a hard sell on the fact that it is simple vs. the other main-stream languages people use, and that simple is obviously better. Once you have people on board, then you can (and will be forced to by those same people, most likely) change it to become a more convoluted mess with not too many people jumping ship as a result; they're too bought in.

Is this good? I certainly think Java was useful in many ways, but I also certainly have a huge distain for how it has changed and become kind of insane - it seems to be heading towards the half-baked buggy implementation of CL event horizon.

So I'd argue that a refined approach would be to have your langauge:

1. somehow designed to be revisable. Claims that you won't break compatibility either need to be backed up with real structure to support that, or you need to just not make the claim. Java kinda falls short there, methinks.
2. "simple" in a really powerful PLT sense, as well as a "can i teach it to others" sense. Oddly, the folks who make Java knew full-well of real simplicity-with-power, but avoided it, presumably as another layer of pragmatism (with the obvious resulting success).

So perhaps the real question I have in mind is: how to make something simple in the FP sense rather than in the imperative sense, and yet have it be be successful? (I believe Sun spent a lot on marketing Java, as an aside.)

Per some old LtU discussion and other implementations, there's interest in having some kind of side-band communication channel. The last post of the mentioned old LtU discussion asks: couldn't one just use an abstract data type? If the answer is "yes, that's a fine idea - but the syntax would get annoying because you would have to be creating all these containers to pass into function calls all the time, and then use getter methods inside the functions" then might an applications of macros, or implicit conversions, be a way to solve that usability issue?

It seems similar to just saying that all functions take optional arguments, but perhaps the two approaches have different consequences when it comes to typing?

(As you can probably tell, I haven't thought this through much, or hacked up any test code, so this line of thinking's value is perhaps fast approaching zero.)

First, many thanks to LtU creator(s)/contributors, I have lurked profitably for a few years now. LtU readers are likely aware of Church's initial attempt to use the lambda calculus as a foundation for mathematics, and Curry's (and his students') subsequent attempts. But perhaps readers are unaware of this paper by Barendregt whose abstract contains the following:

These papers fulfil the program of Church and Curry to base logic on a consistent system of lambda-terms or combinators. Hitherto this program had failed because systems of ICL were either too weak (to provide a sound interpretation) or too strong (sometimes even inconsistent).

While the above announcement is unlikely to cause celebration in the streets, has it had any impact on the programming language or related math communities? I'm curious about the seeming lack of fanfare re the result (it was published in 98) and also about any existing or potential applications the result may have. I look forward to LtU experts to enlighten me (and likely many other interested LtU readers).

With the latest release of the Cat language inference of equirecursive function types (in Cat they are called "self" types) is now implemented. This means that in theory (this is not yet proven unfortunately) all valid Cat programs can be inferred. I was wondering what other languages with non-trivial type systems (e.g. they are able to discriminate higher order functions and different arities of functions) also have this property?