On 19/06/2009, at 5:00 PM, john skaller wrote:
>
> On 19/06/2009, at 4:24 PM, Erick Tryzelaar wrote:
>
>>> There is a language (forget the name, something C like) which
>>> specialises in pointer "kinds".
>>
>>
>> I believe you're thinking about D
>
> no, its an academic language specialising in pointer kinds.
> Cyclone I believe.
>
>> 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
>
> Yep. Assignment can't work either:
>
> x = y;
>
> is deprecated.
The history is: to solve this so primitives could return array entries,
lvalues were invented. however Felix functions could never return
an lvalue, there's no syntax for it. So lvalues have been removed
and we're back to the original problem.
Briefly: x = y syntax requires a notion of lvalues. A symbol is playing
a dual role as an (r)value and and address, depending on where
it occurs. Extend to expressions...
Pointers solve this problem, but to do it right we have to have
a distinct notation for l and r values: either
&v,v // address, value
px, *px // address, value
The first case is uglier because it means you have to decide
what is addressable: a variable or component of one is not
enough if we want to "return" lvalue from things like the
subscript operator.
The second case is much nicer because it s driven by
the type system and a simpler rule that only variables
can be addressed. We can make
&v.member
return an address if desired by defining . as adding an offset
to a pointer .. at present operator . actually returns a value
when the LHS is a structure type.
Even cleaner is more Ocamlesque -- just get rid of variables
altogether. The whole concept is tied in with lvalues.
Instead:
val px = new 1; // pointer, px is a constant
The compiler can still allocate a variable on the stack here.
However it now requires data-flow analysis to see where
things get stored, every time, instead of occasionally,
since pointers are values that can be moved about,
whereas variables are not.
A compromise is to allow:
lval subscript[t] : array[t] * int -> t = "$1[$2]";
which allows primitives to return lvalues. however this
is not part of the type system, and so we still have that
Felix functions cannot implement this kind of thing.
References a'la C++ cannot be part of a sound type system
because they're not combinatorial.
--
john skaller
skal...@users.sourceforge.net
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
