Lambda the Ultimate

We're currently looking at something in BitC, and I'm wondering if there may be a simpler way. I'm concerned that we may have gotten stuck in a "we know how to do types now, so everything is a typing problem" sort of rut.

Background

In BitC, we have both vectors and arrays. The size of an array is part of its type, but we presently have no way to abstract over that size. This means that we cannot currently build a type class for something like (length expr) and instantiate a version of length that operates on arbitrary arrays. Perhaps more importantly, it means that we cannot express a low-level read function that puts data into an existing array in-place, because we cannot abstract over different possible array sizes.

After some head scratching, we concluded that there is no fundamental problem with extending typeclass-style constraints and instantiation to incorporate instantiation over literals. The underlying observation is that every literal can be considered to be a member of some singleton type, and you can then abstract over that type in the usual way. So far so good.

But as we dug into it a bit, we somehow moved from "abstraction over literals" to "abstraction over literal-associated singleton types". For example, our old specification of the array type constructor was:

(array T e)

where e must be a literal of type word. The new specification seems to have become:

(array T T.len)

where "T.len" is required to be a singleton literal type. In this case, that would be a constrained type of the form 'a\(Literal 'a word). So an abstracted "read" function would now be something like:

read: (forall ((Literal 'len Word))
        (fn Stream (by-ref (mutable (array byte 'len))) 'len -> Word)

meaning that read accepts a stream, an array by reference, and a length guaranteed to match the array length, and returns the number of characters read.

All well and good, but from a usability perspective we still want to be able to write something simple like:

(array char 2)

For the moment, there are only a very few syntactic contexts where this would make sense, and Swaroop has proposed that we accept (interchangebly) either a singleton literal type or a value of singleton literal type and "lift" the value to its type in these syntactic contexts. And I think all of that will work.

The Question

While all of this ought to work, it feels like we are going around Robin Hood's barn here. Are there other languages that have dealt with this, and if so, what should we look at to understand better what has previously been done?

[corrected link, apologies] Liquid Metal, Lime:

We introduce Lime, a new Object-Oriented language that can be compiled for the JVM or into a synthesizable hardware description language. Lime extends Java with features that provide a way to carry OO concepts into efficient hardware. We detail an end-to-end system from the language down to hardware synthesis and demonstrate a Lime program running on both a conventional processor and in an FPGA.

Hello,
I was wondering if anyone knew of good explanations of HM-type inference works, with an emphasis on implementation. I've found some papers using citeseer, but all of them seem to assume that the reader has a PhD in computer science and go WAY over my head (I only program as a hobby). I did some google'ing and found The Essentials of Programming Languages, but if possible, I want to avoid having to pay ~$50 just to learn one thing. After reading SICP online and after learning Haskell, I decided to write a toy Lisp interpreter with type inference, but the implementation details for the type inference escape me. What I liked about SICP was the emphasis on implementation and how they provided source code for everything. Is there a similar (freely available?) PDF that explains type inference? I apologize in advance if I accidentally posted this to the wrong forum, or if this has already been answered many times. I perused the archive a little, but I didn't find any similar requests. Although I read LtU, this is the first time I've ever posted anything.
Kind regards,
Kevin

We suggest to use the locality concept as a general form of component, that can be used, at the same time, as a unit of modularity, of isolation, and of mobility. Specifically, we introduce in this paper Oz/K, a kernel programming language, that adds to the Oz computation model a notion of locality borrowed from the Kell calculus. We present an operational semantics for the language, and several examples to illustrate how Oz/K supports open distributed programming.

Oz/K: A kernel language for component-based open programming

I wrote up a small blurb about C# attributes used prominently for reflection, and how I think they can be replaced with interfaces without losing any of the declarative benefits, or requiring special compiler handling for metadata. I argue that parameterizing objects with interfaces is ultimately safer than using attributes, given the static typing benefits.

Hi all,

I'm new to this forum, but it seemed like there are a lotta smart people here, so I wanted to throw an idea out there and see what the 1337 hax0rz think about it. (btw, I'm also not a programming languages guy, so please correct me if I'm wrong)

The Problem:
So there are a lot of programming languages out there, but pretty much all of them are about programming a process, rather than programming an algorithm. Consider the following program:


#include "myCards.h"

int main(void)
{
myCards cards;
cards.shuffle();
cards.deal();
return 0;
}


This is usually a clear way of writing a program, any programmer that looks at the code can deduce the algorithm, namely, create the cards, shuffle them, then deal them. However, this C++ code is actually programming a very specific process and not necessarily the algorithm that it seems to imply. In actuality, you know very little about this code. All we can deduce from this code is that an object was created, and two of its member functions were called in succession. It could be the code that sets up and detonates a bomb, or the code to break eggs and fry them sunny-side up. It depends completely on how myCards.h is defined, and the algorithmic information is buried within the complex relationships.

It is no wonder that understanding someone else's code can be as time-consuming as rewriting the code from scratch. Code without comments is tantamount to writing unusable code.

The Idea
When you are playing cards, you will use this algorithm. Get the cards, shuffle them, then deal the cards. The algorithm is very consistent and reusable - you do the same thing whether you're getting ready to play blackjack, poker, or even go-fish even though those games are very different. So the idea is to create a programming language where you can program the algorithm, and capture everything that is important to the algorithm, separating it from what is process specific.

So looking back on the algorithm -- 1.Get the cards, 2. Shuffle them, 3. Deal the cards. What is different between this and the C++ code before is that here, we don't care how to do it, just get it done. It doesn't matter if I riffled the cards, or pulled some out the middle and put them on top, just as long as they get randomized -- which is what I meant by shuffling them.

The algorithmic way of writing this code would be -- 1.get to the state where i have the cards 2. get to the state where the cards are shuffled 3. get to the state where the cards are dealt. The difference is that this is goal-based -- get there, I don't care how you do it, rather than process-based -- do these specific things.

The Language
The language will be a goal-based language, where each function contains the goal of the function -- which state it will be in after it finishes, and will guarantee that it will get there if the initial conditions are met. Each function will contain a sequence of subgoals to get it from the initial state to the goal state. During compilation/run-time, a STRIPS-like calculation will be done to plan which specific functions to call to create an AST corresponding to the tree of goals and subgoals where each function is a node.

Correctness can be proven since each function is supposed to go from its initial state to goal state, if it doesn't, the the function is incorrect and the run-time can isolate more bugs.

Conclusion
The difficulty in reusing old code is the lack of pre/post information about functions. So a language that requires that information in the form of initial conditions / goal state will allow for greatly reusable code, that will be able to self modify for various purposes at run-time.

K, so there's more to it if people are interested... but right now, it's still in the planning stages, and could use some help from some experts. A simple proof-of-concept version was written in python. I'm trying to work out a version 2 that will compile to parrrot vm. Any ideas/comments/people that are interested?

In Turner's paper "Total Functional Programming", as seen on LtU here, on page 16 it says that in a total functional language it's impossible to write an interpreter for that language. I've seen this statement in other papers too. None of them I've seen have shown or made reference to a proof. Some mumble about the halting problem. Can anyone provide a link to a paper with a proof of this, or sketch a proof themselves?

It seems to me that if one were to have a language that required the programmer to give correct termination proofs of all functions, then if one could prove the termination of an interpreter for that language, one could write the interpreter in that language. That must mean that one couldn't prove the termination of an interpreter for a total functional language. I'm curious to know why.

I am trying to create a very efficient implentation of John Tromp's binary lambda calculus so that it can be used as a toy language at golf.shinh.org. It is the pure untyped lambda calculus with only 3 types of operations, lambda abstraction, variable (argument) lookup, and apply.

I figure the easiest way to do this is just to convert it into some other language. I only have basic knowledge of some functional languages, I would not mind learning more, but only if it is actually possible to convert the untyped lambda calculus into it.

Haskell is lazy but since it is not dynamically typed it runs into problems with "cannot construct the infinite type"

Ocaml might be able to get around this problem with the -rectypes but lazyness must be done manually with lazy and Lazy.force. Even if it could work, Ocaml's lazy functions might not be very efficient at all.

Another option is to convert into the spineless tagless gmachine notation that Haskell uses. Alot of the Haskell optimizations are done before this step.

Can any of these problems be overcome without too much cost? Or any other good languages out there that could? Any advice is appreciated, but you do not need to explain the whole thing in detail, a pointer to the right direction will be of enough help.

CALL FOR SUBMISSIONS

INTERNATIONAL LISP CONFERENCE 2009

Lisp: The Next 50 Years

http://www.international-lisp-conference.org

Massachusetts Institute of Technology
Cambridge, Massachusetts, USA
March 22-25, 2009

Sponsored by the Association of Lisp Users

General Information:

The Association of Lisp Users is pleased to announce the 2009
International Lisp Conference will be held in Cambridge,
Massachusetts, at the Massachusetts Institute of Technology, Sunday
through Wednesday, March 22-25, 2009. The emphasis will be on present
and future applications of technologies that have been or might soon
be associated with the Lisp programming language and/or related
languages and software.

We encourage submissions in diverse areas, including but not limited
to: language design and implementation, memory management, software
engineering, mathematical and scientific computing, artificial
intelligence, database processing and data mining, business
intelligence, performance analysis, parallel processing, quantum
computing, bioinformatics, telecommunications and networking, the
semantic web, music, domain-specific languages, and entertainment
technologies. ILC09 is not limited to topics discussed in previous
symposia. Authors concerned about the appropriateness of a topic may
communicate by electronic mail with the program chair prior to
submission.

Explaining a known idea in a new way may make as strong a contribution
as inventing a new one. We encourage the submission of "pearls":
elegant essays that illustrate an idea, for example by developing a
short program. (A pearl should be concise, instructive,
self-contained, and entertaining. Your pearl is likely to be rejected
if your readers get bored, if the material gets too complicated, if
too much specialized knowledge is needed, or if the writing is
inelegant. The key to writing a good pearl is polishing.)

There is no formal separation of categories and no need to explicitly
label pearls as such: all papers, whether pearl or otherwise, will be
judged on a combination of correctness, significance, novelty,
clarity, and elegance. Each paper should explain its contributions in
both general and technical terms, identifying what has been
accomplished, explaining why it is significant, and comparing it with
previous work. Authors should strive to make their papers
understandable to a broad audience.

Alongside our usual four-day program of tutorials, prominent invited
speakers, and excellent technical sessions, this year we will also
consider demonstration sessions.

The official language of the conference is English. Further details
are available at the conference web site:
http://www.international-lisp-conference.org

Technical Program:

Original submissions in all areas related to the conference themes are
invited for the following categories.

Papers: Technical papers of up to 15 pages that describe original
results ("research papers") or explain known ideas in new ways
("pearls").

Demonstrations: Abstracts of up to 4 pages for demonstrations of
tools, libraries, and applications.

Tutorials: Abstracts of up to 4 pages for in-depth presentations about
topics of special interest for at least 90 minutes and up to 180
minutes.

Panel discussions: Abstracts of up to 4 pages for discussions about
current themes. Panel discussion proposals must mention panel members
who are willing to partake in a discussion.

Lightning talks: Abstracts of up to one page for talks to last
for no more than 5 minutes.

Important Dates:

Please send contributions before the submission deadline to the
program committee (ilc09-program-committee at alu.org).

Deadline for submissions: December 9, 2009
Notification of acceptance or rejection: January 9, 2009
Deadline for final paper submissions: February 9, 2009

Organizing Committee:

Conference Chair: Daniel Weinreb (ITA Software)
General correspondence: ilc09-organizing-committee at alu.org
Program Chair: Guy L. Steele Jr. (Sun Microsystems Laboratories)
Contact: ilc09-program-committee at alu.org
Local chair: Howard Shrobe (MIT)

Technical Program Committee: to be announced soon

Does anyone know of a project roughly similar to the Programming Language Shootout, but for comparing web application frameworks? I'm especially interested in seeing small-to-medium-sized web applications implemented with different tools, with a focus on seeing how each tool enables component reuse.

As I announced in a recent post, I'm working on a DSL for web application programming, and I'm looking for ways to quantify the advantages it provides over the competition. So far, I've been unable to find even a single comparison of the proper kind on the web.