This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: After GOOPS integration: Computation with native types!
- To: djurfeldt at nada dot kth dot se
- Subject: Re: After GOOPS integration: Computation with native types!
- From: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Date: Tue, 15 Aug 2000 12:21:06 +0200 (MEST)
- cc: guile at sourceware dot cygnus dot com, rms at gnu dot org, gang-of-four at red-bean dot com, Keisuke Nishida <kxn30 at po dot cwru dot edu>
On 15 Aug 2000, Mikael Djurfeldt wrote:
> Let FOO be a Guile primitive operating on two <integer>s and returning
> an <integer>. Assume that if FOO is given two <fixnum>s, it is
> guaranteed to return a <fixnum> (example: a binary `-').
Well, binary '-' might also return a bignum :-)
> I propose that we instead give each Guile primitive a type signature,
> and that argument checking and conversions are made outside of the
> code of the primitive.
This is a great idea. We should be aware, however, that there are
probably certain types that can not be given a simple signature, for
example an alist. Thus, type signatures would probably only be feasible
for 'atomic' types, which means that some remaining tests would still have
to be performed within the primitives. Thus, while this idea can probably
be applied to a large set of guile's current primitives (especially to the
vast majority of functions in numbers.c), we should try to have a hybrid
approach, where we still can have functions for which that idea can not be
realized. This would also have the benfit to allow a smooth transition.
Further, as the example '-' shows, things are typically not so simple for
the types of results. While you _know_ the types of the input parameters,
you can't tell in advance about the output parameter type, i. e. you
simply can't have two compiled methods for the two cases that
(- <fixnum> <fixnum>) delivers a fixnum or a bignum. (Well, thinking of
it, you might compile the continuation of the '-' into two separate
functions, which are then called depending on the resulting type :-)
Best regards
Dirk