This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Auto type conversion in target languages


From: bickiia@earlham.edu <bickiia@earlham.edu>
>"Marisha Ray & Neil Jerram" <mpriz@dircon.co.uk> wrote:
>>
>>(define-method inet-ntoa ((s <string>))
>>   (inet-ntoa (string->number s)))
>>
>>Is that an improvement?  You might still consider this a form of
>>predeclaration, but at least it is using a mechanism that is
>>soon-to-be core Guile, rather than a roll-your-own type declaration
>>system.
>
>The problem is that this new inet-ntoa isn't proper Scheme.  Scheme is a
>type-aware language, Tcl isn't.  Making Scheme type-neutral isn't a good
>compromise, nor is it necessary.  Tcl isn't core Guile (and, obviously,
>never will be), so the means to accomidate Tcl's type system don't need
>to be core Guile.

I agree - the above definition needn't be core Guile; it could be in the Tcl
module.

>... The code you wrote is just another possible way of
>using this information.  The basic information is "inet-ntoa takes a
>number as its first argument".  Once this information is given for all
>Scheme procedures then the problem is mostly solved.

I agree - that's why I questioned whether my approach was an improvement.
It's just another way of specifying the same basic information.

>Short of this I
>don't see any good solution.

But we could use some kind of reflection to get the basic information
automatically, where reflection can be either documentation-based - type
information is snarfed from the documentation - or the reflection that GOOPS
currently provides for generic functions.  The obvious problem with GOOPS
reflection, though, is that it doesn't apply to most existing (non-generic)
functions.  But when GOOPS is integrated into the core, I don't know -
(speculating wildly) maybe someone has a plan for extending reflection to
all functions?

>Including type-information in the documentation is a potential way to
>make all of this transparent to the end-user/programmer and encourage
>universality.


I don't understand what you mean by transparency and universality in this
context.  But a system for specifying expected type information could also
be used perhaps to auto-generate the SCM_ASSERTs at the beginning of C
primitives and equivalent checks at the beginning of Scheme procedures.

>  -- Ian

    Neil



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]