main() function(s) ================== - Should main() be a language feature or library feature? Implementing it as a library feature is a nice (and more extensible) design. - If main() is a library feature, how should it be exported? - And how to declare that the library requires the function to exist? - It could be a method, e.g. - Application.start() - CliApp.start() - The Application type should be an opaque/private type, so it can be extended. - The Application type can have a method to get the "root arena" and/or an "Env" type. This/these are used for allocations and serve as a root capability. - The advantage of having an "Env" type is that "system functions" can take it, and allow new operations, in addition to the ones in the standard library. - But to do things that aren't support at all (e.g. direct kernel calls), the code has to be written in a different language AND it should do a check whether the call is 1) overridden, 2) blocked, or 3) pass-through. But that is very easy to get wrong. :( Perhaps something like this: /usr/share/slul-interfaces/application.slul: \slul 0.0.0 \name cli_app \type startup_library \version 0.0.1 RHVtbXlUZXN0RGF0YTAxMjM0NTY3ODkK type CliApp = private type CliExitStatus = enum int { success = 0 failure = 1 any } func CliApp.get_arg(size number) -> ?string func youimplement arena CliApp.start() -> CliExitStatus myexampleapp/main.slul: \slul 0.0.0 \name myexampleapp \depends cli_app 0.0.1 func arena CliApp.start() -> CliExitStatus { if this.get_arg(1) == "yes" return .success else if this.arg_get(1) == "no" return .failure else return 3 } The "youimplement" keyword -------------------------- This means that the application (or perhaps some library?) MUST implement the function. - Decide keyword for "youimplement": - youimplement # <-- this name makes it kind of obvious what it is :) - interface - fill_in - mustimplement - their - Decide whether it should be possible for libraries to implement a "youimplement" function (instead of the application doing it). The "startup_library" module type --------------------------------- - Problem: This could make cross-compilation more difficult, because the binary code needs to be available for the target system / CPU architecture combination. - What file format should be used for the binary code? Perhaps an object file with some additional attributes: - API hash - Not all (if any?) platforms support placing the startup code in a library. This means that libraries cannot depend on startup_libraries [REMOVED] The "cli" and "gui" module types ------------------------------------------ These two are kind of Windows-centric. [DONE] Change it to "app"? Some old ideas around auto-detection of the executable type: - The binary parts of the startup_libraries could contain information on how the final binary should look like: - CLI/GUI flag on Windows. - "Friend libraries"? That can access/define internal data structures of other modules. - That would require two startup_modules and a separate types module: /usr/share/slul-interfaces/startinfo.slul \slul 0.0.0 \name startinfo \type startup_library \version 0.0.1 MUR1bW15VGVzdERhdGEwMTIzNDU2NzgK type Application = private type ExitStatus = enum int { success = 0 failure = 1 any } func ref Application.get_arg(size number) -> ?string /usr/share/slul-interfaces/cli_start.slul: \slul 0.0.0 \name cli_start \type startup_library \version 0.0.1 OTg3NjU0MzIxMDk4NzY1NDMyMTA5ODcK \interface_depends startinfo 0.0.1 MUR1bW15VGVzdERhdGEwMTIzNDU2NzgK func youimplement arena Application.cli_start() -> ExitStatus /usr/share/slul-interfaces/gui_start.slul: \slul 0.0.0 \name startinfo \type startup_library \version 0.0.1 V1ZVVFNSUVBPTk1MS0pJSEdGRURDQkEK \interface_depends startinfo 0.0.1 MUR1bW15VGVzdERhdGEwMTIzNDU2NzgK type GuiStartMode = enum { normal minimized maximized } func ref Application.get_startmode() -> GuiStartMode func youimplement arena Appliation.gui_start() -> ExitStatus