I've been seeing OpenDylan pass by on /r/lisp and HN the past few months. I've installed it, and it looks nice, but it could use some maturing and I'm not sure what the advantage over other LISPs is. Can someone explain it to me?
This can be a difficult thing to answer, as choice in programming language can be something very personal in that different things resonate in different ways with each of us.
For me, some of the important things are:
* The language is much smaller and cleaner than Common Lisp (and designed by some of the same people that participated in the CL standardization).
* Because it has a smaller community and installed base at this point in time, it has the freedom to evolve in new directions whereas an existing Lisp is already defined and tied down to what it is (for the most part). (Coroutines would be a nice addition for example.)
* You can produce executables from it and don't have to have a running image.
* The integration of the type system is, for the most part, nice. It is nice to have the ability to have a mix of dynamic and more static typing. (The type system could be better, and that too is an interesting possible future direction.)
* Always using multi-methods and everything being an object and the more powerful dispatch capabilities are quite handy.
* It has a condition system like Common Lisp rather than exceptions.
* The macro system is okay.
* It is nice having multiple return values, #rest parameters and keyword parameters, all cleanly integrated.
* The C-FFI is good.
* Some people like the syntax. I enjoy how readable the code is to me.
* I'm not tied into using the JVM.
Some Lisps have some of the above, some don't. Not everyone might like all of the above, but for me, it is a comfortable fit.
The "HARP" backend outputs native code for x86-linux, x86-freebsd and x86-windows.
The C backend outputs C and works on x86_64-linux, x86_64-freebsd and Mac OS X.
We have an in-progress LLVM backend that will support all of the above platforms and more.
As for ARM/Linux, we have a port in progress for the C backend. In theory, it should work after a cross-compile or using cross-compilation tools, but we haven't quite tried it out yet ourselves (the person doing the port is getting married this weekend and going away for a couple of weeks).
If you would like to help out with Dylan on ARM/Linux, drop by #dylan on FreeNode IRC and I'll work with you. (The hack-a-thon this weekend is a great time for that.)
Otherwise, we plan to have this in the 2013.2 release (whenever that is).
I would love to help, and I'm really interested in compiler development etc, but I have the habit of promising to help out and concluding that I don't have the time to follow through.
I might have a few weeks between projects in August, and if so, I'll try to see if I can help out (but no promises! ;))
I'll definitely join #dylan tomorrow though!
There are two backends, including a C backend. Porting to a UNIX-y platform is pretty easy as I recall. I think I had it running on OS X/PPC after a week of fiddling.
Apple designed the language to ease the move of experimental (typically Lisp or Smalltalk) code into production (where it had to run faster, in less memory, etc). Tey wanted a Lisp that ran as fast and as memory efficient as C, so that they could write the OS in Lisp.
That's why they put a lot of thought into the sealing functionality (http://jim.studt.net/dirm/interim-36.html) and into limited types. For example, you can store a 'integer between zero and a hundred or letter of the alphabet or NULL' in a single byte. Expressing that in C is cumbersome, as you would need wrapper functions or macros, would need to remember using them, etc. A sufficiently advanced Dylan compiler could figure out a representation of its own.
Pascal-like syntax was bolted on later when they tried to bring the compiler to the masses. That, in turn, required serious thinking about the macro system.
And no, that didn't work out. There was a prerelease development environment, but they never managed to get this mainstream.
> And no, that didn't work out. There was a prerelease development environment, but they never managed to get this mainstream.
This was due to internal Apple politics, as Dylan was planed to be the system language for Newton, I don't remember any longer the full story but other group ended up getting the project.
It's been a while since I've read the paper, but technical aspects like runtime size of binaries led to a bytecode compiled language like Smalltalk, leading to NewtonScript.
The LLVM backend and Coroutines support are a bit more than would fit into a hack-a-thon. The LLVM backend is actually making good progress with someone who has been working on it for a long time (with some breaks).
The postgres client library and uWSGI bindings are probably doable within a weekend. Feel like dropping by? :)
Just out of curiosity, is there a reason for allowing operators in variable names? I've just glanced over the introduction, so if I got something wrong here, sorry. But it seems like this would work?
let shoe = 5;
let size = 3;
let shoe-size = 10;
shoe-size := shoe-size;
I suggest not characterizing this as "allowing operators in variable names" any more than you'd call it "allowing keywords in variable names" that in most languages you can have variables called "life", "athena", "door_count" and "ended" even if "if", "then", "do" and "end" are keywords.
(Does C "allow operators in other operators" because it has both "+" and "++"?)
Rather: in Dylan, more characters than in (say) C are treated as ordinary constituent-of-identifier characters, with the consequences that (1) you can have things like hyphens in your names and (2) you more often have to use actual whitespace to delimit operators. ("shoe-size := shoe - size".)
This is traditional in Lispy languages, in most of which #2 isn't much of a drawback anyway because of the prefix syntax (in C you can say "a=b-c" if compactness is important to you, but obviously you're not going to write "=a-bc" in a prefix language or "bc-a=" in a postfix one). Dylan is unusual in preferring #1 over #2 despite using infix syntax.
White space is required around operators. This allows the names of bindings (variables, methods or whatever) to be very flexible. Things that represent a boolean can end in '?'. Operations that mutate can end in '!'. In the Objective C bridge that I'm working on, I make use of '/' like: 'objc/class-responds-to-selector'.
Type names are typically enclosed in '<...>' like '<integer>' (but that's just a convention used everywhere).
Ah, ok, I had not seen the part about the mandatory whitespaces. I still think it has the potential to confuse, so if I were to write in languages that allow dashes, I'd probably still avoid them where possible (can't see the advantage over using underscores instead). Anyway, thanks for the info.
Having plenty of experience both with languages that do and do not allow "operators" in variable names, it's not actually confusing in practice. You quickly learn that whitespace is very significant in those languages, and then you read them differently. This isn't any different than indentation in Python, line breaks in Ruby, or sigils in C++.
I haven't really programmed in Lisp or Dylan, but the code I read certainly seemed the better because of the punctuation in function names. It gets denser, but stays readable. A question mark signals 'returns boolean' just as strong as a "Is" or "Has" prefix, and there AFAIK is nothing in other languages that signals "modifies its arguments" as strong as a ! suffix.
I also find that Dylan's convention of using brackets in class names rapidly grows on you. But maybe that requires working in Forth as a warming up.
And of course, hyphens not only look better than underscores, they are easier to type, too :-)
