I'm playing with (it's in CVS now!) something which makes
this work .. because I'm writing some documentation (!)
which specifies it:
-------------------------------
#include <flx.flxh>
var v = 1;
fun x => v;
fun y : int => 1;
print$ x; endl;
v = 2;
print$ x; endl;
-------------------------------
The notation
fun x => v;
is short for
(a) fun x() => v;
(b) replace every x in scope with x().
In other words, it's *enforced* lazy evaluation.
At present, this notation:
var x = v;
is *enforced* eager evaluation, and
val x = v;
is *indeterminate evaluation*. This means for a 'val'
you can't be sure when, if, and where x well be evaluated:
it might be lazily or eagerly on somewhere in between.
At present, explicit val's are evaluated with eager semantics,
but as lazily as possible.. however function arguments are
sometimes overlazily evaluated: they're substituted into the
function even if they depend on a variable which might
change because size effects aren't allowed. This is also,
incorrectly, done for procedures (which can change variables).
Following the usual C++ conventions, we should be able to
annotated function parameters var/val/fun. Actually the
parser already supports 'var', and it used to change
the type to lvalue, and attempted to look like 'pascal var'
parameters, which are basically references.
however this is counter to the reality: var actually
stands for eager evaluation .. AS WELL as allowing address
taking and mutation.
It may be that 'val' semantics should be specified as
eager .. in which case some current optimisations would
be bugs, however it provides an alias free immutable form of
a var which is still valuable.
Finally .. an idea is to have a similar trick:
var x = 1;
ref rx <- x;
rx = 2;
This is a like a C++ reference, the semantics are:
(a) val rx = &x;
(b) replace all rx in scope with *rx
This would finally allow procedures to emulate C primitives,
and accept reference (lvalue) arguments which can be modified
from within a procedure.
I will note here that 'ref' is actually lazy evaluation
given by:
fun rx()=>*x;
and replace rx with
rx()
so actually 'ref' is bound up with 'fun' variable semantics.
Note none of these 'extensions' are really more than syntactic
sugar for what can already be done. If you like .. and from
an advocacy viewpoint I'm moving heavily to this view point --
Felix is a way of automating design patterns.
The switch of focus from a 'programming language' to a
'design pattern automation tool' seems likely to attract
more users, but it also changes the focus from attempting
a complete language semantics to a toolkit for implementing
design patterns.
Unlike other such tools, Felix comes with a type system
which makes the generated code safer .. but dear C++ programmer
you're still writing C++!
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
