[Chicken-users] Re: first experiments with "simple-macros"

[felix winkelmann]

On 8/2/05, Michele Simionato <[EMAIL PROTECTED]> wrote:
> 
> 1. First of all, Andre's paper and other documentation should be 
>boundled with the egg. Also, I would like this policy to be valid for 
>all eggs. 

Good point. I will try to think of something.

> 
> 2. Various constructs which work in regular Chicken does not work once 
>the simple-macros egg is loaded; for instance define-values:
> 
> #;1> (use simple-macros)
> ; loading /usr/local/lib//simple-macros.so ...
> #;2> (define-values (x y) (values 1 2))
> Error: unbound variable: y#top
> 
> Notice that the error message is pretty confusing (it seems that 
> simple-macros is renaming *all* names, not only the names inside
> macros defined with define-syntax). Should I assume that
> only R5RS forms are recognized? It seems likely, Chicken extensions 
> such as '->string' are not recognized either, however 'print', which is not

The toplevel has by default the "scheme" and "chicken" modules
imported. The "chicken" module exports everything that is provided
by the "library" and "eval" library units. To use stuff from "extras", say:

(use (module extras))
(import extras)

[Note the separation of loading/linking and import]

> 
> 3. ,x does not work in the REPL; however macroexpand "somewhat" works,
> so it should  be easy to fix.

Hm. ",x" Works for me. What output do you get?

> 
> 4. I was playing with the module system. As an exercise, I wanted to define
> a
>macro to import identifiers prefixed by the module name. So I tried
>   
>   (define (symbol-append . symbols)
> (string->symbol (apply string-append (map symbol->string symbols
> 
>   (define-syntax (import-with-prefix module-name)
> #`(import ,module-name (lambda (sym) (symbol-append ',module-name ':
> sym
> 
>   (module m1 (a b)
> (define a 1)
> (define b 2))
> 
>   (import-with-prefix m1)
> 
> But is does not work. m1:a and m1:b are not imported
> 

I asked Andre and he sent me this:

===
 Sorry, this should be better documented.  The way you have written it,
 the symbols will be imported into the macro definition site.  We need to
 write the macro as if IMPORT appeared at the use site of IMPORT-WITH-SYNTAX,
 as follows:

  (module helper (import-with-prefix)

(define (symbol-append . symbols)
  (string->symbol (apply string-append (map symbol->string symbols


(define-syntax import-with-prefix
  (lambda (form)
(let ((import-use-site (datum->syntax (car form) 'import))
  (module-name (cadr form)))
  #`(,import-use-site ,module-name
  (lambda (sym) (symbol-append ',module-name
   ':
   sym))
) ; module

  ==

> 
>   (macroexpand '(import-with-prefix m1))
> 
> gives 
>   
>   (kffd:load-module (quote m1))
> 
> which is anyway incorrect, since nor a nor b are imported. 

That's ok. The import has already been performed at macroexpansion-
time.

> 
> 5. Further observations will likely follow later on. 
> 

Keep in mind that this is really quite experimental (it isn't officially
announced yet). We are working on the bleeding edge here... ;-)


cheers,
felix


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

[Chicken-users] FFI string with embedded nulls

[Toby Butzon]

Howdy,

This all goes on the assumption that Scheme and Chicken are OK even with
a string with embedded nulls (e.g., "foo\0bar"). That's true, right?

Now then, I have a function that looks vaguely like:

unsigned int foo(char *to, char *from, unsigned int fromlen);

which reads ``from'' and fills some result based on that into a
pre-allocated (via malloc() or, in Chicken, (allocate ...)) ``to''.
Both strings may have embedded nulls: ``fromlen'' therefore tells the
function how long ``from'' is (since strlen() won't work), and the
return value is used similarly by the caller.

So what I'm trying to do in Chicken is create a function (foo from) that
calls the C function and returns the appropriate string, already filled
out as a Scheme string (and the memory allocated for ``to'' already
freed).

I'm stumped. How do I get the string to turn into a Scheme string
without truncating it at the first embedded null?

-- TB



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

Re: [Chicken-users] Re: Better algorithm for growing hash tables

[Alejandro Forero Cuervo]

> When, on the other hand, n is prime, o is always 1 so you won't need
> to worry about this (you'll just need to worry that no single value
> from hash(A) occurs more often than others).

Erm, o is always 1 or n.  I'll leave it up to you to figure out what
happens when o is n.

Alejo.
http://azul.freaks-unidos.net/

---=(  Comunidad de Usuarios de Software Libre en Colombia  )=---
---=(  http://bachue.com/colibri )=--=( [EMAIL PROTECTED]  )=---


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: [Chicken-users] Re: Better algorithm for growing hash tables

[Ed Watkeys]

On Aug 2, 2005, at 5:23 PM, Toby Butzon wrote:


Oops, I missed the "well designed hash functions" part. If your hash
function is well designed, it shouldn't make any difference. The  
safety in
"just to be safe" seems to be against poorly designed hash  
functions. :)


Yeah, I was just writing some code in response to the paper. I  
implemented the hash function from The Practice of Programming and  
ran it on the example variable names the author used:


; Requires SRFI-1.

(define (my-hash nhash s)
  (reduce
   (lambda (ch hash)
 (remainder (+ ch (* hash 31)) nhash))
   0
   (map char->integer (string->list s

(map (lambda (s) (my-hash 128 s))
 (list "a1" "b1" "d1" "X1" "Z1")) ==> (112 15 77 89 23)

If I reduce the size of the table down to four entries, this function  
produces only two collisions. Not bad, given that there is one more  
datum than there are table entries.


The author's laughably bad hash function returned 97 for each string.  
Allegedly, Knuth wrote the following hash function in TAoCP (not in  
Scheme of course; presumably in his whacked pseudo-assembly language):


(define (dumb-hash nhash s)
  (remainder
   (* 2654435761
  (reduce
   (lambda (ch hash)
 (+ ch (* hash 256)))
   0
   (map char->integer (string->list s
   nhash))

(map (lambda (s) (dumb-hash 128 s))
 (list "a1" "b1" "d1" "X1" "Z1")) ==> (97.0 97.0 97.0 97.0 97.0)

A freshman should be able to spend a minute looking at this function  
and realize how bad it is -- even without seeing a sample run.


When we're building systems, we often think of hash tables as black  
boxes that "just work" and invariably work in O(n) time. Probably not  
a good assumption.


Ed

--
Transmogrify, LLC * 



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

Re: [Chicken-users] Re: Better algorithm for growing hash tables

[Ed Watkeys]

On Aug 2, 2005, at 5:09 PM, Toby Butzon wrote:


On Tue, Aug 02, 2005 at 05:22:54PM -0400, Ed Watkeys wrote:


Yup. But you really should use prime numbers for hash tables.



Is there a paper or book that offers a convincing, empirical argument
for this? I've read and heard this exhortation before but the
justification in the presence well designed hash and rehash functions
has always been "just to be safe."



Maybe the blurb about it here
http://www.concentric.net/~Ttwang/tech/primehash.htm
will help. Read the "Expandable Hash Table" section and the first  
paragraph

of the next section.



I'll check it out. Thanks.

Ed

--
Transmogrify, LLC * 



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

Re: [Chicken-users] Re: Better algorithm for growing hash tables

[Toby Butzon]

On Tue, Aug 02, 2005 at 05:22:54PM -0400, Ed Watkeys wrote:
> >Yup. But you really should use prime numbers for hash tables.
> 
> Is there a paper or book that offers a convincing, empirical argument  
> for this? I've read and heard this exhortation before but the  
> justification in the presence well designed hash and rehash functions  
> has always been "just to be safe."

Maybe the blurb about it here
http://www.concentric.net/~Ttwang/tech/primehash.htm
will help. Read the "Expandable Hash Table" section and the first paragraph
of the next section.

-- 
Toby Butzon



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

[Chicken-users] Some notes on simple-macros extension

[Dale Jordan]

I have found a couple of problems with the simple-macros extension:

- The definitions of "include" and "define-macro" in 
chicken-macros-module.scm need to have their argument changed from 
"form" to "(form)" in line with the change referred to on the srfi-72 
discussion list.


- I found it useful to add "##sys#setslot" to the chicken-internals 
module export list defined in simple-macros.scm.


Michele Simionato reports:
> ,x does not work in the REPL;

I haven't seen this and have it used it extensively.  (I have the debug 
extension loaded.  I recompiled it for 2.0, but I don't know if this is 
related.)


There are a few things with this macro system I don't yet understand, 
but I have to say that it makes writing macros fun again!  I really like 
it.  Thanks, felix for putting it up so quickly.


Cheerfully.
Dale



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

Re: [Chicken-users] Re: Better algorithm for growing hash tables

[Ed Watkeys]

On Aug 2, 2005, at 10:50 AM, Nelson Castillo wrote:


On 8/1/05, Ed Watkeys <[EMAIL PROTECTED]> wrote:


_The Practice of Programming_ (Kernighan & Pike) deals with a
situation analgous to this; they grow storage for a string by powers
of two. This works well because it heavily tests the algorithm --
from 1 to 2 to 4 to 8... -- but also causes a grow for every log n
inserts i.e. rarely.



Yup. But you really should use prime numbers for hash tables.


Is there a paper or book that offers a convincing, empirical argument  
for this? I've read and heard this exhortation before but the  
justification in the presence well designed hash and rehash functions  
has always been "just to be safe."


Ed


--
Transmogrify, LLC * 



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

[Chicken-users] Meroon superclasses

[Ash]

Hi,

I've been playing around with the meroon egg, comparing it to tinyclos. 
With tinyclos, I can define a superclass in a one file (or even a static
library), then subclass from it in another file, as long as
both files are linked into the program.

With meroon, the superclass definition must be available at
compile-time.  So, two questions:

If I have a superclass defined in one file, what's the preferred way to
make its definition available in another file at compile-time?  I can
(include ...) the file, but I'm not sure that makes sense.  What if I
need the superclass definition in several files?

On a related note, I have a library that contains several superclasses,
defined in several different files.  If I build this library as a shared
object, I can use (require-for-syntax ...) to pull in the superclass
definitions to any file that subclasses them in a program that uses
the library.  If I build the library statically, I can't do this.  Is
there any way to make superclass definitions from a static library
available?

Thanks,

Ashley



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

Re: [Chicken-users] Re: Better algorithm for growing hash tables

[Nelson Castillo]

On 8/1/05, Ed Watkeys <[EMAIL PROTECTED]> wrote:
> 
> On Aug 1, 2005, at 4:52 PM, Alejandro Forero Cuervo wrote:
> 
> >> That explains Chicken's pathetic performance in the spellcheck
> >> benchmark in the alioth shootout (
> >> http://shootout.alioth.debian.org/benchmark.php?
> >> test=spellcheck&lang=all&sort=fullcpu
> >> ) - dead last, at 35.4 seconds, compared to 16.9 seconds for the next
> >> slowest language.  It's writing and reading ~39000 entries into a
> >> 1 size hash table, with this dumb algorithm.
> >>
> >
> > That's probably right.  I suppose currently it performs (39000 -
> > 500) / 101 = 337 resizes, whereas with the change it would resize
> > the table from 1 to 39709 and then to 79423, just 3 resizes. :)
> 
> _The Practice of Programming_ (Kernighan & Pike) deals with a
> situation analgous to this; they grow storage for a string by powers
> of two. This works well because it heavily tests the algorithm --
> from 1 to 2 to 4 to 8... -- but also causes a grow for every log n
> inserts i.e. rarely.

Yup. But you really should use prime numbers for hash tables.


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

[Chicken-users] first experiments with "simple-macros"

[Michele Simionato]

I have installed Chicken 2.0 and I have decided to try Andre' van Tonder
macro system. Here are my findings/feedback/requests.



1. First of all, Andre's paper and other documentation should be 
   boundled with the egg. Also, I would like this policy to be valid for 
   all eggs. 

Rationale:

a) in this moment I have a dialup connection, I have downloaded the egg
   assuming the documentation was included (as it happens in other eggs)
   and discovered later that it was missing. Now I have to go back and
   download the rest. This is slighly bothering. If I was in an Internet
   Cafe it would be even more bothering. 

b) I don't see a single good reason to provide the documentation 
   separately, since Chicken eggs are tipically simple, the docs
   are small and who cares about few Kbytes more in the download?
   For instance, the metakit egg, which has one of the longest documentation, 
   contains a PDF file of only 191K, which is nothing, even with a dialup 
   connection.

c) as a matter of principle, I consider documentation and tests an 
   integral part of the application, so I always ship everything together
   when I write code for distribution.



2. Various constructs which work in regular Chicken does not work once 
   the simple-macros egg is loaded; for instance define-values:

#;1> (use simple-macros)
; loading /usr/local/lib//simple-macros.so ...
#;2> (define-values (x y) (values 1 2))
Error: unbound variable: y#top

Notice that the error message is pretty confusing (it seems that 
simple-macros is renaming *all* names, not only the names inside
macros defined with define-syntax). Should I assume that
only R5RS forms are recognized? It seems likely, Chicken extensions 
such as '->string' are not recognized either, however 'print', which is not 
R5RS, works just fine (?)



3. ,x does not work in the REPL; however macroexpand "somewhat" works,
so it should  be easy to fix.

Experiments with macroexpand confirm me in my hypothesis that *all*
variables are renamed, for instance

  (macroexpand 'x) ;=> x#top



4. I was playing with the module system. As an exercise, I wanted to define a
   macro to import identifiers prefixed by the module name. So I tried
  
  (define (symbol-append . symbols)
(string->symbol (apply string-append (map symbol->string symbols

  (define-syntax (import-with-prefix module-name)
#`(import ,module-name (lambda (sym) (symbol-append ',module-name ': sym

  (module m1 (a b)
(define a 1)
(define b 2))

  (import-with-prefix m1)

But is does not work. m1:a and m1:b are not imported


  m1:a ;=> Error: unbound variable: m1:a#top

and

  (macroexpand '(import-with-prefix m1))

gives 
  
  (kffd:load-module (quote m1))

which is anyway incorrect, since nor a nor b are imported. 
On the other hand, writing by hand

  (import m1 (lambda (sym) (symbol-append 'm1 ': sym)))
  (list m1:a m1:b) ;=> (1 2)

works, so I am at loss of understanding what the expander is doing.



5. Further observations will likely follow later on. 


   Michele Simionato


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

[Chicken-users] recent changes

[felix winkelmann]

Hello, y'all!

I apologize for being somewhat unresponsive in the moment,
but I'm pretty busy in the moment in RL/work.

Alejandro's hash-table fix has been incorporated, and
the whole entry-point stuff is gone (as suggested by Daniel and
Ashely) , together with a simplification
of the embedding API (Things like CHICKEN_eval, etc... are still
available). Also recursive references in define-record-type seem
to work now. 

I'm behind a firewall, but will update the darcs head on thursday.

Thanks to all who have helped and contributed.


cheers,
felix


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