[Vm-dev] Stupidifying FFI/library loading mechanism

Igor Stasenko siguctua at gmail.com
Fri May 27 11:51:29 UTC 2011


On 27 May 2011 13:25, Andreas Raab <andreas.raab at gmx.de> wrote:
>
> On 5/27/2011 13:01, Igor Stasenko wrote:
>>
>> On 27 May 2011 12:52, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>>
>>> Then perhaps you can clarify what you mean by "I think we should trash
>>> too
>>> clever intrinsic library lookup mechanism and provide a simple primitive,
>>> which attempts to load a library by given file name&  path ". To me, this
>>> sounded as if you want to deliberately abandon implicit search paths on
>>> the
>>> platforms. If not, then I don't understand what is different compared
>>> with
>>> today (other than having better failure information with which I agree).
>>
>> Clarification:
>> if search is implicitly managed by platform, then there's no problem.
>> (and actually you cannot trash this logic since it sits in platform
>> functions, and VM have to use these functions anyway).
>> But VM should not add its own implicit logic in addition to what
>> provided by platform.
>
> It seems to me that a good way to address the implicit logic is simply by by
> exposing (a list of) search paths to the image. In which case you can set
> the search paths to be as wide, or as narrow, as you'd like and the VM can
> list what additional search paths it would use by default, thus making this
> both forwards and backwards compatible.
>

Indeed.
In this way it is language side, are the only who responsible for
finding a library,
while VM could provide a hints , like default search paths, which are
most appropriate for current platform.

So, if we agreed on that, lets sketch the plan what we need to provide:

- extended error handling
- explicit module loading mechanism
- providing hints for library search by VM


-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list