As we discussed in the previous post, we are thinking about a new design and implementation for the streams library in Open Dylan.

While the examples in this post are in Dylan and are using code from our HTTP server, these issues exist in HTTP frameworks in other languages. The code should be clear enough that little to no Dylan knowledge is required to understand the points being made here.

What does this have to do with HTTP? There are several pain points in our HTTP stack as it is currently written:

• Requests are read in their entirety into memory, so a large request (such as a file upload) takes a significant amount of memory.
• Responses often buffer their entire output in memory as well.
• Because of the use of the existing streams library, we don't handle non-blocking sockets and require a thread per socket.
• We don't have a good model for handling long-lasting connections such as might be used with Server Sent Events or WebSockets without tying up a thread for the duration of the socket being open.

We don't know yet what the new streams API will look like, but we can look at our ...

There are comments.

I spend a lot of time debugging Dylan code. Up until now, this has been a somewhat painful process when not using the IDE on Windows. (And I don't really use the IDE on Windows as it doesn't fit well into my workflow.) I finally reached the point where I decided that I wanted to improve our debugger integration.

Much of what is described below may be applicable to people working on debugging support for other languages.

There are comments.

Many compilers are now being outfitted with LLVM backends. There are a variety of ways to do this, and we'll take a look at some of them here.

There are comments.

Last month, we had our first hack-a-thon in many years. Attendance was spread out over the weekend and some great contributions got completed.

• Carl Gay documented our regular expressions library.
• Peter Housel made more solid progress on our LLVM compiler back-end.
• Dustin Voss improved some aspects of our support for limited collections.
• Ingo Promovicz improved support for locking I/O streams.
• Bruce Mitchener worked on merging run-time libraries to help provide more consistent support for various features across the various compiler back-ends.
• Francesco Ceccon worked on the gobject-introspection bindings and the generator for creating C-FFI bindings for the GTK+ family of libraries.
• Hannes Mehnert addressed some issues in the networking library surrounding localhost connections.
• Andreas Bogk returned from the dead and observed the goings on after a multi-year absence.
• Tom Emerson began investigating providing support for Unicode in Dylan.
• Robert Roland enhanced the sqlite bindings.

Thanks to everyone who participated and we're looking forward to our next hack-a-thon in a couple of months.

All of these changes and much much more will be present in our upcoming 2013.2 release!

There are comments.

Open Dylan has 3 compiler back-ends currently:

• HARP
• C
• LLVM

There are comments.

Method dispatch in Dylan is the process by which the compiler and run-time collaborate to choose the right implementation of a function to call. This can get rather complex as a number of factors are involved in choosing the right method to call and whether that can be done at compile-time or deferred to run-time.

Unfortunately, full generic method dispatch at run-time in Open Dylan is currently not as fast as we would like. This means that when performance issues strike, they may well be due to the overhead of method dispatch.

Discussing and improving the overall performance of method dispatch isn't the subject of this post. That's going to require a fair bit of planning and work before that is resolved.

Instead, we're going to look at what to do when you're experiencing performance problems at particular call sites due to the overhead of method dispatch.

Sometimes, this is readily visible in the profiler:

Here, we can see that the percent-encode method in the uri library is going through dispatch to call member?. (I've translated from the names of the functions in C to their names in Dylan. The name mangling isn't that ...

There are comments.

This begins a new series of blog posts that will continue over the next few months as we say "Good-bye!" to parts of Open Dylan.

Freedom comes when you learn to let go
Creation comes when you learn to say no

  -- Madonna, The Power of Good-Bye

We're beginning a process by which we'll start slimming down the compiler and the libraries, letting go of some major chunks of code, with the goal of improving the hackability of the compiler and enabling us to make new leaps in functionality.

There are comments.

Dylan is often seen as a descendent of the Lisp family of languages. It was designed (and implemented) by people from the Common Lisp world and borrowed lots from Scheme, EuLisp and other Lisp dialects. On the other hand, it was given a syntax from the ALGOL tradition rather than using s-expressions.

It is interesting to compare some of what is present within the Dylan language design with ALGOL though and see if perhaps some of the ALGOL influence wasn't just in the syntax. It is difficult today to know the extent to which ALGOL 68 was a direct influence versus having been filtered through Common Lisp and other languages. After all, Dylan was designed some 25 years or so after ALGOL 68. (At the time of this writing, Dylan itself is over 20 years old.)

It is clear though that many languages have picked up ideas from ALGOL over the years, including languages that were direct influencers of Dylan such as Scheme.

This post isn't intended to say "this concept came from ALGOL" but just to look at some of the interesting similarities.

There are comments.

Dylan is in an unusual position for a programming language.

It has a pretty mature implementation, a specification, and a lot of high quality documentation. It has a long history and many people remember it from the early days of its history when it was being developed at Apple and other institutions.

On the other hand, the current community is fairly small as is the available set of libraries. This is typically a disadvantage, however it can be used to the community's advantage in a couple of ways.

There are comments.

The type system and how it is used is a commonly misunderstood aspect of the Dylan language. Although it lacks some forms of expressiveness in the current incarnation, it also has some features that aren't found in many languages, such as singleton types. It is also very important in helping the compiler to generate faster yet still safe code.

One interesting feature in Dylan is that it is optionally typed. While this is more common today and sometimes has fancy names applied like 'gradually typed', the overall point is the same: Your code can start out untyped and looking like code does in Ruby or Python. However, when you want or need additional performance or correctness guarantees, you can supply type annotations that the compiler can use. The compiler can also infer some types from the values used or other type annotations.

In this post, we'll explain some of the basic concepts of the Dylan type system and show how it is used by the compiler.

There are comments.