-
A high performing Lisp that isn’t on the JVM and isn’t old as hell? /me drools
-
-
The project direction looks like it will be high performing eventually, as opposed to something like Racket which doesn’t have any plans to be natively compiled and isn’t terribly concerned with being blazing fast. Building on LLVM is a big hint that Clasp is going the opposite direction. That being said, I love Racket! <3
Also, SBCL was what I was thinking of when I said old as hell. ;)
-
What about ABCL and RoboVM?
-
I don’t know CL or even ABCL but I made a little progress. I followed this blog post on standalone ABCL jars.
But changed
// Load.loadSystemFile //("greet.lisp", false, false, false); Load.load ("./greet.lisp");Compile with
robovm -forcelinkclasses org.armedbear.lisp.* -verbose -jar greet.jargives me a stack trace I dont understand. The jar does run for me, but still references greet.lisp from the local filesystem, isn’t pulling it as a resource.
https://gist.github.com/anonymous/5d3a41fac14bd749b44e
It looks like ABCL calls
src/org/armedbear/lisp/JavaClassLoader.java 186: return defineClass(name, b, off, len);which RoboVM doesn’t like
Rather than load a
.lispfile, one could precompile to .cls(zt.env)volcano:greet animatronic$ abcl Armed Bear Common Lisp 1.3.1 Java 1.7.0_67 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.402 seconds. Startup completed in 1.866 seconds. Type ":help" for a list of available commands. CL-USER(1): :cf greet.lisp ; Compiling /Users/animatronic/w/robovm/tests/greet/greet.lisp ... ; (DEFUN MAIN ...) ; Wrote /Users/animatronic/w/robovm/tests/greet/greet.abcl (0.212 seconds) CL-USER(2): ^D (zt.env)volcano:greet animatronic$ jar tvf greet.abcl 315 Fri Sep 26 16:06:38 PDT 2014 __loader__._ 1744 Fri Sep 26 16:06:38 PDT 2014 greet_1.cls 3464 Fri Sep 26 16:06:38 PDT 2014 greet_2.cls (zt.env)volcano:greet animatronic$
-
-
-
-
-
This is a really lucid explanation of the differences between the type systems in Go, Rust and Haskell even if the title is unnecessarily controversial.
-
Reminds me of The Uneasy Case for Copyright (Breyer 1970).
as a vim user, i’ve been wasiting time figuring out the best way to do overtone things without emacs.
i want to be able to send snippets of code to a lein repl, and i think i’ve settled on vimux (and tmux)
it works pretty well actually. i tried using it for haskell to interact with ghci (actually, ghci-color) but it doesn’t work so well, because you need to wrap multiline things in “:{ … :}”, and just copying a definition like
doesn’t work, as it needs to be
what i should really be doing is study.
Perhaps you might get farther using vim-ipython combined with IHaskell? I haven’t done it myself (I should try!) but I’ve heard that
vim-ipythonmight work with IHaskell.(Disclaimer: IHaskell is my project, so of course take anything I say about it with a grain of salt :) The vim-ipython author filed some issues at some point that made it seem like it should work with IHaskell just fine.)
i wouldn’t even mind using IHaskell by itself; i’ll give it a try again. i’ve tried it before, but i don’t really like the docker way of running it; and the standard installation hasn’t worked out for me; but i can try again when i have more time.
I wish the vim REPL integration plugins were easier to use. I’ve had heaps of trouble getting IDE-like features to work. I’m currently using haskellmode-vim, which seems to work OK, but as soon as I import a cabal dependency, I can’t load a module directly in ghci and therefore haskellmode-vim’s type inference stuff fails.
yeah; i think if i had a bit of free time i’d probably just sit down and learn emacs (or lighttable)
tpope’s dispatch and fireplace work pretty well if you’re already a tmux user. I’m not gonna pretend that it’s like having an actual emacs repl but it’s not too bad and might actually work really well with overtone!