Personally, I think the Lisp way is more elegant, and it has more
opportunities for optimization. But I think it would be a mistake to
try to graft it onto Ruby. It doesn't match with Ruby's style and
philosophy.
That pretty much covers what I suspected.
What I'd love to see (and I'm not asking for it, because that would be hubris, but I would be incredibly grateful for any answers) is some responses by Lispers saying "This-here code sample shows a technique I've used a lot in Lisp. It's useful for (reducing duplication / exposing simpler APIs / making coffee in the morning). When I'm in Ruby, I really miss the ability to use it."
I agree with Edward, but that doesn't mean Ruby's maxed out, conceptually. We might be able to discover a *different* solution to the same problem.
Really, though, I'm just being lazy, where in good conscience I should just learn Lisp thoroughly and figure this out for myself. So, considering On Lisp and Practical Common Lisp have each been linked to at least twice in this thread, I won't take offense if nobody posts code. (Mind you, I'm not the OP.)
True, but that doesn't contradict what I said, does it? I mean, you can't have Lisp without eval - at least without it a major part would be missing. Or do I have a misconception of Lisp here?
Kind regards
robert
···
Bob Hutchison <hutch@recursive.ca> wrote:
On Sep 27, 2005, at 4:26 PM, Robert Klemme wrote:
I believe early versions were actually interpreted only and you
definitely can have a Lisp interpreter that does no compilation
(you wouldn't want it for speed reasons but it's perfectly
feasible). I still don't view Lisp as a compiled language. As far
as I understand the language the runtime must contain a compiler if
you want compiled code. To me this is a definite hint that
compilation is rather an optimization technique than a feature of
the language (as opposed to C etc.). Am I wrong here?
All of the major implementations, with the exception of CLISP, are
native compilers. I know many, if not all, no longer have
interpreters at all. The only time you ever need to compile at
runtime is if you call eval, load an uncompiled source file, or
change some code on the fly (e.g. in the debugger or shell).
I believe early versions were actually interpreted only and you
definitely can have a Lisp interpreter that does no compilation
(you wouldn't want it for speed reasons but it's perfectly
feasible). I still don't view Lisp as a compiled language. As far
as I understand the language the runtime must contain a compiler if
you want compiled code. To me this is a definite hint that
compilation is rather an optimization technique than a feature of
the language (as opposed to C etc.). Am I wrong here?
All of the major implementations, with the exception of CLISP, are
native compilers. I know many, if not all, no longer have
interpreters at all. The only time you ever need to compile at
runtime is if you call eval, load an uncompiled source file, or
change some code on the fly (e.g. in the debugger or shell).
True, but that doesn't contradict what I said, does it? I mean, you can't have Lisp without eval - at least without it a major part would be missing. Or do I have a misconception of Lisp here?
First, I wasn't trying to contradict you, just clarify the situation a bit.
Second, I think you may have a misconception of lisp. I'm working currently working on a lisp program that is about 10,000 lines of code without a single eval in it. I've never come across a need for it. No matter, eval in LispWorks, for example, compiles things, it doesn't interpret them. I suppose I should ask: in what way is compilation ever not an optimisation? and, in those cases, why don't you think they apply to lisp?
First, I wasn't trying to contradict you, just clarify the situation
a bit.
Ah! Ok, then I probably misread you. I'm sorry.
Second, I think you may have a misconception of lisp. I'm working
currently working on a lisp program that is about 10,000 lines of
code without a single eval in it. I've never come across a need for
it. No matter, eval in LispWorks, for example, compiles things, it
doesn't interpret them. I suppose I should ask: in what way is
compilation ever not an optimisation?
Good question. Of course one could interpret every compiled language -
but not necessarily the other way round. Duh!
and, in those cases, why don't
you think they apply to lisp?
Well, I think my point focused around the fact whether a language allows
for code modification at runtime (regardless of whether you use it or not;
I'm rather trying to grasp the nature of the language if you will). You
can do that with Lisp and as far as I understood it's a core feature of
the language. You can't do that with standard C (well, you *can* but that
typically involves features not part of the language like shared objects).
(A funny consequence seems to be that you can view machine code as a
dynamic language...)
Well, I think my point focused around the fact whether a language allows
for code modification at runtime (regardless of whether you use it or not;
I'm rather trying to grasp the nature of the language if you will). You
can do that with Lisp and as far as I understood it's a core feature of
the language. You can't do that with standard C (well, you *can* but that
typically involves features not part of the language like shared objects).
You are right about run-time changes to lisp being an important capability. The fun thing is that you don't actually need to eval or compile anything inside the program being modified. You have to compile for sure, but that can be done outside by the developer then loaded into the running image -- no eval happens. There are also very interesting things you can do with returning functions from functions that don't require eval (this can be a bit astonishing the first time you see it, and every now and again after the first time Here is a quick example:
(defun make-a-function (n)
(lambda (m) (* n m)))
is returning a compiled run-time generated function (with no eval, not even a hidden one
(A funny consequence seems to be that you can view machine code as a
dynamic language...)
Very dynamic. Every now and again when I was working in assembler (a while ago now we made use of that (in fact, one computer I worked on had instructions built into it that explicitly supported changing the code). These days machine code as a dynamic language comes up every now and again as a 'buffer overrun attack'
Well, I think my point focused around the fact whether a language
allows
for code modification at runtime (regardless of whether you use it
or not;
I'm rather trying to grasp the nature of the language if you
will). You
can do that with Lisp and as far as I understood it's a core
feature of
the language. You can't do that with standard C (well, you *can*
but that
typically involves features not part of the language like shared
objects).
You are right about run-time changes to lisp being an important
capability. The fun thing is that you don't actually need to eval or
compile anything inside the program being modified. You have to
compile for sure, but that can be done outside by the developer then
loaded into the running image -- no eval happens. There are also very
interesting things you can do with returning functions from functions
that don't require eval (this can be a bit astonishing the first time
you see it, and every now and again after the first time Here is
a quick example:
(defun make-a-function (n)
(lambda (m) (* n m)))
is returning a compiled run-time generated function (with no eval,
not even a hidden one
Yeah, that's right. Same for Ruby. No compilation needed for closures.
(A funny consequence seems to be that you can view machine code as a
dynamic language...)
Very dynamic. Every now and again when I was working in assembler (a
while ago now
I remember doing Z80 assember - wow, this was *long* ago!
we made use of that (in fact, one computer I worked
on had instructions built into it that explicitly supported changing
the code). These days machine code as a dynamic language comes up
every now and again as a 'buffer overrun attack'
