GNU bug report logs - #10974
guile-user@gnu.org

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10974 in the body.
You can then email your comments to 10974 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alexei Matveev <alexei.matveev <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: guile-user <at> gnu.org
Date: Thu, 8 Mar 2012 12:36:37 +0100

Hi, All,

For use from a Fortran program I am collecting API fixes for libguile.so
as wrapper functions for what is provided to C-programs as macros.
I noted that some of the macros are function-macros some are symbol
macros. An example of the latter is

  #define scm_to_int scm_to_int23

This is inconsistent and makes escaping such macros slightly more difficult.
(Honestly I dont know a way yet).

One guile developer on IRC said this is "probably a good thing to fix"
so I report
it here. I dont build Guile 2 myself as the installations I use are quite
dated/conservative.

As a background, Fortran allows you to declare "foreign" functions, for example,
like this:

type, public, bind(c) :: scm_t
   private
   integer(c_intptr_t) :: do_not_ever_use
end type scm_t

interface
  function scm_symbol_p (obj) result (yes) bind (c)
     type(scm_t), intent(in), value :: obj
    type(scm_t) :: yes
  end function scm_symbol_p
  ...
end interface

This makes use of library functions quite handy. But it does not provide a
way to access a C-macro, naturally.

Alexei

#include <libguile.h>

SCM guile_macro_scm_from_int (int i);
int guile_macro_scm_to_int (SCM obj);

int (scm_is_true) (SCM obj);
int (scm_is_symbol) (SCM obj);

int (scm_is_null) (SCM obj);
SCM (scm_eol) (void);

SCM guile_macro_scm_from_int (int i)
{
  return scm_from_int(i);
}

int guile_macro_scm_to_int (SCM obj)
{
  return scm_to_int(obj);
}

int (scm_is_true) (SCM obj)
{
  return scm_is_true(obj);
}

int (scm_is_symbol) (SCM obj)
{
  return scm_is_symbol(obj);
}

int (scm_is_null) (SCM obj)
{
  return scm_is_null(obj);
}

SCM (scm_eol) ()
{
  return SCM_EOL;
}

Message #8 received at 10974 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alexei Matveev <alexei.matveev <at> gmail.com>
Cc: 10974 <at> debbugs.gnu.org
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Mon, 02 Jul 2012 11:38:27 +0200

Hi,

Sorry for the late reply.

Alexei Matveev <alexei.matveev <at> gmail.com> skribis:

> For use from a Fortran program I am collecting API fixes for libguile.so
> as wrapper functions for what is provided to C-programs as macros.
> I noted that some of the macros are function-macros some are symbol
> macros. An example of the latter is
>
>   #define scm_to_int scm_to_int23

The macros in numbers.h that are “symbol macros”, such as
‘scm_from_int’, allow users to write code like:

  &scm_from_int

This wouldn’t be possible if these were function macros.

Thus, I think things will have to remain this way.

What do you think?

Thanks,
Ludo’.

Message #11 received at 10974 <at> debbugs.gnu.org (full text, mbox):

From: Alexei Matveev <alexei.matveev <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>, 
	guile-devel <guile-devel <at> gnu.org>
Cc: 10974 <at> debbugs.gnu.org
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Mon, 2 Jul 2012 12:15:46 +0200

On Mon, Jul 2, 2012 at 11:38 AM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>
>> For use from a Fortran program I am collecting API fixes for libguile.so
>> as wrapper functions for what is provided to C-programs as macros.
>> I noted that some of the macros are function-macros some are symbol
>> macros. An example of the latter is
>>
>>   #define scm_to_int scm_to_int23
>
> The macros in numbers.h that are “symbol macros”, such as
> ‘scm_from_int’, allow users to write code like:
>
>   &scm_from_int
>
> This wouldn’t be possible if these were function macros.
>
> Thus, I think things will have to remain this way.

Hi,

It's ok. You may close it.

I still think it could be less confusing if the libguile.so implemented/provided
functions as advertised in Guile API docs for the sake of interfacing to
languages other than C. And &scm_from_int wold also work if it were a real
function.

But there are many more macros, so such a link-time interface would be a
lot of work, I realize by now.

Alexei

Message #16 received at 10974-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alexei Matveev <alexei.matveev <at> gmail.com>
Cc: 10974-done <at> debbugs.gnu.org, guile-devel <guile-devel <at> gnu.org>
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Mon, 02 Jul 2012 21:17:59 +0200

Hi,

Alexei Matveev <alexei.matveev <at> gmail.com> skribis:

> It's ok. You may close it.

Thanks.

> I still think it could be less confusing if the libguile.so implemented/provided
> functions as advertised in Guile API docs for the sake of interfacing to
> languages other than C. And &scm_from_int wold also work if it were a real
> function.
>
> But there are many more macros, so such a link-time interface would be a
> lot of work, I realize by now.

Yeah.  Though here, you could still write bindings for ‘scm_from_int32’
(the real function) instead of ‘scm_from_int’, for instance, no?

Thanks,
Ludo’.

Message #17 received at 10974-done <at> debbugs.gnu.org (full text, mbox):

From: Alexei Matveev <alexei.matveev <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 10974-done <at> debbugs.gnu.org, guile-devel <guile-devel <at> gnu.org>
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Mon, 2 Jul 2012 21:35:58 +0200

> Yeah.  Though here, you could still write bindings for ‘scm_from_int32’
> (the real function) instead of ‘scm_from_int’, for instance, no?

Right.

I assume there was a reason to introduce scm_to/from_int macros
and that it gets defined to either -32 or -64 versions depending on
the build/platform (not sure what else, but Guile packagers know it).
Using a specific one invites for portability problems or a pre-processor
mess.

My preferred solution is to compile a

   guile_api_fix_scm_from_int()

that refers to scm_from_int() macro and relies on the expertise
of the Guile packagers to decide which particular instance it is
resolved to.

Alexei

Message #20 received at 10974 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 10974 <at> debbugs.gnu.org, Alexei Matveev <alexei.matveev <at> gmail.com>
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Mon, 02 Jul 2012 23:45:43 +0200

On Mon 02 Jul 2012 11:38, ludo <at> gnu.org (Ludovic Courtès) writes:

> The macros in numbers.h that are “symbol macros”, such as
> ‘scm_from_int’, allow users to write code like:
>
>   &scm_from_int
>
> This wouldn’t be possible if these were function macros.

Interesting, I hadn't thought of that.

> Thus, I think things will have to remain this way.

Would this be "fixed" if we changed these to be implemented as inline
functions?

Dunno, just thinking out loud.

Andy
-- 
http://wingolog.org/

Message #21 received at 10974-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Alexei Matveev <alexei.matveev <at> gmail.com>
Cc: 10974-done <at> debbugs.gnu.org, guile-devel <guile-devel <at> gnu.org>
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Tue, 03 Jul 2012 00:33:50 +0200

Hi,

Alexei Matveev <alexei.matveev <at> gmail.com> skribis:

> I assume there was a reason to introduce scm_to/from_int macros
> and that it gets defined to either -32 or -64 versions depending on
> the build/platform (not sure what else, but Guile packagers know it).
> Using a specific one invites for portability problems or a pre-processor
> mess.

Yes, but it could be that the FORTRAN environment provides info about
sizeof (int) at compile-time, which could be used to wire to the right C
function.

Thanks,
Ludo’.

Message #24 received at 10974 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10974 <at> debbugs.gnu.org, Alexei Matveev <alexei.matveev <at> gmail.com>
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Tue, 03 Jul 2012 00:35:29 +0200

Hi,

Andy Wingo <wingo <at> pobox.com> skribis:

> Would this be "fixed" if we changed these to be implemented as inline
> functions?

In some way, though their address could still not be taken.

Thanks,
Ludo’.

Message #27 received at 10974 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 10974 <at> debbugs.gnu.org, Alexei Matveev <alexei.matveev <at> gmail.com>
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Tue, 03 Jul 2012 01:17:54 +0200

On Tue 03 Jul 2012 00:35, ludo <at> gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo <at> pobox.com> skribis:
>
>> Would this be "fixed" if we changed these to be implemented as inline
>> functions?
>
> In some way, though their address could still not be taken.

Sorry to be obtuse, but with our inline functions, we also residualize a
concrete instantiation (via the inline.c madness).  Does that not work?

A
-- 
http://wingolog.org/

Message #30 received at 10974 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 10974 <at> debbugs.gnu.org, Alexei Matveev <alexei.matveev <at> gmail.com>
Subject: Re: bug#10974: guile-user <at> gnu.org
Date: Tue, 03 Jul 2012 10:09:27 +0200

Hi,

Andy Wingo <wingo <at> pobox.com> skribis:

> On Tue 03 Jul 2012 00:35, ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo <at> pobox.com> skribis:
>>
>>> Would this be "fixed" if we changed these to be implemented as inline
>>> functions?
>>
>> In some way, though their address could still not be taken.
>
> Sorry to be obtuse, but with our inline functions, we also residualize a
> concrete instantiation (via the inline.c madness).  Does that not work?

Yes, right, so we could just inline them all.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.