On Thu, Jun 18, 2009 at 10:38 PM, john skaller<skal...@users.sourceforge.net> wrote: > > "const" is the wrong idea though. It may help, but it isn't the > same as > > int immutable x = 1; > int immutable *px = &x; > > With "const" a function promises not to modify the pointed > at value. This helps the caller make optimisations. > > With "immutable" the caller AND the callee promise > not to modify the value, this helps the callee make > optimisations, in particular it allows > > cache = *px > > and the function knows cache == *px always. > > There is a language (forget the name, something C like) which > specialises in pointer "kinds".
I believe you're thinking about D, which I was reading about while doing research. They support both c-style consts and an immutable keyword that prevents both that pointer and all subpointers from being modified. > there is no way to make a C primitive return an lvalue. This means > we have to have, for example > > Carray::get(a,i) > Carray::set(a,i,v) > > and then > > x.[i] += v > > can be written: > > set(a,i,get(x,i)+v) > > but that is a long way off the C notation. We could do > > a->[i] <- a.[i] > > however, where > > a->[i] // means &a[i] in C Yech, that's ugly :) I'm not sure if I completely understand though. Are you referring to the difficulty of getting the "x.[i] += v" syntax working, or is there a problem with the array semantics? ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
