On Tue, Nov 23, 2010 at 8:48 AM, john skaller <skal...@users.sourceforge.net> wrote: > > The only way to fix this is require exactly one unique tag. > After all you can chain tags: > > header A = " .. "; > header B = " .. "; > header AB requires A, B; > > Not sure if I like this though. Comments? > > In fact, the felix requirements expressions are quite complex and > general: you can use and's and or's and not's etc.. and it isn't clear > what that means either :) > > Original I though of: > > proc create_thread: int = "posix::create_thread ($1);" requires POSIX; > proc create_thread: int = "windows::create_thread($1);" requires WIN32; > > as a way of selecting bindings, with the semantics above this isn't possible. > > but we can always add predicates .. for example > > requires defined(posix); // shades of c-pre-proc ...;( > > This leaves in question what "and" and "or"mean.. I expected > > require A and B > > to means the same as > > require A,B; > > that is, to require both, and > > require A or B; > > to mean: try A, but if not found use B instead: a simple example of the idea > is to have > > require epoll or poll or select; > > meaning use epoll if available, otherwise poll, and if that isn't available > use select. > > however a set-wise interpretation has almost the opposite meaning: > > require A or B; > > means to require the union, which is both A and B, whereas requiring A and B > would be the intersection, which would currently be empty (since one insertion > can't have more than one tag). > > BTW: I believe the problem of resolving such dependencies with alternatives > is NP-hard, which is why production package managers like Debian can't > effectively allow this option.
This feels like we might be trying to do too much with requirements. First off, I'm not sure if we should be baking in the decision of select/poll/epoll. I ran across some benchmarking that suggests that epoll is not always better than poll in all circumstances: http://sheddingbikes.com/posts/1280829388.html Second, the APIs of select, poll, and epoll are vastly different from each other, so I'm not sure it would even make sense to have: proc foo () requires select or poll or epoll { ... } Because you'd still have to have something like: ... macro if epoll do foo_epoll () else if poll do foo_poll () else foo_select () done ... right? ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
