On 01/07/2013, at 12:30 AM, srean wrote:
>
> i) vals initialized by functions taking different values depending on when
> the function is evaluated
>
> ii) generator calls getting silently elided
>
> I think (i) is less of a problem because using var deals with it. (ii) is
> more problematic, its common for callables to have side-effects and return
> values and sometimes a very natural way to do things.
It is a common idiom in C. But Felix is not C :)
> Isnt that the whole point of generators ? to have side effects and return
> values ?
That's the definition, but not the whole point. The main purpose is for actual
generators whose side effects are encapsulated. That is, it simply causes
the generator to return a different value each call, no OTHER code can
detect the state change.
Both malloc() and rand() have this property in theory. The following
generator does too:
var g = iterator ( list (1,2,3,4) );
You get g() == 1, g() == 2, etc. So there's a state mutation but it isn't
a "side" effect in the sense some other piece of code can see the
state.
On the other hand, say, read() on a FILE* has a side effect that any
code with the same FILE* can see: it moves the current position
in the file.
Ocaml has exactly the same problem, only worse because it has no
statements as such, only expressions, and surprise surprise a call
like
let x = f a b c in ...
in Ocaml evaluates in the order c, b, a, f, then calls f: its eager
evaluation but backwards, DESPITE the fact that really f a returns
a function, that then consumes b, returning a function that consumes c.
The argument consumption is left to right but the evaluation of the arguments
is right to left.
However in Felix you don't have to use a generator. If g is a generator:
proc q (x:int, px: &int) { *px = g x; }
is a one liner that turns it into a procedure. Indeed, any C function which is a
generator can be modelled as a procedure and I do it in some cases:
proc q: int * &int = "*$2=g($1);";
This is hard to use:
var result : int;
q (1, &result);
so you can use a generator and write:
result = q (1);
but you're NOT supposed to nest calls to q deep in expressions unless you're
sure it will not create any interference between side effects.
note this is exactly the same sanity that you have to use in C.
This does NOT answer the problem that generators can be elided
if the result isn't used. however note that if they're REAL generators,
i.e. things like malloc(), rand() or a data structure iterator, the state
is encapsulated and there is no observable impact on eliding the
generator call if the result isn't used, because the behaviour is encapsulated
in the result.
So for things that actually *generate* some fresh stream of data
there's no problem losing a call.
The problem is when there are effect on the SIDE i.e. outside the
generator "object".
In these cases, in theory you should use a procedure.
For example for all Posix function calls. Should really be procedures.
In practice, it means you should assign to a variable and test
the result to ensure the error is checked OR explicitly ignore the
result OR nest it in an expression such as a conditional, which
ensures the side effects are kept AND the errors are actually checked.
My point again: there are several problems here introduced by a very
general concept of a generator: something that looks like a function
but isn't. And I don't have any good answers.
I will say this though: it is important to distinguish low level code,
which is hard to write, requires care, and has to go FAST, from
higher level code. Difficulties in the lower levels don't have to
penetrate to the higher levels.
For example Felix has goto and it is essential in the lower levels
to *define* control structures which can then be used in the
higher levels without needing gotos.
--
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
