I thought the Great Compromise of R7RS was to have specifications for
both a small and a large language, so that everyone is happy (or at
least equally mad :-)) .
Isn't the difference with R6RS that R7RS-large draws extensively on
SRFIs which are indeed attempts to codify existing practices?
On
Sounds good to me!
On Fri, Jan 18, 2019 at 11:23 AM Peter wrote:
> > The trouble is that the SRFIs are finalized before we know which ones
> will
> > become part of R7RS-large, in some cases decades before. Currently the
> > SRFI process doesn't allow correcting anything except outright errors
The trouble is that the SRFIs are finalized before we know which ones will
become part of R7RS-large, in some cases decades before. Currently the
SRFI process doesn't allow correcting anything except outright errors of an
editorial nature, except in extremely rare cases.
On Fri, Jan 18, 2019 at
Hi,
I put together a simple interface to Gnuplot, basically popen() with a
couple of procedures to plot lists. The motivation is mainly to draw
exploratory plots from the interpreter. If you think this may be useful
as an egg I'm happy to add wiki documentation. Comments welcome.
Hello ;)
Would it be possible to include the R7RS large library aliases in the
relevant srfis? So srfi-1 would be available also under (scheme list),
etc.?
It might be better to have the individual srfis include these names,
instead of making one large r7rs-large egg, that then depends on *all*
Hello Christoph,
> Understandably. Since I didn't link libmosquitto.so to it. But *HOW*?! I
> tried '-lmosquitto', but that's not passed on to gcc. Which is the correct
> way?
I'll assume for now that you're using CHICKEN 5 because in CHICKEN 4
it's sufficient to pass `-lmosquitto`. This
Dear Chickeneers!
I might be stupid or blind, but I can't find a way of announcing foreign
libraries to 'csc' that have to be linked to my binary. I have the
following code:
*(import bind)*
*(bind "int mosquitto_lib_init(void);")*
*(display (mosquitto_lib_init))*
When doing 'csc mqtt.scm' on
