Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[John Cowan]

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        address@hidden
Income tax, if I may be pardoned for saying so, is a tax on income.
                --Lord Macnaghten (1901)