Email list hosting service & mailing list manager

Re: How many people are interested in designing the OS interface? Lassi Kortela (09 May 2019 13:22 UTC)

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

Is this an up to date document of the relevant interfaces in Gambit?

> 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

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.