Augmenting requirements processing, macros now work in
named requirements, for example:
-------------------------------
#import <flx.flxh>
header fred = "inline int f(int x){return x;}";
macro val joe = fred;
fun f: int -> int = "f($1)" requires joe;
print$ f 2; endl;
--------------------------------
The macro currently has to resolve to a qualified name.
The idea being persused is something like this:
--------------------------------------------
// WINDWS file handling
header win32_sys = "#include <windows.h>";
header win32_sys =
"inline HANDLE native_file_open($1) "
"{ return win_file_open($1); }"
;
// POSIX file handling
header posix_sys = "#include <fd.h>";
header posix_sys =
"inline int native_file_open($1) "
"{ return open($1); }"
;
//
// CHOOSE PLATFOM (use value set in config)
macro val os_sys =
if WIN32 then win32_sys else posix_sys endif
;
type file = "int" requires posix_sys;
type file = "HANDLE" requires win32_sys;
fun open: string -> handle =
"native_file_open($1.data())"
requires os_sys
;
--------------------------------------
This currently will NOT work as written for numerous
reasons .. such as a duplicate definition of 'file'.
However see the basic idea: this is conditional compilation,
but 'control inverted' so instead of compiling one definition
or another, you compile both and then select the one you want.
The selection is implicit, driven by usage, rather than
explicit, driven by #if/#else conditionals which modify
preprocessor 'control flow'.
A difficulty at the moment is that 'requires' is defined
so it hauls in ALL statements tagged by some specified tag,
unless there are none, which is deemed a failure, since you can
always write:
header empty = "";
for an empty set. This really isn't consistent with the idea
that you can depend on a tag that exists, but whose requirements
are unsatisfiable: the above actually means
header empty = "" requires true; // always satisfied
whereas omitting it would be equivalent to
header never = "" requires false; // impossible
Roughly, requires chould just pull in all tags with the
right name, the set of which could be empty, and whose
requirements are satisfied .. again the resulting set
could be empty. This is just selection, and cannot ever fail.
Which is quite different to requiring something which has
a requirement that can't be satisfied, which could imply
the original requirement can't be satisfied, either failing
the program, or removing the entity from tag searches.
The problem is these two things are quite different:
the former errors out Felix when you mistakenly call
a Windows function on Linux. The latter happily generates
C++ code that won't compile.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
