Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.alpha.net!uwm.edu!spool.mu.edu!howland.reston.ans.net!cs.utexas.edu!news.sprintlink.net!dorite!ts2-ind-22.iquest.net!user
From: fritza@iquest.net (Fritz Anderson)
Subject: Re: Integers in dylan
Message-ID: <fritza-2803951259130001@ts2-ind-22.iquest.net>
Sender: news@dorite.use.com (News Admin)
Organization: Himself
References: <alain-2703951633030001@hammer.uchicago.edu>
Date: Tue, 28 Mar 1995 17:59:13 GMT
Lines: 57

In article <alain-2703951633030001@hammer.uchicago.edu>,
alain@cs.uchicago.edu (Alain Roy) wrote:

> I'm confused by integers in Dylan. There are integers and big integers.
> When I interface with C code, how will it deal with the fact that some
> procedures require different sized or signed integers? Will there be any
> sort of checking to make sure I'm not passing something ridiculously out
> of bounds? Will there be conversions going on everytime I pass an integer?
> 
> I suppose some of the same questions apply to strings. C strings and, for
> the Mac, pascal strings.
> 
> -alain

Interface between Dylan and C is an issue that the standard leaves to
implementors.  I gather from postings here that a Dylan/C interface is not
likely to be standardized until everybody's version 1 has been out long
enough to provide a basis for discussion.

Apple Dylan has an interface called Creole, but those who know much about
it are nondisclosed.  Assuming a useful C/Dylan interface, you can
theorize on some minimal features.  I emphasize I am not describing any
interface I've seen.

For strings, a minimal interface could leave you with as little as a
machine pointer and a guarantee of a certain amount of storage for the
string.  You or the interface could then build enclosing classes to impose
byte-valued <sequence> behavior on the contents.  You'd also expect
as(<class>, value) methods to coerce between Pascal, C and Dylan strings.

For integers, I think the Dylan outlook would say this:  Dylan objects can
constrain themselves, C objects rely on the programmer's knowledge to
enforce (or at least work within) their constraints.  Dylan should give
you full service on its objects; but at the C border crossing, you are
pushing the value into territory in which you have to constrain it by
hand.  It's your responsibility, before it crosses the border, to ensure
that the value is within the range the target storage can handle.  If the
value is out of range, it is up to the implementor to decide whether to
truncate the high bits, take the nearest extreme value, use zero, leave
the original garbage in the storage, or whatever else pleases him.  "The
behavior," in the formula of standards-writers world-wide, "is undefined."

I'd imagine this could involve coercion at the interface, depending on how
integers are implemented.  My nave assumption is that an implementor
would have to be crazy not to use native format to keep values that would
fit in a processor register.  But I see by the DIRM that there is no
explicit <big-integer> subclass of <integer>, so it's possible that that
isn't a good assumption.  An interface writer might care to implement
<processor-word> and <processor-longword> classes that are guaranteed to
use native formats, at the expense of not checking overflows.

-- 
Fritz Anderson         Indianapolis, Indiana   317-257-2227
fritza@well.sf.ca.us   fritza@iquest.net       WT9T
I've begun to suspect that large portions of the Universe -- possibly
including history itself -- do not properly reward fair play, and I tell
you I'm pretty worked up about it.
