On 06/04/2009, at 5:54 PM, Erick Tryzelaar wrote: > > > Those annotations, those are essentially effect types, right?
Dunno what they are although the name is suggestive .. > I remember I read a paper a couple months ago from the BitC folks > that talk about implementing their effect system [1]. I've heard it > can get pretty messy if you implement them for everything, but it > might not be too bad to just say that you can have pure or impure > functions, the former corresponding with our `fun`, the later with > `gen`. Something like this would be invalid: > > var x = 1; > fun f () => x; > > You'd have to write this: > > var x = 1; > gen f () => x; > > I think that's what BitC did. You miss the point here that there are 3 categories: f above isn't a generator, it has no side effects, it just *depends* on side effects. The value of x cannot change during evaluation of f (or any other function) (unless a separate pthread changes it). So there are 3 crude categories: 1. Neither have side-effects nor depend on them 2. No side-effects, but depend on them 3. Anything goes but we only have two declarators: fun and gen. Actually we also have 'proc'. Category 3 is really a procedure that happens to return a value as well. Note that at present Felix cannot distinguish ANY of the above 3 categories using type information, which is certainly a bug .. gen and fun should have distinct types, otherwise functions values have to be decided to be generators and then they cannot be invoked except by generators .. but I know about this one .. it is repairable, the question is HOW?? How much clutter do we add to the type system? > How would we handle functions that accept and return functions though? > > fun f[a,b] (x:a->b) => x 5; > > BitC has to include the effect type in this case, so we could too I > guess: > > fun f[a, b, %purity] (x: %purity a->b) => x 5; > > where `%e` is the purity of x, and `f` would be pure if %e was pure. > > [1]: http://www.bitc-lang.org/docs/bitc/bitc-origins.html These "constraints" are damn hard to propagate. At present constraints like "U is an INTEGER" can be stated using type sets .. but these constraints do NOT propagate. In your above example, they not only propagate, both value propagate (making the constraint itself a variable). Actually the above is bad IMHO, because when you see f(..) you can't tell if it is pure. Should be pure fun f(g:int->int % pure) => g 1; See here we know f is pure. If you want an impure version: impure f_impure(g:int->int %impure) => g 1; [If the constraint propagates as a variable there's not much point having it, at least for human readability .. perhaps it helps for optimisation] Anyhow .. we're stripping features, but to fix semantics we may need to also add some ;( -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
