Re: Generalized-Arrays egg v1.0.1

[John Cowan]

I now understand that chicken's srfi-143 egg has a  different spec from
actual SRFI-143; in particular, the egg's procedures are variadic, whereas
the SRFI's procedures were intended not  to be.  Unfortunately, the SRFI
specifies =, <, etc. to be variadic instead of dyadic as a result of cut
and paste disease, although the SRFI sample implementations conform to my
original intention.  I'm going to get the SRFI fixed if possible, or if not
to issue a post-finalization recommendation (i.e. a recommendation by the
SRFI author (me) that only two arguments be supported).

On Mon, Feb 5, 2024 at 8:43 PM Jeremy Steward  wrote:

> On 2/4/24 05:11, felix.winkelm...@bevuta.com wrote:
> >
> >> 1. The egg itself is not compiled with -O3, whereas if I link to
> >> (chicken fixnum) I believe that these procedures will be inlined by the
> >> CHICKEN compiler when the arrays egg is compiled with -O3 or higher.
> >
> > That's correct. As -O3 implies "unsafe", the compiler can just ignore
> > type checks and always inline numeric primitives.
> >
>
> Awesome, glad my intuition about this wasn't unfounded. This is probably
> the biggest factor.
>
> >>
> >> 2. There may be some rewriting rules that the compiler uses for
> >> procedures in the (chicken ...) namespace that optimizes these directly
> >> into their equivalent optimized C procedures. I'm not sure the compiler
> >> has the same visibility if you re-export these from behind a module, and
> >> especially not if you link dynamically (any hope of inlining those is
> >> thus gone forever).
> >
> > As a general rule all renamings and rexports preserve the run-time
> > semantics - as long as a procedure definition is not wrapped inside
> > another procedure, the original procedure gets compiled and any
> > optimizations and inlinings the compiler performs for "known" primitives
> will be
> > applied. Syntax- and module-specific expansions perform renaming
> > only and never introduce run-time code that wasn't explicitly given by
> > the user.
> >
>
> Aha, so as long as something is wrapped we don't see the same kind of
> inlining.
>
> >>
> >> In fact on the latter point above, this raises an interesting question I
> >> had for the mailing list: if I re-export a CHICKEN-specific procedure,
> >> does the way the compiler handles translation units prevent certain
> >> optimizations from applying? I've somewhat noticed that to be the case
> >> but I haven't seen any writing about it nor have I understood the extent
> >> to which that might affect certain SRFIs or eggs.
> >
> > See above - unless something is wrapped, you get the inlining. But as
> > I see in the SRFI-143 spec, their operations take any number of
> > arguments, where the ones from (chicken fixnum) have arity 2,
> > so I assume the srfi code wraps the primitives into multi-argument
> > procedures and thus preserves imports from the srfi-143 module to be
> inlined.
> >
>
> And yup, that's probably it. From what I can tell from the source
> locally they are wrapped e.g.:
>
>  (define (fx+ . args)
>(foldr chicken:fx+ 0 args))
>
> >>
> >>> If you have time/energy, it would be useful to make Chicken's
> >>> implementation do what it was originally intended.  See the
> >>> "Implementation" section in the SRFI, or feel free to ask me for
> >>> explanations of details.
> >
> > One approach would be to extend those exports from (chicken fixnum)
> > that match the multi-argument operations from srfi-143 and make the
> > compiler aware of these, internally expanding the multi-arg cases into
> > nested applications of inline calls to the 2-argument C runtime primitive
> > ops.
> >
>
> So what would this look like? I can see fx+ above, which uses
> `chicken:fx+` (prefixed, 2-arity) and foldr to accomplish its multi-arg
> case. Is adding `(inline-file)` to the srfi-143.egg enough for this? I
> suspect partly that the foldr and `(fx+ . args)` form in general is
> going to be hard to optimize out, but perhaps a case-lambda is faster?
>
> I suppose in pretty much all cases since I'm using the 2-arity versions
> in the generalized-arrays library there's very little pushing me to use
> the SRFI-143 versions, but any improvement to SRFI-143 is probably
> worthwhile considering the kinds of performance differences I was
> measuring with chicken-profile.
>
> >
> >> It might also be a good idea to enforce SRFI-143's behaviour around
> >> overflow / underflow as part of CHICKEN's default behaviour in CHICKEN
> >> 6, but I don't really know how I would get started having that
> discussion.
> >
> > The SRFI-page doesn't seem to specify any behaviour. The runtime system
> > is compiled with "-fwrapv" in the hope to preserve wrapping semantics for
> > integer arithmetic, but I'm not sure how reliable that is.
> >
>
> Interesting! I believed the SRFI-143 was specifying twos-complement
> behaviour, but I now see that I was wrong. I would think in general that
> if -fwrapv is passed, we should assume that twos-complement is used.

Re: Generalized-Arrays egg v1.0.1

[John Cowan]

On Sat, Feb 3, 2024 at 5:39 PM Jeremy Steward  wrote:

 Likewise, I opt to use (chicken fixnum) but this is
> because I discovered that SRFI-143 is so egregiously slower than
> (chicken fixnum) that it was causing serious performance regressions in
> many of the array APIs.
>

That's very odd. The Chicken-specific library wrapper for SRFI 143 at
GitHub (srfi-143.scm, which needs to be updated to Chicken 5) makes use of
Chicken's native fx* procedures.  I don't know how the Chicken (srfi 143)
egg was built, though; it may be using rubber-chicken.scm and fxcore.scm,
which are slow emulations meant for complete portability.

If you have time/energy, it would be useful to make Chicken's
implementation do what it was originally intended.  See the
"Implementation" section in the SRFI, or feel free to ask me for
explanations of details.

Re: cannot open file if name contains accented characters

[John Cowan]

On Mon, Dec 25, 2023 at 6:07 AM  wrote:


> I'm not too familiar with the way Windows handles non-ASCII characters
> in operating system calls, but I assume that what gets passed to the C
> library runtime functions like fopen(3), etc. assumes a particular
> encoding.
>

Basically, there are two modes, one that assumes a particular encoding, as
you say (that's the default) and one that assumes wchar_t, which is always
UTF-16LE.  Which encoding is used in the first mode depends on the locale
setting.

>From a quick glance at the Windows docs[1] it seems one needs to use
> "_fwopen" with a wchar_t string argument to pass extended characters.
>

Indeed, except that it's _wfopen, not _fwopen. Note that _fopen can involve
8-bit, 16-bit, or 8/16-bit mode depending on the encoding.

Sorry, if this is not overly helpful. We are currently in the process of
> improving
> the unicode support for the next major version of CHICKEN.
>

This makes me realize that posixwin needs to be changed in C6 so that it
always uses the second mode.  A simple way to do this is to use a UTF-8 to
UTF-16BE converter (and vice versa for things like dirread) right before
calling _fwopen.


>
> felix
>
>
>

Re: How best to get a default result from sqlite3, or to use or not use first-result?

[John Cowan]

IMO this is an excellent application for folding.

On Wed, Jun 8, 2022 at 10:54 AM Matt Welland  wrote:

> The problem: retrieve one value from a query, if there is no matching
> row return a default.
>
> Method 1: use for-each-row, overwrite the default with found values
> Method 2: use first-result, on exception return the default
> Method 3: use fold-row (wasn't an option when I first wrote the code)
>
> My question is, which of these is the "right" way to do what I want? Is
> there another, better, way? Note that method #2 has problems in my
> program but it might be due to my using chicken 4.10 (for now).
>
> ==additional details==
>
> Method 1, for-each-row, was my original approach and seemed to work
> fine.
>
> Then, in the midst of a major rewrite I tried to use first-result. It
> seemed odd to me to use an exception this way but I assumed (wrongly?)
> it was a fancy software engineery way to do things since the sqlite3
> egg did not provide any direct way to do what I want.
>
> However I hit a strange scalability issue with database locks happening
> only a few hours into a run. After a lot of fruitless debug and on a
> hunch, I replaced the first-result with a for-each-row and now am able
> to run ten of thousands of tests over many hours (still not perfect,
> work progresses).
>
> I plan to replace use of for-each-row with something like:
>
> (define (get-id db name default)
>   (fold-row (lambda (row)
>   (car row))
> #f
> db "SELECT id FROM tests WHERE testname=?" name))
>
> Thanks.
>
>
>

Re: chicken 5.3.0 - improving POSIX test on Cygwin platform

[John Cowan]

On Mon, Mar 21, 2022 at 5:19 AM  wrote:


> Sorry for the overly late reply. I'm not too familiar with cygwin, what
> should the tests report here? The cond-expand for "windows" should trigger
> on cygwin, how is it handling the permission bits (as compared to "raw"
> Windows systems)? Does it "fake" the normal UNIX permission bits?
>
Cygwin maps Windows ACLs into Posix permissions bits, but not 1-1;
consequently, you can't assume that setting the permissions bits and then
reading them back will necessarily produce the same results.  Therefore,
any test that depends on that property should be skipped altogether.

>
>
> felix
>
>
>

Re: Chicken 5 on Cygwin

[John Cowan]

On Mon, Mar 7, 2022 at 3:07 AM Peter Bex  wrote:

>
> I think it's the Cygwin project.  We are only responsible for ensuring
> that it builds and runs correctly on Cygwin.  But I'm sure they'll
> accept a patch if one of us sends it to them.
>
> The real problem is keeping it up to date.  Just updating it to 5.3.0
> should be a matter of sending a patch, but keeping it up to date,
> following up when things break etc is something that really requires
> someone who actively uses CHICKEN from Cygwin.
>

For the foreseeable future I'll once again be running Chicken on Cygwin and
building it myself, so I will definitely report if it breaks.  However, I
think it's enough to send Cygwin updates only for minor versions (5.3, 5.4,
etc.) and security patches, not for every single patch that's ever issued.

Re: Conditional include

[John Cowan]

On Sun, Jul 18, 2021 at 10:16 AM Lassi Kortela  wrote:


> R6RS implementations have a convention of appending the implementation's
> name to the filename.
> Best of all is the R7RS solution:
>

Oh, absolutely.  I didn't choose those four for no reason.  I wanted a pure
R7 system, an R5+ system that supports cond-expand, a hybrid R5-R6 system,
and a pure R6 system.  With those, it was easy to see how to extend it to
any system, pretty much.  (The worst case is R5RS without cond-expand: in
that case, you don't worry about the library and just load the
implementation, possibly with a shim file.)

Re: What are the long-term goals for R7RS in Chicken?

[John Cowan]

On Sun, Jul 18, 2021 at 7:43 AM  wrote:


> Anybody for a "-r7rs" option that does the above?
>

I'd love to see that.

Lassi: The fact that different Schemes have different conventions for where
their library files are is actually a great convenience to me when
developing SRFIs.  All the actual code goes into files named *-impl.scm (or
multiple names if there are multiple files).  Then each library file or
equivalent, which is where the differences are concentrated, is in an
implementation-specific place.  The library file for (foo bar) will be at:

Chibi:  foo/bar.sld
Chicken: foo.bar.scm
Guile: foo/bar.scm
Ypsilon: foo/bar.sls, or foo/bar.ypsilon.sls if it is Ypsilon-specific

And since each of these needs to be slightly different, that's a Good Thing.

Re: Actor model implementation, seeking feedback

[John Cowan]

On Sat, Jun 26, 2021 at 2:38 PM Vasilij Schneidermann 
wrote:


> 2. Cool that you use tweetnacl for encryption, but please don't use
> random numbers for nonces, that's just wrong. Nonces are not supposed to
> be secret, random or unpredictable, but unique numbers that do not
> repeat. Random numbers do repeat eventually.


*Any* numeric sequence will repeat eventually unless it grows without
bound, like a TAI timestamp.  But actually it's not enough that a nonce be
unique, otherwise 1, 2, 3, ... would be a perfectly good sequence of
nonces.  So you do want a long-period cryptographically strong random
sequence like ChaCha20 or Fortuna, or it will be possible to predict the
next nonce from the previous nonces.

Re: SRFI-144 - initial port

[John Cowan]

It would be great to use (chicken flonum) and, where necessary, direct FFI
calls and see if they are faster.  I was quite surprised when the Larceny
Scheme procedures were faster than the C ones, but from what I understand,
Larceny's FFI is expensive.

On Sun, Apr 18, 2021 at 3:41 PM Diego  wrote:

> Hi all,
>
> I've created an initial port of SRFI-144 that passes test-new-egg with
> release-info here:
>
> https://code.dieggsy.com/srfi-144/plain/srfi-144.release-info
>
> I'm thinking a next step might be to test the procedures with C
> equivalents in CHICKEN and see if it'd be best to switch to those.
> Currently, only the two procedures stated in the SRFI document are using
> the FFI, but I'm not sure if the claims made about Larceny hold for us as
> well.
>
> - Diego
>
>

Re: Chicken GUI options survey and questions.

[John Cowan]

On Fri, Mar 5, 2021 at 10:53 AM Matt Welland  wrote:


>  * pstk (probably not really an option, ancient look/feel).
>

Don't dismiss Tk too fast.  Here are the reasons Larry McVoy of BitMover
gives for using it in the GUIs of his company's products:

This question gets raised at least once a year here: why not do native
> GUIs? It is certainly possible to do so. We have done implementations of
> several of our GUIs in other toolkits. The arguments for doing so are
> compelling: better look and feel, native behavior, etc.



> The reasons for staying with Tcl/Tk are simple:
>


> Cost. The cost of creating 2-4 different implementations of each GUI
> interface is probably 3 times what it took us to get where we are today.
> But the cost does not end there. The cost extends to testing the GUIs on
> each platform as well as putting processes in place to make sure that the
> GUIs march forward in sync, i.e., if the Java revtool gets a new feature,
> that same feature needs to be added to the Linux, Windows, and Aqua GUIs.
> When we add up all the costs, it looks more like 6 times the effort.
>


> Functionality. Every time we go look at the other toolkits we find that
> they are not as powerful as the Tk toolkit. In particular, the canvas and
> text widgets are more useful than any others we have found.


I would add that Tcl/Tk Just Works anywhere you take it with essentially
zero customizations, and that there are a lot of themes you can use:  <
https://wiki.tcl-lang.org/page/List+of+ttk+Themes>.

Pros:
>  - super easy to learn and use
>  - Good range of widgets
>  - decent performance
>
> Cons:
>
>  - native widgets can look dated across platforms
>  - you are at the whim of the platform.
>(E.g. In my case Gnome broke using bgcolor in
> buttons which I was relying on.)
>  - Very difficult to install, still no Ubuntu package.
>

Re: New egg: SRFI-87: => in case clauses

[John Cowan]

Since the content of SRFI-87 is built in to the current Chicken, #:srfi-87
should be added to the output of `features` in (chicken-platform).

On Sun, Nov 22, 2020 at 3:16 AM Mario Domenech Goulart 
wrote:

> On Sat, 21 Nov 2020 16:40:21 -0800  wrote:
>
> > On Sat 21 Nov 2020 09:28:10 PM +01, Mario Domenech Goulart wrote:
> >>
> >> The support for `=>' in cond clauses has been added [to CHICKEN 4.9.0]
> >> to conform to R7RS, not exactly to support SRFI-87, as far as I can
> >> tell.  It is documented in
> >> http://wiki.call-cc.org/man/5/Module%20scheme#derived-expression-types
> >> (look for the documentation of `case')
> >
> > I have some questions about this.
> >
> > First, when packaging up the SRFI-87 egg, I ported over the SRFI-87
> > documentation over to svnwiki syntax and posted it on the Chicken wiki:
> >
> >   http://wiki.call-cc.org/eggref/5/srfi-87
> >
> > Because of that, it's now possible to find SRFI-87 and related search
> > terms in a search of the Chicken wiki.
> >
> > Should we keep this documentation?
>
> I think it should be removed.  The support for `=>' in `case' clauses is
> already documented in the manual.  Having a /eggref/5/srfi-87 page is
> going to be misleading, as it would indicate that a srfi-87 egg exists.
>
> > If we do, of course I can take myself out of the credits for packaging
> > up SRFI-87 as there'll be no SRFI-87 egg, and take out the Version
> > history section, and I could put in a note that SRFI-87 is supported in
> > Chicken core with a link to the page you linked to above.  Finally, if
> > we do keep it I can link to that page from our Supported Standards and
> > Chicken SRFI Support pages.  If we don't keep it, then I could just link
> > directly to:
> >
> >
> https://wiki.call-cc.org/man/5/Module%20scheme#derived-expression-types
> >
> > The other questions I have regard my investigation of SRFI-87 support in
> > Chicken.  When you mentioned that Chicken had SRFI-87 support, I tried
> > importing SRFI-87 in csi and succeded, tried uninstalling it (which also
> > succeeded), and the tried installing it again (which failed).
> >
> > If SRFI-87 is not an egg and if there's no explicit support of SRFI-87
> > in chicken, how was I able to (import srfi-87) and uninstall it, and why
> > couldn't I reinstall it?
>
> You could import it because you had a srfi-87 module installed on your
> system (probably your own egg).
>
> Regarding not being able to install it, did you call chicken-install
> from the directory with the sources of your egg?  If you didn't, that's
> expected to fail, as the egg has not been added to our egg servers.
>
> > Here's a log of what I did:
> >
> > %  csi
> > CHICKEN
> > (c) 2008-2020, The CHICKEN Team
> > (c) 2000-2007, Felix L. Winkelmann
> > Version 5.2.0 (rev 317468e4)
> > linux-unix-gnu-x86-64 [ 64bit dload ptables ]
> >
> > Type ,? for help.
> > #;1> (import srfi-87)
> > ; loading /home/me/apps/chicken/overlayfs/merged-chicken/lib/chicken/11/
> srfi-87.import.so ...
> > ; loading /home/me/apps/chicken/overlayfs/merged-chicken/lib/chicken/11/
> chicken.platform.import.so ...
> >
> > Note: re-importing already imported syntax: case
> > ; loading
> /home/me/apps/chicken/overlayfs/merged-chicken/lib/chicken/11/srfi-87.so ...
> > #;2>
> > %  chicken-uninstall srfi-87
> > About to delete the following extensions:
> >
> >   srfi-87
> >
> > Do you want to proceed? (yes/no) yes
> > removing srfi-87
> > %  chicken-install srfi-87
> > Server error:
> >
> > Error: [Server] no such extension or version
> > "srfi-87"
> > #f
> > Server error:
> >
> > Error: [Server] no such extension or version
> > "srfi-87"
> > #f
> >
> > Error: extension or version not found: "srfi-87"
> > %  csi
> > CHICKEN
> > (c) 2008-2020, The CHICKEN Team
> > (c) 2000-2007, Felix L. Winkelmann
> > Version 5.2.0 (rev 317468e4)
> > linux-unix-gnu-x86-64 [ 64bit dload ptables ]
> >
> > Type ,? for help.
> > #;1> (import srfi-87)
> >
> > Error: (import) during expansion of (import ...) - cannot import from
> undefined module: srfi-87
> >
> > Call history:
> >
> >   (import srfi-87)  <--
> > #;1>
> >
>
> All the best.
> Mario
> --
> http://parenteses.org/mario
>
>

Re: New C5 egg: SRFI-145: Assumptions

[John Cowan]

FWIW, SRFI 158 is fully downwardly compatible.

On Mon, Nov 9, 2020 at 1:40 PM Mario Domenech Goulart 
wrote:

> Hi Jeremy,
>
> On Mon, 09 Nov 2020 10:13:19 -0700 Jeremy Steward 
> wrote:
>
> > Ooh boy, is SRFI 158 ready to go?
> >
> > If that's the case, should we deprecate / remove SRFI 121 from the coop?
> >
> > I am currently the maintainer, but am happy to focus efforts on 158 over
> 121.
>
> Thanks for following up on that.
>
> Regardless of the decision on that, the srfi-121 egg will stay in the
> coop.  It can be deprecated, but never removed (considering the CHICKEN
> major version it is available for).
>
> All the best.
> Mario
> --
> http://parenteses.org/mario
>
>

Re: Some questions about concurrency (mostly)

[John Cowan]

On Sat, Nov 7, 2020 at 5:51 PM Chris Vine  wrote:


> For my elucidation, why?  The indentation of the code isn't ideal but
> the whole purpose of dynamic-wind is to handle code leaving the thunk in
> case of exception, application of a continuation object or regular
> return.
>

You're right about the second and third cases, but not the first.  Raising
an exception *simply* calls the current exception handler, which is then
free to return to the point of call like any other procedure.  In such a
case, the after-thunk is not run, since dynamically you are still inside
the main thunk.  This is a fundamental distinction between Lisp exceptions
and every other language's exceptions.

Only if the exception handler uses call/cc to escape back to the dynamic
context where the handler was set up is the after-thunk run.  This is done
for you automatically if you use `handle-exceptions` or `chicken-case` or
R7RS `guard`.

If you raise an exception with `abort` or `error`, then if the handler
returns, another exception "unexpected return from handler" is raised.

Note also that when the thread scheduler switches to a new thread, any
before- or after-thunks are not run, as the thread is supposed to be
unaware that the switch happened.



John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Would your name perchance be surname Puppet, given name Sock?
--Rick Moen

Re: New Egg: SRFI-151

[John Cowan]

Despite little variations in wording, I think that the best thing for
Chicken purposes is to say that the whole egg is MIT.

On Sat, Aug 8, 2020 at 12:59 PM Sören Tempel 
wrote:

> Mario Domenech Goulart  wrote:
> > Hi Sören,
>
> Hello Mario,
>
> > My only remark would be regarding the license, which AFAIK should be
> > MIT.  John Cowan would be able to clarify that.
>
> I went through the license comments in these files and bitwise-60.scm
> and bitwise-core.scm have a license which is identified in the CHICKEN
> wiki as „Free Use” (I have actually never seen this license before):
>
> http://wiki.call-cc.org/eggs-licensing#free-use
>
> The other *.scm files with the exception of (chicken-test.scm and
> srfi-151.scm) have a public domain license header. For this reason, I
> used "Public Domain/Free Use" as the license string, as recommended by
> the eggs-licensing wiki page.
>
> The files chicken-test.scm and srfi-151.scm have no license header.
> However, according to Arthur Gleckler they are in fact licensed under
> the MIT license [1]. I would have added a corresponding license header
> (as suggested by Arthur) but I am unsure who the copyright holders for
> these files are.
>
> > Some files in the repository are not really important for the egg (e.g.,
> > .html files, Scheme files which are not included by the CHICKEN
> > implementation). They would be part of the egg, but not really used.
> > Not a big deal, IMO, but since your repo is a fork to make the code
> > CHICKEN-specific, maybe it would be worth removing the unnecessary
> > files.
>
> That's also something I noticed. Should I just remove these files from
> the repository or would it be preferable to create a meta-file which
> ensures that only the scheme files are included in the egg [2]?
>
> > Fun fact: I had packaged SRF-151 for CHICKEN 5 a couple of hours before
> > I saw your pull request in GitHub (talk about coincidence).  I just
> > didn't make the egg available because I hadn't ported the documentation
> > to the wiki format.  I hope providing documentation in wiki format in
> > your plans.  If so, and if you want a wiki account, please send me the
> > username you intend to use and the hash of your password (it can be
> > generated with "openssl passwd -apr1").  Having the documentation in the
> > wiki is nice, as symbols exported by the egg are indexed by
> > api.call-cc.org.
>
> I didn't know that there was a specific documentation format for the
> wiki. Where can I find more information about it? However, I actually
> just need this egg for a small scheme project of mine. Since my spare
> time is rather limited these days I cannot promise that I get around to
> adding documentation in the wiki format. So far, I relied on the
> documentation provided by the SRFI. I can also include the SRFI code
> directly in the repository of my other project if that's a blocker for
> you. I just thought this SRFI might be useful for other CHICKEN users as
> well.
>
> Thanks for your feedback so far!
>
> Greetings,
> Sören
>
> [1]:
> https://github.com/scheme-requests-for-implementation/srfi-151/pull/4#issuecomment-669245870
> [2]: https://wiki.call-cc.org/releasing-your-egg#meta-file-distribution
>
>

Re: Tidy way to test and set when using test egg?

[John Cowan]

Mixing definitions and expressions in a block isn't actually legal Scheme,
though it does work in Chicken.  All defines are supposed to come first and
all expressions afterwards.  Since the test library is shared with Chibi,
and since Chibi doesn't allow this extension, I can't see adding this to
the library.

On Fri, Jan 10, 2020 at 10:18 AM Matt Welland 
wrote:

> I find myself doing stuff like this very often when writing tests using
> the test egg:
>
> ;; A trivial example where  the function under test is "-"
> (define data #f)
> (test #f 1 (let ((res (- 2 1)))(set! data res) res))
>
> I'd really prefer to do something like:
>
> (test-and-define data #f 1 (- 2 1))
>
> But the closest I could get was:
>
> (define-syntax test-and-set
>   (syntax-rules ()
> ((_ name arg1 arg2 body ...)
>  (test arg1 arg2
>   (let ((res (begin body ...)))
> (set! name res)
> res
> )
>
> So I can do:
>
> (define data #f)
> (test-and-set data #f 1 (- 2 1))
>
> Questions:
>
> 1. Is there a generally better way to test and gather the result for use
> in downstream tests?
>
> 2. Is there a way to write a macro that can create the toplevel binding?
>
>
> --
> --
> Complexity is your enemy. Any fool can make something complicated.
> It is hard to keep things simple. - Richard Branson.
>

Re: Trying to understand chicken limitations

[John Cowan]

Procedures and code files that contain both Scheme and C must be compiled,
but the resulting compiled code  can be loaded into the environment and
invoked from the interpreter.  Obviously pure C files must be compiled by a
C compiler.

On Mon, Dec 23, 2019 at 12:20 AM Iain Duncan 
wrote:

>
>
> (trimmed)
>
>>
>>
>>> I'm hoping to be able to achieve some sort of hot coding, where
>>> functions and definitions in my scheme environment may get overwritten by
>>> the user doing live coding.
>>>
>>
>> That's practical. Eval maintains a global environment which can be
>> changed by evaluating new definitions.
>>
>> Are there limitations on what kind of thing can be dynamically evaluated
>>> or can I evaluate anything, but with perhaps a performance penalty?
>>>
>>
>> You can evaluate anything that doesn't need access to the foreign
>> function interface.
>>
>
> Thank you for the explanations. For the above, I'm not sure I quite
> understand. Does this mean that if I have real-time scheme code sent to the
> plugin, and it will be run by eval, that this code can not calls functions
> that are defined in C and made available to scheme? Can it call functions I
> have precompiled that call into C? Or if I'm misunderstanding, do you mind
> expanding on what the last statement means for a newbie?
>
> thanks
> Iain
>
>

Re: Trying to understand chicken limitations

[John Cowan]

On Sun, Dec 22, 2019 at 7:55 PM Iain Duncan 
wrote:

Regarding your comments about compiling, this is the area I got most
> confused about.
> - Assuming I have an embedded chicken REPL, does the code I send to the
> repl get compiled to C before it exectutes? Or can I embed an interpreter
> that is running chicken?
>

The REPL does not compile code.  The interpreter is available as the
standard Scheme procedure eval.
There is also an egg (library) called compile-file, which invokes the
Chicken and gcc/clang compilers to generate a shared library which can then
be loaded into your program.  Of course that's slow.

- Am I correct in understanding from your explanation that I could have
> precompiled scheme functions and have dynamic scheme code (as in, sent to
> the process in real time from the user) evaluate and call those compiled
> functions for more performance?
>

Yes, definitely.


> - Will it be possible to replace functions or other definitions on the
> fly?
>

Yes, you can do that.


> I'm hoping to be able to achieve some sort of hot coding, where functions
> and definitions in my scheme environment may get overwritten by the user
> doing live coding.
>

That's practical. Eval maintains a global environment which can be changed
by evaluating new definitions.

Are there limitations on what kind of thing can be dynamically evaluated or
> can I evaluate anything, but with perhaps a performance penalty?
>

You can evaluate anything that doesn't need access to the foreign function
interface.



John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
To say that Bilbo's breath was taken away is no description at all.  There
are
no words left to express his staggerment, since Men changed the language
that
they learned of elves in the days when all the world was wonderful. --The
Hobbit

Re: Trying to understand chicken limitations

[John Cowan]

On Sun, Dec 22, 2019 at 1:05 PM Iain Duncan 
wrote:


> and I want to host a scheme environment in a C plugin using the Max SDK.
>

Chicken is a little tricky to use as an embedded Scheme, though it's very
good at embedding C.  (Chez cannot be embedded at all; it has to be the
main program.)

Guile is designed for embedding.  As for S7, I would use Chibi instead:
it's more modern and probably faster.



John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Economists were put on this planet to make astrologers look good.
--Leo McGarry

>

Re: RAM usage of applications?

[John Cowan]

On Sat, Nov 30, 2019 at 10:55 AM Lassi Kortela  wrote:

> >> The Chicken DLL is about 3.4MB, of which a good deal will be relocation
> tables and such.  I'm a Cygwin user, so my C library is included in
> cygwin1.dll, which is about the same size [...]  The native Windows C
> library, also a DLL, is about 1MB, depending on the OS version [...]
>

Cygwin1.dll doesn't use the native C library at all; it lives directly on
top of the Win32 kernel and the lower-level WinNT Executive.


>
> > So the RAM footprint at run time for the executable code (excluding the
> OS) will be on the order of 12KB + 3.4MB + 3.4MB + 1MB, so about 8MB.  I
> think that is a better measure when estimating the amount of RAM needed to
> run an application.
>

I added (let loop () (loop)) after the (print "Hello world") so I could
watch the process, and Windows is charging it with 2.6 MB.  I don't know
how, if at all, Windows allocates DLL memory to applications with the DLL
open.


> The RAM taken by the DLLs ought to be shared with other running programs
> using the same DLLs. If we assume the user's program is the only Chicken
> program running at the time, but there are other Windows/Cygwin
> programs, the Chicken program would be 12KB + 3.4MB on top of those.
>

That's my situation while running this program.



John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
The first thing you learn in a lawin' family is that there ain't
no definite answers to anything.  --Calpurnia in To Kill A Mockingbird

Re: RAM usage of applications?

[John Cowan]

On Sat, Nov 30, 2019 at 10:12 AM Marc Feeley 
wrote:

Interesting.  I assume the 12K excludes dependent DLLs.  Do you know if on
> Windows there’s a DLL for the Chicken runtime library and for the C library
> (and others), and their size?
>

The Chicken DLL is about 3.4MB, of which a good deal will be relocation
tables and such.  I'm a Cygwin user, so my C library is included in
cygwin1.dll, which is about the same size (it uses newlib, not glibc, but
has to provide full Posix plus much other Linux stuff).  The native Windows
C library, also a DLL, is about 1MB, depending on the OS version; Chicken
provides the same interface on Posix and on Windows, but much of it (fork,
obviously) will throw runtime exceptions on Windows.  Of course, Windows
itself is also in DLLs.   Chicken does not have a run-on-bare-metal option;
it depends on the presence of either Posix or Windows.



John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Yes, chili in the eye is bad, but so is your ear.  However, I would
suggest you wash your hands thoroughly before going to the toilet.
--gadicath

Re: RAM usage of applications?

[John Cowan]

On Sat, Nov 30, 2019 at 3:03 AM egarrulo  wrote:


> I mean full support for every language feature. I guess that some
> language features - like "eval" and macros - may impact memory
> requirements significantly. Please note that I am not a Scheme
> programmer (yet).
>

Macros are done at compile time and cost nothing at run time.


> Sure, but there should be a lower limit, due to the runtime. For
> instance, a "Hello World" program compiled with SBCL (Common Lisp) can
> require dozens of megabytes. Anything else that the application does,
> will add to that.
>

The Scheme program (print "Hello world") compiled on Windows and stripped
produces a 12K executable.  Chicken, like many other Schemes but Common
Lisp, is modularized: if you don't use a feature (within reason) it is not
included.



John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
May the hair on your toes never fall out!  --Thorin Oakenshield (to Bilbo)

[Chicken-users] Changing the chickadee home page to C5

[John Cowan]

Currently chickadee.call-cc.org and api.call-cc.org redirect to
api.call-cc.org/4/doc.  This grows more inappropriate with every new
release of Chicken 5, indeed with every day that passes.  It's time to
change it, I think, to redirect to api.call-cc.org/5/doc instead.

In addition, there should be reciprocal links between /4/doc and /5/doc.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] thoughts on alternate "posits" / "unums" instead of traditional floats?

[John Cowan]

On Tue, Jul 9, 2019 at 2:07 PM Peter Bex  wrote:

They could be, but Scheme does not really allow for multiple types
> of inexact numbers.


Actually it has no problem with them.  There are literals for up to four
separate inexact types, using S, F, D,  and L as exponent markers, and
arithmetic just requires that when two float types meet the shorter is
widened  and that in systems without rationals, the widest available float
is returned from division.  The flags and the widening coercion are
inherited from Common Lisp.

Currently Kawa (which inherits its two floating types from Java) supports
32-bit floats with the S or F flag, as well as standard 64-bit floats with
the E, D, or L flag.  So does Racket/C, but Racket/Chez does not, and it
probably never will (since Chez does not) except perhaps as a separate type
that doesn't participate in the numeric tower.

It would also slow everything down even further
> due to even more dispatching.


That's for sure.  It's one of the reasons why ad hoc polymorphism is not
really Scheme's thing, with the big exceptions of numbers and ports; the
more types you support ad hoc, the worse your performance is.


> So it sounds like a modified C compiler and/or FPU would be the way to go
> for this.


Hardware support for posits will come shortly after the Devil dies of
exposure.


John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
What asininity could I have uttered that they applaud me thus?
--Phocion, Greek orator
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] SRFI-38 notation

[John Cowan]

https://raw.githubusercontent.com/ashinn/chibi-scheme/master/lib/srfi/38.scm is
public domain, uses a hash table, and should be reasonably portable.
You'll need to remove the references to read-object, which are a
Chibi-specific lexical extension providing record literals.

On Thu, Jul 4, 2019 at 3:48 AM Sven Hartrumpf  wrote:

> Hi.
>
> Are there any plans to support SRFI-38 (or similar functionality as
> provided
> by R7RS) in Chicken 5 natively?
> I use the reference implementation of SRFI-38, but reading of
> s-expressions with many
> thousand sharings becomes a bottleneck, e.g. 3 hours instead of 1 second.
> (The reason is the use of a list (instead of a vector) for storing pairs of
> (label . datum).)
>
> Ciao
> Sven
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [ANN] CHICKEN 5.1.0 release candidate available

[John Cowan]

On Sat, Jun 8, 2019 at 9:08 AM Peter Bex  wrote:

> HHere's a suggested test procedure:
>
>   $ make PLATFORM= PREFIX= install check
>   $ /bin/chicken-install pastiche
>
> Operating system: Cygwin on Windows 10
> Hardware platform: x86_64
> C Compiler: GCC 7.4.0
> Installation works?: yes
> Tests work?: can't tell, see below
> Installation of eggs works?: yes
>

The output of "make test" was over 20,000 lines, some of which do have the
string "fail" in them.  I've posted it at
<http://vrici.lojban.org/~cowan/faulty> if anyone wants to take a look.


John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Police in many lands are now complaining that local arrestees are insisting
on having their Miranda rights read to them, just like perps in American TV
cop shows.  When it's explained to them that they are in a different
country,
where those rights do not exist, they become outraged.  --Neal Stephenson
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] for those who have interest in procedure objects decoration

[John Cowan]

On Wed, May 22, 2019 at 9:28 AM Peter Bex  wrote:


> So it makes sense they don't have a separate entry.  It's like having =>
> as a separate entry; it doesn't exist either except in cond and case
> forms.
>

Nevertheless, it's a good idea to bind unquote, unquote-splicing, and =>
to macros that throw an error,
so that you can safely rebind them as ordinary variables if you want to.

  <https://lists.nongnu.org/mailman/listinfo/chicken-users>
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Humpty Dump Dublin squeaks through his norse
Humpty Dump Dublin hath a horrible vorse
But for all his kinks English / And his irismanx brogues
Humpty Dump Dublin's grandada of all rogues.  --Cousin James
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Back from the dead: pstk

[John Cowan]

If it's not too hard, you might want to extract your changes from your new
git repo, drop the repo, use reposurgeon (a general VCS converter and
editor), and reapply your changes.  That way the history is preserved and
you don't need multiple repos.

On Tue, Feb 26, 2019 at 8:49 AM  wrote:

> Hello,
>
> As promised, I've ported the pstk egg to Chicken 5, and would like to
> take over as maintainer.
>
> https://github.com/utz82/pstk
> https://raw.githubusercontent.com/utz82/pstk/master/pstk.release-info
>
> License has been reverted to BSD 2-clause, as the main source actually
> never was in the public domain.
>
> I threw out the SVN backlog when importing to git, so maybe the C4 egg
> should continue to use the old SVN repository instead. Otherwise pstk
> should replace Chicken/Tk as the "maintained" Tk egg at this point. I do
> plan on maintaining both 4 and 5 versions, in any case.
>
> Haven't done any changes to the code for now, other than C5
> compatibility tweaks, and setting default tclsh to tclsh8.6. I'm amazed
> that this decade-old code works on C5 pretty much out of the box.
>
> Best wishes,
> -Heinz
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Tangerine Edition final results available

[John Cowan]

ed about on the Orange Edition straw poll, all
were well-supported (with volunteers to implement some of them) except the
prime number library at <
https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/PrimesGauche.md>.
There was also a one-vote majority against the TalliesCowan (descriptive
statistics) library, but as there is a volunteer to implement it, I'll
leave it on the docket for now.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
weirdo:When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [scheme-reports-wg2] Re: Tangerine Edition penultimate report: how I voted, how you're voting

[John Cowan]

On Fri, Jan 18, 2019 at 3:20 PM Ivan Raikov  wrote:


> Isn't the difference with R6RS that R7RS-large draws extensively on
> SRFIs which are indeed attempts to codify existing practices?
>

SRFIs don't always codify existing practice, including the SRFIs drawn on
in past, present, and future R7RS-large ballots.  The original intention of
the
Steering Committee, I think, had nothing to do with SRFIs; I simply decided
when writing the charter (which the committee approved) to leverage both
existing and to-be-written SRFIs in order to be able to create R7RS-large
piecemeal, which has always seemed to me the only practical approach.

That said, SRFIs often do refer to existing implementations, or
implementations
of languages other than Scheme.


>
> On Thu, Jan 17, 2019 at 5:15 PM Per Bothner  wrote:
> >
> > On 1/16/19 6:27 AM, John Cowan wrote:
> > > So what is happening is that people are voting for more rather than
> less, as with the Red Edition.  This encourages me that I'm going in a
> sensible direction with the large language.
> >
> > For the record, I'm extremely leery of the more-is-better approach.
> > We seem to be adding a large number of very large APIs, which seems
> > to be contrary to the Scheme ideal of small well-chosen primitives
> > that work synergistic well together.  People were unhappy with R6RS
> > because of its size and that so much of it was invention rather than
> > codifying existing practice.  R7RS-large is the same - but much more so.
> > --
> > --Per Bothner
> > p...@bothner.com   http://per.bothner.com/
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scheme-reports-wg2+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] R7RS large library aliases

[John Cowan]

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 of
> an
> > editorial nature, except in extremely rare cases.
>
> I know, I just mean that chicken should add an additional
>
> (define-library (scheme list)
>   (import (srfi :1))
>   (export ...))
>
> somewhere in the srfi-1 egg (or core, depending on where the srfi is
> actually implemented). All other Schemes should do the same, so that we
> can actually *use* the new names portably :-/
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] R7RS large library aliases

[John Cowan]

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 6:48 AM Peter  wrote:

> 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*
> relevant srfis, making it hard to only use selected ones.
>
> Greetings,
> Peter
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Tangerine Edition penultimate report: how I voted, how you're voting

[John Cowan]

On Thu, Jan 17, 2019 at 8:15 PM Per Bothner  wrote:

For the record, I'm extremely leery of the more-is-better approach.
> We seem to be adding a large number of very large APIs, which seems
> to be contrary to the Scheme ideal of small well-chosen primitives
> that work synergistic well together.


I don't believe that that idea ever applied to the Scheme library, otherwise
the list primitives would have been pair?, car, cdr, cons, null?, set-car!,
and
set-cdr!, and possibly not even the last two.

Allow me to quote the first paragraph of Olin Shivers's rationale for SRFI
1, itself
a "very large API" of 149 procedures, especially when compared to the
7 minimal procedures above and the 50 R6RS procedures, yet SRFI 1 is
very popular and 24 of the 32 Schemes for which I have SRFI data
implement it.

The set of basic list and pair operations provided by R4RS/R5RS Scheme is
> far from satisfactory. Because this set is so small and basic, most
> implementations provide additional utilities, such as a list-filtering
> function, or a "left fold" operator, and so forth. But, of course, this
> introduces incompatibilities -- different Scheme implementations provide
> different sets of procedures.


The SRFI 43 rationale (by Taylor Campbell) begins similarly:

R5RS provides very few list-processing procedures, for which reason SRFI 1
> (list-lib) exists. However, R5RS provides even fewer vector operations —
> while it provides mapping, appending, et cetera operations for lists, it
> specifies only nine vector manipulation operations —: [list omitted] .
> Many Scheme implementations provide several vector operations beyond the
> miniscule set that R5RS defines (the typical vector-append, vector-map, et
> cetera), but often these procedures have different names, take arguments in
> different orders, don't take the same number of arguments, or have some
> other flaw that makes them unportable. For this reason, this SRFI is
> proposed.


Finally, here's Olin again in SRFI 33, bitwise operations:

If you believe in "small is beautiful," then what is your motivation

for including anything beyond BITWISE-NAND?


Quant. suff.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here.  --DeXiderata by Sean McGrath
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Tangerine Edition penultimate report: how I voted, how you're voting

[John Cowan]

Sorry, left out the voting link this time:  it's
http://tinyurl.com/tangerine-ballot for the vote, and
http://tinyurl.com/orange-straw-poll for the Orange Edition straw poll
(guidance to the editor on what should appear in the next poll).

On Wed, Jan 16, 2019 at 9:27 AM John Cowan  wrote:

> Well, there are two weeks to go on the Tangerine Edition ballot (cutoff is
> 12 noon UTC on Saturday, February 2).  So far, 18 people have voted,
> including me.  For the Red Edition we had 30 voters, so I hope some of you
> who haven't voted yet will take an interest and give us your views.
> Remember that you don't have to vote on all issues: choosing "No vote" is
> equivalent to abstaining, which does not affect the outcome, as votes are
> decided by a majority of the votes cast.
>
> As in the Red Edition, the choice of string library (issue #1) has been
> the most controversial.  There was no majority vote cast in the Red
> Edition, so the issue is being reballoted.  Currently, the index-based SRFI
> 152, which is meant to be a simple basic string library, holds a majority
> position, but only by a single vote.  There is a strong minority for the
> original SRFI 13, which is a superset (with a few deviations) of 152.  SRFI
> 130, which is cursor-based, has only a single vote.  Three write-in votes
> were cast for SRFI 140, which I excluded from Tangerine because it provides
> adjustable-length strings.  These, like all other features that can't be
> implemented (at least minimally) on top of R7RS-small, have been postponed
> to the Green Edition.  I voted for SRFI 152.
>
> Issue #4, supplementing the Red Edition's SRFI 127 generators with their
> dual, accumulators, is substantially beating the alternatives of status quo
> and no library.  Issue #6 is about bitwise operations on integers, and the
> comprehensive SRFI 151 is dominating the R6RS alternative.  The same thing
> is happening with fixnums (issue #7) and flonums (issue #8), where SRFIs
> 143 and 144, both supersets of R6RS, are getting more support than the R6RS
> alternatives. SRFI 160 is a superset of SRFI 4 that provides homogeneous
> vectors (issue #10), and it too is winning, though by a lesser margin.
> Surprising to me is that for the combinator-based formatting library (issue
> #11), the combinator-based SRFI 159 is in a majority position over SRFI 48,
> the traditional template-based (as in Common Lisp) alternative.
> Essentially all the remaining issues are yes/no/abstain, and yes is
> dominant all down the line, though a little less so for ratios (issue #13)
> and exact complex numbers (issue #16).  I voted with the majority for all
> of these except exact complex numbers.
>
> So what is happening is that people are voting for more rather than less,
> as with the Red Edition.  This encourages me that I'm going in a sensible
> direction with the large language.
>
> --
> John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
> It was dreary and wearisome.  Cold clammy winter still held sway in this
> forsaken country.  The only green was the scum of livid weed on the dark
> greasy surfaces of the sullen waters.  Dead grasses and rotting reeds
> loomed
> up in the mists like ragged shadows of long-forgotten summers.
> --LOTR, "The Passage of the Marshes"
>
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Tangerine Edition penultimate report: how I voted, how you're voting

[John Cowan]

Well, there are two weeks to go on the Tangerine Edition ballot (cutoff is
12 noon UTC on Saturday, February 2).  So far, 18 people have voted,
including me.  For the Red Edition we had 30 voters, so I hope some of you
who haven't voted yet will take an interest and give us your views.
Remember that you don't have to vote on all issues: choosing "No vote" is
equivalent to abstaining, which does not affect the outcome, as votes are
decided by a majority of the votes cast.

As in the Red Edition, the choice of string library (issue #1) has been the
most controversial.  There was no majority vote cast in the Red Edition, so
the issue is being reballoted.  Currently, the index-based SRFI 152, which
is meant to be a simple basic string library, holds a majority position,
but only by a single vote.  There is a strong minority for the original
SRFI 13, which is a superset (with a few deviations) of 152.  SRFI 130,
which is cursor-based, has only a single vote.  Three write-in votes were
cast for SRFI 140, which I excluded from Tangerine because it provides
adjustable-length strings.  These, like all other features that can't be
implemented (at least minimally) on top of R7RS-small, have been postponed
to the Green Edition.  I voted for SRFI 152.

Issue #4, supplementing the Red Edition's SRFI 127 generators with their
dual, accumulators, is substantially beating the alternatives of status quo
and no library.  Issue #6 is about bitwise operations on integers, and the
comprehensive SRFI 151 is dominating the R6RS alternative.  The same thing
is happening with fixnums (issue #7) and flonums (issue #8), where SRFIs
143 and 144, both supersets of R6RS, are getting more support than the R6RS
alternatives. SRFI 160 is a superset of SRFI 4 that provides homogeneous
vectors (issue #10), and it too is winning, though by a lesser margin.
Surprising to me is that for the combinator-based formatting library (issue
#11), the combinator-based SRFI 159 is in a majority position over SRFI 48,
the traditional template-based (as in Common Lisp) alternative.
Essentially all the remaining issues are yes/no/abstain, and yes is
dominant all down the line, though a little less so for ratios (issue #13)
and exact complex numbers (issue #16).  I voted with the majority for all
of these except exact complex numbers.

So what is happening is that people are voting for more rather than less,
as with the Red Edition.  This encourages me that I'm going in a sensible
direction with the large language.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
It was dreary and wearisome.  Cold clammy winter still held sway in this
forsaken country.  The only green was the scum of livid weed on the dark
greasy surfaces of the sullen waters.  Dead grasses and rotting reeds loomed
up in the mists like ragged shadows of long-forgotten summers.
--LOTR, "The Passage of the Marshes"
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Change to SRFI under ballot: u1vectors removed from SRFI 160

[John Cowan]

I have sent a request to the SRFI Editor to remove all references to
u1vectors (bitvectors) from SRFI 160, which is a part of the Tangerine
Edition ballot.  This is being done not because they are not useful, but
because they are different enough in both specification and implementation
from the other homogeneous vectors to deserve to be put into a future SRFI
of their own, which will be balloted in a later edition.

If anyone wishes to change their vote as a result of this change (I hope
not), simply go to http://tinyurl.com/tangerine-ballot and submit a second
form.  You can set all other questions to "No vote" and I will merge your
two ballots. In all cases except "No vote", the later ballot will take
precedence.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Voting on the Tangerine Edition of R7RS-large begins!

[John Cowan]

Nobody has voted in the last eight days.  To make reaching the forms
easier, I have created two short URLs:

http://tinyurl.com/tangerine-ballot

http://tinyurl.com/orange-straw-poll

You only need to register if you have not voted in a Scheme election
before, whether for R7RS-small, R6RS, or the Steering Committee.  Otherwise
you only have to care about Scheme standardization.

Please vote!
-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Said Agatha Christie / To E. Philips Oppenheim
"Who is this Hemingway? / Who is this Proust?
Who is this Vladimir / Whatchamacallum,
This neopostrealist / Rabble?" she groused.
--George Starbuck, Pith and Vinegar
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Voting on the Tangerine Edition of R7RS-large begins!

[John Cowan]

Apologies to those who receive multiple copies of this posting.

There are two ballots to vote on this time, the Tangerine Edition ballot,
which decides what goes into R7RS-large, and the Orange Edition straw poll,
which helps to decide what will go on the ballot for the future Orange
Edition.  Voting on both is open until the end of January.  Please vote!

Links to the ballots, which are Google Forms, will be sent to
scheme-reports-wg2 ONLY.  However, you can also reach the forms at
at <
https://docs.google.com/forms/d/1XQNvIzijmCxHgnaRq31u9MogloG0YWDaWKBs-J9CCTA>
(Tangerine) and <
https://docs.google.com/forms/d/1qn1Ut7tR5bzXyWOrxpbLu5O7rJJ5_m2HhAeG8YqfgGI/>
(Orange).  You don't need a Google account.  Let me know if anything goes
wrong.

Here are the detailed instructions for the Tangerine Edition ballot:

This is a ballot to decide which SRFIs are to be included in the Tangerine
(data structures and numerics) Edition of R7RS-large.  This is the second
of about 8 editions, so only certain topics are being voted on now.   If
you are seeing this ballot, you are a member of Working Group 2 provided
you actually vote.  However, if you have not voted on a Scheme ballot or
ratification before, please send an email to
scheme-reports-...@groups.google.com giving your name and a short
explanation of your interest in Scheme.

Choose "No vote" if you wish to abstain, which means that your vote on this
question will not be counted.  Note that if one person votes for
alternative A, and two people for alternative B, and everyone else
abstains, alternative B wins.  That is because we are going by a majority
of the legal votes cast for each ballot question.  If no alternative
achieves a majority, the question will be reballoted at a later date.

Otherwise, choose "None" if you wish not to include a library of the type
described in R7RS-large, or choose one of the SRFIs or R6RS according to
the choices given.  You can also choose "Other" for a write-in vote.

There are also some yes/no questions on the ballot, for which the answers
are "No vote", "No", and "Yes".

If you want to revote, just vote again using the same name.  Only the last
vote is counted.  The ballot closes at the last moment of Friday, February
1, 2019, in any time zone, which is equivalent to noon February 2 UTC.

All ballots will be made public.  If you object to using Google Forms (you
do not need a Google account), post your ballot in an email to
scheme-reports-...@groups.google.com.  As an absolute fallback, send an
email to co...@ccil.org and I will post your vote for you.  Ballots posted
to other fora will be used if I see them, but are not formally supported.

And here are the instructions for the Orange Edition straw poll:

Please vote on the proposals you think should be considered for
R7RS-large.  This vote is not binding, but provides guidance to the editor
about which pre-SRFI proposals should be converted into SRFIs and which
should not.  Ones that are already SRFIs or which have simple or existing
implementations are excluded.

There are four options in all cases:  "No vote", "No", "Yes", and
"Volunteer"; the last means that you are volunteering to write the
implementation.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
weirdo:When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] pp and write ignore keyword-style

[John Cowan]

On Wed, Nov 21, 2018 at 1:35 AM Sven Hartrumpf  wrote:

But my argument is about interoperability between implementations, e.g.
> reading with Scheme implementation A code written by Scheme implementation
> B.
>

I fear that is a lost cause.  Of 22 Schemes that I tested, only 8 support
keywords at all.  (Racket has something it calls keywords, but they are not
self-evaluating or even expressions at all: only quoted keywords are
expressions. They use SRFI 88 syntax.)

Each of the :foo and foo: styles are supported by most of the 9, whereas
the SRFI-88 style was supported by only 4.  See
https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/KeywordSyntax.md for
details

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Business before pleasure, if not too bloomering long before.
--Nicholas van Rijn
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] http-client: distinguishing between responses 301 and 302

[John Cowan]

The difference between 301 and 302 is primarily relevant to crawlers and
caches.  I agree that it needs to exist, but not clear that a
general-purpose client needs to expose it.  Can you explain your use case
more clearly?  Thanks.

On Thu, Oct 18, 2018 at 1:20 PM Norman Gray  wrote:

>
> Greetings.
>
> In http-client, is there any way of distinguishing between server
> responses 301 and 302?
>
> In test code, I want to confirm that a server is responding with the
> correct redirection code, but can't quite get there.
>
> If I make a request using call-with-input-request and the server
> produces a redirection, then the client code follows the redirection.
>
> If I parameterise that with (parameterize ((max-redirect-depth 0)) ...),
> then the client library doesn't follow the redirection but instead
> raises (exn http redirect-depth-exceeded).  That's almost there, except
> that the exception doesn't contain information about _which_
> redirection, 301 or 302, prompted it.  Using (condition->list), I get
>
> redirect-depth-exceeded: e=# redirect-depth-exceeded)>
> list=(
> (exn (arguments ("http://localhost:8081/host/;))
>(message "Maximum number of redirects exceeded")
>(location send-request))
> (http)
> (redirect-depth-exceeded
>(request #)
>(new-uri # "top" "host") query=() fragment=#f>)
>(uri # "host" "") query=() fragment=#f>)))
>
> The documentation for call-with-input-request* doesn't suggest that it
> behaves differently from call-with-input-request in this respect.  And
> although call-with-response mentions the possibility of redirects, and
> multiple calls to 'reader', it doesn't suggest that the reader procedure
> has any access to the response headers.
>
> Is there any other way of getting this status code, or do I feel an
> enhancement request coming on?
>
> Possibly better than this handling of redirect-depth-exceeded would be a
> parameter follow-redirects? which defaults to #t, or having
> call-with-input-request return normally (ie, without the exception) in
> the particular case that max-redirect-depth is 0.
>
> I'm using Chicken 4, but as far as I can see, the Chicken 5 http-client
> is identical in this behaviour.
>
> Best wishes,
>
> Norman
>
>
> --
> Norman Gray  :  https://nxg.me.uk
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] Request for a small Chicken library in C

[John Cowan]

I haven't written any C code for Chicken since version 3 days, and to save
me some time re-learning., I'd like to see if anyone's willing to write
some for me.  What I need is an implementation of the four native IEEE
procedures (single and double ref and set) in the R6RS bytevectors library,
documented at <
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-3.html#node_sec_2.8>.
I can't find any Scheme implementations that are both portable and portably
accurate (I've experimented with SRFI 56 and the sample R6RS implementation
at r6rs.org).

The contract for the four routines is that they accept a byte vector and an
offset, and read or write an inexact number into the bytevector as 4 or 8
bytes with the native endianism, depending on whether it is an ieee-single
procedure or an ieee-double procedure.  The easiest way to do this in C is
with a couple of unions that map a float or double onto an array of 4 or 8
chars, like these:

union float_map {
  float f;
  char c[4];
}

union double_map {
  double d;
  char c[4];
}

This is in aid of SRFI 160, the proposed heterogeneous vector library for
R7RS-large.  Can anyone help?  Thanks.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [Chicken-hackers] Some questions about CHICKEN 5 eggs and modules

[John Cowan]

On Wed, Aug 29, 2018 at 4:21 PM  wrote:


> I don't see the motivation for installing files outside of the chicken
> installation
> tree, so it is not clear to me what you want to achieve with this.
>

>From what I understand (which may be wrong) it's so that chicken-install
can put a
file in a place expected by some external library.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
If I read "upcoming" in [the newspaper] once more, I will be downcoming
and somebody will be outgoing.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Broken `utf8#string-fill!`?

[John Cowan]

 On Thu, Jul 12, 2018 at 6:10 PM, John Cowan  wrote:

> You can't fill a literal string; you have to treat it as immutable.
>

Actually it's not about mutability.  There is a documented restriction
("Attempting to mutate literal strings will result in an error if the
mutated size does not occupy the same number of bytes as the original. This
is standards compliant, since the programmer is not supposed to attempt to
mutate literal values, but it may be a little confusing since the error is
inconsistent.").  But that is not the issue here, since both #\j and
#\Space are single-byte characters, and in fact (string-fill! (string #\j
#\j) #\space) fails in the same way with the utf8 egg but works without the
egg.  So it's a bug, but I would recommend that you avoid mutating strings
altogether.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Broken `utf8#string-fill!`?

[John Cowan]

You can't fill a literal string; you have to treat it as immutable.

On Thu, Jul 12, 2018 at 4:09 PM, Henry Hu  wrote:

> Hello,
>
> `utf8#string-fill!` isn't working for me.  Anyone experiencing this
> problem?
>
> CHICKEN
> (c) 2008-2017, The CHICKEN Team
> (c) 2000-2007, Felix L. Winkelmann
> Version 4.13.0 (rev 68eeaaef)
> linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
> compiled 2017-12-11 on yves.more-magic.net (Linux)
>
> #;1> (use utf8)
> #;2> (string-fill! "jj" #\space)
>
> Error: utf8 trailing char overflow
> ""
> 1
>
> Call history:
>
>   (string-fill! "" #\space)
>   (string-fill! "" #\space)<--
>
> Thanks,
> Henry
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Reason to Celebrate

[John Cowan]

Congratulations.  A bit far away from me (I'm in New York City), but enjoy
anyway.

On Sun, Jul 1, 2018 at 6:20 PM, Thomas Chust  wrote:

> Dear friends,
>
> hopefully you're all doing well!
>
> I have reason to celebrate: It has taken me some years, but I eventually
> defended my PhD thesis last winter and just now the bureaucratic followup
> is completed – I hold the official doctorate degree in my hands. Since
> this feels at least as good as birthday and christmas together, I'd like
> to invite you to join me for a party (if you are interested and happen
> to be near Munich, Germany) :-D
>
> You can find an electronic survey at
>
>   https://dudle.inf.tu-dresden.de/lw4cqmfv/
>
> to determine a convenient common date for a little evening reception
> sometime in August/September, and I'll organize a venue somewhere central
> in Munich. If you and/or someone you know would like to join, let me
> know the number of persons and a contact address by e-mail or through
> the survey not later than 22nd of July. I'll send every interested party
> another message once a date and venue have been found.
>
> Kind regards,
> Thomas
>
>
> --
> There are only two things wrong with C++: The initial concept and the
> implementation.
> -- Bertrand Meyer
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Codepoint indices for matched regexps (UTF-8)?

[John Cowan]

On Fri, Jun 15, 2018 at 9:44 AM, Henry Hu  wrote:

I tried (use utf8), but it is documented that it doesn't affect irregex and
> it sure enough doesn't.  I tried using the 'utf8 option while compiling my
> regex, but it doesn't change the index returned by
> irregex-match-start-index.
>

Do "(use utf8)" and then "(import utf8-lolevel)" to get the (undocumented)
low-level utf8 API.  The function utf8-offset->index accepts a string and a
byte offset and returns a codepoint index.  If you want to go the other
way, utf8-index->offset is also provided.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
I don't know half of you half as well as I should like, and I like less
than half of you half as well as you deserve.  --Bilbo
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] The eggs index needs release dates displayed

[John Cowan]

I think that would be a mistake for the reason you give: it's often the
case that an egg hasn't been updated in a long while because it's complete
and nobody has found any bugs in it.  Lisp/Scheme code tends to be
extremely durable: McCarthy's theorem prover from 1958 is still runnable
with only a few surface repairs.

On Wed, Feb 21, 2018 at 2:45 PM, John Gabriele 
wrote:

> Hi all,
>
> Haven't played around with scheme in a while, but recently was motivated
> to take a peek at what eggs were currently available. I noticed at the [egg
> index](http://wiki.call-cc.org/chicken-projects/egg-index-4.html) that
> although there is much useful info provided (such as description, license,
> and egg version),  there are no egg release dates listed --- only the egg
> version number.
>
> While I understand that some may be hesitant to display dates, since there
> are likely many chicken eggs that are good but also were released some time
> ago (and you may not want to give the impression that you've got old eggs),
> it makes it difficult for new users to get an idea of what's current/active
> vs possibly inactive. Date of the egg's release is just as important to see
> as its version or other info, and also sends a clear message that the egg
> index is more than just a showcase but is in fact *the* tool for finding
> and selecting eggs.
>
> Does the egg packaging format support a field for release date?
>
> Thanks,
> -- John
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Microcontroller schemes

[John Cowan]

You can enhance Microscheme by front-ending it with Rapid Scheme, which is
a Scheme-to-Scheme compiler that provides syntax-rules macros, R7RS
modules, and other things that aren't in Microscheme.

On Wed, Nov 15, 2017 at 12:20 PM, Norman Gray 
wrote:

>
> Greetings.
>
> Christian Kellermann said:
>
> There's also http://www.suchocki.co.uk/microscheme/
>>
>> But most of these have severe constraints in the language making
>> them more like a C in parenthesis. Maybe you are better off using
>> Forth on a microcontroller for a similar explorative REPL approach.
>>
>
> Thanks, Christian -- that's very useful.  I'll explore that, and try to
> work out if it would make things easier or harder!
>
> Best wishes,
>
> Norman
>
> (sorry for the delay in replying -- I seem to have been having some email
> problems w.r.t. the list)
>
>
> --
> Norman Gray  :  https://nxg.me.uk
> SUPA School of Physics and Astronomy, University of Glasgow, UK
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
>
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Bug with #:optional in args egg?

[John Cowan]

On Mon, Sep 4, 2017 at 1:16 AM, Jim Ursetto <zbignie...@gmail.com> wrote:

Anyway, I would avoid using the args egg because the behavior of SRFI-37 as
> specified is not really what we expect from modern argument parsers.
>

In that case it ought to be replaced by a new SRFI, now that we have a good
deprecation mechanism.  What would you consider to be some modern argument
parsers that the new design could be based on?

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory
that the mongoose first came to India on a raft from Polynesia.
--blurb for Rikki-Kon-Tiki-Tavi
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Chicken on Termux

[John Cowan]

On Fri, May 12, 2017 at 5:00 PM, Phil Bewig <pbe...@gmail.com> wrote:

1) What is the correct PLATFORM for the make command? Is it android? Termux
> isn't really android, it is its own version of unix, similar to Debian.
>

I would try PLATFORM=linux and see if it works.  If not, you may need your
own sub-makefile for Termux, starting with Makefile.linux and tweaking a
few things.  Read the warnings here:  <https://termux.com/linux.html>.

You'll need to set Chicken's idea of the PREFIX to the same as Termux's
idea with PREFIX=$PREFIX, or use some other prefix, as /usr does not exist.

You will have to specify C_COMPILER=clang on the make line, as Chicken's
makefile defaults to gcc and gcc is no longer available on Termux.

Best of luck, and tell us how it goes!

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Where the wombat has walked, it will inevitably walk again.
   (even through brick walls!)
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Compiling multiple modules into a single executable

[John Cowan]

On Sun, Oct 16, 2016 at 5:35 PM, Evan Hanson <ev...@foldling.org> wrote:

You can use the "-analyze-only" flag:
>
>$ csc -analyze-only -emit-import-library foo foo.scm
>

If you use -check-syntax (or equivalently -P) then you can use -J to
generate all import libraries.  This is what I normally do.

-- 
 John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
A poetical purist named Cowan   [that's me]
Once put the rest of us dowan.  [on xml-dev]
"Your verse would be sweeter / If it only had metre
And rhymes that didn't force me to frowan." [overpacked line!]
--Michael Kay
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] set! on unbound variable

[John Cowan]

On Sat, Sep 24, 2016 at 11:39 AM, Dan Leslie <d...@ironoxide.ca> wrote:

> It seems that Chicken has a parameter to enforce R5RS strictness:
>
> > -r5rs-syntax disables the Chicken extensions to R5RS syntax
>

All that does is disable the syntax keywords that are normally available
but are not part of R5RS, so it's not relevant here.  In any case, R5RS
does allow the approach Chicken takes to unknown variables.  Section 5.2.1.
says:

Some implementations of Scheme use an initial environment in which all
possible variables are bound to locations, most of which contain undefined
values. Top level definitions in such an implementation are truly
equivalent to assignments.

See http://trac.sacrideo.us/wg/wiki/SetUndefinedVariable for which Schemes
do this
and which do not.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
After fixing the Y2K bug in an application:
WELCOME TO 
DATE: MONDAK, JANUARK 1, 1900
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] srfi-18 threads question

[John Cowan]

On Wed, Sep 21, 2016 at 4:53 PM,  wrote:

> ;; Why does the mutation of a simple global in a thread become visible to
> the main thread, but the mutation of global parameter does not?
>
> In general, parameters are designed to be per-thread rather than shared.
If they weren't, the parameter wouldn't reliably maintain its value
throughout the dynamic scope of a parameterize form.  So when you attempt
to mutate a parameter from another thread, you are mutating a copy.

Specifically, a parameter that has been bound with parameterize is always
per-thread. As you can see by looking at SRFI 39's rationale, unbound
parameters can behave differently in different implementations.  Chicken
chooses to make them per-thread in all cases: parameters are just elements
of a hidden vector that is copied when a new thread is forked (which means
it's expensive to have millions of parameter objects).
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] r7rs improper redefinition of imported symbol

[John Cowan]

On Mon, Sep 19, 2016 at 4:51 PM, John J Foerch <jjfoe...@earthlink.net>
wrote:

I ran into a little problem when working with the r6rs-bytevectors egg,
> which provides an r7rs implementation of (r6rs bytevectors).  The
> bytevector-copy! procedure has a different call signature in r6 than in
> r7, and I found that as r6rs-bytevectors is currently written, its
> bytevector-copy! always shadows or overrides the bytevector-copy! from
> r7rs.
>

The assumption is that because you've imported r6rs-bytevectors explicitly,
the R6RS behavior is what you actually want.  This is the only place where
R6RS and R7RS differ in argument order that is not automatically
detectable.  Larceny provides a combined (r7r6) library that imports
everything from both standards, except that the R6RS version of
bytevector-copy! comes in as r6rs:bytevector-copy!.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Mr. Henry James writes fiction as if it were a painful duty.  --Oscar Wilde
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Continuations

[John Cowan]

Josh Barrett scripsit:

> This seems to imply that the state of variables in the scope the
> continuation was captured are restored with the continuation, but the state
> of variables in scopes higher up the stack are not. But that doesn't sound
> right. If the continuation is copying the entire stack, than every single
> lexical variable would have its state restored when the continuation was
> restored, all the way up to toplevel.

Sorry, you're right and I was wrong, of course.  However, truly global
variables are not affected by restoring a captured continuation.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
LEAR: Dost thou call me fool, boy?
FOOL: All thy other titles thou hast given away:
That thou wast born with.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Continuations

[John Cowan]

Josh Barrett scripsit:

> A continuation is a capture of your location in a program, and its pending
> operations to return a result. In other languages, this is often
> represented by the stack.
> 
> When a continuation is captured, the current state of the stack is captured
> and can be restored later.

So far so good.

> The value of variables within the scope of the continuation are not
> captured: if variables are initialized within a lexical context, a
> continuation of that context is captured, the values of those variables are
> altered, and the continuation is restored, the variables will not reset to
> their original values.

No, this is not true.  The local variables are also on the stack and
are captured along with the return addresses.  Variables that are above
the point where the continuation was captured cannot be restored if they
have been changed.

> In chicken, capturing a continuation is cheap, because you need only take a
> pointer to a set of data, and register that with the GC. In most other
> scheme implementations, escpecially those with a stronger focus on C
> interop, capturing a continuation is expensive, because you need to copy
> the entire program stack.

There are ways to make it cheaper, but basically yes.  In Chicken, you pay
for cheap continuations by occasionally paying much more for ordinary
procedure calls (those that fill the C stack and trigger minor garbage
collections).  In other systems, programs that don't capture continuations
don't pay for them.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Is not a patron, my Lord [Chesterfield], one who looks with unconcern
on a man struggling for life in the water, and when he has reached ground
encumbers him with help?--Samuel Johnson

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] canvas-draw and colors

[John Cowan]

Thomas Chust scripsit:

> Or perhaps just normal arithmetic replacing bitwise-ior by + and
> arithmetic-shift by (lambda (x n) (* x (expt 2 n))). This is probably no
> less efficient, as the result is going to be a bignum anyway.

Well, only on 32-bit machines.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Is not a patron, my Lord [Chesterfield], one who looks with unconcern
on a man struggling for life in the water, and when he has reached ground
encumbers him with help?--Samuel Johnson

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] generate numerical list

[John Cowan]

Jeremy Steward scripsit:

> Note that iota annoyingly does not work well with the numbers egg ->

This is a general problem with the numbers egg and all other Chicken code,
whether part of the main build or an egg.  If the code is not *compiled*
with the numbers egg, it will not know anything about ratios, bignums,
or complex numbers.

Chicken 5 will have a full numeric tower natively and won't have this problem.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
If you have ever wondered if you are in hell, it has been said, then
you are on a well-traveled road of spiritual inquiry.  If you are
absolutely sure you are in hell, however, then you must be on the Cross
Bronx Expressway.  --Alan Feuer, New York Times, 2002-09-20

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Installing chicken on windows

[John Cowan]

Dan Leslie scripsit:

> The Haskell Platform is batteries-included; it ships with gcc, binutils,
> bash et al. IIRC, you can opt not to install those if you wish, but
> they install by default.

I guess we could do that, but it would be a pain in the ass to keep up
to date.

> Alternatively, people can now install Chicken through the Bash package
> that Microsoft ships in the Windows store. It's just Ubuntu without
> the kernel.

Sure.  But then it's not _Windows_ Chicken any more.  Interaction between
pseudo-Ubuntu and Win32 is very limited, basically just the shared file
system and TCP/IP sockets.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Linguistics is arguably the most hotly contested property in the academic
realm. It is soaked with the blood of poets, theologians, philosophers,
philologists, psychologists, biologists and neurologists, along with
whatever blood can be got out of grammarians. - Russ Rymer

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Installing chicken on windows

[John Cowan]

Dan Leslie scripsit:

> It reads to me like Chicken needs an automated builder for the Windows
> package.

It's not very clear how beneficial this is, since in order to use the
compiler, you'll need gcc and gmake anyway.  (If you just want a Scheme
interpreter, there are probably better choices than Chicken, though it
does have some nice eggs.)

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory
that the mongoose first came to India on a raft from Polynesia.
--blurb for Rikki-Kon-Tiki-Tavi

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Asynchronous I/O Egg Release

[John Cowan]

Chris Vine scripsit:

> The same effect can be achieved with other ports using
> thread-wait-for-i/o!, which although blocking also yields and only
> resumes when there is something available to read.  I don't have a
> problem with that: you just need to go with it.  And that is what the
> original poster's egg should be using.

Is there some reason why this isn't the default mode?  It seems to me
that what we want is for all standard Scheme operations to block the
thread that invokes them and no other threads, so that the programming
model is synchronous I/O (as RnRS demands) but threads still "work".
Disk operations aren't exactly instantaneous either, and shouldn't
block other threads that may be doing computations.

Providing asynchronous I/O to the user is a completely different thing.
I personally wouldn't want to use it, but I know there are reasons why
some people would.

> This is a general manifestation of one of the problems with "green"
> threads, and one of the reasons I don't like them: any inadvertent
> blocking on system calls jams everything.

Indeed, but it's a problem that the underlying system should hide
completely.  If not, I call it a design defect.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
To say that Bilbo's breath was taken away is no description at all.  There are
no words left to express his staggerment, since Men changed the language that
they learned of elves in the days when all the world was wonderful. --The Hobbit

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] R7RS-large Red Edition election has begun

[John Cowan]

The election to determine the contents of the Red
Edition of R7RS-large has begun.  To vote, please visit:
.
Ballots may be returned through the form, or on the WG2 mailing list,
or by email to me, .

The balloting period is from whenever you receive the ballot until the
last moment of Monday, July 19, in any time zone, which is equivalent to
noon July 20 in UTC.  Eligible voters are those who have registered for
this election, or those who were registered in the most recent Steering
Committee election, the R6RS plebiscite, and/or the R7RS-small plebiscite.
All registrations received before noon July 20 UTC will be counted.

-- 
weirdo:When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Module unresolved error

[John Cowan]

Michael Silver scripsit:

> > That's because the interpreter implicitly loads some modules, and the
> > compiler doesn't do that.
> 
> That’s odd; I would expect both to implicitly load those modules because the 
> documentation for both data-structures 
> <https://wiki.call-cc.org/man/4/Unit%20data-structures#unit-data-structures> 
> and ports <https://wiki.call-cc.org/man/4/Unit%20ports#unit-ports> say 
> both modules are "used by default, unless the program is compiled with the 
> --explicit-use option”, which I was not using (at least intentionally).

It's not so much the compiler vs. the interpreter (though there
is a difference), but being in a module vs. not being in a module.
The interpreter loads certain units and imports them into the top level.
Once inside a module, however, nothing is available except the name
`import`, so the first order of business is to import identifiers from
scheme and chicken to bootstrap a sufficient environment to do anything.
This is equally true in the interpreter, but doesn't come up much because
most people don't type module forms to the REPL or try to execute modules
as scripts.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here.  --DeXiderata by Sean McGrath

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Understanding modules?

[John Cowan]

Norman Gray scripsit:

> A puzzle: in his message John mentioned that 'Use [...] installs the
> file and imports it into the current module.'  I'm puzzled at this
> use of 'install'.  

It should have been "loads".  It's also worth noting that use (or
require-extension, which is the same thing) depends on the module having
the same name as the file.

-- 
 John Cowan  http://www.ccil.org/~cowanco...@ccil.org
   Si hoc legere scis, nimium eruditionis habes.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] R7RS-large kickoff, list membership, and voter registration process

[John Cowan]

Hwaet!  (Apologies for cross-posting)

The current phase of R7RS-large development, the development of SRFIs
for the Red (data structures) Edition of the language, is coming to an
end within a week or so.  At that point, I'd like to start discussing
the different options to be voted on using the scheme-reports-wg2
mailing list.  If you are not reading this message on that list, you
have several ways to sign up for it:

1) You can send an empty email to
.  Note the pattern of
hyphens and plus signs.   You should get a confirmation email.  You do
not need a Google account to use this method, only an email address.

2) You can sign up on the Web at
.  You need
a Google account to use this method.  You do *not* necessarily need a
Gmail account: anyone with an email address can get a Google account by
signing up at .

The current docket for the Red Edition is available at
.  It is *not* a ballot,
just the agenda for discussion.  However, if you plan to vote, you need
to be a registered Scheme voter.  If you registered to vote in either of
the last two Steering Committee elections, or for the R6RS or R7RS-small
ratification votes, or were a member of Working Group 1 or an original
member of Working Group 2, you are already registered and can vote in R7RS
elections.  Everyone who votes will get their names on the front page.
Note that there will *not* be a final ratification vote.

If you are not registered, simply send an email to this mailing list
with the following information:  your real name (or name you use in
place of a real name), your location, your affiliation if any, your
email address, any other contact information (Web, Facebook, Twitter,
etc.), and a short original paragraph (not a copy of someone else's)
indicating your interest in or experience with Scheme.  Votes by those
who have not registered by the end of the voting period will be ignored.

It's really going to happen now.  In a few days I'll send out preliminary
messages to start discussions on the SRFIs listed on the RedDocket page.
When the vote is complete, we'll know which SRFIs are going into the
Red Edition and which are not.  Then, of course, we'll start work on
the SRFIs for the Orange Edition, and repeat the process until we reach
the complete, or Ultra-Violet edition (so named because it is currently
quite invisible).

-- 
weirdo:When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Numbers weirdness

[John Cowan]

Andy Bennett scripsit:

> I'm mostly using log2 to work out if numbers are a power of two and find
> the highest bit that they have set.

You can use integer-length to tell how many bits are required.  If you
subtract 1 and the number of bits shrinks by 1, you have a power of 2.

Rules for WWI pilots:

1.  Stay out of WWII.


--Peanuts

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Numbers weirdness

[John Cowan]

Peter Bex scripsit:

> That's a complete mischaracterisation.  First, it depends on your
> definition of "accurately", and secondly, you can tell CHICKEN to
> change the print precision.  See my other mail, which shows that
> Racket is _also_ truncating the value, just after more digits than
> CHICKEN is doing so.

By "accurately" I mean what is meant in the Burger & Dybvig paper
"Printing Floating-Point Numbers Quickly and Accurately" at
<http://www.cs.indiana.edu/~dyb/pubs/FP-Printing-PLDI96.pdf>.
That is, printing the shortest correctly rounded output string
that converts to the same IEEE double value when read back in.
Of course it is possible to generate more digits than that,
but they are more precise than IEEE double format allows for,
and therefore are essentially garbage.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
My corporate data's a mess!
It's all semi-structured, no less.
But I'll be carefree / Using XSLT
On an XML DBMS.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Numbers weirdness

[John Cowan]

Andy Bennett scripsit:

> #;5> (log2 (expt 2 251))
> 251.0
> #;6> (ceiling (log2 (expt 2 251)))
> 252.0
> 
> Is it just late on a Friday? Am I crazy?

Trying (log2 (expt 2 251)) in Racket, which prints 64-bit floats
accurately (unlike Chicken, which depends on C to do it) returns
a value of 251.03.  The ceiling of that is indeed 252.0.

As Kernighan and Plauger said back in 1974:  "Floating point numbers
are like sandpiles:  every time you move one, you lose a little sand
and pick up a little dirt."  It's still true.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Barry thirteen gules and argent on a canton azure fifty mullets of five
points of the second,  six, five, six, five, six, five, six, five, and six.
--blazoning the U.S. flag

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Understanding modules?

[John Cowan]

Norman Gray scripsit:

> First: what (I think) I understand about compilation units.

Units go back to Chicken 3.  IMAO, you don't need to know anything
about them unless you are writing code to be incorporated into
the main Chicken build, which is unlikely.

>   * import libraries

An import library is an artifact of how Chicken modules are compiled.
When you compile a file containing a module, specifying the -J option
will cause a *.import.scm file to be created.  This file is required in
order to use the module.  Since it is Scheme, you can compile it as well
if you want to, which will speed up the performance of any macros declared
in your module.  You should not create an import library by hand.

>   * load vs use vs import

Load causes a file to be loaded *at run time*.  It is a standard part of
Scheme and has nothing to do with Chicken's module system.  You shouldn't
use it unless you actually need to load code based on decisions made at
run time.

Use (which can also be spelled require-extension) looks for a file foo.so
(compiled) or foo.scm (source) which declares a module foo.  It installs
the file and imports it into the current module.

Import causes the identifiers declared in a module which has already been
installed to be visible in the current environment.

>   * so in order to use functions defined in one module, in another,
> I must _first_ 'require-library' to take care of linking details,
> and _then_ 'import' the module to take care of the scheme bindings

That is necessary only if the file name is not the same as the module
name, or if you are rebinding standard Scheme names in your code.
Otherwise, you can stick to just use and (import scheme chicken).

> (or more typically specify 'require-extension' or 'use').

That is what you should typically use.

> Presumably both the 'chicken' and 'scheme' modules use only scheme
> bindings,

The bindings in those modules are automatically installed, so using them
makes no sense; you just need to import them into a module.  If you are
not in a module, they are already imported.

> which is why we _import_ those, but must _use_ posix (for
> example).  

We must say "use posix" to get the posix unit installed.

> How do I tell the difference between those modules which need 'use'
> and those modules which must use only 'import'?

In general, only scheme (standard R5RS bindings) and chicken (standard
Chicken bindings that aren't R5RS) need to be just imported, because
there are no scheme.scm and chicken.scm files defining those bindings.
Everything else needs to be used.  Note that it is safe to use a file
even if it has already been installed.

> Secondly, in the 'import libraries' section of 'Modules', it would
> be useful to note parenthetically that the 'emit-import-library'
> compiler option has '-s' as its short form -- this would help link
> it to the discussion in the 'Extensions' chapter.  Alternatively,
> use only the longer form in the 'Extensions' chapter.

Not -s but -J.  The purpose of -s is to make a compiled shared library rather
than a compiled application.

> Preconception alert: I'm guessing that it is indeed idiomatic
> Chicken good style to put all code into modules, yes?  If it's not,
> I may be going against the grain here.

Logically speaking, yes.  However, the code does not have to be physically
in the file containing the module declaration.  My style is to have a
file foo.scm which contains the module declaration including imports and
exports, and then (include "foo-impl.scm") which contains pure Scheme
code with no module forms, imports, or uses.  If foo-impl gets too large,
I break it into multiple files with multiple includes in foo.scm.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
How comes city and country to be filled with drones and rogues, our highways
with hackers, and all places with sloth and wickedness?
--W. Blith, Eng. Improver Improved, 1652

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Is there interest in this Prolog interpreter packaged as an egg?

[John Cowan]

Jeronimo Pellegrini scripsit:

> If you believe this would be interesting as an egg, tell me and I'll
> get it packaged!

Nice!  You should also compare it with Schelog.  Definitely do package
it as an egg.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.  --Gerald Holton

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [s...@speechcode.com: More SRFI reviewers needed.]

[John Cowan]

Jeremy Steward scripsit:

> Nonetheless, I noticed that the SRFI document mentions implementing
> lazy sequences in a different way (utilizing SRFI 121: Generators,
> which is also on your list). I was wondering if the lazy-seq egg has
> been brought up whatsoever regarding this SRFI, and if there's some
> difference I'm not seeing here. 

As best I can tell, the lazy-seq egg is more like SRFI 41 than like
SRFI 127.  I'm considering turning it into a SRFI to serve as a possible
alternative to SRFI 41 and/or 127.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Consider the matter of Analytic Philosophy.  Dennett and Bennett are well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett.
There is also one Dummett.  By their works shall ye know them.  However, just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the function
of this and other e-mail messages, therefore, to do what they can to create him.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

[Chicken-users] [s...@speechcode.com: More SRFI reviewers needed.]

[John Cowan]

- Forwarded message from "Arthur A. Gleckler" <s...@speechcode.com> -

Date: Wed, 06 Jan 2016 11:09:21 -0800
From: "Arthur A. Gleckler" <s...@speechcode.com>
To: srfi-annou...@srfi.schemers.org
Subject: More SRFI reviewers needed.

Happy new year, Scheme users and implementers!

We need your help.

Partly as a result of the R7RS-large standardization effort
(see <http://trac.sacrideo.us/wg/#WorkingGroup2Charter>),
there are now twelve draft SRFI (Scheme Requests for
Implementation <http://srfi.schemers.org/>) in progress:

  <http://srfi.schemers.org/draft-srfis.html>

  SRFI 121: Generators
  SRFI 122: Nonempty Intervals and Generalized Arrays
  SRFI 125: Intermediate hash tables
  SRFI 126: R6RS-based hashtables
  SRFI 127: Lazy Sequences
  SRFI 128: Comparators (reduced)
  SRFI 129: Titlecase procedures
  SRFI 130: String cursors
  SRFI 131: ERR5RS Record Syntax (reduced)
  SRFI 132: Sort Libraries
  SRFI 133: Vector Library (R7RS-compatible)
  SRFI 134: Immutable Deques

While there has been excellent discussion on each, I would
like to encourage more Scheme users and implementers to give
their feedback on the SRFI documents and their reference
implementations, tests, etc.  Participating in the
discussion is an excellent way to help shape the standard.
The goal is to make sharing code between Scheme
implementations more practical and pleasant.

If you're interested, just read a SRFI document in which
you're interested,
e.g. <http://srfi.schemers.org/srfi-121/>; review the
discussion archive; sign up for the associated mailing list
(or <http://srfi.schemers.org/srfi-list-subscribe.html> for
all SRFI discussions); and post away.  We're grateful for
all constructive feedback.

Thank you, and happy scheming!

— SRFI editor

- End forwarded message -

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Normally I can handle panic attacks on my own; but panic is, at the moment,
a way of life. --Joseph Zitt

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] another egg

[John Cowan]

d...@ironoxide.ca scripsit:

> #;2> (case 'a
>   (('a) 1)
>   (('b) 2)
>   (else #f))
> #f

However, (case x ('a 1) ('b 2) (else #f)) will sort of work (one fewer
set of parens), because 'a is (quote a), a list of symbols.  So if x is
'quote or 'a, you get 1; if it's 'b, you get 2, otherwise you get #f.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Dream projects long deferred usually bite the wax tadpole.
--James Lileks

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Using fmt and numbers eggs together

[John Cowan]

Sudarshan S Chawathe scripsit:

> When not using the numbers egg, fmt's behavior seems to be as expected
> (given Chicken's implementation of numbers without the 'numbers' egg).

Since the fmt egg is compiled without the numbers egg, it only recognizes
native Chicken numbers, i.e. fixnums and flonums.  The way to fix that
is to fetch the fmt egg, introduce "(use numbers)" into the appropriate
places, and rebuild the egg locally.

> Is this a known limitation of fmt with 'numbers'?

It's a limitation of the numbers egg: programs (other than csi itself)
have to be compiled with it to work with it.  Chicken 5 will make
this go away, fortunately.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Let's face it: software is crap. Feature-laden and bloated, written under
tremendous time-pressure, often by incapable coders, using dangerous
languages and inadequate tools, trying to connect to heaps of broken or
obsolete protocols, implemented equally insufficiently, running on
unpredictable hardware -- we are all more than used to brokenness.
   --Felix Winkelmann

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] chicken-spock and 'load'

[John Cowan]

Sudarshan S Chawathe scripsit:

> I am probably missing something very obvious, but I cannot seem to
> figure out how to load one file (Scheme source) in another when using
> chicken-spock.  I'd be grateful for any pointers.

Scheme `load` is a procedure; that is, it is executed at run time.
Spock is an offline compiler, so there is no way to load Scheme code
(as opposed to JavaScript code) into a running Spock program.  As far
as I know, Spock doesn't implement `include` either, which would be a
compile-time action.

> (What I'm hoping to do is, for example, use portable SRFI
> implementations within my code destined for Javascript via
> chicken-spock.)

All I can suggest is that you compile them separately and then concatenate
the resulting JavaScript files.  However, if the SRFIs include macros,
those macros won't be available to your code.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
If a soldier is asked why he kills people who have done him no harm, or a
terrorist why he kills innocent people with his bombs, they can always
reply that war has been declared, and there are no innocent people in an
enemy country in wartime.  The answer is psychotic, but it is the answer
that humanity has given to every act of aggression in history.  --Northrop Frye

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] chicken-spock and 'load'

[John Cowan]

Sudarshan S Chawathe scripsit:

> The 'load' not working makes sense now; thanks for the reminder!  It
> seems odd that 'include' or something similar isn't available.

Apparently you are just supposed to supply multiple files of Scheme
code on the Spock command line.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
He played King Lear as though someone had played the ace.
--Eugene Field

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [ANN] sdl2 and sdl2-image 0.1

[John Cowan]

Evan Hanson scripsit:

> Building with gcc-5 instead worked fine. 

That's because the default for GCC 5.x is --std=c11 instead of --std=c89.
The safest approach is to insert --std=c89 into the build commands.

-- 
weirdo:When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] This may be a bug in chickens hash tables - or my bad

[John Cowan]

Ivan Shmakov scripsit:

>   Given that the basic idea of hashing is to produce a key out of
>   the object’s /value/, the change of the value – and mutation
>   does just that – changes the hash.  

Well, yes and no.  SRFI 69 and other Scheme hash table frameworks
support at least two kinds of hashing: hash by value and hash by
identity.  If you have a large tree structure made with pairs, and
you want to keep ancillary information about some but not all of
the pairs, an identity-based hash table will let you keep the information
associated with *a particular pair*.  Otherwise, if you had a tree like
(a (b c) (b c)), then any information associated with the first (b c)
would be overwritten if you associated information with the second (b c).
This is quite independent of whether you ever mutate the tree or not.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
As you read this, I don't want you to feel sorry for me, because,
I believe everyone will die someday.
   --From a Nigerian-type scam spam

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Continuations, control flow, and F-operator

[John Cowan]

Josh Barrett scripsit:

> I mean, I know call/cc is fast in chicken, but is it that fast, or is
> F-operator using some chicken specific implementation that I don't know
> about?

No, it isn't.  Calling an escape procedure from call/cc is as fast in
Chicken as calling a "normal" procedure (which is to say somewhat slower
than in comparable Schemes like Gambit), so Oleg Kiselyov's portable
implementation works well.  There are only a few Chicken-specific touches,
as you can see by loading the code with "chicken-install -r F-operator".

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
By Elbereth and Luthien the Fair, you shall have neither the Ring nor me!
--Frodo

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] optional type checking

[John Cowan]

Joe Python scripsit:

> Does chicken have optional type checking?

Yes, but only in compiled code.  The interpreter ignores all type
declarations and makes no type-checks except at run time.

> A example and pointers to documentation would be nice.

http://wiki.call-cc.org/man/4/Types is the documentation.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
And they pack their lyrics till they're so damn dense
You could put 'em in your yard and you could use 'em for a fence.
  --Alan Chapman, "Everybody Wants to Be Sondheim"

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] srfi-101 egg

[John Cowan]

"Jörg F. Wittenberger" scripsit:

> >> Note that we already have srfi-101 packaged as an egg:
> >> http://wiki.call-cc.org/eggref/4/srfi-101

This page was very misleading: it did not make clear that the egg
contains two different modules with different naming conventions, and
in any case it calls both of them "srfi-101".  I completely rewrote it.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Verbogeny is one of the pleasurettes of a creatific thinkerizer.
--Peter da Silva

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] unary 'when' and 'unless'

[John Cowan]

Sven Hartrumpf scripsit:

> A hidden bug in my code was uncovered by loading it into another
> Scheme (guile), which enforced the limitation of 'when' and 'unless'
> (in R7RS) to at least one result part.

That's pretty much normal in the R5RS/R7RS regime.  I had a similar
problem when I wrote a program in Chez, which at that time and for
historical reasons accepted () as equivalent to '(), as in Common Lisp.
When I moved the code to another Scheme, it broke, and of course mere
search and replace wouldn't fix it, as (lambda () ...) couldn't become
(lambda '() ...).

> Chicken accepts 'when' and 'unless' with only one argument:

In my view, this is a very reasonable extension to R7RS (which in any case
did not exist when `when` and `unless` were added to Chicken; they too
ultimately come from CL).  If the R7RS WG had reflected more on the use of
`when` and `unless` by macros, we might have specified them that way.

> I assume that the extended definition in Chicken is R7RS-compliant,
> but a stricter mode (or a harsh warning) would be helpful.

This is arguably the domain of a separate program (`r7rs-lint`, perhaps)
whose job it is to provide good portability warnings.  One of the reasons
for the failure of the R6RS to take over the Scheme world was its thorough
attempt to mandate portability using a great many statements containing
"must", what Will Clinger calls "preposterous mustard".  This left it
deeply incompatible with existing implementations that did not already
have multiple language modes (like Racket).

Such a program doesn't exist and can't exist in full generality, but
someone who needed it and was interested could make a good first effort
that would look for malformed standard syntax, too many or too few
or manifestly wrong-typed arguments to standard procedures, and so on.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Any day you [see] all five woodpeckers is a good day.  --Elliotte Rusty Harold

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] one more egg - need advice how wrt. exports

[John Cowan]

"Jörg F. Wittenberger" scripsit:

> Firstly I have not found a way to rename identifiers on export (as in
> r6rs libraries).  Is there really no way or did I miss it?

That's a limitation of Chicken that I hope will eventually be lifted.
In the meantime, you have to import the conflicting names with renaming,

.-
In the meantime, you can make two modules, one that holds the code and
another that just plays games with imports and exports.
> Right now the egg contains two modules "srfi-101-ra" and "srfi-101".
> The former exports all identifiers with the "ra:" prefix.  The latter is
> only there to strip the prefix.
> 
> But if one simply does "(use srfi-101)" this behaves confusing.  It's a
> bit hard to make sure "car", "map" etc. are what you expect when mixing
> srfi-101 lists and native lists.
> 
> Should I rather not export anything from the "srfi-101" module and
> require the user to import some (to be written) module?  Or is there a
> better(TM) way?
> 
> Otherwise it may be ready to be added to the eggs listing too.
> 
> Thanks
> 
> /Jörg
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
"But I am the real Strider, fortunately," he said, looking down at them
with his face softened by a sudden smile.  "I am Aragorn son of Arathorn,
and if by life or death I can save you, I will."

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] one more egg - need advice how wrt. exports

[John Cowan]

"Jörg F. Wittenberger" scripsit:

> Firstly I have not found a way to rename identifiers on export (as in
> r6rs libraries).  Is there really no way or did I miss it?

That's a Chicken limitation I hope will one day be lifted.  I'd just go
with fixing the code so that it uses rcar, rcdr, rcons etc.

I'm going to propose this library for R7RS-large after doing this
transformation on it.  I'm also going to propose a "prefix-drop" type
of import that removes, rather than adds, a prefix; this lets you do
flonum arithmetic instead of generic arithmetic by dropping the "fl"
prefix from flonum-specific routines.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Fundamental thinking is ha-ard.  Let's go ideology-shopping.
--Philosopher Barbie

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Which API to use (llrb)?

[John Cowan]

"Jörg F. Wittenberger" scripsit:

> John, does a chicken implementation already exist?

SRFI 125 is only implemented for Larceny, but the code's pretty portable.
I'm in the process of replacing SRFI 114 with the simpler SRFI 128, so
hold off on that for a bit.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Evolutionary psychology is the theory that men are nothing but horn-dogs,
and that women only want them for their money.  --Susan McCarthy (adapted)

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Regex fail?

[John Cowan]

Peter Bex scripsit:

> Note the nonl, which the manual states is equivalent to ".", but of
> course nonl means "no newline".

Dot in regular expressions has *always* meant "match any character but a
newline".  It doesn't come up that much in Unix commands, which typically
process their input line by line anyway.  But if you look at the Posix
definition or the Perl one, you see that dot is indeed equivalent to "nonl".
Indeed, "nonl" exists in order to have an SRE equivalent for dot.

> Maybe Alex can give us some info about why this is the case?  I think this
> may have something to do with the multi-line / single-line distinction
> (which, to be honest, I never really understood).

Multi-line and single-line mean totally different things: you can use one
of them or both or neither.  Multi-line mode means that ^ and $ will match
the beginning and end of a line as well as the beginning and the end of
the string.  In non-multi-line mode, they match only the beginning and
the end of the string.  Single-line mode means that dot matches newline;
non-single-line mode means that it does not.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
You know, you haven't stopped talking since I came here. You must
have been vaccinated with a phonograph needle.
--Rufus T. Firefly

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Some findings (WAS: Re: ANN: new eggs "llrb-syntax" and "llrb-tree")

[John Cowan]

"Jörg F. Wittenberger" scripsit:

> [1] http://www.webfunds.org/guide/ricardian_implementations.html

I read this with interest, but what does it have to do with David Ricardo?

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
And they pack their lyrics till they're so damn dense
You could put 'em in your yard and you could use 'em for a fence.
  --Alan Chapman, "Everybody Wants to Be Sondheim"

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Windows deployment - Numbers egg

[John Cowan]

Peter Bex scripsit:

> On Sun, Oct 04, 2015 at 10:23:26PM +0800, Robert Herman wrote:
> > Yes, I read the manual. All of the examples seem to be a linux host with
> > .so files. Windows uses .dll files.
> 
> Hi again Robert,
> 
> This is of course true, but the .so files that CHICKEN generates on mingw
> are just misnamed .dll-files.  Try running "file" on it to inspect the
> type; it'll let you know that they're DLL files.  I suppose because
> CHICKEN loads those dynamically, the extension is irrelevant.

Right.  When Chicken loads something dynamically on Windows, it uses the
equivalent of Linux dlopen(): it understands LDLIBRARYPATH and its defaults,
and it doesn't really care what the extension is.

But when an executable file has libraries linked into it, there is no
LDLIBRARYPATH (it uses PATH instead), and it insists on the extension "DLL".
That's because the brain-dead Windows loader has to be used, as your
application does not yet have control.
-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
In politics, obedience and support are the same thing.  --Hannah Arendt

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] I've gots an egg: missing.egg

[John Cowan]

Alaric Snell-Pym scripsit:

 Excellent! May I offer some tips?

+1 to these, and also it's better if do* calls syntax-error rather than error.

-- 
weirdo:When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] sequential version of set!

[John Cowan]

Alexej Magura scripsit:

 Is there a sequential version of /set!/, as in /setq/?

There isn't, though it would be straightforward to write a macro.
Scheme doesn't put as much emphasis on mutation as Common Lisp does;
note that while `do` looks the same in Scheme as in Common Lisp,
it does not mutate the iteration variables but rebinds them, and
named `let` is all about looping while rebinding.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
You know, you haven't stopped talking since I came here. You must
have been vaccinated with a phonograph needle.
--Rufus T. Firefly

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] CHICKEN 4.10.0 has been released

[John Cowan]

Peter Bex scripsit:

 One problem with MINGW is that it's badly maintained (unless I'm
 mistaken, the most recent binary release is from 2013).  Mingw-w64
 is better maintained, and despite the name it also works on 32 bit
 systems.  I think it does support getc_unlocked.  You can find it
 here: http://mingw-w64.org

As part of the Chicken 5 effort, we should consider switching not only
to mingw-w64, but also to MSYS2.  We should also look at Cygwin-64,
as there are probably still parts of the code base that assume that
Cygwin is inherently 32-bit.  (I'm not using Cygwin-64 yet myself,
so there is no hurry on this.)

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
He made the Legislature meet at one-horse tank-towns out in the alfalfa
belt, so that hardly nobody could get there and most of the leaders
would stay home and let him go to work and do things as he pleased.
--H.L. Mencken's translation of the Declaration of Independence

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] [Chicken-announce] CHICKEN 4.10.0 release candidate 1 available

[John Cowan]

Peter Bex scripsit:

 I tried digging in, but I hit a wall as soon as I tried gdb on a
 basic csi session: it fails right at the start, in C_toplevel:
 it looks like the toplevel_trampoline argument it passes to
 C_reclaim (a function pointer) already gets mangled.  This might
 be a problem with casting function pointers to C_word *.

Indeed, since that's undefined behavior in ISO C, we can expect support
for it to rot in existing compilers and to be downright absent in future
compilers, as C compiler writers more and more exploit their freedom to
miscompile technically undefined programs in order to speed up defined ones.

See http://blog.regehr.org/archives/1180 for more on this.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Mr. Henry James writes fiction as if it were a painful duty.  --Oscar Wilde

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] unbound variable: or

[John Cowan]

Peter Bex scripsit:

 It's pretty cool in that it supports both er/ir macros *and* syntactic
 closures.

Thanks.  I've updated http://trac.sacrideo.us/wg/wiki/SyntaxDefinitions
accordingly.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
An observable characteristic is not necessarily a functional requirement.
--John Hudson

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] unbound variable: or

[John Cowan]

Michele La Monaca scripsit:

 It would be more correct to say that define-macro has not the feature
 set you're interested in, which may or may not be of general interest
 depending on the context.

If you know for sure that nobody but you will use your macro, then
define-macro is fine, but if you expose it to users, you have created a
booby trap that can go off at any time.

 What is worse is that define-macro used to be the lingua franca for
 macros in Scheme.

For a very brief period.  Before 1986 (R2RS) there were very few
Schemes, and only MIT Scheme survives from that time.  After 1991
(R4RS), syntax-rules caught on.  So you are talking about five years in
the 40-year history of Scheme.

 It was 1991 when define-macro was ushered out the standard

Define-macro was never part of any Scheme standard.  Nonetheless, of
the 33 Schemes in my test suite with macros of some kind, all have
syntax-rules, 15 have define-macro (MIT is not one of them), 13 have
syntax-case, 5 have explicit renaming, 2 have syntactic closures, and 1
have explicit renaming.

 form of unity regarding macros. I doubt it never will.

The nearest thing to unity is syntax-case, though several important
implementations don't have it and probably never will.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
I am he that buries his friends alive and drowns them and draws them
alive again from the water. I came from the end of a bag, but no bag
went over me.  I am the friend of bears and the guest of eagles. I am
Ringwinner and Luckwearer; and I am Barrel-rider.  --Bilbo to Smaug

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] use vs uses?

[John Cowan]

chi scripsit:

 (use a) versus (declare (uses a)) what's the differences between those?

(use a), which can also be written (require-extension a), is the regular
way of bringing in code and making identifiers available in the current
environment.  It first does a require-library, which checks whether
the library a has already been loaded, and if not, loads it (that
is, a.scm, a.so, a.dll, or a.dylib).  Then it imports all the
identifiers of a module named a, which is presumed to have been loaded
by the library a, though this is not actually required.

The (declare (uses a)) form is for use with the unit system, which
precedes the module system as a method of code organization.  It is
pretty much only used internally to Chicken nowadays.

 (use a) will load module...library...module... what do you call the
 thing that (use) loads? Is it a library or a module?

Both: see above.

 But (import) imports modules that are already loaded from libraries. 

Correct.

 Are libraries and modules equivalent?

No.  A library is normally a file, though there are some libraries
that are built in to Chicken:  see
http://wiki.call-cc.org/man/4/Non-standard%20macros%20and%20special%20forms#require-library
for details.  A module is a Scheme form (module name ...).

 Can a library have more than one module?

Yes, although I advise against it.

 If a library has more than one module, then how does (use amodule)
 know to load the same library as (use bmodule)?

It doesn't.  These will try to load different libraries.  If you have
two modules in the same library, you can't use use; you have to use
require-library and import separately.

 Do modules have to be named after libraries?

No, but use relies on it.

 What's the difference between a module inline in your code and
 a library?

Nothing, except that you can't import an inline module with use,
only with import.

In R7RS mode, the rules are different:  import does what native Chicken
use does, and module names are lists of symbols that are converted
into library names thus:  module (foo bar baz) corresponds to library
foo.bar.baz.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
You know, you haven't stopped talking since I came here. You must
have been vaccinated with a phonograph needle.
--Rufus T. Firefly

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] unbound variable: or

[John Cowan]

chi scripsit:

 But I can't find anywhere that really explains why
 that's _fundamentally_ broken, not just ugly.

Define-macro has two problems: it prevents (as opposed to selectively
escaping from) hygiene, and it only supports global macros.
Unhygienic syntax has exactly the same problem as dynamically scoped
variables in Elisp or other pre-Common Lisps: you can't tell what
code does without examining its use of identifiers.

 Incidentally, I'm pretty sure define-syntax isn't hygenic. syntax-rules is
 hygenic. You can still ruin yourself with define-syntax, like:

That's true.  Low-level macro systems allow both hygiene and non-hygiene,
and both can be defined using define-syntax, let-syntax, let*-syntax,
or letrec-syntax.

 (define-syntax a
   (lambda (form rename compare)
 '(define b 23)))

For portability, you should always wrap the lambda in (er-macro-transformer 
...),
even though that does nothing on Chicken.  That way, if your code is ever
ported to a Scheme that provides syntax-case, you'll get an immediate
error rather than randomly going wrong.

 I would like to state for the record that even defining hygenic syntax is
 a pretty ruinous idea. You have to be very careful of what you're doing, and
 confident that it's a good idea, because it is literally impossible for 
 someone
 to tell what your program means without first calculating all of the syntax
 rules you have defined in their head. 

That's where syntax-rules shines: it gives up the full power of Scheme
in favor of safety and clarity.  IMO, there is really no need to use
low-level macros ever.

 It is kind of fun that you can write an uncomputable program though.

It makes things like continuous build servers hard, though.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Mos Eisley spaceport.  You will never see a more wretched hive of scum
and villainy --unless you watch the Jerry Springer Show.
--georgettesworld.com

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] unbound variable: or

[John Cowan]

Michele La Monaca scripsit:

 Gambit has it. Too bad Chicken 4 dropped it.

You're right; I was too hasty.  There are a number of other Schemes
that accept it also.  However, it does not fit into the {define-syntax,
let-syntax, let*-syntax, letrec-syntax} set provided by all post-R4RS
Schemes.

 Let’s say someone had the (bad?) idea to masquerade/embed it in other
 more baroque forms. For example in Chicken you have to write:

Yes, if explicit renaming is available (generally the case except in
Schemes that do syntax-case) then you can simulate it by not renaming
anything.  Syntax-case can sort of simulate it, but not 100% accurately.

I'll have more details on who does what posted later when I get my
suite of Schemes working again: at the moment, some of them have
bit-rotted.

 Define-macro is the most basic, no-frills macro system and the one
 which will give you the most profound understanding of what a macro is
 and is not. Oh, and it is quite powerful. I’ve used Gambit to
 practice. Only when you dominate it, I suggest to move on to
 syntax-rules. The latter works at a higher layer (see below), enforces
 hygiene and introduces you to pattern matching (which is not a macro
 specific topic).

That's like saying you should master assembly language before moving on
to a high-level languge like Scheme, because it gives you the most
profound understanding of what a computer does and is quite powerful.
These things are true, but assembly language and low-level macros
also give you the opportunity not only to shoot yourself in the foot,
but to shoot your users in the foot as well: they will write very
reasonable looking macro calls that just won't work because of the
lack of hygiene.  Gensym-renaming helps with half of hygiene, but
there's nothing you can do in writing your macro to provide for the
other half of it.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
The Unicode Standard does not encode idiosyncratic, personal, novel,
or private use characters, nor does it encode logos or graphics.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] unbound variable: or

[John Cowan]

Jinsong Liang scripsit:

 I want to learn some basic macro programming in Chicken. However, it seems
 there are multiple macro definition APIs in Chicken: define-syntax,
 syntax-rules, syntax-case, define-macro. Which one should I start with?

Define-macro is completely obsolete and not supported in Chicken 4 or
any modern Scheme.

Define-syntax is a general wrapper for defining macros like this:

(define-syntax name (transformer whatever))

This defines a macro named name using the syntax transformer
transformer.  The syntax and semantics of whatever depend on the
symbol used for transformer.

Define-syntax corresponds to define and can be written in the same
places.  You can also define local macros (like local variables) by
using let-syntax or let-syntax*, which correspond to let and let*.

Chicken supports three syntax transformers:  syntax-rules,
er-macro-transformer, and ir-macro-transformer.  The abbreviations er
and ir stand for explicit renaming and implicit renaming.  It does
not support syntax-case, sc-macro-transformer (syntactic closure),
or rsc-macro-transformer (reverse syntactic closure), though they are
supported by other Schemes.

Syntax-rules is the most widely supported, the easiest to use, and
the most idiot-proof, though not the most powerful.  The other syntax
transformers are more powerful but also more dangerous.

 Also, I have heard that, different from Lisp, macro programming in Scheme
 is not recommended. Is it true?

Procedures provide new run-time function, whereas macros provide new
syntax forms to extend the basic set (if, cond, set!, lambda, etc.)
They serve different roles.

But in general, you should write a procedure if you can.  If not, use a
syntax-rules macro.  Only if a syntax-rules macro is insufficient should
you use an implicit-renaming macro, and only if that is too slow should
you use an explicit-renaming macro.

Googling for syntax-rules will point you to a lot of basic tutorials.
When you want something more advanced, look for JRM's Syntax-rules
Primer for the Mildly Eccentric.  Read that until you have trouble
understanding it; you now know as much as you can absorb.  Go back to
it later when you need more.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Half the lies they tell about me are true.
--Tallulah Bankhead, American actress

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] u8vector to numbers bignum

[John Cowan]

Peter Bex scripsit:

 If this is such an important feature it may make more sense to include
 a proper PRNG.  

Different applications will want fast crude random-ish numbers, PRNGs,
cryptographic PRNGs, or full quantum randomness, with tradeoffs for
speed and quality.  Since that's so, I'd rather require programmers
to make the choice up front rather than fall back on some dubious
OS version that does who-knows-what.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
If you understand, things are just as they are.
if you do not understand, things are just as they are.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] unbound variable: or

[John Cowan]

Jinsong Liang scripsit:

 Then is there a straightforward way to get a list of booleans ored? I
 tried fold with or but it does not work either. It seems writing a loop
 or a recursion for this is a little overkill.

You want any.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Newbies always ask:
  Elements or attributes?
Which will serve me best?
  Those who know roar like lions;
  Wise hackers smile like tigers. --a tanka, or extended haiku

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users