guile-devel
[Top][All Lists]
Advanced

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

Re: [patch] subordinate SMOBs with GOOPS superclasses


From: Kjetil S. Matheussen
Subject: Re: [patch] subordinate SMOBs with GOOPS superclasses
Date: Sat, 15 Dec 2007 17:26:11 +0100 (CET)


Clinton Ebadi:

Neil Jerram <address@hidden> writes:

address@hidden (Ludovic Courtès) writes:

Hi Andreas,

Andreas Rottmann <address@hidden> writes:

You should probably also have a look at the Scheme-Level FFI of PLT
Scheme[1], and my reimplementation for Scheme 48[2].

Thanks for the links, that's the kind of think I had in mind.  Perhaps
you'd like to port S42 to Guile as well?  :-)

From a _very_ quick look, my impression is that the PLT FFI is about
equivalent in complexity and function to what the code generation side
of G-Wrap provides.

If that's correct, then the key practical difference is that G-Wrap
does everything at build/compile time, where PLT FFI does everything
at runtime -- in which case, surely G-Wrap is the better option?

I think doing things at runtime is a better idea--it fits more with
the interactive compile-one-expression-at-a-time nature of Lisp.

UFFI and CFFI in the Common Lisp world work this way, and generally
bindings to C libraries are solid. There may be an increased risk of
crashing the system during the initial development stage, but once
speced out the data type specifications rarely change. Any strange
issues that occur when interfacing with C this way should also be
trappable and transformed into a Guile exception that could be caught
and not abort the entire system. At least in SBCL it takes a lot of
abuse before a C library can crash anything.

Perhaps G-Wrap could be modified to work at runtime? A few utilities
from it would be of general use--e.g. the sublanguage for specifying
the layout of C structs could be used for generating high level
interfaces to network protocols without painful manual munging or
resorting to C.

Its not quite the same thing, but eval-c works at runtime,
and perhaps some tips can be picked up from its code:

(load "eval-c.scm")
(eval-c "-lgmp"
        "#include <gmp.h>"
        (proto->public
         "void mpz_init (mpz_t integer);"
         "void mpz_set_ui (mpz_t rop, unsigned long op);"
         "void mpz_add (mpz_t rop, mpz_t op1, mpz_t op2);"
         "unsigned long mpz_get_ui (mpz_t op);")
        (public
         (<mpz_t-*> new-mpz (lambda ()
                              (return (calloc 1 (sizeof <mpz_t>)))))
         (<void> delete-mpz (lambda ((<mpz_t> var))
                              (free var)))))

(let ((a (new-mpz))
      (b (new-mpz)))
  (mpz_init a)
  (mpz_init b)
  (mpz_set_ui a 50)
  (mpz_set_ui b 60)
  (mpz_add a a b)
  (let ((res (mpz_get_ui a)))
    (delete-mpz a)
    (delete-mpz b)
    res))
=> 110


Code at http://snd.sf.net

reply via email to

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