On 30/06/2013, at 8:42 PM, srean wrote:
>
> In contrast I am proposing that there be
>
> 1) var y <- g(c,d)
>
> the <- operator eagerly evaluates the RHS and assigns. "<-" is just a
> suggestion pick anything that looks ok.
In effect you're saying this, given an example (I'm adding an extra - because
<- is already used and
means assignment to a pointer).
y <-- g ( h ( x + y, 20 + k) + z);
to do this:
var t1 = x + y;
var t2 = 20 + k;
var t3 = t1, t2;
var t4 = h t3;
var t5 = t4 + z;
var t6 = g t5;
y = t6;
The question is, why would you want to do this for the whole expression?
As you can see, you can do it manually for ANY given sub-expression.
Furthermore this is ALREADY guaranteed for direct generator calls,
they're already yanked out and assigned to a temporary.
So the question becomes, exactly when can this possibly make any
difference?
It really cannot matter UNLESS
(a) one of the operators depends on a variable
(b) one of the generators sets the variable
Functions cannot set variables. MOST generators do NOT set
variables outside their scope.
So really I'm at a loss to think of an example where it matters.
All the examples I can think of are the opposite: you actually
want to force LAZY evaluation for example
if posix (arg) != 0 then errno.str else "OK" endif
then "errno.str" had better be lazily evaluated.
So:
(1) you can already manually decouple expressions
(2) there is not a single use case given where it matters
I'm not saying such cases don't exist, but I have to see them.
Preferably in real code rather than a hypothetical, but even
the hypothetical is hard to dream up.
FYI: the cases where this matters are not going to be helped by
your operator at all. The problem occurs in cases like
for i in 1 upto 10 do
spawn_fthread { println$ i; };
done
prints 10 or 11 (not sure!) 10 times .. not what you might
expect. The problem here has to do with the binding of the
i in the nested anonymous function which is the argument
of the spawn_fthread procedure, and that will not be
affected by the suggested change because it is ALREADY
eagerly evaluated. The problem is the evaluation is to
return a closure which is evaluated later.
>
> 2) a procedure called "discard" or "dispose" or disappear... whatever
>
> and we can use it as follows
>
> discard( g(c,d) )
Already exists:
C_hack::ignore
If you don't like it, you can easily create your own, or make more convenient
name for it locally eg:
proc discard[T] (x:T) { C_hack::ignore x; }
As it is the name is left "ugly" deliberately. It annoys me, especially in the
SDL code I'm writing now. I like that it annoys me. It makes me try to think
of a proper solution.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
