This looks cool enough but it would need a big community to really change the common lisp landscape (in my opinion). I wonder how the lazy sequence support stacks up to Clojure, Haskell, etc. support.
One difficulty with promoting a more modern layer to common lisp is that Clojure is already such a productive and practical language. I have written a few common lisp books, and remain a fan of the language, and an upgrade does sound good.
I am curious to hear the opinions of the heavy hitters in the common lisp world.
> I wonder how the lazy sequence support stacks up to Clojure, Haskell, etc. support.
A bit of a tangent, but I've been looking at the series library[0] recently. It makes it possible to write functional style code which is compiled into a loop for efficiency. For example:
(defun integers ()
"Returns a series of all of the integers."
(declare (optimizable-series-function))
(scan-range :from 1))
(defun squares ()
"Returns a series of all of the square numbers."
(declare (optimizable-series-function))
(map-fn t
(lambda (x) (* x x))
(integers)))
(defun sum-squares (n)
"Returns the sum of the first N square numbers."
(collect-sum (subseries (squares) 0 k)))
Although the above definition of sum-squares seems like it would be inefficient, it is roughly the same as the following:
(defun sum-squares (n)
"Returns the sum of the first N square numbers."
(loop for i from 1 to n
for square = (* i i)
sum square))
I find it pretty awesome that it is possible to write code that is efficient and functional like that, but I guess series is a bit too magical to be put to actual use.
I can understand the reasons why people prefer to target the CLR/JVM/LLVM/BEAM/Name-your-favorite-vm but I yearn for more compiled-to-native-languages such as Golang. As attractive as partially-compiled/interpretated languages are, I simply do not enjoy creating programs in a language that can be decompiled to source so easily. We need more languages that have decent performance instead of having to drop down to pointer optimizing in C wherever we need some performance. A functional Fortran would certainly be nice...
Keep in mind that's with full run-time type checking and other nice debugging features. You can hint the compiler to turn these things off in your hardened code sections for even smaller, tighter code.
By functional Fortran, do you mean like a "functional programming language" or "more productive Fortran"? As one who has developed in Fortran before, I would also like to see enhanced functional capabilities, as well as a more productive way to write code. I have spent so much time on declaring variables and function arguments over and over across subroutines that it becomes quite a pain. To avoid writing many subroutine interfaces, I also tend to put everything in a single module. My dream is to combine the expressiveness of Lisp with the numerical performance and memory efficiency of Fortran and C.
I had not heard of Fortress before. It seems that Oracle's sponsorship of the project ended in 2012. Guy Steele emphasizes the difficulty of implementing Fortress's type system on virtual machines. [1]
Sadly, Julia will not produce stand-alone executables in the foreseeable future. It's nothing more than a bit of native glue between two Python scripts. The main acceptance group doesn't use it for production, only in the lab.
One difficulty with promoting a more modern layer to common lisp is that Clojure is already such a productive and practical language. I have written a few common lisp books, and remain a fan of the language, and an upgrade does sound good.
I am curious to hear the opinions of the heavy hitters in the common lisp world.