## Function Types and Dylan 2016

Function Types and Dylan 2016

Moving towards Dylan 2016, the Dylan community would like to address some weaknesses in the language specification and what can be readily expressed in Dylan code. In this post, we'll look at function types as well as provide a brief introduction to some details of the type system implementation within the Open Dylan compiler.

One of the big holes in the Dylan type system is the inability to specify function types. What this means is that you can only say that a value is of type and can't indicate anything about the desired signature, types of arguments, return values, etc. This is unfortunate for a number of reasons:

• Poor static type safety. The compiler can verify very little involving a function value. It can't warn when the wrong number of arguments or the wrong types of arguments are passed.
• Less clear interfaces. The type signature of a function must be documented clearly rather than being expressed clearly within the code.
• Optimization is more difficult. Since the compiler can't perform as many checks at compile time, more checks need to be performed at run-time, which limits the amount of optimization that can be performed by the compiler and restricts the generated code to using slower paths for function invocation.

In addition, function types may allow us to improve type inference. This is something that people have long wanted to have in the Dylan language.

## Comment viewing options

### This is unfortunate for a number of stunningly obvious reasons

unless one is a give-me-python-or-give-me-death sort/kind/type of person.

### Clarification?

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

### "stating and restating the very, very obvious"

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.

### Thanks for obliging me

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.

### On being obvious

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.

### Optimise Function Objects

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 ...

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