Re: How many people are interested in designing the OS interface? Lassi Kortela 09 May 2019 13:22 UTC
> I have limited time to contribute, but if you send me the list of OS features that are in scope I can give you a list of the Gambit procedures that are available for those features. Beyond that I’ll try to stay tuned to the discussion. Thanks for staying on board in any case :) I appreciate it. What's tentatively in scope is roughly what's in the headings and procedure names of the draft SRFI at <https://srfi.schemers.org/srfi-170/srfi-170.html>. Is this an up to date document of the relevant interfaces in Gambit? <http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Host-environment> > BTW, it is sad that networking is out of scope… again… It is such an essential feature in modern apps, at least basic networking. I think things get complex (politically) when the details of the socket interface are exposed, but there should be agreement on basic and portable features. I don't know the history (just got into Scheme seriously this year) but apparently there is some disagreement on whether the networking API should be a feature-complete interface to BSD sockets, or a TCP/IP-centric thing favoring convenience above completeness. Is this your experience as well? I have an idea for how to reconcile the two camps but it's still a draft of a draft... > Is filesystem path syntax in scope? i.e. /foo/bar vs C:\foo\bar Yes. John and I would favor a light representation where a path is just a string (and occasionally a lists of strings for splitting). Gambit seems to take the same stand (<http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Handling-of-file-names>). Bytevectors could be supported in addition to strings where an implementation's string type doesn't permit lossless round-tripping of some exotic pathnames (there's a lot of stuff pertaining to Unicode normalization or lack thereof by the file system, mixing Unicode and non-Unicode filenames in the same file system, etc.) I have personally had a great experience with the Go/Python style "strings with a little convenience" pathname approach. It almost always does what you want. Common Lisp and Racket style heavy parsing of pathnames is an admirable goal, but in practice I have found it to be constantly confusing, very verbose and not really making code more portable or reliable.