>
>> And wouldn't you end up defining pretty much one record type per
>> procedure? (not the case in Lua, as tables are weakly dynamically
>> "typed").
>
>This is not a problem if mostly-structural typing is used, which is
>the case for BitC AFAICT (see section 3.10.2 in the spec).
I'd been wondering about copy compatibility, so I checked out that
section. If I understand right, this means any type is compatible
(leaving aside mutability) with any other of equivalent structure. But
what if you don't want that at even a trivial level? An earlier post
by Eric Rannaud gave this example:
set-size :: (box: Box, width: int, height: int) -> void
set-size box: b width: w height: h
set-size b h w // wrong, but hard to catch
but I'd argue that this may be wrong, typewise. If you can't add widths
and heights then arguably width and height types above should not be
compatible and should not have been declared as ints. Instead perhaps
set-size :: (box: Box, width: t_width, height: t_height) -> void
set-size box: b width: t_width height: t_height
set-size b h w // wrong, and caught statically
where t_width & t_height are just integers under the skin.
Delphi (a dialect of object pascal) allowed you to do that with an
little-known extension:
type TWidth = type integer;
type THeight = type integer;
which given
var w: TWidth, h: THeight;
would allow literal assignments but not otherwise:
w := 23; // ok
h := w; // nope, compile error
I'd never used this in my work but I pushed for it in a larger project
(didn't happen...).
The delphi restriction may not be strong enough in general, but it
could tie things down a little more firmly. Can similar be done in
BitC? Should it be?
jan
>_______________________________________________
>bitc-dev mailing list
>[email protected]
>http://www.coyotos.org/mailman/listinfo/bitc-dev
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
