On 05/03/2014, at 5:40 AM, srean wrote:
> Are both necessary ? Can I not use 'noinline' and get away with it (I would
> rather not get in the way of optimizations). Of course this question is only
> relevant when I am changing the captured variable outside.
At the moment yes, noinline and inline are not hints, they're
enforced because they have real semantics. They control
whether a "function" is really a macro or not.
However, the "semantics" of closure don't guarantee this, it just works
that way at the moment. There's no reason a closure should not
be specialised over an argument, it just isn't, usually, at the moment.
[There are some cases where Felix eliminates closures :]
Clearly that's not satisfactory. But it will have to do for now,
because I don't know a better way. When a closure is formed,
parameters are copied up, variable references in the body are not.
Its logical, the parameter is a variable in the local scope, an assignment
p = a
copies a into p.
I would suggest writing functional code. Inside that functional code,
you will have some mutable data structures like varrays which are
just pointers so they're copied by reference (i.e. the pointer is copied).
It is the same in Ocaml. Code isn't referentially transparent
in Ocaml, unless you don't use mutable data structures.
Haskell enforces transparency but doesn't allow mutable
data structures.
The problem of integrating functional and imperative
code manifests in ALL languages. In Haskell it isn't allowed
so the manifestation is the performance issue: no arrays
means slow code, smart optimisations mean unpredictable
performance.
So now I need you to actually write code, because without a set of
cases where it matters and it was hard enough you missed the
implications, i do not have the powers of abstraction to begin to
see a solution.
Felix does do quite a lot of operations automatically, and you have to
know what it does sometimes to predict behaviour.
The semantics are based on the compiler operation. They're NOT
defined by it, that would be stupid. The semantics are abstract,
but things like "indeterminate evaluation strategy" exist because that's
what is required to account for how the compiler generates code,
and it generates code so that in the usual case you get superior
performance.
If you can't deal with these kinds of things in an experimental
language, use a less experimental one. In particular this is a voyage
of discovery and discovery requires actually writing code.
Of course C++ doesn't have closures so you can't run into the issue
there. With C++11 there are lambdas. Have fun with how the committee
decided to control the binding strategy and the lack of a GC which limits
use to synthetic closures (pass down only). The point is these issues
arise in Felix because it actually does have proper, collected, lexical
scoping and function values (closures). C++ does not. Write code
like C++ and you won't have an issue in Felix either.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
