Paul Landes <lan...@mailc.net> writes:
> I actually did consider Clojure, nrepl, Leiningen etc. and I agree on all
> points. The issue for me is it isn't Lisp. It's lisp like and has many of the
> features, but still isn't lisp.
Wikipedia disagrees with you!
There isn't a complete definition of lisp, but functional, untyped,
prefixed and with lots of parenthesis seems to cover it. Clojure isn't
common lisp for sure, but then neither is Elisp.
The biggest single difference is the way functions are called. So
;; elisp
(defvar x 10)
(defun x ()
x)
(x)
;; returns 10
;; clojure
(def x)
(defn x[] x)
(x)
;; returns #<user$x user$x@3f7ebc6c>
where elisp makes more sense. But, the gain for this is:
;; elisp
(defun f (g x)
(g x))
(f (lambda(x) x) 10)
;; crashes
;; clojure
(defn f[g x]
(g x))
(f (fn [x] x) 10)
;; returns 10
As far as I can see, the Java integration is much nicer for Clojure. So
compare this ABCL example, with my attempt at two clojure equivalents
after it.
;; ABCL
(defun void-function (param)
(let* ((class (jclass "Main"))
(intclass (jclass "int"))
(method (jmethod class "addTwoNumbers" intclass intclass))
(result (jcall method param 2 4)))
(format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%"
result)))
;; clojure (two equivalents)
(defn f [param]
(printf
"in f, adding two numbers: %s"
(.addTwoNumbers (Main.) 2 4)))
(defn f [param]
(let [main (Main.)
result (.addTwoNumbers main 2 4)]
(printf "in f, adding two numbers: %s" result)))
Having written quite a lot of Clojure using an Java API underneath, I
think the integration is very nice. The difference is that Clojure was
designed to be tightly integrated with the JVM; ABCL was designed to be
common lisp on a JVM.
There is already a reasonable amount of stuff in Clojure which we could
use. So...
;; fetching javadoc
(use 'clojure.core.javadoc)
(javadoc String)
Nrepl.el provides most of the code that we need to interact already. So,
for instance this is from my own tawny-mode.el which calls clojure (to
call Java). The first function is the key one; all the rest are
subsidiary.
;; elisp calling clojure
(defun tawny-mode-is-coherent ()
(interactive)
(when (tawny-mode-check-for-nrepl-buffer)
(tawny-mode-nrepl-reasoner-eval-string
(format
"(do (require 'tawny.emacs)(tawny.emacs/is-coherent \"%s\"))"
(clojure-find-ns)
))))
(defun tawny-mode-check-for-nrepl-buffer ()
(if (find-if
(lambda (buffer)
(lexical-let ((buffer (get-buffer buffer)))
(equal (nrepl-project-directory-for (nrepl-current-dir))
(buffer-local-value 'nrepl-project-dir buffer))))
nrepl-connection-list)
t
(message
"No nREPL buffer exists. Please use `nrepl-jack-in'")
nil
))
(defun tawny-mode-make-reasoner-response-handler (buffer)
(nrepl-make-response-handler
buffer
(lambda (buffer value)
(tawny-message "For %s: %s" buffer value))
(lambda (buffer value)
(tawny-message "Output: %s %s" buffer value))
(lambda (buffer value)
(tawny-message "Error: %s %s" buffer value))
(lambda (buffer value)
(tawny-message "Complete: %s %s" buffer value))))
> I see this turning into religion very soon, and I really don't want
> that :)
I think we can avoid this. Now that I have written this email, I won't
say more! At the end of the day, the choice is likely to be yours, as I
am not likely to find the time to do more than contribute a little.
It is, of course, absolutely the case that I have an asymmetric
knowledge; I've used clojure a lot since last October, while my closest
exposure to CL is emacs, and I've never used ABCL.
> However, the big thing to me is that at the very minimum the data
> communication is between Emacs and ABCL is still s-expressions. The biggest
> pain point is creating lisp and in beanshell/java and hoping Emacs makes sense
> of it. If both languages speak the same basic same language development should
> prove to be faster and the project easier to maintain.
Sure, it's just a question of how similar. You can manipulate common
lisp or clojure in elisp both as strings or as lisp data structures, and
vice versa.
> There will be those that use an Emacs IDE that will want to use Clojure,
> others JRuby, Jython etc. I can't see adding these other languages in the 0th
> iteration of the new software but I could see abstracting some general API
> that could plug into a JVM and provide interfaces to standard services
> provided (i.e. reflection, template services, wizards, debugging, compiling
> (maven integration), etc). That would have to be a later iteration though.
>
> The idea is to have Emacs fork a JVM that acts a server and binds ports for
> each language. This wouldn't be a command event loop (currently beanshell
> impl), it would be a well defined protocol where a client specifies the
> language and communication parameters. The first and only would be CL and ABCL
> would interpret and respond. Later we could other languages as plugins so if
> you love groovy create your own groovy lang plugin and implement a group of
> services for the JVM to hook into. Given this design bringing other languages
> should be trivial but also give us a way of reusing (at least the core) of the
> services.
This is basically the same as swank -- single Emacs backend, multiple
language backends (even if they are all lisp). Interesting, nrepl is
going in the opposite backend direction -- single language backend,
multiple IDE/editor backends.
> This sounds good on paper, but my gut tells me we'd waste much less time and
> effort if we could just all agree on one language--but I doubt that will
> happen and someone (the one with the most time) will just have to make this
> call.
Yes, I agree. I've no desire to see multiple languages in JDEE; a
pragmatic replacement for beanshell is required, and a JVM hosted lisp
makes a lot of sense. Either clojure or ABCL could fulfil that
requirement.
The secondary points that I raise are important also, though. Having a
goal of replacing all the java so that JDEE would not require a
compilation step, would really simplify the build. And, being able to
launch the JVM hosted from Maven, (as well as without) so that it shared
all the classpath settings, would be a big save.
At this point, the my contribution to the religious war ends! I'll look
forward to what ever is decided.
Phil
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
jdee-devel mailing list
jdee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdee-devel
