From: John Cowan <xxxxxx@ccil.org>
Date: Friday, August 02, 2019 4:39 PM
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.
Since we want stat/file-info anyway, I'd like to support both paradigms.
One can also imagine systems where trying to touch what you shouldn't results in a log file entry or worse.
[ Time stuff, which we're agreed belongs elsewhere, plus multiple process stuff which isn't in the remit of this SRFI. ]
And now that Scheme and Clojure governance have swapped their stories,
Can you explain? Googling "Clojure governance produced nothing useful to me.
I can supply some intemperate screeds and replies, but in short, as Rich Hickey explicitly said, he needs to earn enough money to put his kids through college, which is one reason Datomic is closed source. To get mind share Closure had to be general user oriented at the beginning when it was first released the same year as the R6RS vote, but now it's entirely oriented towards the needs of Cognitect, the company that among other things does Datomic.
Major changes are routinely made without concern for normal users, like a type checking feature released in official alpha state as part of the mainline release which made its already very hard to grok JVM stack traces worse. Community standards in things like that sort of type checking are ignored in favor of whatever Cognetict comes up with, which are sometimes better, but just sometimes different, and sometimes orthogonal which I think was the case with the type checking, with the community standard dying on the vine. In reference to the above link, it has true bugs, not differences of opinion, that have had patches submitted and lingering for half a decade, and as far as I could tell everyone outside of the Inner Circle had stopped trying to do anything with the official core.
All this has resulted in a lot of burnout of what became a lot of former core community members. In general I joined a consensus that "peak Clojure" had occurred before the end of 2018, it should stay reasonably stable and might even grow slowly because of the things it offers, including a fair amount of corporate acceptance, but ... I can choose exactly what I want, and I like Lots of Irritating Sets of Parentheses.
ClojureScript I think was not in such bad shape, but I'm almost entirely a back end type so I didn't really follow it.
[...]
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.
OK, this is big enough we should take our time to make sure partitioning it this way is right, or not.
In the meanwhile, I've got plenty to work on, only just started to glance at the TTY stuff. Although I think most of its procedures also belong in the posited process SRFI(s), and I'm still very uncertain about the with-/without- procedures vs. "put this port in cooked/rare/raw mode and let me run with it". Even more so now that I'm thinking with an implementor's hat, how Scheme implementation specific is the required "dynamic-wind magic"? In any case, yet another thing I need to learn, which is a major reason for my putting so much effort into this SRFI.
- Harold