chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] Msgpack implementation for scheme (and some question


From: Peter Bex
Subject: Re: [Chicken-users] Msgpack implementation for scheme (and some questions)
Date: Thu, 31 Jan 2013 10:27:42 +0100
User-agent: Mutt/1.4.2.3i

On Thu, Jan 31, 2013 at 09:14:32AM +0000, Alaric Snell-Pym wrote:
> On 01/31/2013 01:06 AM, Hugo Arregui wrote:
> > That's right, in fact, when I started the project I think to do so,
> > just create the bindings, but, to be honest, I think it will more fun
> > if I do it from scratch.
> 
> In general, I think it's better to write stuff in pure Scheme when we
> can.

That sort of thing is highly dependent on the project.  For example, for
Postgres I considered writing protocol support for it in pure Scheme but
I'm glad I never did this.  There are many conventions supported by libpq
which are handy and which you lose when you reimplement it yourself.

For example, you have various environment variables and config files that
get picked up by libpq, and which users come to expect to "just work":
http://www.postgresql.org/docs/current/interactive/libpq-envars.html

This is exactly why the Postgres community frowns upon reimplementations.
They're almost always incomplete and break expectations of seasoned
Postgres DBAs/programmers.

> Sure, dump to C if it's too much work to write a performant
> implementation yourself and there's a handy library, etc, but the more
> code that's in Scheme, the more code that can be ported to other
> implementations, is less likely to have EVIL POINTER BUGS, etc...

Your own implementation is also likely to have more high-level bugs
that have already been picked out of the C library by the community.

But yes, it's fun to write your own and it allows better integration
with the GC, which means it might even be faster than using the C
implementation (finalizers are slow!).  And Scheme might allow things
like using higher-order procedures and a more functional style where
in C you'd have an awkward side-effect-heavy API.

Cheers,
Peter
-- 
http://sjamaan.ath.cx



reply via email to

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