I have just added a first cut of namespaces to felix.
It is fairly crude:
//////////////////////////////////////
#import <flx.flxh>
print "b4 fred"; endl;
namespace fred {
print "fred1 start"; endl;
var x = 1;
proc f() { print "f"; endl; }
print "fred1 end"; endl;
}
print "between freds <not!>"; endl;
namespace fred {
print "fred2 start"; endl;
var y = 1;
proc g() { print "g"; endl; }
print "fred2 end"; endl;
};
print "after freds"; endl;
open fred;
print x; print " "; print y; endl;
f(); g();
///////////////////////////////
The rules are:
* all the namespace definitions with the same name must also have
the same type variables and type constraints
* all the non-namespace code is emitted first
* then the namespaces are emitted as modules, in order
of the first appearance of a namespace definition,
each namespace is a module containing all the statements
in all the namespaces of the same name, collated.
Thus the output from above is:
[EMAIL PROTECTED]:/work/felix/svn/felix/felix/trunk$ f ns.flx
b4 fred
between freds <not!>
after freds
0 0
f
g
fred1 start
fred1 end
fred2 start
fred2 end
The reordering of executable statements isn't entirely desirable.
However the alternative is to emit separate initialisations
for each namespace definition. The current implementation
simply fiddles the parse tree, coalescing everything in
the parts of a namespace into a module. Module initialisation
code is put in an _init_ function for that module, and called.
Thus .. the code goes in one function.
The point is the reordering is done just prior to the
desugaring phase splitting the declarations and executable code up:
to keep the order "as written" would require processing
each namespace definition part as a distinct module first,
and the catenating the declarations, but leaving the executable
code alone .. this is too tricky :)
An easier to implement alternative would be to process all the
inits of each namespace where the first definition occurs.
This would actually allow you to 'schedule' as yet unknown
initialisations.. for example:
var a = 1;
namespace First { var x = a; }
namespace Second {var y = x; }
a=22;
namespace First { x++; }
print y; endl;
would print 2. At present it would print 23.
In any case don't rely on a particular interleaving
of namespaces with non-namespaced code.
you CAN, at present anyhow, rely on ALL the code in
a given namespace being executed before or after
that of a sibling, and the ordering within a namespace
is, of course, in order of writing .. unless of course
the namespace contains nested namespaces (catentaion is
applied recursively).
The impetus for namespaces is simply as a trivial
rewriting rule to allow things like the STL library
bindings to be constructed in (operation kind, data structure) order,
instead of modules forcing you to use (data structure, kind) order.
Enjoy! :)
--
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
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
