Talk:Executable library: Difference between revisions

Line 25:
 
::Alternatively: currently the task does not require the library be a single file -- it could easily be a directory or more properly a set of files within a directory. (And if it were changed to be required to be implemented as a single flat file it might be possible to do something by wrapping the necessary pieces in a manner something like a self extracting archive, which when used normally is an executable but can be told to extract the needed library elements at compile time, with an invocation that would need to go in the makefile or msbuild file or whatever. (Though, of course, the task could also be changed to prohibit the generation of object code at compile time, but I think most compilers generate intermediate object files as a normal part of the compilation process..)) --[[User:Rdm|Rdm]] 20:07, 10 May 2011 (UTC)
 
::: The ''idea'' is for the library/shared object/module/... to be what is normally thought of as such for the language, accessed in the normal way for that language. Similarly when used as an executable it should be done in the normal way an executable is run in that language and accessing the same source. I want to allow a language the ability to mess with the content of their library-cum-program, (and maybe with the options used when invoking it in either mode?). For a compiled language, running the compiler as part of 'running' the library is not normal. The only way I could currently see a compiled language being able to do this is if their is some trick which allows a shared object when run to act like an executable, and when used as a library, e.g. left on LD_LIBRARY_PATH in Unix, to act as shared object library.
::: You don't normally require the presence of the compiler at run time so I would expect any solution to not need a compiler as part of the solution.
 
::: What might be possible - although I am at one of the many boundaries to my knowledge - is maybe to use the neccessary presence of a byte-code interpreter for languages that normally require the use of a byte-code interpreter when run.
 
:::Some languages are released with compilers and interpreters. If they can fashion an example that is constrained to using their interpreters only then they should state that prominently and give their solution. I think Haskel has an interpreter. Their are much lesser known interpreters for what are normally thought of as static languages, such as C. A solution for those might best be put under the actual name of the interpreter as their may be so much distance between the two. --[[User:Paddy3118|Paddy3118]] 02:06, 11 May 2011 (UTC)
Anonymous user