Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!gatech!howland.reston.ans.net!news.sprintlink.net!dorite!ts1-ind-19.iquest.net!user
From: fritza@iquest.net (Fritz Anderson)
Subject: Re: What's a generic function?
Message-ID: <fritza-2404951529510001@ts1-ind-19.iquest.net>
Sender: news@dorite.use.com (News Admin)
Organization: Himself
References: <12671.9504241610@subnode.aiai.ed.ac.uk>
Date: Mon, 24 Apr 1995 20:29:51 GMT
Lines: 62

In article <12671.9504241610@subnode.aiai.ed.ac.uk>, jeff@aiai.ed.ac.uk
(Jeff Dalton) wrote:

> But addition would be a procedure call plus a type test.  Is that right?
> I suppose the code could be inlined, but will it be?

I think the answer to many of the concerns you raise is that for a
sufficiently-bad implementation of Dylan, all the horrible cases you
advance are possible.  If the only available Dylans were that bad, the
language would be in serious trouble. Given that Dylan isn't on the market
yet, the only value in the horrible cases is as warnings.  I think the
only reply that can be made is that these cases are _in principle_
avoidable; that the implementors are no more fools than you are; and that
their best efforts are going into avoiding horrors.

> That wasn't what I had in mind at that point.  When you have the
> "multiple versions of methods", there presumably must be a test that
> determines which version to use.

The test _in principle_ can be done at compile time, and dispatch avoided;
there could even be inlining.  The in-principle condition is simply that
the programmer attach as much type information to variables as is
instinctual with C++ programmers.  You are right to hold that standard up
to implementors, but without an implementation to criticize, it is idle to
raise -- as a criticism of Dylan itself -- the spectre of runtime
dispatching of integer addition.

> Of course.  But they're different purposes.  I agree that Dylan
> programmers can often just use <integer>.  But if they need (or want)
> something more efficient, then they can get it in C without too much
> trouble.  For a large range of cases, they can just use int, short,
> long, or char.  In Dylan, though, they can't.  The type name is
> implementation-specific.

I'd fully express my annoyance at the equation between "efficiency" and
"the wrong answer as fast as the hardware can generate it," but it seems
to be a personality thing.  Inherent type-safety appeals to some people
less than others, and there's no arguing it.

int, short, long, and char are also implementation-specific.  That's what
the standard says, and that is what you are saying when you demand scalar
types that map directly to the instruction set of one
(implementation-specific) target processor.  You want to pass the same
source unedited from compiler to compiler, processor to processor, and not
be bothered by the fact that the semantics of the program change with each
port.  That approach is defensible only because we've enjoyed about 10
years of consensus on what abstract types those names represent, and
people are willing to suppress the memory of getting caught by whether
chars are signed.  That consensus is eroding.  We Mac programmers have
lived with 16/32 bit ints, and now on RISC Macs, with 64 bit longs and
long doubles that are faster than integers, long enough that we have fewer
illusions that a C program actually maps to a particular algorithm.

Dylan does not assure you that the same name will refer to different types
in different implementations.  Tell me again how this is bad.

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