On 8 July 2013 08:59, Daniel Diaz
<address@hidden> 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.