Lambda the Ultimate

There are several papers with LtU in their titles. The classic ones are the inspiration for this site's name. This paper is about applying these same ideas to scripting.

Ah! I didn't know about those others, I think, but for some reason Guy Steele popped into my head when I saw the title. Maybe it is just the association with MIT.

This paper is much more recent, and comes from the author of scsh.

A final note on the power of syntactic extension: It seems curious in the mid­nineties to be using Scheme as a serious tool for systems programming. The current standard lacks a module system, static type­checking, exceptions, and record types---it would appear that time has passed the language by. Scheme's sole remaining virtue distin­ guishing it from more modern languages, such as ML [5], is its unusually sophisticated macro system. But it is the syntactic extensibility provided by this macro system that provided us the crucial mechanism we needed to embed our little languages within Scheme. Designers of new programming languages would do well to note the power and utility of this mechanism.

But as of 2001 there are several alternative implementations of "modules, static type checking, exceptions, and record types" available in *non-standard* Scheme or what a recent comp.lang.scheme posting "a crude map of Scheme" called "Common Scheme" (CS) :

http://groups.google.com/groups?threadm=trh6s6tgn09n9d%40corp.supernews.com&prev=/groups%3Fq%3Dcomp.lang.scheme

Through a conservative *add-feature-only-by-consensus* standard Scheme is gradually converging to a stable core (called "Perfect Scheme" (PS) in the paper). In addition to a *uniform s-expression syntax*, this core contains the following semantics:

1. "A side-effectless subset of the language...... isomorphic to an applicative order lambda-calculus-plus- call-with-current-continuation over some given set of primitive types and procedures."

2. A superset with side effects that allows "the values of variables in scope to be modified. The timing of these side effects is determined by the rules of applicative order evaluation and continuations created with call/cc."

I think it's hard to get a handle on what sort of functionality is available in the larger "Common Scheme" and how portable it is or how portable it could be made through refactoring.

There are several code repositories , but no *map through these repositories*. That's why I'm currently taking the "Perl Cookbook Index" and mapping the various practical tasks to "standard scheme" and "non-standard Scheme" such as SRFI's (1 - lists, 13 - strings , 19 - dates and times) and SLIB with code snippets to show very basic functionality.

So much effort has been put into Scheme by so many talented people for so many years that the Scheme code base really is a "knowledge base" (a phrase used by some marketing types I know to sell their consulting services).....an ideal base for re-use.

I've heard that most popular languages tend to change every 8 (?) years....so wouldn't it better to choose a language with a little more continuity for a knowledge base? (...a code kb for scripting as well as for programming language theory)....

what about pleac?

>what about pleac?

PLEAC is great! I'm adding deep links into it from the "annotated code bibliography of Scheme" that I'm working on. The goal of a bibliography is to provide a map and only a very basic description of functionality.

I'm trying to document code that you can use from over a broad range of implementations and platforms. So I'm relying on many sources:

R5RS, SRFI's + PLEAC Cookbook Examples, SLIB (+Pregexp+Schelog), Scsh (awk + pipes), EOPL, Dybvig's "The Scheme Programming Language", The Scheme FAQ, SICP, Oleg's XML processors, LAML/HTML, BRL (Beautiful Report Language), "Unix Power Tools" (also rewritten in Perl) for useful scripting tools to implement, and of course comp.lang.scheme.

I'm basically using the Perl TOC, but I've modified it to highlight Scheme's differences from Perl...and also because I want to avoid any issues of intellectual property theft...if I base an index on the *ideas* implicit in O'Reilly's index no one can accuse me of plagiarism or theft...

I'm not clear on IP as it pertains to code re-use. On the one hand there is are Henry Spencer's classic essays on code stealing:

http://www.cs.umd.edu/users/cml/cstyle/

And on the other there is this recent Slashdot discussion:

http://slashdot.org/bsd/01/09/24/1432223.shtml

It seems that licenses are often written such a way that you can't just select some function , modify it a little , attribute the authorship of the source properly, and then re-use it as you see fit. Often licenses seem to make code less open and hinder re-use.

It seems that there is a fundamental irreconcilable tension between the virtues of code re-use, ownership and theft of the intellectual property inherent in code, attribution of authorship, evolution of standard libraries and standard ways of doing things, intellectual/academic integrity and plagiarism, and refactoring/transforming code into something completely different and assimilating it into your own code base/intellectual property.

Any guidance as to when refactoring can be done and when or when not (some people might want to be associated with the potential mess you create from their code) to attribute authorship of source would be much appreciated.