[Top][All Lists]

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

Re: [Chicken-users] Postscript: (Reading binary files)

From: Will Farr
Subject: Re: [Chicken-users] Postscript: (Reading binary files)
Date: Tue, 18 Dec 2007 17:24:28 -0500


The fundamental difference between Bigloo and Chicken here is that
Bigloo's module system allows it to resolve all bindings at compile
time.  When you write

(module ....)

(define a ...)
(define b ...)

in Bigloo, it knows that all bindings in the "..."s of the body must
come from 1. the base Bigloo language, 2. imported modules in the
(module ...) clause, 3. previous defines inside this module, 4.
lexically bound identifiers (i.e. in a (let ...) block).  If you refer
to a symbol which is not bound in one of these contexts, it throws an
error.  In particular, there is no notion of "top-level" identifier.

In Chicken, on the other hand, when you write

(define a ...)
(define b ...)

in a file, any symbol which is not bound in 1. a previous (define
...), or 2. lexically (i.e. in a (let ...) block) refers to a
"top-level" binding.  Since all modules (and the REPL) have access to
top-level bindings, Chicken can't know which top-level bindings are in
place until it actually runs the code.

Consider this example:

;; In file.scm:
(define (incr-global-counter!) (set! *global-counter* (fx+ *global-counter* 1)))

Now compile this to a shared library:

csc -s file.scm

And do the following in the repl (called "csi"):

> (load "")
> (incr-global-counter!)
=> error because *global-counter* isn't defined.

As opposed to the following:

> (load "")
> (define *global-counter* 0)
> (incr-global-counter!)
> *global-counter*
=> 1

Chicken simply cannot perform the type of analysis you're asking for
at compile time.  Now, it would be possible to record the line-number
of statement which generates the error so it can print that at runtime
(so the error message is more friendly)---I think Chicken may do this
if you compile with some large debug level, like the -d2 option to

On Dec 18, 2007 5:10 PM, Siegfried Gonzi <address@hidden> wrote:
> Sorry I tried it that -check-imports: but jonestly: I want a line number or 
> at least the function where the problem occurs. I mean a 1000 line program 
> please do not ask me to use Emacs for searching the hot-spot then because I 
> only know some basic Emacs commands.
> Hey, why is it hard for the compiler to tell me the line number?
> I cannot remember how Bigloo dealt with that kind of things because it is 
> been 3 months ago when I last used Bigloo (I cannot install it on my 
> Leopard). But not that bad I think otherwise I would like to remember.
> But this is a totally different experience for me that kind with runtime 
> errors. I know this from IDL.
> Anyone here who has ever developed 2000 lines of Chicken code?
> Btw: Cicken is also fast on micro benchmark. When doing the matrix-matrix on 
> 512 arrays and not 2048 though C is 2 times faster now than Chicken but still 
> Chicken is blazingly fast on this.
> Regards, Siegfried
> -------- Original-Nachricht --------
> > Datum: Tue, 18 Dec 2007 22:54:44 +0100
> > Von: Thomas Christian Chust <address@hidden>
> > Scheme variables may be defined at runtime so it is not an error for a
> > symbol to be unbound at compile time. You can, however, tell the CHICKEN
> > compiler to emit warnings for undefined symbols and redefined imported
> > symbols using the -check-imports command line switch.
> >
> > cu,
> > Thomas
> --
> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> Browser-Versionen downloaden:
> _______________________________________________
> Chicken-users mailing list
> address@hidden

reply via email to

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