Lambda the Ultimate

The paper rationalizes the new 'features' as supposed demanded by the users of the langauge, but I feel that the language is sacrificing expressiveness (maybe clouding is a better term) for safety and rigidity, or rather comfort and familiarity.

Reading this provokes thoughts of another language I have been playing with recently: Self, by Sun Labs. And I must say that I am in love. Though the syntax is very concise and constitant (thank you SmallTalk) I am still finding it a little awkward. Of course I felt the same way about Lisp when I first started using it, and I still feel that same way when when doing mathematical computations with prefixed operators.

JavaScript has a lot in common with functional programming languages, and is nicely disguised as a member of the C family. I feel that JavaScript should continue to evolve towards a more complete functional language, and this potential future is shown by the wonderful BeyondJS library. I also felt that instead of pushing for a more stricter typing system, that maybe JavaScript should push more told a complete object-oriented language, where everything is an object. And an object is not about what it is, it is about what it does (roughly quoted from the Self documentation), which soundly oddly close to a functional programming mantra.

I don't see it being very difficult to take JavaScript's syntax and integrate into the semantics of a message passing object system like that of Self and SmallTalk. To do a very simple example:

3 + 4;

could easily be expressed, and syntatic sugar for:

(3).add(4);

When trying this now, JavaScript informs me that I have committed and error. Which of course is to be expected.

I am working on a small runtime at this period of time. Its just a small SECD machine, which is not necessary, but I have never implemented an abstract machine before so I thought it would be a fun exercise.

I would appreciate any comments, or constructive chastising. Thank you all for you ear.

Regards,

Mark Stahl

Second, I share your disappointment with regard to JavaScript 2.0. I too was hoping the future extensions to that language would enhance its unique abilities. Instead, it seems that its developers are intent on making it into another flavor of Java or Python.

I can certainly understand the motivation:

To work in multi-language environments, JavaScript 2.0 provides better mappings for data types and interfaces commonly exposed by other languages. It includes support for classes as well as previously missing basic types such as long.

That is, given JavaScript's historical role as a glue language, they feel it can better accomplish this task by supporting a type system that is closer to most other OO languages. JScript.NET is prime example of this reasoning.

JScript.NET IMO is also a good example why this reasoning is wrong. JScript.NET is rarely used for .NET programming because it doesn't provide any substantial upside over, say, C#. The Rhino environment for the JVM OTOH demonstrates that it is possible to achieve tight integration with the underlying class-based VM while retaining JavaScript's unique nature. Indeed, Rhino (especially when coupled with BeyondJS ;-) is a very cool environment to work with.

That is not to say that everything is bad about the JavaScript 2.0 proposal: I like the new scoping rules and the const keyword. The packages mechanism also looks interesting (though I believe it could have been achieved without extending the language).

I would have preferred a different set of extensions, e.g. the ability to access and manipulate scopes as objects, the ability to dynamically assign scopes to computations, and tail recursion and continuations. Oh yes, a shorter lambda syntax.

With regard to (3).add(4) - this can easily be done in JavaScript:

Number.prototype.add = function(n) {
  return this + n;
};

As you have stated, this function would have no association to the + operator. This is another JavaScript limitation: operators and functions/methods are two distinct entities. In BeyondJS we circumvent this limitation (sort of) buy using string representations of the operators, for example:

var sum = "+".toFunction();
print(sum(1, 2)); // outputs 3

In some cases, when a string-type parameter is passed to a function that expects a function, we apply the toFunction() method automatically. This is why you can write:

var s = (1).to(10).fold("+");

In any event, I would be interested in learning of your progress.

I very much appreciate your reply (the only reply) to the message I posted on Lambda. To be honest, I was hoping that it would catch your eye, and in turn your would reply.

I wrote this directly to you, because I didn't have access to Lambda (ie, it was being flaky again). I apologize for its length. I tend to get a little verbose when excited.

I can agree with the JavaScript 2.0 spec given their expectations of the language, but I guess I question the why's. It can't be for market share, and I would find it hard for anyone to decide that JavaScript, while keeping its prototype heriage and including class, is better than what they are used to or currently comfortable with.

I have spent the last 3 years trying to evolve Lisp, though I fear two things. 1) Its not possible, because the core of Lisp (not CL) is elegant and near perfect in its simplicity and consistancy, and 2) in order to can much of Lisp's power, a prefix syntax is needed somewhere.

Color (as I have named it so far) is my version of Lisp. I find it comfortable because I am used to the C-style family of languages, and I believe that it can be stripped down into one construct that allows for the rest of the language to be built on (ie, the function). I plan on using Lisp's power by using an SECD machine as Color's runtime environment (the CRT). My main reason behind this was for metaprogramming, which is something I miss dearly after learning Lisp and returning to C and Java. Couple this with the reflective capabilities of prototypes, you have yourself something that can be a very good way to misuse a computer (to paraphrase a quote about lisp). On a syntactic level, I have done a lot of studying on Dylan's macro system (which is built for infix syntax languages) and feel that much of it can be used for Color.

I think I also mentioned my goals for the language in the post. I am working on a large web page project right now, which currently requires me to use PHP and SQL, which eventually led me to trying to find a way to make my life easier. I needed JavaScript for a DHTML project, and the code flowed very well from my figures which is usually a good sign. So in turn, JavaScript became my syntactic starting point, and still contributes much of the semantics.

I found a post on here about the BEA extensions to JavaScript for handling XML data, and thought many of them were good ideas (though I don't know how I feel about the .. operator). I didn't know at first how I would feel about the @ operator used for accessing attributes, but the more I thought about it, the more I agree with their choice. I continued to think about and tried to apply a simplier system for relational DB's. And it seems to work out just as well. (db.table.field, or db.table.@field == the type/attributes of the field).

The '.' operator on both XML and relational databases allows for explicit access to data within those stores, but I wanted a way to query as well. SQL is fantastic, but I don't like to have to switch back and forth between languages. The idea that I need to use two languages for doing dynamic website building is ridiculous to me. So I have done some research on Prolog and nondeterminstic evaluators, and started to think about how they could be integrated into the simple syntax with adding the fewest language constructs possible, and maintaining consistancy.

Of course nondeterministic evaluation provides some other interesting power, like have two slots on an object, both with the same name. Accessing the object.slot would in turn return more than one answer. Which is really cool.

Well I have talked a lot about ways that are going to mess programmers up, and I haven't talked at all about safety. As far as packaging goes, I felt that Erlang provided a way to do 'private' slots without have a language construct for it. You have to explicitly declare what is exposed to anyone using the file. This of course could be mean objects, data, or functions (but of course because they are all the same =).

And as far as typing goes, I fail to see the necessity for it, at least within the realm of Color. Typing has other implications other than programmer control (like ease of compilation), but I in a /complete/ object heirarchy, there is no need for the control... because if the slot does not exist on the object, the message will not be sent, and in turn will error out. So I guess what I am saying overall about safety is that I don't have much of a concern with it. I feel that as a wannabe language designer it is my job to provide a powerful user interface, not to baby my users.

Thanks for the ear Dan, and I would appreciate any advice, constructive criticism, or outright chastising that you could provide. =)

M.J. Your post is very interesting, but I unfortunately do not have the time to give it the proper thought and response.

What I can say is that:

1. There are LtU members that are much more knowledgeable about Lisp than I.
2. I think Smalltalk is also very relevant to this discussion.
3. I think some other members may have strong opinions with regard to your comment about "baby my users" with type safety.
4. It's cool that you have the opportunity to develop a new PL for the project you are involved in.
5. You may want to take a look at Sjoerd Visscher's Loell project.
6. You may also want to read about SchemeQL

I hope this post makes it through ...

My biggest problem I constantly have to work around in JavaScript is that neither the variables nor the operators are typed, but the language does a lot of autoconversion (which is sometimes not what you want). All the arguments to functions need to be coerced to numeric type before doing any mathematical operations.

And as long as we're on the subject of JavaScript, I've been toying with creating images on the fly. An xbm image can be created on the client in JavaScript, but the image must be loaded in total into a JavaScript variable. The source for an image can be given as:

<img src='javascript:MyJavaScriptVariable'>

I was tinkering with BeyondJS last week. What I'd like is to use a generator function (output stream) in place of storing the image in a local variable. Something more like:

<img src='javascript:MyGeneratorFunction'>

Is there a way to do this in JavaScript (or BeyondJS)?

3 + 4 is just syntactic suger for,

3.add(4) or in Self/Smalltalk 3 :add 4

Conversion is not necessary because if the object doesn't have the slot, you are going to get an error.

As far as typing goes I have been thinking a little about this, and I agree (being that I am all about productivity) that typing helps with catching early bugs, so I have basically been thinking of a loose typing system for functional arguments, and variables. I just don't know how far I am willing to go yet.

Water,

Slate looks interesting, and I want to look a little bit more into it. But, if you wouldn't mind, I would like to talk to you about certain implementation details that I not necessarily familiar with or have not completly considered. Maybe there are somethings that you have run into that I need to watch out for.

I would appreciate any kind of knowledge you can provide.

3.add(4) or in Self/Smalltalk 3 :add 4

Huh?

In Smalltalk, there are binary message selectors, of which + is one. This is not syntactic sugar for :add. (In any case this would be add: rather than :add, you must be thinking of Common Lisp keywords.)

Please accept my apologies for the mistake in the placement of the colon. I haven't studied much of the Self syntax, only the implementation notes and paper by the authors.

Not a problem. I wanted to set the record straight for those that have not used Smalltalk.

Thanks