Felix current says that if you write
requires X
it means to put all the floating insertions tagged X into the output,
in order of writing within the two fixed places for insertions
(header and body).
Because the semantics is set-like, errors are not possible.
If you mis-spell X, you just
On 24/12/2010, at 3:15 AM, john skaller wrote:
>
> There are two other ways to treat failed requirements.
> A second mysterious way is: drop the symbol with the requirement silently.
> The sane way is: reject the program with a diagnostic.
Ok, this is actually not so easy. In the process of b
On 24/12/2010, at 3:15 AM, john skaller wrote:
>
> There are two other ways to treat failed requirements.
> A second mysterious way is: drop the symbol with the requirement silently.
> The sane way is: reject the program with a diagnostic.
Ok, this is actually not so easy. In the process of b
I'm playing with the requirements processing at the moment because I'm getting
confused by "isnan" being used by not sucking in the header file.
At present, failed requirements are simply ignored. Basically, if you require X
than all the X inserts are generated, but the set of such inserts can be
Augmenting requirements processing, macros now work in
named requirements, for example:
---
#import
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
I got bored building the release candidate, so for fun i added
a new feature. This didn't turn out exactly as I expected.
The feature allows alternatives in requires clauses.
For example you can write:
fun f:int->int="f($1)"
requires a_h or b_h and c_h, d_h;
The comma is a low p
