On Apr 6, 2009, at 12:09 AM, john skaller wrote: > > On 06/04/2009, at 4:33 PM, Erick Tryzelaar wrote: > >>> >>> The question is what 'x' means given >>> >>> var x = 1; >> >> >> To play the devils advocate, do we even need lvalues? I can live >> without pre and post incrementing. > > > What about assignment? If you can't get the address of a variable > you cannot modify its value.. are you sure you want to move to a > 100% purely functional language? If so why not use Haskell or Erlang?
I don't think using the ocaml-esque variables are functional. What I'm thinking about is essentially that you have to dereference a variable in order to assign to it. So: val a = 1; var b = ref x; // b contains 1 val c = *y; // c contains 1 *b = 2; // b contains 2, c is still 1 val d = *y; // d contains 2 >> if it'd make our semantics clearer. It'd also make sense if we ever >> actually made functions are purely functional, rather than just >> assumed they were. > > Functions (funs) are required to be functional now, but they CAN > depend > on variables so we do not have referential transparency ;( > > In fact been thinking of > > var x = 1; > pfun f() => x; // ERROR > >> I think it makes sense to support mutation, but I >> don't think it needs to be transparently supported. > > > Probably the opposite, be nice to *see* where mutations are > done and require that, but even Haskell can't enforce that > (State monad effectively hides mutations by making them > dependent on type instead of syntax). > > It's hard to see how to distinguish say functions and generators, > we'd have to have say > > val x = f( @rand()) > > where the @ was mandatory (i.e. make all generators start with @ so > you > can see them). > > It all gets complex: there is more than one kind of generator, and > indeed kinds > of functions. For example you could be made to write > > var x = 1; > fun f<x>()=>x; > > to say f is pure *except* it refers to variable x, then > > fun f<>()=>1; > > is clearly marked pure and > > fun f()=>x; > > would be an error because pure is the default (missing <> defaults). > > At least two kinds of generators too: ones that depend on external > state like system time, rand, etc, and ones only using internal > state -- the latter are predictable, and can be restarted by making > a new closure (typical example: iterators). > > Which annotations to chose? Some mix of those giving visual strength > to the language reader, and those allowing better optimsations. > > "purity" doesn't help with optimisations in Felix because Felix can > calculate if a function is pure or not anyhow (and does). Those annotations, those are essentially effect types, right? 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. 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 ------------------------------------------------------------------------------ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
