On 26/03/2012, at 3:03 AM, john skaller wrote:
>
> Note I am looking for a way to make this stuff work WITHOUT
> coarse conditional compilation. That is, something like:
>
> typedef socket = int when POSIX;
> typedef socket = HANLE when WIN32;
Just a quick review. The current "requires tag" mechanism works, at the first
level
as follows: if the entity to which the clause is applied is used, all entities
with that
tag are included.
Typically it's a type binding:
header inclx = "...";
type x = "X" requires inclx;
and the included item is a floating header.
A couple of things need to be clarified.
1. The set of tagged items is included. More than one item
can be tagged. Or NONE! It's not an error currently to require
a tag and there be no item with such a tag: it's a set, and empty
sets are allowed.
2. Recursion is fine, the closure is calculated.
3. Only C bindings can have requires clauses.
Naked requirements are allowed in a class, but they are just
a short way to tag all the C bindings in a class.
4. Requirements are not just a simple tag. Actually, they're
expressions which include "and" and "or". But these don't work.
The idea was that you can require A, but if there's no A, you can
use B instead: A | B. The problem is that A is always satisfied,
even if there are no A items (see 1: A is a set, possibly empty).
5. Requirements can be polymorphic. This only works some
of the time, due to the ordering requirements with other
things: do the items go before or after the types?
Ok, so, for the "when" feature, what do we need?
Q: Can we make requirements do this at present?
A:1 No, because requiring a non-existent tag isn't an error.
A2: No, because if it were an error, it would be an error,
whereas what we actually require is an elision.
Q: do the dependencies work in the right order?
A: We have to look at a case. Needing XSI for something
to work means we also need Posix (for example).
So what we need is that if we elide something that requires
XSI and XSI is not available, the non-available ability of
Posix should imply the non-availability of XSI:
XSI when Posix;
This means if we don't have Posix, XSI is elided.
In effect, elisions proceed top down, inclusions
proceed bottom up. An inclusion structure is a tree,
with many bits requiring some common parts,
which require other common parts. Pick one bit,
all its direct and indirect dependent are dragged in.
Elision works the same way: we propagate requirements
from a bit upwards, and die if anything required is missing.
You can view this the other way too: what's present makes
things available, everything else is garbage. That is,
it's a garbage collection, but reachable means reachable
from the specified available bits.
SO: requirements mean something is included if it is
reachable from some code that is actually used.
Elisions work by allowing things to be used if they're
reachable from what's available.
So the answer is NO: the direction of reachability and
the location of the roots of the graph are the opposite.
However the direction of *elision* by "when" is the same as
inclusion by "requires".
Which means we seem to need a separate, dual, mechanism.
Unless we can introduce "logical negations".
Hmm ...
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
