From: Pascal J. Bourguignon
Subject: Re: [ANN] New posting on Codeaholic: [newLISP] reverse-find
Date:
Message-ID: <87ocv5j4s8.fsf@informatimago.com>
axtens <············@gmail.com> writes:
> http://codeaholic.blogspot.com/2009/04/newlisp-reverse-find.html
Oh! My poor friend, that must hurt!
Here is how to write it so it runs on normal lisps (those lisps who
share in common features so your code may be run on any of them):
(defun reverse-find (subseq sequence)
(search subseq sequence :from-end t))
(defun subseq* (sequence start length)
(subseq sequence start (+ start length)))
(let ((target "dog")
(sentence "My first dog's fleas are on my second dog's blanket"))
(values (subseq* sentence (reverse-find target sentence) (length target))
(subseq sentence (reverse-find target sentence))
(subseq sentence (search target sentence))))
--> "dog" ;
"dog's blanket" ;
"dog's fleas are on my second dog's blanket"
(search "a" "b")
--> NIL
(reverse-find "a" "b")
--> NIL
(let ((result (reverse-find target sequence)))
(unless result
(print "not found")))
--
__Pascal Bourguignon__
http://www.informatimago.com
On Apr 9, 10:11 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> axtens <············@gmail.com> writes:
> >http://codeaholic.blogspot.com/2009/04/newlisp-reverse-find.html
>
> Oh! My poor friend, that must hurt!
>
> Here is how to write it so it runs on normal lisps (those lisps who
> share in common features so your code may be run on any of them):
Pascal,
Thanks very much for sharing that with me. Please, could you repost it
as a comment on the weblog so that I can publish it for all to see.
Kind regards,
Bruce.
From: William James
Subject: Re: [ANN] New posting on Codeaholic: [newLISP] reverse-find
Date:
Message-ID: <grpc3f0fh9@enews2.newsguy.com>
Pascal J. Bourguignon wrote:
> axtens <············@gmail.com> writes:
> > http://codeaholic.blogspot.com/2009/04/newlisp-reverse-find.html
>
> Oh! My poor friend, that must hurt!
>
> Here is how to write it so it runs on normal lisps (those lisps who
> share in common features so your code may be run on any of them):
>
>
> (defun reverse-find (subseq sequence)
> (search subseq sequence :from-end t))
>
> (defun subseq* (sequence start length)
> (subseq sequence start (+ start length)))
>
> (let ((target "dog")
> (sentence "My first dog's fleas are on my second dog's
> blanket")) (values (subseq* sentence (reverse-find target sentence)
> (length target)) (subseq sentence (reverse-find target
> sentence)) (subseq sentence (search target sentence))))
>
> --> "dog" ;
> "dog's blanket" ;
> "dog's fleas are on my second dog's blanket"
>
>
>
> (search "a" "b")
> --> NIL
> (reverse-find "a" "b")
> --> NIL
>
>
> (let ((result (reverse-find target sequence)))
> (unless result
> (print "not found")))
That looks very painful.
Ruby:
"My first dog's fleas are on my second dog's blanket".rindex "dog"
==>38
On Apr 11, 3:07 am, "William James" <·········@yahoo.com> wrote:
> Ruby:
>
> "My first dog's fleas are on my second dog's blanket".rindex "dog"
> ==>38
Believe me: it's far more fun when you implement it.
On Apr 11, 9:07 am, "William James" <·········@yahoo.com> wrote:
> Pascal J. Bourguignon wrote:
> > axtens <············@gmail.com> writes:
> > >http://codeaholic.blogspot.com/2009/04/newlisp-reverse-find.html
>
> > Oh! My poor friend, that must hurt!
>
> > Here is how to write it so it runs on normal lisps (those lisps who
> > share in common features so your code may be run on any of them):
>
> > (defun reverse-find (subseq sequence)
> > (search subseq sequence :from-end t))
>
> > (defun subseq* (sequence start length)
> > (subseq sequence start (+ start length)))
>
> > (let ((target "dog")
> > (sentence "My first dog's fleas are on my second dog's
> > blanket")) (values (subseq* sentence (reverse-find target sentence)
> > (length target)) (subseq sentence (reverse-find target
> > sentence)) (subseq sentence (search target sentence))))
>
> > --> "dog" ;
> > "dog's blanket" ;
> > "dog's fleas are on my second dog's blanket"
>
> > (search "a" "b")
> > --> NIL
> > (reverse-find "a" "b")
> > --> NIL
>
> > (let ((result (reverse-find target sequence)))
> > (unless result
> > (print "not found")))
>
> That looks very painful.
>
> Ruby:
>
> "My first dog's fleas are on my second dog's blanket".rindex "dog"
> ==>38
Hello there.... You are late with your homework.
Cheers
--
Marco
From: =?UTF-8?B?QW5kcsOpIFRoaWVtZQ==?=
Subject: Re: [ANN] New posting on Codeaholic: [newLISP] reverse-find
Date:
Message-ID: <grr4n1$df3$1@news.motzarella.org>
William James schrieb:
> Pascal J. Bourguignon wrote:
>
>> axtens <············@gmail.com> writes:
>>> http://codeaholic.blogspot.com/2009/04/newlisp-reverse-find.html
>> Oh! My poor friend, that must hurt!
>>
>> Here is how to write it so it runs on normal lisps (those lisps who
>> share in common features so your code may be run on any of them):
>>
>>
>> (defun reverse-find (subseq sequence)
>> (search subseq sequence :from-end t))
>>
>> (defun subseq* (sequence start length)
>> (subseq sequence start (+ start length)))
>>
>> (let ((target "dog")
>> (sentence "My first dog's fleas are on my second dog's
>> blanket")) (values (subseq* sentence (reverse-find target sentence)
>> (length target)) (subseq sentence (reverse-find target
>> sentence)) (subseq sentence (search target sentence))))
>>
>> --> "dog" ;
>> "dog's blanket" ;
>> "dog's fleas are on my second dog's blanket"
>>
>>
>>
>> (search "a" "b")
>> --> NIL
>> (reverse-find "a" "b")
>> --> NIL
>>
>>
>> (let ((result (reverse-find target sequence)))
>> (unless result
>> (print "not found")))
>
> That looks very painful.
>
> Ruby:
>
> "My first dog's fleas are on my second dog's blanket".rindex "dog"
> ==>38
It's not really much longer in CL:
(search "dog" "My first dog's fleas are on my second dog's blanket"
:from-end t)
Only this ":from-end t" adds a bit to the length. But I don't see that
this would reduce the productivity of a programmer.
The other code that Pascal provided were just some use cases for more
realistic scenario.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
On Apr 9, 10:54 am, axtens <············@gmail.com> wrote:
> G'day everyone
>
> http://codeaholic.blogspot.com/2009/04/newlisp-reverse-find.html
Gotta say I'm perplexed by quoted identifiers in newLisp's set
expressions. One more stinker.
On Apr 10, 1:08 pm, namekuseijin <············@gmail.com> wrote:
> Gotta say I'm perplexed by quoted identifiers in newLisp's set
> expressions. One more stinker.
Can you unpack that comment for me? Please understand that I am a Lisp-
naive. Clearly something has made you, a Lisp veteran, cringe. I would
really like to know why.
Kind regards,
Bruce.
On Fri, 10 Apr 2009 08:28:28 -0700, axtens wrote:
> On Apr 10, 1:08 pm, namekuseijin <············@gmail.com> wrote:
>> Gotta say I'm perplexed by quoted identifiers in newLisp's set
>> expressions. One more stinker.
>
> Can you unpack that comment for me? Please understand that I am a Lisp-
> naive. Clearly something has made you, a Lisp veteran, cringe. I would
> really like to know why.
He is talking about things like
(set 'reverse-find
in your code. Compare to Pascal's CL version and you will see why
this makes CL'ers puke.
Tamas
On Apr 10, 12:04 pm, Tamas K Papp <······@gmail.com> wrote:
[...]
> He is talking about things like
> (set 'reverse-find
> in your code.
Well,
(set 'foo 'bar)
is valid, if deprecated on somewhat grotty, Common Lisp; it's just
equivalent to
(setf (symbol-value 'foo) 'bar)
Despite the fact tha newLISP lacks scads of features necessary to make
it a remotely worthwhile Lisp dialect, it at least has SETF, and using
SET where you should use SETQ or SETF is a classic newbie mistake in
Common Lisp, too.
Then again, one wonders why a "new" dialect of Lisp (or even LISP)
would cling to that particular piece of historical cruft while
dreaming up a novel (not to mention warped) definition for "cons".
Cheers,
Pillsy
axtens <············@gmail.com> writes:
> On Apr 10, 1:08�pm, namekuseijin <············@gmail.com> wrote:
>> Gotta say I'm perplexed by quoted identifiers in newLisp's set
>> expressions. �One more stinker.
>
> Can you unpack that comment for me? Please understand that I am a Lisp-
> naive. Clearly something has made you, a Lisp veteran, cringe. I would
^^^^^^^^^^^^
Note that the chance that a Lisp veteran does not use his/her real name is
quite small. OTOH, the chance that a child or a troll hides behind a
pseudonym is quite large.
Nicolas
On Apr 10, 1:12 pm, Nicolas Neuss <········@math.uni-karlsruhe.de>
wrote:
> axtens <············@gmail.com> writes:
> > On Apr 10, 1:08 pm, namekuseijin <············@gmail.com> wrote:
> >> Gotta say I'm perplexed by quoted identifiers in newLisp's set
> >> expressions. One more stinker.
>
> > Can you unpack that comment for me? Please understand that I am a Lisp-
> > naive. Clearly something has made you, a Lisp veteran, cringe. I would
>
> ^^^^^^^^^^^^
> Note that the chance that a Lisp veteran does not use his/her real name is
> quite small. OTOH, the chance that a child or a troll hides behind a
> pseudonym is quite large.
I'm no Lisp veteran nor a troll, but I still puke at newLisp anyway.
I'd be far less unease at it if they chose a more suitable name, like
Shizznit Lisp or something...
I'm 34 but enjoy anonymity best.
On Apr 10, 5:20 pm, namekuseijin <············@gmail.com> wrote:
> I'm no Lisp veteran nor a troll, but I still puke at newLisp anyway.
> I'd be far less unease at it if they chose a more suitable name, like
> Shizznit Lisp or something...
but everyone knows that common lisp is the shizznit...
;^)
On Apr 11, 1:52 am, Raffael Cavallaro <················@gmail.com>
wrote:
> On Apr 10, 5:20 pm, namekuseijin <············@gmail.com> wrote:
>
> > I'm no Lisp veteran nor a troll, but I still puke at newLisp anyway.
> > I'd be far less unease at it if they chose a more suitable name, like
> > Shizznit Lisp or something...
>
> but everyone knows that common lisp is the shizznit...
>
> ;^)
Yeah, but everyone also knows Lisp is dead, except when they find out
about this new-fangled scripting language with terrible performance
and loads of wrappers around native libs and it happens to be called
newLisp, so they think it's cool and hip.
From: Kazimir Majorinc
Subject: Re: New posting on Codeaholic: [newLISP]
Date:
Message-ID: <op.ur87h9tg1cfios@kazimir-pc>
On Sat, 11 Apr 2009 06:59:40 +0200, namekuseijin <············@gmail.com>
wrote:
>
> Yeah, but everyone also knows Lisp is dead, except when they find out
> about this new-fangled scripting language with terrible performance
> and loads of wrappers around native libs and it happens to be called
> newLisp, so they think it's cool and hip.
Hm ... I see this thread turned into another general Common
Lisp vs Newlisp thread. Although I do not see much point
in restarting pretty much the same claims all over again, I
hope that readers will understand that it is not really good
idea to leave such sort of comments unchallenged, so I'll cut
and paste my (actually fairly recent) claims explaining why
I actually use Newlisp.
==============
I started using Newlisp after I used other Lisp dialects few
years, mostly because of few code=data related features not
available in other languages:
* Unrestricted eval that works for local and global variables and
doesn't require additional running time.
(In almost all Lisp implementation, code containing eval is many
times (up to 1500+ times) slower than same code out of eval)
[see link below]
* Dynamic scope. Because of that, in Newlisp one can define
functions equally powerful as macros - for example, I defined
function IF - standard example why one need macros in some
Lisp dialects.
Newlisp supports lexical scope in the form of contexts.
* Newlisp macros are actually fexprs, i.e. fexprs are not expanded
during compile time, but evaluated during during runtime. Fexprs
are simpler, and slower in normal code, but faster if used inside
of eval (macro expansion inside of eval is very slow).
Additionally, Newlisp macros are the first class citizens, so
one can use these as values, apply or map during runtime.
Macros can be anonymous.
* Functions and macros evaluate to their own definitions,
so one can not only use, apply and map functions (and macros)
during runtime, but he can also analyze and mutate functions
(and macros) during runtime.
These are not just any improvements, but improvements in
metaprogramming, code=data paradigm, and that paradigm is
specificity of Lisp. These features are not emphasized in
the introductory materials, but it is decision of the author
to present the language primarily as simple and practical,
suitable and interesting for wide number of programmers.
The majority of potential users are not primarily interested
in fexpr vs macros issue, but in practical side.
There are many other innovations, like FOOP - functional
object oriented programming, unification with occur check,
regular expressions, basic statistical functions ...
I agree that name is not the most fortunate, but it is not
that important. Generally, author of Newlisp is very helpful
person, and frequently accept requests for features.
============
For one comparison between Common Lisp and Newlisp macros:
http://kazimirmajorinc.blogspot.com/2009/01/challenged-by-common-lispers.html
============
For interesting case how Common Lisp style macros in one
special, but important case actually hurt performances:
http://kazimirmajorinc.blogspot.com/2009/04/on-macro-expansion-evaluation-and.html
--
Blog: http://kazimirmajorinc.blogspot.com
WWW: http://www.instprog.com
On Apr 11, 11:19 pm, "Kazimir Majorinc" <·····@email.address> wrote:
> For interesting case how Common Lisp style macros in one
> special, but important case actually hurt performances:
>
> http://kazimirmajorinc.blogspot.com/2009/04/on-macro-expansion-evalua...
If once considers it "important" to macroexpand the exact same piece
of code 177000 times (not an exaggeration, this is the actual
"important" activity to which KM refers).
On the other hand, if one thinks it more sane to macroexpand
parameterized code once, compile it once, and call it 177000 times
with different parameters, then common lisp is far faster than
newlisp.
KM fails to understand runtime code generation and execution in a
compiled language and performs "tests" in which common lisp is
crippled by requiring it to operate in the same broken fashion as
newlisp.
Raffael Cavallaro wrote:
> If once considers it "important" to macroexpand the exact same piece
> of code 177000 times (not an exaggeration, this is the actual
> "important" activity to which KM refers).
>
> On the other hand, if one thinks it more sane to macroexpand
> parameterized code once, compile it once, and call it 177000 times
> with different parameters, then common lisp is far faster than
> newlisp.
>
> KM fails to understand runtime code generation and execution in a
> compiled language and performs "tests" in which common lisp is
> crippled by requiring it to operate in the same broken fashion as
> newlisp.
I see your point, but this is not an unfair test. This is semantics
Common Lisp does not support as well as newlisp, and I think that's
his point. Also, the "broken" feature of newlisp you're talking
about here doesn't have to be implemented in a way that's broken.
You're talking about implementations and languages, and as a result
of breakage in implementations and languages rejecting a fundamental
idea which is not broken.
The newlisp implementation is, as you point out, in fact broken
because it does treat that as a fexpr and expand it then convert
it into executable form 177000 times 176999 of which are useless
repetition, calling 'eval' on each which is horribly slow compared
to normal function evaluation.
The newlisp language is also broken because of dynamic scope
and One-Reference-only memory management. Finally the semantics
of its first-class macros are also problematic because it doesn't
keep close enough track of environments and as a result nested
macros can have very surprising and unexpectedly variable
semantics.
But the idea of first-class entities which are also first-order,
which newlisp has and common lisp and scheme don't, doesn't have
to come in a broken language with a broken implementation, and
doesn't deserve to be rejected out of hand just because the most
visible example stinks.
Between inlining and partial evaluation, neither of which
the newlisp implementation does, it's possible to treat first-
class macros as efficiently as regular macros in all cases
where you *could* have used regular macros. IOW, it's possible
to do this without major lossage compared to the current
situation of common lisp and scheme. The only things that
remain expensive are things you just can't do otherwise.
And when you think about it, a first-class entity - one that can
be stored in variables, returned from functions, passed as an
argument to higher-order functions, etc ... That's a function.
Once you make macros first-class, the distinction between macros
and functions no longer exists. The fact that in common lisp
and scheme it isn't implementable as a function is an artifact
of eager-evaluation calling semantics.
In the context of a function, the mental model of a macro is
just a way to specify function behavior. If you have a call
semantics that's sufficiently general, the function behaviors
are implementable and behavior specified using the macro model
is at least mostly compilable. You don't have to expand code
and eval each time you use it, you just have to get the
resulting behavior implemented.
Your call frames will have to change; you're going to have to
pass a lot of environments (one for each argument I think to
avoid surprising semantics when composed, plus the static pointer
from the call site) and put the evaluation of the arguments
under the control of the called function.
Bear
On Apr 12, 12:36 pm, Ray Dillinger <····@sonic.net> wrote:
> Also, the "broken" feature of newlisp you're talking
> about here doesn't have to be implemented in a way that's broken.
Which would matter if newlisp were a language standard with multiple
implementations, but it isn't. The only think we can reasonably talk
about when we discuss newlisp is the existing implementation.
Otherwise we're discussing the merits of fexprs in the abstract, which
is orthogonal to how poorly newlisp happens to be implemented.
From: Kazimir Majorinc
Subject: Re: New posting on Codeaholic: [newLISP]
Date:
Message-ID: <op.usazva111cfios@kazimir-pc>
Raffael Cavallaro wrote:
> If once considers it "important" to macroexpand the exact same piece
> of code 177000 times (not an exaggeration, this is the actual
> "important" activity to which KM refers).
The purpose of that loop is discussed in post[1]. As Gabriel wrote
in "Performance and evaluation of Lisp systems."
"Often a single operation is too fast to time directly, and
therefore must be performed many times; the total time is
then used to compute the speed of the operation."
It's typical for benchmarks and strange you discuss it. Oh, well ...
[1]
http://kazimirmajorinc.blogspot.com/2009/04/on-macro-expansion-evaluation-and.html
--
Blog: http://kazimirmajorinc.blogspot.com
WWW: http://www.instprog.com
On Apr 12, 11:29 pm, "Kazimir Majorinc" <·····@email.address> wrote:
> Raffael Cavallaro wrote:
> > If once considers it "important" to macroexpand the exact same piece
> > of code 177000 times (not an exaggeration, this is the actual
> > "important" activity to which KM refers).
>
> The purpose of that loop is discussed in post[1]. As Gabriel wrote
> in "Performance and evaluation of Lisp systems."
>
> "Often a single operation is too fast to time directly, and
> therefore must be performed many times; the total time is
> then used to compute the speed of the operation."
>
> It's typical for benchmarks and strange you discuss it. Oh, well ...
That's not the point at all. The point is that you're comparing a
slow scripting implementation with a fast compilable implementation by
not compiling the program in the fast implementation at all. And thus
you bring it down to newLisp level where it performs worse because
that's not its goal. Like Tamas pointed out in the other post:
newLisp "seems" to have fast eval because it's performance overall is
akin to what you achieve with eval, at all times.
newLisp is childish, perhaps it'll mature sometime... but, yeah, the
FFI bridge looks nice.
On Apr 13, 10:52 am, namekuseijin <············@gmail.com> wrote:
> That's not the point at all. The point is that you're comparing a
> slow scripting implementation with a fast compilable implementation by
> not compiling the program in the fast implementation at all. And thus
> you bring it down to newLisp level where it performs worse because
> that's not its goal. Like Tamas pointed out in the other post:
> newLisp "seems" to have fast eval because it's performance overall is
> akin to what you achieve with eval, at all times.
Precisely. If KM could provide some realistic example of a case where
it is *necessary* to eval a piece of code many times rather than
macroexpand it once (or even several times) and call it many times
with varying parameters, then he might have a reasonable point. He
tried to do this with his at-least fexpr/macro, but was quickly
answered by several common lisp versions that didn't require access to
run-time values at all (i.e., that could be implemented as macros and
compiled before run time).
Absent a compelling example he's merely demonstrating that newlisp is
better than common lisp at something no one realistically ever needs
to do. We've already seen that common lisp if far faster at many tasks
that people realistically need to do than newlisp is. In order for
KM's point to hold he must demonstrate a class of tasks that can
*only* be achieved by repeated eval. So far he has yet to show one
realistic example, much less an entire class.
On Mon, 13 Apr 2009 08:15:39 -0700, Raffael Cavallaro wrote:
> On Apr 13, 10:52 am, namekuseijin <············@gmail.com> wrote:
>
>> That's not the point at all. The point is that you're comparing a slow
>> scripting implementation with a fast compilable implementation by not
>> compiling the program in the fast implementation at all. And thus you
>> bring it down to newLisp level where it performs worse because that's
>> not its goal. Like Tamas pointed out in the other post: newLisp
>> "seems" to have fast eval because it's performance overall is akin to
>> what you achieve with eval, at all times.
>
> Precisely. If KM could provide some realistic example of a case where it
> is *necessary* to eval a piece of code many times rather than
> macroexpand it once (or even several times) and call it many times with
> varying parameters, then he might have a reasonable point. He tried to
> do this with his at-least fexpr/macro, but was quickly answered by
> several common lisp versions that didn't require access to run-time
> values at all (i.e., that could be implemented as macros and compiled
> before run time).
>
> Absent a compelling example he's merely demonstrating that newlisp is
> better than common lisp at something no one realistically ever needs to
> do. We've already seen that common lisp if far faster at many tasks that
> people realistically need to do than newlisp is. In order for KM's point
> to hold he must demonstrate a class of tasks that can *only* be achieved
> by repeated eval. So far he has yet to show one realistic example, much
> less an entire class.
But the whole newLisp scene is surreal. People who don't understand Lisp
and don't have the skills to implement a compiler or a decent macro
system invent a "new" language, and then argue that the deficiencies are
in fact advantageous. It is like arguing that the fact that the Elbonian
Jet Aircraft can't fly is a good thing, because that way it won't crash.
From this point on discussion about newLisp has less to do with
programming language design than psychology -- the inventors of newLisp
did extremely dumb things that would not be excused even for a CS
freshman, but admitting that is impossible for them now, so mere inertia
keeps them going.
This is very sad, as people who have the initiative to invent something
new (nevermind that it is fucked up, we all make mistakes) have the
potential for achieving something -- provided that they are willing to
learn from mistakes and abandon stupid ideas.
Tamas
On Apr 13, 1:17 pm, Tamas K Papp <······@gmail.com> wrote:
> On Mon, 13 Apr 2009 08:15:39 -0700, Raffael Cavallaro wrote:
> > On Apr 13, 10:52 am, namekuseijin <············@gmail.com> wrote:
>
> >> That's not the point at all. The point is that you're comparing a slow
> >> scripting implementation with a fast compilable implementation by not
> >> compiling the program in the fast implementation at all. And thus you
> >> bring it down to newLisp level where it performs worse because that's
> >> not its goal. Like Tamas pointed out in the other post: newLisp
> >> "seems" to have fast eval because it's performance overall is akin to
> >> what you achieve with eval, at all times.
>
> > Precisely. If KM could provide some realistic example of a case where it
> > is *necessary* to eval a piece of code many times rather than
> > macroexpand it once (or even several times) and call it many times with
> > varying parameters, then he might have a reasonable point. He tried to
> > do this with his at-least fexpr/macro, but was quickly answered by
> > several common lisp versions that didn't require access to run-time
> > values at all (i.e., that could be implemented as macros and compiled
> > before run time).
>
> > Absent a compelling example he's merely demonstrating that newlisp is
> > better than common lisp at something no one realistically ever needs to
> > do. We've already seen that common lisp if far faster at many tasks that
> > people realistically need to do than newlisp is. In order for KM's point
> > to hold he must demonstrate a class of tasks that can *only* be achieved
> > by repeated eval. So far he has yet to show one realistic example, much
> > less an entire class.
>
> But the whole newLisp scene is surreal. People who don't understand Lisp
> and don't have the skills to implement a compiler or a decent macro
> system invent a "new" language, and then argue that the deficiencies are
> in fact advantageous. It is like arguing that the fact that the Elbonian
> Jet Aircraft can't fly is a good thing, because that way it won't crash.
>
> From this point on discussion about newLisp has less to do with
> programming language design than psychology -- the inventors of newLisp
> did extremely dumb things that would not be excused even for a CS
> freshman, but admitting that is impossible for them now, so mere inertia
> keeps them going.
That's why I wish they gave up on newLisp as a name in favor of
something more suitable like shizznitLisp. Because there are many
ways to improve on Lisp to make it truly *new*, none of them involving
making it dumber and slower. Clojure should have far more right to
that moniker...
From: Kazimir Majorinc
Subject: Re: New posting on Codeaholic: [newLISP]
Date:
Message-ID: <op.usddnacc1cfios@kazimir-pc>
On Mon, 13 Apr 2009 17:15:39 +0200, Raffael Cavallaro
<················@gmail.com> wrote:
>> That's not the point at all. �The point is that you're comparing a
>> slow scripting implementation with a fast compilable implementation by
>> not compiling the program in the fast implementation at all. �And thus
>> you bring it down to newLisp level where it performs worse because
>> that's not its goal. �Like Tamas pointed out in the other post:
>> newLisp "seems" to have fast eval because it's performance overall is
>> akin to what you achieve with eval, at all times.
>
> Precisely.
CL problem is not interpretation, but macroexpansion during runtime.
It is not just "brought down" to interpreted language level; _in this
particular kind of use_, CL is much slower: 25-1000+ times in my
example, and I can think about much worse.
Oh, well, I think that at this point reader of this thread has
enough information to make his own conclusion.
--
Blog: http://kazimirmajorinc.blogspot.com
WWW: http://www.instprog.com
On Apr 14, 5:22 am, "Kazimir Majorinc" <·····@email.address> wrote:
[...]
> Oh, well, I think that at this point reader of this thread has
> enough information to make his own conclusion.
newLISP: doing pointless things very fast!
Cheers,
Pillsy
On Apr 14, 5:22 am, "Kazimir Majorinc" <·····@email.address> wrote:
> CL problem is not interpretation, but macroexpansion during runtime.
> It is not just "brought down" to interpreted language level; _in this
> particular kind of use_, CL is much slower: 25-1000+ times in my
> example, and I can think about much worse.
(MACROEXPAND '(LAMBDA (I) (DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0)
(DEBUG 0))) (DECLARE (FIXNUM I)) (AT-LEAST 6 T (IF (> I 0) T NIL) I
NIL NIL NIL T NIL NIL NIL NIL NIL T NIL NIL NIL NIL NIL T NIL NIL NIL
NIL NIL))) took 22 microseconds (0.000022 seconds) to run
So doing a runtime macroexpansion will add less than a ten-thousandth
of a second to your program. This is why your point is irrelevant - if
you know how to program in common lisp, you're only going to do this
macroexpansion *once*, even for runtime generated code. If you do this
macroexpansion 177000 times you don't understand how to use common
lisp.
>
> Oh, well, I think that at this point reader of this thread has
> enough information to make his own conclusion.
I think Pillsy has the last word on that below:
"newLISP: doing pointless things very fast!"
On Apr 12, 10:29 pm, "Kazimir Majorinc" <·····@email.address> wrote:
> Raffael Cavallaro wrote:
> > If once considers it "important" to macroexpand the exact same piece
> > of code 177000 times (not an exaggeration, this is the actual
> > "important" activity to which KM refers).
>
> The purpose of that loop is discussed in post[1]. As Gabriel wrote
> in "Performance and evaluation of Lisp systems."
>
> "Often a single operation is too fast to time directly, and
> therefore must be performed many times; the total time is
> then used to compute the speed of the operation."
>
> It's typical for benchmarks and strange you discuss it. Oh, well ...
It is typical for benchmarks to require that some task be accomplished
many times in order to get an accurate timing. It is not typical for
benchmarks to require that said task be accomplished in some broken
fashion.
It is a reasonable benchmark of a compiled language to see how long it
takes to execute something many times. It is not a reasonable
benchmark of a compiled language to see how long it takes to interpret
code many times that it could just as easily have compiled once and
subsequently executed many times. IOW your so-called benchmarks
intentionally require common lisp implementations to be used in ways
that no sane common lisp programmer would ever use the language.
You fall into the trap of believing that because newlisp has no other
choice but to repeatedly eval code at runtime that common lisp needs
to do this as well.But common lisp code can be macroexpanded and
compiled before it is executed, even when that common lisp code is
generated at runtime.
Moreover, as I've pointed out previously, your own benchmarks are self-
contradictory. If you generate a piece of code at runtime and execute
it once then it cannot possibly matter how long its macroexpansion
takes. On the other hand, if you're going to run it many times, then
the interpreted (i.e., eval-based) implementation most certainly
loses. You can't have it both ways: Either its a one-off and
macroexpansion time is completely lost in the total time it takes the
program to run, or it must be executed many times, and the compiled
version leaves the interpreted version in the dust. This is why your
so-called benchmarks are just silly.