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


"Robbert Haarman" <comp.lang.misc@xxxxxxxxxxxxx> wrote in message
news:20060819090141.GX8894@xxxxxxxxxxxxxxxxxxxxxxxxxxx
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

yes, ok.


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.

well, another point is that, declaring a type as 'int' basically means "this
value will fit in an integer".

types like long, or variant (which may both still use fixnums as the general
representation), will in fact detect this overflow and promote the type
automatically.

the big thing is, declaring it 'int' also means declaring it fixnum, and
thus one is bound by the size of fixnum.

more or less, nearly the sole purpose of 'int' is speed (by ommiting futher
typechecks).
the fact is, the number will overflow, and the vm wont care. it is just lame
that it is 29 bits and not 32, which means that it does not match up exactly
with C's int.


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.


variant is the other option (the default type), which will convert freely as
needed...
I just need fixed rules for the sake of the inferencer.

I had considered other types (eg: byte, sbyte, short, ushort, and uint),
which would be like int but implicitly mask or sign extend. I didn't fully
implement them though (in bytecode such types would neccisarily be
slower...).

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.

yes, or variant...

int is intended for the really common case of loops and similar, where it is
known the value wont be all that large. also, being a long time C coder,
such restrictions are nothing major (it is just sad that, since I don't know
the size, overflow can't be utilized the same way it is often used in C...).

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.


yes, I had considered defining it.
then again, I had also considered merging 2 types and giving myself 30 bit
fixnums instead...

I have also considered standardizing on a 32 bit tagged value type, even for
64 bit archs, under the thought that in the 64 bit case (or maybe just
eventually), they wont encode an address but an index into the heap.

this would actually make some operations (eg: reference counting) a little
cheaper (albeit getting the pointer to an object on-heap would be slightly
more expensive).

it is a cost difference along the lines of replacing: (a&(~7)) with:
(arr[a>>19]+((a>>2)&0x1FFFE)).

however, on the side of ref counting (done eaqualy as much or more), it will
save several checks and possibly a loop...

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: 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)
  • 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 undefined" ...
    (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)
Loading