Project: a good floating point printer/reader.

Project: a good floating point printer/reader.

[Marius Vollmer]

Hi,

I think we need a better floating point printer and or reader.  The
current ones can not print denormal numbers, and the string printed
will not always read back as the exact same number (as required by
R5RS).


guile> (define (t x) (= x (string->number (number->string x))))
guile> (t 0.1432987654987436)
#f
guile> (t 0.1432987654987430)
#t

(That is no special number.  I just tried a couple until t returned #f.)

guile> (/ 1e-308 2)
#.#

Also, Guile should be able to read denormal number:

guile> 1e-309
ERROR: In procedure string->number:
ERROR: Argument out of range: -309
ABORT: (out-of-range)


Good algorithms might be the ones describes in these two papers:

  Printing Floating Point Numbers Quickly and Accurately. Robert
  G. Burger and R. Kent Dybvig. ACM SIGPLAN 1996 Conference on
  Programming Language Design and Implementation, June
  1996.

  http://www.cs.indiana.edu/~dyb/FP-Printing-PLDI96.ps.gz


  William D Clinger. How to Read Floating Point Numbers Accurately. In
  Proceedings of the 1990 ACM Conference on Programming Language
  Design and Implementation, pages 92-101.

  ftp://ftp.ccs.neu.edu/pub/people/will/howtoread.ps

If anyone wants to work on this, that would be great.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Project: a good floating point printer/reader.

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> I think we need a better floating point printer and or reader.  The
> current ones can not print denormal numbers, and the string printed
> will not always read back as the exact same number (as required by
> R5RS).

[...]

> If anyone wants to work on this, that would be great.

I haven't checked yet, but can we use GMP's IO routines?  I'll go see
what's there.  Guess I'll also have to see how they relate to r5rs...

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Project: a good floating point printer/reader.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> I haven't checked yet, but can we use GMP's IO routines?

I don't know, I haven't looked...

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

>> I haven't checked yet, but can we use GMP's IO routines?
>
> I don't know, I haven't looked...

After posting this question, I ended up in a good discussion with Greg
Troxel about using GMP and the resultant licensing issues.  Now it may
be that the two of us are misunderstanding things, but it looks like
if we migrate to require GMP then we may be changing the licensing
requirements for apps that use Guile.  In particular, any app that
wants to link against Guile will have to respect the provisions of the
LGPL which is at least a bit more restrictive than Guile's license.  I
think Greg put the possible issues fairly clearly:

> I'm not sure how I feel personally.  It has been guile project
> policy that guile has the guile exception in order to encourage use
> of guile absolutely everywhere.  Meeting LGPL terms isn't
> necessarily hard, but it requires thought and possibly legal
> department review, whereas the guile exception is easier to read and
> get on with life.

and then in response to a question I had about whether or not dynamic
linking avoided the problem (at least for apps that didn't need to
-static link):

> Dynamic linking is not entirely sufficient to comply with LGPL;
> rights to modify for own use and reverse engineer to debug that use
> must also be granted (see section 6 of LGPL).  It may be that given
> where guile is, and perl/python/tcl, that this is really not
> important strategically to guile and the FSF as a whole.  But I
> maintain that departing from the guile exception is a substantial
> philosophical shift.  Only free software weenies seem to use guile
> as it is, so a change probably wouldn't hurt much.  And I only write
> code mostly on platforms with shlibs, but what about palmos?  What
> if cisco wanted to put guile into IOS?  LGPL compliance would not
> perhaps be intellectually problematic, but it would be a lot of
> work, so they wouldn't want to do this.

If the analysis is correct, then it seems like we have a few choices:

  1) Use (and require) GMP anyway and expect people to accomodate the
     licensing changes.

  2) Use GMP, but have a configure switch that allows you to omit it,
     either with fallback non-GMP bignum support, or perhaps no
     bignums at all.

  3) Ask the relevant parties whether or not they might be willing to
     extend the guile exception to GMP, i.e. add a special Guile
     clause to the GMP license.

  4) Abandon GMP and continue to do things ourselves.

Thoughts?

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Greg Troxel]

  1) Use (and require) GMP anyway and expect people to accomodate the
     licensing changes.

This is a lose; it makes guile harder to use in proprietary software,
and that doesn't serve the project's goals now.  For example, I put
guile into gated, and gated's licensing is painful enough as is
without having to figure out if it is really LGPL compatible.

  2) Use GMP, but have a configure switch that allows you to omit it,
     either with fallback non-GMP bignum support, or perhaps no
     bignums at all.

This is reasonable.  I'd fall back to no bignum support, so that the
code doesn't have to be maintained.  I suspect people in embedded
environments (the target audience for whom LGPL is problematic) don't
care about bignums.  (I've never particularly cared in the places I've
embedded guile (a home-grown emulator and gated), because the
underlying programs don't really support them, so this strategy would
not have actually caused me any grief.)

  3) Ask the relevant parties whether or not they might be willing to
     extend the guile exception to GMP, i.e. add a special Guile
     clause to the GMP license.

I'd ask, and see what happens - I can imagine people saying no, but
not reasonably getting really upset at being asked.  The exception
could apply to GMP as used by guile, and not extend to using the GMP
api directly in derived works.  Something like the following, heavily
ripped off from the guile exception:

 * As a special exception, the Free Software Foundation gives permission
 * for additional uses of the text contained in its release of GMP.
 *
 * The exception is that, if you link the GMP library with other files
 * to produce an executable solely because GMP is required for GUILE,
 * and the resulting work does not call any GMP routines except
 * indirectly as a result of using GUILE, this does not by itself
 * cause the resulting executable to be covered by the GNU General
 * Public License.  Your use of that executable is in no way
 * restricted on account of linking the GMP and GUILE library code
 * into it.
 * 
 * This exception does not however invalidate any other reasons why
 * the executable file might be covered by the GNU General Public License.
 *
 * This exception applies only to the code released by the Free
 * Software Foundation under the name GMP when used as a component of
 * GUILE.  If you copy code from other Free Software Foundation
 * releases into a copy of GMP, as the General Public License permits,
 * the exception does not apply to the code that you add in this way.
 * To avoid misleading anyone as to the status of such modified files,
 * you must delete this exception notice from them.
 *
 * If you write modifications of your own for GMP, it is your choice
 * whether to permit this exception to apply to your modifications.
 * If you do not wish that, delete this exception notice.  */

  4) Abandon GMP and continue to do things ourselves.

This is a lose, too - it seems like wasted effort to maintain multiple
copies of similar code, and it really seems the GMP code is better.

        Greg Troxel <gdt@ir.bbn.com>

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Bruce Korb]

Rob Browning wrote:
> > Dynamic linking is not entirely sufficient to comply with LGPL;
> > rights to modify for own use and reverse engineer to debug that use
> > must also be granted [[...]].  But I
> > maintain that departing from the guile exception is a substantial
> > philosophical shift.  Only free software weenies seem to use guile
> > as it is, so a change probably wouldn't hurt much.

I use guile.  My stuff *is* used in commercial environments
that is hostile to LGPL.  If you change and leave me with no
migration path, I'll wind up locked into a frozen version.
I suppose I could change to a Perl extension engine, but
that's real work....

> If the analysis is correct, then it seems like we have a few choices:
> 
>   1) Use (and require) GMP anyway and expect people to accomodate the
>      licensing changes.

No, please.

>   2) Use GMP, but have a configure switch that allows you to omit it,
>      either with fallback non-GMP bignum support, or perhaps no
>      bignums at all.

If this bypasses the licensing issue, great.

>   3) Ask the relevant parties whether or not they might be willing to
>      extend the guile exception to GMP, i.e. add a special Guile
>      clause to the GMP license.

Murky.  Probably legally okay, but businesses want to focus on
business and not wrestle with murky issues.

>   4) Abandon GMP and continue to do things ourselves.

Better than #1 or #3.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

Bruce Korb <bkorb@pacbell.net> writes:

>>   2) Use GMP, but have a configure switch that allows you to omit it,
>>      either with fallback non-GMP bignum support, or perhaps no
>>      bignums at all.
>
> If this bypasses the licensing issue, great.

It should.

>>   3) Ask the relevant parties whether or not they might be willing to
>>      extend the guile exception to GMP, i.e. add a special Guile
>>      clause to the GMP license.
>
> Murky.  Probably legally okay, but businesses want to focus on
> business and not wrestle with murky issues.

Hmm.  If the GMP license could be changed to have a Guile exception
(identical to the one in the current Guile license), then I don't see
how it's really any murkier on this front than the status quo.

>>   4) Abandon GMP and continue to do things ourselves.
>
> Better than #1 or #3.

Not for all purposes -- depends on what your goals are -- if we want a
full numeric tower that's *fast* on multiple platforms, my impression
is we may be better leaving that to numeric experts like the people
working on GMP.

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Carl R. Witty]

Rob Browning <rlb@defaultvalue.org> writes:

> Not for all purposes -- depends on what your goals are -- if we want a
> full numeric tower that's *fast* on multiple platforms, my impression
> is we may be better leaving that to numeric experts like the people
> working on GMP.

You might want to run some benchmarks before you decide on GMP.  My
impression (from the last time I looked at the issue, maybe a couple
of years ago) is that GMP is intended to be asymptotically fast on
large numbers, but that it's not particularly fast on smaller
numbers.  (For instance, you certainly wouldn't want to get rid of
fixnums and use GMP numbers for all numbers; when I looked at it, GMP
had no optimization for small numbers at all, so computing something
like 2*2 would take about 6 function calls and several loops.)

Does anybody have any idea what distribution of numbers is typical in
programs with bignums?  For instance, are most numbers that are bigger
than 32 bits in the 32 to 64 bit range, or are there lots of numbers
with hundreds of bits?  (I don't suppose anybody really knows the
answer to this question, but you'll have to make a guess before you
can decide whether one implementation is faster than another.)

Carl Witty

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

cwitty@newtonlabs.com (Carl R. Witty) writes:

> You might want to run some benchmarks before you decide on GMP.

Yeah, thanks.  I'm working on trying to get some together.  I was
planning to try to do some benchmarking before I actually proposed
committing the GMP bignums.  In the future I'd like to make it so that
we can benchmark guile fairly easily, so people can evaluate (in at
least some sense) various changes.  Of course it's hard to develop a
"really good" set of benchmarks, heck it's hard to even define what
"really good" means, but it would be nice to be able to get some sense
that you haven't made things terribly, obviously worse...

> My impression (from the last time I looked at the issue, maybe a
> couple of years ago) is that GMP is intended to be asymptotically
> fast on large numbers, but that it's not particularly fast on
> smaller numbers.  (For instance, you certainly wouldn't want to get
> rid of fixnums and use GMP numbers for all numbers;

Definitely not.  The GMP integration I'd done so far was only for
bignums, fixnums are untouched.

> it, GMP had no optimization for small numbers at all, so computing
> something like 2*2 would take about 6 function calls and several
> loops.

Right, I'm not planning on going there :>

> Does anybody have any idea what distribution of numbers is typical
> in programs with bignums?  For instance, are most numbers that are
> bigger than 32 bits in the 32 to 64 bit range, or are there lots of
> numbers with hundreds of bits?  (I don't suppose anybody really
> knows the answer to this question, but you'll have to make a guess
> before you can decide whether one implementation is faster than
> another.)

Probably entirely application specific.  I doubt the most common users
of guile (one of which is gnucash) use bignums all that often... or do
they? :> Come to think of it, in gnucash the dates are stored as a
cons pair (secs-since-epoch-utc . ns), so these days, the secs are
well over fixnum size.  Of course on 64-bit machines, if you have 6X
bit fixnums, bignums would be rare.

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Jeff Read]

On Thu, May 16, 2002 at 10:35:44AM -0500, Rob Browning wrote:
> 
> If the analysis is correct, then it seems like we have a few choices:
> 
>   1) Use (and require) GMP anyway and expect people to accomodate the
>      licensing changes.
> 
>   2) Use GMP, but have a configure switch that allows you to omit it,
>      either with fallback non-GMP bignum support, or perhaps no
>      bignums at all.
> 
>   3) Ask the relevant parties whether or not they might be willing to
>      extend the guile exception to GMP, i.e. add a special Guile
>      clause to the GMP license.
> 
>   4) Abandon GMP and continue to do things ourselves.
> 
> Thoughts?

I don't think option 1 is a good idea, both from a licensing standpoint (because changing licenses, especially from less restrictive ones to more restrictive ones, is tricky) and from a more pragmatic standpoint concerning Guile's deployment.

I rather like the notion of Guile as "SIOD on steroids". Basically a relatively lightweight, self-contained, but very powerful and RnRS-compliant Scheme with strengths in extension and integration. For this purpose, anyway, options 2 and 4 are best. Option 3 is a possibility if we bundle in GMP with Guile.

Right now I'm compiling Guile out-of-the-box (out-of-the-tarball?) on a stock OpenBSD system, which doesn't come all tricked out like a lot of popular GNU/Linux distros do. I'd like to continue to be able to do this, and not sweat too much about libraries that Guile depends on for its very existence.

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

"Jeff Read" <bitwize@snet.net> writes:

> I rather like the notion of Guile as "SIOD on steroids". Basically a
> relatively lightweight, self-contained, but very powerful and
> RnRS-compliant Scheme with strengths in extension and
> integration. For this purpose, anyway, options 2 and 4 are
> best. Option 3 is a possibility if we bundle in GMP with Guile.

Option 3 could be possible even if we don't bundle.  It kinda depends
on how RMS, the GMP people, etc. feel about the issue.  I suspect
there may not be any serious technical reasons preventing a Guile
exception from being added to the mainstream GMP license, but that
doesn't mean they'd think it was a good idea :>

> Right now I'm compiling Guile out-of-the-box (out-of-the-tarball?)
> on a stock OpenBSD system, which doesn't come all tricked out like a
> lot of popular GNU/Linux distros do. I'd like to continue to be able
> to do this, and not sweat too much about libraries that Guile
> depends on for its very existence.

So in your opinion, would requiring GMP, even if the licensing issues
were worked out be too big a hassle?

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Jeff Read]

On Thu, May 16, 2002 at 12:22:08PM -0500, Rob Browning wrote:
> 
> So in your opinion, would requiring GMP, even if the licensing issues
> were worked out be too big a hassle?

It would be something of a hassle, yes. My main use for Guile is as a scripting workhorse. Wherever I go, I'd like Guile to go with me (inasmuch as my movement is restricted to vaguely unixoid systems) with a minimum of fuss. Depending on another external lib complicates that. Guile depends on qthreads as it is, but that is essentially resolved by bundling qthreads with Guile. Which is why I mentioned bundling GMP.

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

"Jeff Read" <bitwize@snet.net> writes:

> It would be something of a hassle, yes. My main use for Guile is as
> a scripting workhorse. Wherever I go, I'd like Guile to go with me
> (inasmuch as my movement is restricted to vaguely unixoid systems)
> with a minimum of fuss. Depending on another external lib
> complicates that. Guile depends on qthreads as it is, but that is
> essentially resolved by bundling qthreads with Guile. Which is why I
> mentioned bundling GMP.

OK, well we should keep that in mind, though as long as GMP supports
the target architecture, and we arrange guile to handle a
--with-gmp=/some/prefix argument, I'm not sure that keeping a copy of
GMP's source tree inside ours buys much over just making sure the GMP
tarfile is handy, and that we have good docs about any required
configure args, etc.

This is all presuming we were in a situation where you had to have
GMP, i.e we didn't take the route allowing --without-gmp, or similar.

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Jeff Read]

On Thu, May 16, 2002 at 06:17:07PM -0500, Rob Browning wrote:
> 
> OK, well we should keep that in mind, though as long as GMP supports
> the target architecture, and we arrange guile to handle a
> --with-gmp=/some/prefix argument, I'm not sure that keeping a copy of
> GMP's source tree inside ours buys much over just making sure the GMP
> tarfile is handy, and that we have good docs about any required
> configure args, etc.
> 
> This is all presuming we were in a situation where you had to have
> GMP, i.e we didn't take the route allowing --without-gmp, or similar.
> 

This is acceptable. My main concern is that Guile not exhibit "creeping DLL hell". I once heard a statistic that said the Gnucash project, for instance, has some 60 lib dependencies. Most of these are probably due to interlocking GNOME dependencies... but that factors into why I don't touch GNOME with a ten-foot pole.

Ideally, as you said, we'd provide an option to allow the user to opt out of GMP usage, hopefully with no loss in functionality.

-- 
Jeffrey T. Read
"I fight not for me but the blind babe Justice!" --Galford

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

"Jeff Read" <bitwize@snet.net> writes:

> This is acceptable. My main concern is that Guile not exhibit
> "creeping DLL hell".

Well I'd fight that too.  I agree that it's important, *especially*
given Guile's intent, to remain fairly self-contained, but I also
think that GMP may be a fairly special case.  It appears to do a hard
job pretty well, and probably isn't something where it's easy to roll
your own and get it right.

>I once heard a statistic that said the Gnucash project, for instance,
>has some 60 lib dependencies. Most of these are probably due to
>interlocking GNOME dependencies... but that factors into why I don't
>touch GNOME with a ten-foot pole.

I suspect it's over 60, but you're also right that it's mostly stuff
that's pulled in via GNOME.  The "lots of tiny libraries" doesn't
really cause me all that much trouble, but it's hard to evaluate what
it would be like if I weren't using Debian or some other distribution
that handles the packaging issues well.

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> OK, well we should keep that in mind, though as long as GMP supports
> the target architecture, and we arrange guile to handle a
> --with-gmp=/some/prefix argument, I'm not sure that keeping a copy of
> GMP's source tree inside ours buys much over just making sure the GMP
> tarfile is handy, and that we have good docs about any required
> configure args, etc.

Technically, I think we should not have a copy of GMP in our sources.
The libltdl thing is already somewhat confusing: when you first
configure Guile without a libltdl in your system, it will install it.
When you configure a new version of Guile, it will find the old
libltdl and will use it, while it should probably replace it with the
new version from Guile.

I'd say the user should explicitely state that he/she doesn't want to
use GMP.  When --without-gmp is not given, configure should abort when
GMP is not found.  Otherwise people might be tricked into building a
Guile with inferior number support without noticing it.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> If the analysis is correct,

I think it is, on every point.  I should have caught the license
problem earlier, sorry.[1]

> then it seems like we have a few choices:
> 
>   1) Use (and require) GMP anyway and expect people to accomodate the
>      licensing changes.

Personally, I would be happy to see Guile use the LGPL or even the
unmodified GPL.  It makes things easier (as shown by this very issue),
but relicensing towards more restrictions should not be done lightly.
People have said that they do make use of the exception, and taking
that choice away from them would be bad.

>   2) Use GMP, but have a configure switch that allows you to omit it,
>      either with fallback non-GMP bignum support, or perhaps no
>      bignums at all.

I think this is acceptable.  A not-GMP-using libguile would be
technically inferior to the default libguile, but that can only be
expected.  If you want the good stuff, agree to our terms.

If it is not too much hassle, we should keep our current bignum
implementation as the fall-back.  We might have a thin interface layer
between libguile and GMP (as some SCM_I_BIGNUM_ macros say).  That
interface could be tuned to be efficiently implemented by GMP, and
straightforwardly but not necessarily efficiently implemented with the
current stuff.  What I'm trying to say is that we should not make
ourselves a lot of work to keep the fall back be efficient.

>   3) Ask the relevant parties whether or not they might be willing to
>      extend the guile exception to GMP, i.e. add a special Guile
>      clause to the GMP license.

That would be a solution, but somehow, I don't like it very much.  It
can't hurt to ask.  I am a bit unsure about my own position here, so I
would have to think about this a bit more.  I would ask RMS what he
thinks about removing the exception from libguile and about adding the
restriction to GMP. But I don't know yet in what direction I would
argue myself...

>   4) Abandon GMP and continue to do things ourselves.

That would not be good.  GMP is the technically Right Thing to use,
and it would be strange to refuse our 'own' software for its
restrictive license terms, wouldn't it?



[1] Somehow, it escaped me that the exception was not equivalent to
LGPL.  I had this image in my head where the FSF were trying a new
strategy since they didn't really seem to like the LGPL any more.  But
I also _knew_ that the exception did not turn the GPL into the LGPL.
If someone had asked me directly... :-/

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Bruce Korb]

Marius Vollmer wrote:

> >   2) Use GMP, but have a configure switch...
> 
> I think this is acceptable.  A not-GMP-using libguile would be
> technically inferior to the default libguile, but that can only be
> expected.  If you want the good stuff, agree to our terms.

Then you cannot complain if a proprietary product uses a GMP-using
libguile.  The problem is that the person installing libguile is
not necessarily the installer of the proprietary produce.  e.g.,
SuSE distributes Linux with a pre-packaged libguile.  The proprietary
product installation should do what?  Check for GMP-enablement in
libguile and choke, or just install?

> If it is not too much hassle,

Methinks it is.  I also doubt any of my "clients" use big nums,
but I put no constraints on their Scheme code, either.

> What I'm trying to say is that we should not make
> ourselves a lot of work to keep the fall back be efficient.

Fallback isn't the issue.  You're talking about a new
library with new usage restrictions.  Think:  new name, too.

> >   3) Ask the relevant parties whether or not they might be willing to
> >      extend the guile exception to GMP, i.e. add a special Guile
> >      clause to the GMP license.
> 
> That would be a solution,

It would preclude needing to rename.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Bruce Korb <bkorb@pacbell.net> writes:

> Marius Vollmer wrote:
> 
> > >   2) Use GMP, but have a configure switch...
> > 
> > I think this is acceptable.  A not-GMP-using libguile would be
> > technically inferior to the default libguile, but that can only be
> > expected.  If you want the good stuff, agree to our terms.
> 
> Then you cannot complain if a proprietary product uses a GMP-using
> libguile.

I could complain... but I understand that it would look like a scam to
the other side.

> The problem is that the person installing libguile is not
> necessarily the installer of the proprietary produce.  e.g., SuSE
> distributes Linux with a pre-packaged libguile.  The proprietary
> product installation should do what?  Check for GMP-enablement in
> libguile and choke, or just install?

As you say, we can handle this with giving distinct names to libguile,
depending on its license.

> > If it is not too much hassle,
> 
> Methinks it is.  I also doubt any of my "clients" use big nums,
> but I put no constraints on their Scheme code, either.

Without bignums, fixnums would overflow into floats.  So we would have
to have two versions of 'bignums' anyway, whether they are implemented
with floats or with our current bignum code.  Assuming that our
current bignum code is correct, it wouldn't need much maintainance
itself.

> > What I'm trying to say is that we should not make
> > ourselves a lot of work to keep the fall back be efficient.
> 
> Fallback isn't the issue.  You're talking about a new
> library with new usage restrictions.  Think:  new name, too.

Yep, this occured to me... but which one should be plain "libguile"?
The one with GMP or the one without?  Also, we already have API
variants: with or without threads, with or without heavy-weight
debugging support.  Maybe we should give distinct names to them also?

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Bruce Korb]

Marius Vollmer wrote:

> Without bignums, fixnums would overflow into floats.  ...
> Assuming that our current bignum code is correct,
> it wouldn't need much maintainance itself.

Works for me.  :-)

> > > What I'm trying to say is that we should not make
> > > ourselves a lot of work to keep the fall back be efficient.
> >
> > Fallback isn't the issue.  You're talking about a new
> > library with new usage restrictions.  Think:  new name, too.
> 
> Yep, this occured to me... but which one should be plain "libguile"?

The one without new restrictions.

> The one with GMP or the one without?  Also, we already have API
> variants: with or without threads, with or without heavy-weight
> debugging support.  Maybe we should give distinct names to them also?

If there are usage constraints, yes.  Otherwise, it's a config
issue.  "Does the library support function X?" is a fundamentally
different question than, "Am I allowed to link with the library at all?"

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Bruce Korb <bkorb@pacbell.net> writes:

> > Yep, this occured to me... but which one should be plain "libguile"?
> 
> The one without new restrictions.

Yes that seems to be the best choice.  (Although I was hoping that we
could find an argument that let's us use the nicer "libguile" for the
'best' library.)  We would also need to add an option to guile-config,
no?

Anyway, I'm sure we can find a good solution that doesn't turn
libguile into a trap for people that want the exception.

> > The one with GMP or the one without?  Also, we already have API
> > variants: with or without threads, with or without heavy-weight
> > debugging support.  Maybe we should give distinct names to them also?
> 
> If there are usage constraints, yes.  Otherwise, it's a config
> issue.  "Does the library support function X?" is a fundamentally
> different question than, "Am I allowed to link with the library at all?"

Yes, agreed.  Good point.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Bruce Korb]

Marius Vollmer wrote:
> We would also need to add an option to guile-config, no?

Probably:

  LDOPTS=`guile-config --license=gpl link`

Yes?

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Marius Vollmer]

Bruce Korb <bkorb@pacbell.net> writes:

> Marius Vollmer wrote:
> > We would also need to add an option to guile-config, no?
> 
> Probably:
> 
>   LDOPTS=`guile-config --license=gpl link`
> 
> Yes?

Yes, or rather "--license=lgpl".

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: The Guile license and the use of LGPL libs (like GMP).

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> If it is not too much hassle, we should keep our current bignum
> implementation as the fall-back.  We might have a thin interface layer
> between libguile and GMP (as some SCM_I_BIGNUM_ macros say).  That
> interface could be tuned to be efficiently implemented by GMP, and
> straightforwardly but not necessarily efficiently implemented with the
> current stuff.  What I'm trying to say is that we should not make
> ourselves a lot of work to keep the fall back be efficient.

I think I can do this without too much trouble.  I'll go ahead and see
after I get the next beta out and start working on 1.7 again.

> That would be a solution, but somehow, I don't like it very much.  It
> can't hurt to ask.  I am a bit unsure about my own position here, so I
> would have to think about this a bit more.  I would ask RMS what he
> thinks about removing the exception from libguile and about adding the
> restriction to GMP. But I don't know yet in what direction I would
> argue myself...

I don't really like this option too much either, unless the FSF really
does consider Guile a Very Special Case.

> That would not be good.  GMP is the technically Right Thing to use,
> and it would be strange to refuse our 'own' software for its
> restrictive license terms, wouldn't it?

Agreed.

> [1] Somehow, it escaped me that the exception was not equivalent to
> LGPL.  I had this image in my head where the FSF were trying a new
> strategy since they didn't really seem to like the LGPL any more.  But
> I also _knew_ that the exception did not turn the GPL into the LGPL.
> If someone had asked me directly... :-/

Well, my recollecion is that Guile was intended to have a somewhat
special status.  Since the FSF kinda hoped for World Domination on the
extension language front, the goal was to make sure the license didn't
get in the way, but only with respect to that particular issue --
hence the exception.  I can see the point, but it does make things a
little more complicated when Guile wants to depend (at the direct
linking level) on anything else.

Lets see how hard it is for me to get a --without-gmp fallback
working.  If I can, then we can probably just put a note in LICENSE
and forget about it for now.  I'll have to see how to best arrange
this.

Anyone here familiar enough with goops to know if we might be able to
handle bignums via goops with sufficient efficiency?  I kinda doubt
it, but I was wondering.  In any case I want to see if there's a way
to refactor the numerics so that the bignum code is less tangled with
the rest.  I'm not sure it's possible without too much loss of
efficiency, but I'll check.

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

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel