On 02/03/2014, at 4:45 PM, srean wrote:
> On Sat, Mar 1, 2014 at 11:19 PM, john skaller <skal...@users.sourceforge.net>
> wrote:
>
> On 02/03/2014, at 2:08 PM, srean wrote:
>
> > It is this _uncertainty_ that makes it difficult, for me at least.
>
> Then use fthreads and channels.
>
> Yes, but that feels too cumbersome,
Deal with it. Use it. Then suggest some better syntax.
Without uncertaintly, there'd be no hope. No relationships.
No spirit and no soul. There's be no computers because they
rely on quantum mechanics, and no sun because it does too.
Even when you do machine learning with complex meshes
of cellular automata and you know the underlying components
are deterministic, you cannot *reason* about that system mechanically
because it is too complex.
To reason at all you need a non-deterministic theory.
In general computer language must be non-determinstic.
That's not to say there aren't rules, but rather that the
rules are abstract.
If you don't understand this, you end up with crap like Python
as specified by people like Guido van Rossum who just do
not get it. Python can't be efficient and you can't easily reason
about it because it is too deterministic.
In particular, you can't do type checking, or compile efficient
versions of it. To understand why, you have to see that a compiler
needs to make assumptions, like "this is an integer", if it is to avoid
run time checks.
It is hard to deduce any such thing in Python because the specification
deterministically says it is NOT POSSIBLE to make an error. There
is no such thing as an invalid python program. This email is a VALID
Python program. Because the language STUPIDLY specifies if you
run this email, you will get a syntax error exception, and you can catch
such an exception and take some action.
Compare that with gcc 4.8 which does aggressive loop optimisations
which are BASED on non-determinism. It does those optimisations
because it can detect that IF some code were not well formed
and deterministic THEN it can do whatever it likes. So it can optimise
loops based on the assumption the code is well defined.
The idea that deterministic specifications make it easier to reason
about code is completely and utterly wrong.
Knowing that arguments are evaluated in a particular order,
for example, make it HARDER to reason about code. Because
you have to look at the side effects of each argument evaluation
in that order. Whereas if the order is unspecified, you can ignore
interactions between side effects in arguments, on assumption
the code is well formed (and if you find there's a bug you know
where to look: violations of the abstraction: dependencies
on unspecified behaviour such as lack of deterministic ordering
or arguments.
In order words, LACK of detailed determinism is vital for
abstract reasoning precisely because LACK of detail is
the definition of abstraction!
In Felix fthreads are "in principle" non-deterministic in their
order of execution. You can spawn two threads and do a read
and a write and the semantics, in the abstract, just say they
synchronise at those points.
In particular it is precisely the LACK of determinism which makes
them easy to reason about because you know that code between
schannel operations on a particular fthread must be independent
of all other fthreads. I mean that when reading correct code,
you can assume this, and when writing it, you must ensure it.
In fact the actual implementation is a lot more deterministic,
which is a design problem! It isn't an advantage that readers
run before writers, so that the reader has a chance to copy
any variables the writer might modify at the synchronisation
point, BEFORE the writer can get a chance to modify that
variable: the implementation makes a heap copy of the channel
data to ensure this is true for the transmitted object, but it is
of course only a shallow copy.
The problem, then, isn't that the channel I/O is not deterministic
enough, the problem is that it is TOO deterministic. It is not
in fact the fault of the CSP design (Hoarse: communicating
sequential processes) but the fact that Felix has VARIABLES
which can be shared. Can't happen with real message passing.
And it can't happen in Rust, because that's the whole point of
the Rust design model.
I'm not saying Felix doesn't have an issue with variables:
of course it does, ALL languages do. The idea is nonsense.
But Felix choses to use the C/C++ ABI so its stuck with them.
Felix is less strictly determined that C or C++. This is necessary
for performance. It is also necessary to have BETTER ability
to reason about programs.
That's not to say the way the evaluation strategies are managed
in Felix is optimal, right, correct, or whatever. But its is BETTER
than C/C++ precisely because it is LESS deterministic.
In particular if there's code you're unsure about .. you're probably
writing it the wrong way. If you want data to be transferred from
a variable to a closure at the time the closure is formed, instead
of when it is invoked .. just writing the name of the variable
is clearly wrong. That would refer to the value at ANY time
between closure formation and execution. OBVIOUSLY.
If you want the latest value you can use a pointer.
If you want the current value, you have to EXECUTE something
to copy it. Since closures, on formation, don't execute anything,
there's no reason to expect them to bind to the current value
of a variable.
That's what fthreads are for. You can spawn them and use
channels to guarantee that they get data from a variable
at a particular time, but then suspend the rest of the evaluation
until later. In fact you can send the value of the same variable
at many different times to a fibre using channels.
var i,o = mk_schannel_pair[int]();
spawn_fthread {
var sum = 0;
while true do
sum = sum + read i;
println$ sum;
done
};
for var k = 0 upto 10 do
write (o,k);
done
The spawned fthread is a closure, but one which binds to
variable k of the enclosing scope using schannels.
Seeing this code do you have any doubts at all about the
behaviour??
--
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
