[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Announcing 8sync: an asynchronous programming language for Guile

From: Christopher Allan Webber
Subject: Re: Announcing 8sync: an asynchronous programming language for Guile
Date: Sun, 29 Nov 2015 16:31:40 -0600

Ludovic Courtès writes:

> Christopher Allan Webber <address@hidden> skribis:
>> Christopher Allan Webber writes:
>>> ... and the complicated-number-code will launch asynchronously, but wake
>>> back up the appropriate function appropriately.  You can also set timed
>>> events, read and write to ports asynchronously, and etc.  It has a nice
>>> non-blocking loop, and personally I've found it to be a delight to use.
>> There's one potential long-term caveat to this (maybe?), which is that
>> the way this achieves nice asynchronous communication is by working hand
>> in hand with guile's (select) statement, which seems to only work for
>> socket type ports and file type ports I think?
> Yes, ‘select’ is only for “file ports”, which means ports backed by a
> file descriptor.  I guess 8sync will have to provide a higher-level
> interface on top of that?
> Ludo’.

Yes, it's actually already kind of extensible (and polling is already an
option in the loop)... though I'm not sure, what kind of things is
(select) insufficient for?  Databases usually expose some sort of port
interface, though Squee doesn't use it, for instance.

I guess maybe stuff like interfacing with GTK might be insufficient, but
I don't know.

Anyway, it seems like a lot can be done with (select).  The main concern
is, if other things aside from (select) are needed, can they be

For now, I'm forging ahead with (select)... luckily in Unix, many things
are backed by a file descriptor, including sockets... :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]