I'd still rather give the user the tools to avoid all that ceremony, assuming of course they're e.g. starting with a call to file-info as part of dispatching on a file as they're perhaps traversing part of the filesystem
I was thinking of just calling an open or write or whatever it is and trapping the exception, rather than "check if you can do it, then do it (possibly with a race condition in between)." That's Python's attitude, and R6/R7RS `guard` makes it super easy.
Ugh. To go further on my previous reply, this is the sort of thing that's ideally compartmentalized in one or more other SRFIs.
Once you can get the current time (forget the current timezone), everything else in a date-time SRFI can be portable. I like having portable SRFIs wherever possible. clock_gettime() is Posix, and it's core to this, so put it here even if nobody calls it except the date-time SRFI.
Especially since you often want to do other date-time stuff at the same time, like subtracting and adding intervals, while allowing for a change in daylight savings time, leap years, etc. etc. ad nauseam. The newly adopted by mainline Java date time library, Joda-Time when I used it, was pretty sane to use (wrapped for Clojure).
The other pieces of this are the /usr/share/zoneinfo files, which are in every Posix system, plus Windows implementations of Python, Ruby, MySQL, etc. provide them, or the user can download them, plus the leapseconds file at <
http://maia.usno.navy.mil/ser7/tai-utc.dat>. After that it's all plain sailing, though I have a few wrinkles around durations to work out. 24 hours after noon can be noon, 1100, or 1300 the next day, depending on DST effects. But is the same true of 1 day? I don't know. XQuery says yes, my intuition is more doubtful.
It's a very small step from gochans (available in Chicken now) to pipes, and multiprograming can become multiprocessing can become distributed processing trivially by replacing pipes with raw TCP connections, too.
And now that Scheme and Clojure governance have swapped their stories,
Can you explain? Googling "Clojure governance produced nothing useful to me.
I'm going to give it all very serious "nit picking" analysis. The latest thoughts pertain to 3.2 I/O, the first 5 procedures that convert between ports and file descriptors.
I assume they're useful for the base SRFI in the context of a developer who's writing C native or FFI code to run in the same address space as the Scheme code, but who doesn't want to hunt around for these primitives in the implementation's code, as I am doing right now with Chibi Scheme ^_^. Vs. their being only useful for fork/exec and thus candidates to move to the process SRFI.
+1
Setting umask at the beginning of your code also helps protect you from making errors, plus you don't know what umask a user might be using.
Yes, I accept this.
I'd like a decision on moving out the process stuff "soon", e.g. sometime next week if that fits everyone's schedule (it is vacation season). I think it would do a great job of partitioning the POSIX functionality we want to supply into two much more digestible meals, and I can't think of any other axis that would suffice.
Works for me.
the new SRFI shouldn't just be a clone, it should be a reworked high-level process control library.
Or you could do both.
Since we don't even have a pre-SRFI yet, we're not under the gun for creating something, just for removing things.
Ah, the more I think about it, the better I like it. Scheme implementation gurus have to write the lower level one to interact with their implementation, while the higher level needs experts in how to least unsafely do spawn et. al. on Linux, the BSDs, etc.
We already have too many experts in how to do things unsafely. But a safe and easy-to-understand design can have bad implementations replaced. We have always tried to be a Right Thing (as opposed to Worse is Better) language.