Re: lang effort: type conversions
- From: "Aaron Gray" <ang.usenet@xxxxxxxxx>
- Date: Fri, 30 Jun 2006 16:45:30 +0100
if anyone cares (or wants to make comment), after working some more of the
inferencer for the lang I am implementing, I have started to consider some
rules.
in its basic semantics, the lang will be dynamically typed with a
prototype object system, however, the lang will also have the ability to
define static types and use them for basic optimizations.
at this point in time, a lot of type violations aren't caught, and those
that are often only generate warnings. this may change eventually (it is
still the first month of implementation).
the basic syntax is more or less c style, and similar goes for
declarations:
int x;
int fib(int x)if(x>2)fib(x-1)+fib(x-2) else 1;
there will also the variant type ('var'), which may take any other type,
and will not have many of the same restrictions as the other types.
Yes I have came to the same idea of using a variant type with either
explicit declaration or invisible syntatic sugar like you are in functions.
in the case of functions, types may be ommited:
fact(x)if(x>1)x*fact(x-1) else 1;
in which case, variant will be assumed (unless the inferencer thinks
otherwise).
in the case of variables, a type is still required so that the parser is
sure that it is a definition, eg:
var x;
all types are implemented as tagged references.
most casts will be implicit, but an explicit cast may be written as the
type name followed by an expression:
(long 3)/4.
numerical types:
for numbers, the following types are viewed as primitive:
int, represented as a fixnum, with 29 bit precision, 28 unsigned;
Why, what are the extra bits for ?
If you wish to interface to FFI code which I believe you do then what are
you going to do there ?
long, either a fixnum or an on-heap object, with undefined precision (for
now, 64 bit, but maybe bignums may also exist);
float, as with fixnums, it is in-place with reduced precision;
double, on heap with full precision;
rat, rational, fixnum (if integral), or on heap (if needed).
other numeric types (eg: complex) will typically be heap-based, and will
have more generic rules (and are more resigned to being slower).
basic ops division integer division
int+int->int, int/int->float, int\int->int
long+long->long, long/long->double, long\long->long
long+int->long, long/int->double, long\int->long
rat+rat->rat rat/rat->rat undefined...
rat+int->rat, rat/int->rat
rat+long->rat, rat/long->rat
float+float->float
double+double->double
double+float->double
float+rat->double
...
variants will work slightly different wrt integer values:
all operations will use the smallest, sufficiently large numerical type,
and will promote types as needed (wheras int will generally allow them to
overflow). likewise, int/int->int if int%int=0.
I would suggest not doing that and have a "function" that "normalizes"
values down to the minimum representation size required. Much better to have
this explicit and under control of the programmer for maths reasons and also
for execution speed of maths.
I am also considering seperating the variable and function namespaces.
function calls will work by first checking the function namespace, then
the variable one (if no functions are declared by that name in the current
scope).
declared functions will be immutable. mutable functions are possible, but
will need to be declared like variables.
example:
fact(x)if(x>1)x*fact(x-1) else 1;
will declare an immutable function, however:
var fact=fun r(x)if(x>1)x*r(x-1) else 1;
will declare a mutable one.
also for declared functions, this may be restricted further:
declared functions may not be used in the creation of new objects at all;
it will only be possible to use these functions in a new object via either
delegation or cloning.
why ? Are your functions pure ?
note that in the case of delegation, it will be allowed to overload the
functions with new ones (if they have matching function definitions).
overload or replace ?
these restrictions will not apply to first-class functions.
note, however, for other reasons closures may not be allowed as methods
(first-class functions and closures are distinguished based on whether or
not they capture variables from the parent scope).
why ?
casts, conversions, and coercions, implicit and explicit.
I am working on producing a sound system of them as side task at the moment.
I had a model years ago but cannot remember it or find the documentation,
may be I'll go and look harder.
Aaron
.
- References:
- lang effort: type conversions
- From: cr88192
- lang effort: type conversions
- Prev by Date: Re: RAD vs. performance
- Next by Date: Re: RAD vs. performance
- Previous by thread: lang effort: type conversions
- Next by thread: Re: lang effort: type conversions
- Index(es):
Relevant Pages
|
