From: Robert Harley
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c869q$ss0@news-rocq.inria.fr>
Erik Naggum <····@naggum.no> writes:
>as for speed, I'm using Allegro Common Lisp in two projects right now. the
>compiler has a switch `declared-fixnums-remains-fixnum' that gets true if
>speed > 2 and safety < 1 in the optimization settings. [...]
So you complain about how obscure this check is in C:
v += u;
if (v < u) overflow();
but you're happy with this mess to not check in Lisp:
(locally (declare (optimize (speed 3) (safety 0))) (set v (plus v u)))
!!!?!??! Ha ha ha!
>in any case, the code produced at these settings is as fast as C,
>or even faster [...]
So you found an example where it occasionally approaches the speed of C,
until suddenly the garbage collector stops everything to reclaim
unused memory that should never have been allocated in the first
place, but is so conservative that it only frees a fraction of it?
Am I right or am I right?
This thread has turned into a farce.
Let's allow it die before someone starts ad hominem flames.
Oh yeah, you already did to Dan...
Bye,
Rob.
.-. ·············@inria.fr .-.
/ \ .-. "Dances with bits" .-. / \
/ \ / \ .-. _ .-. / \ / \
/ \ / \ / \ / \ / \ / \ / \
/ \ / \ / `-' `-' \ / \ / \
\ / `-' `-' \ /
`-' Hit me with those laser beams. `-'
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3063053847634983@naggum.no>
* Robert Harley
| So you complain about how obscure this check is in C:
|
| v += u;
| if (v < u) overflow();
|
| but you're happy with this mess to not check in Lisp:
|
| (locally (declare (optimize (speed 3) (safety 0))) (set v (plus v u)))
|
| !!!?!??! Ha ha ha!
thank you. I needed that.
Common Lisp programmers write macros that do these things for them. this
is another important point you missed about the lack of abilities in C.
| So you found an example where it occasionally approaches the speed of C,
| until suddenly the garbage collector stops everything to reclaim unused
| memory that should never have been allocated in the first place, but is
| so conservative that it only frees a fraction of it? Am I right or am I
| right?
you're wrong, and you're being silly, now, instead of witty, like above.
| This thread has turned into a farce.
yeah, funny how it just did, isn't it?
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
From: Peter da Silva
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c96sp$k21@web.nmti.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> | v += u;
> | if (v < u) overflow();
> Common Lisp programmers write macros that do these things for them. this
> is another important point you missed about the lack of abilities in C.
#define CHKADD(v,u) (((v)+=(u) < (u)) || overflow())
--
The Reverend Peter da Silva, ULC, COQO, BOFH.
Har du kramat din varg, idag? `-_-'
From: David H. Thornley
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cb0aa$794@epx.cis.umn.edu>
In article <··········@web.nmti.com>, Peter da Silva <·····@nmti.com> wrote:
>In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>> | v += u;
>> | if (v < u) overflow();
>
>> Common Lisp programmers write macros that do these things for them. this
>> is another important point you missed about the lack of abilities in C.
>
>#define CHKADD(v,u) (((v)+=(u) < (u)) || overflow())
Nice try, but there are several problems with this.
First, it only works with unsigned integral types, since those are the
only ones with any sort of defined behavior on overflow. To make this
work with signed integers, you have to cast to unsigned, perform the
operation, and then test to see if unsigned overflow occurred or whether
overflow would have occurred on the signed addition.
Second, this works as a statement, not as an embedded expression, and
so doesn't preserve the semantics. The value of v += u is v; the value
of CHKADD(v,u) is 1 (provided it doesn't overflow). While you can,
certainly, conduct arithmetic statement by statement, it seems like
you're throwing away much of what made FORTRAN popular in the first place.
Third, the macro can evaluate u twice, so u had better not be an
expression with side-effects.
Fourth, this works for addition. For multiplication, you'll need another
macro to divide the maximum unsigned integer (of the appropriate type)
by one of the operands to see if overflow occurs. I *don't* think you
can get this one to work without multiply evaluating operands.
I'm not perfect, so I'll concede that you might be able to come up
with macros that do the necessary checking without the above problems.
They'll be ugly, of course. (It would be easier and prettier in C++.)
After doing all of this work, you'll be able to write either efficient
and unchecked or inefficient and checked code in C or C++.
In Common Lisp, you can already write inefficient and checked code,
with the added advantage that you can check for overflow whenever you
feel the need, not after each operation (is this integer a fixnum or
a bignum?). If you want to write unchecked and efficient code, I'll
guarantee you that writing something that starts (defmacro
with-blazing-speed (... is going to be a lot easier than writing
the above in C++, let alone C.
I know that there are C implementations that can provide overflow
protection, but I doubt whether there's as many of them as there
are good implementations of Common Lisp. Unless you've got one
of them, it's far easier to get the right answer in Lisp, and
much easier to get the fast answer in Lisp than the right answer
in C (when they conflict).
Lisp programmers are possibly not concerned enough with efficiency
(although that's one of the themes of Norvig's book), but C and C++
programmers are probably overconcerned with efficiency.
--
David H. Thornley, known to the Wise as ········@cs.umn.edu O-
Disclaimer: These are not the opinions of the University of Minnesota,
its Regents, faculty, staff, students, or squirrels.
Datclaimer: Well, maybe the squirrels. They're pretty smart.
David H. Thornley <········@cs.umn.edu> wrote:
> this works as a statement, not as an embedded expression,
[ ... ]
> the macro can evaluate u twice,
Apparently you're unaware that C programmers use lowercase for macros
that simulate functions, uppercase for macros that don't.
> inefficient
Even with a naive compiler it's only one extra instruction.
---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
···@koobera.math.uic.edu (D. J. Bernstein) wrote:
>David H. Thornley <········@cs.umn.edu> wrote:
>> this works as a statement, not as an embedded expression,
> [ ... ]
>> the macro can evaluate u twice,
>
>Apparently you're unaware that C programmers use lowercase for macros
>that simulate functions, uppercase for macros that don't.
That's fascinating, because many C programmers fall into exactly the
trap he mentioned with writing MIN() or MAX() macros. Maybe they
forgot?
RSR
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://www.wam.umd.edu/~rsrodger
please discontinue use of ···@msn.com
Robert Rodgers <········@wam.umd.edu> wrote:
> That's fascinating, because many C programmers fall into exactly the
> trap he mentioned with writing MIN() or MAX() macros.
The convention is that you can write
#define MAX(a,b) ((a) < (b) ? (b) : (a))
because MAX, being uppercase, doesn't have to simulate a function. If
someone writes
c = MAX(a++,b);
then he's making the mistake. If, on the other hand, you had written
#define max(a,b) ((a) < (b) ? (b) : (a))
then callers would be entirely justified in writing
c = max(a++,b);
and it'd be your fault that the code doesn't work.
---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
In article <·······················@koobera.math.uic.edu>
···@koobera.math.uic.edu "D. J. Bernstein" writes:
> David H. Thornley <········@cs.umn.edu> wrote:
> > this works as a statement, not as an embedded expression,
> [ ... ]
> > the macro can evaluate u twice,
>
> Apparently you're unaware that C programmers use lowercase for macros
> that simulate functions, uppercase for macros that don't.
This is not only irrelevant, as conventions don't stop a macro
from evaluation an argument more than once, but it isn't even
a universal convention. Not everyone uses upper case for function
names.
A side effect is is a side effect, and quite possibly a bug, too.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Developer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
From: Vassili Bykov
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32E98B51.1EBF34B@cam.org>
Peter da Silva wrote:
> In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> [...]
> > Common Lisp programmers write macros that do these things for them. this
> > is another important point you missed about the lack of abilities in C.
>
> #define CHKADD(v,u) (((v)+=(u) < (u)) || overflow())
a = CHKADD(b, c++); /* Oops! */
--Vassili
In article <··········@web.nmti.com>, ·····@nmti.com (Peter da Silva) wrote:
> In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> > | v += u;
> > | if (v < u) overflow();
>
> > Common Lisp programmers write macros that do these things for them. this
> > is another important point you missed about the lack of abilities in C.
>
> #define CHKADD(v,u) (((v)+=(u) < (u)) || overflow())
This is one of these macros, where u (whatever expression it is)
may be evaluated twice. Which may go wrong. For example if
this is not an atomic instruction.
--
http://www.lavielle.com/~joswig/
Rainer Joswig wrote:
> > #define CHKADD(v,u) (((v)+=(u) < (u)) || overflow())
>
> This is one of these macros, where u (whatever expression it is)
> may be evaluated twice. Which may go wrong. For example if
> this is not an atomic instruction.
C IMHO has either too few internal types or it doesn't allow to add
types easy enough. It's a 90% language: it fits 90% of the needs of 90%
of the users well enough. There are enough lanuages out there that
either have all the internal types you want to (Ada), that allow to add
them in case (C++, Ada), or don't have the problem with this concept at
all (e.g. Forth - + is just a function on two cells, add check+, another
function on two cells on the stack, something like
: check+ ( u v -- r )
over + tuck u< abort" overflow" ;
).
Overall, I as programmer want the control what happens in case of an
overflow. I often really use mod 2^32 values, and I know how to do it
(e.g. you compare with (a-b)<0). I would go mad with a programming
language that thinks it must abort or jump to the error handler. The
variable names of C certainly are missleading, they are signed and
unsigned "cell", not "int".
Languages are tools. Nothing more. Choose your tool as appropriate for
the case. If you find none, choose a language that is appropriate to
create new tools. These languages are rarely mainstream, as rarely, as
hammer and chimney are viewed as convenient tools (except perhaps for
making horse shoes). So they are niche languages. Forth is used in
embedded control, Lisp in AI. Neither needs a lot of man power behind
it, especially, since these tools make the programmers that know how to
use them very productive.
--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/
From: Richard Tobin
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <E4q4w2.CJ3@cogsci.ed.ac.uk>
In article <··········@web.nmti.com> ·····@nmti.com (Peter da Silva) writes:
>#define CHKADD(v,u) (((v)+=(u) < (u)) || overflow())
Oh come on, Peter, you know that C's macros are annoyingly limited.
Suppose you wanted this macro to only evaluate u once? C's macro
language gives the impression of being designed to be just powerful
enough to implement getchar(), but no more.
Inline functions sometimes do the trick, but there are plenty of cases
where you just can't do what you want with either macros or functions,
especially in the cases where you are effectively "extending the
language" to overcome problems like C's second-class arrays.
-- Richard
--
"The Socialists had many branches in America, and the deceased had no
doubt infringed their unwritten laws" - A Study in Scarlet
From: Mike McDonald
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c914e$bqh@fido.asd.sgi.com>
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> writes:
> * Robert Harley
>| So you complain about how obscure this check is in C:
Let's see,
v = -1;
u = 1;
>| v += u;
>| if (v < u) overflow();
Whoops! I've got overflow. Dang, I've been getting overflows all these years
and never knew it. :-)
Mike McDonald
·······@engr.sgi.com
From: Bruce Hoult
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <2937034375@hoult.actrix.gen.nz>
·······@engr.sgi.com (Mike McDonald) writes:
> In article <················@naggum.no>,
> Erik Naggum <····@naggum.no> writes:
> > * Robert Harley
> >| So you complain about how obscure this check is in C:
>
> Let's see,
>
> v = -1;
> u = 1;
>
> >| v += u;
> >| if (v < u) overflow();
>
> Whoops! I've got overflow. Dang, I've been getting overflows all these years
> and never knew it. :-)
That was a correct test for unsigned integers. If you want to test for overflow
of signed integers then you use something like:
t = v + u;
if ((v^u | t^u) >= 0) overflow();
-- Bruce
--
...in 1996, software marketers wore out a record 31,296 copies of Roget's
Thesaurus searching for synonyms to the word "coffee" ...
From: Steven Huang
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5cigod$5mi@hnssysb.hns.com>
In article <··········@fido.asd.sgi.com> ·······@engr.sgi.com (Mike McDonald) writes:
>> * Robert Harley
>>| So you complain about how obscure this check is in C:
> Let's see,
> v = -1;
> u = 1;
>>| v += u;
>>| if (v < u) overflow();
> Whoops! I've got overflow. Dang, I've been getting overflows all these
>years and never knew it. :-)
Perhaps because you missed the fact that u and v were declared as
unsigned longs in preceding postings.
From: Jose Paredes
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32ECE98C.3F54@vnet.ibm.com>
Okay, so some of us like C and some of us like LISP. We each have our
own reasons and experiences to back up our decision. Can we please,
please stop posting about it? I hate to "kill" a certain thread because
I feel that sometimes I might miss something that makes me a little
wiser, but I also hate the way this thread has gone. This is basically a
"na na na nanana, my language is better than yours" thread and is
begging to get a little sickening.
No one, of course, has to stop posting, but please drop it. The whole
newsgroup is getting cluttered up with this.
What I have learned from this newsgroup is that C programmers are
going to program in C and that LISP programmers are going to program in
LISP. That's all. Nothing else.
THankyouverymuch,
Jose
Jose Paredes <········@vnet.ibm.com> writes:
>
> Okay, so some of us like C and some of us like LISP. We each have our
> own reasons and experiences to back up our decision. Can we please,
> please stop posting about it? I hate to "kill" a certain thread because
> I feel that sometimes I might miss something that makes me a little
> wiser, but I also hate the way this thread has gone. This is basically a
> "na na na nanana, my language is better than yours" thread and is
> begging to get a little sickening.
> No one, of course, has to stop posting, but please drop it. The whole
> newsgroup is getting cluttered up with this.
> What I have learned from this newsgroup is that C programmers are
> going to program in C and that LISP programmers are going to program in
> LISP. That's all. Nothing else.
>
> THankyouverymuch,
> Jose
It is not so bad, actually. Before I followed flamewar just like this
I had no idea that numerical code in Lisp may be as efficient as in C
and that Lisp can do a lot of other thing I never suspected before.
There are probably a lot of lurkers that will learn some new things
about Lisp that they would never learn otherwise and give it a try.
Of course it would help if exchange would be less emotional.
In article <··············@spot.uchicago.edu>, Alexey Goldin
<······@spot.uchicago.edu> wrote:
> It is not so bad, actually. Before I followed flamewar just like this
> I had no idea that numerical code in Lisp may be as efficient as in C
It can be. Sometimes. But Common Lisp atleast tries to be faster than, say,
Smalltalk. Few would try to do image processing in pure
Smalltalk. In CL (given a good compiler) it is atleast not
completely impossible. CL has a lot of numerical datatypes and you
can provide compiler hints for inlining, stack allocation,
type declarations, compilation strategy (alues from 0 upto 3 for
speed, compilation speed, safety, space and debug), ...
Common Lisp is being used a lot for math software (statistics,
symbolic algrebra, ...). Many application areas of CL actually
use quite a lot of mathematics (neural networks, statistics in AI,
image processing, CAD systems, 3d modelling and rendering, ...).
There is even work in sophisticated sound synthesis in CL.
In this case they never tried to write fast CL code
for generating and manipulating sounds (acoustic modelling,
3d room effects, and similar stuff), but they compile
this to some external code (signal processor code, C, ...)
and use from Lisp.
In Macintosh Common Lisp there once has been few support for fast floating
point computation on the Motorola 68k platform (this has
changed with the PowerPC compiler). So what did people do?
They wrote a package where you can generate the code
for the floating point processor directly from Lisp.
I saw a package where one has written some code
for *simple* 3d graphics - and it was fast. You wouldn't
believe that this could be written in Lisp.
> and that Lisp can do a lot of other thing I never suspected before.
> There are probably a lot of lurkers that will learn some new things
> about Lisp that they would never learn otherwise and give it a try.
Sure.
> Of course it would help if exchange would be less emotional.
;-)
Rainer Joswig
--
http://www.lavielle.com/~joswig/
In article <··········@news-rocq.inria.fr> ······@pauillac.inria.fr (Robert Harley) writes:
>So you complain about how obscure this check is in C:
>
> v += u;
> if (v < u) overflow();
>
>but you're happy with this mess to not check in Lisp:
>
> (locally (declare (optimize (speed 3) (safety 0))) (set v (plus v u)))
>
>!!!?!??! Ha ha ha!
(locally (declare (optimize (speed 3) (safety 0)))
(set v (plus v u))
...
100 Kloc later
...
(values 'Haha))
--
--
Patric Jonsson,·······@nada.kth.se;"always mount a scratch monkey"-jargon-file.