Lambda the Ultimate

Hallo,
In the paper "Scalable Component Abstractions", Odersky introduces the selftype construct for Scala,
and says its different from the MyType construct.Does anyone one have a link to a paper that compares the two constructs? A paper that provides in depth discription of selftype construct?

Often in modularity discussions the concept of "local reasoning" is discussed, and it's always assumed we want to make it easier, as a tactic for in turn making it easier for programmers to keep programs in their head. 'Local' to me implies that we have some notion of distance, and I'm curious what work if any has been done on measuring that distance. I've seen lots of claims about X or Y language feature reducing the ability to engage in local reasoning, but no attempts at quantification, without which I don't understand how the languages can be properly compared. Papers, links to prior discussions, etc. appreciated.

As a long-time developer, I've created more bugs than is even remotely funny, so I'm not trying to make this a complaint or a witch hunt. Rather, I would really like to know how realistic it is to avoid bugs in the 'fundamentals' (relative term) of a programming language, and still have a language that is use/able in the real world? Testing & Modeling are the answer, I assume, but who has really applied them rigorously in the development of a programming language? It scares me that the tools we're supposed to build on might not be hallowed ground from a quality standpoint. (Yes, I know there are good reasons to trade off quality vs. speed.) I feel like there's something about "obviously no bugs" vs. "no obvious bugs" here, mixed in with issues of how the programming language will affect the program language; the simpler the programming language, the more we're just shifting the bugs out to all of the programs?

Here is a crazy thought experiment:

Take your favorite programming language and create a project in your favorite IDE (say C# and Visual Studio, but Scala and Eclipse or Haskell and Emacs would also work). Now imagine that this project is shared by you and a thousand of your closest programming friends. Everyone can edit the project, and you are pushed contributions in real time without any vetting. The idea is to collaborate building a library in an organic way that precludes a centralized maintainer/gatekeeper/project manager. Rather, you and everyone else could review code changes by other people, revert when vandalism occurs, or ensure that standards are met from people you don't know very well and may just be casual contributors. Yes, like a wiki.

Now, here are some of the questions that I can think:

• Could a useful/usable library ever result from large-scale de-centralized collaboration?
• If someone added functionality to the library that would be useful to me, how could I be made aware of that functionality? Likewise, how could I add functionality so that others could find it (answer might be language specific).
• Can community review enough to ensure quality and say..security; e.g., that someone doesn't insert a virus into codebase. Also, that contributed code is not copied from somewhere else with an incompatible license?
• Would certain programming languages work better than others in a code wiki? For example, would strong static typing hinder to massive collaboration because it requires too much pre-planning, or help because it ensures some consistency between contributions?
• If the library is continuously changing (no static releases), how would it be feasible to take a dependency on the library?

Not really expecting answers, but thoughts and other questions.

Onward 2009 essay* by Elisa Baniassad and Clayton Myers.

A well written essay that argues how programs form their own unique and self describing languages. Whereas programming languages have formal execution and are designed for the programmer to tell the computer what to do, program languages communicate what the program does to other programmers and (over time) to the programmer themselves. They claim that programming languages and program languages are inversely related in complexity: a higher-level programming language allows our program language to be simpler, which makes sense.

A couple of implications that I found interesting: First, perhaps we have to teach program languages as well as programming languages; e.g., knowing Java != knowing how to hack Eclipse code, we have to learn a lot about Eclipse through documentation and studying its source code first. Second, code migration (moving code from one program to another) is essentially language translation as the code must be translated from its from-program language to the to-program language, even if the programming language hasn't changed.

Ralph Johnson also has a good blog post on the essay.

* Unfortunately, the only link I could find was behind the ACM paywall. The paper hasn't made it to the author's homepage yet.

I am currently designing my own programming language (as many other visitors of this site are doing, too, I guess :-)). I want it to have a purely functional subset. I decided to include "random" and "choice" in this purely functional subset. My reasons why (probabilistic) non-determinism should still be considered (weakly) purely functional are outlined here in my blog. I am very interested in your opinions on this topic!

Small question I don't really feel like thinking about too much, and which is probably in literature somewhere anyway. I am looking for references.

Assume a lambda calculus (LCi) with side effects/impure function calls: LCi = v | \v . LCi | (LCi LCi) | call LCi* . * is a sequence of terms.

An example term: (\x. \y. call (+) x y) 2 3.

Assume EAGER(l) and LAZY(l), eager and lazy operational semantics for closed, mostly terminating, terms in LCi, respectively. Call accepts terms in strong normal form (snf), and return terms in snf.

We assume that EAGER and LAZY map a term into (LCi = call LCi*)* LCi, the collection of made calls in temporal order followed (possibly) by the term in snf.

I.e., the eager operational semantics of the example would be: 5 = call (+) 2 3, 5.

Needed: two functions e_to_l and l_to_e such that EAGER(l) =LAZY(e_to_l l), LAZY(l) = EAGER(l_to_e l), EAGER(l) = EAGER(l_to_e (e_to_l l)), and LAZY(l) = LAZY(e_to_l (l_to_e l)).

Note that = is equivalence modulo alpha-renaming.

Rationale: I want to implement some lazy features in an eager language.

More rationale: Nice functions to have because:

1. Say you would like to implement a Haskell compiler but you only have a Lisp compiler. Solution: translate Haskell to a corresponding LCi term l, translate that term to l' = l_to_e l, translate that to Lisp.

2. Say you want to have eager semantics in impure Haskell. That could be done similarly with the e_to_l function.

I didn't think it through too much, CPS probably doesn't do it.

[EDIT: REPLACED THE WHOLE POST :)]

Hello all,

I'm really not academic (I don't even have a B. Sci. :(, but I try to keep myself up to date enough on theoretical topics, and that I really care about in general, by the way.

Some background info on my current experiments relevant to this post and some rationale, is available there :

#1 http://www.ysharp.net/the.language/rationale

Not wanting to waste anyone's time, just know upfront that it's about this formerly codenamed "Oslo" and what it is, maybe, missing (as my intuition suspects) for it to scale well enough (— but, as one's own intuition is never enough to draw any useful conclusion to build upon, of course, hence my current effort at formalizing my feeling "at a minimum").

Then, as I intend to publish more about it using a specific notation, and that I leveraged for my purpose, I had to "push the envelope" further with this notation, testing my uncommon usage of it against better known topics, that have been studied for much longer(*) until today.

This is for me to see if that would lead me too easily to anything absurd/unconstructive.

Here's the result:

#2 http://www.ysharp.net/the.language/rationale/T_Party_0.html

If (and only if) this latter draft of ideas is not totally non-sensical to you and you find it interesting enough, I'd love to hear from you and about your advice on how I/we could formalize it more seriously.

Or I'd just love anyone to show me where are the biggest reasoning flaws in my statements.

Note I'm well aware it's unlikely I've found anything really new from a theoretical PoV, but I have some ideas about a hopefully useful application, to address the issue at hand.

Thank you in advance, & merry end of year holidays to all.

(*) (> 70 years or more...)

A recent post about a Lisp variant got me thinking about the usefulness of metadata and its desired properties.

1. - should metadata be preserved by copy?
2. - should metadata be preserved by reuse (my language is prototype-based)?
3. - should metadata be preserved when assigned a new value to the variable?

Points 1 and 2 raise the question whether the metadata should be part of the variable or outside of it.
Point 3 questions if the metadata should be associated with a name or with a memory location.

Is there a good list of desirable properties for metadata?

I am designing a module system for Heron. I was originally going to just pop in something that resembled the Python module system when I started reading some of Gilad Bracha's blog posts and articles, and some of the related discussions on Lambda-the-Ultimate.org and various other blogs.

There are two major considerations for me:

1. A module system should be easy to use, and keep the language easy to use. Python's success as a language seems to me to be largely due to how easy it is to write and use modules.
2. It would be nice to do some things right with the module system. To avoid some of the problems with module systems in existing language.

In my experience with modules systems in Turbo Pascal / Delphi the biggest practical problem I faced with reusing modules was that they were hard to reuse generically. Ideally I wanted a way to pass arguments to a module when it is loaded, so that I could configure it. This seems to be one of the benefits offered by the Newspeak module system.

I believe this is what other people are talking about when they refer to parameterized modules, correct? Would simply having the ability to parameterize modules, make an improvement to simple module systems like those found in Python?

Some related links that I have been studying:

• Objects as Modules in Newspeak LtU discussion on this article by Gilad Bracha
• Gilad Bracha: Cutting out Static LtU discussion on this blog post
• I Seek a Reasonable Survey on the Concept of "Module System" - LtU discussion
• A modular module system [PDF], by Xavier Leroy
• Newspeak specification [PDF]
• A Ban on Imports and A Ban on Imports (continued)
• PLT Scheme Units (Components)
• Import is not Inheritance - Why We Need Both: Modules and Classes (1992) - by Clemens A. Szyperski
• Importing Python Modules - Interesting article about import statements in Python
• Python Modules from the Python module
• Advanced Module Systems: A Guide for the Perplexed [PS Slide Deck] by Benjamin Pierce
• Scalable Component Abstractions by Odersky and Zenger, describing objects as modules