Lambda the Ultimate

inactiveTopic Needle, An OO FP Language
started 11/14/2002; 9:43:47 AM - last post 11/19/2002; 4:49:03 AM
Noel Welsh - Needle, An OO FP Language  blueArrow
11/14/2002; 9:43:47 AM (reads: 2431, responses: 13)
Needle, An OO FP Language

Needle is a new language that was discussed at LL2. The feature list reads like everything I've ever wanted in a language: multiple dispatch, continuations, macros and static typing plus the all usual features you'd expect. Impressive piece of work created by someone who's obviously got a great understanding of modern programming languages.
Posted to object-functional by Noel Welsh on 11/14/02; 9:45:25 AM

water - Re: Needle, An OO FP Language  blueArrow
11/14/2002; 1:05:03 PM (reads: 1671, responses: 0)
I watched this live, and it was very encouraging to see, since I have been working on a language with very similar features but an opposite viewpoint: that typing is optional and doesn't drive performance. My Smalltalk derivative Slate. If you run it on CMUCL with caching and inlining turned on, it delivers almost the same speed, but we haven't released that yet; we're more focussed on the bootstrap and building out the libraries.

Dejan Jelovic - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 4:08:03 AM (reads: 1568, responses: 1)
I never understood what's so hot about multiple dispatch as a language feature?

First of all, it's trivial to implement multiple dispatch as a library object in any language that supports reflection.

Second, multiple dispatch is often presented as a better alternative to the Visitor pattern. However, Visitor is statically type-safe and multiple dispatch is not. The moment you use multiple dispatch you throw static typing out the door.


Noel Welsh - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 4:54:14 AM (reads: 1600, responses: 0)

However, Visitor is statically type-safe and multiple dispatch is not. The moment you use multiple dispatch you throw static typing out the door.

Bzzzt! This is incorrect. Examples of statically type-safe multiple-dispatch languages include Needle and EML.

Multiple dispatch support modularity in a way neither OO nor FP address. If you have a table with rows being operations and columns being types, OO allows you to fill columns at a time, FP to fill rows at a time and multiple dispatch to fill cells at a time. So I think multiple dispatch is the unity of OO and FP, at least for modularity concerns. See SICP section 2.4.3.

Alex Moffat - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 6:31:56 AM (reads: 1531, responses: 1)
But, what will make a language like this "successful"? Is it the features it provides, the platforms it's available on, some cool application that it's written in or what? I don't think just having all of the nice features is enough, somehow a community has to come together round the language. How do you design for that to happen, how do you replicate the success of perl, python but with a "better" language? My initial though is that it needs to satisfy some group of people along some axis that is not being addressed by existing languages. So, for a bad example people here may not like :), if there was a language that made creating webservices trivial I think people would overlook a lot of other flaws it might have.

Frank Atanassow - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 7:08:05 AM (reads: 1526, responses: 0)
Looks interesting! Is Neel a member here?

Isaac Gouy - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 10:47:27 AM (reads: 1535, responses: 0)
what will make a language like this "successful"?
You seem to be thinking along the same lines as Disruptive Programming Language Technologies presented at LL2.

Surely the success of a programming language is as uncontrollable as the success of any of our other activities in the world. Excellence is not always recognized or rewarded. Being in the right-place at the right-time is really important. Being persistent is really important (Was it on the 3rd or 4th attempt that Oak/Java finally attached to a successful project?).

We know all this - the strange thing is how much we want to believe this doesn't apply to programming languages.

Neel Krishnaswami - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 6:31:00 PM (reads: 1460, responses: 0)
Hi, I just learned about this website from Bryn Keller.

My main goal with Needle is to write the language that I want to program in. Obviously, Needle will get the features that I, personally, like a lot: macros, multimethods, static typing, continuations, higher-order functions. But getting all that implemented isn't really what I'm primarily interested in (though I am interested in that, and have learned a lot).

What really interests me is the standard library. In practice, the ease of programming is in the libraries. Example: Python is an okay language (it's like Smalltalk's dumber cousin) and it kind of sucks in terms of design, with a lot of ad-hoc'd up protocols, but they're all *actually there*. So it has a rich library set and I can turn to it immediately when I need to hack. This is a *big* win, and a reason I use it as much as I use Ocaml, despite liking ML a lot more than Python. My goal with Needle is to see what kind of maximum-leverage libraries I can write when I have everything I want in a language. I mean to put things like parser combinators, constraint sublanguages, concurrency, and other really extremely powerful ideas right into the core libraries.

One of the things that surprised me was that a lot of Todd Proebsting's potential "disruptive technlogies" were things I was already contemplating for Needle's standard library. It felt like he was reading my mind, though I guess if you are looking for things to seriously raise the abstraction level of programs you don't have a big list. The big difference is that I think of these as things you build from macros, HOFs and call/cc, and he thinks that they should be basic language features.

Alex Moffat - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 7:33:10 PM (reads: 1416, responses: 1)
While I agree that you can't guarantee success for a programming language perhaps there are things that can be done to improve the chances of success. I think the biggest one is to target making some programming problem or task easier to solve with the new language than with any existing language. People who have this problem or task should then tend to adopt the new language for the task and hopefully use and improve it for new tasks. You need a beachhead into the language space that isn't already heavily defended by existing languages.

p.s. Of course you also need extensive libraries :)

Adewale Oshineye - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 8:54:42 PM (reads: 1456, responses: 0)
If you were to adopt this plan then targetting an existing language would be a good idea. Being a better X than X gives you a well-defined goal to aim at and a target group of potential users to convince. For instance a lot of scripting languages (Perl, Python and Ruby especially) on Unix platforms tend to get adopted because they're a better Shell than Shell. This helps when it comes to deciding which libraries to implement first and deciding when things are "good enough." Being a better X than X in a particular niche is easy to ascertain but being perfect/successful are too vague to be useful goals.

Chris Rathman - Re: Needle, An OO FP Language  blueArrow
11/15/2002; 9:46:58 PM (reads: 1417, responses: 0)
Just from glancing at the Needle info, it appears to share a lot of common goals with the Goo programming language - both seem to lean on Dylan with a tendency to want the flexibility of Scheme. (Like Dylan, Cecil and CLOS, method definitions are seperated from the data slots).

From a syntax standpoint, Needle seems to be leaning to a more common looking syntax - i.e. towards a syntax with Java-esque qualities.

Frank Atanassow - Re: Needle, An OO FP Language  blueArrow
11/17/2002; 5:44:18 AM (reads: 1376, responses: 0)
So, is there a paper forthcoming with the technical details? Needle looks very ambitious, but I expect there is a lot of delicate interaction between subtyping, type inference, parametric polymorphism, modules, multiple dispatch, assignment and continuations which endanger type soundness and principal typing. In fact, I don't think I have ever seen a language which integrates all these things in a provably sound fashion. It might be quite a coup if you could show otherwise.

Neel Krishnaswami - Re: Needle, An OO FP Language  blueArrow
11/17/2002; 1:18:12 PM (reads: 1329, responses: 0)
Frank: Needle relies on a lot of well-proven PL technology. Needle, like Daniel Bonniot's Nice language, relies on the ML-sub type system. Soundness was "easy", in the sense that I could mostly just piggy-back on the work of Bourdoncle and Merz. Soundness in the face of assignment and continuations comes from the familiar value restriction of ML. However, Needle does not have (and will never have!) principal typing. The extra expressivity that subtype relations between types give you means you lose the idea of a single most general unifier between type expressions. Like all constraint-based type systems, Needle will have to rely on a type simplifier to make inferred types readable.

Chris: I'm familiar with Goo, and talk with Jonathan Bachrach regularly. Needle *is* a reaction to Dylan, except that I went in the "more static" direction rather than the "more dynamic" direction.

Franck Arnaud - Re: Needle, An OO FP Language  blueArrow
11/19/2002; 4:49:03 AM (reads: 1275, responses: 0)
Examples of statically type-safe multiple-dispatch languages include Needle [which relies on the ML-sub type system] and EML.

Strictly speaking, maybe, but if I recall the ML-sub paper correctly, it's full of type exceptions in the list examples which are not that far from dynamic typing: that is you do get "a message not understood" error at runtime even if it is written by the programmer in an explicit routine that issues an exception. Making the locations of runtime type errors explicit is better than risking them all the time as in fully dynamic languages, but it is a bit remote from the ideal of fully static typing.

Also multiple dispatch seems likely to suffer from implicit type errors if not exhaustive: if you do not declare all combinations explicitely, which may be inconvenient, you may get the wrong version called, where there should be a type error.

For instance



we want a multiply dispatched feed: (Animal * Fodd), so we declare:

feed : (Carnivore * Meat) = ...
feed : (Herbivore * Vegs) = ...
feed : (Animal * Food) = raise "I'm not statically typed"

all well, but then we add


the compiler won't tell you to add a routine, but call feed (Animal * Food) which is really a type error (a _different_ one from what the "raise" catches). Neither the OO visitor pattern, nor the ML datatype inspection suffer from this problem.

If you are exhaustive, you solve this one, but you have to declare explicitely (exception raising) implementations for (Carnivore * Vegs) and (Herbivore * Meat). Of course if the hierarchies have a few more classes, it's N*M combinations to declare explicitely...