On Mon, 2006-07-10 at 18:16 -0700, Erick Tryzelaar wrote:
> skaller wrote:
> >> language:
> >> 1.2: olabl-like labels/keywords
> >>
> >
> > We have named fields, the syntax is just messy:
> >
> > f struct { x = 1; y = 2; }
> >
> > works now, provided f is written to accept a suitable recor
skaller wrote:
>> language:
>> 1.2: olabl-like labels/keywords
>>
>
> We have named fields, the syntax is just messy:
>
> f struct { x = 1; y = 2; }
>
> works now, provided f is written to accept a suitable record type.
>
>
Err, I meant adding sugar for label support :)
>> 1.3: multi
On Mon, 2006-07-10 at 11:51 -0400, Stephane Le Dorze wrote:
> As I told before; I am considering using Felix as a high level
> programming language in Video Game.
>
> My preferred choice as: “The next video game mainstream programming
> language”.
>
> Video games are a real time application and c
As I told before; I am considering using Felix as a
high level programming language in Video Game.
My preferred choice as: “The next video game mainstream
programming language”.
Video games are a real time application and cannot suffer
the “stop the world” side effect of garbage collectio
On Mon, 2006-07-10 at 00:59 -0700, Erick Tryzelaar wrote:
[]
Erick, I just looked at your 'slow' program: it turns
out all the time is being taken in the inliner NOT in
the lookup module.
The problem is basically this: when a function is inlined,
all its children have to be copied and reparented
#import
open Debug;
print "Hi!"; endl;
noinline fun d()= {
var x = FLX_SRCLOC;
var cf = CPP_FILE;
var cl = CPP_LINE;
var f = filename x;
var sl = startline x;
var sc = startcol x;
var el = endline x;
var ec = endcol x;
return cf,cl,f,sl,sc,el,ec;
}
cf,cl,f,sl,sc,el,ec := d();
p
On Mon, 2006-07-10 at 00:59 -0700, Erick Tryzelaar wrote:
> bug fixes:
> 1.1.3: cache the binding of every sub-expression and type to make lookup
> linear
This can be done, but it is rather tricky. It makes the AST dependent
on bound terms, since they have to be mentioned. It also means
either c
Hola,
Since I think we're getting pretty close to a 1.1.2 release (and John is
getting antsy to implement new things it seems :)), I think it might be
a good idea to start planning what we want in the next, and future
releases. Here's some of my ideas. What do you guys think?
bug fixes:
1.1.3:
