[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] What is the role of standardization in things like FFI?
- To: Stefan Edwards <saedwards.ecc@x>
- Subject: Re: [Scheme-reports] What is the role of standardization in things like FFI?
- From: John Cowan <cowan@x>
- Date: Wed, 16 Nov 2011 12:24:14 -0500
- Cc: scheme-reports@x
- In-reply-to: <CAEMRNFNcdLiViAoYYP=5-gyw9seu8zWuEsVpmp7EibVoDFqyYA@mail.gmail.com>
- References: <CAAjq1mc3xdRrUGBYYP-EeR0U5CftHh=+YKXo+FKBMgdFriN81Q@mail.gmail.com> <4EC38561.firstname.lastname@example.org> <CAEMRNFNcdLiViAoYYP=5-gyw9seu8zWuEsVpmp7EibVoDFqyYA@mail.gmail.com>
Stefan Edwards scripsit:
> I would think that the standard would define something akin to
> Bordeaux threads and support some minimal-level of threading across
> a wide variety of systems, whilst the language itself would allow
> for users to select the best possible threading for themselves via
> SRFI-0/7. It could be as simple as falling back to continuation based
> threads should the OS/VM target not support threading natively.
Threads, unlike FFI, will be part of R7RS-large. See
http://trac.sacrideo.us/wg/wiki/ThreadsCowan for my current proposal,
which closely tracks SRFI 18. It deliberately says nothing about whether
the threads are continuation-based, library-based, kernel-based, or even
> A decent FFI would allow the user to work around this. I don't think
> having a standard FFI means assuming that there is no difference in
> ABI, system calls, &c., but it would mean that if I need to interact
> with C on system X, I don't have different syntax from system Y, even
> though the way I interact with system X is *completely* different from
> system Y (32 vs 64 bit, ropes vs flat strings, ad infinitum).
I marvel at the creature: so secret and John Cowan
so sly as he is, to come sporting in the pool cowan@x
before our very window. Does he think that http://www.ccil.org/~cowan
Men sleep without watch all night?
Scheme-reports mailing list