I am changing the operator . rules: in
LHS . RHS
1. If the LHS is a pointer, it is dereferenced automatically,
resulting in DLHS
2. IF DLHS is a struct, cstruct, class, or record,
AND RHS is a simple name defined for the record,
THEN result refers to the object component, and it
is an lvalue iff LHS is an lvalue OR LHS is a pointer.
3. IF the RHS is a function, it is applied to the DLHS
4. Otherwise if the RHS is a simple name, get_RHS is applied
to the DLHS
5. Otherwise fail
The effect (I hope) is that you can write:
struct A { int x; };
var a = A 1;
var px = &a;
println px.x; // means (*px).x, no need for ->. now
println px.y; // means get_y (*px)
// note: arg deref auto
// note: arg is an lvalue
fun f(a:A)=>a.x;
println x.f; // means f x
This means you can now define:
fun myadd(a:int)(b:int)=>a + b;
println$ 1 .myadd 2;
That is, any 2-ary curried function can be used in unfix
position by prepending a . character. The interpretation is:
(1 .myadd) 2 ==> (myadd 1) 2 ==> myadd 1 2
Note: myadd can be ANY EXPRESSION not just a function name,
as long as it has function type.
NOTE: it isn't associative:
x . f . g ==> (x . f) . g
x . (f . g) ==> applies g to f first
It would be kind of nice if f . g here meant 'function
composition' but this cannot be so, it would destroy
the proper meaning of:
f . map x lst
which is of course just
map f x lst
There is another ambiguity here. If you write:
a . f
the this could mean EITHER
get_f a
f a
There is a simple solution .. get rid of the 'get_' part of
the name.
RF BE WARNED!!!! You will need to write:
fun x(a:mytype)=> f x;
to make
a.x
work, instead of fun get_x. This all means that in a structure,
all the component names are automatically projection functions as well.
The bad impact of this change is seen here: this code WILL BE BROKEN:
type t = "...";
fun x: t -> int = "...";
var x = a.x; // WOOPS
The problem is that a.x now means
x a
and x is a variable which clashes with the function x.
Previously, we had a clash if you wrote:
type t = "...";
fun get_x: t -> int = "...";
var get_x = a . x; // WOOPS
but of course, this is less likely to happen! The best solution
here actually seems to be:
type t = "...";
fun get_x: t -> int = "...";
var x = a . get_x; // OK!
which makes it clear the access is using a fetch function,
i.e. it is abstracted, rather than being a direct reference
to the component name.
***** NOTE ****
The change to get_x function names isn't implemented YET.
Instead, a.f is left ambiguous: it will mean get_f a iff
f is a simple name AND LHS is a (pointer to) an object
type (struct, cstruct, class, cclass, record).
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
