Stupidifying FFI/library loading mechanism

>
> On 5/27/2011 13:51, Igor Stasenko wrote:
>>
>> On 27 May 2011 13:25, Andreas Raab<[hidden email]>  wrote:
>>>
>>> On 5/27/2011 13:01, Igor Stasenko wrote:
>>>>
>>>> On 27 May 2011 12:52, Andreas Raab<[hidden email]>    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
>
> Almost :-) I really can't see a reason for requiring explicit module
> loading. Amongst other things it bloats applications (which will attempt to
> preload all libraries they might *possibly* need instead of those they
> *actually* need) and slow down system startup (for the same reason) or
> otherwise require people to write lots of either repeated code (as an
> example, just look at how many senders of Socket initializeNetwork there are
> all of which should be removed) or equally pointless extra primitive/ffi
> failure code. I can really see no good reason for requiring explicit loading
> other than ensure some library is available and that can be done with better
> error reporting.
>