[Top][All Lists]

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

[Chicken-users] Chicken Gazette - Issue 16

From: Mario Domenech Goulart
Subject: [Chicken-users] Chicken Gazette - Issue 16
Date: Thu, 16 Dec 2010 06:26:49 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

     _/_/_/  _/        _/            _/
  _/        _/_/_/          _/_/_/  _/  _/      _/_/    _/_/_/
 _/        _/    _/  _/  _/        _/_/      _/_/_/_/  _/    _/
_/        _/    _/  _/  _/        _/  _/    _/        _/    _/
 _/_/_/  _/    _/  _/    _/_/_/  _/    _/    _/_/_/  _/    _/

--[ Issue 16 ]------------------------------------- G A Z E T T E
                               brought to you by the Chicken Team

== 0. Introduction

Welcome to the belated issue 16 of the Chicken Gazette.

== 1. The Hatching Farm

It has been a bit quiet in the egg repository apart from Kon Lovett
releasing a new version of the lookup-table egg. Alan Post has been
busy getting his genturfa'i egg into shape. Mario Goulart has ported
the statvfs egg to chicken 4.

== 2. Core development

In the `experimental` branch of the code repository
( several bugs have been fixed this week:

  * Ticket #438: Makefile's clean target removed generated setup-api    
    DISTFILEs which is not acceptable.                                  
  * Ticket #340: (Spiffy hangs occasionally (again!)) has been closed   
    since it seems that the fixes introduced in the `safer-scheduler`   
    branch are fixing (or hiding) the problem. Additionally Peter fixed 
    a couple of bugs in the openssl bindings.                           
  * Ticket #424: (umask support) our first change request has been      
  * Ticket #447: Inconsistencies when calling set-finalizer! multiple   
    times have been found by Moritz Heidkamp and fixed by Felix         
    Winkelmann. Finalizers are scanned first and then marked to make    
    sure the first mark will trigger the finalizer of the object.       
  * Ticket #444: Symbol lookup fails in modules in conjunction with     
    renaming macros: Peter Bex came up with a patch to fix this bug     
    which turned out to be of a more general nature than just affecting 
    the IR-macro expander.                                              

Also chicken now has another scrutinizer mode called `-picky`.

  When given, the scrutinizer warns about undefined branches in
  conditionals in tail-position of global procedures that do not
  perform a self-call.

as Felix explains on chicken-users

The debug switch -:d is now also handed to the chicken program by
the compiler driver csc.

And we welcome back our lambda lifting code which has been put back
into the experimental branch by Felix.

== 3. Chicken Talk

But alas, this has also been bug finding week! Alan Post as
well as Moritz and Peter stumbled over some strange findings
during the last week. Alan's genturfa'i egg somehow caused
the compiler to create huge amounts of code as you know from
last week's issue. This week Alan wanted to check for common
subexpression in his data and compared the whole list with equal?
which contained in his case circular defined procedures. equal?
traversed these structures blowing up the heap. If you are interested
in the process of this issue follow ticket #440.

Sven Hartrumpf pointed out a problem in the
handling of a huge number of command line arguments
which Felix fixed in the `experimental` branch.

David Dreisigmeyer has been running
into problems with the bind egg's parser
that still have to be resolved.

Apart from other smaller questions to the list we have experienced
an outtake of the chicken-users mailing list due to the recent
hack at GNU's savannah site. In the meantime FSF's admin have been
able to restore the list and its archives to full functionality.
Thanks for that. If the main archive at is not
available you can use mirrors of this archive at

== 4. Omelette Recipes

This week I'd like to give you a brief introduction to Chicken's
module system ( Modules form
a namespace or environment. Basically you can think of modules as
containers for bindings. Also you have full control over which bindings
are exported from a module. This way you don't have to worry about
polluting the global namespace with auxiliary bindings. No silly name
prefixes anymore! An example illustrates this best:

    (module palindrome 
    (palindromify palindrome?)
    (import chicken scheme extras)
    (use srfi-13)
    (define max-length 100)
    (define (palindromify s)
      (string-append s (string-reverse s)))
    (define (palindrome? s)
      (let* ((len (string-length s))
             (half (quotient len 2)))
        (cond ((> len max-length)
               (error 'palindrome? 
                      (format "palindromes may not be longer than ~A 
characters" max-length)))
              ((odd? len)
               (palindrome? (string-append (string-take s half) 
                                           (string-drop s (+ half 1)))))
              (else (string=? (string-reverse (string-take s half))
                              (string-drop s half))))))

As you can see, it's pretty straight forward. Unsurprisingly, the
`module` form introduces a module definition. The first symbol
`palindrome` is the module's name, followed by a list of symbols to be
exported from the module: `(palindromify palindrome?)`. These symbols
have to be bound somewhere inside the module. The rest of the form is
regular Scheme establishing these bindings. The first thing we have
to do is `(import chicken scheme srfi-13)`. Yes, this means a module's
environment is completely blank initially (except for the `import`
form) thus we even have to import `scheme`, yet! This is an especially
nice way to create an environment for a DSL: No regular Scheme bindings
are going to get in your way. In our case we stick to Chicken flavored
Scheme and some SRFI-13 goodness to define a few palindrome procedures.
Note that we define a `max-length` of 100 characters inside our module
without exporting it. This means users of our module will not be able
to touch that limit. Further note that code inside the `module` form is
not indented since usually there's only one module definition spanning
the whole file.

How to use this module now? Well, just import it like any other module.
Try sticking the above code into a `palindrome.scm` file, `load` it in
a `csi` REPL and then `(import palindrome)`:

    #;1> (load "palindrome.scm")
    ; loading palindrome.scm ...
    #;2> (import palindrome)
    #;3> (palindrome? "chicken")
    #;4> (palindromify "fo")     
    #;5> (palindrome? (palindromify "fo"))
    #;6> max-length
    Error: unbound variable: max-length

See, no rocket science in that, though some basic linguistics. The best
thing is that the modules we imported into our `palindrome` module are
not visible in the environment our module is imported into. So if our
REPL environment hadn't `srfi-13` imported before importing our module,
it still won't have it afterwards. Nice!

One thing that might cause confusion is that Chicken eggs are not
equal to modules, although many eggs consist of just one module. The
difference is that eggs may contain any kind of Chicken Scheme code, be
it only one module, many modules, one or more programs or just some raw
definitions. It's all up to the egg author. Then you have accompanying
egg specific forms like `require-library` which loads a module from
an egg and `use`/`require-extension` which load and then import egg
modules. How these are used and how eggs are built is beyond the scope
of this recipe but you may want to check out the eggs tutorial on the
wiki (

== 5. About the Chicken Gazette

The Gazette is produced weekly by a volunteer from the
Chicken community. The latest issue can be found at or you can follow it in your feed reader at If you'd like to write an issue,
consult the wiki ( for the schedule and

[ --- End of this issue --- ]


reply via email to

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