From: Noah Lavine <noah.b.lavine@gmail.com>
To: NalaGinrut@gmail.com
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: New feature proposal: Support C-code inline?
Date: Fri, 22 Apr 2011 16:14:19 -0400 [thread overview]
Message-ID: <BANLkTim9GGPwx_qFZu5iVt5cg2XDFn=+hg@mail.gmail.com> (raw)
In-Reply-To: <1303293013.2749.41.camel@Renee-desktop>
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?
Noah
On Wed, Apr 20, 2011 at 5:50 AM, nalaginrut <nalaginrut@gmail.com> 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 hackerkey.com
> ---end key---
>
next prev parent reply other threads:[~2011-04-22 20:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-20 9:50 New feature proposal: Support C-code inline? nalaginrut
2011-04-22 20:14 ` Noah Lavine [this message]
2011-04-23 4:24 ` nalaginrut
[not found] ` <BANLkTinaRFc5z5DFvhE-jecwfLOLSv0gjw@mail.gmail.com>
2011-04-25 1:33 ` nalaginrut
2011-04-26 10:11 ` William ML Leslie
2011-05-05 17:04 ` nalaginrut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTim9GGPwx_qFZu5iVt5cg2XDFn=+hg@mail.gmail.com' \
--to=noah.b.lavine@gmail.com \
--cc=NalaGinrut@gmail.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).