Felix Winkelmann scripsit: > > * Designing a decent POSIX API is a hard task. I have not seen any > > reasonably good API wrapper for that yet - they are either too > > lowlevel (Basis, Ocaml, etc.), or too highlevel.
Part of the problem is that Posix is huge. There are 1191 system interfaces in 82 modules, in the 2013 version. Some of these are language-specific, like setjmp/longjmp, but most are not. Any Posix binding (other than ones that involve invoking arbitrary C code directly) has to be selective, and I have never seen any principles set forth for selecting them. Peter Bex scripsit: > Putting things like, for example, "directory" in some other unit would > make more sense to me, because there's nothing inherently POSIXy in > reading the contents of a directory. +1 > I'm not sure what will happen to POSIX in the future, but I think > its hegemony will end sooner rather than later. the landscape is > shifting so quickly with these mobile devices (think Windows Phone, > Firefox OS but also the crippled POSIX support on iOS and Android), I think "crippled" is an exaggeration, at least for Android. There is no Sys V IPC, but that's always been a marginal feature for most users. Likewise, there is no pthread_cancel, but arguably canceling a thread from outside the thread is a design mistake anyway, except perhaps for a debugger. See <http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html> for why Java doesn't have it. > the Linux crowd seems to be taking an increasingly aggressive stance > against "backwards compatibility" (think Wayland, systemd etc). But these don't affect POSIX system interface conformance. Linux is almost 100% conformant and I don't see it ceasing to be so. > Agreed. Recall that my suggestion was simply to "bless" UTF-8 as the > canonical internal representation (which is the case, de facto, anyway) That is what I meant also, and perhaps adding the Chibi string-cursor API for people who need more efficiency. > and *maybe* adding some detection code to reject invalid sequences > rather than just continuing with bogus data. That doesn't concern me too much. > Possibly making the default string ops the ones from the UTF-8 egg. +1 to that. > Anything beyond that is overkill [...] +1 > There is strong support from the community to do this, and I'm willing > to put in the required effort. I feel very strongly about adding at > least bignum support to core. I don't care as much about ratnums and > I don't care at all about compnums, but it may be simpler to add them; > the code to support them too is relatively straightforward. +1 to bignums, +0 to the rest. > - When dealing with foreign procedures returning full-width 64-bit > integers, as those simply cannot be fully represented by flonums. Right. Bignums that fit in 64 bits should be properly marshaled and unmarshaled by the core. Biggernums that don't should provoke errors at the FFI interface, in the same way (and for the same reasons) that strings containing NUL do. > - Having bignums be external to the core causes a lot of headaches when > one generates them and passes them to some library. For instance, > storing very large numbers in a database is perfectly sane and > generally possible with the DECIMAL type, but this requires all the > database eggs to pull in the numbers egg, which they currently don't. > In short, the numbers egg is "contagious". Long ago I proposed to Felix an implementation of the numbers egg using run-time hooks rather than modular renaming of procedures, such that + would always go through a hook which would invoke either the fixnum-flonum definition in core, or else the definition in any egg that had loaded itself into this hook (with the understanding that such eggs don't compose). I don't think this would play well with types, though. -- John Cowan http://www.ccil.org/~cowan co...@ccil.org Income tax, if I may be pardoned for saying so, is a tax on income. --Lord Macnaghten (1901) _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers