Re: dynamic vs. static: the age-old debate

On Sat, Aug 19, 2006 at 04:08:32PM +1000, cr88192 wrote:

"Robbert Haarman" <comp.lang.misc@xxxxxxxxxxxxx> wrote in message
news:20060819042225.GW8894@xxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sat, Aug 19, 2006 at 01:23:19PM +1000, cr88192 wrote:

"Curtis W" <cwarren89@xxxxxxxxx> wrote in message
news:1155937717.842798.228720@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(To those of you who might be curious: I used to be a soft typing
supporter, until I realized there's no reason not to just use dynamic
typing.)


What do you mean?

I can think of one:
the coder can explicitly limit what types of values allowed where, and
get
the compiler to complain about it.

add(x, y)x+y;

will add any 2 items for which '+' is defined.

int add(int x, int y)x+y;

It can indeed be useful for a language to allow this, but it's
orthogonal to static/dynamic/soft typing.


it seems I am not sure what you mean...

I mean it can be useful for a language to allow type annotations to be
included or omitted, but this is independent from the language being
statically, dynamically, or softly typed. Given one of the above
definitions, and a function call add("foo", 12), you could get:

# Static typing
$ static-compiler program.source -o program
Error: add(string, int) not defined
$ ./program
no such file or directory: ./program

# Dynamic typing
$ dynamic-compiler program.source -o program
$ ./program
Error: add(string, int) not defined

# Soft typing
$ soft-compiler program.source -o program
Warning: add(string, int) not defined
$ ./program
Error: add(string, int) not defined

sadly as it is, there is no real way to verify in many cases if 'int+int'
will overflow, leaving the (imo crude) "overflow behavior is undefined"
semantics...

It depends. All CPUs I've written assembly code for had the ability to
detect and report integer overflow. Many languages detect overflow and
silently convert fixnums to bignums when it occurs. IIRC, Java has clear
specifications about the size of data types and the range of values they
can represent. So, actually, you can get predictable overflow, detect
overflow, and have well-defined behavior in case it occurs.


but defining/handling these cases is often more expensive than not...

True. But then, it can also be that your program produces incorrect
results if you don't detect and handle integer overflow. Take your pick:
a program that runs incredibly fast, but produces incorrect results, or
a program that runs somewhat slower, but produces correct ones.

my problems are:
int in my language does not increase its size (it is, whatever will fit in a
fixnum);
long, however, will upgrade to a larger size (a 64 bit heap integer), and
then possibly to bignum.

Well, then that's your specification, and your users will have to deal
with it. Or use a different language, of course.

int+int is defined to return int, but there is no proof it wont overflow.
long, however, is more expensive than int, and thus to be avoided.

Depends. If you want correct results, and you don't know that your
values will fit in an int (whose range you don't know), you'd better use
long.

would be nice if my ints were the same size as C, but they are not, so I
leave the rest of the definition generally undefined (in practice, they will
overflow, but I don't define this exactly...).

It's ok to leave things undefined sometimes. Lots of people won't care
that their ints can overflow, and many won't care if ints are 29-bits,
31-bits, or 48-bits, either. Alternatively, since you know your ints are
29-bits, you could include that in the spec, and leave only the result
of an operation that causes integer overflow undefined. Or you could
actually detect and handle it; really, detecting integer overflow
shouldn't be all that expensive, and it _should_ occur rarely enough
that the cost of handling it doesn't have a huge impact on performance.

Regards,

Bob

---
Those who do not study history are doomed to repeat it

Yes, and those who do study history are doomed to watch in frustration
as it is unwittingly repeated by those who do not :-)

-- jonadab on Slashdot



.

Relevant Pages

  • Re: dynamic vs. static: the age-old debate
    ... int addx+y; ... orthogonal to static/dynamic/soft typing. ... $ dynamic-compiler program.source -o program ... will overflow, leaving the "overflow behavior is ...
    (comp.lang.misc)
  • Re: Python less error-prone than Java
    ... overflow exception was raised when the int got too big. ... been that way, typing or no typing. ... Actually, the docs are obsolete on this point, and an int becomes a long ...
    (comp.lang.python)
  • Re: size_t overflow
    ... than overflow. ... question is about size_t arithmetics. ... means all computations involving unsigned char promoted to int, ... After promotion to int, ...
    (comp.std.c)
  • Re: size_t overflow
    ... than overflow. ... question is about size_t arithmetics. ... ..."A computation involving unsigned operands can never overflow, ... means all computations involving unsigned char promoted to int, ...
    (comp.std.c)
  • ishopcart cgi 0day and multiple vulnerabilities
    ... While spending a night auditing I have found 2 buffer overflows and 1 ... there is an overflow in the vGetPostfunction, it does not do any size checking on the inputed data but instead ... void changeport(char *code, int port, int offset); ...
    (Bugtraq)
Loading