unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* Bad deprecation warnings in numbers.c
@ 2002-04-01 15:10 Neil Jerram
  2002-04-02 19:16 ` Dirk Herrmann
  0 siblings, 1 reply; 6+ messages in thread
From: Neil Jerram @ 2002-04-01 15:10 UTC (permalink / raw)


There is a group of deprecation warnings in (stable) numbers.c that
say, for example:

  scm_c_issue_deprecation_warning ("`scm_mkbig' is deprecated. "
                                   "Use `scm_i_mkbig' instead.");

No!!!!!

This directly contradicts our aim of using `scm_i_' to mark Guile
internals, which libguile users shouldn't use _at all_!

What's the right thing here?  Could we do it before 1.6?

        Neil


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad deprecation warnings in numbers.c
  2002-04-01 15:10 Bad deprecation warnings in numbers.c Neil Jerram
@ 2002-04-02 19:16 ` Dirk Herrmann
  2002-04-13 12:44   ` Neil Jerram
  2002-04-14  5:11   ` Rob Browning
  0 siblings, 2 replies; 6+ messages in thread
From: Dirk Herrmann @ 2002-04-02 19:16 UTC (permalink / raw)
  Cc: Guile Bugs

On 1 Apr 2002, Neil Jerram wrote:

> There is a group of deprecation warnings in (stable) numbers.c that
> say, for example:
> 
>   scm_c_issue_deprecation_warning ("`scm_mkbig' is deprecated. "
>                                    "Use `scm_i_mkbig' instead.");
> 
> No!!!!!
> 
> This directly contradicts our aim of using `scm_i_' to mark Guile
> internals, which libguile users shouldn't use _at all_!
> 
> What's the right thing here?  Could we do it before 1.6?

IMO, people should not use any of these functions at all.  We should try 
to remove their use from other places within guile as well.  The reason
is, that these functions depend on the implementation of the bignums,
which should be considered the secret knowledge of the number
implementation.  It is, btw., likely to change in the not too far future,
if for example we manage the switch to the GNU mp library.

Best regards,
Dirk Herrmann


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad deprecation warnings in numbers.c
  2002-04-02 19:16 ` Dirk Herrmann
@ 2002-04-13 12:44   ` Neil Jerram
  2002-04-15 21:42     ` Dirk Herrmann
  2002-04-14  5:11   ` Rob Browning
  1 sibling, 1 reply; 6+ messages in thread
From: Neil Jerram @ 2002-04-13 12:44 UTC (permalink / raw)
  Cc: Guile Bugs

>>>>> "Dirk" == Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

    Dirk> On 1 Apr 2002, Neil Jerram wrote:
    >> There is a group of deprecation warnings in (stable) numbers.c that
    >> say, for example:
    >> 
    >> scm_c_issue_deprecation_warning ("`scm_mkbig' is deprecated. "
    >> "Use `scm_i_mkbig' instead.");
    >> 
    >> No!!!!!
    >> 
    >> This directly contradicts our aim of using `scm_i_' to mark Guile
    >> internals, which libguile users shouldn't use _at all_!
    >> 
    >> What's the right thing here?  Could we do it before 1.6?

    Dirk> IMO, people should not use any of these functions at all.
    Dirk> We should try to remove their use from other places within
    Dirk> guile as well.  The reason is, that these functions depend
    Dirk> on the implementation of the bignums, which should be
    Dirk> considered the secret knowledge of the number
    Dirk> implementation.  It is, btw., likely to change in the not
    Dirk> too far future, if for example we manage the switch to the
    Dirk> GNU mp library.

OK, but...

- can you think of any good reasons why developers might have been
  using these functions anyway?

- if there are such reasons, what could we suggest to developers that
  they do instead?

If there are no valid reasons for using these functions, we should
change the messages to say that "this function was never intended to
be part of the libguile API".  (And then the mailing list may later
produce a valid reason for us! :-)

If there are valid reasons, we should change the messages to indicate
what developers should _really_ be doing instead.

Regards,
        Neil


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad deprecation warnings in numbers.c
  2002-04-02 19:16 ` Dirk Herrmann
  2002-04-13 12:44   ` Neil Jerram
@ 2002-04-14  5:11   ` Rob Browning
  2002-04-15 21:44     ` Dirk Herrmann
  1 sibling, 1 reply; 6+ messages in thread
From: Rob Browning @ 2002-04-14  5:11 UTC (permalink / raw)
  Cc: Neil Jerram, Guile Bugs

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> IMO, people should not use any of these functions at all.  We should
> try to remove their use from other places within guile as well.  The
> reason is, that these functions depend on the implementation of the
> bignums, which should be considered the secret knowledge of the
> number implementation.  It is, btw., likely to change in the not too
> far future, if for example we manage the switch to the GNU mp
> library.

FWIW I've got GMP bignum's working here :> Guile passes make check,
but I've still got a lot of FIXMEs and #warnings to repair.

IMO, scm_i_mkbig probably shouldn't be used by user code and shouldn't
even be in numbers.h unless (as is the case ATM) other libguile code
needs to call it.  (The only way around that I can think of would be
go to a "public/private" header arrangement.)

However, a function like 

  void scm_num2mpz(mpz_t dest, SCM src);

(or similar) might not be a bad idea.  We could continue to provide it
in libguile or in a helper lib indefinitely, no matter what our
internal representation is.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad deprecation warnings in numbers.c
  2002-04-13 12:44   ` Neil Jerram
@ 2002-04-15 21:42     ` Dirk Herrmann
  0 siblings, 0 replies; 6+ messages in thread
From: Dirk Herrmann @ 2002-04-15 21:42 UTC (permalink / raw)
  Cc: Guile Bugs

On 13 Apr 2002, Neil Jerram wrote:

>     Dirk> IMO, people should not use any of these functions at all.
>     Dirk> We should try to remove their use from other places within
>     Dirk> guile as well.  The reason is, that these functions depend
>     Dirk> on the implementation of the bignums, which should be
>     Dirk> considered the secret knowledge of the number
>     Dirk> implementation.  It is, btw., likely to change in the not
>     Dirk> too far future, if for example we manage the switch to the
>     Dirk> GNU mp library.
[...]
> If there are no valid reasons for using these functions, we should
> change the messages to say that "this function was never intended to
> be part of the libguile API".  (And then the mailing list may later
> produce a valid reason for us! :-)

IMO that's a good way to go.

Best regards
Dirk Herrmann


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Bad deprecation warnings in numbers.c
  2002-04-14  5:11   ` Rob Browning
@ 2002-04-15 21:44     ` Dirk Herrmann
  0 siblings, 0 replies; 6+ messages in thread
From: Dirk Herrmann @ 2002-04-15 21:44 UTC (permalink / raw)
  Cc: Neil Jerram, Guile Bugs

On Sun, 14 Apr 2002, Rob Browning wrote:

> FWIW I've got GMP bignum's working here :> Guile passes make check,
> but I've still got a lot of FIXMEs and #warnings to repair.

Sounds great.

> IMO, scm_i_mkbig probably shouldn't be used by user code and shouldn't
> even be in numbers.h unless (as is the case ATM) other libguile code
> needs to call it.  (The only way around that I can think of would be
> go to a "public/private" header arrangement.)
> 
> However, a function like 
> 
>   void scm_num2mpz(mpz_t dest, SCM src);
> 
> (or similar) might not be a bad idea.  We could continue to provide it
> in libguile or in a helper lib indefinitely, no matter what our
> internal representation is.

I like this idea.  However, I favor the 'helper lib' approach.

Best regards
Dirk Herrmann


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2002-04-15 21:44 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-04-01 15:10 Bad deprecation warnings in numbers.c Neil Jerram
2002-04-02 19:16 ` Dirk Herrmann
2002-04-13 12:44   ` Neil Jerram
2002-04-15 21:42     ` Dirk Herrmann
2002-04-14  5:11   ` Rob Browning
2002-04-15 21:44     ` Dirk Herrmann

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).