On 15/08/2008, at 9:41 AM, john skaller wrote:
As per previous email, "lvalue" is now eliminated from the compiler.
in the library we now have
typedef lvalue[t] = t;
so you can no longer overload on lvalueness. The prefix operator & used
to take an address can now be applied to any value and Felix won't
detect
any errors (but the underlying C++ compiler will if the value isn't a C
++ lvalue).
Also, var parameters are now just of type t. I have modified the array
type so
x.[i]
is type t, and no longer overloaded so if the argument is an lvalue,
then
the return type is too. Some other data structures will need mods too,
notably stl::Map and stl::Vector tests currently fail regression tests.
All this is a hack. In theory,
++x;
should be a procedure
proc pre_incr: &t -> void;
that is, it should accept a pointer, not a value. Thus we should have
var x = 1;
++&x;
where you're forced to write the & operator to match procedure
pre_incr. Were & applied automatically, or, x was determined to be
of type pointer to t, then you'd need to write
x = *x + 1;
instead of
&x = x + 1;
but in no case would
x = x + 1;
be accepted. This DOES work at the moment, since assignment no longer
requires the LHS to be an lvalue. The "right" way is probably to allow
++x;
x = x + 1;
and then syntactically transform these to
incr (&x);
assign(&x,x+1);
that is, add the & automagically in an lvalue position. Then we can
check
that the argument of & is a simple variable, or an expression
*px
where px is of pointer type, or, some other cases (such as, perhaps,
array access like a.[i] which might be addressable).
I note the nasty case of assignment like:
var x: int;
def x, var y = 1,2;
I also note: the aliasing problem with pointer is re-introduced by
addressing
variables for purpose of modification, so it is important the
optimiser can
detect that &x and &y cannot reference the same store (being pointers to
distinct variables). We think of &x in this case as just the name of the
variable and plain x as actually dereferencing it. As in assemblers
like LLVM
this variables are REALLY constants which are just storage location
addresses.
Exactly how to fix the lvalue thing now is still open, but it will be
mainly modifications
to the library, user code, and perhaps some hacks in the compiler to
support
a bit more "C like" syntax -- we cannot leave
&1
as a legal expression, but we also cannot require the argument of & to
be an lvalue type now (since such types are gone).
--
john skaller
[EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
