comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Overflows (lisp fixnum-bignum conversion)
Date: 1997/04/05
Date: 1997-04-05T00:00:00+00:00	[thread overview]
Message-ID: <dewar.860257082@merv> (raw)
In-Reply-To: Pine.SUN.3.96.970405054237.22894A-100000@eskimo.com


Robert Duff said

<<> Analogy: Suppose you write a signed integer expression that overflows.
> In C, you get unpredictable results (exactly what Ada calls erroneous).
> In Ada, you get a run-time error.  In Lisp, you get the right answer.
> It seems to me that, as far as preventing bugs goes, with respect to
> this particular issue, C is worst, Ada is better (because it detects the
> error), and Lisp is better still (because it prevents the error).>>

I find this too facile. The trouble is that better means better according
to some metric. What are you interested in?

More flexibility
More efficiency
More simplicity
...


Sure, it is more convenient for a programmer if all integers have unlimited
length, including array subscripts, but there is a real cost for this (if
I remember, even in LISP standard arrays do not allow bignums as subscripts).
If you are interested in expressive power, and do not care about efficiency,
then Ada is not the apprropriate language level (neither is C++ or Java).
LISP is getting somewhere closer to where you want to be, but in general
you want to take a better look at very high level languages like SETL
(In SETL *all* integers, including those used for subscripts, are unlimited
in size, and indeed general mappings mean that you can do arbitrary things
with the equivalent of arrays like:

    a (1) := 0;
    a (1000000000000000000000000000000000000000000000000) := 0;

and it works fine -- BUT slowly! You pay a price for this kind of
flexibility. I often find that I can write things in SPITBOL (a
dialect of SNOBOL-4) in a fraction of the time that it would take
in a language like C++ or Ada. But I do not expect to use SPITBOL
for writing high efficiency general purpose code.

Someone who is interested in efficiency to the exclusion of any other
consideration may consider C to be the best language with respect to
overflow handling, since neither the language nor the compiler is
burdened by "useless" overflow checks.

In practice language design is a series of compromises, and we choose
different places on the scale depending on our purpose. In Ada we make
a concious decision to give up a small amount of efficiency in the
interests of safety, and Java makes a similar decision.

That's why arguing that one language is better than another is always
a confusing activity, where lack of communication is common!





  reply	other threads:[~1997-04-05  0:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-04-02  0:00 What Happened While I Wasn't Looking? Charles H. Sampson
1997-04-03  0:00 ` Robert A Duff
1997-04-03  0:00   ` Robert Dewar
1997-04-03  0:00   ` Robert Dewar
1997-04-05  0:00   ` Nick Roberts
1997-04-05  0:00   ` Overflows (lisp fixnum-bignum conversion) Clayton Weaver
1997-04-05  0:00     ` Robert Dewar [this message]
1997-04-08  0:00       ` Robert A Duff
1997-04-09  0:00         ` Charles H. Sampson
1997-04-06  0:00     ` Robert A Duff
1997-04-06  0:00       ` Nick Roberts
1997-04-07  0:00         ` Robert A Duff
1997-04-07  0:00           ` Robert Dewar
1997-04-07  0:00             ` Larry Kilgallen
1997-04-07  0:00               ` Nick Roberts
1997-04-07  0:00                 ` Robert Dewar
1997-04-07  0:00               ` Robert Dewar
1997-04-09  0:00                 ` Robert A Duff
1997-04-09  0:00               ` Joel VanLaven
1997-04-12  0:00                 ` Architectures Nick Roberts
1997-04-07  0:00   ` What Happened While I Wasn't Looking? Charles H. Sampson
1997-04-07  0:00   ` Charles H. Sampson
1997-04-09  0:00     ` Robert A Duff
1997-04-08  0:00 ` Overflows (lisp fixnum-bignum conversion) Jon S Anthony
  -- strict thread matches above, loose matches on Subject: below --
1997-04-08  0:00 Marin David Condic, 561.796.8997, M/S 731-93
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox