[Top][All Lists]

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

Re: New feature proposal: Support C-code inline?

From: Noah Lavine
Subject: Re: New feature proposal: Support C-code inline?
Date: Fri, 22 Apr 2011 16:14:19 -0400

I just looked at the code. It's really cool! This looks like a way to
write modules that use C and Scheme together in such a way that the
code is all in one place. I think it could be much easier to read code
written this way than code in separate C and Scheme files.

What do other people think?


On Wed, Apr 20, 2011 at 5:50 AM, nalaginrut <address@hidden> wrote:
> hi all!
> I think somebody will need such a C-inline feature when he wants to
> write a smart C-function to replace the critical function in his
> algorithm.
> And I found a similar feature in Ruby. So I wrote a module to provide
> this.
> Anyway, I think the best solution is a AOT compiler for guile. But it
> seems to be dystocia. So this module provides an easy solution.
> Let me show it's usage:
> (use-modules (inline inline))
> (define in (make <inline> #:name "mytest"))
> ;; this name is arbitrary. But if you made more than one inline instance
> ;; in your program, each must has an unique name. Or shit happens.
> (inline:eat-code in "int func(int a ,int b){ return a+b;}")
> ;; well~this example is too stupid. Try another as you will...
> (let ((myfunc (inline:get in)))
>   (myfunc 5 6)
>  )
> ===> 11
> Drawback:
> 1. Though this module will parse the function type list, it's not
> perfect. Users can only chose "int/float/double/char/long/void".
> 2. Can't support "unsigned" in the function declaration. But you can use
> them in the function body.
> 3. Can't support "pointers" in the function declaration, it's a big
> drawback. This inline feature is restricted so much because of this
> pity. The good news is you can use it in the function body.
> 4. ...Anyone find more?
> Future:
> 1. Fix the known drawbacks.
> 2. Each inline instance will generate a share lib file. That means each
> inline function will have one share lib file.
> Though they won't conflict because the lib file name is bound to the
> program name which use it, I think it's not proper.
> Maybe we can add several inline functions to one inline instance, and
> generate just one share lib for each program.
> I don't know how much people is interested it. For some low-level
> programming guys, this module even provides inline assemble. I know this
> module is too simple for some guys, but it's easy to implement and easy
> to use.
> My patch is attached(actually it's not a patch...).
> Any advices?
> --
> GNU Powered it
> GPL Protected it
> GOD Blessed it
> HFG - NalaGinrut
> --hacker key--
> v4sw7CUSMhw6ln6pr8OSFck4ma9u8MLSOFw3WDXGm7g/l8Li6e7t4TNGSb8AGORTDLMen6g6RASZOGCHPa28s1MIr4p-x
> ---end key---

reply via email to

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