Some ideas for a runtime API...


Nice to have:
* Request (or "pre-cache"?) many operations, then "start" them, and fetch results.



fs.getsysdir(sysdir_id) -> dir
[path].fromname(s) -> path
[path].frompathstr(s) -> path
[path].fromarray(s[],len=s.len) -> path
# read-only vs read-write directories?
dir.opendir(path) -> dir
dir.openfile(path) -> file
dir.openr(path) -> rfile
dir.openw(path) -> wfile
# also, it would be nice to have some specialized and/or high level file types, such as:
# - reading into a byte/text stream (without any seek functionality)
# - streaming parsed data from the file


# or, maybe something like this:
fs.asyncfs(sysrootdir_id) -> adir
asyncdir.subdir(path) -> adir
asyncdir.openr(path) -> arfile
arfile.req(offs=0, nbytes=-1)    # requests bytes to be read

# maybe skip async stuff and use only green threads?
[fs].new()
fs.sysdir(sysrootdir_id) -> dir
dir.subdir(path) -> dir
dir.openr(path) -> rfile
# the above functions return futures
# these functions block:
dir.error() -> error
rfile.error() -> error
rfile.read(byte[],nbytes) -> len
rfile.close()
# function for submitting pending open/subdir requests
# (or should this be implicit?)
fs.submit()
# this would drop privs for all threads.
# maybe the sys object should be passed as a parameter to slul_main?
sys.dropprivs()



# but in "SLUSYS" we should of course pass command-line parameters that
# refer to files/directories as file references, and not allow access
# to any other files!
func slul_main(procctx) -> int
{
}


# cool idea:
# how about having implicit types for parameters with a lowercase
# version of a type name?
#
# these might need to be unambiguous, though.
# (which leads to the same problem that Java has with capitalization of abbreviations)
# also:
#   procctx -> Procctx(ugly!)
#   proc_ctx(ugly!) -> ProcCtx
# can we avoid this?
# one really simple way is to require that identifiers are unique
# even *case-insensitively* from character 2 to the end. for example:
#   procctx == pROCCTX
#   ProcCtx == Procctx == PROCCTX == ProcCTX
# this feels like a good idea anyway, because it prevents confusing code from compiling.
#
#
# we could *maybe* also extend this to parameters named i,j (indices, BUT int or usize???)
# "len" is pretty much unambiguously a usize (although a smaller type may be desired sometimes).
#
# This could also be extended to variables:
#  - some kind of "let" syntax but ONLY when the name tells which type it is (it's not an obfuscation contest!)
#  - for "ret" variables, we could (maybe) also get the type from the function body.
#    (in this case, it is not a strict "let" syntax, because the variable is mutable)
#
# Maybe allow this only with the "ref" and "data" keywords?
# And require a uppercase starting letter for names of types?
#    ref file = ... 
#    data point = ...
#    data color = .rgb(0, 0, 255)
# Equivalent to:
#    ref File file = ...
#    data Point point = ...
#    data Color color = .rgb(0, 0, 255)
# The downside of this is that it encourages longer names.
# Long names are good for identifiers that are only used a few times,
# but otherwise it is nicer with short names:
#    ref File f = ...
#    data Point p = ...
#    data Color clr = ...