On 02/03/2014, at 9:23 AM, srean wrote:
> A major advantage of this is that it will get srean off my back a bit :)
>
> I trust you to do the right thing rather than listen to me. fthreads are
> still unchartered territory for me. I am still struggling with functions,
> generators and procedures :)
You need to get over that and just get on with it :)
> Quick question: when is 'var' required in the for loop syntax. I see
> sometimes it is used sometimes it is not. Could this be unified ?
You use var, as always, to declare the variable. If it's already declared you
can't re-declare it. If it's not you must.
var i:int;
for i in .... // netter not redeclare i
for var j in .. // declares j
>
> then k will be set to the value of i at the time of the spawn,
> not 9 as it used to be (because i was 9 at the end of the loop
> before any of the fthreads started running).
>
> Wait, for loop bounds arent "inclusive" anymore ?
Sure, 0 upto 9 runs 0 1 2 .. 9 then stops.
The last value is 9. Felix doesn't allow "one past the end".
The terminating condition is an equality. The test MUST be
done prior to the increment, because the increment
might be invalid.
> So now you can use the rule: if you want the current value of a variable
> copy it up into the fthread.
>
> that seems like somewhat heavy machinery to ensure this property.
The machinery ensures nothing. You do.
> [Closures still won't behave themselves though :]
>
> Is this the only tricky case: I form a closure over a var and then change the
> var ?
A var is like a ref cell in Ocaml sometimes. Its an address of a storage slot.
So it takes on the value of whatever is stored there.
When you have indeterminate timing for computations its not quite
so easy to know exactly when things get done.
In Haskell you have no idea!
In C there is still indeterminism, up to sequence points,
which are quite hard to understand (in fact the latest C
doesn't have them, even the committee couldn't understand them).
Felix is in between. You have to have indeterminism to get
performance. Optimisation in a purely deterministic language
is almost impossible .. by definition.
What you really want is a way to limit the determinism so that
your semantics are ensured. That's no so easy.
Example: in ocaml
f a b c
evaluates arguments in an indeterminate order, as does C. To fix the order
let a' = a in
let b' = b in
let c' = c in
f a' b' c'
and of course in C you do the same:
a' = a;
b' = b;
c' = c;
And so it is in Felix. For example if you want this to work:
proc closure () { println$ i; }
for i in 0 to 9 do
a . i = closure;
done
for k in 0 upto 9 do
a.k ();
done
its quite tricky. The easiest solution is functional programming: use recursion.
proc setup (i:int) {
if i < 0 return;
a.i = closure;
setup (i-1);
}
Not very nice but it works as expected because i isn't a variable.
There's one i in each stack from of setup and closure binds to that one.
And that should work .. even with tail rec optimisation.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
