Lambda the Ultimate

As Bill Gates finally bows out of Microsoft to pursue his charity interests, we look at some of the hits and misses of the software company he founded.

This is the premise of a recent BBC story. Alas, the story does not talk about (and certainly doesn't focus on) programming languages, something that was part of Microsoft practically from day one (i.e., the Altair BASIC). So how would you write the story from the perspective of programming languages (their impact on the success of the company, on the quality of its products, and on the industry as a whole)? No trolls, please!

Hi, we can now get to the second part of the exercise! Please help me by locating on the map and marking with a yellow pin the birth places of influential ideas in the programming languages theory and design, that influenced major programming languages (in the sense discussed in the previous message). Again - the point is not to employ subjective value judgments, but rather include any idea that was considered influential. For example: ADTs, OOP, structured programming, explicit typing, strong typing etc. There are, of course, more influential ideas than major languages.

Since debates about priority are common, please mention in the pin description the researcher/paper/book that you have in mind, and if possible the year the idea was announced.

If the origin of an idea is closely associated with a language already on the map, you should still go ahead and add a yellow pin (you can mention the connecetion in the description, of course).

[To change the color of the pin, click on the pin icon on the pin edit window, and choose the yellow pin from the available options.]

I've set up a shared google map, for visualizing the distribution of "birth" places of major programming languages. Please assist by placing a pin in the birth place of major general purpose programming languages. Only place major languages for now, in the sense of wide adoption, rather than intellectual significance please (when the two conflict, of course). That is things like: C, C++, Java, COBOL, Fortran etc.

When in doubt whether a language should be included or as regards the appropriate location to use, please share your thoughts here.

I'm looking for example type systems that can type list structure.

For a simple example... (Sorry, I think in code)

// Map two elts at a time, not two lists
def map2(alist:List, f(*,* -> 'u) -> 'u List) // f(*,*) is not good 
  def mklis(nl: 'u List, rest: List)
    match rest
    | a :: b :: r  -> mklis(f(a,b) :: nl, r)  // types of a and b?
    | else -> reverse(nl)
  in mklis(nil, alist);

def plist2alist(plist:List -> <List>List)
  map2(plist, fn(a,b) a :: b :: nil);

plist2alist('(A, 1, B, 2, C, 3))
 => ((A,1),(B,2),(C,3))

It would be very nice to type plist's internal structure, 
thus allowing for typing the map2 function, plist2alist()'s 
resulting internal structure, etc.

I can sort of imagine some kind of regex typing construct, 
but I have no clear ideas on this.  Any languages out there 
do a good job of typing repeating internal patterned structure 
like this?

If this is impossible for any theoretical reason, I'd love 
to know that too :-)

Many thanks.

Scott

In Self and Ruby, to name two examples, procedure call can be implicit. In an expression context, a naked identifer, such as "foo", gets interpreted as a procedure call to "self" or "this" or some such implicit context. So, "foo" can mean "self.foo".

In Mozart/Oz (whichever of those is the language), the naked identifier "foo" implicitly quotes itself. So, in Oz, "foo" can mean what "'foo" means in Lisp, "#foo" means in Smalltalk, and ":foo" means in Ruby, namely, the symbol "foo" itself.

If a programming language syntax chooser chooses to make any meaning implicit in the syntax, e. g., procedure call or quoting, she has expended a lot of syntactic capital in one go. The decision to make one meaning implicit likely excludes the possibility of making some other meaning implicit, and it may turn out that the second assignment of meaning would have been more valuable to programmers. For example, "foo" cannot both mean 'foo and self.foo.

Would readers care to express a feeling about what is the most valuable place to expend the opportunity of assiging implicit meaning in a programming language syntax? Is Oz what to copy, or Self, or something else?

Maybe in the early stages of inventing a language, the designers should reserve the assignment of meaning of naked identifiers as a future decision to be carried out _after_ there is a body of working, useful code. Such a body could then be studied to determine which assignment of implicit meaning would have produced more economy (of keystrokes) as an aid to expressing the programs that exist by then.

But in that case, procedure call, or message passing, or both, whatever operation or meaning like that is most relevant to the semantics of the programming language under construction, still needs to have as economic and tasty a syntax as possible. So, if you think procedure call (or message passing) should be given an explicit syntax, what syntax would you favor? In Oz, for example, the procedure reference and the argument are enclosed in curly braces.

The semantic context in which the question of implicitness in syntax applies for me, is of a language in which it should be common and easy to pass messages by asserting their membership in bags. A concurrent constraint language along the lines of Janus and ToonTalk. A logical variable will be splittable into two kinds of reference, an asker and a teller, representing, respectively, the right to query the variable and the right to tell constraints on the variable.

I'll give an example of what should be easy. In exposing the example to you, I'll follow the Oz convention that symbols in caps represent plumbing and symbols in lowercase represent themselves.

Then we could be in the middle of a procedure definition where one of the parameters in the procedure is some teller given by the plumbing symbol A. The value of A at runtime will be a teller for a bag, the teller having been passed as an argument to the procedure we're writing. Then it should be easy in the defintion of the procedure to write multiple assertions that certain messages belong to the bag. I don't know whether the symbol A should be repeated for each of these, which would amount to an admission that A isn't referentially transparent, or whether there should be a syntax saying A is the union of A', A'', and so on, and we have A', A'', and so on, appearing where we talk about sending our messages into A. But what's more important, is I would like an economical syntax to express a meaning like B := {A foo bar: 2 bletch: 3} where we're sending a message into A consisting of a record with 'foo the verb (just a symbol that is going to be interpreted by whoever is consuming A), 'bar:bletch: the description of two of the parameters or arguments being passed, 2 and 3 the values being passed associated to the keywords 'bar: and 'bletch: respectively, and another argument, the teller for the variable that B is the asker for. The reason for the syntax to treat B differently than 2 where 2 is being passed as the argument with keyword 'bar:, is that it's nice to be able to nest expressions that we think of as returning values. Plumbing can take fewer keystrokes if we don't have to name all the pipes.

Here's an announcement I'm sending out. Hopefully this will be of interest to a few SoCal LtUers.

Announcing the creation of Southern California Functional Programmers (SoCalFP), a group for people in Los Angeles, Orange County, and San Diego to meet in person and/or virtually to discuss, debate, present, and learn about functional programming concepts and techniques in various languages.

You might ask, "why a functional programming group in Southern California?"

Well, SoCal, wake up and smell the lambda. There's increasing interest in bastions of functional programming like Haskell and various Lisps; popular mainstream languages like Ruby and Python have lambda (or lambda like) capabilities; hybrid OO/functional languages like F# and Scala are generating buzz; C# 3.0 has embraced core functional ideas like closures and monads; and even staid, conservative Java may get some functional goodness in the next version. Perhaps most importantly, programmers can't ignore the oncoming multi-core freight train and Erlang has shown that concurrency and functional programming go together like peanut butter and chocolate.

If you're intrigued come visit our main site and join our mailing list.

This is just to note that I recently updated Parametric Higher-Order Abstract Syntax for Mechanized Semantics to reflect the fact that a draft of the paper is available, for those who might be interested.

http://lisperati.com/july12th.png
http://lisperati.com/fringedc.html

FringeDC is a group in DC interested in Fringe and Functional Programming Languages such as Lisp, Haskell, Erlang, Prolog, etc.

Join us at Sova Espresso & Wine for a presentation from Conrad Barski, M.D. from the new book "Land of Lisp" published by No Starch Press, due this Fall.

We'll discuss Lisp and see never-before-seen comics and game examples from the book!

Afterward, we'll be talking over some wine, coffee and food at this
great little hangout in DC's H Street Corridor.

SOVA - Espresso & Wine
1359 H Street, NE,
Washington, DC 20002
tel: (202) 397-3080

Hi, I want to write a new language. However, I need something new to justify writing the language. I imagined a system where all code would be transformed by bytecode via macros. Turns out that has been done. I imagined objects that were made by copying - turns out that has been done in prototype OOP. I imagined where functions and objects were the same thing - turns out that is just first class functions. Can people of this forum suggest anything? I would prefer ideas that target the below key principles:

1. makes code shorter. I want to be able to describe client-server programs with ten lines or less. I want to be able to write gui code with just a data structure and telling it to represent itself. How? Standard templates? Code generation of gui, protocols? Transparent functions and data?

2. makes code less error prone. Typos and Logic errors should be the only thing to exist. How can we enforce less errors by making errors impossible to express?

3. makes intention/purpose over implementation. In a perfect world, programming would be done with strong AI assistants (paid in cpu hours). Without AI what methods would we use intention to guide (potentially automatic) implementation?

4. makes reading, sharing, and reusing over writing. OOP was touted as the solution to sharing. Is it?

5. unifying

What I am not interested is static/dynamic, typed/untyped, etc debates.
New algorithms are pretty much irrelevant to this since they just do things better.
Nor another algebra that unifies logic into a computable framework.
Make sure your ideas do not require O(e^N) time :D

Cheers!

Kilim is a message-passing framwork for Java that provides ultra-lightweight threads and facilities for fast, safe, zero-copy messaging between these threads.