Have you seen the shootout recently?:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
times faster than Java (client), and is finally as fast as Ocaml.
I'm pretty sure that if the SBCL team continue to work, it will become
one of the fastest language implementation, very close to C++ itself.
Thank you for your work!
On Tue, 24 Jun 2008 22:12:35 -0700 (PDT), Javier <·······@gmail.com> said:
| Have you seen the shootout recently?:
Not to diminish the achievements of all who contribute to SBCL, of
course---
Besides Shakespeare's works, Lewis Carroll's also have a quote for
everything, more or less:
"Are five nights warmer than one night, then?" Alice ventured to
ask.
"Five times as warm, of course."
"But they should be five times as _cold_, by the same rule---"
"Just so!" cried the Red Queen. "Five times as warm, _and_ five
times as cold---just as I'm five times as rich as you are, _and_
five times as clever!"
(_Through the Looking-Glass_, Chapter IX)
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
On Jun 25, 6:38 am, Vassil Nikolov <···············@pobox.com> wrote:
> On Tue, 24 Jun 2008 22:12:35 -0700 (PDT), Javier <·······@gmail.com> said:
>
> | Have you seen the shootout recently?:
>
> Not to diminish the achievements of all who contribute to SBCL, of
> course---
>
> Besides Shakespeare's works, Lewis Carroll's also have a quote for
> everything, more or less:
>
> "Are five nights warmer than one night, then?" Alice ventured to
> ask.
>
> "Five times as warm, of course."
I'm not entirely sure what you mean here. Sure, it's not directly
meaningful to say that language implementation X is z times faster
than Y, but it still has some relative value.
Especially when we see that, on average/mode/worst/best-case, SBCL's
performance in time and memory terms has improved relative to other
language implementations.
The memory use is still pretty high though.
What I'd personally like to see is a set of quite large applications,
implemented in different languages, so we could compare the
readability and code sizes. In the shootout programs, they're a)
optimised to the level where they're barely above C and b) too short
and limited in scope to be meaningful samples on those terms.
Everyone is saying that Lisp is more expressive than other languages,
but it's not visible on the shootout; in fact the Lisp programs are at
the longer, more verbose end.
Oisín
On 25 jun, 16:17, Oisín Mac Fhearaí <···········@gmail.com> wrote:
> Everyone is saying that Lisp is more expressive than other languages,
> but it's not visible on the shootout; in fact the Lisp programs are at
> the longer, more verbose end.
I think this is because of how large operators are in Lisp:
(setf my-variable 99)
versus
my_var=99
But, in general, if you only count the number of lines, Lisp is
usually shorter.
Also, in big applications, defmacro and functional programming allow
us to reduce complexity and size.
On 25 Giu, 16:54, Javier <·······@gmail.com> wrote:
> On 25 jun, 16:17, Oisín Mac Fhearaí <···········@gmail.com> wrote:
>
> > Everyone is saying that Lisp is more expressive than other languages,
> > but it's not visible on the shootout; in fact the Lisp programs are at
> > the longer, more verbose end.
>
> I think this is because of how large operators are in Lisp:
>
> (setf my-variable 99)
>
> versus
>
> my_var=99
The horror, the horror! No spaces around the assignment operator! Is
anybody reading the GNU coding standards nowadays instead of the
guidelines to punch ForTran IV cards? :)
Cheers
--
Marco
On Jun 25, 9:54 am, Javier <·······@gmail.com> wrote:
> On 25 jun, 16:17, Oisín Mac Fhearaí <···········@gmail.com> wrote:
>
> > Everyone is saying that Lisp is more expressive than other languages,
> > but it's not visible on the shootout; in fact the Lisp programs are at
> > the longer, more verbose end.
>
> I think this is because of how large operators are in Lisp:
>
> <snip>
>
> But, in general, if you only count the number of lines, Lisp is
> usually shorter.
How about counting symbols or tokens rather than characters or lines?
For example,
(setf my-variable 99)
and
my_var = 99
would both count as 3. It strikes me that this would be a better
measure of verbosity, because it's the number of elements needed more
than the amount of typing that is most relevant. This is especially
true when modern environments provide word completion, so it doesn't
actually take many more keystrokes to enter `long-named-function' than
`f'.
On 26 jun, 15:37, are <·········@gmx.net> wrote:
> On Jun 25, 9:54 am, Javier <·······@gmail.com> wrote:
>
> > On 25 jun, 16:17, Oisín Mac Fhearaí <···········@gmail.com> wrote:
>
> > > Everyone is saying that Lisp is more expressive than other languages,
> > > but it's not visible on the shootout; in fact the Lisp programs are at
> > > the longer, more verbose end.
>
> > I think this is because of how large operators are in Lisp:
>
> > <snip>
>
> > But, in general, if you only count the number of lines, Lisp is
> > usually shorter.
>
> How about counting symbols or tokens rather than characters or lines?
> For example,
>
> (setf my-variable 99)
>
> and
>
> my_var = 99
>
> would both count as 3. It strikes me that this would be a better
> measure of verbosity, because it's the number of elements needed more
> than the amount of typing that is most relevant. This is especially
> true when modern environments provide word completion, so it doesn't
> actually take many more keystrokes to enter `long-named-function' than
> `f'.
If we were typing as fast as we can think the solution, there would be
little difference in development time between languages. We spend most
of the time reading documentation, thinking, and understanding what we
wrote months ago.
1.- For thinking, Lisp has got lot of facilities, including
functional, object oriented, and imperative programming, a large
library, a more or less uniform semantic, a REPL for testing while
typing, and automatic memory management. The rest is up to the
knowledge and intelligence of the programmer.
2.- For understanding, Lisp is a very readable language, and has macro
facilities which allows to construct embedded micro-languages. This
eliminates a lot of verbose.
3.- For documentation, the language encourages it by built in
facilities like function and classes inline documentations, which can
be consulted in real time using Slime or any other specific editor
(this is equivalent to Javadoc, but better).
So Lisp is a winner here.
P� Thu, 26 Jun 2008 16:24:54 +0200, skrev Javier <·······@gmail.com>:
>
>
> If we were typing as fast as we can think the solution, there would be
> little difference in development time between languages. We spend most
> of the time reading documentation, thinking, and understanding what we
> wrote months ago.
> 1.- For thinking, Lisp has got lot of facilities, including
> functional, object oriented, and imperative programming, a large
> library, a more or less uniform semantic, a REPL for testing while
> typing, and automatic memory management. The rest is up to the
> knowledge and intelligence of the programmer.
> 2.- For understanding, Lisp is a very readable language, and has macro
> facilities which allows to construct embedded micro-languages. This
> eliminates a lot of verbose.
> 3.- For documentation, the language encourages it by built in
> facilities like function and classes inline documentations, which can
> be consulted in real time using Slime or any other specific editor
> (this is equivalent to Javadoc, but better).
>
> So Lisp is a winner here.
Fuzzy completion is awesome.. Like the mouse scroll button once you are
used to it you can't do without it.
--------------
John Thingstad
On Jun 26, 3:37 pm, are <·········@gmx.net> wrote:
> On Jun 25, 9:54 am, Javier <·······@gmail.com> wrote:
>
> > On 25 jun, 16:17, Oisín Mac Fhearaí <···········@gmail.com> wrote:
>
> > > Everyone is saying that Lisp is more expressive than other languages,
> > > but it's not visible on the shootout; in fact the Lisp programs are at
> > > the longer, more verbose end.
>
> > I think this is because of how large operators are in Lisp:
>
> > <snip>
>
> > But, in general, if you only count the number of lines, Lisp is
> > usually shorter.
>
> How about counting symbols or tokens rather than characters or lines?
> For example,
>
> (setf my-variable 99)
>
> and
>
> my_var = 99
>
> would both count as 3. It strikes me that this would be a better
> measure of verbosity, because it's the number of elements needed more
> than the amount of typing that is most relevant. This is especially
> true when modern environments provide word completion, so it doesn't
> actually take many more keystrokes to enter `long-named-function' than
> `f'.
Actually the both are improtant. The language could be terse - short
tokens and concise -use less tokens.
Lisp is sesquipedalian http://www.answers.com/sesquipedalian+?gwp=11&ver=2.3.0.624&method=3
and concise.
J / K and Q are both terse and concise. But the most improtant thing
to me the style of coding it promotes.
here's the best explanation so far from http://pozorvlak.livejournal.com/89208.html
It may interest you to know that most of my development time for that
was spent typing: paging through the library, trying things out at the
REPL, tweaking, debugging, iterating. It's a style I find much easier
than staring at a blank screen and thinking very hard, and one for
which I find forgiving languages like Perl and Lisp are much better
than Haskell.
So I guess it matters of type of personality you are. I'm gemini
BTW :)
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Better measure of program length?
Date:
Message-ID: <rem-2008jul11-004@yahoo.com>
> > > Everyone is saying that Lisp is more expressive than other languages,
> > > but it's not visible on the shootout; in fact the Lisp programs are at
> > > the longer, more verbose end.
> > I think this is because of how large operators are in Lisp:
> > But, in general, if you only count the number of lines, Lisp is
> > usually shorter.
> From: are <·········@gmx.net>
> How about counting symbols or tokens rather than characters or lines?
> For example,
> (setf my-variable 99)
> and
> my_var =3D 99
> would both count as 3. It strikes me that this would be a better
> measure of verbosity, because it's the number of elements needed
> more than the amount of typing that is most relevant.
I almost agree. What you should count is the number of nodes in the
parse tree (if it's binary then the number of terminals is one
greater than the number of nodes, so the total is about twice the
number of nodes or terminals, so it doesn't matter whether you
count only nodes or only terminals or both consistently).
With Lisp, the number of nodes is obvious from knowledge of the
internal CONS-tree representation. In other languages the parse
tree is not documented and rather a pain to try to analyze. Since
some parse-tree nodes in other languages require more than one
token, such as "else if", there may be a slight discrepancy between
the node count and the literal token count. Still what you suggest
is probably close enough for a reasonable approximation.
> This is especially true when modern environments provide word
> completion, so it doesn't actually take many more keystrokes to
> enter `long-named-function' than `f'.
IMO it's quite likely that Lisp has the advantage here. Compare:
In Lisp, you just start typing what you want, in hyphenated
English. For example if you want to know the count of number of
some element in a sequence (string or list), you type "cou" and
at that point the editor knows what you mean and can remind you the
sequence of the parameters to the COUNT function and the also
keyword options available. If you want to get the universal time,
you just start typing get-u and it can complete the rest already.
In C, it takes several minutes to figure out what the cryptic name
is for the library function that works with strings, which is
different from that which works with arrays, which is different
from what works with linked lists (which you never use anyway
because there's no decent GC). Then if you type it slightly wrong
you accidently make it look more like *another* cryptic
abbreviation that does something entirely different. And you can't
even see if you got it right without writing a PRINTF statement and
compiling and loading and starting your entire program, then you
need to remove that PRINTF statement sometime later so that there
won't be so much clutter of trace output you can't see the PRINTF
for what you try next after this.
And then three months later when your boss tells you there's a bug
that has worked its way through customer support to the management
team and now it really needs to be fixed, so you need to look at your
code again, you can't figure out what all those C-cryptic things mean.
(OK, I overstated my case a little, but I think my point is
somewhat correct.)
Robert Maas, http://tinyurl.com/uh3t wrote:
> For example if you want to know the count of number of
> some element in a sequence (string or list), you type "cou" and
> at that point the editor knows what you mean and can remind you the
> sequence of the parameters to the COUNT function and the also
> keyword options available.
Unless you have rebound those symbols or redefined lexical definitions.
I don't like software that tries to be smarter than me (it usually fails).
Matthias Buelow wrote:
> Robert Maas, http://tinyurl.com/uh3t wrote:
>
>> For example if you want to know the count of number of
>> some element in a sequence (string or list), you type "cou" and
>> at that point the editor knows what you mean and can remind you the
>> sequence of the parameters to the COUNT function and the also
>> keyword options available.
>
> Unless you have rebound those symbols or redefined lexical definitions.
> I don't like software that tries to be smarter than me (it usually fails).
Oh. Are we supposed to be checking the auto-completions? This could
explain a lot...
kk
On Jun 25, 10:54 am, Javier <·······@gmail.com> wrote:
> I think this is because of how large operators are in Lisp:
>
> (setf my-variable 99)
>
> versus
>
> my_var=99
As a side note, the language shootout doesn't measure the number of
lines in the program but the gzipped bytes.
The idea is that this reduces the penalties for longer keywords etc.
since they will be compressed down more effectively
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g53c1r$s1m$1@aioe.org>
Javier wrote:
> But, in general, if you only count the number of lines, Lisp is
> usually shorter.
Actually Lisp is almost always longer by any reasonable metric including
LOC. I went out of my way to measure the verbosity of Lisp on the ray
tracer benchmark:
http://www.ffconsultancy.com/languages/ray_tracer/results.html
Lisp is among the most verbose languages both by LOC and non-whitespace
bytes.
> Also, in big applications, defmacro and functional programming allow
> us to reduce complexity and size.
Macros without basic features means that Lisp projects have a considerable
constant overhead of boiler plate code spent Greenspunning features like
pattern matchers.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 9 Lug, 23:52, Jon Harrop <····@ffconsultancy.com> wrote:
> ...
P.S. The sad thing is, I will die eventually, but Lisp will never die.
But who will continue my important part of insulting Common Lisp
gratuitously? Who?
Jon Harrop
On Jul 10, 1:10 am, ···················@gmail.com wrote:
> On 9 Lug, 23:52, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > ...
>
> P.S. The sad thing is, I will die eventually, but Lisp will never die.
> But who will continue my important part of insulting Common Lisp
> gratuitously? Who?
You are not the first, nor will be the last, don't worry :)
It is just a matter of getting numbers straight. For example, your
ray tracer (with low level optimizations) can be rewritten in at least
132 lines with the same semantics using another standard, albeit less
tight, indentation style (just spread the if's and move around the
in's).
Juho's version is just 162 lines, once you maitain CL style but "get
the hang of it" :)
Cheers
--
Marco
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g54s4u$g82$1@aioe.org>
Marco Antoniotti wrote:
> On Jul 10, 1:10�am, ···················@gmail.com wrote:
>> P.S. The sad thing is, I will die eventually, but Lisp will never die.
>> But who will continue my important part of insulting Common Lisp
>> gratuitously? Who?
>
> You are not the first, nor will be the last, don't worry :)
>
> It is just a matter of getting numbers straight. For example, your
> ray tracer (with low level optimizations) can be rewritten in at least
> 132 lines with the same semantics using another standard, albeit less
> tight, indentation style (just spread the if's and move around the
> in's).
>
> Juho's version is just 162 lines, once you maitain CL style but "get
> the hang of it" :)
Compare to OCaml (43 lines) and Haskell (45 lines).
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Jul 10, 1:33 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Marco Antoniotti wrote:
> > On Jul 10, 1:10 am, ···················@gmail.com wrote:
> >> P.S. The sad thing is, I will die eventually, but Lisp will never die.
> >> But who will continue my important part of insulting Common Lisp
> >> gratuitously? Who?
>
> > You are not the first, nor will be the last, don't worry :)
>
> > It is just a matter of getting numbers straight. For example, your
> > ray tracer (with low level optimizations) can be rewritten in at least
> > 132 lines with the same semantics using another standard, albeit less
> > tight, indentation style (just spread the if's and move around the
> > in's).
>
> > Juho's version is just 162 lines, once you maitain CL style but "get
> > the hang of it" :)
>
> Compare to OCaml (43 lines) and Haskell (45 lines).
>
Yes, sure. I cheated by making Juho's example 162 lines. :) I suppose
we can cheat in many other ways.
Cheers
--
Marco
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g552bt$9ve$2@aioe.org>
Marco Antoniotti wrote:
> Yes, sure. I cheated by making Juho's example 162 lines. :) I suppose
> we can cheat in many other ways.
Much of the Lisp code is wasted performing tedious manual deconstructions of
data structures because Lisp lacks pattern matching. I wonder how much more
reasonable the code might look if you pull in cl-unification.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 10 Lug, 15:19, Jon Harrop <····@ffconsultancy.com> wrote:
> ...
BTW, what's exactly the difference between paren matching and pattern
matching?
Maybe you all Common Lispers don't need the latter because you already
have the further one?
Jon Harrop
From: John Thingstad
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <op.ud2zl3k4ut4oq5@pandora.alfanett.no>
P� Thu, 10 Jul 2008 16:19:30 +0200, skrev <···················@gmail.com>:
> On 10 Lug, 15:19, Jon Harrop <····@ffconsultancy.com> wrote:
>> ...
>
> BTW, what's exactly the difference between paren matching and pattern
> matching?
>
> Maybe you all Common Lispers don't need the latter because you already
> have the further one?
>
> Jon Harrop
pattern matching as in cl-ppcre, cl-yacc, cl-unify,...?
--------------
John Thingstad
On Thu, 10 Jul 2008 16:52:41 +0200, "John Thingstad" <·······@online.no> said:
|...
|| BTW, what's exactly the difference between paren matching and pattern
|| matching?
|| ...
| pattern matching as in cl-ppcre, cl-yacc, cl-unify,...?
As in
f 0 = 0
f 1 = 1
f (n+2) = f n + f (n+1)
Unless we are talking about parent matching, that is...
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: John Thingstad
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <op.ud3ptoa9ut4oq5@pandora.alfanett.no>
P� Fri, 11 Jul 2008 00:25:13 +0200, skrev Vassil Nikolov
<···············@pobox.com>:
> On Thu, 10 Jul 2008 16:52:41 +0200, "John Thingstad" <·······@online.no>
> said:
>
> |...
> || BTW, what's exactly the difference between paren matching and pattern
> || matching?
> || ...
> | pattern matching as in cl-ppcre, cl-yacc, cl-unify,...?
>
> As in
>
> f 0 = 0
> f 1 = 1
> f (n+2) = f n + f (n+1)
>
> Unless we are talking about parent matching, that is...
>
> ---Vassil.
>
>
I think my point was that there are many types of pattern matching.
Why should one be a part of the language and the others not?
Seems to me to be pretty few places in the code where algebraic matching
helps the code.
--------------
John Thingstad
On Fri, 11 Jul 2008 02:18:50 +0200, "John Thingstad" <·······@online.no> said:
| P� Fri, 11 Jul 2008 00:25:13 +0200, skrev Vassil Nikolov
| <···············@pobox.com>:
|| On Thu, 10 Jul 2008 16:52:41 +0200, "John Thingstad"
|| <·······@online.no> said:
||
|| |...
|| || BTW, what's exactly the difference between paren matching and pattern
|| || matching?
|| || ...
|| | pattern matching as in cl-ppcre, cl-yacc, cl-unify,...?
||
|| As in
||
|| f 0 = 0
|| f 1 = 1
|| f (n+2) = f n + f (n+1)
||
|| Unless we are talking about parent matching, that is...
| I think my point was that there are many types of pattern matching.
| Why should one be a part of the language and the others not?
| Seems to me to be pretty few places in the code where algebraic
| matching helps the code.
I did not follow up in disagreement with you...
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g579i1$q51$1@aioe.org>
John Thingstad wrote:
> I think my point was that there are many types of pattern matching.
> Why should one be a part of the language and the others not?
Indeed. Looking at functional code it is clear that users benefit from
pattern matching (e.g. in SML, OCaml, Haskell, Scala, F#, Mathematica and
even Scheme) only if it is standardized and well implemented.
> Seems to me to be pretty few places in the code where algebraic matching
> helps the code.
Try any of the above languages and the enormous advancement made by built-in
pattern matching will be blindingly obvious.
Compare this OCaml code:
let rec intersect orig dir (l, _ as hit) (center, radius, scene) =
match ray_sphere orig dir center radius, scene with
| lam', _ when lam' >= lam -> hit
| lam', [] -> lam', unitise (orig +| lam' *| dir -| center)
| _, scenes -> List.fold_left (intersect orig dir) hit scenes
With the equivalent Common Lisp:
(defun intersect (orig dir scene)
(labels ((aux (lam normal scene)
(let* ((center (sphere-center scene))
(lamt (ray-sphere orig
dir
center
(sphere-radius scene))))
(if (>= lamt lam)
(values lam normal)
(etypecase scene
(group
(dolist (kid (group-children scene))
(setf (values lam normal)
(aux lam normal kid)))
(values lam normal))
(sphere
(values lamt (unitise
(-v (+v orig (*v lamt dir)) center)))))))))
(aux infinity zero scene)))
The considerable difference in verbosity is primarily due to pattern
matching, which is used both for destructuring (replacing
MULTIPLE-VALUE-BIND, DESTRUCTURING-BIND, CAR, CDR etc.) and for dispatch
(replacing COND etc.).
With pattern matching, the syntactic overhead is as low as possible, e.g.
destructuring a pair return value:
# let polar x y = sqrt(x *. x +. y *. y), atan2 y x;;
val polar : float -> float -> float * float = <fun>
# let r, theta = polar 3. 4.;;
val r : float = 5.
val theta : float = 0.927295218001612187
Compared to:
* (defun polar (x y)
(values (sqrt (+ (* x x) (* y y))) (atan y x)))
POLAR
* (multiple-value-bind (r theta) (polar 3.0 4.0)
(vector r theta))
#(5.0 0.9272952)
Pattern matching improves most function definitions.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 11 Lug, 11:34, Jon Harrop <····@ffconsultancy.com> wrote:
> Pattern matching improves...
Thinking of it, should I use K in future?! Should I create (in the
sense of: building from nothing, like God) a new K# language?
Should I?
What's your kind Common Lispers' opinion?
(I think I should. Definitely.)
Jon Harrop
On Jul 11, 12:13 pm, ···················@gmail.com wrote:
> On 11 Lug, 11:34, Jon Harrop <····@ffconsultancy.com> wrote:
>
> > Pattern matching improves...
>
> Thinking of it, should I use K in future?! Should I create (in the
> sense of: building from nothing, like God) a new K# language?
> Should I?
> What's your kind Common Lispers' opinion?
> (I think I should. Definitely.)
You shoould start with COBOL# first :)
Seriously: pattern matching as a substitute of MULTIPLE-VALUE-* and
DESTRUCTURING-BIND is a good thing.
If you read some of the best K's tutorials, even there you see hints
of a "maybe K went too far in succinctness" syndrome :)
Cheers
--
Marco
On 11 Lug, 12:45, Marco Antoniotti <·······@gmail.com> wrote:
> Seriously: pattern matching as a substitute of MULTIPLE-VALUE-* and
> DESTRUCTURING-BIND is a good thing.
Are you sure?
If some Lisp Nobody (like JH) throws in some "advanced-language-
technology-progress", we all (real world coding Lispers) have to
forget all of our Lisp knowledge (I hate to call it "wisdom") which is
(1) *not* evident at first glance, like many ingenious theories (they
seem in fact too simple to be true...)
(2) not visible to anybody not deeply rooted inside the Lisp way of
understanding the programming process
(3) (maybe the most important point:) not flexible enough to be
attributed to *any* coding problem around ("pattern matching" is in
fact nothing more than a very, very restricted and quarter baked macro
system, which can be applied only in a very, very restricted number of
coding problem cases...)
Do I have to continue?
(I'd really like to do so, as I could bring you literally *thousands*
of examples from already *existing* Common Lisp code, which in more
"modern" languages would have to be made up...)
-PM
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5847g$bpn$1@aioe.org>
········@gmail.com wrote:
> (3) (maybe the most important point:) not flexible enough to be
> attributed to *any* coding problem around ("pattern matching" is in
> fact nothing more than a very, very restricted and quarter baked macro
> system, which can be applied only in a very, very restricted number of
> coding problem cases...)
Pattern matching and macros do not even attempt to provide similar
functionality. In fact, Mathematica really highlights just how much macros
stand to benefit from pattern matching.
> Do I have to continue?
You have to restart.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 11 Lug, 19:09, Jon Harrop <····@ffconsultancy.com> wrote:
> Pattern matching and macros...
BTW: these stinky macros!!
They shouldn't be called "macros".
I've just created a better term for them (you know, I'm a Multiple
Computer Science Degree Holder):
BM-ATA-MB (TM).
(Black Magic Any-To-Any Meta Box)
"Macro" is just too misleading (I'll never understand them).
Jon Harrop
On Jul 11, 5:53 pm, ········@gmail.com wrote:
> On 11 Lug, 12:45, Marco Antoniotti <·······@gmail.com> wrote:
>
> > Seriously: pattern matching as a substitute of MULTIPLE-VALUE-* and
> > DESTRUCTURING-BIND is a good thing.
>
> Are you sure?
>
> If some Lisp Nobody (like JH) throws in some "advanced-language-
> technology-progress", we all (real world coding Lispers) have to
> forget all of our Lisp knowledge (I hate to call it "wisdom") which is
>
> (1) *not* evident at first glance, like many ingenious theories (they
> seem in fact too simple to be true...)
You are forgetting one of the reasons why JH *does* have a point: the
fundamental theorem on programming languages evolution :)
> (2) not visible to anybody not deeply rooted inside the Lisp way of
> understanding the programming process
I am not giving up anything. As a matter of fact, the existence of
pattern matching (and more - CL-UNIFICATION as a shameless plug :) )
in CL demonstrate the flexibility and range of the language. You
simply cannot "add" it to another language without reworking it from
the guts (and yes: there are things that do need reworking from the
guts in CL).
> (3) (maybe the most important point:) not flexible enough to be
> attributed to *any* coding problem around ("pattern matching" is in
> fact nothing more than a very, very restricted and quarter baked macro
> system, which can be applied only in a very, very restricted number of
> coding problem cases...)
Not really. In the way JH and the ML/Haskell crowd look at it, it is
IMHO a very useful thing. I personally have made the choice that
sticking with CL is better for me (and for you) exaclty because I can
"macro-up" pattern matching if I need it among many other things.
Having said that... yes: MULTIPLE-VALUE-BIND and DESTRUCTURING-BIND
are very long names indeed.
Cheers
--
Marco
On 12 Lug, 12:12, Marco Antoniotti <·······@gmail.com> wrote:
> I am not giving up anything. As a matter of fact, the existence of
> pattern matching (and more - CL-UNIFICATION as a shameless plug :) )
> in CL demonstrate the flexibility and range of the language. You
> simply cannot "add" it to another language without reworking it from
> the guts (and yes: there are things that do need reworking from the
> guts in CL).
agreed, but my point was on a much more abstract level:
There are so many terms arising nowadays, which aren't really new to
many creative (and practical) Lisp coders:
Many of us have been using things like "pattern matching" (or better,
or other) for years, but without creating a fresh-and-shiny term every
time we invented new abstractions...
But Lisp remains the big exception: quite every other language has to
shout it out loud and clear, every time a new abstraction has been
finally found (as it seems to happen only every X years...).
In practical lisping, these things are happening so naturally and
frequently, that we never feel the need of "creating a shiny new fresh
super language" to embed the latest things finally adopted even by
computer science teachers (and, hopefully only some decade later, the
rest of industrial coding crowd...)
-PM
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5aj9k$n6p$1@aioe.org>
········@gmail.com wrote:
> On 12 Lug, 12:12, Marco Antoniotti <·······@gmail.com> wrote:
>> I am not giving up anything. �As a matter of fact, the existence of
>> pattern matching (and more - CL-UNIFICATION as a shameless plug :) )
>> in CL demonstrate the flexibility and range of the language. �You
>> simply cannot "add" it to another language without reworking it from
>> the guts (and yes: there are things that do need reworking from the
>> guts in CL).
>
> agreed, but my point was on a much more abstract level:
>
> There are so many terms arising nowadays, which aren't really new to
> many creative (and practical) Lisp coders:
> Many of us have been using things like "pattern matching" (or better,
> or other) for years, but without creating a fresh-and-shiny term every
> time we invented new abstractions...
>
> But Lisp remains the big exception: quite every other language has to
> shout it out loud and clear, every time a new abstraction has been
> finally found (as it seems to happen only every X years...).
>
> In practical lisping, these things are happening so naturally and
> frequently, that we never feel the need of "creating a shiny new fresh
> super language" to embed the latest things finally adopted even by
> computer science teachers (and, hopefully only some decade later, the
> rest of industrial coding crowd...)
In other words, Lispers are so used to having to Greenspun everything all
the time that they have forgotten that it is a bad idea.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Sat, 12 Jul 2008 03:12:10 -0700 (PDT), Marco Antoniotti <·······@gmail.com> said:
| ...
| [argument pattern matching] IMHO a very useful thing.
One important thing is to understand what it can and cannot do for
the programmer.
For example, in mathematics, one can write
f(3*x) = ...
f(3*x+1) = ...
f(3*x+2) = ...
(while I hear that even matching ``x+k'' may be removed from
Haskell, but I don't know details).
Then correct me if I am wrong, but argument pattern matching can
only be done when the structure is exactly known at the time of
writing the program. Consider this as another example [*]:
(defun mapcar1 (fn list)
"MAPCAR for one-argument functions."
(if (endp list) '()
(cons (funcall fn (first list)) (mapcar1 fn (rest list)))))
(defun x::mapcar (fn &rest lists)
"A naive implementation of MAPCAR."
(if (every #'endp lists) '()
(cons (apply fn (mapcar1 #'first lists))
(apply #'x::mapcar fn (mapcar1 #'rest lists)))))
The former can easily be done with pattern matching; but how to do
the latter? A human reader would understand
mapcar f [] [] ... = []
mapcar f (h1:t1) (h2:t2) ... = (f h1 h2 ...):(mapcar f t1 t2 ...)
but how to make a compiler grok that? (Yes, you can rewrite it into
several function definitions, but it is the above pseudo-code that
we would really want.)
_________
[*] Disclaimer: purely for illustrative purposes; not library-grade code.
| ...
| MULTIPLE-VALUE-BIND and
| DESTRUCTURING-BIND are very long names indeed.
I wonder if anybody has experimented even with something as simple as
(defmacro mvbind (&rest body) `(multiple-value-bind ,@body))
(defmacro dbind (&rest body) `(destructuring-bind ,@body))
and what the conclusions were.
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
On Jul 12, 6:22 pm, Vassil Nikolov <···············@pobox.com> wrote:
> On Sat, 12 Jul 2008 03:12:10 -0700 (PDT), Marco Antoniotti <·······@gmail.com> said:
> | ...
> | [argument pattern matching] IMHO a very useful thing.
>
> One important thing is to understand what it can and cannot do for
> the programmer.
>
> For example, in mathematics, one can write
>
> f(3*x) = ...
> f(3*x+1) = ...
> f(3*x+2) = ...
>
> (while I hear that even matching ``x+k'' may be removed from
> Haskell, but I don't know details).
>
> Then correct me if I am wrong, but argument pattern matching can
> only be done when the structure is exactly known at the time of
> writing the program.
Yes. That is the whole point of MLish languages and their 'datatype'
declarations.
> Consider this as another example [*]:
>
> (defun mapcar1 (fn list)
> "MAPCAR for one-argument functions."
> (if (endp list) '()
> (cons (funcall fn (first list)) (mapcar1 fn (rest list)))))
>
> (defun x::mapcar (fn &rest lists)
> "A naive implementation of MAPCAR."
> (if (every #'endp lists) '()
> (cons (apply fn (mapcar1 #'first lists))
> (apply #'x::mapcar fn (mapcar1 #'rest lists)))))
>
> The former can easily be done with pattern matching; but how to do
> the latter? A human reader would understand
>
> mapcar f [] [] ... = []
> mapcar f (h1:t1) (h2:t2) ... = (f h1 h2 ...):(mapcar f t1 t2 ...)
>
> but how to make a compiler grok that? (Yes, you can rewrite it into
> several function definitions, but it is the above pseudo-code that
> we would really want.)
That is a very good example. (As an aside, I think this is the gripe
with Microsoft CLR; Duane can recall that bit better). Yet, I find
pattern matching programming useful.
Cheers
--
Marco
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5asal$vru$1@aioe.org>
Vassil Nikolov wrote:
> On Sat, 12 Jul 2008 03:12:10 -0700 (PDT), Marco Antoniotti
> <·······@gmail.com> said:
> | ...
> | [argument pattern matching] IMHO a very useful thing.
>
> One important thing is to understand what it can and cannot do for
> the programmer.
>
> For example, in mathematics, one can write
>
> f(3*x) = ...
> f(3*x+1) = ...
> f(3*x+2) = ...
>
> (while I hear that even matching ``x+k'' may be removed from
> Haskell, but I don't know details).
You cannot do that directly anyway (and I think you are missing a constraint
like "x in Integers") so you are not really missing out. To implement that
in OCaml/F#, I would rephrase it:
match x % 3 with
| 0 -> ...
| 1 -> ...
| _ -> ...
> Then correct me if I am wrong, but argument pattern matching can
> only be done when the structure is exactly known at the time of
> writing the program. Consider this as another example [*]:
>
> (defun mapcar1 (fn list)
> "MAPCAR for one-argument functions."
> (if (endp list) '()
> (cons (funcall fn (first list)) (mapcar1 fn (rest list)))))
>
> (defun x::mapcar (fn &rest lists)
> "A naive implementation of MAPCAR."
> (if (every #'endp lists) '()
> (cons (apply fn (mapcar1 #'first lists))
> (apply #'x::mapcar fn (mapcar1 #'rest lists)))))
>
> The former can easily be done with pattern matching; but how to do
> the latter? A human reader would understand
>
> mapcar f [] [] ... = []
> mapcar f (h1:t1) (h2:t2) ... = (f h1 h2 ...):(mapcar f t1 t2 ...)
>
> but how to make a compiler grok that?
That is just the transpose of an ordinary "map", so the simplest definition
is:
let mapcar f = transpose >> map f >> transpose
If you must use pattern matching, you can shoehorn it into a single
function:
let rec mapcar f ?(hs=[]) = function
| [] -> []
| (h::ts)::tss -> mapcar f ~hs:(h::hs) (ts::tss)
| []::tss -> f(rev hs) :: mapcar f tss;;
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Sat, 12 Jul 2008 19:13:31 +0100, Jon Harrop <···@ffconsultancy.com> said:
| Vassil Nikolov wrote:
| ...
|| For example, in mathematics, one can write
||
|| f(3*x) = ...
|| f(3*x+1) = ...
|| f(3*x+2) = ...
||
|| ...
| You cannot do that directly anyway (and I think you are missing a constraint
| like "x in Integers") so you are not really missing out.
I am. My points, in other words, are that the above is (1) acceptable
to mathematicians, (2) well-defined, (3) computable, and (4) arguably
useful. What are the reasons why argument pattern matching won't do it?
| To implement that in OCaml/F#, I would rephrase it:
| match x % 3 with
| | 0 -> ...
| | 1 -> ...
| | _ -> ...
That is different from what I want, namely, that x be bound to the
_quotient_ (of the integer division of the argument by 3).
|| ...
|| A human reader would understand
||
(A)
|| mapcar f [] [] ... = []
|| mapcar f (h1:t1) (h2:t2) ... = (f h1 h2 ...):(mapcar f t1 t2 ...)
||
|| but how to make a compiler grok that?
| That is just the transpose of an ordinary "map", so the simplest definition
| is:
| let mapcar f = transpose >> map f >> transpose
That merely replaces the question with "how to define `transpose'
with argument pattern matching?".
| If you must use pattern matching, you can shoehorn it into a single
| function:
(B)
| let rec mapcar f ?(hs=[]) = function
| | [] -> []
| | (h::ts)::tss -> mapcar f ~hs:(h::hs) (ts::tss)
| | []::tss -> f(rev hs) :: mapcar f tss;;
If an additional facility (an optional parameter) needs to be
brought in, that demonstrates to me that argument pattern matching
alone is not enough. (Moreover, (B) also seems overly complicated
compared to (A), but let's leave that aside in the absence of a
commonly accepted objective measure of program source complexity.)
Note: For the sake of discussing programming approaches in
principle, let's ignore that (B) does not in fact do the same as the
pseudo-code in (A) does---compare
(mapcar #'+ '(1 2 3) '(4 5 6) '(7 8 9))
=> (12 15 18) ;(list (+ 1 4 5) (+ 2 5 8) (+ 3 6 0))
to
(s::mapcar #'+ '((1 2 3) (4 5 6) (7 8 9)))
=> (6 15 24) ;(list (+ 1 2 3) (+ 4 5 6) (+ 7 8 9))
where
;; (C)
(defun s::mapcar (f lists &key (hs '()))
(if (null lists) '()
(destructuring-bind (a &rest tss) lists
(if (null a) (cons (apply f (reverse hs)) (s::mapcar f tss))
(destructuring-bind (h &rest ts) a
(s::mapcar f (cons ts tss) :hs (cons h hs)))))))
is my translation of (B) into Common Lisp. (I hope the question of
whether (C) looks better or worse than (B) won't be brought up, but
if it were brought up, it would be a red herring, since what matters
here is only that (C) computes the same values as (B); (C) serves no
other purpose.)
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5clsi$5it$1@aioe.org>
Vassil Nikolov wrote:
> On Sat, 12 Jul 2008 19:13:31 +0100, Jon Harrop <···@ffconsultancy.com>
> said:
> | Vassil Nikolov wrote:
> | ...
> || For example, in mathematics, one can write
> ||
> || f(3*x) = ...
> || f(3*x+1) = ...
> || f(3*x+2) = ...
> ||
> || ...
>
> | You cannot do that directly anyway (and I think you are missing a
> | constraint like "x in Integers") so you are not really missing out.
>
> I am. My points, in other words, are that the above is (1) acceptable
> to mathematicians, (2) well-defined, (3) computable, and (4) arguably
> useful. What are the reasons why argument pattern matching won't do it?
Simply that pattern matching is not designed to solve Diophantine equations.
> | To implement that in OCaml/F#, I would rephrase it:
>
> | match x % 3 with
> | | 0 -> ...
> | | 1 -> ...
> | | _ -> ...
>
> That is different from what I want, namely, that x be bound to the
> _quotient_ (of the integer division of the argument by 3).
match x/3, x%3 with
| x, 0 -> ...
| x, 1 -> ...
| x, _ -> ...
> || ...
> || A human reader would understand
> ||
> (A)
> || mapcar f [] [] ... = []
> || mapcar f (h1:t1) (h2:t2) ... = (f h1 h2 ...):(mapcar f t1 t2 ...)
> ||
> || but how to make a compiler grok that?
>
> | That is just the transpose of an ordinary "map", so the simplest
> | definition is:
>
> | let mapcar f = transpose >> map f >> transpose
>
> That merely replaces the question with "how to define `transpose'
> with argument pattern matching?".
# let rec transpose = function
| [] | []::_ -> []
| tss -> map hd tss :: transpose (map tl tss);;
val transpose : 'a list list -> 'a list list = <fun>
# transpose [[1;2;3];[4;5;6];[7;8;9]];;
- : int list list = [[1; 4; 7]; [2; 5; 8]; [3; 6; 9]]
> | If you must use pattern matching, you can shoehorn it into a single
> | function:
> (B)
> | let rec mapcar f ?(hs=[]) = function
> | | [] -> []
> | | (h::ts)::tss -> mapcar f ~hs:(h::hs) (ts::tss)
> | | []::tss -> f(rev hs) :: mapcar f tss;;
>
> If an additional facility (an optional parameter) needs to be
> brought in, that demonstrates to me that argument pattern matching
> alone is not enough.
Pattern matching simply dissects data structures. You were essentially
asking for a transpose. That requires a data structure to be constructed as
well and, consequently, other features are required.
> (Moreover, (B) also seems overly complicated
> compared to (A), but let's leave that aside in the absence of a
> commonly accepted objective measure of program source complexity.)
>
> Note: For the sake of discussing programming approaches in
> principle, let's ignore that (B) does not in fact do the same as the
> pseudo-code in (A) does---compare
>
> (mapcar #'+ '(1 2 3) '(4 5 6) '(7 8 9))
> => (12 15 18) ;(list (+ 1 4 5) (+ 2 5 8) (+ 3 6 0))
>
> to
>
> (s::mapcar #'+ '((1 2 3) (4 5 6) (7 8 9)))
> => (6 15 24) ;(list (+ 1 2 3) (+ 4 5 6) (+ 7 8 9))
>
> where
>
> ;; (C)
> (defun s::mapcar (f lists &key (hs '()))
> (if (null lists) '()
> (destructuring-bind (a &rest tss) lists
> (if (null a) (cons (apply f (reverse hs)) (s::mapcar f tss))
> (destructuring-bind (h &rest ts) a
> (s::mapcar f (cons ts tss) :hs (cons h hs)))))))
>
> is my translation of (B) into Common Lisp. (I hope the question of
> whether (C) looks better or worse than (B) won't be brought up, but
> if it were brought up, it would be a red herring, since what matters
> here is only that (C) computes the same values as (B); (C) serves no
> other purpose.)
Yes. Writing "mapcar" in terms of the "transpose" function is much easier
because it does little more than a transpose.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Sun, 13 Jul 2008 11:35:56 +0100, Jon Harrop <···@ffconsultancy.com> said:
| Vassil Nikolov wrote:
|| On Sat, 12 Jul 2008 19:13:31 +0100, Jon Harrop <···@ffconsultancy.com>
|| said:
|| | Vassil Nikolov wrote:
|| || ...
|| || f(3*x) = ...
|| || f(3*x+1) = ...
|| || f(3*x+2) = ...
|| || ...
|| ...
|| My points, in other words, are that the above is (1) acceptable
|| to mathematicians, (2) well-defined, (3) computable, and (4) arguably
|| useful. What are the reasons why argument pattern matching won't do it?
| Simply that pattern matching is not designed to solve Diophantine equations.
Where exactly, then, is the boundary between what pattern matching
is and is not designed to solve, and why is it there (and not
further out)?
|| ...
| match x/3, x%3 with
| | x, 0 -> ...
| | x, 1 -> ...
| | x, _ -> ...
Only a very trivial case of pattern matching, if that.
|| ...
|| That merely replaces the question with "how to define `transpose'
|| with argument pattern matching?".
| # let rec transpose = function
| | [] | []::_ -> []
| | tss -> map hd tss :: transpose (map tl tss);;
Which does its job with selectors, and pattern matching plays only a
supporting role, if that.
| ...
|| | If you must use pattern matching, you can shoehorn it into a single
|| | function:
|| (B)
|| | let rec mapcar f ?(hs=[]) = function
|| | | [] -> []
|| | | (h::ts)::tss -> mapcar f ~hs:(h::hs) (ts::tss)
|| | | []::tss -> f(rev hs) :: mapcar f tss;;
||
|| If an additional facility (an optional parameter) needs to be
|| brought in, that demonstrates to me that argument pattern matching
|| alone is not enough.
| Pattern matching simply dissects data structures. You were essentially
| asking for a transpose. That requires a data structure to be constructed as
| well and, consequently, other features are required.
No. I was asking for pattern matching for data structure with
repeated components where the number of repetitions is not known
before run-time. It happens to be possible to use `transpose' for
the particular (simple) example I used, but "essentially asking for
a transpose" can serve as the answer only if it is proved that _all_
such cases can be dealt with by `transpose', which is at best an
open question.
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5dq93$c4t$1@aioe.org>
Vassil Nikolov wrote:
> On Sun, 13 Jul 2008 11:35:56 +0100, Jon Harrop <···@ffconsultancy.com>
> said:
> | Simply that pattern matching is not designed to solve Diophantine
> | equations.
>
> Where exactly, then, is the boundary between what pattern matching
> is and is not designed to solve, and why is it there (and not
> further out)?
Different languages have chosen different sweet spots.
Pattern matching in Haskells and MLs is for the destructuring of ML's
algebraic data types which can include dispatch. OCaml extends this to
arrays and adds guarded patterns and or-patterns. In all of these cases,
pattern matching can be heavily optimized resulting in much better
performance.
F# has arbitrarily extensible pattern matching with its active patterns
(aka "views"). That can be very useful, particularly for .NET interop and
lazy structures, but it completely undermines performance.
Pattern matching over integers (as in your first example) is only really
useful when it is combined in parallel with data structures, e.g. List.nth
in OCaml.
You can expand the capabilities of pattern matching (many OCaml macros do
this) but you quickly lose benefits like exhaustiveness and redundancy
checking.
Mathematica provides much more functionality (akin to unification) at the
cost of no static typing and almost no optimization. This is an excellent
choice for a symbolic algebra package but the unpredictable performance of
Mathematica's pattern matcher renders it unsuitable for general purpose
programming.
> || ...
> | match x/3, x%3 with
> | | x, 0 -> ...
> | | x, 1 -> ...
> | | x, _ -> ...
>
> Only a very trivial case of pattern matching, if that.
Yes: there are no structures to match against in that problem.
> || ...
> || That merely replaces the question with "how to define `transpose'
> || with argument pattern matching?".
>
> | # let rec transpose = function
> | | [] | []::_ -> []
> | | tss -> map hd tss :: transpose (map tl tss);;
>
> Which does its job with selectors, and pattern matching plays only a
> supporting role, if that.
Even in that trivial case, the alternative without pattern matching is more
verbose and more fragile.
> | ...
> || | If you must use pattern matching, you can shoehorn it into a single
> || | function:
> || (B)
> || | let rec mapcar f ?(hs=[]) = function
> || | | [] -> []
> || | | (h::ts)::tss -> mapcar f ~hs:(h::hs) (ts::tss)
> || | | []::tss -> f(rev hs) :: mapcar f tss;;
> ||
> || If an additional facility (an optional parameter) needs to be
> || brought in, that demonstrates to me that argument pattern matching
> || alone is not enough.
>
> | Pattern matching simply dissects data structures. You were essentially
> | asking for a transpose. That requires a data structure to be constructed
> | as well and, consequently, other features are required.
>
> No. I was asking for pattern matching for data structure with
> repeated components where the number of repetitions is not known
> before run-time. It happens to be possible to use `transpose' for
> the particular (simple) example I used, but "essentially asking for
> a transpose" can serve as the answer only if it is proved that _all_
> such cases can be dealt with by `transpose', which is at best an
> open question.
I cannot infer what you mean by "components" and what "such cases" you are
referring to. Can you give an example that is not trivially reducible?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487a7709$0$4999$607ed4bc@cv.net>
Jon Harrop wrote:
> Vassil Nikolov wrote:
>> On Sun, 13 Jul 2008 11:35:56 +0100, Jon Harrop <···@ffconsultancy.com>
>> said:
>> | Simply that pattern matching is not designed to solve Diophantine
>> | equations.
>>
>> Where exactly, then, is the boundary between what pattern matching
>> is and is not designed to solve, and why is it there (and not
>> further out)?
>
> Different languages have chosen different sweet spots.
That was the mistake Lisp avoided because back then people were just
trying To Write Applications, they had not made the Grave Error of
getting enamored of languages in and of themselves. All paradigms found
in the wild unobstructed by Harropian Paradigm Police thus found their
way into Lisp.
Since then we have Prolog saying everything is unification and Steele
saying everything is a constraint and Harrop saying everything is a
pattern and more than one failed language saying everything is an
object, all because they have lost site of why we program these damn
things and fallen in love with particular language syntax.
Hell, the single most powerful programming toy you can have is the Cell
and you don't see me using it for everything or dashing out to make a
new language. In fact, the second thing I realized is now Tilton's Law,
aping a sixties classic: "Make new datatypes, not new languages."
kzo
> Since then we have Prolog saying everything is unification and Steele
> saying everything is a constraint and Harrop saying everything is a
> pattern and more than one failed language saying everything is an
> object, all because they have lost site of why we program these damn
> things and fallen in love with particular language syntax.
Everything is lists?
-a
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487e1268$0$20935$607ed4bc@cv.net>
Ariel wrote:
>> Since then we have Prolog saying everything is unification and Steele
>> saying everything is a constraint and Harrop saying everything is a
>> pattern and more than one failed language saying everything is an
>> object, all because they have lost site of why we program these damn
>> things and fallen in love with particular language syntax.
>
> Everything is lists?
<g> ...or vectors or hash tables or complex numbers or defstructs or
defclasses or...
The one Lisp mandate seems to be that code be data and how cute is it
that this is a meta-mandate?
:)
kt
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487e5589$0$5008$607ed4bc@cv.net>
Kenny wrote:
> Ariel wrote:
>>> Since then we have Prolog saying everything is unification and Steele
>>> saying everything is a constraint and Harrop saying everything is a
>>> pattern and more than one failed language saying everything is an
>>> object, all because they have lost site of why we program these damn
>>> things and fallen in love with particular language syntax.
>>
>> Everything is lists?
>
> <g> ...or vectors or hash tables or complex numbers or defstructs or
> defclasses or...
>
> The one Lisp mandate seems to be that code be data and how cute is it
> that this is a meta-mandate?
Doh!
In
http://smuglispweeny.blogspot.com/2008/02/tall-ship-and-star-to-steer-her-by.html
...some wise soul pointed out:
"First principles are Good Things. In Lisp, every form returns a value.
That first principle works great. This despite Tilton's Law of
Programming: All X all the time is the root of all evil."
...and then went on to list prolog et al just as I did!
Still working on how I can talk myself out of that one.
kt
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487e5ad3$0$7346$607ed4bc@cv.net>
Kenny wrote:
> Kenny wrote:
>> Ariel wrote:
>>>> Since then we have Prolog saying everything is unification and
>>>> Steele saying everything is a constraint and Harrop saying
>>>> everything is a pattern and more than one failed language saying
>>>> everything is an object, all because they have lost site of why we
>>>> program these damn things and fallen in love with particular
>>>> language syntax.
>>>
>>> Everything is lists?
>>
>> <g> ...or vectors or hash tables or complex numbers or defstructs or
>> defclasses or...
>>
>> The one Lisp mandate seems to be that code be data and how cute is it
>> that this is a meta-mandate?
>
> Doh!
>
> In
> http://smuglispweeny.blogspot.com/2008/02/tall-ship-and-star-to-steer-her-by.html
>
>
> ...some wise soul pointed out:
>
> "First principles are Good Things. In Lisp, every form returns a value.
> That first principle works great. This despite Tilton's Law of
> Programming: All X all the time is the root of all evil."
>
> ...and then went on to list prolog et al just as I did!
>
> Still working on how I can talk myself out of that one.
>
> kt
I got it! Every form returning a value is necessary for us to have the
functional paradigm /available/ to us, and it is a fine paradigm, we
just do not want to be enslaved to never changing state.
Whew! That was close. Not sure my flock is ready for me to be wrong
about something.
kt
On Wed, 16 Jul 2008 16:31:14 -0400
Kenny <·········@gmail.com> wrote:
> Kenny wrote:
> > Kenny wrote:
> >> Ariel wrote:
> >>>> Since then we have Prolog saying everything is unification and
> >>>> Steele saying everything is a constraint and Harrop saying
> >>>> everything is a pattern and more than one failed language saying
> >>>> everything is an object, all because they have lost site of why we
> >>>> program these damn things and fallen in love with particular
> >>>> language syntax.
> >>>
> >>> Everything is lists?
> >>
> >> <g> ...or vectors or hash tables or complex numbers or defstructs or
> >> defclasses or...
> >>
> >> The one Lisp mandate seems to be that code be data and how cute is it
> >> that this is a meta-mandate?
> >
> > Doh!
> >
> > In
> > http://smuglispweeny.blogspot.com/2008/02/tall-ship-and-star-to-steer-her-by.html
> >
> >
> > ...some wise soul pointed out:
> >
> > "First principles are Good Things. In Lisp, every form returns a value.
> > That first principle works great. This despite Tilton's Law of
> > Programming: All X all the time is the root of all evil."
> >
> > ...and then went on to list prolog et al just as I did!
> >
> > Still working on how I can talk myself out of that one.
> >
> > kt
>
> I got it! Every form returning a value is necessary for us to have the
> functional paradigm /available/ to us, and it is a fine paradigm, we
> just do not want to be enslaved to never changing state.
>
> Whew! That was close. Not sure my flock is ready for me to be wrong
> about something.
>
> kt
Heh, works for me. I do like what I am learning about Lisp, reading other peoples code is starting to show me the the freedoms (as in fries) that it allows for. But for the most part I am stuck in the paradigm of how I was originally taught, so I wonder if the real potential is still being wasted on me.
Although I do like how being enslaved to an object oriented holding pattern in turn breathes creativity into how to handle objects, becoming more graceful and adapted. Sort of like how Dinosaur Comics (http://www.qwantz.com/) continues to be funny.
-a
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487e9bca$0$5009$607ed4bc@cv.net>
Ariel wrote:
> On Wed, 16 Jul 2008 16:31:14 -0400
> Kenny <·········@gmail.com> wrote:
>
>> Kenny wrote:
>>> Kenny wrote:
>>>> Ariel wrote:
>>>>>> Since then we have Prolog saying everything is unification and
>>>>>> Steele saying everything is a constraint and Harrop saying
>>>>>> everything is a pattern and more than one failed language saying
>>>>>> everything is an object, all because they have lost site of why we
>>>>>> program these damn things and fallen in love with particular
>>>>>> language syntax.
>>>>> Everything is lists?
>>>> <g> ...or vectors or hash tables or complex numbers or defstructs or
>>>> defclasses or...
>>>>
>>>> The one Lisp mandate seems to be that code be data and how cute is it
>>>> that this is a meta-mandate?
>>> Doh!
>>>
>>> In
>>> http://smuglispweeny.blogspot.com/2008/02/tall-ship-and-star-to-steer-her-by.html
>>>
>>>
>>> ...some wise soul pointed out:
>>>
>>> "First principles are Good Things. In Lisp, every form returns a value.
>>> That first principle works great. This despite Tilton's Law of
>>> Programming: All X all the time is the root of all evil."
>>>
>>> ...and then went on to list prolog et al just as I did!
>>>
>>> Still working on how I can talk myself out of that one.
>>>
>>> kt
>> I got it! Every form returning a value is necessary for us to have the
>> functional paradigm /available/ to us, and it is a fine paradigm, we
>> just do not want to be enslaved to never changing state.
>>
>> Whew! That was close. Not sure my flock is ready for me to be wrong
>> about something.
>>
>> kt
>
>
> Heh, works for me. I do like what I am learning about Lisp, reading
> other peoples code is starting to show me the the freedoms (as in
> fries) that it allows for. But for the most part I am stuck in the
> paradigm of how I was originally taught, so I wonder if the real
> potential is still being wasted on me.
Let's try for a more positive spin: Lisp is like skiing, fun the first
day but you get better every year and have even more fun.
>
> Although I do like how being enslaved to an object oriented holding
pattern in turn breathes creativity into how to handle objects, becoming
more graceful and adapted.
Absolutely, but do we program these damn things to get good at
programming them or to see them __<your application here>__?
kt
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87tzep1je4.fsf@hubble.informatimago.com>
Ariel <··@mail.poo> writes:
>
> Heh, works for me. I do like what I am learning about Lisp, reading
> other peoples code is starting to show me the the freedoms (as in
> fries) that it allows for. But for the most part I am stuck in the
> paradigm of how I was originally taught, so I wonder if the real
> potential is still being wasted on me.
>
> Although I do like how being enslaved to an object oriented holding
> pattern in turn breathes creativity into how to handle objects,
> becoming more graceful and adapted. Sort of like how Dinosaur
> Comics (http://www.qwantz.com/) continues to be funny.
You need to read SICP and PAIP (PAIP even if you're not very concerned
by AI, because it just exposes quite a number of different paradigms):
SICP = Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
PAIP = Paradigms of Artificial Intelligence Programming:
Case Studies in Common Lisp
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Kenny <·········@gmail.com> wrote:
+---------------
| Kenny wrote:
| http://smuglispweeny.blogspot.com/2008/02/tall-ship-and-star-to-steer-her-by.html
| > ...some wise soul pointed out:
| > "First principles are Good Things. In Lisp, every form returns a value.
| > That first principle works great. This despite Tilton's Law of
| > Programming: All X all the time is the root of all evil."
...
| > Still working on how I can talk myself out of that one.
|
| I got it! Every form returning a value is necessary for us to have the
| functional paradigm /available/ to us, and it is a fine paradigm, we
| just do not want to be enslaved to never changing state.
+---------------
And it is precisely this lack of "enslavement" which motivated
CL to *silently ignore* excess return values and provide NIL
for excess caller requests for them, whereas the Scheme standards
[and most Scheme implementations] blow chunks at any caller/callee
mismatch on number of values.
Liberty vs. safety. No brainer! I pick liberty!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487ebc0d$0$5018$607ed4bc@cv.net>
Rob Warnock wrote:
> Kenny <·········@gmail.com> wrote:
> +---------------
> | Kenny wrote:
> | http://smuglispweeny.blogspot.com/2008/02/tall-ship-and-star-to-steer-her-by.html
> | > ...some wise soul pointed out:
> | > "First principles are Good Things. In Lisp, every form returns a value.
> | > That first principle works great. This despite Tilton's Law of
> | > Programming: All X all the time is the root of all evil."
> ...
> | > Still working on how I can talk myself out of that one.
> |
> | I got it! Every form returning a value is necessary for us to have the
> | functional paradigm /available/ to us, and it is a fine paradigm, we
> | just do not want to be enslaved to never changing state.
> +---------------
>
> And it is precisely this lack of "enslavement" which motivated
> CL to *silently ignore* excess return values and provide NIL
> for excess caller requests for them, whereas the Scheme standards
> [and most Scheme implementations] blow chunks at any caller/callee
> mismatch on number of values.
Omigod!!! Why wasn't I told?? Throw me a bone, people!
Somewhat more seriously, duh-yamn, I never heard this one before. So in
Scheme I would die asking floor to give me the floor if I did not
pretend to be interested in the remainder.
Oh, man. What part of...
> Liberty vs. safety. No brainer! I pick liberty!
...do academics not understand?
Well, I guess it's what I said above. The job description of an academic
is to think Deep Thoughts about programming languages so there is an
instant conflict because programming languages exist only to make
applications easier to write than with a Turing machine.
They are kinda like the competition committee* for mud wrestling.
kt
* Folks who think about subtle rule changes for big league sports to
correct perceived degradation of play, such as lowering the pitcher's
mound when no one could hit .300.
Kenny <·········@gmail.com> wrote:
+---------------
| Rob Warnock wrote:
| > Kenny <·········@gmail.com> wrote:
| > +---------------
| > | I got it! Every form returning a value is necessary for us to have the
| > | functional paradigm /available/ to us, and it is a fine paradigm, we
| > | just do not want to be enslaved to never changing state.
| > +---------------
| >
| > And it is precisely this lack of "enslavement" which motivated
| > CL to *silently ignore* excess return values and provide NIL
| > for excess caller requests for them, whereas the Scheme standards
| > [and most Scheme implementations] blow chunks at any caller/callee
| > mismatch on number of values.
|
| Omigod!!! Why wasn't I told?? Throw me a bone, people!
|
| Somewhat more seriously, duh-yamn, I never heard this one before.
| So in Scheme I would die asking floor to give me the floor if I
| did not pretend to be interested in the remainder.
+---------------
Yup. As pointed out in a parallel reply, in Scheme FLOOR is *just*
FLOOR and MOD is *just* MOD [no REM per se]. However, R6RS introduced
a new standard library procedure [not available in R5RS or earlier],
DIV-AND-MOD, which returns two values, see:
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.7.4.3
11.7.4.3 Arithmetic operations
But caller/callee values still must exactly match, see:
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-8.html#node_sec_5.8
5.8 Multiple return values
and:
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.15
11.15 Control features
...
The continuations of all non-final expressions within a sequence
of expressions, such as in lambda, begin, let, let*, letrec, letrec*,
let-values, let*-values, case, and cond forms, usually take an
arbitrary number of values.
[That is, the places in "bodies" [implicit PROGNs, in CL] that would
throw away *a* value will also throw away any number of values.]
Except for these and the continuations created by call-with-values,
let-values, and let*-values, continuations implicitly accepting a
single value, such as the continuations of <operator> and <operand>s
of procedure calls or the <test> expressions in conditionals, take
exactly one value. The effect of passing an inappropriate number of
values to such a continuation is undefined.
(call-with-values producer consumer) procedure
Producer must be a procedure and should accept zero arguments.
Consumer must be a procedure and should accept as many values as
producer returns. ...
...
Implementation responsibilities: After producer returns, the
implementation must check that consumer accepts as many values
as consumer has returned.
So there you have it! [Just one more reason I switched to CL, b.t.w.]
To be fair(?), the one obvious escape-hatch *is* supported, in that a
procedure with a single &REST arg [in Scheme, (LAMBDA REST BODY...)]
can be used as a consumer that will will accept any number of values.
And thus one could define a near-equivalent of CL's MULTIPLE-VALUE-LIST
in Scheme this way:
(define (multiple-value-list producer) ; Note: PRODUCER must be a thunk
(call-with-values producer (lambda rest rest)))
or more simply:
(define (multiple-value-list producer)
(call-with-values producer list)) ; Assumes LIST has not been rebound
-Rob
p.s. Allowing a Scheme MULTIPLE-VALUE-LIST take a function-call
FORM arg [as in CL] instead of a PRODUCER thunk arg would require
MULTIPLE-VALUE-LIST to be a macro.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Andrew Reilly
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <6e81iqF5irm3U1@mid.individual.net>
On Wed, 16 Jul 2008 23:27:12 -0400, Kenny wrote:
> So in
> Scheme I would die asking floor to give me the floor if I did not
> pretend to be interested in the remainder.
Not in that particular case: floor (in scheme) just gives you the floor.
If you want the remainder you have to work that out yourself.
This seems more like a style issue than some sort of mud wrestling
specification to me. I haven't had it cause me any pain yet, but I'm new
to this stuff.
Cheers,
--
Andrew
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487ef579$0$20932$607ed4bc@cv.net>
Andrew Reilly wrote:
> On Wed, 16 Jul 2008 23:27:12 -0400, Kenny wrote:
>
>> So in
>> Scheme I would die asking floor to give me the floor if I did not
>> pretend to be interested in the remainder.
>
> Not in that particular case: floor (in scheme) just gives you the floor.
I had a feeling that would be the workaround: when I need both I have to
make two calls doing the same computation (or do the second myself) when
I could have gotten the two results off one computation.
Juuuusssst peachy. Interesting how some elegance is not so elegant when
applied. mccarthy's worked out great, sussman&steele not so much.
> If you want the remainder you have to work that out yourself.
>
> This seems more like a style issue than some sort of mud wrestling
> specification to me. I haven't had it cause me any pain yet, but I'm new
> to this stuff.
The pain is only when you realize you are getting less bang for the buck
from a construct because some school marm finger shaking chin pulling
pointy headed intellectual pipe sucking ivory tower sitting rule making
genius decided elegance as only he defined it was more important than
you getting your work done. Or something like that.
kt
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <7cy74097rn.fsf@pbourguignon.anevia.com>
Kenny <·········@gmail.com> writes:
> Andrew Reilly wrote:
>> On Wed, 16 Jul 2008 23:27:12 -0400, Kenny wrote:
>>
>>> So in
>>> Scheme I would die asking floor to give me the floor if I did not
>>> pretend to be interested in the remainder.
>> Not in that particular case: floor (in scheme) just gives you the
>> floor.
>
> I had a feeling that would be the workaround: when I need both I have
> to make two calls doing the same computation (or do the second myself)
> when I could have gotten the two results off one computation.
>
> Juuuusssst peachy. Interesting how some elegance is not so elegant
> when applied. mccarthy's worked out great, sussman&steele not so much.
>
>> If you want the remainder you have to work that out yourself.
>> This seems more like a style issue than some sort of mud wrestling
>> specification to me. I haven't had it cause me any pain yet, but
>> I'm new to this stuff.
>
> The pain is only when you realize you are getting less bang for the
> buck from a construct because some school marm finger shaking chin
> pulling pointy headed intellectual pipe sucking ivory tower sitting
> rule making genius decided elegance as only he defined it was more
> important than you getting your work done. Or something like that.
Or like this:
http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations-original.html
--
__Pascal Bourguignon__
On Wed, 16 Jul 2008 23:27:12 -0400, Kenny <·········@gmail.com> said:
| Rob Warnock wrote:
|| ...
|| And it is precisely this lack of "enslavement" which motivated
|| CL to *silently ignore* excess return values and provide NIL
|| for excess caller requests for them, whereas the Scheme standards
|| [and most Scheme implementations] blow chunks at any caller/callee
|| mismatch on number of values.
| Omigod!!! Why wasn't I told?? Throw me a bone, people!
| Somewhat more seriously, duh-yamn, I never heard this one before. So
| in Scheme I would die asking floor to give me the floor if I did not
| pretend to be interested in the remainder.
| Oh, man. What part of...
|| Liberty vs. safety. No brainer! I pick liberty!
| ...do academics not understand?
Before this is accepted as the only possible verdict and sentence is
passed, consider that this is in fact just one possible point in
language design space, rather than a battle on the barricades, much
more exciting though the latter may be (cf. Delacroix's painting).
Common Lisp chooses to consider multiple values as representing data
points that are related, but each with a meaning on its own, so it
allows an arbitrary subset of them to be silently discarded.
Another principle [*], I believe also reasonable and not impinging
on anyone's freedom, might be that multiple values are considered to
form a single compound value, and thus it would be justified for the
language processor to insist that they are all received. For a
quick example, consider a non-Common-Lisp approach where complex
numbers are returned as two real values, e.g. (SQRT2 -1) => 0 1.
Then we might like it if the compiler catches something like
(FLOAT= (SQRT2 X) Y) which would silently lose for a negative X
(where FLOAT= is a suitable proximity test).
Maybe there are better examples; I think there is an analogy to the
following case. Consider the following simplistic evaluator (where
ap is `apply'):
ev[e] <= [symbolp[e] -> symbol-value[e];
listp[e] -> ap[first[e];mapcar[ev;rest[e]]]]
so, for example, ev[(EXP (* I PI))] = -1 (approximately; where I is
the imaginary unit). Now, what should ev[1] be? NIL or undefined?
Mathematicians, I believe, would say the latter, but if we make the
usual translation of the right-hand side of the above into
S-expressions, viz.
(cond ((symbolp e) (symbol-value e))
((listp e) (ap (first e) (mapcar #'ev (rest e)))))
we would have the former. Thus, COND cuts the programmer quite a
bit of slack (it seems to me that CL:COND does that because the need
for compatibility overrode any other considerations here), but is
that an unequivocally good thing? [+]
_________
[*] I do not wish to speak for Scheme, though, as to whether it
embraces precisely this principle or some other.
[+] It is not an unequivocally bad thing, either; the important
thing is to know which trade-off is called for when (like
Humpty-Dumpty says).
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
Vassil Nikolov <···············@pobox.com> wrote:
+---------------
| Kenny <·········@gmail.com> said:
| | Rob Warnock wrote:
| | | And it is precisely this lack of "enslavement" which motivated
| | | CL to *silently ignore* excess return values and provide NIL
| | | for excess caller requests for them, whereas the Scheme standards
| | | [and most Scheme implementations] blow chunks at any caller/callee
| | | mismatch on number of values.
...
| | Oh, man. What part of...
| | | Liberty vs. safety. No brainer! I pick liberty!
| | ...do academics not understand?
|
| Before this is accepted as the only possible verdict and sentence is
| passed, consider that this is in fact just one possible point in
| language design space...
+---------------
Of course. But that's not to say that all points in design space
will be judged as "equally good" by all users.
+---------------
| Common Lisp chooses to consider multiple values as representing data
| points that are related, but each with a meaning on its own, so it
| allows an arbitrary subset of them to be silently discarded.
| Another principle, I believe also reasonable... [reordering a bit --rpw3]
| ...might be that multiple values are considered to form a single
| compound value, and thus it would be justified for the language
| processor to insist that they are all received.
+---------------
Reasonable, perhaps, if one were of that persuasion. And if one were,
then having the language processor enforce it would also be reasonable.
But not all users *will* find it reasonable, since not all users are
of that persuasion[1] or perhaps not of that persuasion all the time.
[See below for the design option of *selective* enforcement.]
+---------------
| ...and not impinging on anyone's freedom...
+---------------
Free choice is fine; forced choice is not so fine. One may freely
choose to use Scheme, for example, but once one has done so then
the choice of whether values-matching is enforced by the language
processor is no longer a choice, and thus *does* impinge on one's
freedom.
Whereas if one freely chooses to use Common Lisp, then one has the
*choice* of whether to enforce such values matching. One can easily
write one's own MULTIPLE-VALUE-BIND/STRICT which would raise a condition
if the binding list and the values delivered did not exactly match, e.g.:
(multiple-value-bind/strict (a b c)
(values 1 2 3 4)
(list a b c))
>> Error: Function returned more values than available binding variables!
>> To continue, type :CONTINUE followed by an option number:
>> 1: Return to Lisp Toplevel.
>> Debug>
It might not be as *efficient* as the built-in MULTIPLE-VALUE-BIND, but
it's at least possible to write. The language gives one such freedom.
It's *that* choice [in *addition* to the default convenience of
relaxed values-matching] that is the significant "liberty" of CL!!
-Rob
[1] I myself, however, am [now, 2008] of the other persuasion,
which is partially why I switched [circa 2000] from Scheme to CL.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487ff56f$0$20940$607ed4bc@cv.net>
Vassil Nikolov wrote:
> On Wed, 16 Jul 2008 23:27:12 -0400, Kenny <·········@gmail.com> said:
>
> | Rob Warnock wrote:
> || ...
> || And it is precisely this lack of "enslavement" which motivated
> || CL to *silently ignore* excess return values and provide NIL
> || for excess caller requests for them, whereas the Scheme standards
> || [and most Scheme implementations] blow chunks at any caller/callee
> || mismatch on number of values.
>
> | Omigod!!! Why wasn't I told?? Throw me a bone, people!
>
> | Somewhat more seriously, duh-yamn, I never heard this one before. So
> | in Scheme I would die asking floor to give me the floor if I did not
> | pretend to be interested in the remainder.
>
> | Oh, man. What part of...
>
> || Liberty vs. safety. No brainer! I pick liberty!
>
> | ...do academics not understand?
>
> Before this is accepted as the only possible verdict and sentence is
> passed, consider that this is in fact just one possible point in
> language design space, rather than a battle on the barricades, much
> more exciting though the latter may be (cf. Delacroix's painting).
>
> Common Lisp chooses to consider multiple values as representing data
> points that are related, but each with a meaning on its own, so it
> allows an arbitrary subset of them to be silently discarded.
"Chooses"? That is the whole point of extra values, they are auxiliary
to the result, not part of it.
> Another principle [*], I believe also reasonable and not impinging
> on anyone's freedom, might be that multiple values are considered to
> form a single compound value,...
Ah, the smoking gun. No, sir, we have plenty of ways to represent
compound values. VALUES exists to allow us to return a result all by its
lonesome, but also provide the caller with other info if they care. Note
the "if". C being a good example: I want to return a pointer and mention
something else, say, how much remains. Pass me null for where to write
how much remains and I won't bother. Fortunately Lisp is more elegant,
the callee can return the info and I can Just Ignore It. In both
languages, however, the result remains pure and unsullied by having to
tote around extra baggage.
> and thus it would be justified for the
> language processor to insist that they are all received. For a
> quick example, consider a non-Common-Lisp approach where complex
> numbers are returned as two real values, e.g. (SQRT2 -1) => 0 1.
> Then we might like it if the compiler catches ...
I'm sorry, I could have sworn I heard you waxing euologic on compilers
catching things for us... does anyone know the newsgroup for C++ or Java
for this gentleman?
:)
kzo
On Thu, 17 Jul 2008 21:44:16 -0400, Kenny <·········@gmail.com> said:
| ...
| I'm sorry, I could have sworn I heard you waxing euologic on compilers
| catching things for us... does anyone know the newsgroup for C++ or
| Java for this gentleman?
:- )
(What, no offers of the F-word? Am I _that_ unworthy?)
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <48802feb$0$20921$607ed4bc@cv.net>
Vassil Nikolov wrote:
> On Thu, 17 Jul 2008 21:44:16 -0400, Kenny <·········@gmail.com> said:
>
> | ...
> | I'm sorry, I could have sworn I heard you waxing euologic on compilers
> | catching things for us... does anyone know the newsgroup for C++ or
> | Java for this gentleman?
>
> :- )
>
> (What, no offers of the F-word? Am I _that_ unworthy?)
Try harder. Say something bad about Cells. But it has to be informed --
Seibel and Costanza have already staked* out the Denunciation Without
Looking turf.
kt
* Why does that look so misspelled? k
On Jul 18, 3:44 am, Kenny <·········@gmail.com> wrote:
> Vassil Nikolov wrote:
>
> > Another principle [*], I believe also reasonable and not impinging
> > on anyone's freedom, might be that multiple values are considered to
> > form a single compound value,...
>
> Ah, the smoking gun. No, sir, we have plenty of ways to represent
> compound values. VALUES exists to allow us to return a result all by its
> lonesome, but also provide the caller with other info if they care. Note
> the "if". C being a good example: I want to return a pointer and mention
> something else, say, how much remains. Pass me null for where to write
> how much remains and I won't bother. Fortunately Lisp is more elegant,
> the callee can return the info and I can Just Ignore It. In both
> languages, however, the result remains pure and unsullied by having to
> tote around extra baggage.
>
In all fairness, if you don't take the extreme view of languages,
you'll realize languages such as Python will also allow you to return
multiple values, and even easier than in Lisp.
Compare
def foo():
return 1, 2, 3
a, b, c = foo()
print a, b, c
to
(defun foo ()
(values 1 2 3))
(multiple-value-bind (a b c) (foo)
(format t "~A ~A ~A" a b c))
Granted, VALUES solves a slightly different problem, and you could
argue that what the Python version *really* does is returning a list
and the callee then performs a d-b... (no notion of primary vs
auxillary values).
--
Mikael Jansson
http://mikael.jansson.be
On Jul 20, 10:36 am, Mikael Jansson <··············@gmail.com> wrote:
> On Jul 18, 3:44 am, Kenny <·········@gmail.com> wrote:
>
> > Vassil Nikolov wrote:
>
> > > Another principle [*], I believe also reasonable and not impinging
> > > on anyone's freedom, might be that multiple values are considered to
> > > form a single compound value,...
>
> > Ah, the smoking gun. No, sir, we have plenty of ways to represent
> > compound values. VALUES exists to allow us to return a result all by its
> > lonesome, but also provide the caller with other info if they care. Note
> > the "if". C being a good example: I want to return a pointer and mention
> > something else, say, how much remains. Pass me null for where to write
> > how much remains and I won't bother. Fortunately Lisp is more elegant,
> > the callee can return the info and I can Just Ignore It. In both
> > languages, however, the result remains pure and unsullied by having to
> > tote around extra baggage.
>
> In all fairness, if you don't take the extreme view of languages,
> you'll realize languages such as Python will also allow you to return
> multiple values, and even easier than in Lisp.
>
> Compare
>
> def foo():
> return 1, 2, 3
> a, b, c = foo()
> print a, b, c
>
> to
>
> (defun foo ()
> (values 1 2 3))
> (multiple-value-bind (a b c) (foo)
> (format t "~A ~A ~A" a b c))
>
> Granted, VALUES solves a slightly different problem, and you could
> argue that what the Python version *really* does is returning a list
> and the callee then performs a d-b... (no notion of primary vs
> auxillary values).
>
> --
> Mikael Janssonhttp://mikael.jansson.be
you already comment that it's not the same thing as returning multiple
values ...
compare python example with appropriate lisp code (and it does not
depends on list length)
CL-USER> (defun foo ()
(list 1 2 3))
(let ((x (foo)))
(format t "~{~a ~}" x))
1 2 3
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <4883632b$0$7344$607ed4bc@cv.net>
Mikael Jansson wrote:
> On Jul 18, 3:44 am, Kenny <·········@gmail.com> wrote:
>> Vassil Nikolov wrote:
>>
>>> Another principle [*], I believe also reasonable and not impinging
>>> on anyone's freedom, might be that multiple values are considered to
>>> form a single compound value,...
>> Ah, the smoking gun. No, sir, we have plenty of ways to represent
>> compound values. VALUES exists to allow us to return a result all by its
>> lonesome, but also provide the caller with other info if they care. Note
>> the "if". C being a good example: I want to return a pointer and mention
>> something else, say, how much remains. Pass me null for where to write
>> how much remains and I won't bother. Fortunately Lisp is more elegant,
>> the callee can return the info and I can Just Ignore It. In both
>> languages, however, the result remains pure and unsullied by having to
>> tote around extra baggage.
>>
> In all fairness, if you don't take the extreme view of languages,
Fairness? Unextreme? From Kenny? One minute of play and you are down
two-nil. :)
> you'll realize languages such as Python will also allow you to return
> multiple values, and even easier than in Lisp.
I think you meant with fewer characters typed, not "easier". I have
monkeys for typing. I also have macros so I could create mvb and dsb but
for some reason I have not. They are pretty rare in my code.
My larger concern is that you and a certain noxious toad saw me mention
C as an aside and turned the ball over by booting it out of topic,
deciding the topic is now one of language comparison. Context, people,
context: multiple values vs a single compound structure for returning
stuff of varying degrees of relatedness.
If other languages support multiples values, I am delighted for their
users, but then we still have the OT to settle.
>
> Compare
>
> def foo():
> return 1, 2, 3
> a, b, c = foo()
> print a, b, c
>
> to
>
> (defun foo ()
> (values 1 2 3))
> (multiple-value-bind (a b c) (foo)
> (format t "~A ~A ~A" a b c))
>
> Granted, VALUES solves a slightly different problem, and you could
> argue that what the Python version *really* does is returning a list
> and the callee then performs a d-b... (no notion of primary vs
> auxillary values).
I presume Pythn allows me to ignore any number of returned values or you
would not have offered this as an equivalent.
Again, if other languages do the same, god bless 'em. I mentioned C only
as evidence that programmers do sometimes need such a thing, mentioning
only in passing that Lisp made it more elegant.
kt
Kenny wrote:
> I presume Pythn allows me to ignore any number of returned values or you
> would not have offered this as an equivalent.
·····@enterprise:~ $ python
Python 2.5.2 (r252:60911, Mar 1 2008, 13:52:45)
[GCC 4.2.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
... return 1, 2, 3
...
>>> a, b = foo()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: too many values to unpack
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <488390c0$0$7362$607ed4bc@cv.net>
Joost Kremers wrote:
> Kenny wrote:
>> I presume Pythn allows me to ignore any number of returned values or you
>> would not have offered this as an equivalent.
>
> ·····@enterprise:~ $ python
> Python 2.5.2 (r252:60911, Mar 1 2008, 13:52:45)
> [GCC 4.2.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> def foo():
> ... return 1, 2, 3
> ...
>>>> a, b = foo()
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: too many values to unpack
>
>
Oh, my.
kt
On Jul 20, 6:38 pm, Joost Kremers <············@yahoo.com> wrote:
> Kenny wrote:
> > I presume Pythn allows me to ignore any number of returned values or you
> > would not have offered this as an equivalent.
>
> ·····@enterprise:~ $ python
> Python 2.5.2 (r252:60911, Mar 1 2008, 13:52:45)
> [GCC 4.2.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.>>> def foo():
>
> ... return 1, 2, 3
> ...>>> a, b = foo()
>
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: too many values to unpack
>
Kind-of works::
>>> a, *b = 1, 2, 3
>>> a
1
>>> b
[2, 3]
Of course, you'll need Python3k...
--
Mikael Jansson
http://mikael.jansson.be
Mikael Jansson wrote:
> On Jul 20, 6:38�pm, Joost Kremers <············@yahoo.com> wrote:
>> Kenny wrote:
>> > I presume Pythn allows me to ignore any number of returned values or you
>> > would not have offered this as an equivalent.
>>
>> ·····@enterprise:~ $ python
>> Python 2.5.2 (r252:60911, Mar �1 2008, 13:52:45)
>> [GCC 4.2.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.>>> def foo():
>>
>> ... � � return 1, 2, 3
>> ...>>> a, b = foo()
>>
>> Traceback (most recent call last):
>> � File "<stdin>", line 1, in <module>
>> ValueError: too many values to unpack
>>
> Kind-of works::
>
> >>> a, *b = 1, 2, 3
> >>> a
> 1
> >>> b
> [2, 3]
>
> Of course, you'll need Python3k...
but that means you need to apply a further operation to b in order to get
to the value '2', which, after all, is what you want.
what *does* work is:
>>> a, b, _ = foo()
>>> a
1
>>> b
2
>>>
--
Joost Kremers ············@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g60av8$2is$1@aioe.org>
Kenny wrote:
> I think you meant with fewer characters typed, not "easier". I have
> monkeys for typing. I also have macros so I could create mvb and dsb but
> for some reason I have not.
Because deep down you know that would just be Greenspunning pattern matching
from a modern language so you grit your teeth and battle on with a fragile
antique instead.
> My larger concern is that you and a certain noxious toad saw me mention
> C as an aside and turned the ball over by booting it out of topic,
> deciding the topic is now one of language comparison. Context, people,
> context: multiple values vs a single compound structure for returning
> stuff of varying degrees of relatedness.
You have built an artificial distinction simply because you have run out of
options with Lisp. The same is not true of modern languages. Multiple
return values are nothing more than a special case of tuples.
Deconstructing them is nothing more than a special case of pattern
matching.
>> Compare
>>
>> def foo():
>> return 1, 2, 3
>> a, b, c = foo()
>> print a, b, c
>>
>> to
>>
>> (defun foo ()
>> (values 1 2 3))
>> (multiple-value-bind (a b c) (foo)
>> (format t "~A ~A ~A" a b c))
>>
>> Granted, VALUES solves a slightly different problem, and you could
>> argue that what the Python version *really* does is returning a list
>> and the callee then performs a d-b... (no notion of primary vs
>> auxillary values).
>
> I presume Pythn allows me to ignore any number of returned values or you
> would not have offered this as an equivalent.
Once you have pattern matching, the solution is obvious: nested tuples:
let foo() = 1, (2, (3, 4))
let a, (b, _) = foo()
> Again, if other languages do the same, god bless 'em. I mentioned C only
> as evidence that programmers do sometimes need such a thing, mentioning
> only in passing that Lisp made it more elegant.
Except that the nearest Lisp equivalents are either bloated or fragile:
(defun foo ()
'((1 2) 3))
(defvar abc (foo))
(defvar a (caar abc))
(defvar b (cadar abc))
(defvar c (cadr abc))
(format t "~A ~A ~A" a b c)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Jul 21, 12:33 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Kenny wrote:
> > I think you meant with fewer characters typed, not "easier". I have
> > monkeys for typing. I also have macros so I could create mvb and dsb but
> > for some reason I have not.
>
> Because deep down you know that would just be Greenspunning pattern matching
> from a modern language so you grit your teeth and battle on with a fragile
> antique instead.
>
> > My larger concern is that you and a certain noxious toad saw me mention
> > C as an aside and turned the ball over by booting it out of topic,
> > deciding the topic is now one of language comparison. Context, people,
> > context: multiple values vs a single compound structure for returning
> > stuff of varying degrees of relatedness.
>
> You have built an artificial distinction simply because you have run out of
> options with Lisp. The same is not true of modern languages. Multiple
> return values are nothing more than a special case of tuples.
> Deconstructing them is nothing more than a special case of pattern
> matching.
>
>
>
> >> Compare
>
> >> def foo():
> >> return 1, 2, 3
> >> a, b, c = foo()
> >> print a, b, c
>
> >> to
>
> >> (defun foo ()
> >> (values 1 2 3))
> >> (multiple-value-bind (a b c) (foo)
> >> (format t "~A ~A ~A" a b c))
>
> >> Granted, VALUES solves a slightly different problem, and you could
> >> argue that what the Python version *really* does is returning a list
> >> and the callee then performs a d-b... (no notion of primary vs
> >> auxillary values).
>
> > I presume Pythn allows me to ignore any number of returned values or you
> > would not have offered this as an equivalent.
>
> Once you have pattern matching, the solution is obvious: nested tuples:
>
> let foo() = 1, (2, (3, 4))
> let a, (b, _) = foo()
>
> > Again, if other languages do the same, god bless 'em. I mentioned C only
> > as evidence that programmers do sometimes need such a thing, mentioning
> > only in passing that Lisp made it more elegant.
>
> Except that the nearest Lisp equivalents are either bloated or fragile:
>
> (defun foo ()
> '((1 2) 3))
>
> (defvar abc (foo))
> (defvar a (caar abc))
> (defvar b (cadar abc))
> (defvar c (cadr abc))
>
> (format t "~A ~A ~A" a b c)
>
> --
> Dr Jon D Harrop, Flying Frog Consultancyhttp://www.ffconsultancy.com/products/?u
How about:
cl-user> (destructuring-bind ((a b) c) (foo)
(list a b c))
(1 2 3)
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <4883d9b8$0$7346$607ed4bc@cv.net>
Jon Harrop wrote:
> Kenny wrote:
>> I think you meant with fewer characters typed, not "easier". I have
>> monkeys for typing. I also have macros so I could create mvb and dsb but
>> for some reason I have not.
>
> Because deep down you know that would just be Greenspunning pattern matching
> from a modern language so you grit your teeth and battle on with a fragile
> antique instead.
You know Lisp is great because Jon has fallen in love with this NG, and
has been graciously adopted by The Savages.
I smell a screenplay. Ice Age III? Probably in final production, ok, IV.
We'll have to cast Jon as the squirrel, but he's part chameleon, he'll
do. He sees a bit of code, starts chipping away at the ice, kablam! Lisp
is back. (Yeah, squirrel is flattened again. Audience laughs and cheers.)
>
>> My larger concern is that you and a certain noxious toad saw me mention
>> C as an aside and turned the ball over by booting it out of topic,
>> deciding the topic is now one of language comparison. Context, people,
>> context: multiple values vs a single compound structure for returning
>> stuff of varying degrees of relatedness.
>
> You have built an artificial distinction simply because you have run out of
> options with Lisp. The same is not true of modern languages. Multiple
> return values are nothing more than a special case of tuples.
Oh, f*ck, wartmaker is on topic. Er...would you care to address it? Cuz
what you just announced is actually the subject of the discussion.
Kruschev got good mileage out of banging his shoe on the table at the UN
(omigod, did he really do that? that would be so cool, ya gotta love
them Rooskies) but on this august forum of astute intellectual debate...
hang on... no, you are doing fine there with your shoe.
hth, kenny
ps....
> Deconstructing them is nothing more than a special case of pattern
> matching.
>
>>> Compare
>>>
>>> def foo():
>>> return 1, 2, 3
>>> a, b, c = foo()
>>> print a, b, c
>>>
>>> to
>>>
>>> (defun foo ()
>>> (values 1 2 3))
>>> (multiple-value-bind (a b c) (foo)
>>> (format t "~A ~A ~A" a b c))
>>>
>>> Granted, VALUES solves a slightly different problem, and you could
>>> argue that what the Python version *really* does is returning a list
>>> and the callee then performs a d-b... (no notion of primary vs
>>> auxillary values).
>> I presume Pythn allows me to ignore any number of returned values or you
>> would not have offered this as an equivalent.
>
> Once you have pattern matching, the solution is obvious: nested tuples:
>
> let foo() = 1, (2, (3, 4))
> let a, (b, _) = foo()
>
>> Again, if other languages do the same, god bless 'em. I mentioned C only
>> as evidence that programmers do sometimes need such a thing, mentioning
>> only in passing that Lisp made it more elegant.
>
> Except that the nearest Lisp equivalents are either bloated or fragile:
>
> (defun foo ()
> '((1 2) 3))
>
> (defvar abc (foo))
> (defvar a (caar abc))
> (defvar b (cadar abc))
> (defvar c (cadr abc))
>
> (format t "~A ~A ~A" a b c)
>
You are accustomed to people reponding to such idiocy, aren't you? I
told you, please wait for the next dog to come along, I am chewing on
Algebra software these days.
k
On Sun, 20 Jul 2008 20:33:56 -0400, Kenny <·········@gmail.com> said:
| ...
| Kruschev got good mileage out of banging his shoe on the
| table at the UN (omigod, did he really do that?
There is a version in which that was staged, and he banged his third
shoe. Se non e vero...
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <4886bdf1$0$7317$607ed4bc@cv.net>
Vassil Nikolov wrote:
> On Sun, 20 Jul 2008 20:33:56 -0400, Kenny <·········@gmail.com> said:
> | ...
> | Kruschev got good mileage out of banging his shoe on the
> | table at the UN (omigod, did he really do that?
>
> There is a version in which that was staged, and he banged his third
> shoe. Se non e vero...
>
If Wikipedia says it is so (and it do) that is good enough for me. Well,
not quite the same as a genuine heat-of-the-moment shoe-removing
desk-pounding, but I am on record in favor of diligent preparation...
http://smuglispweeny.blogspot.com/
... I guess Nikita is still good for a silver.
kt
On Jul 20, 6:08 pm, Kenny <·········@gmail.com> wrote:
> Mikael Jansson wrote:
> > In all fairness, if you don't take the extreme view of languages,
>
> Fairness? Unextreme? From Kenny? One minute of play and you are down
> two-nil. :)
>
Hey, who made you the judge?
> > you'll realize languages such as Python will also allow you to return
> > multiple values, and even easier than in Lisp.
>
> I think you meant with fewer characters typed, not "easier". I have
> monkeys for typing. I also have macros so I could create mvb and dsb but
> for some reason I have not. They are pretty rare in my code.
>
Indeed, that is what I meant, on the merit of easier things getting
done more often. Multiple values in e.g. Java isn't done very often
for precisely that reason.
> My larger concern is that you and a certain noxious toad saw me mention
> C as an aside and turned the ball over by booting it out of topic,
> deciding the topic is now one of language comparison. Context, people,
> context: multiple values vs a single compound structure for returning
> stuff of varying degrees of relatedness.
>
And who is to say that my comment wasn't also an aside? Looks like the
table has turned, and it is now two-nil in my favour!
>
>
> > Compare
>
> > def foo():
> > return 1, 2, 3
> > a, b, c = foo()
> > print a, b, c
>
> > to
>
> > (defun foo ()
> > (values 1 2 3))
> > (multiple-value-bind (a b c) (foo)
> > (format t "~A ~A ~A" a b c))
>
> > Granted, VALUES solves a slightly different problem, and you could
> > argue that what the Python version *really* does is returning a list
> > and the callee then performs a d-b... (no notion of primary vs
> > auxillary values).
>
> I presume Pythn allows me to ignore any number of returned values or you
> would not have offered this as an equivalent.
>
No, because I changed opinions mid-post and realized Python only gives
you the equivalent of destructuring-bind with the &rest argument
defaulting for the values-returned-but-not-matching-the-number-of-
variables-getting-assigned-to. Try to keep up, Kenny!
> Again, if other languages do the same, god bless 'em. I mentioned C only
> as evidence that programmers do sometimes need such a thing, mentioning
> only in passing that Lisp made it more elegant.
>
Fully agreed. I write C and C++ for a living, and while my experience
with Lisp is limited compared to the almost undless fountain of
knowledge contained by the elders frequenting c.l.l, I'd like to think
that many things could be expressed shorter and more to-the-point in
Lisp. And likewise, some things still feel a bit unnatural in Lisp --
but just you wait, LOOP! One day, one day...
--
Mikael Jansson
Lisp? Vim? Yeah! http://mikael.jansson.be/hacking/limp
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <48847829$0$20920$607ed4bc@cv.net>
Mikael Jansson wrote:
> On Jul 20, 6:08 pm, Kenny <·········@gmail.com> wrote:
>> Mikael Jansson wrote:
>>> In all fairness, if you don't take the extreme view of languages,
>> Fairness? Unextreme? From Kenny? One minute of play and you are down
>> two-nil. :)
>>
> Hey, who made you the judge?
He has a lot to learn.
>> I presume Pythn allows me to ignore any number of returned values or you
>> would not have offered this as an equivalent.
>>
> No, because I changed opinions mid-post and realized Python only gives
> you the equivalent of destructuring-bind with the &rest argument
> defaulting for the values-returned-but-not-matching-the-number-of-
> variables-getting-assigned-to. Try to keep up, Kenny!
Oh, that was a complete reversal? Next time meet me half way: instead of
saying "granted" just delete the article unsent, your change of opinion
will stand out better.
>
>> Again, if other languages do the same, god bless 'em. I mentioned C only
>> as evidence that programmers do sometimes need such a thing, mentioning
>> only in passing that Lisp made it more elegant.
>>
> Fully agreed. I write C and C++ for a living, and while my experience
> with Lisp is limited compared to the almost undless fountain of
> knowledge contained by the elders frequenting c.l.l, I'd like to think
> that many things could be expressed shorter and more to-the-point in
> Lisp.
Now here's a rarity, a newcomer to Lisp who has some changes they want
to make. Generally this is not a problem since most of you also start
work immediately on your own lisp and can edify us by example. My one
concern is how much progress you will make if your opinions on language
design do not last even one article.
:)
kt
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5v8al$j3i$2@aioe.org>
Kenny wrote:
> Ah, the smoking gun. No, sir, we have plenty of ways to represent
> compound values. VALUES exists to allow us to return a result all by its
> lonesome, but also provide the caller with other info if they care. Note
> the "if". C being a good example: I want to return a pointer and mention
> something else, say, how much remains. Pass me null for where to write
> how much remains and I won't bother. Fortunately Lisp is more elegant,
> the callee can return the info and I can Just Ignore It. In both
> languages, however, the result remains pure and unsullied by having to
> tote around extra baggage.
Except the "extra baggage" you refer is actually shorter than the Lisp
equivalent, the semantics you call "elegant" is a fountain of bugs and your
only comparison is with C because you secretly know how poorly Lisp fares
against modern languages. Other than that, nice comeback.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Jul 20, 1:41 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Kenny wrote:
> > Ah, the smoking gun. No, sir, we have plenty of ways to represent
> > compound values. VALUES exists to allow us to return a result all by its
> > lonesome, but also provide the caller with other info if they care. Note
> > the "if". C being a good example: I want to return a pointer and mention
> > something else, say, how much remains. Pass me null for where to write
> > how much remains and I won't bother. Fortunately Lisp is more elegant,
> > the callee can return the info and I can Just Ignore It. In both
> > languages, however, the result remains pure and unsullied by having to
> > tote around extra baggage.
>
> Except the "extra baggage" you refer is actually shorter than the Lisp
> equivalent, the semantics you call "elegant" is a fountain of bugs and your
> only comparison is with C because you secretly know how poorly Lisp fares
> against modern languages. Other than that, nice comeback.
>
Mind sharing a drop from this fountain of bugs?
--
Mikael Jansson
http://mikael.jansson.be/
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <488358b6$0$7317$607ed4bc@cv.net>
Jon Harrop wrote:
> Kenny wrote:
>> Ah, the smoking gun. No, sir, we have plenty of ways to represent
>> compound values. VALUES exists to allow us to return a result all by its
>> lonesome, but also provide the caller with other info if they care. Note
>> the "if". C being a good example: I want to return a pointer and mention
>> something else, say, how much remains. Pass me null for where to write
>> how much remains and I won't bother. Fortunately Lisp is more elegant,
>> the callee can return the info and I can Just Ignore It. In both
>> languages, however, the result remains pure and unsullied by having to
>> tote around extra baggage.
>
> Except the "extra baggage" you refer is actually shorter than the Lisp
> equivalent, the semantics you call "elegant" is a fountain of bugs and your
> only comparison is with C because you secretly know how poorly Lisp fares
> against modern languages. Other than that, nice comeback.
>
Jonny http://www.theoryyalgebra.com/ boy, I
http://www.theoryyalgebra.com/ am http://www.theoryyalgebra.com/ busy,
go http://www.theoryyalgebra.com/ play with
http://www.theoryyalgebra.com/ some of http://www.theoryyalgebra.com/
the others. My chew toy these days is: http://www.theoryyalgebra.com/
(June 1 starting to look like July 25, Our Birthday.)
hth, http://www.theoryyalgebra.com/
From: Stanisław Halik
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5s91g$cvv$3@opal.icpnet.pl>
thus spoke Kenny <·········@gmail.com>:
>>>> Since then we have Prolog saying everything is unification and Steele
>>>> saying everything is a constraint and Harrop saying everything is a
>>>> pattern and more than one failed language saying everything is an
>>>> object, all because they have lost site of why we program these damn
>>>> things and fallen in love with particular language syntax.
>>> Everything is lists?
>> <g> ...or vectors or hash tables or complex numbers or defstructs or
>> defclasses or...
>> The one Lisp mandate seems to be that code be data and how cute is it
>> that this is a meta-mandate?
> "First principles are Good Things. In Lisp, every form returns a value.
> That first principle works great. This despite Tilton's Law of
> Programming: All X all the time is the root of all evil."
Not all do, some perform a non-local exit. Such an interpretation
prevents the falsification of The Kennyness Law.
:-)
--
The great peril of our existence lies in the fact that our diet consists
entirely of souls. -- Inuit saying
On Sun, 13 Jul 2008 21:56:59 +0100, Jon Harrop <···@ffconsultancy.com> said:
| Vassil Nikolov wrote:
| ...
|| No. I was asking for pattern matching for data structure with
|| repeated components where the number of repetitions is not known
|| before run-time. It happens to be possible to use `transpose' for
|| the particular (simple) example I used, but "essentially asking for
|| a transpose" can serve as the answer only if it is proved that _all_
|| such cases can be dealt with by `transpose', which is at best an
|| open question.
| I cannot infer what you mean by "components"
Constituent parts of structures being matched against patterns.
| and what "such cases"
Where said parts are repeated an unspecified number of times, and we
want enhanced pattern matching that can handle that.
| you are referring to. Can you give an example that is not trivially
| reducible?
Perhaps
[[[x1 v1] [x2 v2] ...] f1 f2 ...] -> [[[x1 x2 ...] f1 f2 ...] v1 v2 ...]
---can this be done with `transpose' without selectors and at the
same level of clarity?
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5g2qc$on2$1@aioe.org>
Vassil Nikolov wrote:
> On Sun, 13 Jul 2008 21:56:59 +0100, Jon Harrop <···@ffconsultancy.com>
> said:
> | Vassil Nikolov wrote:
> | ...
> || No. I was asking for pattern matching for data structure with
> || repeated components where the number of repetitions is not known
> || before run-time. It happens to be possible to use `transpose' for
> || the particular (simple) example I used, but "essentially asking for
> || a transpose" can serve as the answer only if it is proved that _all_
> || such cases can be dealt with by `transpose', which is at best an
> || open question.
>
> | I cannot infer what you mean by "components"
>
> Constituent parts of structures being matched against patterns.
>
> | and what "such cases"
>
> Where said parts are repeated an unspecified number of times, and we
> want enhanced pattern matching that can handle that.
You can already pattern match against structures with unknown numbers of
repeats. You want something more but I am not sure what exactly.
> | you are referring to. Can you give an example that is not trivially
> | reducible?
>
> Perhaps
>
> [[[x1 v1] [x2 v2] ...] f1 f2 ...] -> [[[x1 x2 ...] f1 f2 ...] v1 v2
> [[[...]
>
> ---can this be done with `transpose' without selectors and at the
> same level of clarity?
I do know what you mean by "selectors" and "same level of clarity" is, of
course, subjective. Indeed, I am not sure what your pseudo code is supposed
to do. The square brackets do not match. I do not know what they are
supposed to be representing anyway (lists? trees? cons cells?).
Perhaps this implements what you are trying to describe:
xvs::fs -> map fst xvs :: fs @ map snd xvs
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Mon, 14 Jul 2008 18:35:10 +0100, Jon Harrop <···@ffconsultancy.com> said:
| Vassil Nikolov wrote:
|| On Sun, 13 Jul 2008 21:56:59 +0100, Jon Harrop <···@ffconsultancy.com>
|| said:
|| ...
|| Where said parts are repeated an unspecified number of times, and we
|| want enhanced pattern matching that can handle that.
| You can already pattern match against structures with unknown numbers of
| repeats.
But can I have a match that binds a variable to a repeated part of a
structure, rather than to the whole repetition?
| You want something more but I am not sure what exactly.
I very much hope this post explains it.
|| | you are referring to. Can you give an example that is not trivially
|| | reducible?
||
|| Perhaps
||
|| [[[x1 v1] [x2 v2] ...] f1 f2 ...] -> [[[x1 x2 ...] f1 f2 ...] v1 v2
|| [[[...]
||
|| ---can this be done with `transpose' without selectors and at the
|| same level of clarity?
| I do know what you mean by "selectors"
Operators that return parts of a structure (as in "partial inverses
of constructors"), e.g. fst, snd, CAR, CDR, etc.
| and "same level of clarity" is, of course, subjective. Indeed, I am
| not sure what your pseudo code is supposed to do. The square
| brackets do not match.
It seems that line wrapping or quoting mangled it; here it is again:
[[[x1 v1] [x2 v2] ...] f1 f2 ...] -> [[[x1 x2 ...] f1 f2 ...] v1 v2 ...]
and the intent is to perform the transformation that, for example,
converts
[[[1 2] [3 4]] 5 6 7]
into
[[[1 3] 5 6 7] 2 4]
| I do not know what they are supposed to be representing anyway
| (lists? trees? cons cells?).
Informally and abstractly, heterogeneous sequences.
| Perhaps this implements what you are trying to describe:
| xvs::fs -> map fst xvs :: fs @ map snd xvs
Yes, and while it is indeed succinct, it still does not use pattern
matching in a non-trivial way and significantly relies on selectors;
compare then to either of these Common Lisp definitions,
;; s ::= (((x1 v1) (x2 v2) ...) f1 f2 ...)
(lambda (s)
`((,(mapcar #'first (first s)) ,@(rest s)) ,@(mapcar #'second (first s))))
and
(lambda (s)
(destructuring-bind ((&rest xvs) &rest fs) s
`((,(mapcar #'first xvs) ,@fs) ,@(mapcar #'second xvs))))
(the latter being essentially "isomorphic" to the Caml code above).
What I am after could be expressed as the hypothetical
(lambda (s)
(destructuring-bind ((&star (xs vs)) &rest fs) s
`((,xs ,@fs) ,@vs)))
(which, of course, I ought to implement one fine day (or night)).
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
Vassil Nikolov <···············@pobox.com> writes:
> It seems that line wrapping or quoting mangled it; here it is again:
>
> [[[x1 v1] [x2 v2] ...] f1 f2 ...] -> [[[x1 x2 ...] f1 f2 ...] v1 v2 ...]
>
> and the intent is to perform the transformation that, for example,
> converts
>
> [[[1 2] [3 4]] 5 6 7]
>
> into
>
> [[[1 3] 5 6 7] 2 4]
What you want is more or less what the syntax-rules pattern matching in
Scheme does, no?
(define-syntax test
(syntax-rules ()
((test ((x1 v1) (x2 v2) ...) f1 f2 ...)
(quote (((x1 x2 ...) f1 f2 ...) v1 v2 ...)))))
(test ((1 2) (3 4)) 5 6 7)
=> (((1 3) 5 6 7) 2 4)
Nicolas
On Tue, 15 Jul 2008 11:13:09 +0200, Nicolas Neuss <········@math.uni-karlsruhe.de> said:
| Vassil Nikolov <···············@pobox.com> writes:
|| ...
|| [[[x1 v1] [x2 v2] ...] f1 f2 ...] -> [[[x1 x2 ...] f1 f2 ...] v1 v2 ...]
|| ...
| What you want is more or less what the syntax-rules pattern matching in
| Scheme does, no?
| (define-syntax test
| (syntax-rules ()
| ((test ((x1 v1) (x2 v2) ...) f1 f2 ...)
| (quote (((x1 x2 ...) f1 f2 ...) v1 v2 ...)))))
Indeed this performs the matching and transformation I described. I
want two more things, however:
1. More elaborate matching---another example is the one I used
earlier in this thread, the MAPCAR case, ideally as (I use
subscripts for the ellipses to try to indicate which repetition
matches where):
[f [x ..._1] ..._2] -> [[f x ..._2] ..._1]
e.g. [f [a b c] [1 2 3]] -> [[f a 1] [f b 2] [f c 3]]. Or has
someone proved that the above cannot be made to work at all (i.e. a
pattern matcher cannot ever be made to handle it), even with some
variations to add more information to the pattern to aid the
matcher?
2. The ability to do the transformation at run-time, i.e. for the
purposes of evaluation, and not (just) on program source, for the
purposes of macro expansion. (That ought to be easier than the
previous point.)
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5jfp6$321$1@aioe.org>
Vassil Nikolov wrote:
> What I am after could be expressed as the hypothetical
>
> (lambda (s)
> (destructuring-bind ((&star (xs vs)) &rest fs) s
> `((,xs ,@fs) ,@vs)))
>
> (which, of course, I ought to implement one fine day (or night)).
Ah yes, of course. What you are after is closer to parsing than ML-style
pattern matching. It is also reminiscent of Mathematica-style pattern
matching although (IIRC) even Mathematica cannot do what you describe
directly.
However, Mathematica has a real problem that its high-level declarativeness
in pattern matching comes at a grave cost in terms of productivity because
the performance of any given pattern match is wildly unpredictable. Even
relatively trivial Mathematica patterns can take asymptotically longer to
match than you might reasonable expect. An obvious example is decapitating
a sequence:
f[{h_, t___}] := ...
That is O(n) in Mathematica because the tail sequence is eagerly copied but
O(1) in all other pattern matchers that I am familiar with.
I think your suggestion is an excellent idea for pattern matching in Lisp
though, provided the standard dictates the asymptotic complexities of a set
of core patterns (like ML-style patterns). Programmers may then use more
sophisticated patterns at will but have the fall back of predictability if
they hit performance problems.
Good idea!
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal Costanza
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <6dvb2nF4ghodU2@mid.individual.net>
Jon Harrop wrote:
> Different languages have chosen different sweet spots.
Maybe you should meditate on this for a while.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Kaz Kylheku
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <20080711122921.640@gmail.com>
On 2008-07-11, Jon Harrop <···@ffconsultancy.com> wrote:
> Try any of the above languages and the enormous advancement made by built-in
> pattern matching will be blindingly obvious.
>
> Compare this OCaml code:
Can't be parsed without a detailed knowledge of OCaml syntax.
> let rec intersect orig dir (l, _ as hit) (center, radius, scene) =
> match ray_sphere orig dir center radius, scene with
> | lam', _ when lam' >= lam -> hit
> | lam', [] -> lam', unitise (orig +| lam' *| dir -| center)
> | _, scenes -> List.fold_left (intersect orig dir) hit scenes
54 tokens. Maybe more; it's not clear what is and is not a token in this
syntax.
> With the equivalent Common Lisp:
Can be reduced to an abstract syntax tree by someone who doesn't know Common
Lisp.
> (defun intersect (orig dir scene)
> (labels ((aux (lam normal scene)
> (let* ((center (sphere-center scene))
> (lamt (ray-sphere orig
> dir
> center
> (sphere-radius scene))))
> (if (>= lamt lam)
> (values lam normal)
> (etypecase scene
> (group
> (dolist (kid (group-children scene))
> (setf (values lam normal)
> (aux lam normal kid)))
Your ``fold_left'' function improves code density, and has nothing to do with
pattern matching. Here the analogous logic is performed by an open-coded loop.
Some kind of LOOP would probably be more dense. Or you could actually
use some Common Lisp version FOLD-LEFT.
You've increased verbosity by using types like GROUP and SPHERE, which don't
appear in the OCaml.
If the type here was simply CONS, then you wouldn't have to call the accessor
(GROUP-CHILDREN SCENE) to pull out the scene elements. So that's one less
abstract syntax tree node right away.
> (values lam normal))
> (sphere
> (values lamt (unitise
> (-v (+v orig (*v lamt dir)) center)))))))))
> (aux infinity zero scene)))
62 tokens.
> The considerable difference in verbosity is primarily due to pattern
The Lisp is actually only 15% larger in abstract syntax tree size.
> matching, which is used both for destructuring (replacing
> MULTIPLE-VALUE-BIND, DESTRUCTURING-BIND, CAR, CDR etc.) and for dispatch
> (replacing COND etc.).
>
> With pattern matching, the syntactic overhead is as low as possible, e.g.
Syntactic size is not the entire overhead of syntax.
There is also the mental overhead of sorting through incomprehensible line
noise.
Terseness isn't everything, and let's not forget that it is one dominant
attribute of obfuscated programming contest entries.
> destructuring a pair return value:
>
> # let polar x y = sqrt(x *. x +. y *. y), atan2 y x;;
This looks like incomrehensible drivel. More parentheses are needed to show
what goes with what.
I have to resort to the semantics of Cartesian to polar to work out the idiotic
syntax!!!
In any reasonable programming language, the comma would have a the lowest
precedence.
Here is a better syntax:
let polar (x, y) = (sqrt(x *. x +. y *. y), atan2(y, x));
> val polar : float -> float -> float * float = <fun>
I'm guessing this is the output seen in REPL? But I can't make head or tail out
of it. This polar is supposed to take two numbers, and yield two numbers. So
isn't it a mapping from (float, float) -> (float, float)?
What is the associativity and precedence of -> ?
> # let r, theta = polar 3. 4.;;
> val r : float = 5.
> val theta : float = 0.927295218001612187
> Compared to:
>
> * (defun polar (x y)
> (values (sqrt (+ (* x x) (* y y))) (atan y x)))
Ahh, clear structure. No associativity and precedence bullshit to deal with.
Even someone who doesn't know Common Lisp can at least work out the
abstract syntax tree.
It's obvious that the major syntax here is
(defun polar (x y) (values ...))
That is, a DEFUN node with three children.
> Pattern matching improves most function definitions.
Huh? The polar function doesn't use pattern matching. The terseness of the
definition depends on a bizarre syntax notation full of associativity and
precedence rules, and on slicker handling of multiple values.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5912r$3dk$1@aioe.org>
Kaz Kylheku wrote:
> On 2008-07-11, Jon Harrop <···@ffconsultancy.com> wrote:
>> let rec intersect orig dir (l, _ as hit) (center, radius, scene) =
>> match ray_sphere orig dir center radius, scene with
>> | lam', _ when lam' >= lam -> hit
>> | lam', [] -> lam', unitise (orig +| lam' *| dir -| center)
>> | _, scenes -> List.fold_left (intersect orig dir) hit scenes
>
> 54 tokens.
Yes.
>> (defun intersect (orig dir scene)
>> (labels ((aux (lam normal scene)
>> (let* ((center (sphere-center scene))
>> (lamt (ray-sphere orig
>> dir
>> center
>> (sphere-radius scene))))
>> (if (>= lamt lam)
>> (values lam normal)
>> (etypecase scene
>> (group
>> (dolist (kid (group-children scene))
>> (setf (values lam normal)
>> (aux lam normal kid)))
>
> Your ``fold_left'' function improves code density, and has nothing to do
> with
> pattern matching. Here the analogous logic is performed by an open-coded
> loop.
>
> Some kind of LOOP would probably be more dense. Or you could actually
> use some Common Lisp version FOLD-LEFT.
>
> You've increased verbosity by using types like GROUP and SPHERE, which
> don't appear in the OCaml.
Note that the Lisp was written by Juho Snellman, one of the authors of SBCL,
and not by me. Those types are implicit in the OCaml but they are both
inferred and anonymous so they add no syntactic overhead at all.
> If the type here was simply CONS, then you wouldn't have to call the
> accessor (GROUP-CHILDREN SCENE) to pull out the scene elements. So that's
> one less abstract syntax tree node right away.
Your Lisp code would be littered with CAR and CDR instead.
>> (values lam normal))
>> (sphere
>> (values lamt (unitise
>> (-v (+v orig (*v lamt dir))
>> center)))))))))
>> (aux infinity zero scene)))
>
> 62 tokens.
Only if you ignore the superfluous parentheses that make up most of the Lisp
code, which is absurd because they are essential in Lisp.
In reality, the Lisp has 125 tokens.
>> The considerable difference in verbosity is primarily due to pattern
>
> The Lisp is actually only 15% larger in abstract syntax tree size.
The Lisp is 2.3x longer by tokens if you count the (essential) parentheses.
>> matching, which is used both for destructuring (replacing
>> MULTIPLE-VALUE-BIND, DESTRUCTURING-BIND, CAR, CDR etc.) and for dispatch
>> (replacing COND etc.).
>>
>> With pattern matching, the syntactic overhead is as low as possible, e.g.
>
> Syntactic size is not the entire overhead of syntax.
>
> There is also the mental overhead of sorting through incomprehensible line
> noise.
>
> Terseness isn't everything, and let's not forget that it is one dominant
> attribute of obfuscated programming contest entries.
You may have noticed that almost all programmers disagree with you: huge
numbers of superfluous parentheses being one of the most complained about
disadvantages of Lisp.
>> destructuring a pair return value:
>>
>> # let polar x y = sqrt(x *. x +. y *. y), atan2 y x;;
>
> This looks like incomrehensible drivel. More parentheses are needed to
> show what goes with what.
No, more parentheses are not needed.
> I have to resort to the semantics of Cartesian to polar to work out the
> idiotic syntax!!!
>
> In any reasonable programming language, the comma would have a the lowest
> precedence.
>
> Here is a better syntax:
>
> let polar (x, y) = (sqrt(x *. x +. y *. y), atan2(y, x));
>
>> val polar : float -> float -> float * float = <fun>
>
> I'm guessing this is the output seen in REPL?
Yes. That is the inferred type.
> But I can't make head or
> tail out of it. This polar is supposed to take two numbers, and yield two
> numbers. So isn't it a mapping from (float, float) -> (float, float)?
My "polar" function was curried.
> What is the associativity and precedence of -> ?
Right associative and low precedence.
>> # let r, theta = polar 3. 4.;;
>> val r : float = 5.
>> val theta : float = 0.927295218001612187
>
>> Compared to:
>>
>> * (defun polar (x y)
>> (values (sqrt (+ (* x x) (* y y))) (atan y x)))
>
> Ahh, clear structure. No associativity and precedence bullshit to deal
> with.
>
> Even someone who doesn't know Common Lisp can at least work out the
> abstract syntax tree.
You say that as if we were not all capable of deciphering the precedence of
addition and multiplication by the age of 5.
> It's obvious that the major syntax here is
>
> (defun polar (x y) (values ...))
>
> That is, a DEFUN node with three children.
>
>> Pattern matching improves most function definitions.
>
> Huh? The polar function doesn't use pattern matching.
Every argument to every function is a pattern in all MLs. When you write:
let polar(x, y) = ...
the "(x, y)", the "x" and the "y" are all patterns and the pattern matcher
automates the dissection of the pair.
So you can write:
let f((x, y), z) = ...
or:
let f(x, y as pair) = ...
or:
let f(`A x | `B x) = ...
> The terseness of
> the definition depends on a bizarre syntax notation full of associativity
> and precedence rules, and on slicker handling of multiple values.
What you call "slicker handling of multiple values" is largely thanks to
pattern matching.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <871w1zzs3k.fsf@geddis.org>
Jon Harrop <···@ffconsultancy.com> wrote on Sat, 12 Jul 2008:
> Kaz Kylheku wrote:
>> 62 tokens.
>
> Only if you ignore the superfluous parentheses that make up most of the Lisp
> code, which is absurd because they are essential in Lisp.
What ought to matter is the cognitive effort required to write or understand
the code. The parentheses in Lisp do not occupy cognitive effort. Real Lisp
programmers (but perhaps not you) don't really even see them.
So, yes, it is appropriate to "ignore" the parentheses, when estimating how
complex a piece of Lisp code is.
>> Terseness isn't everything, and let's not forget that it is one dominant
>> attribute of obfuscated programming contest entries.
>
> You may have noticed that almost all programmers disagree with you: huge
> numbers of superfluous parentheses being one of the most complained about
> disadvantages of Lisp.
Complained about ... by NON-lisp programmers. People with no experience in
the language believe (incorrectly) that the parentheses require cognitive
effort and make the code more complex.
ACTUAL lisp programmers do not cite the parentheses as a disadvantage.
(Conversely, most cite them as an advantage, particularly when editing code.)
In fact, from time to time various lisp programmers embark on a syntax change
to lisp, to eliminate the parentheses, spurred by the same error you make here.
Each time, they eventually realize that nobody cares about their efforts,
and they were wrong to believe that they were solving a real problem in the
language.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Hard work never killed anybody, but why take a chance?
-- Charlie McCarthy (ventriloquist puppet)
On 12 Lug, 05:41, Don Geddis <····@geddis.org> wrote:
> Jon Harrop <····@ffconsultancy.com> wrote on Sat, 12 Jul 2008:
>
> > Kaz Kylheku wrote:
> >> 62 tokens.
>
> > Only if you ignore the superfluous parentheses that make up most of the Lisp
> > code, which is absurd because they are essential in Lisp.
>
> What ought to matter is the cognitive effort required to write or understand
> the code. The parentheses in Lisp do not occupy cognitive effort. Real Lisp
> programmers (but perhaps not you) don't really even see them.
As long as you work with an editor that does parentheses matching,
otherwise you have to either use C-style identation (which makes Lisp
programs extremely verbose) or you have to count parentheses.
> So, yes, it is appropriate to "ignore" the parentheses, when estimating how
> complex a piece of Lisp code is.
>
> >> Terseness isn't everything, and let's not forget that it is one dominant
> >> attribute of obfuscated programming contest entries.
>
> > You may have noticed that almost all programmers disagree with you: huge
> > numbers of superfluous parentheses being one of the most complained about
> > disadvantages of Lisp.
>
> Complained about ... by NON-lisp programmers. People with no experience in
> the language believe (incorrectly) that the parentheses require cognitive
> effort and make the code more complex.
>
> ACTUAL lisp programmers do not cite the parentheses as a disadvantage.
> (Conversely, most cite them as an advantage, particularly when editing code.)
Yet parentheses are an obstacle in the learning curve of the language.
> In fact, from time to time various lisp programmers embark on a syntax change
> to lisp, to eliminate the parentheses, spurred by the same error you make here.
> Each time, they eventually realize that nobody cares about their efforts,
> and they were wrong to believe that they were solving a real problem in the
> language.
Python is a sort of Lisp without parentheses and it's much more
popular than CL and Scheme, thus I don't think that nobody cares.
I agree that the parenthesized notation can be more handy once you get
used to it and you have an editor that supports it, but it certainly
scares newcomers.
From: Patrick May
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <m263rbqarc.fsf@spe.com>
Vend <······@virgilio.it> writes:
> On 12 Lug, 05:41, Don Geddis <····@geddis.org> wrote:
>> > You may have noticed that almost all programmers disagree with
>> > you: huge numbers of superfluous parentheses being one of the
>> > most complained about disadvantages of Lisp.
>>
>> Complained about ... by NON-lisp programmers. People with no
>> experience in the language believe (incorrectly) that the
>> parentheses require cognitive effort and make the code more
>> complex.
>>
>> ACTUAL lisp programmers do not cite the parentheses as a
>> disadvantage. (Conversely, most cite them as an advantage,
>> particularly when editing code.)
>
> Yet parentheses are an obstacle in the learning curve of the
> language.
I disagree. Relative to the effort required to understand
functional programming idioms, getting used to the parentheses is
trivial. In fact, recognizing that the parentheses delineate the AST
is a significant milestone in understanding.
The parentheses are anything but superfluous.
Regards,
Patrick
------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
···@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Kaz Kylheku
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <20080714114845.218@gmail.com>
On 2008-07-12, Vend <······@virgilio.it> wrote:
> Yet parentheses are an obstacle in the learning curve of the language.
Everything that is in a learning curve is, by definition, an obstacle.
Programming languages that use LR(k) type syntax also have a learning curve.
To working with programs in those languages, you have to be able to parse the
syntax. Parsing that syntax is far more difficult than parsing nested
parentheses.
You can get considerable assistance from your text editor with those
parentheses, too: reformatting, treating a parenthesized section as a unit of
text, etc.
>> In fact, from time to time various lisp programmers embark on a syntax change
>> to lisp, to eliminate the parentheses, spurred by the same error you make here.
>> Each time, they eventually realize that nobody cares about their efforts,
>> and they were wrong to believe that they were solving a real problem in the
>> language.
>
> Python is a sort of Lisp without parentheses and it's much more
> popular than CL and Scheme, thus I don't think that nobody cares.
But then the functional programming languages without parentheses are less
popular than CL and Scheme. So whereas it's obvious that people care about
something, it's not clear that parentheses are it!
Python has parentheses, in a way. They are encoded in the whitespace, and have
a similar role. For instance, an ``if else'' ambiguity could not exist in
Python. Indentation makes it obvious which if clause an else goes with.
The whitespace structure of Python explicitly encodes much of the abstract
syntax tree (modulo expressions). Lisp parentheses also explicitly encode the
AST structure.
Most Python programmers would probably gack at the syntactic bullshit that has
been piled into things like Haskell, OCaml, etc.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5gb3j$sih$1@aioe.org>
Kaz Kylheku wrote:
> On 2008-07-12, Vend <······@virgilio.it> wrote:
>> Yet parentheses are an obstacle in the learning curve of the language.
>
> Everything that is in a learning curve is, by definition, an obstacle.
Features that reduce the learning curve are a counter example: being both in
the learning curve and not an obstacle.
>> Python is a sort of Lisp without parentheses and it's much more
>> popular than CL and Scheme, thus I don't think that nobody cares.
>
> But then the functional programming languages without parentheses are less
> popular than CL and Scheme.
Erlang, Haskell, OCaml and F# are all counter examples, being functional
languages without superfluous parentheses that are all much more popular
than Common Lisp and Scheme.
> The whitespace structure of Python explicitly encodes much of the abstract
> syntax tree (modulo expressions). Lisp parentheses also explicitly encode
> the AST structure.
The following operators from Lisp are all counter examples:
`
,
'
#
@
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 14 Lug, 21:56, Jon Harrop <····@ffconsultancy.com> wrote:
> ...
It finally happened!
As of today (2008-07-14), the number of postings on comp.lang.lisp
finally exceed the respective number of OCaml postings:
comp.lang.lisp: 829
fa.caml: 747
Want to verify?
http://groups.google.com/groups/profile?enc_user=I_YUthUAAACWD_8VFKtRU42NeunWF-drfMq7BcOOnMpM9MYZ86CqoA
Wow!
You may start to bet on my soon conversion!
Stay tuned!
One year or the other, it will finally happen!
Jon Harrop
On Mon, 14 Jul 2008 13:22:45 -0700 (PDT),
···················@gmail.com wrote:
>On 14 Lug, 21:56, Jon Harrop <····@ffconsultancy.com> wrote:
>> ...
>
>It finally happened!
>
>As of today (2008-07-14), the number of postings on comp.lang.lisp
>finally exceed the respective number of OCaml postings:
>
>comp.lang.lisp: 829
>fa.caml: 747
>
>Want to verify?
>http://groups.google.com/groups/profile?enc_user=I_YUthUAAACWD_8VFKtRU42NeunWF-drfMq7BcOOnMpM9MYZ86CqoA
>
>Wow!
>
>You may start to bet on my soon conversion!
>Stay tuned!
>One year or the other, it will finally happen!
>
>Jon Harrop
You make the mistake of equating numbers with popularity. You'd do
better to count the participants in those forums rather than the
number of messages. Ocaml's numbers are so large because all 3 of its
users constantly debate how to win over Lispers. Lispers, OTOH, have
better things to do.
George
--
for email reply remove "/" from address
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5jgjc$57o$1@aioe.org>
George Neuner wrote:
> You make the mistake of equating numbers with popularity. You'd do
> better to count the participants in those forums rather than the
> number of messages. Ocaml's numbers are so large because all 3 of its
> users constantly debate how to win over Lispers. Lispers, OTOH, have
> better things to do.
Ironically, Google Groups already proved the exact opposite:
http://groups.google.com/group/fa.caml/about
http://groups.google.com/group/comp.lang.lisp/about
c.l.lisp has fewer contributors than fa.caml but 4-5x as many posts.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
Jon Harrop a écrit :
> George Neuner wrote:
> > You make the mistake of equating numbers with popularity. You'd do
> > better to count the participants in those forums rather than the
> > number of messages. Ocaml's numbers are so large because all 3 of its
> > users constantly debate how to win over Lispers. Lispers, OTOH, have
> > better things to do.
>
> Ironically, Google Groups already proved the exact opposite:
>
> http://groups.google.com/group/fa.caml/about
> http://groups.google.com/group/comp.lang.lisp/about
>
> c.l.lisp has fewer contributors than fa.caml but 4-5x as many posts.
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> http://www.ffconsultancy.com/products/?u
comp.lang.lisp
Discussion about LISP.
Langue : Anglais
3834 subscribers, Messages per month: 1472, Usenet
It's just a little more than comp.lang.ml and fa.caml ...
Just a question : do you have a real job, or your job is just post in
different forum to make a strange buz around ML.
Best Regards,
Christophe
On 16 Lug, 09:57, Christophe <····················@birdtechnology.net>
wrote:
> do you have a real job
My important job in the WWWeb is called:
Cestoda (or simply: tapeworm), since I won't be able to survive
without unawares hosts (BTW, thank you all who still love to talk with
me!).
You should remember this name, its nice sound is really special:
C E S T O D A
Jon Harrop
···················@gmail.com a écrit :
> On 16 Lug, 09:57, Christophe <····················@birdtechnology.net>
> wrote:
> > do you have a real job
>
> My important job in the WWWeb is called:
>
> Cestoda (or simply: tapeworm), since I won't be able to survive
> without unawares hosts (BTW, thank you all who still love to talk with
> me!).
>
> You should remember this name, its nice sound is really special:
>
> C E S T O D A
>
> Jon Harrop
Harrop Introspection is Ok ... :)
Seriously, here, it's comp.lang.lisp, not ml forum.
ML have some qualities, perhaps, but it's not the good forum to make
buz around
Best Regards,
Christophe
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487e15a6$0$7348$607ed4bc@cv.net>
···················@gmail.com wrote:
> On 16 Lug, 09:57, Christophe <····················@birdtechnology.net>
> wrote:
>> do you have a real job
>
> My important job in the WWWeb is called:
>
> Cestoda (or simply: tapeworm), since I won't be able to survive
> without unawares hosts (BTW, thank you all who still love to talk with
> me!).
>
> You should remember this name, its nice sound is really special:
>
> C E S T O D A
You need a spell-checker, it's:
C H E W T O Y
...and cll hasn't had one like you since Erann changed his name.
Our little rubber froggy is easy to find, offers only token resistance,
never wears out -- lord knows he never wears out -- and makes satisfying
squeaking sounds when chewed.
Perfect!
hth,kt
On 16 Lug, 17:36, Kenny <·········@gmail.com> wrote:
> ...and cll hasn't had one like you since Erann changed his name.
(((Shhh!!! Please please don't tell it to the real JH!!!)))
Jon Harrop <···@ffconsultancy.com> wrote:
> The following operators from Lisp are all counter examples:
>
> `
> ,
> '
> #
> @
Huh? None of them is an operator.
In particular, #\`, #\, and #\' are macro characters (in the standard
readtable); #\# is a dispatching macro character, and ··@ is an
uninteresting constituent character which (like #\.) just happens to be
processed specially by the #\, macro.
But these inhabit the same syntactic world as #\" and #\(, which for
some reason you don't mention.
Perhaps you should learn more about the things you wish to criticize.
Then you might not appear so foolish.
-- [mdw]
> Yet parentheses are an obstacle in the learning curve of the language.
I find the parentheses the most refreshing part of my learning actually. For one they make it very easy to define order of execution when in other languages I've had to chain several operations to be able to clearly and consistently perform a single equation.
For another, both vim and emacs match parens out of the box so no matter what mood I'm in it's easy to jump right in. (I still prefer vim, but am slowly getting used to emacs as I try to follow the apparent Lisp way of doing things.)
-a
On Jul 16, 2:42 pm, Ariel <····@mail.poo> wrote:
> > Yet parentheses are an obstacle in the learning curve of the language.
>
> I find the parentheses the most refreshing part of my learning actually. For one they make it very easy to define order of execution when in other languages I've had to chain several operations to be able to clearly and consistently perform a single equation.
>
> For another, both vim and emacs match parens out of the box so no matter what mood I'm in it's easy to jump right in. (I still prefer vim, but am slowly getting used to emacs as I try to follow the apparent Lisp way of doing things.)
>
(plug "Did you try Limp yet?" :shame nil)
--
Mikael Jansson
http://mikael.jansson.be/hacking/limp
On 12 Lug, 05:41, Don Geddis <····@geddis.org> wrote:
> Jon Harrop <····@ffconsultancy.com> wrote on Sat, 12 Jul 2008:
>
> > Kaz Kylheku wrote:
> >> 62 tokens.
>
> > Only if you ignore the superfluous parentheses that make up most of the Lisp
> > code, which is absurd because they are essential in Lisp.
>
> What ought to matter is the cognitive effort required to write or understand
> the code. The parentheses in Lisp do not occupy cognitive effort. Real Lisp
> programmers (but perhaps not you) don't really even see them.
As long as you work with an editor that does parentheses matching,
otherwise you have to either use C-style identation (which makes Lisp
programs extremely verbose) or you have to count parentheses.
> So, yes, it is appropriate to "ignore" the parentheses, when estimating how
> complex a piece of Lisp code is.
>
> >> Terseness isn't everything, and let's not forget that it is one dominant
> >> attribute of obfuscated programming contest entries.
>
> > You may have noticed that almost all programmers disagree with you: huge
> > numbers of superfluous parentheses being one of the most complained about
> > disadvantages of Lisp.
>
> Complained about ... by NON-lisp programmers. People with no experience in
> the language believe (incorrectly) that the parentheses require cognitive
> effort and make the code more complex.
>
> ACTUAL lisp programmers do not cite the parentheses as a disadvantage.
> (Conversely, most cite them as an advantage, particularly when editing code.)
Yet parentheses are an obstacle in the learning curve of the language.
> In fact, from time to time various lisp programmers embark on a syntax change
> to lisp, to eliminate the parentheses, spurred by the same error you make here.
> Each time, they eventually realize that nobody cares about their efforts,
> and they were wrong to believe that they were solving a real problem in the
> language.
Python is a sort of Lisp without parentheses and it's much more
popular than CL and Scheme, thus I don't think that nobody cares.
I agree that the parenthesized notation can be more handy once you get
used to it and you have an editor that supports it, but it certainly
scares newcomers.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5adh3$1bc$1@aioe.org>
Don Geddis wrote:
> Jon Harrop <···@ffconsultancy.com> wrote on Sat, 12 Jul 2008:
>> Kaz Kylheku wrote:
>>> 62 tokens.
>>
>> Only if you ignore the superfluous parentheses that make up most of the
>> Lisp code, which is absurd because they are essential in Lisp.
>
> What ought to matter is the cognitive effort required to write or
> understand the code.
But we cannot quantify that so we quantify related features like lines,
bytes, non-whitespace bytes and tokens. Lisp is grossly verbose by all of
those objective metrics.
> The parentheses in Lisp do not occupy cognitive effort. Real Lisp
> programmers (but perhaps not you) don't really even see them.
Real Lisp programmers (not you) recognise the inherent flaws in the language
and leave Lisp to use any of the better, more modern alternatives.
> So, yes, it is appropriate to "ignore" the parentheses, when estimating
> how complex a piece of Lisp code is.
Let's just see what that does. Consider this Lisp:
(define Y
(lambda (f)
(let ((future
(lambda (future)
(f (lambda (arg)
((future future) arg))))))
(future future))))
This is what you want to count:
define Y lambda f let future lambda future f lambda arg future future arg
future future
From which it is clearly impossible to decipher a working program. So your
point is obviously wrong. In reality, deliberately miscounting the number
of tokens was just clutching at straws. A desperate attempt to make Lisp
look less stupid.
>>> Terseness isn't everything, and let's not forget that it is one dominant
>>> attribute of obfuscated programming contest entries.
>>
>> You may have noticed that almost all programmers disagree with you: huge
>> numbers of superfluous parentheses being one of the most complained about
>> disadvantages of Lisp.
>
> Complained about ... by NON-lisp programmers.
And the expert Lisp programmers who invented Dylan, OCaml, SML...
> People with no experience
> in the language believe (incorrectly) that the parentheses require
> cognitive effort and make the code more complex.
So you are saying that people who do not even know Lisp complain about its
deficiencies? Has it occurred to you that people who do not even know Lisp
cannot be aware of its deficiencies?
> ACTUAL lisp programmers do not cite the parentheses as a disadvantage.
Circular argument: you just defined programmers who cite superfluous
parentheses as a disadvantage as non-Lisp programmers.
So what you're really saying is that people who don't know any better don't
complain. I'd agree with that but it applies just as much to the tiny
lingering Lisp community as it does elsewhere. Observe how Lispers not only
fail to understand the benefits of pattern matching but are even oblivious
to its increasingly widespread use.
> (Conversely, most cite them as an advantage, particularly when editing
> code.)
Because they are still using text editors because they are stuck in the 20th
century.
> In fact, from time to time various lisp programmers embark on a syntax
> change to lisp, to eliminate the parentheses, spurred by the same error
> you make here. Each time, they eventually realize that nobody cares about
> their efforts, and they were wrong to believe that they were solving a
> real problem in the language.
That is also obviously wrong. The creators of the ML family of languages
embarked on that journey and they not only completed it, creating a new
family of languages without superfluous parentheses, but the fruits of
their labour (OCaml and F#) are now used by more people than Lisp ever was.
The only way you could possibly have remained oblivious to this is by
burying your head in Lisp and not learning about the alternatives. So you
just made my point. Thank you.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Jul 12, 4:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Don Geddis wrote:
>
> > The parentheses in Lisp do not occupy cognitive effort. Real Lisp
> > programmers (but perhaps not you) don't really even see them.
>
> Real Lisp programmers (not you) recognise the inherent flaws in the language
> and leave Lisp to use any of the better, more modern alternatives.
Last I checked a lot of us are still hanging around here :)
> > So, yes, it is appropriate to "ignore" the parentheses, when estimating
> > how complex a piece of Lisp code is.
>
> Let's just see what that does. Consider this Lisp:
>
> (define Y
> (lambda (f)
> (let ((future
> (lambda (future)
> (f (lambda (arg)
> ((future future) arg))))))
> (future future))))
>
> This is what you want to count:
>
> define Y lambda f let future lambda future f lambda arg future future arg
> future future
>
> From which it is clearly impossible to decipher a working program. So your
> point is obviously wrong. In reality, deliberately miscounting the number
> of tokens was just clutching at straws. A desperate attempt to make Lisp
> look less stupid.
let val x = 40 + 2.0;;
yielding an error is what I call mildly stupid. :) After all we all
know the rules about '+' since junior high.
> And the expert Lisp programmers who invented Dylan, OCaml, SML...
Ahem, Dylan is a relatively good thing, but it is CL down to the
core. Cleaned up as much as you want, but that is what it is. And it
may be that is was Java to make Dylan wimper. Moreover, it has been
accepted that Dylan Big Mistake was to abandon S-expr syntax. As per
the ML lineage, it started earlier than current Lisp and it started in
the very mathematic/logic oriented world. And even that is a path
strewn with somewhat dead bodies. How many people remember OBJ?
> > People with no experience
> > in the language believe (incorrectly) that the parentheses require
> > cognitive effort and make the code more complex.
>
> So you are saying that people who do not even know Lisp complain about its
> deficiencies? Has it occurred to you that people who do not even know Lisp
> cannot be aware of its deficiencies?
>
> > ACTUAL lisp programmers do not cite the parentheses as a disadvantage.
>
> Circular argument: you just defined programmers who cite superfluous
> parentheses as a disadvantage as non-Lisp programmers.
>
> So what you're really saying is that people who don't know any better don't
> complain. I'd agree with that but it applies just as much to the tiny
> lingering Lisp community as it does elsewhere. Observe how Lispers not only
> fail to understand the benefits of pattern matching but are even oblivious
> to its increasingly widespread use.
I have not seen pattern-matching pop up in Java or C#...
> > (Conversely, most cite them as an advantage, particularly when editing
> > code.)
>
> Because they are still using text editors because they are stuck in the 20th
> century.
>
> > In fact, from time to time various lisp programmers embark on a syntax
> > change to lisp, to eliminate the parentheses, spurred by the same error
> > you make here. Each time, they eventually realize that nobody cares about
> > their efforts, and they were wrong to believe that they were solving a
> > real problem in the language.
>
> That is also obviously wrong. The creators of the ML family of languages
> embarked on that journey and they not only completed it, creating a new
> family of languages without superfluous parentheses, but the fruits of
> their labour (OCaml and F#) are now used by more people than Lisp ever was.
Your last sentence can only be greeted with a "maybe". As per the
first part, it is mostly true. Yet, there is *no* way to add new
language features to such languages: any new "language" in the style
of MLish syntax needs a fresh "compiler". Witness the interesting
PADS/ML work.
> The only way you could possibly have remained oblivious to this is by
> burying your head in Lisp and not learning about the alternatives. So you
> just made my point. Thank you.
... and telling people who chose to stick to CL (also after having
used ML/Haskellish systems and/or written other languages' compilers
and systems) that they are stupid where is getting you?
Cheers
--
Marco
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5akmd$tsi$1@aioe.org>
Marco Antoniotti wrote:
> On Jul 12, 4:00�pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Don Geddis wrote:
>> From which it is clearly impossible to decipher a working program. So
>> your point is obviously wrong. In reality, deliberately miscounting the
>> number of tokens was just clutching at straws. A desperate attempt to
>> make Lisp look less stupid.
>
> let val x = 40 + 2.0;;
>
> yielding an error is what I call mildly stupid. :) After all we all
> know the rules about '+' since junior high.
Except those rules do not apply in the context of floating point arithmetic,
e.g. associativity:
# (0.1 +. 0.2) +. 0.3 = 0.1 +. (0.2 +. 0.3);;
- : bool = false
>> And the expert Lisp programmers who invented Dylan, OCaml, SML...
>
> Ahem, Dylan is a relatively good thing, but it is CL down to the
> core. Cleaned up as much as you want, but that is what it is. And it
> may be that is was Java to make Dylan wimper. Moreover, it has been
> accepted that Dylan Big Mistake was to abandon S-expr syntax.
Mathematica abandoned s-exprs and is a resounding success.
> As per
> the ML lineage, it started earlier than current Lisp and it started in
> the very mathematic/logic oriented world. And even that is a path
> strewn with somewhat dead bodies.
All such paths are strewn with failures. That is an inevitable consequence
of progress.
>> > ACTUAL lisp programmers do not cite the parentheses as a disadvantage.
>>
>> Circular argument: you just defined programmers who cite superfluous
>> parentheses as a disadvantage as non-Lisp programmers.
>>
>> So what you're really saying is that people who don't know any better
>> don't complain. I'd agree with that but it applies just as much to the
>> tiny lingering Lisp community as it does elsewhere. Observe how Lispers
>> not only fail to understand the benefits of pattern matching but are even
>> oblivious to its increasingly widespread use.
>
> I have not seen pattern-matching pop up in Java or C#...
Look at Scala and F#.
>> > In fact, from time to time various lisp programmers embark on a syntax
>> > change to lisp, to eliminate the parentheses, spurred by the same error
>> > you make here. Each time, they eventually realize that nobody cares
>> > about their efforts, and they were wrong to believe that they were
>> > solving a real problem in the language.
>>
>> That is also obviously wrong. The creators of the ML family of languages
>> embarked on that journey and they not only completed it, creating a new
>> family of languages without superfluous parentheses, but the fruits of
>> their labour (OCaml and F#) are now used by more people than Lisp ever
>> was.
>
> Your last sentence can only be greeted with a "maybe". As per the
> first part, it is mostly true. Yet, there is *no* way to add new
> language features to such languages: any new "language" in the style
> of MLish syntax needs a fresh "compiler". Witness the interesting
> PADS/ML work.
That is not true. Look at camlp4, for example. Then look at the F# code dom.
Finally, consider what it takes to create a "fresh compiler" when the
source to the original is available.
>> The only way you could possibly have remained oblivious to this is by
>> burying your head in Lisp and not learning about the alternatives. So you
>> just made my point. Thank you.
>
> ... and telling people who chose to stick to CL (also after having
> used ML/Haskellish systems and/or written other languages' compilers
> and systems) that they are stupid where is getting you?
Again, you are just proving my point. You are claiming to be familiar with
alternatives whilst simultaneously making false statements about them and
then claiming that Lisp is Blub.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Jul 12, 6:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Marco Antoniotti wrote:
> > On Jul 12, 4:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> Don Geddis wrote:
> >> From which it is clearly impossible to decipher a working program. So
> >> your point is obviously wrong. In reality, deliberately miscounting the
> >> number of tokens was just clutching at straws. A desperate attempt to
> >> make Lisp look less stupid.
>
> > let val x = 40 + 2.0;;
>
> > yielding an error is what I call mildly stupid. :) After all we all
> > know the rules about '+' since junior high.
>
> Except those rules do not apply in the context of floating point arithmetic,
> e.g. associativity:
>
> # (0.1 +. 0.2) +. 0.3 = 0.1 +. (0.2 +. 0.3);;
> - : bool = false
Come on. You know what I am getting at. I can write very fast and
"type-correct" CL code in implementation X using
(low-level-stuff::*. 40.0 2.0)
Moreover
CL-USER 40 > (= (+ 1.0 (+ 2.0 3.0)) (+ (+ 1.0 2.0) 3.0)) ; LWM on an
Intel Mac.
T
So: which is "correct"? LWM or Ocaml? And why? Or isn't this just the
the well known "thou shall not compare two floating point numbers?"
>
> >> And the expert Lisp programmers who invented Dylan, OCaml, SML...
>
> > Ahem, Dylan is a relatively good thing, but it is CL down to the
> > core. Cleaned up as much as you want, but that is what it is. And it
> > may be that is was Java to make Dylan wimper. Moreover, it has been
> > accepted that Dylan Big Mistake was to abandon S-expr syntax.
>
> Mathematica abandoned s-exprs and is a resounding success.
Maybe. Deep, deep down, at least until some time ago, mathematica was
all Conses. I have not checked it lately.
> > As per
> > the ML lineage, it started earlier than current Lisp and it started in
> > the very mathematic/logic oriented world. And even that is a path
> > strewn with somewhat dead bodies.
>
> All such paths are strewn with failures. That is an inevitable consequence
> of progress.
>
> >> > ACTUAL lisp programmers do not cite the parentheses as a disadvantage.
>
> >> Circular argument: you just defined programmers who cite superfluous
> >> parentheses as a disadvantage as non-Lisp programmers.
>
> >> So what you're really saying is that people who don't know any better
> >> don't complain. I'd agree with that but it applies just as much to the
> >> tiny lingering Lisp community as it does elsewhere. Observe how Lispers
> >> not only fail to understand the benefits of pattern matching but are even
> >> oblivious to its increasingly widespread use.
>
> > I have not seen pattern-matching pop up in Java or C#...
>
> Look at Scala and F#.
Scala is a language on its own as is F#. I have not played around
with Scala (which looks like a "lets-look-like-C" language), but I
have been playing with F#, which is well integrated within MSVS and it
is nice to use. But that is a MLish language.
You are not seeing pattern matching popping up in Java 7 (is it?).
Same for the next C#.
> >> > In fact, from time to time various lisp programmers embark on a syntax
> >> > change to lisp, to eliminate the parentheses, spurred by the same error
> >> > you make here. Each time, they eventually realize that nobody cares
> >> > about their efforts, and they were wrong to believe that they were
> >> > solving a real problem in the language.
>
> >> That is also obviously wrong. The creators of the ML family of languages
> >> embarked on that journey and they not only completed it, creating a new
> >> family of languages without superfluous parentheses, but the fruits of
> >> their labour (OCaml and F#) are now used by more people than Lisp ever
> >> was.
>
> > Your last sentence can only be greeted with a "maybe". As per the
> > first part, it is mostly true. Yet, there is *no* way to add new
> > language features to such languages: any new "language" in the style
> > of MLish syntax needs a fresh "compiler". Witness the interesting
> > PADS/ML work.
>
> That is not true. Look at camlp4, for example. Then look at the F# code dom.
> Finally, consider what it takes to create a "fresh compiler" when the
> source to the original is available.
Nope. camlp4 does not count as an argument. It is a preprocessor
outside the core language. I do not know F# dom, but I would be
surprised if it were different.
Put it this way. Get me away from actual work and saturday afternoons
writing on CLL :) and I will get you an extended CL written *in* CL
that did pattern matching (avec pattern compilatiòn). Bottom line:
you can throw mud at Lisp... it still looks like a ball of mud. You
can't throw mud at OCaml, it'll just look like a muddy camel :) (Pun
intended and waiting for the unescapable witty retorts :) ).
> >> The only way you could possibly have remained oblivious to this is by
> >> burying your head in Lisp and not learning about the alternatives. So you
> >> just made my point. Thank you.
>
> > ... and telling people who chose to stick to CL (also after having
> > used ML/Haskellish systems and/or written other languages' compilers
> > and systems) that they are stupid where is getting you?
>
> Again, you are just proving my point. You are claiming to be familiar with
> alternatives whilst simultaneously making false statements about them and
> then claiming that Lisp is Blub.
What false statements am I making? (The camlp4 topic is one were we
obviously disagree, but I would not call that "misrepresenting").
We may look at certain aspects of the languages differently, but I am
not misrepresenting MLish languages at all. At least I do not think I
do. I reserve my sarcasm for true SLDJs :)
Cheers
--
Marco
On Jul 12, 12:08 pm, Marco Antoniotti <·······@gmail.com> wrote:
> On Jul 12, 6:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>
>
>
> > Marco Antoniotti wrote:
> > > On Jul 12, 4:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> > >> Don Geddis wrote:
> > >> From which it is clearly impossible to decipher a working program. So
> > >> your point is obviously wrong. In reality, deliberately miscounting the
> > >> number of tokens was just clutching at straws. A desperate attempt to
> > >> make Lisp look less stupid.
>
> > > let val x = 40 + 2.0;;
>
> > > yielding an error is what I call mildly stupid. :) After all we all
> > > know the rules about '+' since junior high.
>
> > Except those rules do not apply in the context of floating point arithmetic,
> > e.g. associativity:
>
> > # (0.1 +. 0.2) +. 0.3 = 0.1 +. (0.2 +. 0.3);;
> > - : bool = false
>
> Come on. You know what I am getting at. I can write very fast and
> "type-correct" CL code in implementation X using
>
> (low-level-stuff::*. 40.0 2.0)
>
> Moreover
>
> CL-USER 40 > (= (+ 1.0 (+ 2.0 3.0)) (+ (+ 1.0 2.0) 3.0)) ; LWM on an
> Intel Mac.
> T
Small integers can be represented in floating point exactly due the
way floating point is normally implemented; numbers like .1 don't have
a terminating sequence in binary.
Anyways, on x86 Linux, (= (+ (+ .1 .2) .3) (+ .1 (+ .2 .3))) returns T
on SBCL, CLISP, and ABCL. (I suspect that SINGLE-FLOAT-EPSILON has
something to do with it...)
On Sat, 12 Jul 2008 12:53:45 -0700 (PDT), Brian <··············@gmail.com> said:
| ...
| Anyways, on x86 Linux, (= (+ (+ .1 .2) .3) (+ .1 (+ .2 .3))) returns T
| on SBCL, CLISP, and ABCL. (I suspect that SINGLE-FLOAT-EPSILON has
| something to do with it...)
It's not that difficult to find a case of non-associativity, but
with this particular computation there happens to be no loss of
accuracy, e.g. with a 24-bit mantissa
(integer-decode-float 0.1) => 110011001100110011001101 -11011 1
(integer-decode-float 0.2) => 110011001100110011001101 -11010 1
(integer-decode-float 0.3) => 100110011001100110011010 -11001 1
(integer-decode-float (+ 0.1 0.2)) => 100110011001100110011010 -11001 1
(integer-decode-float (+ 0.1 (+ 0.2 0.3))) => 100110011001100110011010 -11000 1
(integer-decode-float (+ (+ 0.1 0.2) 0.3)) => 100110011001100110011010 -11000 1
(integer-decode-float (float 3/10)) => 100110011001100110011010 -11001 1
(integer-decode-float (float 6/10)) => 100110011001100110011010 -11000 1
where the results are printed in binary.
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5b6dd$dj9$1@aioe.org>
Marco Antoniotti wrote:
> On Jul 12, 6:03�pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Marco Antoniotti wrote:
>> > On Jul 12, 4:00�pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> >> Don Geddis wrote:
>> >> From which it is clearly impossible to decipher a working program. So
>> >> your point is obviously wrong. In reality, deliberately miscounting
>> >> the number of tokens was just clutching at straws. A desperate attempt
>> >> to make Lisp look less stupid.
>>
>> > let val x = 40 + 2.0;;
>>
>> > yielding an error is what I call mildly stupid. :) �After all we all
>> > know the rules about '+' since junior high.
>>
>> Except those rules do not apply in the context of floating point
>> arithmetic, e.g. associativity:
>>
>> # (0.1 +. 0.2) +. 0.3 = 0.1 +. (0.2 +. 0.3);;
>> - : bool = false
>
> Come on. You know what I am getting at.
I also know what you're glossing over.
What is the result of:
1. / 0
is it an integer divide by zero exception or the special floating point
infinity?
The static error you describe forces the programmer to clarify the code
before the program can be run. Claiming that to be "mildly stupid" is
mildly stupid. Implying that floats and ints should be interchangeable when
they have wildly different properties is considerably more stupid.
> I can write very fast and "type-correct" CL code in implementation X using
>
> (low-level-stuff::*. 40.0 2.0)
>
> Moreover
>
> CL-USER 40 > (= (+ 1.0 (+ 2.0 3.0)) (+ (+ 1.0 2.0) 3.0)) ; LWM on an
> Intel Mac.
> T
>
> So: which is "correct"? LWM or Ocaml?
If you are trying to compare my OCaml code with your Lisp translation then
your Lisp translation is wrong.
> And why?
Because you used the wrong numbers. Specifically, you used decimals that
happen to have exact representations in machine-precision floating point so
the results happen to be equal for that particular case.
> Or isn't this just the the well known "thou shall not compare two floating
> point numbers?"
Which is part of my point that Don Geddis' argument that Lisp's integers
make it more suitable for mission critical applications in the specific
context of rockets is completely ridiculous because floats are the source
of far more errors than ints and Lisp is no better than C in that respect.
If someone said "Mathematica is better because it bundles interval
arithmetic" then I would be inclined to agree.
>> >> And the expert Lisp programmers who invented Dylan, OCaml, SML...
>>
>> > Ahem, Dylan is a relatively good thing, but it is CL down to the
>> > core. �Cleaned up as much as you want, but that is what it is. �And it
>> > may be that is was Java to make Dylan wimper. �Moreover, it has been
>> > accepted that Dylan Big Mistake was to abandon S-expr syntax.
>>
>> Mathematica abandoned s-exprs and is a resounding success.
>
> Maybe. Deep, deep down, at least until some time ago, mathematica was
> all Conses. I have not checked it lately.
Mathematica is similar to Lisp in many ways but it does use vectors entirely
rather than cons cells. I think the Lisp community have a huge amount to
learn from Mathematica because it addressed so many of Lisp's deficiencies.
>> >> So what you're really saying is that people who don't know any better
>> >> don't complain. I'd agree with that but it applies just as much to the
>> >> tiny lingering Lisp community as it does elsewhere. Observe how
>> >> Lispers not only fail to understand the benefits of pattern matching
>> >> but are even oblivious to its increasingly widespread use.
>>
>> > I have not seen pattern-matching pop up in Java or C#...
>>
>> Look at Scala and F#.
>
> Scala is a language on its own as is F#.
I don't know what you mean by "a language on its own" but F# is being
productized by Microsoft and placed along C# and VB as their next
generation language for .NET.
> I have not played around
> with Scala (which looks like a "lets-look-like-C" language), but I
> have been playing with F#, which is well integrated within MSVS and it
> is nice to use. But that is a MLish language.
F# is MLish, yes.
> You are not seeing pattern matching popping up in Java 7 (is it?).
> Same for the next C#.
F# is the next C# and it does have pattern matching.
Scala is considered to be the next Java by many of its proponents and it
also has pattern matching.
>> >> That is also obviously wrong. The creators of the ML family of
>> >> languages embarked on that journey and they not only completed it,
>> >> creating a new family of languages without superfluous parentheses,
>> >> but the fruits of their labour (OCaml and F#) are now used by more
>> >> people than Lisp ever was.
>>
>> > Your last sentence can only be greeted with a "maybe". �As per the
>> > first part, it is mostly true. �Yet, there is *no* way to add new
>> > language features to such languages: any new "language" in the style
>> > of MLish syntax needs a fresh "compiler". �Witness the interesting
>> > PADS/ML work.
>>
>> That is not true. Look at camlp4, for example. Then look at the F# code
>> dom. Finally, consider what it takes to create a "fresh compiler" when
>> the source to the original is available.
>
> Nope. camlp4 does not count as an argument. It is a preprocessor
> outside the core language.
Camlp4 is a preprocessor (just like Lisp's macros) but it can be used
interactively and it is part of the core OCaml distribution.
So OCaml is actually every bit as extensible as Lisp and, of course, many
people have published extensions for it. For example, Martin Jambon has
extended OCaml's ordinary pattern matching to also support regular
expression matching, by writing a camlp4 syntax extension:
http://martin.jambon.free.fr/micmatch-howto.html
> I do not know F# dom, but I would be surprised if it were different.
>
> Put it this way. Get me away from actual work and saturday afternoons
> writing on CLL :) and I will get you an extended CL written *in* CL
> that did pattern matching (avec pattern compilati�n).
You are grossly underestimating the effort required to Greenspun modern
language features.
>> >> The only way you could possibly have remained oblivious to this is by
>> >> burying your head in Lisp and not learning about the alternatives. So
>> >> you just made my point. Thank you.
>>
>> > ... and telling people who chose to stick to CL (also after having
>> > used ML/Haskellish systems and/or written other languages' compilers
>> > and systems) that they are stupid where is getting you?
>>
>> Again, you are just proving my point. You are claiming to be familiar
>> with alternatives whilst simultaneously making false statements about
>> them and then claiming that Lisp is Blub.
>
> What false statements am I making?
Every single statement you have made about OCaml's extensibility has been
completely wrong. You appear to have read and misunderstood the Wikipedia
page without actually trying to find how people have already used camlp4 to
do all of the things that you are claiming to be impossible.
Again, you are proving my point about Lispers. You should get out there and
learn more about modern languages by actually using them. Once you know the
facts you will be able to substantiate your arguments but, of course, if
you knew the truth you would not be using Lisp...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Jul 12, 11:05 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Marco Antoniotti wrote:
> > On Jul 12, 6:03 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> Marco Antoniotti wrote:
> >> > On Jul 12, 4:00 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> >> Don Geddis wrote:
> >> >> From which it is clearly impossible to decipher a working program. So
> >> >> your point is obviously wrong. In reality, deliberately miscounting
> >> >> the number of tokens was just clutching at straws. A desperate attempt
> >> >> to make Lisp look less stupid.
>
> >> > let val x = 40 + 2.0;;
>
> >> > yielding an error is what I call mildly stupid. :) After all we all
> >> > know the rules about '+' since junior high.
>
> >> Except those rules do not apply in the context of floating point
> >> arithmetic, e.g. associativity:
>
> >> # (0.1 +. 0.2) +. 0.3 = 0.1 +. (0.2 +. 0.3);;
> >> - : bool = false
>
> > Come on. You know what I am getting at.
>
> I also know what you're glossing over.
>
> What is the result of:
>
> 1. / 0
>
> is it an integer divide by zero exception or the special floating point
> infinity?
In CL it is clearly defined as a raising an exception. I do not know
what MLish languages do in this case. I suppose that you could check
the constant 0 and raise a compiler error.
> The static error you describe forces the programmer to clarify the code
> before the program can be run. Claiming that to be "mildly stupid" is
> mildly stupid. Implying that floats and ints should be interchangeable when
> they have wildly different properties is considerably more stupid.
Maybe, but number coercing rules are pretty well understood. It is
true that you get the "debug early" effect, but this at the price of
getting very annoyed with the compiler.
>
> > I can write very fast and "type-correct" CL code in implementation X using
>
> > (low-level-stuff::*. 40.0 2.0)
>
> > Moreover
>
> > CL-USER 40 > (= (+ 1.0 (+ 2.0 3.0)) (+ (+ 1.0 2.0) 3.0)) ; LWM on an
> > Intel Mac.
> > T
>
> > So: which is "correct"? LWM or Ocaml?
>
> If you are trying to compare my OCaml code with your Lisp translation then
> your Lisp translation is wrong.
>
> > And why?
>
> Because you used the wrong numbers. Specifically, you used decimals that
> happen to have exact representations in machine-precision floating point so
> the results happen to be equal for that particular case.
Fine. I was stupid.
CL-USER> (= (+ 0.1 (+ 0.2 0.3)) (+ (+ 0.1 0.2) 0.3))
T
> > Or isn't this just the the well known "thou shall not compare two floating
> > point numbers?"
>
> Which is part of my point that Don Geddis' argument that Lisp's integers
> make it more suitable for mission critical applications in the specific
> context of rockets is completely ridiculous because floats are the source
> of far more errors than ints and Lisp is no better than C in that respect.
Nope. We are talking about different behavior between Ocaml and LWM
(incidentally, I expect other CL implementations to return NIL). As
per the C/CL behavior with ints and floats, they are different and
unrelated. In both cases you have well known pitfalls. In the Ariane
5 disaster, given the very, very strict typing rules of Ada, from what
I gathered from perusing the Google results, there must have been an
Unchecked_Conversion somewhere (I have not seen the code, I am just
surmising).
>
> If someone said "Mathematica is better because it bundles interval
> arithmetic" then I would be inclined to agree.
>
> >> >> And the expert Lisp programmers who invented Dylan, OCaml, SML...
>
> >> > Ahem, Dylan is a relatively good thing, but it is CL down to the
> >> > core. Cleaned up as much as you want, but that is what it is. And it
> >> > may be that is was Java to make Dylan wimper. Moreover, it has been
> >> > accepted that Dylan Big Mistake was to abandon S-expr syntax.
>
> >> Mathematica abandoned s-exprs and is a resounding success.
>
> > Maybe. Deep, deep down, at least until some time ago, mathematica was
> > all Conses. I have not checked it lately.
>
> Mathematica is similar to Lisp in many ways but it does use vectors entirely
> rather than cons cells. I think the Lisp community have a huge amount to
> learn from Mathematica because it addressed so many of Lisp's deficiencies.
So, Mathematica is no more Conses deep down. As per Lisp deficiencies
w.r.t. Mathematica I think it goes both ways. In general I defer my
opinions about Mathematica to people who know better, like Fateman.
>
> >> >> So what you're really saying is that people who don't know any better
> >> >> don't complain. I'd agree with that but it applies just as much to the
> >> >> tiny lingering Lisp community as it does elsewhere. Observe how
> >> >> Lispers not only fail to understand the benefits of pattern matching
> >> >> but are even oblivious to its increasingly widespread use.
>
> >> > I have not seen pattern-matching pop up in Java or C#...
>
> >> Look at Scala and F#.
>
> > Scala is a language on its own as is F#.
>
> I don't know what you mean by "a language on its own" but F# is being
> productized by Microsoft and placed along C# and VB as their next
> generation language for .NET.
I mean that it is not an extension of Java or C++ or C#. I know about
F#. I am playing with it.
> > I have not played around
> > with Scala (which looks like a "lets-look-like-C" language), but I
> > have been playing with F#, which is well integrated within MSVS and it
> > is nice to use. But that is a MLish language.
>
> F# is MLish, yes.
>
> > You are not seeing pattern matching popping up in Java 7 (is it?).
> > Same for the next C#.
>
> F# is the next C# and it does have pattern matching.
That is wishful thinking on your part. Of course F# has pattern
matching, but that does not mean that F# is taking over C# or that C#
is getting pattern matching.
> Scala is considered to be the next Java by many of its proponents and it
> also has pattern matching.
Scala runs on the JVM, but it is a Java extension just much as Clojure
is. Just perusing the Scala manual makes you see that it is not Java.
>
>
>
> >> >> That is also obviously wrong. The creators of the ML family of
> >> >> languages embarked on that journey and they not only completed it,
> >> >> creating a new family of languages without superfluous parentheses,
> >> >> but the fruits of their labour (OCaml and F#) are now used by more
> >> >> people than Lisp ever was.
>
> >> > Your last sentence can only be greeted with a "maybe". As per the
> >> > first part, it is mostly true. Yet, there is *no* way to add new
> >> > language features to such languages: any new "language" in the style
> >> > of MLish syntax needs a fresh "compiler". Witness the interesting
> >> > PADS/ML work.
>
> >> That is not true. Look at camlp4, for example. Then look at the F# code
> >> dom. Finally, consider what it takes to create a "fresh compiler" when
> >> the source to the original is available.
>
> > Nope. camlp4 does not count as an argument. It is a preprocessor
> > outside the core language.
>
> Camlp4 is a preprocessor (just like Lisp's macros) but it can be used
> interactively and it is part of the core OCaml distribution.
>
> So OCaml is actually every bit as extensible as Lisp and, of course, many
> people have published extensions for it. For example, Martin Jambon has
> extended OCaml's ordinary pattern matching to also support regular
> expression matching, by writing a camlp4 syntax extension:
>
> http://martin.jambon.free.fr/micmatch-howto.html
Nope. It still does not count. Of course you can do very neat things
with camlp4, but it just isn't the same as the macro system plus the
code-is-data of (any) Lisp.
>
> > I do not know F# dom, but I would be surprised if it were different.
>
> > Put it this way. Get me away from actual work and saturday afternoons
> > writing on CLL :) and I will get you an extended CL written *in* CL
> > that did pattern matching (avec pattern compilatiòn).
>
> You are grossly underestimating the effort required to Greenspun modern
> language features.
I specifically did not talk about writing a full blown type-inferencer
for CL. That would definitively prove the fundamental theorem on
programming languages :) Yet, doing pattern compilation in CL is
simple. Extending CL is simple. The work goes in getting the "look-n-
feel" right. One of the problems I have with your posts is that you
keep confusing pattern matching and type inferencing. These are
separate issues, and I am staying clear of even hinting that I am
going to write a type inferencing engine for CL.
>
> >> >> The only way you could possibly have remained oblivious to this is by
> >> >> burying your head in Lisp and not learning about the alternatives. So
> >> >> you just made my point. Thank you.
>
> >> > ... and telling people who chose to stick to CL (also after having
> >> > used ML/Haskellish systems and/or written other languages' compilers
> >> > and systems) that they are stupid where is getting you?
>
> >> Again, you are just proving my point. You are claiming to be familiar
> >> with alternatives whilst simultaneously making false statements about
> >> them and then claiming that Lisp is Blub.
>
> > What false statements am I making?
>
> Every single statement you have made about OCaml's extensibility has been
> completely wrong. You appear to have read and misunderstood the Wikipedia
> page without actually trying to find how people have already used camlp4 to
> do all of the things that you are claiming to be impossible.
I claim something very precise and very different from what you are
attributing me. I claim that the use of camlp4 is at a different
level than using the CL macro system. Like it or not that is the way
it is. It is the ball of mud vs. the muddy camel argument. :) I am
not saying that a muddy camel is a bad thing. Hey, you can also say
that a camel (muddy or not) moves, and a ball of mud does not. :) I
guess Lisp programmers are just piglets who love rolling in mud :)
> Again, you are proving my point about Lispers. You should get out there and
> learn more about modern languages by actually using them. Once you know the
> facts you will be able to substantiate your arguments but, of course, if
> you knew the truth you would not be using Lisp...
If I remember correctly, I wrote a type inferencer in ML well before
you appeared in C.L.L.; actually it was a translation of Miranda
code. *And* I am playing with F# (and Haskell). I think I am looking
around quite a bit; some things I like, other I like less. I don't
program much anymore, and, BTW, most code I see these days is Java
(which is a good alternative w.r.t. any SLDJ :) )
Cheers
--
Marco
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5bj3r$3td$1@aioe.org>
Marco Antoniotti wrote:
> On Jul 12, 11:05�pm, Jon Harrop <····@ffconsultancy.com> wrote:
>> Which is part of my point that Don Geddis' argument that Lisp's integers
>> make it more suitable for mission critical applications in the specific
>> context of rockets is completely ridiculous because floats are the source
>> of far more errors than ints and Lisp is no better than C in that
>> respect.
>
> Nope. We are talking about different behavior between Ocaml and LWM
> (incidentally, I expect other CL implementations to return NIL). As
> per the C/CL behavior with ints and floats, they are different and
> unrelated. In both cases you have well known pitfalls. In the Ariane
> 5 disaster, given the very, very strict typing rules of Ada, from what
> I gathered from perusing the Google results, there must have been an
> Unchecked_Conversion somewhere (I have not seen the code, I am just
> surmising).
Arian is irrelevant.
>> Mathematica is similar to Lisp in many ways but it does use vectors
>> entirely rather than cons cells. I think the Lisp community have a huge
>> amount to learn from Mathematica because it addressed so many of Lisp's
>> deficiencies.
>
> So, Mathematica is no more Conses deep down. As per Lisp deficiencies
> w.r.t. Mathematica I think it goes both ways.
What do you think Mathematica can learn from Lisp?
> In general I defer my opinions about Mathematica to people who know
> better, like Fateman.
Fateman is just another grumpy old Lisper who tried to plagiarise Wolfram's
work, got in trouble with the law for it and then spent the best years of
his life failing to get people to use his free software whilst publishing a
series of petty jabs at Mathematica. His knowledge is now decades out of
date.
>> I don't know what you mean by "a language on its own" but F# is being
>> productized by Microsoft and placed along C# and VB as their next
>> generation language for .NET.
>
> I mean that it is not an extension of Java or C++ or C#.
Yes, of course.
>> So OCaml is actually every bit as extensible as Lisp and, of course, many
>> people have published extensions for it. For example, Martin Jambon has
>> extended OCaml's ordinary pattern matching to also support regular
>> expression matching, by writing a camlp4 syntax extension:
>>
>> http://martin.jambon.free.fr/micmatch-howto.html
>
> Nope. It still does not count. Of course you can do very neat things
> with camlp4, but it just isn't the same as the macro system plus the
> code-is-data of (any) Lisp.
Perhaps we can get to the root of your misconception: what exactly do you
mean by "just isn't the same" given that they have the same capabilities?
>> > I do not know F# dom, but I would be surprised if it were different.
>>
>> > Put it this way. �Get me away from actual work and saturday afternoons
>> > writing on CLL :) and I will get you an extended CL written *in* CL
>> > that did pattern matching (avec pattern compilati�n).
>>
>> You are grossly underestimating the effort required to Greenspun modern
>> language features.
>
> I specifically did not talk about writing a full blown type-inferencer
> for CL.
Neither was I.
> That would definitively prove the fundamental theorem on
> programming languages :) Yet, doing pattern compilation in CL is
> simple.
You are grossly underestimating the effort required to Greenspun a modern
pattern matcher.
> Extending CL is simple.
Not if the extension is inherently complicated, as pattern matching is.
> One of the problems I have with your posts is that you keep confusing
> pattern matching and type inferencing.
I have said nothing of type inference. I am telling you that implementing a
modern pattern matcher is far harder than you apparently think.
> These are separate issues, and I am staying clear of even hinting that I
> am going to write a type inferencing engine for CL.
This never had anything to do with type inference.
>> Every single statement you have made about OCaml's extensibility has been
>> completely wrong. You appear to have read and misunderstood the Wikipedia
>> page without actually trying to find how people have already used camlp4
>> to do all of the things that you are claiming to be impossible.
>
> I claim something very precise and very different from what you are
> attributing me.
You claims are anything but precise. Look:
> I claim that the use of camlp4 is at a different level than using the CL
> macro system.
See. What is "at a different level" supposed to mean?
> Like it or not that is the way it is.
Now you're asserting a meaningless statement as a fact.
>> Again, you are proving my point about Lispers. You should get out there
>> and learn more about modern languages by actually using them. Once you
>> know the facts you will be able to substantiate your arguments but, of
>> course, if you knew the truth you would not be using Lisp...
>
> If I remember correctly, I wrote a type inferencer in ML well before
> you appeared in C.L.L.; actually it was a translation of Miranda
> code. *And* I am playing with F# (and Haskell). I think I am looking
> around quite a bit; some things I like, other I like less. I don't
> program much anymore, and, BTW, most code I see these days is Java
Then I fully understand why you've stopped coding.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <48796a98$0$5003$607ed4bc@cv.net>
Jon Harrop wrote:
> Marco Antoniotti wrote:
>> On Jul 12, 11:05 pm, Jon Harrop <····@ffconsultancy.com> wrote:
>>> Which is part of my point that Don Geddis' argument that Lisp's integers
>>> make it more suitable for mission critical applications in the specific
>>> context of rockets is completely ridiculous because floats are the source
>>> of far more errors than ints and Lisp is no better than C in that
>>> respect.
>> Nope. We are talking about different behavior between Ocaml and LWM
>> (incidentally, I expect other CL implementations to return NIL). As
>> per the C/CL behavior with ints and floats, they are different and
>> unrelated. In both cases you have well known pitfalls. In the Ariane
>> 5 disaster, given the very, very strict typing rules of Ada, from what
>> I gathered from perusing the Google results, there must have been an
>> Unchecked_Conversion somewhere (I have not seen the code, I am just
>> surmising).
>
> Arian is irrelevant.
Perhaps.
The developers eyeballed the code meticulously and decided what should
happen in each case any place there was a possibility of an overflow.
For A4. For A4, the conclusion was that a an overflow would mean the
computer was broken and should failover to its backup. This decision was
not reviewed for A5 because management did not pay for the same
meticulous review. Had they done so, one can easily imagine this
thorough team deciding that the new circumstances dictated a larger
numeric type.
Interestingly, I presume they would not have gone to each arithmetic
operation and agonize over the computation reaching certain powers of
two and said (for A4), hey, what if we get 32769 here? Lisp won't mind,
but should we failover anyway? Of course not. But the determination that
overflow would mean hardware failure might have been because they knew
the largest reasonable value was 5000, so anything like 30k is just
nuts. ie, They might well have sprinkled assertions all over the code to
proactively detect a computer run amok. In which case A5 still goes down
if management still does not pay for a review of all these assertions.
Otoh, management /might/ have paid for a review of those extreme
assertions, if in fact it was a much smaller task than reviewing all the
arithmetic in the system. But if they added assertions around all the
arithmetic....
>
>>> Mathematica is similar to Lisp in many ways but it does use vectors
>>> entirely rather than cons cells. I think the Lisp community have a huge
>>> amount to learn from Mathematica because it addressed so many of Lisp's
>>> deficiencies.
>> So, Mathematica is no more Conses deep down. As per Lisp deficiencies
>> w.r.t. Mathematica I think it goes both ways.
>
> What do you think Mathematica can learn from Lisp?
>
>> In general I defer my opinions about Mathematica to people who know
>> better, like Fateman.
>
> Fateman is just another grumpy old Lisper who tried to plagiarise Wolfram's
> work, ...
The stuff Wolfram copied off Fredkin?
kt
Kenny <·········@gmail.com> writes:
> Jon Harrop wrote:
> > Arian is irrelevant.
>
> Perhaps.
<<discussion mostly nailing what happened as per official post mortem review>>
A couple other things worth mentioning:
> mind, but should we failover anyway? Of course not. But the
> determination that overflow would mean hardware failure might have
> been because they knew the largest reasonable value was 5000, so
> anything like 30k is just nuts.
This is exactly right. That's how real world engineering works - the
limits have to do with what is actually happening, not some artificial
cpu limit (unless the cpu itself is the object of study - which in A4
it did play a bit part in this).
> Otoh, management /might/ have paid for a review of those extreme
> assertions, if in fact it was a much smaller task than reviewing all
> the arithmetic in the system. But if they added assertions around all
> the arithmetic....
Just to make Harrop apoplectic: They also would have caught this early
on if management had paid to have the _testing_ done as well (and per
engineering requests).
> > Fateman is just another grumpy old Lisper who tried to plagiarise
> > Wolfram's
> > work, ...
>
> The stuff Wolfram copied off Fredkin?
;-)
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <487a30fc$0$5013$607ed4bc@cv.net>
jayessay wrote:
> Kenny <·········@gmail.com> writes:
>
>> Jon Harrop wrote:
>>> Arian is irrelevant.
>> Perhaps.
>
> <<discussion mostly nailing what happened as per official post mortem review>>
>
> A couple other things worth mentioning:
>
>
>> mind, but should we failover anyway? Of course not. But the
>> determination that overflow would mean hardware failure might have
>> been because they knew the largest reasonable value was 5000, so
>> anything like 30k is just nuts.
>
> This is exactly right. That's how real world engineering works - the
> limits have to do with what is actually happening, not some artificial
> cpu limit (unless the cpu itself is the object of study - which in A4
> it did play a bit part in this).
>
>
>> Otoh, management /might/ have paid for a review of those extreme
>> assertions, if in fact it was a much smaller task than reviewing all
>> the arithmetic in the system. But if they added assertions around all
>> the arithmetic....
>
> Just to make Harrop apoplectic: They also would have caught this early
> on if management had paid to have the _testing_ done as well (and per
> engineering requests).
And if we want to leave Harrop crying after the fit passes we point out
that had they used Lisp they would have worked so much faster and built
such better software that testing would have been well affordable.
Indeed, a code walker would have helped catalog the various hotspots
such as divisions that might be fed zero denominators, so the code
review would cost less even as more money was available for it.
Jon's answer will begin "But with pattern matching...."
Over here I was hunting between two quick fixes since the usual Quality
Comes First(tm) sign got taken down and replaced with "No more bananas
until we ship" when I realized, awfukkit, it will be easier to Do It
Right? Pencil in a month delay? Nah, three days at the end of which
Something Wonderful Happened, there was a loud snap and when i
investigated a bit of the application that had gotten quietly bent out
of shape by the stresses forced on it by the prior ugly solution had
snapped back into its proper spacetime shape all by itself.
That doesn't happen with F#.
Watch for a blog entry entitled "There's a Reason Imelda Marcos Had 2000
Pairs of Shoes, Jeff" for more on how agile languages encourage better
programs, not better programmers.
kt
On Jul 13, 2:42 am, Jon Harrop <····@ffconsultancy.com> wrote:
> Marco Antoniotti wrote:
> > On Jul 12, 11:05 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> >> Mathematica is similar to Lisp in many ways but it does use vectors
> >> entirely rather than cons cells. I think the Lisp community have a huge
> >> amount to learn from Mathematica because it addressed so many of Lisp's
> >> deficiencies.
>
> > So, Mathematica is no more Conses deep down. As per Lisp deficiencies
> > w.r.t. Mathematica I think it goes both ways.
>
> What do you think Mathematica can learn from Lisp?
It already did. And it forgot a few things in the process. But you
are overestimating the "language merits" of Mathematica as far as its
diffusion is concerned. Mathematica greatest contribution is the
notion of IDE for mathematics. As another example, look at Matlab.
It is an even more diffused system simply because they did one thing
very, very well; incidentally the "language implications" of Simulink
go beyond our discussion of Lisp, MLish and pattern matching. But
this is for another thread.
> > In general I defer my opinions about Mathematica to people who know
> > better, like Fateman.
>
> Fateman is just another grumpy old Lisper who tried to plagiarise Wolfram's
> work, got in trouble with the law for it and then spent the best years of
> his life failing to get people to use his free software whilst publishing a
> series of petty jabs at Mathematica. His knowledge is now decades out of
> date.
Fateman is also the father of a rock singer! Difficult to beat
that! :) ...and an emeritus professor at Berkeley (last I checked, the
aroma that was coming from Telegraph Street did help the creativity of
people hanging around Soda Hall :) or maybe it was the coffee from
Nefeli's :) ).
>
> >> I don't know what you mean by "a language on its own" but F# is being
> >> productized by Microsoft and placed along C# and VB as their next
> >> generation language for .NET.
>
> > I mean that it is not an extension of Java or C++ or C#.
>
> Yes, of course.
>
> >> So OCaml is actually every bit as extensible as Lisp and, of course, many
> >> people have published extensions for it. For example, Martin Jambon has
> >> extended OCaml's ordinary pattern matching to also support regular
> >> expression matching, by writing a camlp4 syntax extension:
>
> >>http://martin.jambon.free.fr/micmatch-howto.html
>
> > Nope. It still does not count. Of course you can do very neat things
> > with camlp4, but it just isn't the same as the macro system plus the
> > code-is-data of (any) Lisp.
>
> Perhaps we can get to the root of your misconception: what exactly do you
> mean by "just isn't the same" given that they have the same capabilities?
camlp4 is a pre-processor and its "language" is not Ocaml; similar
yes, but no cigar. You invoke it on the command line (e.g., with the -
pp option to ocamlc). Plus it seems to rely on deep knowledge of the
Ocaml internal AST implementation. I am not saying that you cannot
use camlp4 to do very fancy things. After all it is (it *has* to be!)
a full blown parser. camlp4 is a good thing and quite a feat; plus, I
do think that some of the best language and compiler people nowadays
are working on Ocaml and friends. Yet, it just is not the same as
DEFMACRO. camlp4 is more like using SQL embedded in C/C++, while in
CLSQL you do
(select [emplid] [last-name] :from [employee] :where [= [emplid]
42])
Full blown CL!
To continue, I have not seen a similar facility in F# (I mean camlp4-
like: again, I may be wrong).
CL and S-exprs have a much more organic loon'n'feel to it. Either you
get it or you don't (if you don't, you are not alone :) ). To this
end, we should consider the following quote from somebody who knows
what is talking about.
"Different languages choose different sweet spots"
> >> > I do not know F# dom, but I would be surprised if it were different.
>
> >> > Put it this way. Get me away from actual work and saturday afternoons
> >> > writing on CLL :) and I will get you an extended CL written *in* CL
> >> > that did pattern matching (avec pattern compilatiòn).
>
> >> You are grossly underestimating the effort required to Greenspun modern
> >> language features.
>
> > I specifically did not talk about writing a full blown type-inferencer
> > for CL.
>
> Neither was I.
>
> > That would definitively prove the fundamental theorem on
> > programming languages :) Yet, doing pattern compilation in CL is
> > simple.
>
> You are grossly underestimating the effort required to Greenspun a modern
> pattern matcher.
>
> > Extending CL is simple.
>
> Not if the extension is inherently complicated, as pattern matching is.
>
> > One of the problems I have with your posts is that you keep confusing
> > pattern matching and type inferencing.
>
> I have said nothing of type inference. I am telling you that implementing a
> modern pattern matcher is far harder than you apparently think.
And I think, you are grossly underestimating the easiness with which
you do these things in CL. :)
On my part I also think you think it is so difficult because you are
mixing up type inferencing with pattern matching. But that it is
me... I may be wrong.
>
> > These are separate issues, and I am staying clear of even hinting that I
> > am going to write a type inferencing engine for CL.
>
> This never had anything to do with type inference.
>
> >> Every single statement you have made about OCaml's extensibility has been
> >> completely wrong. You appear to have read and misunderstood the Wikipedia
> >> page without actually trying to find how people have already used camlp4
> >> to do all of the things that you are claiming to be impossible.
>
> > I claim something very precise and very different from what you are
> > attributing me.
>
> You claims are anything but precise. Look:
>
> > I claim that the use of camlp4 is at a different level than using the CL
> > macro system.
>
> See. What is "at a different level" supposed to mean?
>
> > Like it or not that is the way it is.
>
> Now you're asserting a meaningless statement as a fact.
Let's look at the following code snippets.
Snippet 1:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defgeneric iter (f container)
(:method ((f symbol) (c t)) (iter (symbol-function f) c))
(:method ((f function) (c list)) (map nil f c))
(:method ((f function) (c vector)) (map nil f c))
(:method ((f function) (c hash-table)) (maphash f c))
)
;;; 6 lines for ITER.
(defmacro foreach ((vs in-kwd container) &body forms)
(assert (string-equal 'in in-kwd))
`(iter (lambda ,(if (symbolp vs) (list vs) vs) ,@forms) ,container))
;;; 3 lines for FOREACH. You can make it 2: witness DOLIST.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
... just to be a little more sophisticated, let's make things a little
more interesting (and rightly so, for the sake of the argument).
Let's substitute FOREACH with FOR-EACH.
Snippet 2:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defmacro for-each (&whole for-form vs in-kwd container &body forms)
(let ((lvar (if (symbolp vs) vs (gensym))))
(cond ((string-equal 'in in-kwd) ; one at a time...
`(iter (lambda (,lvar)
,@(if (symbolp vs) forms `((destructuring-
bind ,vs ,lvar ,@forms))))
,container))
((and (string-equal 'over in-kwd) (null (assert (listp
vs))))
`(iter (lambda ,vs ,@forms) ,container))
(t (error "Invalid FOR-EACH syntax ~S." for-form)))))
;;; 9 lines for FOR-EACH.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
The second version just separates the multiple lambda arg from the
destructuring version. If we had "patterns", things would have to
look different. You can use it as
(for-each x in '(1 2 3) (print x)
(for-each (x y z) in '((1 2 3) (4 5 6)) (print (list z y x)))
(for-each (k v) over some-hash-table (format t "~S -> ~S~%" k v))
The above was a half an hour hack. (I counted by thinking 10 minutes,
doubled it and added 10 extra minutes for precision). Don't take it
too seriously. Yet it "works".
After apples, let's now look at oranges.
http://www.ocaml-tutorial.org/camlp4_3.10/foreach_tutorial
Very nice, but I direct the reader at the full blown "for" example at
the end, which, admittedly, leverages OCaml to do somewhat more that
the CL code above. It definitively may have the look'n'feel of MLish
languages, but it is different from OCaml (and different, as we learn
at the top of the page, from version 3.9). And it requires an off-
line call at the command line.
Finally it is 17 lines long (actually 36 if you count all the
necessary supporting code). Now, which language is more verbose?
>
> >> Again, you are proving my point about Lispers. You should get out there
> >> and learn more about modern languages by actually using them. Once you
> >> know the facts you will be able to substantiate your arguments but, of
> >> course, if you knew the truth you would not be using Lisp...
>
> > If I remember correctly, I wrote a type inferencer in ML well before
> > you appeared in C.L.L.; actually it was a translation of Miranda
> > code. *And* I am playing with F# (and Haskell). I think I am looking
> > around quite a bit; some things I like, other I like less. I don't
> > program much anymore, and, BTW, most code I see these days is Java
>
> Then I fully understand why you've stopped coding.
>
I stopped coding because I spend too much time on C.L.L. and
elsewhere :)
In any case, enough of this. I'd better go back to coding. :)
Cheers
--
Marco
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5g9ca$ljb$1@aioe.org>
Marco Antoniotti wrote:
> On Jul 13, 2:42 am, Jon Harrop <····@ffconsultancy.com> wrote:
>> Perhaps we can get to the root of your misconception: what exactly do you
>> mean by "just isn't the same" given that they have the same capabilities?
>
> camlp4 is a pre-processor and its "language" is not Ocaml; similar
> yes, but no cigar.
I give a trivial counter example below.
> You invoke it on the command line (e.g., with the - pp option to ocamlc).
You can also load and use Camlp4 interactively, as I do below.
> Plus it seems to rely on deep knowledge of the Ocaml internal AST
> implementation.
Yet the OCaml macro you cited made no reference to or use of the OCaml AST.
> I am not saying that you cannot
> use camlp4 to do very fancy things. After all it is (it *has* to be!)
> a full blown parser. camlp4 is a good thing and quite a feat; plus, I
> do think that some of the best language and compiler people nowadays
> are working on Ocaml and friends. Yet, it just is not the same as
> DEFMACRO.
Indeed, Camlp4 supports a rich syntax including precedence and associativity
levels in a typeful way whereas DEFMACRO does not.
> camlp4 is more like using SQL embedded in C/C++, while in
> CLSQL you do
>
> (select [emplid] [last-name] :from [employee] :where [= [emplid]
> 42])
>
> Full blown CL!
You can do the same in OCaml, of course.
> To continue, I have not seen a similar facility in F# (I mean camlp4-
> like: again, I may be wrong).
There is no such facility in F#.
> Let's look at the following code snippets.
>
> Snippet 1:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> (defgeneric iter (f container)
> (:method ((f symbol) (c t)) (iter (symbol-function f) c))
> (:method ((f function) (c list)) (map nil f c))
> (:method ((f function) (c vector)) (map nil f c))
> (:method ((f function) (c hash-table)) (maphash f c))
> )
> ;;; 6 lines for ITER.
>
> (defmacro foreach ((vs in-kwd container) &body forms)
> (assert (string-equal 'in in-kwd))
> `(iter (lambda ,(if (symbolp vs) (list vs) vs) ,@forms) ,container))
> ;;; 3 lines for FOREACH. You can make it 2: witness DOLIST.
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> ... just to be a little more sophisticated, let's make things a little
> more interesting (and rightly so, for the sake of the argument).
> Let's substitute FOREACH with FOR-EACH.
>
> Snippet 2:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> (defmacro for-each (&whole for-form vs in-kwd container &body forms)
> (let ((lvar (if (symbolp vs) vs (gensym))))
> (cond ((string-equal 'in in-kwd) ; one at a time...
> `(iter (lambda (,lvar)
> ,@(if (symbolp vs) forms `((destructuring-
> bind ,vs ,lvar ,@forms))))
> ,container))
> ((and (string-equal 'over in-kwd) (null (assert (listp
> vs))))
> `(iter (lambda ,vs ,@forms) ,container))
> (t (error "Invalid FOR-EACH syntax ~S." for-form)))))
> ;;; 9 lines for FOR-EACH.
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> The second version just separates the multiple lambda arg from the
> destructuring version. If we had "patterns", things would have to
> look different. You can use it as
>
> (for-each x in '(1 2 3) (print x)
> (for-each (x y z) in '((1 2 3) (4 5 6)) (print (list z y x)))
> (for-each (k v) over some-hash-table (format t "~S -> ~S~%" k v))
>
> The above was a half an hour hack. (I counted by thinking 10 minutes,
> doubled it and added 10 extra minutes for precision). Don't take it
> too seriously. Yet it "works".
>
> After apples, let's now look at oranges.
>
> http://www.ocaml-tutorial.org/camlp4_3.10/foreach_tutorial
>
> Very nice, but I direct the reader at the full blown "for" example at
> the end, which, admittedly, leverages OCaml to do somewhat more that
> the CL code above.
Indeed, the OCaml supports precedence, associativity and pattern matching
whereas the Lisp does not.
> It definitively may have the look'n'feel of MLish languages, but it is
> different from OCaml.
In other words, it is a language extension.
> And it requires an off-line call at the command line.
Not true.
> Finally it is 17 lines long (actually 36 if you count all the
> necessary supporting code). Now, which language is more verbose?
Now consider my working vanilla OCaml implementation and example:
# #load "camlp4oof.cma";;
Camlp4 Parsing version 3.10.2
# open Camlp4.PreCast;;
# open Syntax;;
# EXTEND Gram
expr: LEVEL "top"
[ [ "foreach"; p = ipatt; "in"; m = a_UIDENT; seq = expr; "do";
body = do_sequence ->
<:expr< $uid:m$.iter (fun $p$ -> $body$) $seq$ >> ] ];
END;;
- : unit = ()
# foreach x, y in List [1, 2; 3, 4] do
Printf.printf "%d, %d\n" x y
done;;
1, 2
3, 4
- : unit = ()
Note the following points:
. No command-line arguments were used.
. This macro is written entirely in OCaml.
. Everything is done entirely from the interactive session.
. This OCaml macro requires only 6 lines of code to achieve the same effect,
compared to 11 lines of your FOR-EACH Lisp macro.
. This OCaml macro supports full pattern matching.
The above code took 60 seconds to write and test.
Please stop trying to tell me that camlp4 is "off-line", requires
command-line arguments, is not OCaml and requires deep AST knowledge.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Sat, 12 Jul 2008 15:00:55 +0100
Jon Harrop <···@ffconsultancy.com> wrote:
> Real Lisp programmers (not you) recognise the inherent flaws in the language
> and leave Lisp to use any of the better, more modern alternatives.
I lol'd... and nearly sprayed my keyboard with orange juice. Not only is this a gross generalization on the magnitude of never to be taken seriously, but you are stating that (real) Lisp programmers don't use Lisp? Does that leave only fake Lisp programmers?
As a codesmith, do you really fail to realize the requirement of working around "flaws" regardless of what language you are using? I find it silly that you can only see slow, weak, and possibly senile qualities of Lisp and in nothing else. By the way you talk, I assume anyone can jump into OCaml and build the tower of babel without even so much as learning the language surface (where it is rough and where it is smooth, where it is hard and where it is soft, etc). What a glorious achievement this modern language must be.
-a
From: Kaz Kylheku
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <20080714102726.555@gmail.com>
On 2008-07-12, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>> On 2008-07-11, Jon Harrop <···@ffconsultancy.com> wrote:
>>> let rec intersect orig dir (l, _ as hit) (center, radius, scene) =
>>> match ray_sphere orig dir center radius, scene with
>>> | lam', _ when lam' >= lam -> hit
>>> | lam', [] -> lam', unitise (orig +| lam' *| dir -| center)
>>> | _, scenes -> List.fold_left (intersect orig dir) hit scenes
>>
>> 54 tokens.
>
> Yes.
>
>>> (defun intersect (orig dir scene)
>>> (labels ((aux (lam normal scene)
>>> (let* ((center (sphere-center scene))
>>> (lamt (ray-sphere orig
>>> dir
>>> center
>>> (sphere-radius scene))))
>>> (if (>= lamt lam)
>>> (values lam normal)
>>> (etypecase scene
>>> (group
>>> (dolist (kid (group-children scene))
>>> (setf (values lam normal)
>>> (aux lam normal kid)))
>>
>> Your ``fold_left'' function improves code density, and has nothing to do
>> with
>> pattern matching. Here the analogous logic is performed by an open-coded
>> loop.
>>
>> Some kind of LOOP would probably be more dense. Or you could actually
>> use some Common Lisp version FOLD-LEFT.
>>
>> You've increased verbosity by using types like GROUP and SPHERE, which
>> don't appear in the OCaml.
>
> Note that the Lisp was written by Juho Snellman, one of the authors of SBCL,
> and not by me.
Be that as it may, was he working with a requirement for speed, or terseness?
> Those types are implicit in the OCaml but they are both
Types are also frequently implicit in Lisp. '(1 2 3) is implicitly a list,
etc.
> inferred and anonymous so they add no syntactic overhead at all.
But they do. Your pattern match for the list case requires three tokens:
lam' , []
this is longer than a single atom CONS in a TYPECASE. Though that CONS
constitutes an occurence of an explicit type, it's shorter.
>> If the type here was simply CONS, then you wouldn't have to call the
>> accessor (GROUP-CHILDREN SCENE) to pull out the scene elements. So that's
>> one less abstract syntax tree node right away.
>
> Your Lisp code would be littered with CAR and CDR instead.
I disagree. The GROUP object still contains a list made up of cons cells.
This layer of encapsulation means that an accessor has to be used to retrieve
that list.
In the OCaml, there is no such encapsulation; the object itself matches
a list and is passed straight to List.fold_left.
>>> (values lam normal))
>>> (sphere
>>> (values lamt (unitise
>>> (-v (+v orig (*v lamt dir))
>>> center)))))))))
>>> (aux infinity zero scene)))
>>
>> 62 tokens.
>
> Only if you ignore the superfluous parentheses that make up most of the Lisp
> code, which is absurd because they are essential in Lisp.
Parentheses are punctuation, not tokens. They are not part of the abstract
syntax tree, though of course they determine its shape.
> In reality, the Lisp has 125 tokens.
Abstract syntax tree size is the best measure of the raw size of an
expression in some language.
To estimate this size, we can count the number of non-punctuation elements
in the program: the symbolic, numeric and data items which constitute it.
For the purpose of doing this, we can call them ``tokens'', though this word
also has a very language-specific meaning. Perhaps I should have used ``atoms''
instead, by the way.
In Lisp, parentheses are not considered tokens. But for instance, in the C
language, the semicolon is a token, but it's lexically categorized as a
punctuator, rather than an operator.
I would consider these to be of size 3, based on counting the atoms:
foo(x, y); // C: do not count parens, comma and semicolon
(foo x y) // Lisp: do not count parens
>>> The considerable difference in verbosity is primarily due to pattern
>>
>> The Lisp is actually only 15% larger in abstract syntax tree size.
>
> The Lisp is 2.3x longer by tokens if you count the (essential) parentheses.
Fair enough.
It is true that the parentheses are an essential component of the program,
right? After all, (A (B (C)) is not the same thing as (((A) B) C).
It takes bits to form the internal nodes which encode the shape of a tree,
independently of its size; if we count only the leaves, we ignore this
piece of information whose representation requires space.
The fallacy is in your assumption that programming languages with associativity
and precedence rules do /not/ also represent that information in their
programs. But of course they do!
If we count the Lisp as being 125 tokens, then likewise, to be perfectly fair,
we also have to count the corresponding information in the OCaml program.
In Lisp, the information is plainly encoded in the program source, with only
the addition of some minimal, obvious, external rules required to decode it.
Even though that information is not visible in the OCaml program, it is still
encoded in it, by means of a more complicated compression scheme, which
requires a considerably complex set of parsing rules.
Though the Lisp program's encoding of structure adds to its raw lexical size,
that encoding is easy to work with, and is an important property of Lisp
programs: not only is the information essential, as you note above, but the
explicit manner in which it is encoded is also essential. It is not only
helpful in metasyntactic programming, but it's a big help in formatting and
manipulating the program text itself.
By comparing the raw lexical size of two programs in these very different
languages, you are comparing something compressed to something uncompressed. As
an extreme example, would you compare, say, assembly language which has been
passed through GNU zip to uncompressed C source code?
The way to avoid this type of intellectual mistake is to normalize programs to
a decompressed representation: the abstract syntax tree.
Counting the nonatoms is a good measure of the abstract syntax tree size. It
is not necessary to include internal nodes of the tree because that's a fixed
overhead. A binary tree with N atoms at the leaves always has N-1 internal
nodes.
>>> matching, which is used both for destructuring (replacing
>>> MULTIPLE-VALUE-BIND, DESTRUCTURING-BIND, CAR, CDR etc.) and for dispatch
>>> (replacing COND etc.).
>>>
>>> With pattern matching, the syntactic overhead is as low as possible, e.g.
>>
>> Syntactic size is not the entire overhead of syntax.
>>
>> There is also the mental overhead of sorting through incomprehensible line
>> noise.
>>
>> Terseness isn't everything, and let's not forget that it is one dominant
>> attribute of obfuscated programming contest entries.
>
> You may have noticed that almost all programmers disagree with you: huge
A couple of trolls in comp.lang.lisp don't constitute the entire programmimg
population.
Be careful about making assertions about almost all programmers. By raw
headcount, most programmers prefer to work with Visual Basic.
> numbers of superfluous parentheses being one of the most complained about
> disadvantages of Lisp.
A pair of parentheses is superfluous only if you can remove them without
compensating for that removal by the addition of a language rule.
If you have to do that, then you aren't removing anything, but merely
increasing the complexity of the encoding to achieve a higher compression.
A new rule is a far greater burden than a pair of parentheses. You
could argue that one rule eliminates countless pairs of parentheses, but
that is fallacious, because that rule has to be /instantiated/ in every
situation where those parentheses were removed.
In short, invisible is not necessarily better.
>>> destructuring a pair return value:
>>>
>>> # let polar x y = sqrt(x *. x +. y *. y), atan2 y x;;
>>
>> This looks like incomrehensible drivel. More parentheses are needed to
>> show what goes with what.
>
> No, more parentheses are not needed.
I disagree; a bit more punctuation would go a long way.
You have a comma there which binds more tightly than equals!
Note that in C:
a = b, b = c, c = a
parses as:
(a = b), (b = c), (c = a)
This is the way god intended it to be. This is why there are parentheses around
comma-separated lists, when those lists are to be treated as a unit. For
instance function calls:
f(a, b, c); // NOT: f a, b, c;
In a syntax where a comma expression is used to denote multiple values, it
should be parenthesized:
(x, y, z) = (1, 2, 3); // NOT: x, y, z = 1, 2, 3;
This is more psychologically sound.
>> What is the associativity and precedence of -> ?
>
> Right associative and low precedence.
Right-to-left associative /binary/ operator? That's braindamaged.
Oh yeah, C++ programmers are going to love this. Arrows that clump right to
left, commas that bind more tightly than equals.
OCaml had its ass kicked in the benchmark by C++, and, amazingly, Lisp lagged
behind only by 4%.
The C++ code is way more understandable than the OCaml.
What that tells us is that we should write in Lisp, and use C or C++ libraries
when we want maximum speed without sacrificing portability.
By doing that we not only get the best of both worlds, and we can do it
all with understandable, maintainable code.
>> Even someone who doesn't know Common Lisp can at least work out the
>> abstract syntax tree.
>
> You say that as if we were not all capable of deciphering the precedence of
> addition and multiplication by the age of 5.
Well, the problem is that addition and multiplication is where the similarity
among most programming language syntaxes ends.
Moreover, deciphering never ceases to be deciphering.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5gae8$q3l$1@aioe.org>
Kaz Kylheku wrote:
> On 2008-07-12, Jon Harrop <···@ffconsultancy.com> wrote:
>> Note that the Lisp was written by Juho Snellman, one of the authors of
>> SBCL, and not by me.
>
> Be that as it may, was he working with a requirement for speed, or
> terseness?
Juho was trying to be concise. That code was quoted from the first version
of the ray tracer benchmark, which is the slowest and most concise.
>> Those types are implicit in the OCaml but they are both
>
> Types are also frequently implicit in Lisp. '(1 2 3) is implicitly a list,
> etc.
Still requires explicit deconstruction in Lisp but not in OCaml.
>> inferred and anonymous so they add no syntactic overhead at all.
>
> But they do. Your pattern match for the list case requires three tokens:
>
> lam' , []
>
> this is longer than a single atom CONS in a TYPECASE. Though that CONS
> constitutes an occurence of an explicit type, it's shorter.
I assume you are still neglecting the single most common and completely
superfluous component of the Lisp source code: the parentheses.
>>> If the type here was simply CONS, then you wouldn't have to call the
>>> accessor (GROUP-CHILDREN SCENE) to pull out the scene elements. So
>>> that's one less abstract syntax tree node right away.
>>
>> Your Lisp code would be littered with CAR and CDR instead.
>
> I disagree. The GROUP object still contains a list made up of cons cells.
If that list were deconstructed within this source code that would be
relevant but it is not.
>>>> (values lam normal))
>>>> (sphere
>>>> (values lamt (unitise
>>>> (-v (+v orig (*v lamt dir))
>>>> center)))))))))
>>>> (aux infinity zero scene)))
>>>
>>> 62 tokens.
>>
>> Only if you ignore the superfluous parentheses that make up most of the
>> Lisp code, which is absurd because they are essential in Lisp.
>
> Parentheses are punctuation, not tokens.
So we cannot even agree on what a token is.
> They are not part of the abstract syntax tree, though of course they
> determine its shape.
So the parentheses are both visible and essential but you still want to
neglect them.
>> In reality, the Lisp has 125 tokens.
>
> Abstract syntax tree size is the best measure of the raw size of an
> expression in some language.
Absolutely not. The AST is compiler-dependent and invisible to the
programmer. So its size cannot be objectively quantified and would be
irrelevant anyway.
>> The Lisp is 2.3x longer by tokens if you count the (essential)
>> parentheses.
>
> Fair enough.
>
> It is true that the parentheses are an essential component of the program,
> right? After all, (A (B (C)) is not the same thing as (((A) B) C).
Yes.
> It takes bits to form the internal nodes which encode the shape of a tree,
> independently of its size; if we count only the leaves, we ignore this
> piece of information whose representation requires space.
>
> The fallacy is in your assumption that programming languages with
> associativity and precedence rules do /not/ also represent that
> information in their programs. But of course they do!
Strawman argument.
> If we count the Lisp as being 125 tokens, then likewise, to be perfectly
> fair, we also have to count the corresponding information in the OCaml
> program.
>
> In Lisp, the information is plainly encoded in the program source, with
> only the addition of some minimal, obvious, external rules required to
> decode it.
>
> Even though that information is not visible in the OCaml program, it is
> still encoded in it, by means of a more complicated compression scheme,
> which requires a considerably complex set of parsing rules.
>
> Though the Lisp program's encoding of structure adds to its raw lexical
> size, that encoding is easy to work with, and is an important property of
> Lisp programs: not only is the information essential, as you note above,
> but the explicit manner in which it is encoded is also essential. It is
> not only helpful in metasyntactic programming, but it's a big help in
> formatting and manipulating the program text itself.
>
> By comparing the raw lexical size of two programs in these very different
> languages, you are comparing something compressed to something
> uncompressed. As an extreme example, would you compare, say, assembly
> language which has been passed through GNU zip to uncompressed C source
> code?
I would only compared human edited formats, i.e. OCaml source, Lisp source
but not gzipped assembler.
>> You may have noticed that almost all programmers disagree with you: huge
>
> A couple of trolls in comp.lang.lisp don't constitute the entire
> programmimg population.
Fortunately, the set of programmers who dislike superfluous parentheses
extends far beyond "a couple of trolls in comp.lang.lisp".
> Be careful about making assertions about almost all programmers. By raw
> headcount, most programmers prefer to work with Visual Basic.
Exactly.
>> numbers of superfluous parentheses being one of the most complained about
>> disadvantages of Lisp.
>
> A pair of parentheses is superfluous only if you can remove them without
> compensating for that removal by the addition of a language rule.
That is an incorrect definition of "superfluous".
> If you have to do that, then you aren't removing anything, but merely
> increasing the complexity of the encoding to achieve a higher compression.
In other words, you are improving brevity.
> A new rule is a far greater burden than a pair of parentheses.
Almost all programmers and mathematicians disagree with you on that.
> You
> could argue that one rule eliminates countless pairs of parentheses, but
> that is fallacious, because that rule has to be /instantiated/ in every
> situation where those parentheses were removed.
We were all trained to comprehend that (and a lot more) from a very young
age.
> In short, invisible is not necessarily better.
There is a trade-off.
>>>> # let polar x y = sqrt(x *. x +. y *. y), atan2 y x;;
>>>
>>> This looks like incomrehensible drivel. More parentheses are needed to
>>> show what goes with what.
>>
>> No, more parentheses are not needed.
>
> I disagree; a bit more punctuation would go a long way.
>
> You have a comma there which binds more tightly than equals!
>
> Note that in C:
>
> a = b, b = c, c = a
>
> parses as:
>
> (a = b), (b = c), (c = a)
>
> This is the way god intended it to be.
Note that you just contradicted yourself by claiming that my OCaml
was "incomrehensible drivel" and needed "more parentheses" in your previous
post before explaining in detail the only non-obvious aspect of precedence
required to completely parse it in this post. Indeed, you are now
saying "this is the way god intended it to be".
So you obviously can comprehend precedence.
> This is why there are parentheses
> around comma-separated lists, when those lists are to be treated as a
> unit. For instance function calls:
>
> f(a, b, c); // NOT: f a, b, c;
>
> In a syntax where a comma expression is used to denote multiple values, it
> should be parenthesized:
>
> (x, y, z) = (1, 2, 3); // NOT: x, y, z = 1, 2, 3;
>
> This is more psychologically sound.
You just contradicted yourself again by saying that unbracketed
comma-separated sequences are "what God intended" but you want to bracket
them.
>>> What is the associativity and precedence of -> ?
>>
>> Right associative and low precedence.
>
> Right-to-left associative /binary/ operator? That's braindamaged.
Power is another right associative binary operator.
>>> Even someone who doesn't know Common Lisp can at least work out the
>>> abstract syntax tree.
>>
>> You say that as if we were not all capable of deciphering the precedence
>> of addition and multiplication by the age of 5.
>
> Well, the problem is that addition and multiplication is where the
> similarity among most programming language syntaxes ends.
Power, comma, equality, comparisons, definitions, application, construction,
indexing etc. are all very similar between languages. The outlier is
undoubtedly s-exprs.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Kaz Kylheku
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <20080714134259.505@gmail.com>
On 2008-07-14, Jon Harrop <···@ffconsultancy.com> wrote:
> Kaz Kylheku wrote:
>>> Those types are implicit in the OCaml but they are both
>>> inferred and anonymous so they add no syntactic overhead at all.
>>
>> But they do. Your pattern match for the list case requires three tokens:
>>
>> lam' , []
>>
>> this is longer than a single atom CONS in a TYPECASE. Though that CONS
>> constitutes an occurence of an explicit type, it's shorter.
>
> I assume you are still neglecting the single most common and completely
> superfluous component of the Lisp source code: the parentheses.
Well, if I could see the darn things, I probably wouldn't! :)
From: Kaz Kylheku
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <20080714134954.834@gmail.com>
On 2008-07-14, Jon Harrop <···@ffconsultancy.com> wrote:
>> Abstract syntax tree size is the best measure of the raw size of an
>> expression in some language.
>
> Absolutely not. The AST is compiler-dependent and invisible to the
> programmer. So its size cannot be objectively quantified and would be
> irrelevant anyway.
An AST can be easily and neatly identified for any well-formed expression of
any programming language.
Far from being invisible to the programmer, it is a key concept at the
forefront of cophrehension and manipulation of the program.
The programmer is keenly aware of how the symbols and data in the program text
are hierarchically grouped in relation to each other.
> Strawman argument.
Build something better than a strawman.
>> By comparing the raw lexical size of two programs in these very different
>> languages, you are comparing something compressed to something
>> uncompressed. As an extreme example, would you compare, say, assembly
>> language which has been passed through GNU zip to uncompressed C source
>> code?
>
> I would only compared human edited formats, i.e. OCaml source, Lisp source
> but not gzipped assembler.
Uh oh, man-machine distinction creeping in! I sort of liked it better when we
didn't agree about what a token was, and you claimed that an abstract syntax
tree was compiler-dependent and not objectively quantifiable. :)
>> A pair of parentheses is superfluous only if you can remove them without
>> compensating for that removal by the addition of a language rule.
>
> That is an incorrect definition of "superfluous".
Superfluous means unnecessary, redundant. Earlier you wrote that parentheses
were essential. What definition of ``superfluous'' is even remotely compatible
with ``essential'', never mind synonymous?
>> A new rule is a far greater burden than a pair of parentheses.
>
> Almost all programmers and mathematicians disagree with you on that.
Perhaps mathematicians who are also programmers, I suspect.
I can't help but note that the programmer I was, say, fifteen years ago might
also disagree with me.
On Mon, 14 Jul 2008 21:37:31 +0000 (UTC), Kaz Kylheku <········@gmail.com> said:
| On 2008-07-14, Jon Harrop <···@ffconsultancy.com> wrote:
||...
||| A new rule is a far greater burden than a pair of parentheses.
||
|| Almost all programmers and mathematicians disagree with you on that.
| Perhaps mathematicians who are also programmers, I suspect.
Mathematicians to the rescue... I am undecided about that. In
mathematics, parentheses serve (at least) three distinguishable
(though to some extent overlapping) purposes:
(I) making a term of a non-atomic structure (exhibits A and B)
(II) enclosing a compound value (exhibit B, C)
(III) denoting a special (in some sense) meaning (exhibit D)
Exhibit A: (x + y)/z
( y_1 )
Exhibit B: (x_1 x_2 x_3) . ( y_2 )
( y_3 )
(scalar product ("row by column"))
Exhibit C: f(x_1, x_2, x_3)
(function application)
Exhibit D: y^(n)
(n-th derivative; without the parentheses, n-th power)
In Fortran and Algol (and their progeny) parentheses are used for
(I) and (II) (rarely (III), e.g. for type casts in C).
In Lisp, however, (I) and (II) are merged into one. Maybe that is
what makes dealing with those pesky parentheses allegedly difficult?
("Is it a term? Is it a sequence? It is an S-expression!")
* * *
Of course, there are other ways to get help from mathematicians, e.g.
"when in doubt, think: what would Gauss do?"
---Vassil.
P.S. "What's in a pair of parentheses? Would an S-expression be as
sweet in any other syntax?"
--
Peius melius est. ---Ricardus Gabriel.
On Jul 15, 4:46 am, Vassil Nikolov <···············@pobox.com> wrote:
> On Mon, 14 Jul 2008 21:37:31 +0000 (UTC), Kaz Kylheku <········@gmail.com> said:
>
> | On 2008-07-14, Jon Harrop <····@ffconsultancy.com> wrote:
> ||...
> ||| A new rule is a far greater burden than a pair of parentheses.
> ||
> || Almost all programmers and mathematicians disagree with you on that.
>
> | Perhaps mathematicians who are also programmers, I suspect.
>
> Mathematicians to the rescue... I am undecided about that. In
> mathematics, parentheses serve (at least) three distinguishable
> (though to some extent overlapping) purposes:
>
> (I) making a term of a non-atomic structure (exhibits A and B)
> (II) enclosing a compound value (exhibit B, C)
> (III) denoting a special (in some sense) meaning (exhibit D)
>
> Exhibit A: (x + y)/z
>
> ( y_1 )
> Exhibit B: (x_1 x_2 x_3) . ( y_2 )
> ( y_3 )
> (scalar product ("row by column"))
>
> Exhibit C: f(x_1, x_2, x_3)
> (function application)
>
> Exhibit D: y^(n)
> (n-th derivative; without the parentheses, n-th power)
>
> In Fortran and Algol (and their progeny) parentheses are used for
> (I) and (II) (rarely (III), e.g. for type casts in C).
>
> In Lisp, however, (I) and (II) are merged into one. Maybe that is
> what makes dealing with those pesky parentheses allegedly difficult?
> ("Is it a term? Is it a sequence? It is an S-expression!")
>
Yes, I believe that is what caused me most trouble in the beginning --
being used to C, parens in the form you see in Lisp code are used to
group things together, i.e. (I). However, as you say, Lisp has merged
(I) and (II).
Once I realized that all forms are (more-or-less) equal, and that
parens don't really have any "meaning" (in the C sense of grouping to
make explicit precedence), they'll start fading away and stop becoming
a nuisance.
--
Mikael Jansson
http://mikael.jansson.be
On 20 Lug, 10:15, Mikael Jansson <··············@gmail.com> wrote:
> On Jul 15, 4:46 am, Vassil Nikolov <···············@pobox.com> wrote:
>
> > On Mon, 14 Jul 2008 21:37:31 +0000 (UTC), Kaz Kylheku <········@gmail.com> said:
>
> > | On 2008-07-14, Jon Harrop <····@ffconsultancy.com> wrote:
> > ||...
> > ||| A new rule is a far greater burden than a pair of parentheses.
> > ||
> > || Almost all programmers and mathematicians disagree with you on that.
>
> > | Perhaps mathematicians who are also programmers, I suspect.
>
> > Mathematicians to the rescue... I am undecided about that. In
> > mathematics, parentheses serve (at least) three distinguishable
> > (though to some extent overlapping) purposes:
>
> > (I) making a term of a non-atomic structure (exhibits A and B)
> > (II) enclosing a compound value (exhibit B, C)
> > (III) denoting a special (in some sense) meaning (exhibit D)
>
> > Exhibit A: (x + y)/z
>
> > ( y_1 )
> > Exhibit B: (x_1 x_2 x_3) . ( y_2 )
> > ( y_3 )
> > (scalar product ("row by column"))
>
> > Exhibit C: f(x_1, x_2, x_3)
> > (function application)
>
> > Exhibit D: y^(n)
> > (n-th derivative; without the parentheses, n-th power)
>
> > In Fortran and Algol (and their progeny) parentheses are used for
> > (I) and (II) (rarely (III), e.g. for type casts in C).
>
> > In Lisp, however, (I) and (II) are merged into one. Maybe that is
> > what makes dealing with those pesky parentheses allegedly difficult?
> > ("Is it a term? Is it a sequence? It is an S-expression!")
>
> Yes, I believe that is what caused me most trouble in the beginning --
> being used to C, parens in the form you see in Lisp code are used to
> group things together, i.e. (I). However, as you say, Lisp has merged
> (I) and (II).
>
> Once I realized that all forms are (more-or-less) equal, and that
> parens don't really have any "meaning" (in the C sense of grouping to
> make explicit precedence), they'll start fading away and stop becoming
> a nuisance.
How can they fade away?
(+ (* 2 3 4) 5)
is different from
(+ (* 2 3) 4 5)
> --
> Mikael Janssonhttp://mikael.jansson.be
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <48839287$0$7356$607ed4bc@cv.net>
Vend wrote:
> On 20 Lug, 10:15, Mikael Jansson <··············@gmail.com> wrote:
>> On Jul 15, 4:46 am, Vassil Nikolov <···············@pobox.com> wrote:
>>
>>> On Mon, 14 Jul 2008 21:37:31 +0000 (UTC), Kaz Kylheku <········@gmail.com> said:
>>> | On 2008-07-14, Jon Harrop <····@ffconsultancy.com> wrote:
>>> ||...
>>> ||| A new rule is a far greater burden than a pair of parentheses.
>>> ||
>>> || Almost all programmers and mathematicians disagree with you on that.
>>> | Perhaps mathematicians who are also programmers, I suspect.
>>> Mathematicians to the rescue... I am undecided about that. In
>>> mathematics, parentheses serve (at least) three distinguishable
>>> (though to some extent overlapping) purposes:
>>> (I) making a term of a non-atomic structure (exhibits A and B)
>>> (II) enclosing a compound value (exhibit B, C)
>>> (III) denoting a special (in some sense) meaning (exhibit D)
>>> Exhibit A: (x + y)/z
>>> ( y_1 )
>>> Exhibit B: (x_1 x_2 x_3) . ( y_2 )
>>> ( y_3 )
>>> (scalar product ("row by column"))
>>> Exhibit C: f(x_1, x_2, x_3)
>>> (function application)
>>> Exhibit D: y^(n)
>>> (n-th derivative; without the parentheses, n-th power)
>>> In Fortran and Algol (and their progeny) parentheses are used for
>>> (I) and (II) (rarely (III), e.g. for type casts in C).
>>> In Lisp, however, (I) and (II) are merged into one. Maybe that is
>>> what makes dealing with those pesky parentheses allegedly difficult?
>>> ("Is it a term? Is it a sequence? It is an S-expression!")
>> Yes, I believe that is what caused me most trouble in the beginning --
>> being used to C, parens in the form you see in Lisp code are used to
>> group things together, i.e. (I). However, as you say, Lisp has merged
>> (I) and (II).
>>
>> Once I realized that all forms are (more-or-less) equal, and that
>> parens don't really have any "meaning" (in the C sense of grouping to
>> make explicit precedence), they'll start fading away and stop becoming
>> a nuisance.
>
> How can they fade away?
>
> (+ (* 2 3 4) 5)
> is different from
> (+ (* 2 3) 4 5)
>
As a rule exceptions rock when it comes to proving rules and the above
is no exception.
hth, kt
ps. Meanwhile, a fun drama is being played out on Amazon S3 as they go
into hour three of their outage (along with a couple of other services
they offer). Seems they did this before in February and the one lesson
they picked up was for the love of god to keep users posted, so the
status board has updates every 20-30 minutes on the hand-to-hand
fighting I can imagine going on somewhere in the cloud.
pps. Giving me a good chance to live test the resilience of my Algebra
software in the face of an S3 outage.
kt
On Jul 20, 6:38 pm, Vend <······@virgilio.it> wrote:
> On 20 Lug, 10:15, Mikael Jansson <··············@gmail.com> wrote:
>
> [snip]
>
> > Once I realized that all forms are (more-or-less) equal, and that
> > parens don't really have any "meaning" (in the C sense of grouping to
> > make explicit precedence), they'll start fading away and stop becoming
> > a nuisance.
>
> How can they fade away?
>
> (+ (* 2 3 4) 5)
> is different from
> (+ (* 2 3) 4 5)
>
Wasn't meant literally and universally. For general control
structures, such as LET, COND and what have you, it's not the parens
which unveil information, but instead indentation and the name of the
form itself.
But you were just playing the devil's advocate, right?
> > --
> > Mikael Jansson
> > http://mikael.jansson.be
On 21 Lug, 09:32, Mikael Jansson <··············@gmail.com> wrote:
> On Jul 20, 6:38 pm, Vend <······@virgilio.it> wrote:> On 20 Lug, 10:15, Mikael Jansson <··············@gmail.com> wrote:
>
> > [snip]
>
> > > Once I realized that all forms are (more-or-less) equal, and that
> > > parens don't really have any "meaning" (in the C sense of grouping to
> > > make explicit precedence), they'll start fading away and stop becoming
> > > a nuisance.
>
> > How can they fade away?
>
> > (+ (* 2 3 4) 5)
> > is different from
> > (+ (* 2 3) 4 5)
>
> Wasn't meant literally and universally. For general control
> structures, such as LET, COND and what have you, it's not the parens
> which unveil information, but instead indentation and the name of the
> form itself.
>
> But you were just playing the devil's advocate, right?
Mostly but not completely.
Identation conveys information to the programmer, while the
parentheses convey information to the machine, if identation is not in-
synch with the parentheses cognitive dissonance will ensue.
Sure, lisp-enabled editors can take care of that, but if you are stuck
with a simple text editor then you are on your own.
Also, when you want to insert an expression in the middle of a complex
program, you have to either use a parentheses matching editor, or use
C-style identation or count parentheses.
From: Duane Rettig
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <o0abgb439h.fsf@gemini.franz.com>
Vend <······@virgilio.it> writes:
> On 21 Lug, 09:32, Mikael Jansson <··············@gmail.com> wrote:
>> On Jul 20, 6:38 pm, Vend <······@virgilio.it> wrote:> On 20 Lug, 10:15, Mikael Jansson <··············@gmail.com> wrote:
>>
>> > [snip]
>>
>> > > Once I realized that all forms are (more-or-less) equal, and that
>> > > parens don't really have any "meaning" (in the C sense of grouping to
>> > > make explicit precedence), they'll start fading away and stop becoming
>> > > a nuisance.
>>
>> > How can they fade away?
>>
>> > (+ (* 2 3 4) 5)
>> > is different from
>> > (+ (* 2 3) 4 5)
>>
>> Wasn't meant literally and universally. For general control
>> structures, such as LET, COND and what have you, it's not the parens
>> which unveil information, but instead indentation and the name of the
>> form itself.
>>
>> But you were just playing the devil's advocate, right?
>
> Mostly but not completely.
>
> Identation conveys information to the programmer, while the
> parentheses convey information to the machine, if identation is not in-
> synch with the parentheses cognitive dissonance will ensue.
>
> Sure, lisp-enabled editors can take care of that, but if you are stuck
> with a simple text editor then you are on your own.
Nobody's ever "stuck" with a simple text editor. Emacs and vi are
pretty much ubiquitous, and even if not available temporarily, it
doesn't tend to last long. No, being "stuck" with a simple text
editor is almost always a choice.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On 21 Lug, 18:21, Duane Rettig <·····@franz.com> wrote:
> Vend <······@virgilio.it> writes:
> > On 21 Lug, 09:32, Mikael Jansson <··············@gmail.com> wrote:
> >> On Jul 20, 6:38 pm, Vend <······@virgilio.it> wrote:> On 20 Lug, 10:15, Mikael Jansson <··············@gmail.com> wrote:
>
> >> > [snip]
>
> >> > > Once I realized that all forms are (more-or-less) equal, and that
> >> > > parens don't really have any "meaning" (in the C sense of grouping to
> >> > > make explicit precedence), they'll start fading away and stop becoming
> >> > > a nuisance.
>
> >> > How can they fade away?
>
> >> > (+ (* 2 3 4) 5)
> >> > is different from
> >> > (+ (* 2 3) 4 5)
>
> >> Wasn't meant literally and universally. For general control
> >> structures, such as LET, COND and what have you, it's not the parens
> >> which unveil information, but instead indentation and the name of the
> >> form itself.
>
> >> But you were just playing the devil's advocate, right?
>
> > Mostly but not completely.
>
> > Identation conveys information to the programmer, while the
> > parentheses convey information to the machine, if identation is not in-
> > synch with the parentheses cognitive dissonance will ensue.
>
> > Sure, lisp-enabled editors can take care of that, but if you are stuck
> > with a simple text editor then you are on your own.
>
> Nobody's ever "stuck" with a simple text editor. Emacs and vi are
> pretty much ubiquitous, and even if not available temporarily, it
> doesn't tend to last long. No, being "stuck" with a simple text
> editor is almost always a choice.
It's not like Emacs and vi are the easiest to use editors around.
From: Cor Gest
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87ljzuolbc.fsf@atthis.clsnet.nl>
The entity, AKA Vend <······@virgilio.it> wrote :
(selectively-snipped-or-not-P)
> It's not like Emacs and vi are the easiest to use editors around.
Yeps, I allways had problems with the IBM-selectric since I was
used to the Underwood type-5.
Cor
--
Mijn Tools zijn zo modern dat ze allemaal eindigen op 'saurus'
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
SPAM DELENDA EST http://www.clsnet.nl/mail.php
Ik ontwerp schpellvauden, ergo innoveer taal
On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
> On 21 Lug, 18:21, Duane Rettig <·····@franz.com> wrote:
>
>
>
>
>
> > Vend <······@virgilio.it> writes:
> > > On 21 Lug, 09:32, Mikael Jansson <··············@gmail.com> wrote:
> > >> On Jul 20, 6:38 pm, Vend <······@virgilio.it> wrote:> On 20 Lug, 10:15, Mikael Jansson <··············@gmail.com> wrote:
>
> > >> > [snip]
>
> > >> > > Once I realized that all forms are (more-or-less) equal, and that
> > >> > > parens don't really have any "meaning" (in the C sense of grouping to
> > >> > > make explicit precedence), they'll start fading away and stop becoming
> > >> > > a nuisance.
>
> > >> > How can they fade away?
>
> > >> > (+ (* 2 3 4) 5)
> > >> > is different from
> > >> > (+ (* 2 3) 4 5)
>
> > >> Wasn't meant literally and universally. For general control
> > >> structures, such as LET, COND and what have you, it's not the parens
> > >> which unveil information, but instead indentation and the name of the
> > >> form itself.
>
> > >> But you were just playing the devil's advocate, right?
>
> > > Mostly but not completely.
>
> > > Identation conveys information to the programmer, while the
> > > parentheses convey information to the machine, if identation is not in-
> > > synch with the parentheses cognitive dissonance will ensue.
>
> > > Sure, lisp-enabled editors can take care of that, but if you are stuck
> > > with a simple text editor then you are on your own.
>
> > Nobody's ever "stuck" with a simple text editor. Emacs and vi are
> > pretty much ubiquitous, and even if not available temporarily, it
> > doesn't tend to last long. No, being "stuck" with a simple text
> > editor is almost always a choice.
>
> It's not like Emacs and vi are the easiest to use editors around.
And of course, judging an editor based on how easy it is to use if you
have never used it before is rather pointless.
--
Mikael Jansson
http://mikael.jansson.be
On 22 Lug, 10:36, Mikael Jansson <··············@gmail.com> wrote:
> On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
>
>
>
> > On 21 Lug, 18:21, Duane Rettig <·····@franz.com> wrote:
>
> > > Vend <······@virgilio.it> writes:
> > > > On 21 Lug, 09:32, Mikael Jansson <··············@gmail.com> wrote:
> > > >> On Jul 20, 6:38 pm, Vend <······@virgilio.it> wrote:> On 20 Lug, 10:15, Mikael Jansson <··············@gmail.com> wrote:
>
> > > >> > [snip]
>
> > > >> > > Once I realized that all forms are (more-or-less) equal, and that
> > > >> > > parens don't really have any "meaning" (in the C sense of grouping to
> > > >> > > make explicit precedence), they'll start fading away and stop becoming
> > > >> > > a nuisance.
>
> > > >> > How can they fade away?
>
> > > >> > (+ (* 2 3 4) 5)
> > > >> > is different from
> > > >> > (+ (* 2 3) 4 5)
>
> > > >> Wasn't meant literally and universally. For general control
> > > >> structures, such as LET, COND and what have you, it's not the parens
> > > >> which unveil information, but instead indentation and the name of the
> > > >> form itself.
>
> > > >> But you were just playing the devil's advocate, right?
>
> > > > Mostly but not completely.
>
> > > > Identation conveys information to the programmer, while the
> > > > parentheses convey information to the machine, if identation is not in-
> > > > synch with the parentheses cognitive dissonance will ensue.
>
> > > > Sure, lisp-enabled editors can take care of that, but if you are stuck
> > > > with a simple text editor then you are on your own.
>
> > > Nobody's ever "stuck" with a simple text editor. Emacs and vi are
> > > pretty much ubiquitous, and even if not available temporarily, it
> > > doesn't tend to last long. No, being "stuck" with a simple text
> > > editor is almost always a choice.
>
> > It's not like Emacs and vi are the easiest to use editors around.
>
> And of course, judging an editor based on how easy it is to use if you
> have never used it before is rather pointless.
It's not. The time and effort you need to learn to use something
productively matters a lot.
From: Duane Rettig
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <o0vdyyrlk9.fsf@gemini.franz.com>
Vend <······@virgilio.it> writes:
> On 22 Lug, 10:36, Mikael Jansson <··············@gmail.com> wrote:
>> On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
>>
>> > It's not like Emacs and vi are the easiest to use editors around.
>>
>> And of course, judging an editor based on how easy it is to use if you
>> have never used it before is rather pointless.
>
> It's not. The time and effort you need to learn to use something
> productively matters a lot.
You're absolutely correct. It took me many years to learn to play the
trumpet even to the point where people no longer cringed or covered
their ears. Now people enjoy hearing me play, but it is a rough road
that I don't recommend for everyone.
So take comfort in knowing that you can easily master the kazoo.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <48860efa$0$5022$607ed4bc@cv.net>
Duane Rettig wrote:
> Vend <······@virgilio.it> writes:
>
>> On 22 Lug, 10:36, Mikael Jansson <··············@gmail.com> wrote:
>>> On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
>>>
>>>> It's not like Emacs and vi are the easiest to use editors around.
>>> And of course, judging an editor based on how easy it is to use if you
>>> have never used it before is rather pointless.
>> It's not. The time and effort you need to learn to use something
>> productively matters a lot.
>
> You're absolutely correct.
I was going to say he had absolutely changed the subject from easy to
use to easy to learn, utterly unrelated.
I was also going to suggest AllegroCL Free Trial in host edit mode (the
default out of the box). I do not use that mode cuz I grew up on MCL
hence Fred, but I imagine there would not even be a learning curve worth
mentioning in host mode.
I mostly not going to respond at all because we have in fact nothing
more than a classic case of The Imaginary Whine(tm), a complaint
imagined someone if they were to do something they have no intention of
doing anyway.
I'll say this for academia, this NG sure goes to hell when they take the
summer off.
It took me many years to learn to play the
> trumpet even to the point where people no longer cringed or covered
> their ears. Now people enjoy hearing me play, but it is a rough road
> that I don't recommend for everyone.
So how do musicians pick an instrument out of the whole orchestra? Chet
Baker fan?
kt
On 22 Lug, 18:46, Kenny <·········@gmail.com> wrote:
> Duane Rettig wrote:
> > Vend <······@virgilio.it> writes:
>
> >> On 22 Lug, 10:36, Mikael Jansson <··············@gmail.com> wrote:
> >>> On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
>
> >>>> It's not like Emacs and vi are the easiest to use editors around.
> >>> And of course, judging an editor based on how easy it is to use if you
> >>> have never used it before is rather pointless.
> >> It's not. The time and effort you need to learn to use something
> >> productively matters a lot.
>
> > You're absolutely correct.
>
> I was going to say he had absolutely changed the subject from easy to
> use to easy to learn, utterly unrelated.
I don't think they are utterly unrelated, but yes, I should have been
more precise.
> I was also going to suggest AllegroCL Free Trial in host edit mode (the
> default out of the box). I do not use that mode cuz I grew up on MCL
> hence Fred, but I imagine there would not even be a learning curve worth
> mentioning in host mode.
>
> I mostly not going to respond at all because we have in fact nothing
> more than a classic case of The Imaginary Whine(tm), a complaint
> imagined someone if they were to do something they have no intention of
> doing anyway.
I've tried to code in Lisp using plain text editors and I found it
difficult, so I switched to IDEs.
<snip>
On Tue, 22 Jul 2008 14:10:19 -0700 (PDT), Vend <······@virgilio.it> said:
| ...
| I've tried to code in Lisp using plain text editors and I found it
| difficult, so I switched to IDEs.
But if you ever try to code plain text editors using IDEs and you
find it difficult, you'll still be able to switch to Lisp...
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
In article <··············@gemini.franz.com>,
Duane Rettig <·····@franz.com> wrote:
> Vend <······@virgilio.it> writes:
>
> > On 22 Lug, 10:36, Mikael Jansson <··············@gmail.com> wrote:
> >> On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
> >>
> >> > It's not like Emacs and vi are the easiest to use editors around.
> >>
> >> And of course, judging an editor based on how easy it is to use if you
> >> have never used it before is rather pointless.
> >
> > It's not. The time and effort you need to learn to use something
> > productively matters a lot.
>
> You're absolutely correct. It took me many years to learn to play the
> trumpet even to the point where people no longer cringed or covered
> their ears. Now people enjoy hearing me play, but it is a rough road
> that I don't recommend for everyone.
>
> So take comfort in knowing that you can easily master the kazoo.
A classic. ;-)
--
http://lispm.dyndns.org/
From: Paul Donnelly
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87wsjd4tv7.fsf@plap.localdomain>
Vend <······@virgilio.it> writes:
> On 22 Lug, 10:36, Mikael Jansson <··············@gmail.com> wrote:
>> On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
>>> It's not like Emacs and vi are the easiest to use editors around.
>>
>> And of course, judging an editor based on how easy it is to use if you
>> have never used it before is rather pointless.
>
> It's not. The time and effort you need to learn to use something
> productively matters a lot.
Assuming that learning a text editor takes a lot of time and effort
for you compared to the amount of time you spend actually editing
text. I would hope the ratio skews heavily toward the latter activity.
From: Kaz Kylheku
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <20080722154201.835@gmail.com>
On 2008-07-22, Vend <······@virgilio.it> wrote:
> On 22 Lug, 10:36, Mikael Jansson <··············@gmail.com> wrote:
>> On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
>> > On 21 Lug, 18:21, Duane Rettig <·····@franz.com> wrote:
>> > > Vend <······@virgilio.it> writes:
>> > > > Sure, lisp-enabled editors can take care of that, but if you are stuck
>> > > > with a simple text editor then you are on your own.
>>
>> > > Nobody's ever "stuck" with a simple text editor. Emacs and vi are
>> > > pretty much ubiquitous, and even if not available temporarily, it
>> > > doesn't tend to last long. No, being "stuck" with a simple text
>> > > editor is almost always a choice.
>>
>> > It's not like Emacs and vi are the easiest to use editors around.
>>
>> And of course, judging an editor based on how easy it is to use if you
>> have never used it before is rather pointless.
>
> It's not. The time and effort you need to learn to use something
> productively matters a lot.
You're obvously a trolling fuck. I'd plonk you, but you're already kill-filed
based on your NNTP domain; the only reason I'm reading this bullshit is that I
made the mistake of explicitly chasing a parent article reference from one of
your followups.
I now return you to your flourishing software development career built around
using NOTEPAD.EXE or EDLIN.COM.
On 23 Lug, 00:46, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-07-22, Vend <······@virgilio.it> wrote:
>
>
>
> > On 22 Lug, 10:36, Mikael Jansson <··············@gmail.com> wrote:
> >> On Jul 21, 11:08 pm, Vend <······@virgilio.it> wrote:
> >> > On 21 Lug, 18:21, Duane Rettig <·····@franz.com> wrote:
> >> > > Vend <······@virgilio.it> writes:
> >> > > > Sure, lisp-enabled editors can take care of that, but if you are stuck
> >> > > > with a simple text editor then you are on your own.
>
> >> > > Nobody's ever "stuck" with a simple text editor. Emacs and vi are
> >> > > pretty much ubiquitous, and even if not available temporarily, it
> >> > > doesn't tend to last long. No, being "stuck" with a simple text
> >> > > editor is almost always a choice.
>
> >> > It's not like Emacs and vi are the easiest to use editors around.
>
> >> And of course, judging an editor based on how easy it is to use if you
> >> have never used it before is rather pointless.
>
> > It's not. The time and effort you need to learn to use something
> > productively matters a lot.
>
> You're obvously a trolling fuck. I'd plonk you, but you're already kill-filed
> based on your NNTP domain; the only reason I'm reading this bullshit is that I
> made the mistake of explicitly chasing a parent article reference from one of
> your followups.
>
> I now return you to your flourishing software development career built around
> using NOTEPAD.EXE or EDLIN.COM.
What a friendly attitude.
On 2008-07-22 04:41:35 -0400, Vend <······@virgilio.it> said:
> It's not. The time and effort you need to learn to use something
> productively matters a lot.
If some functionality is essential be being productive then it is a
fixed cost amortized over many years of use. The time spent learning to
comfortably use some editor that does paren matching and proper
indentation of lisp code is an absolute requirement for programming
effectively in lisp. You must make this investment of time. Just pick
the lisp aware editor you want to learn and learn it.
There is no magic escape from the need to learn *some* lisp-aware
editor in order to code effectively in lisp. You have now heard from a
half dozen people with decades of experience coding lisp that notepad
just won't cut it. Persisting in using notepad (or some other editor
that is not lisp aware) at this point is just stubborn wishful thinking
because you will never get notepad to edit lisp code nearly as quickly
and easily as can be done with emacs, or vi(m), or ACL's IDE, or LWW's
IDE, etc.
If you post again claiming that you are "stuck" with a non lisp-aware
editor you will only be proving Kenny's guess that yours is what he
calls an "imaginary whine" because if you are at all serious about
writing more than 10 lines of lisp code you will take the advice of
those with several cumulative lifetimes of experience and use *some*
lisp aware editor.
IOW, you will never match Wynton Marsalis's musical expressiveniss no
matter how well you play the kazoo. Saying you are "stuck" with notepad
is like saying you want to play jazz with Wynton Marsalis but are
"stuck" with the kazoo.
On 23 Lug, 19:05, Raffael Cavallaro <················@pas-d'espam-s'il-
vous-plait-mac.com> wrote:
> On 2008-07-22 04:41:35 -0400, Vend <······@virgilio.it> said:
>
> > It's not. The time and effort you need to learn to use something
> > productively matters a lot.
>
> If some functionality is essential be being productive then it is a
> fixed cost amortized over many years of use. The time spent learning to
> comfortably use some editor that does paren matching and proper
> indentation of lisp code is an absolute requirement for programming
> effectively in lisp. You must make this investment of time. Just pick
> the lisp aware editor you want to learn and learn it.
>
> There is no magic escape from the need to learn *some* lisp-aware
> editor in order to code effectively in lisp. You have now heard from a
> half dozen people with decades of experience coding lisp that notepad
> just won't cut it. Persisting in using notepad (or some other editor
> that is not lisp aware) at this point is just stubborn wishful thinking
> because you will never get notepad to edit lisp code nearly as quickly
> and easily as can be done with emacs, or vi(m), or ACL's IDE, or LWW's
> IDE, etc.
>
> If you post again claiming that you are "stuck" with a non lisp-aware
> editor you will only be proving Kenny's guess that yours is what he
> calls an "imaginary whine" because if you are at all serious about
> writing more than 10 lines of lisp code you will take the advice of
> those with several cumulative lifetimes of experience and use *some*
> lisp aware editor.
I didn't claim that. In fact, I mostly use DrScheme IDE or KDevelop.
My complain was that having to learn an IDE or a "smart" editor and a
odd-looking (for new users) language at the same time is probably an
element that keeps potential users away.
In fact, I would probably never have learned Lisp if I didn't had to
at college. I suppose this is the case with other people too.
> IOW, you will never match Wynton Marsalis's musical expressiveniss no
> matter how well you play the kazoo. Saying you are "stuck" with notepad
> is like saying you want to play jazz with Wynton Marsalis but are
> "stuck" with the kazoo.
From: Tobias C. Rittweiler
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <877ibc1jx4.fsf@freebits.de>
Vend <······@virgilio.it> writes:
> My complain was that having to learn an IDE or a "smart" editor and a
> odd-looking (for new users) language at the same time is probably an
> element that keeps potential users away.
I think we should care less about these "potential users" who will "at
some point in future" write "potential software", and care more about
people who are learning _now_, and who are writing cool software _now_.
Do you?
-T.
From: Paul Donnelly
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87y73sz8vl.fsf@plap.localdomain>
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> IOW, you will never match Wynton Marsalis's musical expressiveniss no
> matter how well you play the kazoo. Saying you are "stuck" with
> notepad is like saying you want to play jazz with Wynton Marsalis but
> are "stuck" with the kazoo.
Better not try to take the analogy this far--the kazoo strikes me as a more
flexible instrument than the trumpet.
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <48878d43$0$20904$607ed4bc@cv.net>
Paul Donnelly wrote:
> Raffael Cavallaro
> <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
>
>> IOW, you will never match Wynton Marsalis's musical expressiveniss no
>> matter how well you play the kazoo. Saying you are "stuck" with
>> notepad is like saying you want to play jazz with Wynton Marsalis but
>> are "stuck" with the kazoo.
>
> Better not try to take the analogy this far--the kazoo strikes me as a more
> flexible instrument than the trumpet.
How can you leave the harmonica out of this discussion? Meanwhile, can
you imagine how much better Romeo and Juliet would have turned out if
Dire Straits had had WordPad?
hth, kenny
In article
<····································@59g2000hsb.googlegroups.com>,
Ali <·············@gmail.com> wrote:
> Editors? gedit has no learn time and does have bracket matching
> powers. That's for gnome linux though.
One can get much more support for Lisp programming from an editor
than just bracket matching.
Reading the manual of an editor is still recommended.
There are several editors for Lisp. LispWorks has one.
Also written in Lisp. The LispWorks editor is easy to use.
Still for effective use, read the manuals:
LispWorks, Common LispWorks, Chapter 12, The Editor:
http://www.lispworks.com/documentation/lw51/CLWUG-M/html/clwuser-m-204.htm#pgfId-852604
LispWorks, Editor User Guide
http://www.lispworks.com/documentation/lw51/EDUG-M/html/eduser-m.htm
--
http://lispm.dyndns.org/
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87tzeg9qkz.fsf@hubble.informatimago.com>
Ali <·············@gmail.com> writes:
> Editors? gedit has no learn time and does have bracket matching
> powers. That's for gnome linux though.
Don't believe those who say that you need an editor that does bracket
matching to edit lisp code. Anybody can type a closing parenthesis
after an open parenthesis. If this is all your editor has to provide
to help you editing code, you could as well edit your code with a
magnet over the hard disk plate.
Fetch and use emacs, paredit and slime!!!
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
On Jul 24, 12:35 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Ali <·············@gmail.com> writes:
> > Editors? gedit has no learn time and does have bracket matching
> > powers. That's for gnome linux though.
>
> Don't believe those who say that you need an editor that does bracket
> matching to edit lisp code. Anybody can type a closing parenthesis
> after an open parenthesis. If this is all your editor has to provide
> to help you editing code, you could as well edit your code with a
> magnet over the hard disk plate.
>
> Fetch and use emacs, paredit and slime!!!
>
Just to chip in to the discussion on editors:
If you swing the other way, Limp for Vim beats manually copy-and-
pasting text into the REPL.
Limp adds some useful features, such as:
* booting/attaching/detaching a Lisp (SBCL) from Vim or a command-line
script, optionally specifying a core;
* send code to the attached Lisp (and limited introspection, see Help
Describe);
* automatically close brackets;
* ease s-exp navigation and (experimental) transposing;
* highlight current form under the cursor;
* lookup documentation from the HyperSpec;
* complete (some) names.
Get it at http://mikael.jansson.be/hacking/limp/docs/ -> Download
While it's nowhere near as polished nor feature-complete as SLIME, it
does ease Lisp development in Vim, and making it slimier is on the
todo list.
--
Mikael Jansson
http://mikael.jansson.be/hacking/limp
On Mon, 21 Jul 2008 09:21:14 -0700, Duane Rettig <·····@franz.com>
wrote:
>Vend <······@virgilio.it> writes:
>
>> On 21 Lug, 09:32, Mikael Jansson <··············@gmail.com> wrote:
>>
>> Identation conveys information to the programmer, while the
>> parentheses convey information to the machine, if identation is not in-
>> synch with the parentheses cognitive dissonance will ensue.
>>
>> Sure, lisp-enabled editors can take care of that, but if you are stuck
>> with a simple text editor then you are on your own.
>
>Nobody's ever "stuck" with a simple text editor. Emacs and vi are
>pretty much ubiquitous, and even if not available temporarily, it
>doesn't tend to last long. No, being "stuck" with a simple text
>editor is almost always a choice.
Yep! Even on Windows where Emacs is iffy (at least I've never been
able to get it to work reliably) there are some decent freely
available programming editors - some of which even have a useful Lisp
mode.
George
--
for email reply remove "/" from address
From: Steve Allan
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <uiquxwv2s.fsf@attachmate.com>
George Neuner <·········@/comcast.net> writes:
> On Mon, 21 Jul 2008 09:21:14 -0700, Duane Rettig <·····@franz.com>
> wrote:
>
>>Vend <······@virgilio.it> writes:
>>
>>> On 21 Lug, 09:32, Mikael Jansson <··············@gmail.com> wrote:
>>>
>>> Identation conveys information to the programmer, while the
>>> parentheses convey information to the machine, if identation is not in-
>>> synch with the parentheses cognitive dissonance will ensue.
>>>
>>> Sure, lisp-enabled editors can take care of that, but if you are stuck
>>> with a simple text editor then you are on your own.
>>
>>Nobody's ever "stuck" with a simple text editor. Emacs and vi are
>>pretty much ubiquitous, and even if not available temporarily, it
>>doesn't tend to last long. No, being "stuck" with a simple text
>>editor is almost always a choice.
>
> Yep! Even on Windows where Emacs is iffy (at least I've never been
> able to get it to work reliably)
As another data point for potential emacs users, I've been using emacs
on Windows for years. All day, everyday. I use it as an editor,
mail/news reader, planner, contact manager, shell, file manager, and
lisp IDE. I've always found it to be rock solid.
FWIW
--
-- Steve
On Tue, 22 Jul 2008 12:57:31 -0700, Steve Allan <··········@yahoo.com>
wrote:
>George Neuner <·········@/comcast.net> writes:
>
>>Even on Windows where Emacs is iffy (at least I've never been
>> able to get it to work reliably)
>
>As another data point for potential emacs users, I've been using emacs
>on Windows for years. All day, everyday. I use it as an editor,
>mail/news reader, planner, contact manager, shell, file manager, and
>lisp IDE. I've always found it to be rock solid.
I gave up on Emacs on Windows. Over the years, I've used most
versions of Windows and tried whatever version of Emacs was current on
them. I always found Emacs to be slow, flaky and prone to crashes ...
well, the char-mode versions weren't slow, but they were still flaky.
George
--
for email reply remove "/" from address
From: John Thingstad
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <op.ueppiyijut4oq5@pandora.alfanett.no>
P� Tue, 22 Jul 2008 21:57:31 +0200, skrev Steve Allan
<··········@yahoo.com>:
> George Neuner <·········@/comcast.net> writes:
>
>> On Mon, 21 Jul 2008 09:21:14 -0700, Duane Rettig <·····@franz.com>
>> wrote:
>>
>>> Vend <······@virgilio.it> writes:
>>>
>>>> On 21 Lug, 09:32, Mikael Jansson <··············@gmail.com> wrote:
>>>>
>>>> Identation conveys information to the programmer, while the
>>>> parentheses convey information to the machine, if identation is not
>>>> in-
>>>> synch with the parentheses cognitive dissonance will ensue.
>>>>
>>>> Sure, lisp-enabled editors can take care of that, but if you are stuck
>>>> with a simple text editor then you are on your own.
>>>
>>> Nobody's ever "stuck" with a simple text editor. Emacs and vi are
>>> pretty much ubiquitous, and even if not available temporarily, it
>>> doesn't tend to last long. No, being "stuck" with a simple text
>>> editor is almost always a choice.
>>
>> Yep! Even on Windows where Emacs is iffy (at least I've never been
>> able to get it to work reliably)
>
> As another data point for potential emacs users, I've been using emacs
> on Windows for years. All day, everyday. I use it as an editor,
> mail/news reader, planner, contact manager, shell, file manager, and
> lisp IDE. I've always found it to be rock solid.
>
> FWIW
>
Depends what you mean by reliably. If you use EmacsW32 it fixes many of
the annoyances with GNU emacs. Like the printer will work.
Also get GNU utilleties for W32 and make sure Emacs sees it (set PATH).
This should make most stuff work.
get Miktex and Ghostscript as well for LaTeX support. (get auctex mode as
well)
For full support for pictures make sure the build is for version 22.1 or
higher.
--------------
John Thingstad
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87fxq3p0ai.fsf@hubble.informatimago.com>
Duane Rettig <·····@franz.com> writes:
> Nobody's ever "stuck" with a simple text editor. Emacs and vi are
> pretty much ubiquitous, and even if not available temporarily, it
> doesn't tend to last long.
Indeed: 11 minutes away on this slow computer:
[···@hubble tmp]$ time bash -c '( cd /tmp ; wget ftp://ftp.gnu.org/pub/gnu/emacs/emacs-22.2.tar.gz ; tar zxf emacs-22.2.tar.gz ; cd emacs-22.2 ; ./configure --prefix=$HOME/opt && make && make install ) > /tmp/emacs.log 2>&1 && $HOME/opt/bin/emacs --version'
GNU Emacs 22.2.1
Copyright (C) 2008 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
real 10m52.591s
user 4m8.684s
sys 0m45.219s
[···@hubble tmp]$ cat /proc/cpuinfo |grep -i bogo
bogomips : 2688.05
[···@hubble tmp]$
> No, being "stuck" with a simple text
> editor is almost always a choice.
Make the right choice, type at your shell:
( cd /tmp ;\
wget ftp://ftp.gnu.org/pub/gnu/emacs/emacs-22.2.tar.gz ;\
tar zxf emacs-22.2.tar.gz ;\
cd emacs-22.2 ;\
./configure --prefix=$HOME/opt && make && make install )
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5v83j$j3i$1@aioe.org>
Mikael Jansson wrote
> Once I realized that all forms are (more-or-less) equal, and that
> parens don't really have any "meaning" (in the C sense of grouping to
> make explicit precedence), they'll start fading away and stop becoming
> a nuisance.
Except that the superfluous parentheses are essential to understand s-exprs
so they cannot fade away. What you really mean, of course, is that you have
learned to live with them because you don't know any better.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Jul 20, 1:37 pm, Jon Harrop <····@ffconsultancy.com> wrote:
> Mikael Jansson wrote
>
> > Once I realized that all forms are (more-or-less) equal, and that
> > parens don't really have any "meaning" (in the C sense of grouping to
> > make explicit precedence), they'll start fading away and stop becoming
> > a nuisance.
>
> Except that the superfluous parentheses are essential to understand s-exprs
> so they cannot fade away. What you really mean, of course, is that you have
> learned to live with them because you don't know any better.
>
Nah, I tend to say what I mean. Of course, there will always be
people trying to put words into one's mouth.
In any event. At first, the parens are distracting, but eventually you
start looking at other cues such as indentation. Parens just become
the way to mark how the indentation is done and to, well, bundle
together symbols to form expression. I'll give you one for the "learn
to live with it", but it's a "wow, these thingies are useful!" rather
than "yuck, I wish they'd go away!" feeling. Editing becomes so much
easier when you can move around a piece of code simply by extracting
everything inside a set of parens, same thing with navigation.
Moreover, with modern editors such as Vim, you can fairly easily
customize the syntax highlighting -- I myself have a black background,
and parens in an almost-black gray...
Don't know what else to say, other than the fact that they do
disappear over time, when you have had some experience actually
writing Lisp code...
--
Mikael Jansson
Limp: The Lisp IDE for Vim - http://mikael.jansson.be/hacking/limp
On 2008-07-20, Jon Harrop <···@ffconsultancy.com> wrote:
> Mikael Jansson wrote
>> Once I realized that all forms are (more-or-less) equal, and that
>> parens don't really have any "meaning" (in the C sense of grouping to
>> make explicit precedence), they'll start fading away and stop becoming
>> a nuisance.
>
> Except that the superfluous parentheses are essential to understand s-exprs
^^^^^^^^^^^ ^^^^^^^^^
There he goes again, mixing antonyms.
From: Stefan Nobis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <m1tzer8jn9.fsf@familie-nobis.de>
Jon Harrop <···@ffconsultancy.com> writes:
> Kaz Kylheku wrote:
>> A new rule is a far greater burden than a pair of parentheses.
> Almost all programmers and mathematicians disagree with you on that.
Hmmm... and that's why in every math book all those pages on basic
notations are wasted? Because these rules and abbreviations are so
common and easy and streamlined, that they are no burden, really easy
to remember and an overall success story that have to be generalized
to everything and are not just only useful in special purpose text
books?
OK, then maybe I'm an exception: I hate all those abbreviations
(mostly) and have quite some problems to distinguish their
meanings. For me, reading math books is really hard work. So, I
assume, Lisp is for people like me: Just be a bit more elaborate, but
then it's much more readable afterwards. (Maybe I'm just to dumb for
all those abbreviations -- by the way: I also don't like Perl, and
Haskell is a bit too perlish for me.) :)
--
Stefan.
Next time, I make a little suggestion, we will must not speak about
xcaml in the title to avoid the Harrop pollution.
He is unbearrable.
comp.lang.lisp NOT equals comp.lang.ocaml ...
Best Regards,
Christophe
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g55lm6$qn1$1@aioe.org>
John Thingstad wrote:
> pattern matching as in cl-ppcre, cl-yacc, cl-unify,...?
As in Qi.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Stanisław Halik
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5s66g$cvv$2@opal.icpnet.pl>
thus spoke Jon Harrop <···@ffconsultancy.com>:
>> Yes, sure. I cheated by making Juho's example 162 lines. :) I suppose
>> we can cheat in many other ways.
> Much of the Lisp code is wasted performing tedious manual
> deconstructions of data structures because Lisp lacks pattern
> matching. I wonder how much more reasonable the code might look if you
> pull in cl-unification.
Lisp is dynamically typed so pattern-matching can't be done during
compile time. It's a design tradeoff.
--
The great peril of our existence lies in the fact that our diet consists
entirely of souls. -- Inuit saying
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <873am6yxgn.fsf@hubble.informatimago.com>
Stanisław Halik <··············@tehran.lain.pl> writes:
> thus spoke Jon Harrop <···@ffconsultancy.com>:
>
>>> Yes, sure. I cheated by making Juho's example 162 lines. :) I suppose
>>> we can cheat in many other ways.
>> Much of the Lisp code is wasted performing tedious manual
>> deconstructions of data structures because Lisp lacks pattern
>> matching. I wonder how much more reasonable the code might look if you
>> pull in cl-unification.
>
> Lisp is dynamically typed so pattern-matching can't be done during
> compile time. It's a design tradeoff.
This is not exactly the case.
It depends on the program, not on the language.
(defun f ()
(flet ((g (x)
(etypecase x
(string (concatenate 'string x x))
(number (/ x 2))
(symbol (symbol-value x)))))
(g 84)))
if you compile-file this function, the compiler is entitled to
generate only this code for f:
(defun f ()
(flet ((g (x) (/ x 2)))
(g 84)))
or even:
(defun f ()
42)
Even if g was public:
(defun g (x)
(etypecase x
(string (concatenate 'string x x))
(number (/ x 2))
(symbol (symbol-value x))))
the compiler could actually generate five binary functions for g:
(defun g/string (x) (concatenate 'string x x))
(defun g/number (x) (/ x 2))
(defun g/symbol (x) (symbol-value x))
(defun g/error (x) (error "expected string, number of symbol, not ~S" (type-of x)))
(defun g (x)
(etypecase x
(string (concatenate 'string x x))
(number (/ x 2))
(symbol (symbol-value x))))
and depending on the infered type at the call site, call one or the
other. Only in the rarest situation, when an argument type is not
known, would the generic g be called:
(g (ecase (random 3) (0 "XXIV") (1 84) (2 :fourty-two)))
(g 84) could be compiled as (g/number 84)
But how often do you really pass random arguments to your functions?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
On 19 Lug, 12:34, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
<snip>
> But how often do you really pass random arguments to your functions?
Not often, but I think that in large programs written in dynamically-
typed languages it's difficult for the compiler to perform compile-
time type-inference, expecially for values passed between different
lexical scopes, so I wouldn't rely on it.
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87vdz2xfpo.fsf@hubble.informatimago.com>
Vend <······@virgilio.it> writes:
> On 19 Lug, 12:34, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> <snip>
>
>> But how often do you really pass random arguments to your functions?
>
> Not often, but I think that in large programs written in dynamically-
> typed languages it's difficult for the compiler to perform compile-
> time type-inference, expecially for values passed between different
> lexical scopes, so I wouldn't rely on it.
It is not too difficult, but it would require global analysis, and
freezing the code. Freezing the code is not something that's often
done when we program in lisp (some people even correct bugs in web
applications with the users on phone, asking them "What bug? Could you
try again?").
But when you're ready to deploy an application, and to use a
tree-shaker, then a globally analysing compiler could do miracles.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
On 19 Lug, 13:42, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Vend <······@virgilio.it> writes:
> > On 19 Lug, 12:34, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> > <snip>
>
> >> But how often do you really pass random arguments to your functions?
>
> > Not often, but I think that in large programs written in dynamically-
> > typed languages it's difficult for the compiler to perform compile-
> > time type-inference, expecially for values passed between different
> > lexical scopes, so I wouldn't rely on it.
>
> It is not too difficult, but it would require global analysis, and
> freezing the code. Freezing the code is not something that's often
> done when we program in lisp (some people even correct bugs in web
> applications with the users on phone, asking them "What bug? Could you
> try again?").
What do you mean by "freezing the code"?
> But when you're ready to deploy an application, and to use a
> tree-shaker, then a globally analysing compiler could do miracles.
On Sat, 19 Jul 2008 07:19:55 -0700 (PDT), Vend <······@virgilio.it> said:
| ...
| What do you mean by "freezing the code"?
(1) Prohibiting code changes before a release.
(2) Subcontracting development to a company in Alaska, Chukotka,
Greenland, or Spitsbergen.
(3) Proclaiming everything inline, pervasively.
(4) Testing the software for the Large Hadron Collider's refrigerators.
(5) All of the above.
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87r69pygu1.fsf@hubble.informatimago.com>
Vend <······@virgilio.it> writes:
> On 19 Lug, 13:42, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> Vend <······@virgilio.it> writes:
>> > On 19 Lug, 12:34, ····@informatimago.com (Pascal J. Bourguignon)
>> > wrote:
>> > <snip>
>>
>> >> But how often do you really pass random arguments to your functions?
>>
>> > Not often, but I think that in large programs written in dynamically-
>> > typed languages it's difficult for the compiler to perform compile-
>> > time type-inference, expecially for values passed between different
>> > lexical scopes, so I wouldn't rely on it.
>>
>> It is not too difficult, but it would require global analysis, and
>> freezing the code. Freezing the code is not something that's often
>> done when we program in lisp (some people even correct bugs in web
>> applications with the users on phone, asking them "What bug? Could you
>> try again?").
>
> What do you mean by "freezing the code"?
Have you ever tried to modify code by -20 celcius?
When the sources are read-only, you can run global analyses, and
unless heavy run-time meta-programming techniques are used, most of
the code can be determined at "compilation time".
If all occurences of calls to my function G are done with arguments
whose type can be infered at compilation time, then there is no need
to generate the generic G, the compiler can generate only the
statically typed versions.
Unless something like (eval `(,(read) ,(read))) appears somewhere, but
this means that the code cannot be freezed, since it can be
modified/determined only at run-time.
>> But when you're ready to deploy an application, and to use a
>> tree-shaker, then a globally analysing compiler could do miracles.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."
In article
<····································@k13g2000hse.googlegroups.com>,
Vend <······@virgilio.it> wrote:
> On 19 Lug, 12:34, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> <snip>
>
> > But how often do you really pass random arguments to your functions?
>
> Not often, but I think that in large programs written in dynamically-
> typed languages it's difficult for the compiler to perform compile-
> time type-inference, expecially for values passed between different
> lexical scopes, so I wouldn't rely on it.
Depends. When using CLOS the selected methods may have some
more information:
(defmethod foo ((bar float))
(+ bar 2.0))
(defmethod belongs-to ((p1 person) (b1 book))
...)
Within the second method you know that it was called with
p1 as an object of class person and b1 of class book.
Within FOO you know that it was called with an object of class float.
In this case the class float is also the same as the type float.
The compiler would add the float bar to the float 2.0 and the
result would be another float.
--
http://lispm.dyndns.org/
On 19 Lug, 14:39, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@k13g2000hse.googlegroups.com>,
>
> Vend <······@virgilio.it> wrote:
> > On 19 Lug, 12:34, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> > <snip>
>
> > > But how often do you really pass random arguments to your functions?
>
> > Not often, but I think that in large programs written in dynamically-
> > typed languages it's difficult for the compiler to perform compile-
> > time type-inference, expecially for values passed between different
> > lexical scopes, so I wouldn't rely on it.
>
> Depends. When using CLOS the selected methods may have some
> more information:
>
> (defmethod foo ((bar float))
> (+ bar 2.0))
>
> (defmethod belongs-to ((p1 person) (b1 book))
> ...)
>
> Within the second method you know that it was called with
> p1 as an object of class person and b1 of class book.
>
> Within FOO you know that it was called with an object of class float.
> In this case the class float is also the same as the type float.
> The compiler would add the float bar to the float 2.0 and the
> result would be another float.
But in these cases (the first one in particular) you are using static
typing.
From: Stanisław Halik
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5spc4$cvv$4@opal.icpnet.pl>
thus spoke Pascal J. Bourguignon <···@informatimago.com>:
>> Lisp is dynamically typed so pattern-matching can't be done during
>> compile time. It's a design tradeoff.
> This is not exactly the case.
> It depends on the program, not on the language.
> (defun f ()
> (flet ((g (x)
> (etypecase x
> (string (concatenate 'string x x))
> (number (/ x 2))
> (symbol (symbol-value x)))))
> (g 84)))
> if you compile-file this function, the compiler is entitled to
> generate only this code for f:
> (defun f ()
> (flet ((g (x) (/ x 2)))
> (g 84)))
> or even:
> (defun f ()
> 42)
> Even if g was public:
> (defun g (x)
> (etypecase x
> (string (concatenate 'string x x))
> (number (/ x 2))
> (symbol (symbol-value x))))
> the compiler could actually generate five binary functions for g:
> (defun g/string (x) (concatenate 'string x x))
> (defun g/number (x) (/ x 2))
> (defun g/symbol (x) (symbol-value x))
> (defun g/error (x) (error "expected string, number of symbol, not ~S" (type-of x)))
> (defun g (x)
> (etypecase x
> (string (concatenate 'string x x))
> (number (/ x 2))
> (symbol (symbol-value x))))
Except that redefinition of g can happen at any point, thus callees
can't really reference any of the g/* stuff, otherwise the changes to
native code would have to be propagated in real time. A SSC could do all
of that, but there's a fine line of what's technically possible and
what's feasible in practice.
Why all the attention given to Toady? It's hard to catch up with several
hundreds of posts after a few days of absence. Could we please raise the
s/n ratio a bit? :-)
--
The great peril of our existence lies in the fact that our diet consists
entirely of souls. -- Inuit saying
In article <············@opal.icpnet.pl>,
Stanis��aw Halik <··············@tehran.lain.pl> wrote:
> thus spoke Pascal J. Bourguignon <···@informatimago.com>:
>
> >> Lisp is dynamically typed so pattern-matching can't be done during
> >> compile time. It's a design tradeoff.
> > This is not exactly the case.
> > It depends on the program, not on the language.
>
> > (defun f ()
> > (flet ((g (x)
> > (etypecase x
> > (string (concatenate 'string x x))
> > (number (/ x 2))
> > (symbol (symbol-value x)))))
> > (g 84)))
>
> > if you compile-file this function, the compiler is entitled to
> > generate only this code for f:
>
> > (defun f ()
> > (flet ((g (x) (/ x 2)))
> > (g 84)))
>
> > or even:
>
> > (defun f ()
> > 42)
>
> > Even if g was public:
>
> > (defun g (x)
> > (etypecase x
> > (string (concatenate 'string x x))
> > (number (/ x 2))
> > (symbol (symbol-value x))))
>
> > the compiler could actually generate five binary functions for g:
>
> > (defun g/string (x) (concatenate 'string x x))
> > (defun g/number (x) (/ x 2))
> > (defun g/symbol (x) (symbol-value x))
> > (defun g/error (x) (error "expected string, number of symbol, not ~S" (type-of x)))
> > (defun g (x)
> > (etypecase x
> > (string (concatenate 'string x x))
> > (number (/ x 2))
> > (symbol (symbol-value x))))
>
> Except that redefinition of g can happen at any point,
No. There are two ways to look at it:
1) what the Lisp system actually implements. For example for a
delivery system, there might be all kinds of optimizations
selectable - more than what the ANSI CL spec would define.
2) ANSI CL already defines restrictions. For example the file compiler
(called by COMPILE-FILE ) may assume
a) that a call to G inside G is the same G
(defun g (x)
...
(g y) ; <- this G is the same G as above
...)
b) that G used by other functions in the same file is the same G:
--- file foo.lisp
(defun g (x) ...)
(defun f (y) (g (+ y 10))) ; <- This G is the G above.
--- end of file foo.lisp
Some compilers mayalso do analysis across files (called blocks)
or delivery systems.
> thus callees
> can't really reference any of the g/* stuff, otherwise the changes to
> native code would have to be propagated in real time. A SSC could do all
> of that, but there's a fine line of what's technically possible and
> what's feasible in practice.
>
> Why all the attention given to Toady? It's hard to catch up with several
> hundreds of posts after a few days of absence. Could we please raise the
> s/n ratio a bit? :-)
--
http://lispm.dyndns.org/
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87iqv1yfw3.fsf@hubble.informatimago.com>
Stanisław Halik <··············@tehran.lain.pl> writes:
> Except that redefinition of g can happen at any point, thus callees
> can't really reference any of the g/* stuff, otherwise the changes to
> native code would have to be propagated in real time. A SSC could do all
> of that, but there's a fine line of what's technically possible and
> what's feasible in practice.
Indeed, that's why the condition is to freeze the code. Lisp programs
can be self modifying, but most lisp programs are not self modifying
and those who are self modifying are only partly self modifying. Only
a few functions are modified at run-time.
For example, while a lisp implementation (REPL) is widely self
modifying (since it provides the REPL to let the programmer modify it
intensively at run-time, to the point of morphing the lisp
implementation into other applications, usually all the code in the
COMMON-LISP package is frozen.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
From: Kaz Kylheku
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <20080709152830.386@gmail.com>
On 2008-07-09, Jon Harrop <···@ffconsultancy.com> wrote:
> Javier wrote:
>> But, in general, if you only count the number of lines, Lisp is
>> usually shorter.
>
> Actually Lisp is almost always longer by any reasonable metric including
> LOC. I went out of my way to measure the verbosity of Lisp on the ray
> tracer benchmark:
>
> http://www.ffconsultancy.com/languages/ray_tracer/results.html
>
> Lisp is among the most verbose languages both by LOC and non-whitespace
> bytes.
If you were benchmarking programming languages for speed, wouldn't
the programs be optimized for speed? Wouldn't a speed-optimized Common Lisp
ray-tracing benchmark program have lots of declaration-heavy sections,
greatly inflating its size?
Should a honest researcher be using small, speed-optimized pieces of benchmark
source code pieces as the basis for claims about the code density of typical
programs written in some programming language?
LOC and bytes are /not/ particularly reasonable metrics, either.
I suggest that counting the number of atoms and in its abstract syntax tree is
a better indicator of the true size of a program.
LOC can be reduced by cramming more code into a line of code.
A raw character count, even if whitespace is excluded, is inflated by the use
of longer identifiers. Rewriting a function with longer identifiers doesn't
change its complexity.
> in fact the Lisp programs are at
> the longer, more verbose end.
I think thats the way they are written. The implementors aimed for
performance and put in all the bells and whistles (often at the cost
of perpiscuity).
Mark
From: Kenny
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <48628038$0$11628$607ed4bc@cv.net>
Mark Tarver wrote:
>> in fact the Lisp programs are at
>> the longer, more verbose end.
>
> I think thats the way they are written. The implementors aimed for
> performance and put in all the bells and whistles (often at the cost
> of perpiscuity).
How prosmicuous of you!
:)
kt
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <7cskv1lec5.fsf@pbourguignon.anevia.com>
Ois�n Mac Fheara� <···········@gmail.com> writes:
> The memory use is still pretty high though.
Who cares?
> What I'd personally like to see is a set of quite large applications,
> implemented in different languages, so we could compare the
> readability and code sizes. In the shootout programs, they're a)
> optimised to the level where they're barely above C and b) too short
> and limited in scope to be meaningful samples on those terms.
> Everyone is saying that Lisp is more expressive than other languages,
> but it's not visible on the shootout; in fact the Lisp programs are at
> the longer, more verbose end.
But on large applications, you won't have the same application,
because obviously you will program it differently in different
programming languages. Or else, you'll be doing Fortran in C and in
Lisp, and you won't compare how well gcc compiles C vs. how well sbcl
compiles lisp, but how well gcc compiles Fortran vs. how well sbcl
compiles Fortran.
Therefore you won't be comparing the compilers, or the language per se
anymore. You will be comparing the whole system: (developers ide
libraries language compiler). And since this includes a human
factor, they will say, "Of course, but it's not because lisp is
better, it's just you took good lisp programmers and bad blub
programmers.".
--
__Pascal Bourguignon__
On Jun 25, 4:32 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Oisín Mac Fhearaí <···········@gmail.com> writes:
>
> > The memory use is still pretty high though.
>
> Who cares?
Well, for example, most programmers including myself approaching a new
language have a perhaps superstitious need to compare benchmarks and
see 'how fast' or 'how big' programs are when compiled. Even if we
don't actually need cutting edge speed in our web-app/stock quote
fetcher/...etc.
The huge memory use thing is a bit offputting when you used to be
disappointed upon 'upgrading' from C to C++ and finding that some
simple application now compiles to over 100k (!!) and uses 5 megs of
heap to do its job. Then again, I read a really interesting article
called "Lisping at JPL" a month ago or so when I decided to learn
Lisp, which described useful Lisp systems on embedded platforms with a
ridiculous amount of RAM (compiled Lisp running in 2kb, then 32kb, and
an interpreter running in 8mb). Maybe the programs used in the
shootout cause a lot of things to be allocated before a GC kicks in,
or maybe SBCL carries a large runtime.
> Therefore you won't be comparing the compilers, or the language per se
> anymore. You will be comparing the whole system: (developers ide
> libraries language compiler). And since this includes a human
> factor, they will say, "Of course, but it's not because lisp is
> better, it's just you took good lisp programmers and bad blub
> programmers.".
That's true. Also, I guess the code would be quite contrived and not
representative of real Lisp, like the shootout code (too C-style-
optimised - it's a pity the compilers don't automatically do more of
that stuff so we can have automatically-optimised code which isn't so
ugly). I guess it'd be more beneficial and natural to just search up
some good Lisp code (AI archives look good) and see how I feel about
it, and whether my confusions and worries are answered; for example,
how big does an application have to be before macros and such become
useful abstractions? What's the deal with that weird gensym stuff? Are
dynamic variables good or bad?
Oisín
In article
<····································@j22g2000hsf.googlegroups.com>,
Ois�n Mac Fheara� <···········@gmail.com> wrote:
> On Jun 25, 4:32�pm, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
> > Ois�n Mac Fheara� <···········@gmail.com> writes:
> >
> > > The memory use is still pretty high though.
> >
> > Who cares?
>
> Well, for example, most programmers including myself approaching a new
> language have a perhaps superstitious need to compare benchmarks and
> see 'how fast' or 'how big' programs are when compiled. Even if we
> don't actually need cutting edge speed in our web-app/stock quote
> fetcher/...etc.
> The huge memory use thing is a bit offputting when you used to be
> disappointed upon 'upgrading' from C to C++ and finding that some
> simple application now compiles to over 100k (!!) and uses 5 megs of
> heap to do its job. Then again, I read a really interesting article
> called "Lisping at JPL" a month ago or so when I decided to learn
> Lisp, which described useful Lisp systems on embedded platforms with a
> ridiculous amount of RAM (compiled Lisp running in 2kb, then 32kb, and
> an interpreter running in 8mb). Maybe the programs used in the
> shootout cause a lot of things to be allocated before a GC kicks in,
> or maybe SBCL carries a large runtime.
Check out Clozure CL. Its code is quite small and the runtime
is small, too. What is now Clozure CL started twenty years ago on
tiny Macs with 4MB RAM. CLISP has also a small footprint.
If you compare compiled Lisp to other code make sure that
you understand whether the compiled Lisp code contains development
information or not. Development information would be:
* original parsed source code
* symbols
* argument lists
* documentation strings
* source locations
* other debug info
Plus the Lisp application may include some facilities
that might not be needed (for example the compiler might not
be needed).
Some Lisp systems can get rid of most of that and more.
For example for LispWorks and Allegro CL there are
delivery tools which also remove unused code and
do lots of other fancy things.
But often one just delivers Lisp applications with full
development information. That makes it quite large sometimes.
Having the ability to change running software is
one of the strengths of Lisp systems.
> > Therefore you won't be comparing the compilers, or the language per se
> > anymore. You will be comparing the whole system: (developers ide
> > libraries language compiler). � And since this includes a human
> > factor, they will say, "Of course, but it's not because lisp is
> > better, it's just you took good lisp programmers and bad blub
> > programmers.".
>
> That's true. Also, I guess the code would be quite contrived and not
> representative of real Lisp, like the shootout code (too C-style-
> optimised - it's a pity the compilers don't automatically do more of
> that stuff so we can have automatically-optimised code which isn't so
> ugly). I guess it'd be more beneficial and natural to just search up
> some good Lisp code (AI archives look good) and see how I feel about
> it, and whether my confusions and worries are answered; for example,
> how big does an application have to be before macros and such become
> useful abstractions?
You have to find out. ;-)
> What's the deal with that weird gensym stuff?
Used in generated code for generated symbols.
> Are dynamic variables good or bad?
Both.
>
> Ois�n
--
http://lispm.dyndns.org/
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <rem-2008jul11-005@yahoo.com>
> From: Rainer Joswig <······@lisp.de>
> What is now Clozure CL started twenty years ago on tiny Macs with
> 4MB RAM.
That wasn't tiny!! RAM was horribly expensive back then. Where I
worked at Stanford, during our Calculus-CAI project (1986-91), my
boss bought a Macintosh II, as target for porting our software
which had already been developed on Tenex, because we wanted
students in high schools to use our software without needing to
maintain a 1200 baud modem connection to Stanford's IMSSS Tenex
system and suffer loss of context each time the modem disconnected.
But 1MB RAM chips for the Mac weren't available, so he had to
change plans and port to VM/CMS instead. (Then later IBM gave us a
good deal on some Unix workstations and we ported to them too.) In
1990 I finally could afford my own Macintosh Plus, with only one
megabyte of RAM. I couldn't afford to upgrade to 2.5 MB until years
later. Maybe my 1 MB was tiny, but back around 1976 I purchased a
custom-built MOS-6502 computer with only 4k bytes of RAM (and 1k
bytes of pROM that contained octal-DDT, downloader utility, and
relay-between-two-RS232-ports utility so that I could switch
between terminal-talking-to-6502 and
terminal-talking-through-modem-to-Stanford-or-MIT just by starting
and stopping the program without having to physically change
cables). That 4k bytes of RAM was *tiny*, requiring about half of
it for the screen buffer for my DataMedia 2500 emulator I wrote,
but the emulator code was small enough that I had plenty of extra
RAM for a background program to run whenever the DM2500 emulator
didn't need service (it ran *entirely* on device interrupts, no
main program at all). One such background program counted the
number of ways to bisect an 11-by-11 chessboard into congruent
halves for the first time ever.
4 MB RAM was immense compared to what I did very useful work on!
(Well I cheated a little, cross-assembling MOS-6502 code on the
PDP-10 at Stanford-AI then downloading it using a bootstrap
downloader I wrote myself that allowed multiple independent blocks
of code to be downloaded in a single batch process, with progress
reports on-screen as it runs, client program cross-assembled too,
server program written in Lisp or Algol, I forget which.)
> ... for LispWorks and Allegro CL there are delivery tools which
> also remove unused code and do lots of other fancy things.
If the language system is properly factored into barebones
essentials and add-on libraries, that ought to make this process
easier. Just use the essentials plus the libraries you are actually
using. And with Lisp you can even split up libraries down to the
single function level if you have software to analyze call graphs
to find everything that could ever be called directly or indirectly
by your application. And for some applications you don't need GC
since you the amount of memory you newly-allocate during runtime is
tiny enough.
> But often one just delivers Lisp applications with full
> development information. That makes it quite large sometimes.
> Having the ability to change running software is
> one of the strengths of Lisp systems.
Yeah. That depends on who the customer is. Will the customer be
able to debug? Will the customer be able to take instructions over
the phone about how to download a patch which either better
diagnoses the problem or actually fixes it? Or does the customer
want shrink-wrapped software that either works or doesn't from the
get-go, and installing patches in the field is not an option
because "time is money"? It's good if the vendor has options how
*much* debugging/development environment to include for different
situations.
> > What's the deal with that weird gensym stuff?
> Used in generated code for generated symbols.
Or make-symbol if you want the print-name to be meaningful in some
way, and you want the name to be consistent from run to run so that
you can use grep or other keyword search to find where that symbol
appears in trace output, like if some human will *ever* look at it,
such as during debugging.
> > Are dynamic variables good or bad?
> Both.
And there's a sorta-third option. Just *one* dynamic variable per
call stack which points to a single data structure that has *all*
the dynamic information nicely organized, such as in a hash table
or nested ASSOC lists or binary search tree etc. If you use a
self-balancing binary-search-tree using the no-side-effect
methodology (make any change by re-allocating the path down to the
change and sharing all side branches that didn't change), and you
re-bind the "special" (dynamic) variable whenever your thread is
about to make a change to its value, then you can fork threads with
shared pointer to a single call-stack sbbst and the different
threads will non-destructively update their view of "it"
independently, and the whole thing will be thread safe, like this:
(defvar $sbbst$ (make-empty-sbbst))
(defun ... (...)
"Called from dynamic context where
somebody else has already put stuff in $sbbst$
that we'll be referring to here"
... code referring to original state of sbbst ...
(let* ((newkey ...) (newval ...)
($sbbst$ (sbbst-insert $sbbst$ newkey newval)))
... code referring to new updated state of sbbst ...
(... call to function that can refer to my rebinding of $sbbst$ ...)
)
... code referring to original state of sbbst, which is visible again ...
(let* ((oldkey ...)
($sbbst$ (sbbst-delete $sbbst$ oldkey)))
... code referring to new updated state of sbbst ...
(... call to function that can refer to my rebinding of $sbbst$ ...)
)
... code referring to original state of sbbst, which is visible again ...
(let ((newkey1 ...) (newval1 ...)
(newkey2 ...) (newval2 ...))
(let ((new-sbbst1 (sbbst-insert $sbbst$ newkey1 newval1))
(new-sbbst2 (sbbst-insert $sbbst$ newkey2 newval2))
(multiple-thread-bind ;Does a JOIN of both threads finishing and
; returning their respective values
; before starting to execute the body
((res1 (let (($sbbst$ new-sbbst1)) (doSomething ...)))
(res2 (let (($sbbst$ new-sbbst2)) (doSomething ...))))
(doSomethingWithBothResults res1 res2) ;This is the body here
)))
)
On 25 jun, 07:38, Vassil Nikolov <···············@pobox.com> wrote:
> On Tue, 24 Jun 2008 22:12:35 -0700 (PDT), Javier <·······@gmail.com> said:
>
> | Have you seen the shootout recently?:
>
> Not to diminish the achievements of all who contribute to SBCL, of
> course---
>
> Besides Shakespeare's works, Lewis Carroll's also have a quote for
> everything, more or less:
>
> "Are five nights warmer than one night, then?" Alice ventured to
> ask.
>
> "Five times as warm, of course."
>
> "But they should be five times as _cold_, by the same rule---"
>
> "Just so!" cried the Red Queen. "Five times as warm, _and_ five
> times as cold---just as I'm five times as rich as you are, _and_
> five times as clever!"
>
> (_Through the Looking-Glass_, Chapter IX)
Ok, Shakespeare in c.l.l. The latest thing we happen to see here.
You say that you don't want to diminish the SBCL team, what do you
mean with this quote then?
On Tue, 24 Jun 2008 22:12:35 -0700 (PDT), Javier <·······@gmail.com> said:
| ...
| <http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all>
| ...
| SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
| times faster than Java (client), and is finally as fast as Ocaml.
On Wed, 25 Jun 2008 07:38:58 -0700 (PDT), Javier <·······@gmail.com> said:
| On 25 jun, 07:38, Vassil Nikolov <···············@pobox.com> wrote:
|| ...
|| � � "Are five nights warmer than one night, then?" �Alice ventured to
|| � � ask.
|| � � "Five times as warm, of course."
|| � � "But they should be five times as _cold_, by the same rule---"
|| � � "Just so!" cried the Red Queen. �"Five times as warm, _and_ five
|| � � times as cold---just as I'm five times as rich as you are, _and_
|| � � five times as clever!"
|| � (_Through the Looking-Glass_, Chapter IX)
| ...
| You say that you don't want to diminish the SBCL team, what do you
| mean with this quote then?
That it summarizes fairly well many---not all, but way too
many---discussions about "X is faster than Y". It is about such
discussions, not about SBCL.
I don't want to ask why an _implementation_---SBCL---is quoted to be
slower or faster than one or another _language_ (C++, C, etc.).
Perhaps more importantly, I don't want to ask what exactly "faster"
or "slower" mean when languages---or implementations---are compared,
either. (I do not say that such a meaning cannot be ascribed in a
sensible way, just that it requires some care, and more than I am
willing to afford at this time.) Is this horse still alive anyway?
Note that the above web page itself only gives lies ^W damn lies ^W^W
statistics, but does not speak of faster or better (except the
sarcastic question at the top; the FAQ is another matter, but then
some of it is tongue-in-cheek, of course).
By the way, Gabriel's _Performance and Evaluation of Lisp Systems_
is still worth reading for more than historic value; and it is now
available as a PDF file from Gabriel's site
(<http://www.dreamsongs.com/Files/Timrep.pdf>).
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <873an0kaj4.fsf@hubble.informatimago.com>
Vassil Nikolov <···············@pobox.com> writes:
> On Tue, 24 Jun 2008 22:12:35 -0700 (PDT), Javier <·······@gmail.com> said:
> | ...
> | <http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all>
> | ...
> | SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
> | times faster than Java (client), and is finally as fast as Ocaml.
>
> On Wed, 25 Jun 2008 07:38:58 -0700 (PDT), Javier <·······@gmail.com> said:
>
> | On 25 jun, 07:38, Vassil Nikolov <···············@pobox.com> wrote:
> || ...
> || � � "Are five nights warmer than one night, then?" �Alice ventured to
> || � � ask.
> || � � "Five times as warm, of course."
> || � � "But they should be five times as _cold_, by the same rule---"
> || � � "Just so!" cried the Red Queen. �"Five times as warm, _and_ five
> || � � times as cold---just as I'm five times as rich as you are, _and_
> || � � five times as clever!"
> || � (_Through the Looking-Glass_, Chapter IX)
>
> | ...
> | You say that you don't want to diminish the SBCL team, what do you
> | mean with this quote then?
>
> That it summarizes fairly well many---not all, but way too
> many---discussions about "X is faster than Y". It is about such
> discussions, not about SBCL.
>
> I don't want to ask why an _implementation_---SBCL---is quoted to be
> slower or faster than one or another _language_ (C++, C, etc.).
To help people understand the futility of this exercise, compare:
int fact(int x){
return((i<=1)?1:(x*fact(x-1)));
}
int main(void){
printf("%d\n",fact(1000));
return(0);
}
vs.
(defun fact (x)
(if (<= i 1) 1 (* x (fact (1- x)))))
(defun main ()
(print (fact 1000))
0)
C/C++ Lisp
Correctness ? ?
Development Time ? ?
Maintainability ? ?
Run Time ? ?
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
On 26 jun, 07:52, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Vassil Nikolov <···············@pobox.com> writes:
> > On Tue, 24 Jun 2008 22:12:35 -0700 (PDT), Javier <·······@gmail.com> said:
> > | ...
> > | <http://shootout.alioth.debian.org/gp4/benchmark.php?test=all〈=all>
> > | ...
> > | SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
> > | times faster than Java (client), and is finally as fast as Ocaml.
>
> > On Wed, 25 Jun 2008 07:38:58 -0700 (PDT), Javier <·······@gmail.com> said:
>
> > | On 25 jun, 07:38, Vassil Nikolov <···············@pobox.com> wrote:
> > || ...
> > || "Are five nights warmer than one night, then?" Alice ventured to
> > || ask.
> > || "Five times as warm, of course."
> > || "But they should be five times as _cold_, by the same rule---"
> > || "Just so!" cried the Red Queen. "Five times as warm, _and_ five
> > || times as cold---just as I'm five times as rich as you are, _and_
> > || five times as clever!"
> > || (_Through the Looking-Glass_, Chapter IX)
>
> > | ...
> > | You say that you don't want to diminish the SBCL team, what do you
> > | mean with this quote then?
>
> > That it summarizes fairly well many---not all, but way too
> > many---discussions about "X is faster than Y". It is about such
> > discussions, not about SBCL.
>
> > I don't want to ask why an _implementation_---SBCL---is quoted to be
> > slower or faster than one or another _language_ (C++, C, etc.).
>
> To help people understand the futility of this exercise, compare:
>
> int fact(int x){
> return((i<=1)?1:(x*fact(x-1)));
> }
> int main(void){
> printf("%d\n",fact(1000));
> return(0);
> }
>
> vs.
>
> (defun fact (x)
> (if (<= i 1) 1 (* x (fact (1- x)))))
>
> (defun main ()
> (print (fact 1000))
> 0)
>
> C/C++ Lisp
> Correctness ? ?
> Development Time ? ?
> Maintainability ? ?
> Run Time ? ?
We are just asking for runtime speed. Other questions may be debated
apart.
We all know that Lisp code is usually corrent, maintainable, and has
short development times.
But please, let debate about the OTHER thing, one IMPORTANT thing,
even if it is not the most important on some applications.
There is a mith that run time execution of programs written in
language X is not important because most of the time the computer is
iddle and bla, bla, bla. But analize it carefully: this mith is true
for a web application running on actual computers, for most of the
sites. It might also be true for enterprise applications up to some
point. But look at your computer, can you imagine a mp3 player
borrowing 50% of your CPU time? Can you imagine having to wait 0.5s
for every time you press a button? Can you imagine you OS loosing data
when comunicating with other computers? These things are important.
People is buying a 3.0 Ghz computer with 2Gb of RAM, and they don't
want it to run as if it where a 500Mhz one.
Desktop is important. Servers speed is also important. SPEED is
important. Yes, it is just ONE variable for choosing a language, but a
definitive one.
And microbenchmarks are right when showing how a language
implementation manage the code you write. For example, math
calculations being fast is an important prerequisite for real time
applications. If a microbenmark shows up that the implementation can
be fast with short algorithms, it means that good programmers can do
big fast applications. We cannot say the same for implementations
being slow on short programs.
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <rem-2008jul11-006@yahoo.com>
> From: Javier <·······@gmail.com>
> > Correctness =C2=A0 =C2=A0 =C2=A0 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0 ?
> > Development Time =C2=A0? =C2=A0 =C2=A0 =C2=A0 =C2=A0 ?
> > Maintainability =C2=A0 ? =C2=A0 =C2=A0 =C2=A0 =C2=A0 ?
> > Run Time =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> We are just asking for runtime speed. Other questions may be
> debated apart.
I disagree strongly. If the program doesn't produce anything
whatsoever like the correct answer, as that C program to compute
the factorial of 1000, except it only keeps the low-order 31 or 63
bits of the result depending on which implementation you use, i.e.
it always returns 0 as the result, who the fuck cares how fast it
computes an exactly wrong answer? Getting the correct answer, maybe
not exactly correct but at least close enough to the theoretically
correct answer for practical purposes, is a mandatorary
qualification for getting considered at all. You flunk the
correct-answer qualification, and nobody cares to time you.
Would you want the Israeli defense computer to tell within 2
seconds, instead of the 5 seconds that a Lisp program would
require, that Iran has launched a missile and Israel has only 5
minutes to launch a retaliatory stike, when in fact the missile
launch was a test headed *away* from Israel out to sea South of
India?
In this hypothetical scenerio, the Lisp program would get the
correct answer but take 3 seconds too long. You can't wait. You
need the (wrong) answer three seconds earlier, only 2 seconds
instead of 5 seconds after launch. Time is of the essence. Damn
correctness. That's how you truly feel about correctness, right?
> We all know that Lisp code is usually corrent [sic],
> maintainable, and has short development times. But please, let
> debate about the OTHER thing, one IMPORTANT thing, even if it is
> not the most important on some applications.
Correctness is *always* the most important quality, first and
foremost, correct enough for the needs at hand, correct enough to
tell that factorial(1000) isn't zero, that it in fact has 2568
digits, starting with 40238726007709377354370243392300398571937...
and ending with ...16909004153690105933983835777939410970027753472
as the last digits before the final run of all zeroes.
If it told me only 4.0238726E+2567, that might be good enough for
some applications, not good enough for others.
Better is the enemy of good enough, but misusing that cliche is the
tool of somebody who just doesn't care about correctness. There's a
reasonable trade-off between cost and benefit, and 4.0238726E+2567
might be a reasonable trade-off point, but a totally wrong answer
like that C program for factorial(1000) just doesn't pass muster.
If you just want to return 0, Lisp has the fastest and shortest
program of all.
> Can you imagine having to wait 0.5s for every time you press a button?
That's a lot faster than my VCR.
Sometimes it takes about five seconds to start playing after I
press the PLAY button, which is only a nuisance, or to start
recording after I press the OTR button, which causes me to lose the
quick thing I wanted. (What I really need is a back-in-time OTR
button. I've heard that TIVO provides that. Is that correct?)
MS-Windows is even slower. Every time it hangs and we have to
re-boot, it takes several minutes. (My Macintosh hardly ever
crashes, like maybe two times a year. FreeBSD Unix needs to be
rebooted about once every two weeks to avoid it hanging.)
> Can you imagine you OS loosing [sic] data when comunicating with other
> computers?
You don't care about correctness, so who cares if a little data is lost??
You're contradicting yourself, like any old troll.
> SPEED is important. Yes, it is just ONE variable for choosing a
> language, but a definitive one.
It's important **only** after essential correctness. Next time you
are applying for a job, tell the hiring manager that you can't do
the job correctly at all, but you will very very quickly do it
wrong, and speed is more important than correctness. Tell the
hiring manager at StarBucks that you don't know how to make coffee
that doesn't taste like urine, but your make u-coffee very quickly,
oh and it's only lukewarm, about 99 degrees fahrenheit as it comes
out, and they should be happy to hire you to piss in their mugs.
> For example, math calculations being fast is an important
> prerequisite for real time applications.
Only if it's basically correct in the first place.
Remember those missiles that were launched by Iran towards
Israel^H^H^H^H^H^Hthe Indian Ocean yesterday?
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g595bk$j3e$1@aioe.org>
Robert Maas, http://tinyurl.com/uh3t wrote:
>> From: Javier <·······@gmail.com>
>> We are just asking for runtime speed. Other questions may be
>> debated apart.
>
> I disagree strongly. If the program doesn't produce anything
> whatsoever like the correct answer, as that C program to compute
> the factorial of 1000, except it only keeps the low-order 31 or 63
> bits of the result depending on which implementation you use, i.e.
> it always returns 0 as the result, who the fuck cares how fast it
> computes an exactly wrong answer? Getting the correct answer, maybe
> not exactly correct but at least close enough to the theoretically
> correct answer for practical purposes, is a mandatorary
> qualification for getting considered at all. You flunk the
> correct-answer qualification, and nobody cares to time you.
>
> Would you want the Israeli defense computer to tell within 2
> seconds, instead of the 5 seconds that a Lisp program would
> require, that Iran has launched a missile and Israel has only 5
> minutes to launch a retaliatory stike, when in fact the missile
> launch was a test headed *away* from Israel out to sea South of
> India?
>
> In this hypothetical scenerio, the Lisp program would get the
> correct answer but take 3 seconds too long...
May I point out some more irony here: not only was Pascal's code wrong (both
his C and his Lisp) but his Lisp was also prone to stack overflowing
because it is not tail recursive. Moreover, arbitrary-precision integer
arithmetic is almost entirely useless in practice (so it does not improve
the reliability of real software) and, in particular, is not suitable for
the application you cite.
Next time you guys want to make a really important point about a bigint
factorial I suggest avoiding recursion because Common Lisp does not support
it correctly.
In the meantime, you might consider the Mathematica solution:
1000!
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 12 Lug, 04:35, Jon Harrop <····@ffconsultancy.com> wrote:
> Robert Maas,http://tinyurl.com/uh3twrote:
> >> From: Javier <·······@gmail.com>
> >> We are just asking for runtime speed. Other questions may be
> >> debated apart.
>
> > I disagree strongly. If the program doesn't produce anything
> > whatsoever like the correct answer, as that C program to compute
> > the factorial of 1000, except it only keeps the low-order 31 or 63
> > bits of the result depending on which implementation you use, i.e.
> > it always returns 0 as the result, who the fuck cares how fast it
> > computes an exactly wrong answer? Getting the correct answer, maybe
> > not exactly correct but at least close enough to the theoretically
> > correct answer for practical purposes, is a mandatorary
> > qualification for getting considered at all. You flunk the
> > correct-answer qualification, and nobody cares to time you.
>
> > Would you want the Israeli defense computer to tell within 2
> > seconds, instead of the 5 seconds that a Lisp program would
> > require, that Iran has launched a missile and Israel has only 5
> > minutes to launch a retaliatory stike, when in fact the missile
> > launch was a test headed *away* from Israel out to sea South of
> > India?
>
> > In this hypothetical scenerio, the Lisp program would get the
> > correct answer but take 3 seconds too long...
>
> May I point out some more irony here: not only was Pascal's code wrong (both
> his C and his Lisp) but his Lisp was also prone to stack overflowing
> because it is not tail recursive. Moreover, arbitrary-precision integer
> arithmetic is almost entirely useless in practice (so it does not improve
> the reliability of real software) and, in particular, is not suitable for
> the application you cite.
There is at least one case in which an overflow error caused
catastrophic failure with huge financial loss: The first flight of the
Ariane 5 launcher.
The Ariane 5 reused much of the software form the Ariane 4, which was
smaller and operated on a different flight path. Under the new
operating conditions, a value overflowed and caused an untrapped
hardware exception (software exception handling was disabled for
efficiency), causing the inertial guidance computers to hang. Left
without guidance, the missile tilted, broke due to aereodynamical
forces and self-destructed.
<snip>
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5ae62$3e6$1@aioe.org>
Vend wrote:
> There is at least one case in which an overflow error caused
> catastrophic failure with huge financial loss: The first flight of the
> Ariane 5 launcher.
>
> The Ariane 5 reused much of the software form the Ariane 4, which was
> smaller and operated on a different flight path. Under the new
> operating conditions, a value overflowed and caused an untrapped
> hardware exception (software exception handling was disabled for
> efficiency), causing the inertial guidance computers to hang. Left
> without guidance, the missile tilted, broke due to aereodynamical
> forces and self-destructed.
The trap was disabled for performance reasons => arbitrary-precision integer
arithmetic would not even have been suitable there.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 12 Lug, 16:12, Jon Harrop <····@ffconsultancy.com> wrote:
> The trap was disabled for performance reasons => arbitrary-precision integer
> arithmetic would not even have been suitable there.
(You know, CL is still the language I'm secretly most attracted by,
but there seems to be no way I finally will get into even the basics
of this Holy Archaic Language, and so I'll throw at you all kind of
superficial ignorance arguments I can get my mind on, this way I'll
distract you from real world CL coding, which is in fact the only
thing I'm after, after all...)
Jon Harrop (Your All Superb Master Of Future Computer Science)
From: Duane Rettig
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <o0y747rtto.fsf@gemini.franz.com>
···················@gmail.com writes:
> On 12 Lug, 16:12, Jon Harrop <····@ffconsultancy.com> wrote:
>> The trap was disabled for performance reasons => arbitrary-precision integer
>> arithmetic would not even have been suitable there.
>
> (You know, CL is still the language I'm secretly most attracted by,
> but there seems to be no way I finally will get into even the basics
> of this Holy Archaic Language, and so I'll throw at you all kind of
> superficial ignorance arguments I can get my mind on, this way I'll
> distract you from real world CL coding, which is in fact the only
> thing I'm after, after all...)
I read you on this ng for entertainment only, as a break from the
grind of coding in my Holy Archaic Language. I almost never answer
your articles, because aside from their entertainment value, they are
fairly worthless. Sorry, as some in this ng are running interference
and keeping you busy, they and others of us are coding and actually
getting things done. Your Superb Master plan just isn't working.
> Jon Harrop (Your All Superb Master Of Future Computer Science)
Duane Rettig (servant of Current Computer Science)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On 12 Lug, 16:12, Jon Harrop <····@ffconsultancy.com> wrote:
> Vend wrote:
> > There is at least one case in which an overflow error caused
> > catastrophic failure with huge financial loss: The first flight of the
> > Ariane 5 launcher.
>
> > The Ariane 5 reused much of the software form the Ariane 4, which was
> > smaller and operated on a different flight path. Under the new
> > operating conditions, a value overflowed and caused an untrapped
> > hardware exception (software exception handling was disabled for
> > efficiency), causing the inertial guidance computers to hang. Left
> > without guidance, the missile tilted, broke due to aereodynamical
> > forces and self-destructed.
>
> The trap was disabled for performance reasons => arbitrary-precision integer
> arithmetic would not even have been suitable there.
From the Wikipedia article it seems that the trap was disabled more
because of programmers overobsessed with micro-optimization rather
than for real performance requirements.
Anyway, the program was written in Ada, which I've never seen but I
heard described as a kind of monster.
<snip>
Jon Harrop <···@ffconsultancy.com> wrote:
> Moreover, arbitrary-precision integer arithmetic is almost entirely
> useless in practice (so it does not improve the reliability of real
> software)
Oh. You must be writing very different software from me, then.
I find it rather hard to believe, in a world where integer overflows are
really being exploited as security holes, that modern high-level and
apparently `safe' languages don't provide unbounded integers as the
/default/ and /recommended/ integer type.
I don't have a problem with using bounded integer types as an
optimization for performance-critical parts of a program, but I think
the author should sit down and convince himself that overflow or
wraparound is either impossible or harmless.
> Next time you guys want to make a really important point about a
> bigint factorial I suggest avoiding recursion because Common Lisp does
> not support it correctly.
The usual toy factorial I write in Lisp is
(defun stupid-factorial (n)
(do ((i 1 (1+ n))
(a 1 (* a i)))
((> i n) a)))
which isn't recursive at all.
I don't know what you mean about avoiding recursion, though. The
standard tail-recursive factorial looks fine.
(defun tail-factorial (n)
(labels ((iter (a n)
(if (plusp n)
(iter (* a n) (1- n))
a)))
(iter 1 n)))
The non-tail-recursive factorial will blow the stack in more or less any
language implementation. (Yes, I did test it with OCaml, specifically
version 3.10.2.) Stupid techniques fail in most languages.
But even the iterative (DO) version is a terribly inefficient way of
implementing the function. Much better:
(defun factorial (n)
(do ((stack (list 1))
(i 1 (1+ i)))
((> i n) (reduce #'* stack))
(do ((hand i (* hand top))
(top (pop stack) (pop stack)))
((or (null stack) (> top hand))
(push top stack)
(push hand stack)))))
This doesn't make a big difference on SBCL (not quite a factor of two),
but try it on CLISP. It wins big with implementations which use
Karatsuba-Ofman or other fancy multipliers. Also, make sure you measure
the performance with TIME: converting the result to decimal is
nontrivial and can easily dominate the time needed to compute the
factorial, particularly if the base conversion is naive. Therefore
waiting with a stopwatch to see the answer print will give you a highly
misleading idea of how long it takes.
-- [mdw]
On Jul 15, 6:41 am, Mark Wooding <····@distorted.org.uk> wrote:
> The non-tail-recursive factorial will blow the stack in more or less any
> language implementation. (Yes, I did test it with OCaml, specifically
> version 3.10.2.) Stupid techniques fail in most languages.
Perhaps this is slightly OT, but I hope someone targets LLVM with a CL
implementationl. Check out http://llvm.org/demo/ , where the LLVM (a
general purpose compiler back end) optimizer converts naive recursive
factorial into a loop. I saw some abstract interpretation techniques
to do this years ago, but did not expect to see a general purpose back
end (mostly for imperative languages) actually implement it...
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g594h1$g47$1@aioe.org>
Javier wrote:
>> int fact(int x){
>> return((i<=1)?1:(x*fact(x-1)));
>> }
>> int main(void){
>> printf("%d\n",fact(1000));
>> return(0);
>> }
>>
>> vs.
>>
>> (defun fact (x)
>> (if (<= i 1) 1 (* x (fact (1- x)))))
>>
>> (defun main ()
>> (print (fact 1000))
>> 0)
>
> We are just asking for runtime speed. Other questions may be debated
> apart.
> We all know that Lisp code is usually corrent, maintainable, and has
> short development times.
Can I just point out the irony here: Not only is Pascal's code completely
wrong in every case but you even misspelled "correct" in your claim that
Lisp code is usually correct. ROTFLMAO.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g532kr$di3$2@aioe.org>
Pascal J. Bourguignon wrote:
> To help people understand the futility of this exercise, compare:
>
> int fact(int x){
> return((i<=1)?1:(x*fact(x-1)));
> }
> int main(void){
> printf("%d\n",fact(1000));
> return(0);
> }
I love the way Lispers litter their non-Lisp code with superfluous
parentheses. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <7cskuib0am.fsf@pbourguignon.anevia.com>
Jon Harrop <···@ffconsultancy.com> writes:
> Pascal J. Bourguignon wrote:
>> To help people understand the futility of this exercise, compare:
>>
>> int fact(int x){
>> return((i<=1)?1:(x*fact(x-1)));
>> }
>> int main(void){
>> printf("%d\n",fact(1000));
>> return(0);
>> }
>
> I love the way Lispers litter their non-Lisp code with superfluous
> parentheses. :-)
They are not superfluous: they allow the use of quick editing commands
to navigate and manipulate sub-syntax-trees.
If you write:
return (i<=1)?1:(x*fact(x-1));
^
and with the cursor at the position indicated by the caret, when you
type C-M-k, it cuts only (i<=1). You would have to count the syntactic
elements to cut the whole ?: expression, or work at the level of
characters, to find the next semicolon and cut a range of characters.
Instead, with:
return((i<=1)?1:(x*fact(x-1)));
^
when you type C-M-k, you get ((i<=1)?1:(x*fact(x-1)))
Etc, for all the structured editing commands.
--
__Pascal Bourguignon__
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g595l1$k3g$1@aioe.org>
Pascal J. Bourguignon wrote:
> To help people understand the futility of this exercise, compare:
Thank you for helping people to fully understand the futility of this
exercise, Pascal.
> int fact(int x){
> return((i<=1)?1:(x*fact(x-1)));
> }
> int main(void){
> printf("%d\n",fact(1000));
> return(0);
> }
>
> vs.
>
> (defun fact (x)
> (if (<= i 1) 1 (* x (fact (1- x)))))
>
> (defun main ()
> (print (fact 1000))
> 0)
Both of your programs are wrong and I can see now that Lisp really is as
unreliable as C, just as you imply.
You might also consider why the programs are still poorly written even after
the incorrect identifiers are fixed:
* (fact 100000)
Control stack guard page temporarily disabled: proceed with caution
debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread
#<THREAD "initial thread" {1002704B11}>:
Control stack exhausted (no more space for function call frames). This is
probably due to heavily nested or infinitely recursive function calls, or a
tail call that SBCL cannot or has not optimized away.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
0]
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87wsjryd41.fsf@geddis.org>
Jon Harrop <···@ffconsultancy.com> wrote on Sat, 12 Jul 2008:
> Pascal J. Bourguignon wrote:
>> int fact(int x){
>> return((i<=1)?1:(x*fact(x-1)));
>> }
>> int main(void){
>> printf("%d\n",fact(1000));
>> return(0);
>> }
>> vs.
>> (defun fact (x)
>> (if (<= i 1) 1 (* x (fact (1- x)))))
>> (defun main ()
>> (print (fact 1000))
>> 0)
>
> * (fact 100000)
> Control stack guard page temporarily disabled: proceed with caution
>
> debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread
> #<THREAD "initial thread" {1002704B11}>:
> Control stack exhausted (no more space for function call frames). This is
> probably due to heavily nested or infinitely recursive function calls, or a
> tail call that SBCL cannot or has not optimized away.
[...]
>
> (SB-KERNEL::CONTROL-STACK-EXHAUSTED-ERROR)
> 0]
Works just fine in CMUCL. No stack overflow, correct answer returned.
Oh wait: did you neglect to compile the FACT function?
I wish you luck getting even this much performance out of the C code, if
you similarly neglect to compile that fragment. Or equivalent non-compiled
code written in your precious Irish Dromedary language.
Otherwise: if you want to make a comment on Common Lisp, you ought to learn
to program in the language first.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Twas brillig, and the slithy toves
Did gyre and gimble in the wabe
All mimsy were the borogoves
And the mome raths outgrabe
-- _Jabberwocky_, by Lewis Carroll (Charles Dodgson)
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g5abdr$pfs$1@aioe.org>
Don Geddis wrote:
> I wish you luck getting even this much performance out of the C code, if
> you similarly neglect to compile that fragment.
The Lisp is wrong. Its performance is irrelevant.
> Otherwise: if you want to make a comment on Common Lisp, you ought to
> learn to program in the language first.
Again, I did not write this Lisp code: it was posted be a seasoned Lisper
who was trying to explain how Lisp is great for correctness but,
unfortunately, his Lisp code was incorrect and his design was fragile in a
way that cannot be addressed in Common Lisp because the language lacks the
necessary features (tail calls).
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On 12 Lug, 15:24, Jon Harrop <····@ffconsultancy.com> wrote:
> ...
Did you understand? OK, I'll repeat it once and for all:
My personal 10 Commandments are:
(1) Lisp must die.
(2) Lisp must die.
(3) Lisp must die.
(4) Lisp must die.
(5) Lisp must die.
(6) Lisp must die.
(7) Lisp must die.
(8) Lisp must die.
(9) Lisp must die.
(10) Lisp must die.
I hope it's clear now.
Jon Harrop
From: Duane Rettig
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <o03amft8th.fsf@gemini.franz.com>
···················@gmail.com writes:
> On 12 Lug, 15:24, Jon Harrop <····@ffconsultancy.com> wrote:
>> ...
>
> Did you understand? OK, I'll repeat it once and for all:
>
> My personal 10 Commandments are:
>
> (1) Lisp must die.
> (2) Lisp must die.
> (3) Lisp must die.
> (4) Lisp must die.
> (5) Lisp must die.
> (6) Lisp must die.
> (7) Lisp must die.
> (8) Lisp must die.
> (9) Lisp must die.
> (10) Lisp must die.
>
> I hope it's clear now.
It's been clear from the begiinning. But I feel sorry for you; if you
keep this set of commandments to live by, you're going to be one
frustrated individual.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Javier wrote:
> Have you seen the shootout recently?:
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>
> SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
> times faster than Java (client), and is finally as fast as Ocaml.
>
> I'm pretty sure that if the SBCL team continue to work, it will become
> one of the fastest language implementation, very close to C++ itself.
> Thank you for your work!
Maybe a newer SBCL would be faster. They seem to be using SBCL 1.0.12
which is from November 2007.
--
Lars Rune N�stdal
http://nostdal.org/
On Jun 25, 1:12 am, Javier <·······@gmail.com> wrote:
>
> SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
> times faster than Java (client), and is finally as fast as Ocaml.
For purposes of propaganda, i.e. advocating Common Lisp, this is
great.
I'm all for propaganda of this kind. I guess "marketing collateral"
would be a more euphemistic way of putting it.
As for whether it really means anything: microbenchmarking is hard,
and interpreting the results is hard. See Richard Gabriel's book
on measuring Lisp for a great discussion of why it's so hard.
See Didier Verna's excellent paper, in which he compares
Common Lisp and C++ for some simple image-processing apps to
see how masterfully he deals with the hard issues. It's called
"Beating C in Scientific Computing Applications: On the Behavior
and Performance of Lisp, Part 1". One of the many smart things
he does is to try several Common Lisp implementations. SBCL
and Allegro both come out well.
Notice that the "shootout" numbers are taking the mean of
many benchmarks, because everybody wants a single number
that measures speed, as if every microbenchmark will have
exactly the same ratio for each language. Of course that's
not true, and it depends a lot on which things you benchmark.
And if you're going to take a mean, you have to choose your
weighting. To their credit, they provide a way to do that,
but how do you know what to put in those boxes? The
"what fun!" comment on that web page shows that they
understand this perfectly.
See the full comparison between SBCL and the fastest
Java that they show:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=sbcl&lang2=javaxx
That's more informative. The mean is being influenced
by a few benchmarks on which SBCL did a lot better,
whereas it did somewhat worse on many of the benchmarks.
What you really want is a way to predict, in advance, how
much faster or slower your app will be, so that you can
take that into account when you choose a language. The
ability of this kind of microbenchmark to help you make
that prediction is limited at best.
By the way, I often say that you get the most speed from
Lisp, compared to other languages, because you can make
your program work correctly in less time, thus leaving
more time between then and the project deadline to work
on performance improvement. And big performance wins
come from high-level approaches, which also take time
to develop, so developer productivity translates directly
into runtime performance, if you decide to care about
runtime performance.
Warm congratulations to the SBCL maintainers
(hi, Nikodemus!). They deserve lots of credit. These
results are extremely impressive!
-- Dan
On 26 jun, 13:40, ··········@gmail.com wrote:
> On Jun 25, 1:12 am, Javier <·······@gmail.com> wrote:
>
>
>
> > SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
> > times faster than Java (client), and is finally as fast as Ocaml.
>
> For purposes of propaganda, i.e. advocating Common Lisp, this is
> great.
> I'm all for propaganda of this kind. I guess "marketing collateral"
> would be a more euphemistic way of putting it.
>
> As for whether it really means anything: microbenchmarking is hard,
> and interpreting the results is hard. See Richard Gabriel's book
> on measuring Lisp for a great discussion of why it's so hard.
> [...]
I think microbenchmarking is at least as important as full-
benchmarking. It shows up where is actually the limit on speed that
you can achieve.
I obviusly agree that it is not the same comparing small algorithms
using different language implementations, as doing the same with full
applications. It is obvious, too, that getting good performance using C
++ is harder.
But there are times (and desktop applications do almost always require
this), in which performance is so much important, that people still
prefer to use the fastest language implementation, even if it is very
hard to code on.
Knowing that SBCL is getting close to C++, and that it is now very
close to be optimal, can encourage lot of programmers to choose Lisp.
I hope SBCL gets better and better. Lot of myths and misconceptions
may fall out.
I hope that you agree with me that if a Lisp implementation is good at
microbenchmarking, it also means, in some way, that it will be good
when using it for full applications. The faster it is at concrete
things, the faster it should be in general. Any point at which it is
not fast, is a bottle-neck that prevents the full application to be
fast. That's logical.
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <874p7gz0f2.fsf@geddis.org>
Javier <·······@gmail.com> wrote on Thu, 26 Jun 2008:
> I hope that you agree with me that if a Lisp implementation is good at
> microbenchmarking, it also means, in some way, that it will be good when
> using it for full applications.
This assumption of yours is exactly the cause of the disagreement on this
thread.
Programmers with more experience than you are trying to tell you that the
inference doesn't hold. You can only make very poor predictions about full
application speed, based only on microbenchmarking results.
Your assumption that microbenchmarking is a good proxy for real application
benchmarking, is false.
> The faster it is at concrete things, the faster it should be in general.
> Any point at which it is not fast, is a bottle-neck that prevents the full
> application to be fast. That's logical.
Science trumps logic, I'm afraid. It doesn't matter how airtight you think
your argument is. The actual experience of real programmers writing real
applications is that microbenchmarking is not a very useful guide to the
eventual speed of the final full application.
We can debate the reasons for why that might so, but the fact that it is so
should not be in doubt.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I'm not saying you lack the brains God gave a potato. I'm just saying that
in a similar situation a potato -- or any tuber, for that matter -- would
almost certainly have thought before proceeding. -- "Sally Forth", 2/8/2007
On 26 jun, 17:22, Don Geddis <····@geddis.org> wrote:
> Javier <·······@gmail.com> wrote on Thu, 26 Jun 2008:
>
> > I hope that you agree with me that if a Lisp implementation is good at
> > microbenchmarking, it also means, in some way, that it will be good when
> > using it for full applications.
>
> This assumption of yours is exactly the cause of the disagreement on this
> thread.
>
> Programmers with more experience than you are trying to tell you that the
> inference doesn't hold. You can only make very poor predictions about full
> application speed, based only on microbenchmarking results.
I don't think it might be so much poor as you state.
And you don't know what my experience is.
> Your assumption that microbenchmarking is a good proxy for real application
> benchmarking, is false.
No, it is not false. Your opinion is that it is false. You cannot
demonstrate it, as I cannot my own. We just can believe our respective
and contradictory positions.
> > The faster it is at concrete things, the faster it should be in general.
> > Any point at which it is not fast, is a bottle-neck that prevents the full
> > application to be fast. That's logical.
>
> Science trumps logic, I'm afraid.
Logic is the language to explain science. Science is the understanding
of the logic of the nature. Science doesn't trumps anything.
> It doesn't matter how airtight you think
> your argument is. The actual experience of real programmers writing real
> applications is that microbenchmarking is not a very useful guide to the
> eventual speed of the final full application.
It may depend upon the kind of application, and how it is done, don't
you think so? Experience of real programmers writing real applications
know that performance problems are usually concentrated in concrete
points, called bottle-necks. You can resolve them up to the human
limit. From there on, the speed depends on the implementation of your
choice. If your implementation doesn't generate optimum machine code
for the best algorithm you can choose, and it is not enough for you,
there is nothing more to do, except changing the implementation.
Compare, for example, an application written in CL, compiled both in
Clisp and SBCL. It is the same application, but in SBCL it is clearly
faster than in the other one. Previusly, we made some
microbenchmarking on both implementations, with the same result: SBCL
is clearly the winner.
We can, then, establish the relation. If for almost every program,
either being a big or small one, and for almost every
microbenchmarking, SBCL is faster, we can say that, on the average,
SBCL is clearly faster. Microbenchmarking is really a helpful thing,
it cannot measure every application and circunstance, but we can
figure out how relatively fast is a specific implementation before
being chosen.
> We can debate the reasons for why that might so, but the fact that it is so
> should not be in doubt.
Allow me to doubt it. Demonstrate it.
And... talking about experience. Have you got the experience of
applications written in C that are slower than similar applicatons
written in Lisp? I mean correctly ones for both, not correctly ones
written in Lisp, and badly ones written in C.
Perhaps you can surprise me... I doubt it.
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87od5ovxgi.fsf@geddis.org>
Javier <·······@gmail.com> wrote on Thu, 26 Jun 2008:
>> > The faster it is at concrete things, the faster it should be in general.
>> > Any point at which it is not fast, is a bottle-neck that prevents the full
>> > application to be fast. That's logical.
>>
>> Science trumps logic, I'm afraid.
>
> Logic is the language to explain science. Science is the understanding
> of the logic of the nature. Science doesn't trumps anything.
The point is that you can have an abstract argument that something "ought to
be so", and it might be that we can't see what the flaw in the argument is.
That is "logic".
But the real test comes from the real world. Actually do the experiment, and
observe the results. Sometimes the real world surprises you, and produces a
result that you _thought_ you had an airtight logical argument to rule out.
That appears to be the case in this example. You think that "the faster [an
implementation] is at [microexamples], the faster it should be in general."
Yet actual experience with real programmers shows that there is little
correlation here: big programming teams working on big programs don't
actually come up with faster full applications by being forced to use
languages/implementations that happen to get the best scores in a few micro
examples.
>> It doesn't matter how airtight you think your argument is. �The actual
>> experience of real programmers writing real applications is that
>> microbenchmarking is not a very useful guide to the eventual speed of the
>> final full application.
>
> It may depend upon the kind of application, and how it is done, don't
> you think so?
Of course. Yet another reason why it's premature to make any grand sweeping
conclusions based only on a few small microexamples.
> Experience of real programmers writing real applications know that
> performance problems are usually concentrated in concrete points, called
> bottle-necks.
Agreed.
> You can resolve them up to the human limit. From there on, the speed
> depends on the implementation of your choice.
Most industrial-class implementations allow FFI or embedded assembly, if
some tiny fraction of your application really was limited by the compiler.
> If your implementation doesn't generate optimum machine code for the best
> algorithm you can choose, and it is not enough for you, there is nothing
> more to do, except changing the implementation.
Agreed, but what you're missing is that this does NOT imply that a real
programming team on a real problem will actually wind up with faster code,
if they use a language/implementation that "won" the microbenchmark.
Let me just pose one (of many) hypotheticals: Most real-world programming
tasks are resource-limited, say by money or time. What if the microbenchmark
winner made it more difficult for programmers to express algorithms? You
might find that the higher-level language/implementation allows more
experimentation with algorithms, so -- in REAL WORLD applications -- the
two teams actually wind up with DIFFERENT algorithms. And I'm sure you know
that the choice of algorithm and/or data structure swamps all the micro things
you've been trying to measure with these benchmarks.
Where in your comparison do you account for the ability of programmers to
_find_ the best algorithm, in a given unit of programming time?
Or, let me try another way: everything you've said applies equally well to
any high-level language vs. assembly code. Why aren't you arguing that every
program should be written in assembly language? SURELY assembly language (in
principle) wins EVERY microbenchmark.
If you start to explore your (limited?) understanding of why C is "better"
than assembly language -- despite doing WORSE on the microbenchmarks -- then
you'll start to also understand why Lisp is better than C (regardless of
microbenchmark performance).
> Compare, for example, an application written in CL, compiled both in Clisp
> and SBCL. It is the same application, but in SBCL it is clearly faster than
> in the other one. Previusly, we made some microbenchmarking on both
> implementations, with the same result: SBCL is clearly the winner.
This is a pretty easy case, since they're the same language, just different
implementations. And one compiles to native code, while the other uses a
byte-code interpreter.
Even so, you're still wrong to quantify over every application. It turns out
that there are significant examples you can come up with where Clisp is
faster. Perhaps (for example) as a unix shell-like scripting language, where
the source file is pure text (like most Perl or shell scripts). In that
case, the time cost of compilation gets charged to the overall running time
of the application, and it is no longer clear that SBCL is the obvious winner
over Clisp.
> We can, then, establish the relation. If for almost every program, either
> being a big or small one, and for almost every microbenchmarking, SBCL is
> faster, we can say that, on the average, SBCL is clearly faster.
Or, you could understand better what is going on, and make a more informed
choice.
>> We can debate the reasons for why that might so, but the fact that it is so
>> should not be in doubt.
>
> Allow me to doubt it. Demonstrate it.
Let's be Socratic here. I can help you find the answer yourself.
Why is C preferred to assembly, even though assembly can beat C on
microbenchmarks?
(C is actually intermediate between assembly and most other high level
languages, so this would be even clearer if you'd pick a different one.
I don't know what your favorite HLL is. C++? C#? F#? Haskell? Python?
Perl? Compare any of those to pure assembly.)
> Have you got the experience of applications written in C that are slower
> than similar applicatons written in Lisp? I mean correctly ones for both,
> not correctly ones written in Lisp, and badly ones written in C.
Ah, but you see how you had to wriggle out of it, with all the exceptions?
The REAL question of interest in the REAL world is something more like:
You've got a 5-person team, and 3-months, to implement software from scratch
that does X. If that team chose to use Java or Lisp or C (assuming equal
experience in any), which would lead to a superior final product (including
features, speed, etc.)?
That's a very, very hard question to answer. Microbenchmarks tell you almost
nothing about the answer.
Consider this: it is surely harder to make "correct" programs in C, than in
Lisp. The additional effort required to make the C program correct isn't
free. You can't sweep under the rug the fact that the Lisp program gets to a
correct state much faster. So, for a fixed total amount of programming time,
there is more time left in the Lisp camp to do profiling and performance
improvement.
Again, otherwise I ask you: "Have you got the experience of applications
written in assembly that are slower than similar applications written in C?
I mean correctly ones for both, not correctly ones written in C, and badly
written in assembly."
If you ignore the cost of developing correct programs, you can get all sorts
of bizarre conclusions. But those conclusions don't apply to the real world.
(Note this is all BESIDE the point of how well you can optimize a
microbenchmark, which is a small but somewhat useful piece of data for a
language and/or implementation. Your mistake is not in exploring that topic,
but in thinking it's the only one that matters for a language comparison.
It's a minor issue, of small but non-zero importance. And, by the way, Lisp
isn't too bad at that micro topic as well.)
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
When I told the people of Northern Ireland that I was an atheist, a woman in
the audience stood up and said, "Yes, but is it the God of the Catholics or the
God of the Protestants in whom you don't believe?" -- Quentin Crisp
On 26 jun, 20:54, Don Geddis <····@geddis.org> wrote:
> Your mistake is not in exploring that topic,
> but in thinking it's the only one that matters for a language comparison.
Not at all. Read other messages I wrote in this thread.
We were just discussing speed.
I've read all your message, but I think you don't finally got my
point. Just a small example: can you imagine an application like
Cubase or Logic written in Lisp? This is a tipical application which
can be measured pretty well using microbenmarking, because it is using
lot of math, with simple and repetitive algorithms. Speed is so much
important, that implementors are even going to sacrifice
maintainability in order to compete. In such circuntances, it doesn't
mind if the development time increases by one month. If Lisp is 2x
slower in these small algorithms, it means that the program would be
able to manage less tracks, fewer effects, and being less interactive.
There are lots of applications like this. Look at your OS: most parts
of the kernel, web navigators, music players, photo managers, video
editing tools, framework libraries, even games... in fact, most of the
applications we usually use require speed at the low level.
Using CFFI has a cost. If you are going to use it for rewriting the
kernel of your application, what is the utility of Lisp? Just to be a
glue? I resign of such.
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87k5gbd53u.fsf@yoda.geddis.org>
Javier <·······@gmail.com> wrote on Thu, 26 Jun 2008:
> I've read all your message, but I think you don't finally got my
> point. Just a small example: can you imagine an application like Cubase or
> Logic written in Lisp?
Music production? Recording, producing, and mixing sounds?
Uh, yeah. Sure. There's no reason why Lisp couldn't be a fine language for
implementing such an application.
Now, at some point you get down to device drivers for hardware. On the old
Lisp Machines, you could write drivers in Lisp too. With modern hardware and
modern OSes, this is a little more of a challenge, since Windows and Unix
aren't especially friendly to Lisp. I'd recommend that you write hardware
drivers in whatever language is closest to what the OS wants, which probably
means C.
But aside from that? For the basic application itself? Sure!
Let's see ... Cubase 1.0 was released in 1989 for an Atari. Uh, yeah.
Moore's Law is our friend here. I'm sure an Intel Quad core running SBCL
could keep up with a 1989 Atari.
> This is a tipical application which can be measured pretty well using
> microbenmarking, because it is using lot of math, with simple and
> repetitive algorithms.
And a bunch of GUI, don't forget. GUI is often the largest and most complex
part of applications like these.
As for "lots of math", the numeric performance of (some implementations of)
Lisp has been favorably compared to Fortran (the gold standard of numeric
performance):
http://portal.acm.org/citation.cfm?id=200989
SBCL, in particular, is a fork of CMUCL, which itself is a public-domain
successor to CMU Common Lisp, a research project that was created specifically
to demonstrate Fortran-level numeric performance in Lisp.
> Speed is so much important, that implementors are even going to sacrifice
> maintainability in order to compete. In such circuntances, it doesn't mind
> if the development time increases by one month.
You never answered my question in the previous post: why aren't they
programming in assembly language?
> If Lisp is 2x slower in these small algorithms, it means that the program
> would be able to manage less tracks, fewer effects, and being less
> interactive.
Again, you confuse microbenchmarks with overall application performance.
The way you optimize programs, is you find the very tight loops where they are
spending 99% of their CPU time. This is only a tiny fraction of the code, and
vastly easier to optimize than the whole program.
> There are lots of applications like this. Look at your OS: most parts of
> the kernel, web navigators, music players, photo managers, video editing
> tools, framework libraries, even games... in fact, most of the applications
> we usually use require speed at the low level.
You persist in the delusion that using Lisp would force a slower application.
> Using CFFI has a cost. If you are going to use it for rewriting the kernel
> of your application, what is the utility of Lisp? Just to be a glue? I
> resign of such.
Ever hear of the 80/20 rule? The point is that the vast majority of your
programming effort can take advantage of the superior programming language,
EVEN IF the tight loops need to be rewritten in assembly language (or C).
And, of course, you haven't at all established that something other than Lisp
is required for the inner loops (vs. optimizing within the Lisp language,
using an optimizing compiler like SBCL).
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Dear Mrs, Mr, Miss, or Mr and Mrs Daneeka: Words cannot express the deep
personal grief I experienced when your husband, son, father or brother was
killed, wounded, or reported missing in action. -- Joseph Heller, _Catch-22_
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87od5nfiho.fsf@hubble.informatimago.com>
Don Geddis <···@geddis.org> writes:
> Javier <·······@gmail.com> wrote on Thu, 26 Jun 2008:
>> I've read all your message, but I think you don't finally got my
>> point. Just a small example: can you imagine an application like Cubase or
>> Logic written in Lisp?
>
> Music production? Recording, producing, and mixing sounds?
>
> Uh, yeah. Sure. There's no reason why Lisp couldn't be a fine language for
> implementing such an application.
>
> Now, at some point you get down to device drivers for hardware. On the old
> Lisp Machines, you could write drivers in Lisp too. With modern hardware and
> modern OSes, this is a little more of a challenge, since Windows and Unix
> aren't especially friendly to Lisp. I'd recommend that you write hardware
> drivers in whatever language is closest to what the OS wants, which probably
> means C.
Just bypass these OSes. Use Movitz, implement your sound driver in
lisp and have fun!
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
On 26 Jun, 23:28, Javier <·······@gmail.com> wrote:
> On 26 jun, 20:54, Don Geddis <····@geddis.org> wrote:
>
> > Your mistake is not in exploring that topic,
> > but in thinking it's the only one that matters for a language comparison.
>
> Not at all. Read other messages I wrote in this thread.
> We were just discussing speed.
>
> I've read all your message, but I think you don't finally got my
> point. Just a small example: can you imagine an application like
> Cubase or Logic written in Lisp? This is a tipical application which
> can be measured pretty well using microbenmarking, because it is using
> lot of math, with simple and repetitive algorithms. Speed is so much
> important, that implementors are even going to sacrifice
One of the nice things about using lisp in such a project, is the
efficiency gain you could have when allowing people to write their own
filters. You can use read, macros, and compile to move from a nice
little DSL to efficiently compiled code for their filters. This is
relatively easy to write, and can be massively faster than a tightly
optimized naive interpreter written in C.
As an example look at Edi Weltz's copy of perl reg-expressions. The
first draft was written in a weekend and out performed the optimized c
code in the perl5 interpreter.
Due to efficiency concerns, the user control is typically limited to
describing to setting parameters outside of inner loops, and gluing
filters together. If you don't have to worry about this, you can allow
user control where ever is useful
On Jun 26, 11:28 pm, Javier <·······@gmail.com> wrote:
> I've read all your message, but I think you don't finally got my
> point. Just a small example: can you imagine an application like
> Cubase or Logic written in Lisp? This is a tipical application which
> can be measured pretty well using microbenmarking, because it is using
> lot of math, with simple and repetitive algorithms. Speed is so much
> important, that implementors are even going to sacrifice
> maintainability in order to compete.
You're making a large and naieve assumption here on exactly how "high-
speed" these applications are.
Someone already mentioned that Cubase runs on old Atari machines - I
have Cubase and a few other commercial music applications, designed to
be powerful yet capable of running smoothly on my Falcon (16mhz CPU
with a dodgy 50mhz upgrade board I don't use) and even ST (8mhz, 4
megs RAM!).
You think you're being fair and open-minded but you're not. I think
programs like this can be implemented efficiently in Lisp without
being twice as slow as some mystical optimal C implementation.
> In such circuntances, it doesn't
> mind if the development time increases by one month. If Lisp is 2x
> slower in these small algorithms, it means that the program would be
> able to manage less tracks, fewer effects, and being less interactive.
And you're kidding yourself if you think implementing an application
of that size in C instead of Lisp would cost you one month extra.
The cost might be 3-6 months, a year, or even the failure of the
project (it happens, a lot, apparently).
> There are lots of applications like this. Look at your OS: most parts
> of the kernel, web navigators, music players, photo managers, video
> editing tools, framework libraries, even games... in fact, most of the
> applications we usually use require speed at the low level.
Again, you're presuming that all of these applications (come on, a web
browser?) use 100% of the CPU time to do their jobs in their optimal C/
assembly/? implementation, and presuming that the best Lisp
implementation is dog-slow. Based on some microbenchmarks.
If Lisp is so expressive, and I think it is, why not try to implement
one of these - the easiest one; perhaps the music player or a game.
Then see if it's really so slow - I doubt it.
> Using CFFI has a cost. If you are going to use it for rewriting the
> kernel of your application, what is the utility of Lisp? Just to be a
> glue? I resign of such.
The point is that if you really need it, you can just use FFI to
implement those bottlenecks you previously mentioned, in C or assembly
or Eiffel or whatever you like.
I get the feeling you're also misjudging the size of those bottlenecks
compared to the size of the whole application. Typically, such a
program will have a few really tight loops; maybe an audio/video codec
or, say, a SNES sound chip emulator core. Maybe <5% of the whole.
You're talking about it as if these bottlenecks make up 90% of the
source.
Oisín
On 27 jun, 12:57, Oisín Mac Fhearaí <···········@gmail.com> wrote:
> If Lisp is so expressive, and I think it is, why not try to implement
> one of these - the easiest one; perhaps the music player or a game.
> Then see if it's really so slow - I doubt it.
Ok, lets start with a MP3 reader codec, and some CFFI for connecting
to the OS sound driver.
I'm not very fluent in Lisp, yet I am in C.
Any suggestion?
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87abh67qyl.fsf@geddis.org>
Javier <·······@gmail.com> wrote on Fri, 27 Jun 2008:
> On 27 jun, 12:57, Ois�n Mac Fheara� <···········@gmail.com> wrote:
>> If Lisp is so expressive, and I think it is, why not try to implement
>> one of these - the easiest one; perhaps the music player or a game.
>> Then see if it's really so slow - I doubt it.
>
> Ok, lets start with a MP3 reader codec, and some CFFI for connecting
> to the OS sound driver.
It's ok to start with something that you're comfortable with.
But what's odd, is that you seem to be deliberately choosing poor examples.
This one -- and your microbenchmarks -- are examples where the optimal
algorithm has already been worked out and is well-known, and the ONLY question
is how close the language can come to implementing the already-known optimal
assembly language.
That's just not a common scenario for real-world, valuable software. For
most significant software, a major part of the programming problem is in
figuring out what the optimal algorithms and data structures are going to be.
This isn't to say that Lisp can help you with the task you've suggested.
But you're going to miss a lot of the power and benefit of Lisp if this is
the kind of example you think is "typical".
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <7cvdzu5001.fsf@pbourguignon.anevia.com>
Javier <·······@gmail.com> writes:
> On 27 jun, 12:57, Ois�n Mac Fheara� <···········@gmail.com> wrote:
>
>> If Lisp is so expressive, and I think it is, why not try to implement
>> one of these - the easiest one; perhaps the music player or a game.
>> Then see if it's really so slow - I doubt it.
>
> Ok, lets start with a MP3 reader codec, and some CFFI for connecting
> to the OS sound driver.
You don't need any CFFI.
(defun theta (frequency sampling-rate)
(/ (* 2 pi frequency) sampling-rate))
(with-open-file (dsp "/dev/dsp" :direction :output
:if-exists :append
:element-type '(unsigned-byte 16))
(loop
:for i :from 0 :to 44100
:do (write-byte (truncate (1+ (sin (* i (theta 440 44100)))) 1/32768) dsp)))
should be all you need.
> I'm not very fluent in Lisp, yet I am in C.
> Any suggestion?
--
__Pascal Bourguignon__
On 27 jun, 18:13, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Javier <·······@gmail.com> writes:
> > On 27 jun, 12:57, Oisín Mac Fhearaí <···········@gmail.com> wrote:
>
> >> If Lisp is so expressive, and I think it is, why not try to implement
> >> one of these - the easiest one; perhaps the music player or a game.
> >> Then see if it's really so slow - I doubt it.
>
> > Ok, lets start with a MP3 reader codec, and some CFFI for connecting
> > to the OS sound driver.
>
> You don't need any CFFI.
>
> (defun theta (frequency sampling-rate)
> (/ (* 2 pi frequency) sampling-rate))
>
> (with-open-file (dsp "/dev/dsp" :direction :output
> :if-exists :append
> :element-type '(unsigned-byte 16))
> (loop
> :for i :from 0 :to 44100
> :do (write-byte (truncate (1+ (sin (* i (theta 440 44100)))) 1/32768) dsp)))
>
> should be all you need.
Yes, but it doesn't work with OSX, and doesn't use ALSA on Linux (just
OSS emulation).
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87iqvucj5f.fsf@geddis.org>
Javier <·······@gmail.com> wrote on Fri, 27 Jun 2008:
> On 27 jun, 18:13, ····@informatimago.com (Pascal J. Bourguignon) wrote:
>> Javier <·······@gmail.com> writes:
>> > Ok, lets start with a MP3 reader codec, and some CFFI for connecting
>> > to the OS sound driver.
>>
>> You don't need any CFFI.
[...]
>> (with-open-file (dsp "/dev/dsp" :direction :output
[...]
>
> Yes, but it doesn't work with OSX, and doesn't use ALSA on Linux (just
> OSS emulation).
Ah, so now you've changed your requirements. Now it seems that your REAL
requirement is that you have an existing OS with some existing drivers, and
you want to interface to those drivers as painlessly as possible.
Naturally, when you express your goal that way, the answer is: use whatever
language the OS happens to be written in. If you're using an OS written
in Fortran, then write your code in Fortran too.
It no longer matters how good the language is in the abstract. For your
task, all that matters is the impedance between the OS and your language.
Naturally, you should choose whatever random thing the OS implementors chose,
and don't worry about whether it is good or not.
But: if this is your goal, why did you waste our time on microbenchmarks,
as though the outcome of those tests mattered to you? In reality, you had
already selected the answer, based on the form of the question you decided
was important to you.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If the bark is the skin of the tree, then what are the acorns? You don't want
to know. -- Deep Thoughts, by Jack Handey [1999]
On 28 jun, 05:50, Don Geddis <····@geddis.org> wrote:
> Javier <·······@gmail.com> wrote on Fri, 27 Jun 2008:
>
> > On 27 jun, 18:13, ····@informatimago.com (Pascal J. Bourguignon) wrote:
> >> Javier <·······@gmail.com> writes:
> >> > Ok, lets start with a MP3 reader codec, and some CFFI for connecting
> >> > to the OS sound driver.
>
> >> You don't need any CFFI.
> [...]
> >> (with-open-file (dsp "/dev/dsp" :direction :output
> [...]
>
> > Yes, but it doesn't work with OSX, and doesn't use ALSA on Linux (just
> > OSS emulation).
>
> Ah, so now you've changed your requirements. Now it seems that your REAL
> requirement is that you have an existing OS with some existing drivers, and
> you want to interface to those drivers as painlessly as possible.
You are becoming a little paranoiac now.
Yes, off course I want to interface to those drivers as painlessly as
possible. I'm not going to write my own OS!!
> Naturally, when you express your goal that way, the answer is: use whatever
> language the OS happens to be written in.
This is actually why C is so successful, but I want to give Lisp a
try. But if you, a prominent Lisp user, is trying to convince me not
do so, should I think it twice?
> If you're using an OS written
> in Fortran, then write your code in Fortran too.
There is no OS written in Fortran. Most OS's are written in C.
> It no longer matters how good the language is in the abstract. For your
> task, all that matters is the impedance between the OS and your language.
More paranoia.
"All" is not correct. It matters, but there are other things that also
matters.
> Naturally, you should choose whatever random thing the OS implementors chose,
> and don't worry about whether it is good or not.
>
> But: if this is your goal, why did you waste our time on microbenchmarks,
> as though the outcome of those tests mattered to you? In reality, you had
> already selected the answer, based on the form of the question you decided
> was important to you.
Your logic is crazy.
I was really wanting to make an audio multi-OS library allowing SBCL
to interact with audio drivers and audio file formats, just to deserve
to my future projects.
OSS is very limiting. There are lot of things an audio driver does,
not only play sound.
I found CL-ALSA, CL-MADHL, and CM. Perhaps it is a good start. The
first two one use CFFI, of course. I don't like it, but I can live
with it if there is no other choice.
On Jun 28, 7:18 am, Javier <·······@gmail.com> wrote:
> [...]
> I found CL-ALSA, CL-MADHL, and CM. Perhaps it is a good start. The
> first two one use CFFI, of course. I don't like it, but I can live
> with it if there is no other choice.
If interfacing with C libraries is crucial for you, go with ECL! You
can inline embed C code, no CFFI needed! It's maintained, and the CVS
version is getting faster and faster.
I'm a very happy ECL user.
-PM
On 28 jun, 09:48, ········@gmail.com wrote:
> On Jun 28, 7:18 am, Javier <·······@gmail.com> wrote:
>
> > [...]
> > I found CL-ALSA, CL-MADHL, and CM. Perhaps it is a good start. The
> > first two one use CFFI, of course. I don't like it, but I can live
> > with it if there is no other choice.
>
> If interfacing with C libraries is crucial for you, go with ECL! You
> can inline embed C code, no CFFI needed! It's maintained, and the CVS
> version is getting faster and faster.
> I'm a very happy ECL user.
ECL has improved considerably since the last time I saw it.
Nice. Do you know if it support multi-threading on OSX?
On Jun 29, 1:30 pm, Javier <·······@gmail.com> wrote:
> ECL has improved considerably since the last time I saw it.
> Nice. Do you know if it support multi-threading on OSX?
Simply put, yes :-) The performance of multi-threaded lisp can be
severely improved, though, but right now it is acceptable. BTW, OS X
is my main development platform, so it is the best supported one.
Juanjo
On 29 jun, 14:46, Juanjo <·····················@googlemail.com> wrote:
> On Jun 29, 1:30 pm, Javier <·······@gmail.com> wrote:
>
> > ECL has improved considerably since the last time I saw it.
> > Nice. Do you know if it support multi-threading on OSX?
>
> Simply put, yes :-) The performance of multi-threaded lisp can be
> severely improved, though, but right now it is acceptable. BTW, OS X
> is my main development platform, so it is the best supported one.
>
> Juanjo
Nice. I've been watching ECL this morning, and reading the
documentation.
I have compiled it under OSX with default options (./configure &&
make).
Under Chapter 4, there are some functions described. It seems that
they are under MP package, but I fail to load it up:
CL-USER> (require :mp)
Module error: Don't know how to REQUIRE MP.
CL-USER> (mp:process-name)
There is no package with the name MP.
The same happens with UFFI.
CL-USER> *features*
(:DARWIN :IEEE-FLOATING-POINT :RELATIVE-PACKAGE-NAMES :DFFI :CLOS-
STREAMS
:CMU-FORMAT :DLOPEN :CLOS :BOEHM-GC :ANSI-CL :COMMON-
LISP :ECL :COMMON
:PENTIUM3 :FFI :PREFIXED-API)
Is there something I forgot to do?
Also, is there any simple way to install and use asdf-install? I want
to use and install ltk, and some database engine (like cl-sql and/or
elephant).
Thanks!
Javier <·······@gmail.com> writes:
> Also, is there any simple way to install and use asdf-install? I want
> to use and install ltk, and some database engine (like cl-sql and/or
> elephant).
Obviously: (asdf-install:install :asdf-install)
Otherwise, I fail to see the unsimplicity of downloading a tarball,
extracting it, adding the path to asdf:*central-registry* and typing
(asdf:oos 'asdf:load :asdf-install). But that's only me.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
On 29 jun, 15:25, Javier <·······@gmail.com> wrote:
> Nice. I've been watchingECLthis morning, and reading the
> documentation.
> I have compiled it under OSX with default options (./configure &&
> make).
The default option is _not_ to include multi-thread support. The
reason is that it slows down Common Lisp and many people don't use it.
> Under Chapter 4, there are some functions described. It seems that
> they are under MP package, but I fail to load it up:
If you configure with ./configure --enable-threads plus any other
options you need, then this package is included _always_. There is no
need to use REQUIRE.
> Also, is there any simple way to install and use asdf-install? I want
> to use and install ltk, and some database engine (like cl-sql and/or
> elephant).
I think asdf-install contains fixes to add support for ECL. However my
experience so far has been mixed: there are still many packages out
there which do not include support for ECL and thus fail to install
properly. For instance, this has been the situation with Hunchentoot
so far: porting was not too difficult (thanks Geo!), but getting the
patches into the distribution takes time. Hence I normally use CVS
copies + my own ASDF scripts (see mailing list) + my own patches to
those libraries if needed.
Juanjo
On 30 jun, 12:46, Juanjo <·····················@googlemail.com> wrote:
> On 29 jun, 15:25, Javier <·······@gmail.com> wrote:
>
> > Nice. I've been watchingECLthis morning, and reading the
> > documentation.
> > I have compiled it under OSX with default options (./configure &&
> > make).
>
> The default option is _not_ to include multi-thread support. The
> reason is that it slows down Common Lisp and many people don't use it.
>
> > Under Chapter 4, there are some functions described. It seems that
> > they are under MP package, but I fail to load it up:
>
> If you configure with ./configure --enable-threads plus any other
> options you need, then this package is included _always_. There is no
> need to use REQUIRE.
>
> > Also, is there any simple way to install and use asdf-install? I want
> > to use and install ltk, and some database engine (like cl-sql and/or
> > elephant).
>
> I think asdf-install contains fixes to add support for ECL. However my
> experience so far has been mixed: there are still many packages out
> there which do not include support for ECL and thus fail to install
> properly. For instance, this has been the situation with Hunchentoot
> so far: porting was not too difficult (thanks Geo!), but getting the
> patches into the distribution takes time. Hence I normally use CVS
> copies + my own ASDF scripts (see mailing list) + my own patches to
> those libraries if needed.
>
> Juanjo
Thank you very much for all your work.
I'm starting to like ECL.
Just more one question: SLIME fails to show the arg names of some
functions. Is a minor issue, but I'm used to it. Also, the apropos
just shows in what package the function is defined and little more.
Any ideas on this and SLIME support in general?
I would like to help ECL project, in the future. I'm learning... yet.
On Jun 30, 10:06 pm, Javier <·······@gmail.com> wrote:
> Just more one question: SLIME fails to show the arg names of some
> functions. Is a minor issue, but I'm used to it. Also, the apropos
> just shows in what package the function is defined and little more.
> Any ideas on this and SLIME support in general?
This is a known issue. There is work in progress to ease gathering of
debug information such as argument names, positions in files, etc. It
is just a problem of coordination between the Slime and ECL projects:
those features can be added, but I want them to remain optional, so
that memory consumption is reduced; at the same time I need a precise
specification of what is needed and what should be the interface.
What I was repeatedly told is to look at the slime code myself and do
it like other implementations, which means that automatically becomes
second priority on my list and only improves when other nice people
like Geo Carncross push the project further.
> I would like to help ECLproject, in the future. I'm learning... yet.
You are welcome to join whenever you feel like. There are many small
tasks like the ones mentioned before that can be carried by new users.
Juanjo wrote:
> On Jun 30, 10:06 pm, Javier <·······@gmail.com> wrote:
>> Just more one question: SLIME fails to show the arg names of some
>> functions. Is a minor issue, but I'm used to it. Also, the apropos
>> just shows in what package the function is defined and little more.
>> Any ideas on this and SLIME support in general?
>
> This is a known issue. There is work in progress to ease gathering of
> debug information such as argument names, positions in files, etc. It
> is just a problem of coordination between the Slime and ECL projects:
> those features can be added, but I want them to remain optional, so
> that memory consumption is reduced; at the same time I need a precise
> specification of what is needed and what should be the interface.
Additionaly, the ECL CVS version is now incompatible with SLIME 2.0.
It does work with the SLIME CVS version, but this version is somewhat less
complete (something that I can't undersatnd).
> What I was repeatedly told is to look at the slime code myself and do
> it like other implementations, which means that automatically becomes
> second priority on my list and only improves when other nice people
> like Geo Carncross push the project further.
>
>> I would like to help ECLproject, in the future. I'm learning... yet.
>
> You are welcome to join whenever you feel like. There are many small
> tasks like the ones mentioned before that can be carried by new users.
I'll subcribe to ECL list and see what can I do.
Javier <··············@gmail.com> writes:
> Additionaly, the ECL CVS version is now incompatible with SLIME 2.0.
> It does work with the SLIME CVS version, but this version is somewhat less
> complete (something that I can't undersatnd).
You are confused. SLIME 2.0 is too old and doesn't work with most
modern versions of various CLs. SLIME CVS has a contrib system and some
of the functionality was moved there. I use:
(slime-setup '(slime-fancy slime-asdf slime-indentation))
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
In article
<····································@m36g2000hse.googlegroups.com>,
Juanjo <·····················@googlemail.com> wrote:
> On 29 jun, 15:25, Javier <·······@gmail.com> wrote:
> > Nice. I've been watchingECLthis morning, and reading the
> > documentation.
> > I have compiled it under OSX with default options (./configure &&
> > make).
>
> The default option is _not_ to include multi-thread support. The
> reason is that it slows down Common Lisp and many people don't use it.
>
> > Under Chapter 4, there are some functions described. It seems that
> > they are under MP package, but I fail to load it up:
>
> If you configure with ./configure --enable-threads plus any other
> options you need, then this package is included _always_. There is no
> need to use REQUIRE.
>
> > Also, is there any simple way to install and use asdf-install? I want
> > to use and install ltk, and some database engine (like cl-sql and/or
> > elephant).
>
> I think asdf-install contains fixes to add support for ECL. However my
> experience so far has been mixed: there are still many packages out
> there which do not include support for ECL and thus fail to install
> properly. For instance, this has been the situation with Hunchentoot
> so far: porting was not too difficult (thanks Geo!), but getting the
> patches into the distribution takes time. Hence I normally use CVS
> copies + my own ASDF scripts (see mailing list) + my own patches to
> those libraries if needed.
>
> Juanjo
Hi,
a few questions:
* does ECL support X11/CLX?
* are the threads native?
* compiler compiles to C - also to byte codes?
* GC under Mac OS X is Boehm/Weiser conservative/generational? Right?
* Delivery via as shared libray, application? Also as dumped images?
* 32bit support on Mac OS X on PPC and Intel? Right? How about 64bit?
I was just building ECL on my MacBook Pro and it is indeed painless.
Well done!
Regards,
Rainer Joswig
--
http://lispm.dyndns.org/
On 30 jun, 15:42, Rainer Joswig <······@lisp.de> wrote:
> * doesECLsupport X11/CLX?
It ships a possibly out of date version of the telent library. I must
admit I have not built it for some years now and somebody should
upgrade it to the latest versions -- but I lost my account in that
project and have no time to keep track of it.
> * are the threads native?
Yes. They are posix threads.
> * compiler compiles to C - also to byte codes?
It ships by default with a bytecodes compiler that works on the fly.
Interpreted in our case means bytecodes compilation and then run. This
is indeed the most stable component of the suite. By comparison, the C
compiler needs to be significantly improved.
> * GC under Mac OS X is Boehm/Weiser conservative/generational? Right?
Both. There is a flag --enable-gengc that activates the generational
algorithm in the Boehm/Weiser library. That brings ECL's performance
on par with SBCL on some real life code.
> * Delivery via as shared libray, application? Also as dumped images?
No dumped images because there is no portable way to do it. However,
you can link all your code into a single program, shared library or
FASL file using ASDF. See http://ecls.sourceforge.net/new-manual/ and
more precisely the section on ASDF extensions.
> * 32bit support on Mac OS X on PPC and Intel? Right? How about 64bit?
I do not have a 64bit machine right now, but if you find out the right
compiler flags, it should be rather painless to include it in the
configuration file. ECL itself is word-size and word-endian agnostic.
It simply does not care whether you use 32, 48, 64 or 128 bits.
> I was just buildingECLon my MacBook Pro and it is indeed painless.
> Well done!
I am glad to read this. Should any problem occur, please contact me
either by private email or in the mailing list -- I prefer this
method.
Juanjo
On Jun 30, 6:34 pm, Juanjo <·····················@googlemail.com>
wrote:
> > * GC under Mac OS X is Boehm/Weiser conservative/generational? Right?
>
> Both. There is a flag --enable-gengc that activates the generational
> algorithm in the Boehm/Weiser library. That bringsECL'sperformance
> on par with SBCL on some real life code.
The --enable-gengc (generational garbage collector) and the --enable-
smallcons (conses are two-word objects) increase the speed of ECL
significantly, but are still only available in the CVS unstable
version. If time permits and I finish setting up the test farm, I will
release a new version of ECL this summer. This is in particular
important for only with the recent changes does Maxima run on ECL.
Juanjo
In article
<····································@c65g2000hsa.googlegroups.com>,
Juanjo <·····················@googlemail.com> wrote:
> On Jun 30, 6:34�pm, Juanjo <·····················@googlemail.com>
> wrote:
> > > * GC under Mac OS X is Boehm/Weiser �conservative/generational? Right?
> >
> > Both. There is a flag --enable-gengc that activates the generational
> > algorithm in the Boehm/Weiser library. That bringsECL'sperformance
> > on par with SBCL on some real life code.
>
> The --enable-gengc (generational garbage collector) and the --enable-
> smallcons (conses are two-word objects) increase the speed of ECL
> significantly, but are still only available in the CVS unstable
> version. If time permits and I finish setting up the test farm, I will
> release a new version of ECL this summer. This is in particular
> important for only with the recent changes does Maxima run on ECL.
>
> Juanjo
Last questions:
* Unicode?
* Gray streams (or similar)?
* MOP?
* SSL streams?
* SLIME support?
Regards,
Rainer Joswig
--
http://lispm.dyndns.org/
On Jun 30, 11:02 pm, Rainer Joswig <······@lisp.de> wrote:
> * Unicode?
Currently only support for big characters in the strings and #\Uxxxx
codes when reading. The streams I/O system still needs to be upgraded
to support UTF-* and other input formats.
> * Gray streams (or similar)?
(use-package "GRAY")
If for some reason you really want CL:CLOSE to be a generic, then also
(REDEFINE-CL-FUNCTIONS). Otherwise it will still work but you will
have to do something like (DEFMETHOD GRAY:CLOSE (...) ...).
> * MOP?
Look for it in the CLOS package -- though now that I come to think
about it, I should eventually export the appropriate names through a
MOP package --. Some "difficult" features are missing, such as METHOD-
LAMBDA.
> * SSL streams?
Not yet, just SB-SOCKETS, but enough that hunchentoot runs on it.
Given that FLEXI-STREAMS and similar packages work with ECL (thanks
again Geo!) support for SSL streams should be rather easy.
> * SLIME support?
There is some support on the slime side. Swank simply works.
Integrating further features such as better documentation and function
argument names can be easily done.
Juanjo
On Jun 30, 6:34 pm, Juanjo <·····················@googlemail.com>
wrote:
> On 30 jun, 15:42, Rainer Joswig <······@lisp.de> wrote:
> > * GC under Mac OS X is Boehm/Weiser conservative/generational? Right?
>
> Both. There is a flag --enable-gengc that activates the generational
> algorithm in the Boehm/Weiser library. That bringsECL'sperformance
> on par with SBCL on some real life code.
Let me be a bit more precise here. There are several interesting
configuration flags which are only available in the unstable version,
reachable only via CVS or git. These flags are --enable-gengc (enable
generational garbage collector), --enable-smallcons (conses take only
2 words) and --enable-asmapply (on x86/32 we use assembler for faster
function dispatch).
Juanjo
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87zlp5d4jn.fsf@geddis.org>
Javier <·······@gmail.com> wrote on Fri, 27 Jun 2008:
> On 28 jun, 05:50, Don Geddis <····@geddis.org> wrote:
>> >> Javier <·······@gmail.com> writes:
>> >> > Ok, lets start with a MP3 reader codec, and some CFFI for connecting
>> >> > to the OS sound driver.
>>
>> Ah, so now you've changed your requirements. �Now it seems that your REAL
>> requirement is that you have an existing OS with some existing drivers, and
>> you want to interface to those drivers as painlessly as possible.
>
> You are becoming a little paranoiac now. Yes, off course I want to
> interface to those drivers as painlessly as possible. I'm not going to
> write my own OS!!
Your example has almost nothing EXCEPT interfacing with the OS. This is
not a good example for evaluating the quality of a number of programming
languages. You'll find that the language the OS is written in to be by
far the easiest to use, for interfacing with it.
If you really mean "...let's start with...", and that this task is just
preliminary to get you started and productive with music/audio software,
and you're not going to stop after only doing the driver interface and loudly
proclaim "C is easier to use than Lisp (in my example)!" ... well, then, ok.
In that case, go ahead and use CFFI or whatever, make your interfaces ... and
then get on with the real task of writing the actual interesting application
in Lisp (or whatever language you're evaluating).
>> Naturally, when you express your goal that way, the answer is: use whatever
>> language the OS happens to be written in.
>
> This is actually why C is so successful
Yes of course.
Also, popularity helps too. There are tons of books and conferences and
classes on Java programming.
This is all independent from whether Java or C is a well-designed, productive
language for programmers.
> but I want to give Lisp a try. But if you, a prominent Lisp user, is trying
> to convince me not do so, should I think it twice?
Lisp is certainly worth trying. But if your only task is interfacing to
unix device drivers, that's not a situation where you will find Lisp more
convenient than C.
> I was really wanting to make an audio multi-OS library allowing SBCL to
> interact with audio drivers and audio file formats, just to deserve to my
> future projects.
OK, you can do that.
Just be sure you don't stop with the driver interfaces. Actually write some
interesting algorithms in the source code as well, if you want to learn
something about Lisp.
> I found CL-ALSA, CL-MADHL, and CM. Perhaps it is a good start. The
> first two one use CFFI, of course. I don't like it, but I can live
> with it if there is no other choice.
Looks like you're off to a good start.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Do married people live longer, or does it just seem that way?
On 28 juin, 16:20, Don Geddis <····@geddis.org> wrote:
> Javier <·······@gmail.com> wrote on Fri, 27 Jun 2008:
> > but I want to give Lisp a try. But if you, a prominent Lisp user, is trying
> > to convince me not do so, should I think it twice?
>
> Lisp is certainly worth trying. But if your only task is interfacing to
> unix device drivers, that's not a situation where you will find Lisp more
> convenient than C.
[...]
> Looks like you're off to a good start.
He's been up to this nonsense for two years now. Still claiming he
wants to give Lisp a try but something-or-other is in the way. Doesn't
sound like a good start to me.
On 29 jun, 11:35, "Thomas F. Burdick" <········@gmail.com> wrote:
> On 28 juin, 16:20, Don Geddis <····@geddis.org> wrote:
>
> > Javier <·······@gmail.com> wrote on Fri, 27 Jun 2008:
> > > but I want to give Lisp a try. But if you, a prominent Lisp user, is trying
> > > to convince me not do so, should I think it twice?
>
> > Lisp is certainly worth trying. But if your only task is interfacing to
> > unix device drivers, that's not a situation where you will find Lisp more
> > convenient than C.
>
> [...]
>
> > Looks like you're off to a good start.
>
> He's been up to this nonsense for two years now. Still claiming he
> wants to give Lisp a try but something-or-other is in the way. Doesn't
> sound like a good start to me.
If you look at c.l.l, there are many people here wasting their time
speculating about programming languages, and not doing anything really
remarkable.
For example, can you show us up any significant project or general
application in which you are working using Lisp? If so, how much time
do you dedicate to it compared to how much time do you waste in this
newsgroup? And how much time did you needed for the first time until
you wrote your fist Lisp program?
Now ask the same to the rest of people here.
But soon or later, I'm going to start. Perhaps when I stop to read
c.l.l and start to code...
Just noticed this reply because the thread got bumped again.
On Jun 29, 1:27 pm, Javier <·······@gmail.com> wrote:
> On 29 jun, 11:35, "Thomas F. Burdick" <········@gmail.com> wrote:
>
> > On 28 juin, 16:20, Don Geddis <····@geddis.org> wrote:
> >
> > > Looks like you're off to a good start.
>
> > He's been up to this nonsense for two years now. Still claiming he
> > wants to give Lisp a try but something-or-other is in the way. Doesn't
> > sound like a good start to me.
>
> If you look at c.l.l, there are many people here wasting their time
> speculating about programming languages, and not doing anything really
> remarkable.
That means that you are off to a good start by following their lead?
> For example, can you show us up any significant project or general
> application in which you are working using Lisp?
Yes. Hell, I even presented an application at a ECLM.
> If so, how much time
> do you dedicate to it compared to how much time do you waste in this
> newsgroup?
The time I spend reading this newsgroup is not time that I would have
been hacking. It takes away from my LOL-Cat and YouTube time, though.
Come to think of it, I should cut back and make room for more of this:
http://www.youtube.com/watch?v=9HaxFbEDCV4
But seriously, I'd say the large majority of my 40 h/week, plus maybe
a weekend day every 5 or 6 weeks on personal stuff.
> And how much time did you needed for the first time until
> you wrote your fist Lisp program?
I dove in head-first. I was actually working on code and little tools
within a couple weeks of picking up On Lisp.
> Now ask the same to the rest of people here.
>
> But soon or later, I'm going to start. Perhaps when I stop to read
> c.l.l and start to code...
I didn't say it's impossible that you'll eventually do something. Only
you can know. But again, complaining on c.l.l about why you can't!
possibly! do what you really! need! to do in Lisp ... while a popular
passtime, a good start it is not.
On 26 Giu, 20:54, Don Geddis <····@geddis.org> wrote:
<snip>
> Or, let me try another way: everything you've said applies equally well to
> any high-level language vs. assembly code. Why aren't you arguing that every
> program should be written in assembly language? SURELY assembly language (in
> principle) wins EVERY microbenchmark.
>
> If you start to explore your (limited?) understanding of why C is "better"
> than assembly language -- despite doing WORSE on the microbenchmarks -- then
> you'll start to also understand why Lisp is better than C (regardless of
> microbenchmark performance).
I don't think he claimed that C is better than Lisp, but that C is
faster than Lisp.
Assembly is indeed faster than every high level language, but that
doesn't make it better.
<snip>
> Consider this: it is surely harder to make "correct" programs in C, than in
> Lisp. The additional effort required to make the C program correct isn't
> free. You can't sweep under the rug the fact that the Lisp program gets to a
> correct state much faster. So, for a fixed total amount of programming time,
> there is more time left in the Lisp camp to do profiling and performance
> improvement.
Yes but usually C allows for more manual optimization, as far as I
know.
Unless perhaps a Lisper makes a large use of dynamically generated
code and maybe Scheme-like continuations, but I'm not sure there are
many real world cases you can apply these techniques to get a
performance bonus over C (or C++ with properly implemented templates
and exceptions).
Perhaps interpreters are among the few applications where these
techniques can be efficiently used. Are interpeters written in Lisp
faster than their equivalents written in C?
<snip>
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87vdzsec7c.fsf@hubble.informatimago.com>
Vend <······@virgilio.it> writes:
> Assembly is indeed faster than every high level language, but that
> doesn't make it better.
This is not true.
There exist some programs such as there exist some (very few)
programmers who could write a faster program in assembler than any
equivalent program written in higher level programming language.
But
for most programs, almost all programmer are not able to write a
faster equivalent one in assembler.
There was a time when all programmers were expert assembler
programmers (because there was no other way to program a computer),
and when compilers were something new enough and were lacking enough
optimization algorithms, so that it was true.
But since the times of RISC processors, the compilers have been able
to better optimize pipeline scheduling than any human programmer, and
have in general produced faster code than human, for the programs of
the size of the programs we create nowadays.
> Yes but usually C allows for more manual optimization, as far as I
> know.
But overall, the quicks of C and C++ prevent them to make more
automatic optimizations, which is why they're doomed and high level
programming language will have compilers generating faster code.
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
On 29 Giu, 13:02, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Vend <······@virgilio.it> writes:
> > Assembly is indeed faster than every high level language, but that
> > doesn't make it better.
>
> This is not true.
>
> There exist some programs such as there exist some (very few)
> programmers who could write a faster program in assembler than any
> equivalent program written in higher level programming language.
>
> But
>
> for most programs, almost all programmer are not able to write a
> faster equivalent one in assembler.
Most likely they wouldn't be able to write an equivalent program in
assembler, within their time and cost constraints.
But if they manage to write it and they spend enough time optimizing
it the result will be likely faster than the optimized high level
code, at least until compilers become more 'intelligent' than
programmers.
If you take into account development time and cost into the measure of
a language speed, then even Matlab is faster than C for many
scientific/engineering applications.
> There was a time when all programmers were expert assembler
> programmers (because there was no other way to program a computer),
> and when compilers were something new enough and were lacking enough
> optimization algorithms, so that it was true.
>
> But since the times of RISC processors, the compilers have been able
> to better optimize pipeline scheduling than any human programmer, and
> have in general produced faster code than human, for the programs of
> the size of the programs we create nowadays.
I might be wrong but I think that pipeline scheduling is mostly a
local issue, so it shouldn't depend very much on the program size.
Anyway, pipeline scheduling is surely tedious to do manually, but I'm
not sure whether compilers get a more efficient result than humans.
> > Yes but usually C allows for more manual optimization, as far as I
> > know.
>
> But overall, the quicks of C and C++ prevent them to make more
> automatic optimizations, which is why they're doomed and high level
> programming language will have compilers generating faster code.
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> READ THIS BEFORE OPENING PACKAGE: According to certain suggested
> versions of the Grand Unified Theory, the primary particles
> constituting this product may decay to nothingness within the next
> four hundred million years.
On Jun 29, 10:23 am, Vend <······@virgilio.it> wrote:
>
> > for most programs, almost all programmer are not able to write a
> > faster equivalent one in assembler.
>
> Most likely they wouldn't be able to write an equivalent program in
> assembler, within their time and cost constraints.
>
> But if they manage to write it and they spend enough time optimizing
> it the result will be likely faster than the optimized high level
> code, at least until compilers become more 'intelligent' than
> programmers.
So if we have a team of programmers with no time and cost constraints,
and who are as knowledgeable about writing assembly language as are
the best compiler-writers (who know all about how to predict the speed
of execution of a sequence of instructions, which in modern CPU's is
extremely difficult), does that mean they'd come up with a faster
program?
Well, if the job is to write a relatively small numerical algorithm,
yes, I'd concede that. If the job is to write a huge transaction
processing system that make heavy use of a database management system,
message parsing and production, communication with other computers,
complex abstractions, arcane industry business rules, user interfaces,
transactions, timeouts, and so on? Will all that careful hand-coding
make that much difference? I suppose if we truly postulate infinite
time and resources, perhaps, but the entire point of software
engineering and doing programming in reality is that there's no such
thing as infinite time and resources.
-- Dan
From: Don Geddis
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87tzfcrqib.fsf@geddis.org>
···@informatimago.com (Pascal J. Bourguignon) wrote on Sun, 29 Jun 2008:
> But since the times of RISC processors, the compilers have been able to
> better optimize pipeline scheduling than any human programmer, and have in
> general produced faster code than human, for the programs of the size of
> the programs we create nowadays.
Yeah, I thought of this too. It's unlikely that a human programmer can
hand-generate better assembly than an optimizing compiler for a high-level
language.
But it's also true that high-level languages impose some constraints on
the generated assembly. There are calling conventions, etc. Lisp allows
run-time function redefinition, so code has to be prepared for changes like
that. Etc.
I suppose the comparison would be: a search through the space of all possible
assembly language programs. Say that the goal was to write a sort function,
to sort a list of integers. One approach might be: start enumerating
sequences of assembly language programs, and stop when you get a really fast
one that matches the specs. Presumably, there does exist SOME assembly
programs which is faster/smaller/better than the result of any (current)
optimizing compiler on any high-level language.
That's not a practical way to program, of course. But if we're just talking
in theory...
Well, in any case, the whole point was that a lot of things matter in
the practical realities of programming, than just the raw absolute speed
of the final code on a few microbenchmarks.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If trees could scream, would we be so cavalier about cutting them down? We
might, if they screamed all the time, for no good reason.
-- Deep Thoughts, by Jack Handey [1999]
On Sun, 29 Jun 2008 12:27:08 -0700, Don Geddis <···@geddis.org> said:
| ...
| I suppose the comparison would be: a search through the space of all possible
| assembly language programs. Say that the goal was to write a sort function,
| to sort a list of integers. One approach might be: start enumerating
| sequences of assembly language programs, and stop when you get a really fast
| one that matches the specs.
But how to determine that?
| Presumably, there does exist SOME assembly programs which is
| faster/smaller/better than the result of any (current) optimizing
| compiler on any high-level language.
By the speed-up theorem, certainly... (Not that it is feasible to
construct it by hand, of course.)
---Vassil.
--
Peius melius est. ---Ricardus Gabriel.
On Sun, 29 Jun 2008 13:02:15 +0200, ···@informatimago.com (Pascal J.
Bourguignon) wrote:
>Vend <······@virgilio.it> writes:
>> Assembly is indeed faster than every high level language, but that
>> doesn't make it better.
>
>This is not true.
>
>There exist some programs such as there exist some (very few)
>programmers who could write a faster program in assembler than any
>equivalent program written in higher level programming language.
>
>But
>
>for most programs, almost all programmer are not able to write a
>faster equivalent one in assembler.
This can be trivially shown to be incorrect.
Compilers frequently have a limited scope of awareness where several
logical code sequences are interleaved - under register pressure they
only rarely choose the most effective instruction sequencing and
frequently optimization does not completely remove superfluous code
resulting from generator templates or inserted by various analysis
phases and transformations (SSA phi functions are a prime example -
take a look at the hoops GCC jumps through to try to remove them).
With shockingly little effort, most programmers are able to take an
assembler listing from most compilers and optimize the code to run
faster (in some corner cases, much faster).
I spent years implementing hard real time systems where virtually
every cycle counted - and a great deal of time teaching young
programmers how to optimize algorithms and shave cycles when needed.
Once the programmer understands the workings of the pipeline and
studies the instruction set, she can *usually* beat the compiler
alone. In 20 years, I have only seen a handful of cases where the
compiler managed to produce optimal code to begin with.
btw: I have also written a production compiler for an embedded
DSP+FPGA system (speaking of weird constraints!) and several hobby
compilers. Compilers and runtime systems are two of my main geek
hobbies.
George
--
for email reply remove "/" from address
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <87y74ap7wl.fsf@hubble.informatimago.com>
George Neuner <·········@/comcast.net> writes:
> On Sun, 29 Jun 2008 13:02:15 +0200, ···@informatimago.com (Pascal J.
> Bourguignon) wrote:
>
>>Vend <······@virgilio.it> writes:
>>> Assembly is indeed faster than every high level language, but that
>>> doesn't make it better.
>>
>>This is not true.
>>
>>There exist some programs such as there exist some (very few)
>>programmers who could write a faster program in assembler than any
>>equivalent program written in higher level programming language.
>>
>>But
>>
>>for most programs, almost all programmer are not able to write a
>>faster equivalent one in assembler.
>
> This can be trivially shown to be incorrect.
>
> Compilers frequently have a limited scope of awareness where several
> logical code sequences are interleaved - under register pressure they
> only rarely choose the most effective instruction sequencing and
> frequently optimization does not completely remove superfluous code
> resulting from generator templates or inserted by various analysis
> phases and transformations (SSA phi functions are a prime example -
> take a look at the hoops GCC jumps through to try to remove them).
> With shockingly little effort, most programmers are able to take an
> assembler listing from most compilers and optimize the code to run
> faster (in some corner cases, much faster).
>
> I spent years implementing hard real time systems where virtually
> every cycle counted - and a great deal of time teaching young
> programmers how to optimize algorithms and shave cycles when needed.
> Once the programmer understands the workings of the pipeline and
> studies the instruction set, she can *usually* beat the compiler
> alone. In 20 years, I have only seen a handful of cases where the
> compiler managed to produce optimal code to begin with.
>
> btw: I have also written a production compiler for an embedded
> DSP+FPGA system (speaking of weird constraints!) and several hobby
> compilers. Compilers and runtime systems are two of my main geek
> hobbies.
You're right, after all, there's more processing power in a brain than
in the processors on which compilers can work right now.
I forgot the economic term of the equation.
For most programs, for most (real) budgets (money and time), almost
all programmers are not able to write a faster equivalent one in
assembler.
No human programmer would be able to translate 250 KB of C++ sources
into a 5 MB exectuable in less than 5 mn and less than $1. But this
is what gcc does for me flawlessly several times a day.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
On Thu, 10 Jul 2008 08:31:22 +0200, ···@informatimago.com (Pascal J.
Bourguignon) wrote:
>George Neuner <·········@/comcast.net> writes:
>
>> On Sun, 29 Jun 2008 13:02:15 +0200, ···@informatimago.com (Pascal J.
>> Bourguignon) wrote:
>>
>>>Vend <······@virgilio.it> writes:
>>>> Assembly is indeed faster than every high level language, but that
>>>> doesn't make it better.
>>>
>>>This is not true.
>>>
>>>There exist some programs such as there exist some (very few)
>>>programmers who could write a faster program in assembler than any
>>>equivalent program written in higher level programming language.
>>>
>>>But
>>>
>>>for most programs, almost all programmer are not able to write a
>>>faster equivalent one in assembler.
>>
>> This can be trivially shown to be incorrect.
>>
>> Compilers frequently have a limited scope of awareness where several
>> logical code sequences are interleaved - under register pressure they
>> only rarely choose the most effective instruction sequencing and
>> frequently optimization does not completely remove superfluous code
>> resulting from generator templates or inserted by various analysis
>> phases and transformations (SSA phi functions are a prime example -
>> take a look at the hoops GCC jumps through to try to remove them).
>> With shockingly little effort, most programmers are able to take an
>> assembler listing from most compilers and optimize the code to run
>> faster (in some corner cases, much faster).
>>
>> I spent years implementing hard real time systems where virtually
>> every cycle counted - and a great deal of time teaching young
>> programmers how to optimize algorithms and shave cycles when needed.
>> Once the programmer understands the workings of the pipeline and
>> studies the instruction set, she can *usually* beat the compiler
>> alone. In 20 years, I have only seen a handful of cases where the
>> compiler managed to produce optimal code to begin with.
>>
>> btw: I have also written a production compiler for an embedded
>> DSP+FPGA system (speaking of weird constraints!) and several hobby
>> compilers. Compilers and runtime systems are two of my main geek
>> hobbies.
>
>You're right, after all, there's more processing power in a brain than
>in the processors on which compilers can work right now.
>
>I forgot the economic term of the equation.
>
>For most programs, for most (real) budgets (money and time), almost
>all programmers are not able to write a faster equivalent one in
>assembler.
>
>
>No human programmer would be able to translate 250 KB of C++ sources
>into a 5 MB exectuable in less than 5 mn and less than $1. But this
>is what gcc does for me flawlessly several times a day.
That's true. For most purposes, it would be completely impractical to
write any significant portion of a whole application in assembler.
And if you did, it is likely that a compiler would still provide
better performance for significant portions of it simply by brute
force and programmer inattention - assembly fu has a well deserved
reputation for being inconsistent. The right way is always to
leverage the compiler and do peephole optimization only where
necessary.
George
--
for email reply remove "/" from address
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g531rv$50d$1@aioe.org>
Don Geddis wrote:
> Javier <·······@gmail.com> wrote on Thu, 26 Jun 2008:
>> The faster it is at concrete things, the faster it should be in general.
>> Any point at which it is not fast, is a bottle-neck that prevents the
>> full application to be fast. That's logical.
>
> Science trumps logic, I'm afraid. It doesn't matter how airtight you
> think your argument is. The actual experience of real programmers writing
> real applications is that microbenchmarking is not a very useful guide to
> the eventual speed of the final full application.
>
> We can debate the reasons for why that might so, but the fact that it is
> so should not be in doubt.
What you are calling a "fact" certainly is in doubt. Microbenchmarks are
used to find a huge variety of fundamental problems (e.g. exception
handling on .NET is 600x than OCaml's) and those results are absolutely
essential when optimizing whole programs.
IMHO, your "fact" is completely wrong.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
On Jun 26, 8:41 am, Javier <·······@gmail.com> wrote:
> On 26 jun, 13:40, ··········@gmail.com wrote:
>
> I hope that you agree with me that if a Lisp implementation is good at
> microbenchmarking, it also means, in some way, that it will be good
> when using it for full applications.
Well, no, I don't. That is, the ratios of speed that we see in
various microbenchmarks vary, sometimes greatly, depending on what you
measure. The problem is more severe in full applications, where the
total time tends to depend on even more variables, such as GC
overhead, demand paging overhead, CPU cache hit rates (being more
complicated than in microbenchmark situations), use of many more
language features, and so on.
I do think that being able to show that Lisp can hold its own on some
microbenchmarks is a good first step toward getting someone to believe
that Lisp might also do well on real applications. That's a very
different statement, though. To put it another way, suppose I'm
trying to convince Alice that doing our new project in Lisp is a good
idea, and she says, no, everybody knows Lisp is much too slow for
anything real. Now what do I do? Well, one thing I can do is show
her some nice microbenchmark results. It doesn't prove anything about
how fast the real project will run. But it does make it feel more
plausible that the real application has some chance of being fast, and
it might make Alice more optimistic about Lisp, and more amenable to
spending the time to do some real benchmarking rather than simply
dismissing Lisp out of hand. In that respect, I think this kind of
microbenchmarking is valuable for the Lisp "cause".
-- Dan
In article
<····································@f36g2000hsa.googlegroups.com>,
Dan Weinreb <···@alum.mit.edu> wrote:
> On Jun 26, 8:41 am, Javier <·······@gmail.com> wrote:
> > On 26 jun, 13:40, ··········@gmail.com wrote:
>
> >
> > I hope that you agree with me that if a Lisp implementation is good at
> > microbenchmarking, it also means, in some way, that it will be good
> > when using it for full applications.
>
> Well, no, I don't. That is, the ratios of speed that we see in
> various microbenchmarks vary, sometimes greatly, depending on what you
> measure. The problem is more severe in full applications, where the
> total time tends to depend on even more variables, such as GC
> overhead, demand paging overhead, CPU cache hit rates (being more
> complicated than in microbenchmark situations), use of many more
> language features, and so on.
True.
Often these microbenchmarks use litte library code and
are compiled to unsafe code (no runtime checks, ...).
I often prefer to use the opposite: lots of library code
and safe code (library + application code).
So may be equally important to measure how a Lisp system
behaves with fully safe code, lots of debug info included
and using lots of pre-compiled libraries (hopefully also
compiled to safe code).
Safe code should also be used for the FFI. I like to see
runtime checks of argument types and return values to/from foreign
code.
> I do think that being able to show that Lisp can hold its own on some
> microbenchmarks is a good first step toward getting someone to believe
> that Lisp might also do well on real applications. That's a very
> different statement, though. To put it another way, suppose I'm
> trying to convince Alice that doing our new project in Lisp is a good
> idea, and she says, no, everybody knows Lisp is much too slow for
> anything real. Now what do I do? Well, one thing I can do is show
> her some nice microbenchmark results. It doesn't prove anything about
> how fast the real project will run. But it does make it feel more
> plausible that the real application has some chance of being fast, and
> it might make Alice more optimistic about Lisp, and more amenable to
> spending the time to do some real benchmarking rather than simply
> dismissing Lisp out of hand. In that respect, I think this kind of
> microbenchmarking is valuable for the Lisp "cause".
>
> -- Dan
--
http://lispm.dyndns.org/
From: Jon Harrop
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g532gb$di3$1@aioe.org>
Rainer Joswig wrote:
> Often these microbenchmarks use litte library code and
> are compiled to unsafe code (no runtime checks, ...).
>
> I often prefer to use the opposite: lots of library code
> and safe code (library + application code).
>
> So may be equally important to measure how a Lisp system
> behaves with fully safe code, lots of debug info included
> and using lots of pre-compiled libraries (hopefully also
> compiled to safe code).
>
> Safe code should also be used for the FFI. I like to see
> runtime checks of argument types and return values to/from foreign
> code.
I think it is particularly enlightening to note just how far the Haskell
contributors took that idea.
For example, the Haskell implementation of k-nucleotide is 2x slower and
2.5x longer than OCaml because it is filled with unsafe pointer arithmetic
written using the FFI (which has no place in this program):
htHash (I# max) (I# size) ···@(Ptr p) = abs . inlinePerformIO . IO $ go p 0#
where
lim = p `plusAddr#` size
go p acc !s
| p `geAddr#` lim = (# s, I# (acc `remInt#` max) #)
| otherwise = case readInt8OffAddr# p 0# s of
(# s, i #) -> go (p `plusAddr#` 1#) (5# *# acc +# i) s
There are very few significant Haskell programs in existence. At ~10kLOC,
Frag (a simple 3D game) is one of them and it segfaulted on my 64-bit
machine when I tried to run it precisely because it was full of this kind
of unsafe pointer arithmetic.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
From: Pascal J. Bourguignon
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <7cod56b07p.fsf@pbourguignon.anevia.com>
Jon Harrop <···@ffconsultancy.com> writes:
> Rainer Joswig wrote:
>> Often these microbenchmarks use litte library code and
>> are compiled to unsafe code (no runtime checks, ...).
>>
>> I often prefer to use the opposite: lots of library code
>> and safe code (library + application code).
>>
>> So may be equally important to measure how a Lisp system
>> behaves with fully safe code, lots of debug info included
>> and using lots of pre-compiled libraries (hopefully also
>> compiled to safe code).
>>
>> Safe code should also be used for the FFI. I like to see
>> runtime checks of argument types and return values to/from foreign
>> code.
>
> I think it is particularly enlightening to note just how far the Haskell
> contributors took that idea.
>
> For example, the Haskell implementation of k-nucleotide is 2x slower and
> 2.5x longer than OCaml because it is filled with unsafe pointer arithmetic
> written using the FFI (which has no place in this program):
>
> htHash (I# max) (I# size) ···@(Ptr p) = abs . inlinePerformIO . IO $ go p 0#
> where
> lim = p `plusAddr#` size
> go p acc !s
> | p `geAddr#` lim = (# s, I# (acc `remInt#` max) #)
> | otherwise = case readInt8OffAddr# p 0# s of
> (# s, i #) -> go (p `plusAddr#` 1#) (5# *# acc +# i) s
>
> There are very few significant Haskell programs in existence. At ~10kLOC,
> Frag (a simple 3D game) is one of them and it segfaulted on my 64-bit
> machine when I tried to run it precisely because it was full of this kind
> of unsafe pointer arithmetic.
Well, of course. That's why it would be preferable to re-implement in
Lisp libraries written in lower level languages. Using FFI is a Q&D
temporary solution.
--
__Pascal Bourguignon__
From: Didier Verna
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <muxd4lx3gz1.fsf@uzeb.lrde.epita.fr>
Javier <·······@gmail.com> wrote:
> I hope that you agree with me that if a Lisp implementation is good at
> microbenchmarking, it also means, in some way, that it will be good
> when using it for full applications.
Nope. Full applications (that is, bigger and more complex code) come
with additional parameters that can pretty much defeat performance, and
that microbenches will miss. I'm thinking about the quality of the
register allocation policy for example. This is a problem that doesn't
show up small-and-simple code for microbenches.
The way I see it, if you want to convince somebody that a language L is
good, you *need* to start with microbenches because if you loose even
for low-level stuff, it's not worth going further. However, if you win,
then you might get people's attention.
See my ELW'06 paper about that:
http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf
--
5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
On Jun 26, 4:40 am, ··········@gmail.com wrote:
> On Jun 25, 1:12 am, Javier <·······@gmail.com> wrote:
>
>
>
> > SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
> > times faster than Java (client), and is finally as fast as Ocaml.
>
> For purposes of propaganda, i.e. advocating Common Lisp, this is
> great.
> I'm all for propaganda of this kind. I guess "marketing collateral"
> would be a more euphemistic way of putting it.
>
> As for whether it really means anything: microbenchmarking is hard,
> and interpreting the results is hard. See Richard Gabriel's book
> on measuring Lisp for a great discussion of why it's so hard.
> See Didier Verna's excellent paper, in which he compares
> Common Lisp and C++ for some simple image-processing apps to
> see how masterfully he deals with the hard issues. It's called
> "Beating C in Scientific Computing Applications: On the Behavior
> and Performance of Lisp, Part 1". One of the many smart things
> he does is to try several Common Lisp implementations. SBCL
> and Allegro both come out well.
>
> Notice that the "shootout" numbers are taking the mean of
> many benchmarks, because everybody wants a single number
> that measures speed, as if every microbenchmark will have
> exactly the same ratio for each language. Of course that's
> not true, and it depends a lot on which things you benchmark.
> And if you're going to take a mean, you have to choose your
> weighting. To their credit, they provide a way to do that,
> but how do you know what to put in those boxes? The
> "what fun!" comment on that web page shows that they
> understand this perfectly.
And rather than being a sarcastic question "Can you manipulate the
multipliers and weights to make your favourite language the best
programming language in the Benchmarks Game?" is an invitation to play
around - iirc I once managed to get Python to be #1 ;-)
> See the full comparison between SBCL and the fastest
> Java that they show:
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all〈=sbc...
>
> That's more informative. The mean is being influenced
> by a few benchmarks on which SBCL did a lot better,
> whereas it did somewhat worse on many of the benchmarks.
Yes that is how the FAQ says to compare language implementations.
For some reason, the OP chose to state that the SBCL was faster than
the Java -client.
In contrast you have chosen a comparison with Java -server, not with
Java -client.
Just looking at the mean scores would give the impression that SBCL
was a little slower than Java -server :-)
>
> What you really want is a way to predict, in advance, how
> much faster or slower your app will be, so that you can
> take that into account when you choose a language. The
> ability of this kind of microbenchmark to help you make
> that prediction is limited at best.
>
> By the way, I often say that you get the most speed from
> Lisp, compared to other languages, because you can make
> your program work correctly in less time, thus leaving
> more time between then and the project deadline to work
> on performance improvement. And big performance wins
> come from high-level approaches, which also take time
> to develop, so developer productivity translates directly
> into runtime performance, if you decide to care about
> runtime performance.
>
> Warm congratulations to the SBCL maintainers
> (hi, Nikodemus!). They deserve lots of credit. These
> results are extremely impressive!
>
> -- Dan
(It's not obvious to me that these results are particularly different
to what they were a year ago?)
From: John Thingstad
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <op.udc50qb2ut4oq5@pandora.alfanett.no>
P� Thu, 26 Jun 2008 13:40:20 +0200, skrev <··········@gmail.com>:
> On Jun 25, 1:12 am, Javier <·······@gmail.com> wrote:
>
>>
>> SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
>> times faster than Java (client), and is finally as fast as Ocaml.
>
I might add thet while the efficiency model of C is simple to understand
the efficiency of Lisp is notoriously difficult to understand.
It is easy to get performance 40x times that of C without understanding
the reason.
I recomend 'dissassemble if in doubt.
Thus I also take this claim with a grain of salt.
--------------
John Thingstad
On 26 jun, 18:13, "John Thingstad" <·······@online.no> wrote:
> På Thu, 26 Jun 2008 13:40:20 +0200, skrev <··········@gmail.com>:
>
> > On Jun 25, 1:12 am, Javier <·······@gmail.com> wrote:
>
> >> SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
> >> times faster than Java (client), and is finally as fast as Ocaml.
>
> I might add thet while the efficiency model of C is simple to understand
> the efficiency of Lisp is notoriously difficult to understand.
I agree.
> It is easy to get performance 40x times that of C without understanding
> the reason.
And also we can get performance of 400x times slower in Lisp without
understanding the reason...
> I recomend 'dissassemble if in doubt.
> Thus I also take this claim with a grain of salt.
I think the shootout is not the complete truth, but an approximation.
It is useful.
On Jun 26, 12:13 pm, "John Thingstad" <·······@online.no> wrote:
> På Thu, 26 Jun 2008 13:40:20 +0200, skrev <··········@gmail.com>:
>
>
> I might add thet while the efficiency model of C is simple to understand
> the efficiency of Lisp is notoriously difficult to understand.
I completely disagree. Lisp contains a lot of functions that amount
to being utility libraries. If your C code uses libraries, you have
exactly the same problem of not knowing precisely how fast library
code is. If you don't use libraries, then you have vast amounts of C
code, and the total work to predict speed becomes correspondingly
vast. There's nothing about Lisp that makes it hard to understand its
performance, that doesn't exist analogously in any other language.
(And don't tell me that the big difference is garbage collection. If
you think that it's easy to predict the speed of malloc and free,
think again, and try it in a real software system.)
From: John Thingstad
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <op.udme1rqrut4oq5@pandora.alfanett.no>
P� Tue, 01 Jul 2008 14:42:22 +0200, skrev Dan Weinreb <···@alum.mit.edu>:
> On Jun 26, 12:13 pm, "John Thingstad" <·······@online.no> wrote:
>> P� Thu, 26 Jun 2008 13:40:20 +0200, skrev <··········@gmail.com>:
>>
>
>>
>> I might add thet while the efficiency model of C is simple to understand
>> the efficiency of Lisp is notoriously difficult to understand.
>
> I completely disagree. Lisp contains a lot of functions that amount
> to being utility libraries. If your C code uses libraries, you have
> exactly the same problem of not knowing precisely how fast library
> code is. If you don't use libraries, then you have vast amounts of C
> code, and the total work to predict speed becomes correspondingly
> vast. There's nothing about Lisp that makes it hard to understand its
> performance, that doesn't exist analogously in any other language.
Well I can mention a few things.
You have a function returning a integer.
Is a bigint or a fixnum?
SQRT works for complex numbers.
Thus it can be praisingly slow.
MOD returns the remaining fraction on the heap.
Thus it is 10 times slower than rem.
It is variations in type like this which make performance unpredictable.
In C++ you instantiate a template and know the type the code works with.
In Lisp is at the implementors discretion whether code is inlined or not.
Maybe it can use the type info, maybe not.
> (And don't tell me that the big difference is garbage collection. If
> you think that it's easy to predict the speed of malloc and free,
> think again, and try it in a real software system.)
This has nothing to do with it and is highly system dependent anyway.
But having more contol over what goes to the stack and what goes to the
heap does help.
--------------
John Thingstad
From: Alex Mizrahi
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <op.udmjsvawldr535@your-a80c79e8b3>
> I completely disagree. Lisp contains a lot of functions that amount
> to being utility libraries. If your C code uses libraries,
probably difference is that Lisp _encourages_ using high-level
library constructs, while C programmers are often satisfied
by bare minimum.
> (And don't tell me that the big difference is garbage collection. If
> you think that it's easy to predict the speed of malloc and free,
> think again, and try it in a real software system.)
while it might be true if overall thoroughput is measured,
in case of real-time applications response time is critical,
and malloc/free is _orders of magnitude_ more predictable
than GC in this field (while still there might be surprises with malloc,
especially with buggy/broken implementations).
to my knowledge, no modern CL implementations
implement incremental GC with response time guarantees.
or do they?
From: John Doe
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <g4i48n$2ff$1@aioe.org>
Javier wrote:
> Have you seen the shootout recently?:
>
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>
> SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
> times faster than Java (client), and is finally as fast as Ocaml.
>
> I'm pretty sure that if the SBCL team continue to work, it will become
> one of the fastest language implementation, very close to C++ itself.
> Thank you for your work!
I would love to see them spend their time on getting memory management
on Windows right an finally bring the I/O layer on par to finally see a
viable FOSS solution of Lisp on that major plattform.
Johann
From: Raymond Toy (RT/EUS)
Subject: Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
Date:
Message-ID: <sxdhcb780h2.fsf@rtp.ericsson.se>
>>>>> "John" == John Doe <········@will.no> writes:
John> Javier wrote:
>> Have you seen the shootout recently?:
>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>> SBCL is only about 0.9 times slower than C++, 0.7 slower than C, 0.2
>> times faster than Java (client), and is finally as fast as Ocaml.
>> I'm pretty sure that if the SBCL team continue to work, it will
>> become
>> one of the fastest language implementation, very close to C++ itself.
>> Thank you for your work!
John> I would love to see them spend their time on getting memory management
John> on Windows right an finally bring the I/O layer on par to finally see
John> a viable FOSS solution of Lisp on that major plattform.
Clisp, gcl, and ecl run on Windows. What makes them not a viable FOSS
Lisp?
Ray