Peter Newman 8 January 2005 ------------------- Unified Programming Language
The "Bootstrap File" is a plain ASCII text file that allows the script-level programmer to select the data types and command/functions they want, in their own personal or application specific programming toolkit.
It looks like (for example):-
module d:/UPL/lib/interpreters/Tcl.dll (.so on Linux) # module d:/UPL/lib/interpreters/C.dll (.so on Linux) # module d:/UPL/lib/interpreters/Perl.dll (.so on Linux) # module d:/UPL/lib/interpreters/Python.dll (.so on Linux) module d:/UPL/lib/interpreters/Lisp.dll (.so on Linux) # module d:/UPL/lib/interpreters/Scheme.dll (.so on Linux) module d:/UPL/lib/dataTypes/integers.dll (.so on Linux) module d:/UPL/lib/dataTypes/strings.dll (.so on Linux) module d:/UPL/lib/dataTypes/lists/basic.dll (.so on Linux) # module d:/UPL/lib/dataTypes/arrays.dll (.so on Linux) module d:/UPL/lib/io/files.dll (.so on Linux) module d:/UPL/lib/io/std.dll (.so on Linux) etc etc
Where module functions pretty much like Tcl's load - and 'loads' the dll/so whoose path follows on the command line.
The "Bootstrap File" is loaded by UPL: The Bootstrap Interpreter.
RS As the script to be executed would know best which modules it needs, I'd propose to put such requirements (à la package require) in the beginning of each app script - but of course this makes boring reading, like a page full of #include in some C sources... Otherwise exchanging scripts between different sites will get difficult.
Peter Newman Yeah, I agree. Work needs to be done on this. I'm thinking that an intelligent parser that could figure out the modules required itself would also be a good idea. Instead of executing unknown when it comes across a command it doesn't understand, it looks in the module library for the command concerned, and auto-loads it.
That requires careful thinking about however. Because two or more modules might possess the same command. So which one is intended? Etc. Presumably, if there's only one such module, the parser can auto-load it. If there's two or more, it aborts, asking the programmer to select the one they mean. And if there's none, it complains and aborts.
DKF: OK, so your code is going to complain and abort (when loading my code) due to the lack of rmmadwim.dll on your system...
Peter Newman I don't quite follow that DKF. What else can it do?
That being said, I was thinking that our library of DLL's (and docs and sources,) should be in a directory tree on the local disk - or at least that fragment of the directory tree that the programmer concerned has seen fit to download. The complete directory tree (DLLs, docs and sources) would probably be on an FTP site somewhere.
So if the parser discovers an unknown module, it might pop up a window informing the programmer of this fact, and asking the programmer if they want to download said module. If the programmer answers Yes, it downloads the dll/so, docs and sources, and installs them into the appropriate place in the programmer's directory tree. Then it continues parsing... Sortof like the Perl Package Manager (only better).