[Top][All Lists]

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

Re: [dev-serveez] switching to guile

From: Martin Grabmueller
Subject: Re: [dev-serveez] switching to guile
Date: Thu, 04 Jan 2001 12:00:22 +0100

> From: "Raimi 'Raimi' Jacob" <address@hidden>
> Date: Wed, 3 Jan 2001 20:29:56 +0100 (CET)
> On Wed, 3 Jan 2001, Martin Grabmueller wrote:
> /usr[/local]/include/libguile.h

If you are interested in Guile's hash table functions, have a look at

> I dont really care for sizzle / guile syntax compatibility. I just want a
> syntax that is non-schemer understandable.

I think that alist syntax is not worse than Sizzle hash syntax, unless
you come from Perl.

#{foo => bar}
(foo . bar)

is not much of a difference.

> OK... as long as i can traverse them from the C end...

It's pretty much the same as for Sizzle.  The biggest difference is
that you have to install exception handlers when using Guile, because
Guile's type checking macros longjmp() on errors.

> Ha... they all use hot water for cooking :-)

You bet.

> Ok, that's better. But not really. The syntax for hash creation sucks. I'd
> rather use alists than that [syntax].

Fine for me.  alists are easier to handle anyway.

> (define-server! "server name" "server type" <some good syntax for a
> hash/alist>)
> i'd also rather call it define-server than register-server. doesnt sound
> that coder-tongue.

I don't care for the name.  define-server[!] is fine for me.

> define_server would be a scheme-callable c routine getting 3
> arguments: server name, type and a hash/alist of things that are copied
> into a struct. i suspect that can't be that hard.


> > Of course, there is still the problem with Guile on Windoze.
> I hope that the guile people are willing to accept patches from ela. he
> made sizzle work on windoze, so he can make guile [core] work on windoze,
> too (i'll help him, of course).

I'll dig through the guile-devel archives, because someone already
tried to port Guile to Windows.  Stay tuned.

Martin Grabmueller              address@hidden  address@hidden on EFnet

reply via email to

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