I have added two new routines in List:

/////////////////////////
#import <flx.flxh>
open List;

var x = list(1,2,3);
var y = list(4,5,6);
splice(&x,y);
println q"x=$(x)";
rev (&x);
println q"x=$(x)";
///////////////////////

splice appends the second list to the first one.
rev reverse a list in place.

Both require a pointer to a variable containing the list
which is being modified as the first argument.

Both these routines are DANGEROUS because they modify what
are traditionally immutable values (namely, lists).

I will be adding some more of them though. Sometime mutation
is safe. In particular the current implementation of List::join
is ridiculously inefficient because

        (a) it is not tail recursive
        (b) Felix is unable to eliminate any closures

The second point is, independently, a rather serious bug:
the optimiser is supposed to eliminate closures, especially
those which are generated, and especially those created by
functions written in "Haskell"ish form, i.e. functions like

        fun f(x:int) (y:int) (z:int)=> x + y + z;

should generate the same code as

        fun f(x:int, y:int, z:int)=> x + y + z;

provided both are called with all arguments. In particular,
routines like 'fold_left' should generate trivial loops.

Non-tail-recursive functions almost always use closures,
however there should only be a single closure around the
recursion -- intermediate calls in the cycle should still
be inlined. And functional VALUES passed to routines
should be inlined! However this is hard for cases like:

        fun f(g:a->b, c) => k ( g c, f g ( g c))

where the 'argument' is propagated to recursion. I need to 
think about how to recognize that an f specialised to a particular
g by inlining, when making a recursive call to the old f with
the same g, can call the specialised f (without passing the g,
since it is inlined into the specialised f).

Non trivial (especially if the functions are polymorphic ..)

The main problem as usual is probably the way 'cloning/reparenting'
is done.. this seems unique to Felix.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to