Hi Daniel, On 8 July 2013 08:59, Daniel Diaz <[email protected]> wrote:
> Hi, > > I understand the problem you state but it is due to the fact that you want > to provide all libld functionalities at the Prolog level. I'm not sure it > is a good idea. > Me neither but it never stopped me before. It *could* be incredibly dangerous for sure but then again, working with C has always been like walking through a minefield with extra large metal boots just for fun. > Allowing the user to load arbitrarily an dynamic lib and invoke any > function provided by the lib can be very dangerous: we are handling > pointers as simple Prolog integers. Btw a C pointer cannot be safely casted > to a Prolog integer which use some bits (currently 3) for the tag (e.g. on > a 32 bits machine, gprolog integers are on 29 bits). > I had wondered about that. Lots of systems steal a few bits to tag integers. I think Squeak smalltalk does it, the JVM does it(?). It obv. allows for faster runtime processing of integers that really are integers not pointers to an object table. Been there, seen it, pulled out hair over it a lot over the years! HAHAH. > > I'm however convinced that it is important to provide Prolog built-in > predicates to load a Prolog module dynamically (I don't mean "consult" but > load a natively compiled Prolog module). Such built-ins would rely on > dlopen,dlsym (or equivalent functions under windows) internally but they > would not be directly accessible by the user (except if he use the C > interface obviously). To be loadable a Prolog source file should be > compiled by gplc in a specific way to provide a dynamic lib (.so ou .dll > under windows). I'm working on this with the introduction of a module > system for gprolog. > Well I think that I will stop there... if the author of GNU Prolog is working on a module system then I reckon it will be better than anything I would have come up with that's certain. I look forward to seeing how it turns out. Cheers, Sean Charles.
_______________________________________________ Users-prolog mailing list [email protected] https://lists.gnu.org/mailman/listinfo/users-prolog
