On Thu, 2006-01-12 at 17:17 +0100, Nicolas Cannasse wrote:
Off list...
> Luzifer Altenberg wrote:
> > Hallo
> >
> > localhost:~/neko undo$ nekoc
> > 1 data_pos -1337393152 (before if( neko_is_big_endian() )
> > 2 data_pos -80 (after if( neko_is_big_endian() )
> > Uncaught exception - [EMAIL PROTECTED]
>
> Could you update and try again ? I changed data_pos to unsigned, that
> might be a good reason with the byte reverse is failing (unless I made
> another mistake there).
BTW: this kind of problem is fairly common with cross platform
stuff using C. I'm curious about your experience here,
and what things in a *programming language* would fix it.
I ask because of Felix of course: it wraps C/C++ and
allows considerable end user control over typing.
The original version was fully strict, for example
a function
fun f(x:uint16)
would only accept precisely a 16 bit unsigned int
argument. Also the types for 'int' 'long' etc were
distinct from 'int16' 'int32' 'int64' etc.
However I think the result was counter productive,
and it made wrapping existing C very difficult.
Too many times, you had the wrong type and had to
explicitly cast it. The idea of course WAS to force
an explicit, visible, cast .. but having to cast
many arguments of many functions just clutters the code,
and the programmer just does the casts without thinking
to make the typing correct .. instead of thinking about
the design.
I have not reverted the strict typing rules, however
I have enriched the type system and library. There
is now an optional module which can be opened
which has overloads for mixed mode integer arithmetic,
so you can write
1 + 2L
for example. In addition, I introduced constrained
genericity, so you can write:
fun add[t1: integer, t2: integer] (x:t1, y:t2) :
integral_promotion(t1,t2)
= "$1+$2";
which write a polymorphic function with constraints
that can add any two integer types, C style (this saves
on writing out all the implied overloads by hand).
The notation
t1: integer
says t1 is one of the types in the set 'integer' which
is defined elsewhere as {int,long,...} etc.
The library has also been changed so int16 etc are
aliases for int, long etc (as in C) rather than
distinct types.
So .. I have quite a lot of tools to control the typing.
I just don't know what model to build.
For example: one of my rules is that you can use | ^ and &
only on unsigned types, which can represent integers or
bitstrings, whereas a signed integer is just an integer
and you must cast to an unsigned type to do bitwise operations.
Anyhow my question is, in the light of the mistakes you've
made and difficulties you've had, what, if anything, in
the typing would have helped avoid them?
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
--
Neko : One VM to run them all (http://nekovm.org)
