Lambda the Ultimate

Could you state what you mean by "this" a little more explicitly? The proposal? The current state of affairs in Dylan?

sorry I was obtuse. That was a rewording of a line from the abstract up there. It just seems sad to me that there's apparently a zillion people in the world to whom "wait, we could *use types* in our apis?!" is a revelation of such magnitude, or needs to have those bullet points pointed out explicitly.

"It's a nice day,"
or
"You're very tall,"
or
"So this is it, we're going to die,"
or
"Types in your APIs might help."

:-)

I have been excited about the mere existence of OpenDylan for a while, and I'm truthfully excited that it appears to have some people dedicating meat-cycles to it, still. Not dead yet.

But I'd never used Dylan enough to even know/realize/notice that it didn't support types for signatures :-) so this was a little bit of a depressing surprise to my previously blissful ignorance.

The block quote from early in the article makes it clear that the Dylan designers were aware of the issue very early in the life of the language. It comes across like they chose the present solution as a kind of sweet spot, rather than being completely blind to the issues.

For what it's worth, it seems that Julia (which is heavily Dylan-influenced) makes the same choice.

There's probably an argument to be made that the low-hanging fruit optimization for higher-order functions comes from specializing to particular function values rather than function types. For example, being able to specialize map(f,a) for a known f (e.g., a lambda).

Also, pervasive use of "bare" functions may not have been anticipated as a common use case, given that Dylan tended to be presented as more OO than functional in the early days. It would seem like a stereotypically Java-ish approach (that is, express your callback as a class/interface with only a single method) could regain typing across API boundaries. Not that I'd advocate for such things.

Anyway, I basically agree with your (clarified) assessment. Just wanted to throw out some possible excuses for the current state of affairs.

I'm the author of the linked piece (and after years of lurking here, finally signed up for an account).

I am not allowed the luxury of writing for an expert audience and in previous drafts, people asked questions, so I answered them in the writing.

As Tim Foley pointed out, the desire for improvement in this area was recognized early on, but most of the code written at the time wouldn't have benefitted much from it. At the time, there was also an assumption that the Dylan partners (Apple, CMU and Harlequin) wouldn't end up collapsing and having to drop Dylan for various reasons. :)

This isn't the only thing that was discussed at the time that was punted to a future version. (Although I'd have to trawl through thousands of emails to find another good example.)

Another reason that this wasn't as much of an issue at the time was that, given the machines of the time, the implementations of generic dispatch were pretty good, so the overhead of going through a full dispatch in the cases where this might've been used wouldn't have been so bad. Unfortunately, at least the Open Dylan implementation of generic dispatch has not aged well in relation to the advances and changes in hardware since then. Given that and that we're writing more code that uses "bare" functions, we're seeing the lack of compiler support in an ever-increasing way.

Two other reasons to call things out that might be obvious to some: It gave some structure for analyzing the motivating case and sometimes it can help make someone excited. Sometimes, when listing stuff like that out, someone says "Oh, that sounds like an interesting thing to do!" and volunteers to help out.

And regarding this:

I have been excited about the mere existence of OpenDylan for a while, and I'm truthfully excited that it appears to have some people dedicating meat-cycles to it, still. Not dead yet.

But I'd never used Dylan enough to even know/realize/notice that it didn't support types for signatures :-) so this was a little bit of a depressing surprise to my previously blissful ignorance.

There are many misunderstandings about Dylan out there. Many think it died entirely when Apple axed Apple Dylan (it lived on commercially for a couple of years after). Many think that it doesn't make much compile-time usage of type info (it does). You thought it provided better type checks than it does. :)

Anyway, we're looking at some large revisions to the type system over the next couple of years as well as some other major changes. We'll be discussing that on the hackers mailing list starting next week.

Why not optimise the case of a function object with a single 'do this' function member and no data? You could replace the object by a plain function as an internal compiler/interpreter transform, or even in-line small objects.

Forgive me, but I'm not really sure what you mean here.