Open Dylan 2013.1 released
opendylan.org
opendylan.org
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.
Is the backend of the compiler outputting C or native assembly? Is there a way to use Dylan on ARM/Linux?
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 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!
I've also written most of a porting guide in our Hacker's Guide as well: http://opendylan.org/documentation/hacker-guide/porting.html
Does it support native OS threads or green threads?
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.
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.
Hopefully we'll be making some good headway on things for our next release (which will include ARM Linux support among other things).
Things that stand out to me are the LLVM back end, Coroutines support, Postgres library, and uWSGI binding.
The postgres client library and uWSGI bindings are probably doable within a weekend. Feel like dropping by? :)
let shoe = 5;
let size = 3;
let shoe-size = 10;
shoe-size := shoe-size;
Type names are typically enclosed in '<...>' like '<integer>' (but that's just a convention used everywhere).
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 :-)
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.
Hyphens get reused to mean negation and subtraction, but they aren't operators everywhere.
If that surprises you, you haven't used enough Lisp or Forth.
See http://opendylan.org/documentation/intro-dylan/expressions-v... for more info (note the naming conventions. Those will quickly learn you to discriminate operators from characters used in symbols)