Lambda the Ultimate

I've just finished a paper submission on live programming languages and how live programming is realized in SuperGlue. Any feedback is appreciated. Here is the link:

http://lamp.epfl.ch/~mcdirmid/mcdirmid07live.pdf

Because the paper has inlined movies, it is best read in a later version of AcroRead with QuickTime installed.

Abstract:

A dynamic language improves programmer productivity through flexible typing, a focus on high-level programming, and by streamlining the edit-compile-debug cycle. Live languages go beyond dynamic languages with more programmer-centric features. A live language supports live programming that provides programmers with responsive and continuous feedback about how their edits affect program execution. A live language is also based on declarative programming constructs such as rules or data-flow connections so that programmers can write less code. A live language should also provide programmers with responsive semantic feedback to enable time-saving services such as code completion. This paper describes the design a textual live language known as SuperGlue. SuperGlue is based on reactive values known as signals that are supported with declarative data-flow connections and dynamic inheritance. Through signals and dynamic inheritance, SuperGlue supports live programming, declarative programming, and responsive semantic feedback. We demonstrate live programming in SuperGlue with a working prototype.

Call for Papers

Sixth International Conference on
Generative Programming and Component Engineering (GPCE'07)

October 1-3, 2007
Salzburg, Austria
(co-located with ESWEEK'07)

http://www.gpce.org/07

Important Dates:

* Submission of abstracts: April 17, 2007
* Submission: April 20, 2007
* Notification: June 10, 2007

* Tutorial and workshop proposals: March 16, 2007
* Tutorial and workshop notification: April 9, 2007

Scope

Generative and component approaches are revolutionizing software
development similar to how automation and components revolutionized
manufacturing. Generative Programming (developing programs that
synthesize other programs), Component Engineering (raising the level
of modularization and analysis in application design), and
Domain-Specific Languages (elevating program specifications to compact
domain-specific notations that are easier to write, maintain, and
analyze) are key technologies for automating program development.

GPCE provides a venue for researchers and practitioners interested in
foundational techniques for enhancing the productivity, quality, and
time-to-market in software development that stems from deploying
standard componentry and automating program generation. In addition to
exploring cutting-edge techniques for developing generative and
component-based software, our goal is to foster further
cross-fertilization between the software engineering research
community and the programming languages community. As GPCE is
co-located with ESWEEK this year, we also especially encourage papers
from the embedded systems community.

Submissions

10 pages in SIGPLAN proceedings style (sigplanconf.cls) reporting
research results and/or experience related to the topics above (PC
chair can advise on appropriateness). We particularly encourage
original high-quality reports on applying GPCE technologies to
real-world problems, relating ideas and concepts from several topics,
or bridging the gap between theory and practice.

Please note that in contrast to last year, GPCE 2007 is not using a
double-blind reviewing process.

Topics

GPCE seeks contributions in software engineering and in programming
languages related (but not limited) to:

* Generative programming
o Reuse, meta-programming, partial evaluation, multi-stage and
multi-level languages, and step-wise refinement
o Semantics, type systems, symbolic computation, linking and
explicit substitution, in-lining and macros, templates, and
program transformation
o Runtime code generation, compilation, active libraries,
synthesis from specifications, development methods, generation of
non-code artifacts, formal methods, and reflection
* Generative techniques for
o Product-line architectures
o Distributed, real-time and embedded systems
o Model-driven development and architecture
o Resource bounded/safety critical systems.
* Component-based software engineering
o Reuse, distributed platforms and middleware, distributed
systems, evolution, patterns, development methods, deployment
and configuration techniques, and formal methods
* Integration of generative and component-based approaches
* Domain engineering and domain analysis
o Domain-specific languages (DSLs) including visual and UML-based
DSLs
* Separation of concerns
o Aspect-oriented and feature-oriented programming,
o Intentional programming and multi-dimensional separation
of concerns
* Industrial applications
* Applications in embedded systems

Reports on applications of these techniques to real-world problems are
especially encouraged, as are submissions that relate ideas and concepts
from several of these topics, or bridge the gap between theory and
practice. The program chair is happy to advise on the appropriateness of a
particular subject.

Submissions must adhere to SIGPLAN's republication policy. Please contact
the program chair if you have any questions about how this policy applies
to your paper (gpce07 at diku.dk).

General Chair

* Charles Consel (LABRI/INRIA, Bordeaux)

Program Committee

Program Chair:

* Julia Lawall (DIKU, University of Copenhagen)

Program Committee Members:

* Edwin Brady (University of St Andrews, UK)
* Johan Brichau (UniversitÈ Catholique de Louvain, Belgium)
* Rastislav Bodik (UC Berkeley, USA)
* Jacques Carette (McMaster University, Canada)
* Albert Cheng (University of Houston, USA)
* Remi Douence (Ecole des Mines de Nantes-Inria, Lina, France)
* Lidia Fuentes (University of M·laga, Spain)
* Ian Gorton (Pacific Northwest National Lab)
* Jean-Marc Jezequel (IRISA (INRIA & Univ. Rennes 1), France)
* Kyo Kang (Pohang University of Science and Technology, Korea)
* Siau Cheng Khoo (National University of Singapore, Singapore)
* Paul Kelly (Imperial College London, UK)
* Anne-Francoise Le Meur (University of Lille 1, France)
* Christian Lengauer (University of Passau, Germany)
* Sandeep Neema (Vanderbilt University, USA)
* Scott Owens (University of Cambridge, UK)
* Jens Palsberg (UCLA, USA)
* Renaud Pawlak (Rensselaer Polytechnic Institute, USA)
* Zoltan Porkolab (Eotvos Lorand University, Hungary)
* Robby (Kansas State University, USA)
* Peter Sestoft (IT University of Copenhagen, Denmark)
* Jeremy Siek (University of Colorado at Boulder, USA)
* Tony Sloane (Macquarie University, Australia)
* Kevin J. Sullivan (University of Virginia, USA)
* Peri Tarr (IBM Thomas J. Watson Research Center, USA)

I am interested in implementing a program analysis, where the operations applied to an instance of an abstract data type (e.g. a list) determine the implementation's choice of data structure (e.g. array vs linked list).

For example if "insert" or "delete" is used, then a linked list might be chosen, or if "nth" operation (accessing the nth item) is applied then an array might be used.

I am unfamiliar with such analyses. Can anyone recommend any papers or related work?

John Backus, inventor of FORTRAN, the BNF, and winner of the 1977 Turing Award, has passed away. New York Times has an obituary. I'm sure the more eloquent members of LtU will have much to say about him, so I'll just point out that his Turing Award lecture is an absolute classic, and seems to be more relevant than ever. My condolences to the Backus family and friends.

I would like to solicit some opinions from the community on a language concept I've been working on. I'm not sure what category to describe it as. The language is called 2e -- two e's, as in expression evaluator -- and for the most part, that is exactly what it does, evaluate an expression.

Other than the syntax used for defining functions, the whole program is one large single expression, composed of operators and operands. What looks like a statement delimiter (the ";" operator) is actually similar to the comma operator in C; it is a "join", where the expression on both sides of the operator are evaluated, and the left side result is thrown away and the right hand expression result is returned. This is why I assert that the whole program (minus function definitions) is one single expression.

Conditionals are handled via a C style inline-conditional and "while" loops are done with an iterative variant of the inline-conditional syntax, so that complex code segments can be part of a larger expression. There are no other flow control constructs (other than function calls).

On the surface, it looks like a procedural language, but it doesn't execute a sequence of steps, instead it evaluates one expression. Also, functions are recursive, and you can pass functions as arguments to other functions. These two items combined make it almost fit the requirements for a functional language. However, it includes a standard assignment operator that is used to change state of variables (the assignment operator can logically appear anywhere in an expression, just like C), so that seems to exclude it from the functional category (although there is no reason you can't program in a functional style).

So my main question is, what type of language is this, functional or procedural? Or some other type that I haven't studied? My second question is if anyone would find this language useful for any projects or research purposes. The main appeals of the language is an algebraically "clean" syntax and a rather simple easy to understand interpreter. The parser was done by hand using classical algorithms, instead of using lexx / yacc, and the interpreter is provided in the form of a library that can be imbedded into other applications. I've got some clean up to do on the code to make it usable for study (there's been some performance modifications added that end up making it harder to read; I've got plans to fix that), and more documentation is needed. I've seen mention on this site of plans that others have for creating experimental languages, feel free to grab any techniques or code that you want.

The site for 2e is lang2e.sourceforge.net, where there is some documentation and code samples, but I can post some specifics that highlight various language aspects if that helps.

Thanks.

Hi guys, I am a freshman student in Kenya. After I stumbled on MIT's ocw website, I got interested in Scheme and after a few while on this LtU site, I felt like starting with DrScheme is the best way since its tailoured to the biginners. I am very new in Programming and we just don't have great teachers who have command of the subject here in Kenya.
Well after installing and running DrScheme, I encountered a problem which I will be very greatful to anyone of you who can help.
I difined this procedure: (define (area-of-disk r)
(* 3.14 (* r r)))
which worked when I ran like this (area-of-disk 5)

then I defined this: (define (area-of-ring outer inner)
(- (area-of-disk outer)
(area-of-disk inner)))
However upon running this procedure I got this message; area-of-disk: name is not defined, not an argument, and not a primitive name.
and this on the tracing window: No tracing results are available, yet. (Make sure that your language supports tracing and that tracing is enabled.)
Can anyone help?

Remarkable little language. This thread on embedded languages got me looking, and I came across this paper:

Embedded microcontrollers are becoming increasingly prolific, serving as the primary or auxiliary processor in products and research systems from microwaves to sensor networks. Microcontrollers represent perhaps the most severely resource-constrained embedded processors, often with as little as a few bytes of memory and a few kilobytes of code space. Language and compiler technology has so far been unable to bring the benefits of modern object-oriented languages to such processors. In this paper, I will present the design and implementation of Virgil, a lightweight object-oriented language designed with careful consideration for resource-limited domains. Virgil explicitly separates initialization time from runtime, allowing an application to build complex data structures during compilation and then run directly on the bare hardware without a virtual machine or any language runtime. This separation allows the entire program heap to be available at compile time and enables three new data-sensitive optimizations: reachable members analysis, reference compression, and ROM-ization. Experimental results demonstrate that Virgil is well suited for writing microcontroller programs, with five demonstrative applications fitting in less than 256 bytes of RAM with fewer than 50 bytes of metadata. Further results show that the optimizations presented in this paper reduced code size between 20% and 80% and RAM size by as much as 75%.

Looks very promising. It's notion of "initialization-time" is worthy of further thought. See also the Virgil homepage, where you can download preliminary source releases. The features page list a number of interesting tidbits as well: Virgil will soon support tail call optimization! In particular, see what's coming in Virgil II:

* Parametric types
* Module system
* Tuples
* Generalized Algebraic Types
* Integration with non-Virgil code

March 24th 2007, 6PM

Formal meeting- Intro to Haskell, plus some PARSEC wizardry. Adam Turoff, our resident Haskell guru, will be giving a presentation on said language. If you live near DC and have an interest in Haskell, this'll be your rare opportunity to get exposed to the laziest of functional languages! Plus, we'll have a small presentation on some fun plt-scheme code as an opening act (and, of course, we'll go out for beer as a closing act)

http://www.lisperati.com/fringedc.html

Who would be willing to suggest a syntax to go with the semantics I allude to here?

Since the language I am hinting at here (thinking to flesh a definition out, once someone else has drafted a syntax) does not try for referential transparency, and therefore retains sort of an imperative flavor, I assign the langauge the working title, Imperatrix Mundi.  If someone wants to suggest another name, maybe I'd favor adopting such suggested name instead.

I think it could be interesting (for me with help and suggestions from you readers) to flesh out a language of this sort, even though for some years I have been thinking a referentially transparent (RT) language would be the ultimate way to go.  I suggest Imperatrix Mundi as an intermediate step in a possible evolution toward an eventual RT language for general computer programming purposes that don't require blindingly fast performance nor specialization to an unusual application area.

For talking about the message passing in this language, I borrow the terms "bird" and "nest" from ToonTalk, but with some semantic differences, chief among them being that whereas in ToonTalk, bird/nest channels guarantee that the messages read off the nest come in the same order as they were handed to the bird, in this language I say that the order of the messages is not guaranteed to be preserved.

This language does not try for referential transparency.  However, it must meet a weaker requirement, that the values (or references or meanings) denoted by the occurrences of a given identifier in a given context could be exchanged with each other without changing the semantics of the segment of code occupying the context.  This should happen because of don't-care nondeterminism.  For example, suppose a <- b is a command meaning to send a message denoted by b via a bird denoted by a, and the code says a <- b; a <- c.  What this would mean is that the message stream sent along 'a' is some random merge of a1 with a2; a1 <- b; a2 <- c.  The bird, 'a', would get the messages b and c, and whoever is reading the nest at the other end could get b before c or c before b.

A segment of code consists of a bag of commands (or statements if you prefer to think of them that way); the order of the commands cannot affect the meaning of the segment.

List of semantic constructs that need syntactic expression:

• The usual complement of literals that a language would have.
  
• Manifest a bird/nest pair out of thin air.
• Compose a message from a word to function as a verb, and from a list of keyword/argument pairs.  For example, {bletch foo: 2; bar: 3;} could mean a message with verb bletch and keywords foo and bar associated to values 2 and 3 respectively.  {bletch bar: 3; foo: 2;} would be the same message, because the order of the keywords does not matter.  {bletch bar: 2; foo: 3;} would be a different message, because the association of the arguments to their respective keywords does matter.
• Send a message via a bird, and optionally capture a result (which would be a nest).  Failing to capture the result should change the semantics of the message in a way detectible by the process that eventually receives the message from the nest associated to the bird (argue against this distinction if you think it's a bad idea).
  
• Send a message to any value, and capture a result.  For example 2 + 2 could be interpreted as a message {+ : 2} (where the naked colon indicates an empty keyword) being sent to the value 2, and the result should be 4.
  
• Associate a nest to a process that is an instance of a class, so that the process will interpret the stream of messages arriving on the nest.
• Instantiate a process from a class by sending the class a message and capturing the resulting new process.
• Define a class with methods.  Each method should have a header that can match messages based on their verbs and keywords.  Maybe it should be possible to make some keywords optional in the sense that the method would be invoked even if the optional keywords are not supplied in the message.  The class definition should also provide for message patterns for creating an instance from the class (class methods).  There may need to be a definition of parameters that would be given values in the instances (instance variables).
  
• Refer to a value to be taken from a nest.
• Compose a list of values.
• Quote functions for passing to map functions, etc.
• Quote code for conditional execution.
• Disappear the current process, but capture the residue of the nest it has been interpreting (e. g., to pass the residual nest as an argument in some message).
  

I have had many helpful comments and reviews on my recent paper about Cat, but the biggest criticism seems to be that I don't motivate the paper very well. This is perhaps the hardest thing to do!

The contribution of the paper is that it is the first time (AFAIK) that anyone has presented a type system for a pure functional stack-based language.

To understand the implications, consider if we were to introduce the ability to use primitive operations as first class values in MSIL or JVML in a type-safe manner.

So my question to the community is, is that sufficient motivation and should I emphasize these points in the paper?

I have even considered rewriting the name and abstract as follows:

Typing a Functional Stack Based Language

Stack based langauges, such as the JVML and MSIL, are very popular as VM languages, but are mostly imperative in nature; they lack the ability to treat operations as first class values.

This paper presents a formal typing discipline for a purely functional stack-based language.

Perhaps this kind of paper would be more well received by the community?

Thanks again for everyone's help!