Lambda the Ultimate

L is a "dynamically-typed, block-structured, purely-functional, strict language" which takes the following from Smalltalk:

* There is only one kind of value: the object.
* There is only one kind of operation: the message send.
* The grammar is small: few expression/parse types.
* The system is self-contained; everything is an object, including source code.
* The system is dynamic; objects, including source code, are editable at runtime.

adds the following:

# Modularity.
# Security.... A module should only have access to what it needs to do its job and no more.
# Thread Safety.
# Distributed Computing.
# Virtual Machine

found at E's what's new page

The design space of generic programming languages is largely unexplored, partly due to the time and effort required to implement such a language. In this paper we show how to write flexible prototype implementations of two existing generic programming languages, PolyP and Generic Haskell, using Template Haskell

The original template haskell paper showed how to wrtie printf and zipN, which are (or used to be) cited as dependent type examples -- what other haskell
extensions can we write without compiler hacking?

extended metaphor relating real world design with software design; quote. "If there is a gap between designing and making, that gap is nonexistent in software."

From the about page:

CiteULike is a free service to help academics to share, store, and organise the academic papers they are reading. When you see a paper on the web that interests you, you can click one button and have it added to your personal library. CiteULike automatically extracts the citation details, so there's no need to type them in yourself. It all works from within your web browser. There's no need to install any special software.

There's an option to create groups of same-interests likers, maybe we could create a Lambda the Ultimate group to share interesting papers. Most of the Lambda papers are already referenced here.

I was looking at the SICP lectures the other day, and in the part on streams he talks about implementing a system with lazy evaluation, then gives as a example of the "dificulty" in combining streams a system that has 2 users entering data, each with their own stream, and something which has to choose which stream to take the next event from, while combining them into one stream. aparently the "problem" is that they try alternating between user streams, but one of the users may not enter anything for a while, causing the system to wait for him to enter something before continuing.

It would seem to me that the problem here is not in the streams, but in the interface to the keyboard. The keyboard sends events. that means a charactor at a specific moment in time. of course normaly the time gets thrown out, but the event itself should be timestamped as the imput stream. This was even mentioned as a question, which he didn't adress very well.

The next part is what should the keyboard stream return while "waiting" for a keystroke? It should return a "constraint object", which contains not a specifc value, but the constraint that the next data objects timestamp is greater then {current moment}. Then when the system goes to compile the streams, it can compile in timestamp order, and whenever it gets one item from one stream, it can just check the other stream to see if its next objects timestamp is greater then the curent object. Then add the first if it is, or add it if it is not.

To start the process there would have to be a "current time" stream which the current time could be pulled from, and then the referened streams would be checked against it.

Starting a stream access without checking if it's timestamp was less then the current time would be a error that would lock the system up till a event was entered. Just like taking the (cdr `()) is a error.

So i don't see the problem. Is there something wrong with what i put forward, or did this problem just get solved after the videos were made (1980's)?

I am planning on using the following definition of type for my documentation on Heron:

A type is a semantic classification of a set of values. In other words it is a set of values which share some kind of information, whether it is intensional, extensional or otherwise.

Any comments?

Some recent forum topics regarding programming language phenomenology, language oriented programming, and natural programming languages may be connected through a common theme of software metaphors.

Software is entirely and thoroughly metaphorical. Metaphors pervade every element and aspect of software, from the lowliest variable name to the largest of enterprise architectures. Software is so steeped in metaphors that we often overlook the extent and nature of these metaphors. Like fish in water, software developers often do not perceive the medium that surrounds us: our natural languages, natural conceptual models, and the natural and linguistic metaphors we use every day in our software designs. Even so, software developers borrow ideas, terminology and organizational structures from every field they encounter and every problem they solve.

Should we explicitly include consideration of metaphors and characterize any gaps between the expressive power of our natural languages and programming languages in any phenomenological study of our programming experience?

Or specifically, Region Streams: Functional Macroprogramming for Sensor Networks ("Macro" as in "big" not macros).

We are investigating high level languages for programming diverse, distributed networks of sensors. Our goal is to greatly simplify sensor network application design by providing high-level programming abstractions and primitives that automatically compile down to the complex, low-level operations implemented by each sensor node.

Sensor networks are an emerging computing platform consisting of large numbers of small, low-powered, wireless "motes" each with limited computation, sensing, and communication abilities. Sensor networks are being investigated for applications such as environmental monitoring, seismic analysis of structures, and tracking moving vehicles. Still, sensor network programming is incredibly difficult, due to the limited capabilities and energy resources of each node as well as the unreliability of the radio channel.

The language described in the paper, Regiment, is purely functional and uses techniques such as monads and functional reactive programming. It'd be quite ironic if this turned out to be the 'killer app' of pure FP. Sensor nets are related to Amorphous Computing and Swarm Computing which though mentioned in LtU appear never to have been a topic despite being quite deserving.

In simplified terms, phenomenology means inner perceptions of reality. Phenomenology is the study of structures of consciousness as experienced from the first-person point of view.

Given that, this programming journal assignment sounds really interesting.

The purpose of this journal is to make you more familiar with the phenomenology of the languages you use, so that you will be more sensitive to the full range of phenomenological issues when you design programming languages (and other language-like systems) and when you choose a language for a particular project.

Can you share the phenomenology of languages that you use or that you have designed ?

A lot of thought has been dedicated to scalability in computer systems. However, outside of the embedded systems arena, most of this effort has gone into making systems ever larger and faster.

For a change, let's have a look at downwardly scalable systems - systems that work well where resources are not abundant. Going beyond considering systems that don't place hefty requirements on the hardware (CPU, disk, memory, bandwidth), we wish to consider "human resources" - people, and the effects that downwardly scalable systems have on development.

I'm still mulling the subject over in my head, but I like the concept a lot.