Umm... I might have misunderstood your point, but I think Haskell doesn't
really do coercion. In general type conversions are explicit. For example,
> x :: Int
> x = 3.0
will be rejected by the compiler (mine's GHC).
> y :: Double
> y = 3
will be accepted, I suppose because 3 is good enough (but only as a literal)
for Doubles. Assuming the types given above, both
> y = x
and
> z :: Double
> z = x + y
will be rejected, because (1) you can't bind an Int to a Double, and (2)
there is no definition of (+) with type Int -> Double -> Double (nor do I
think the type system will let you define one, as (+) has type a -> a -> a,
where "a" would be either Int or Double in our case, but not a mixture of
types.)
You must explicitly convert the Int to a Double:
> y = fromIntegral x
> x = fromIntegral x + y
My position: I prefer explicit conversion, mainly because I've been bitten
by implicit conversion in the past (I'd rather have the compiler tell me I'm
doing something stupid, than let the users tell me via a bug report).
Anyway, enough language pedantry...
Sorry to drag the conversation back a couple of days, but can someone please
tell me what you would use an "eval" function for? What problem might you be
trying to solve that would be cumbersome in a language without an "eval"?
(It's not that I don't think it's useful, rather just that I can't think of
any uses for it.)
For example, Matt Hellige said the following, but I don't find it a
compelling example (and it doesn't look like something particularly
difficult in a statically-typed language):
-- snip --
Here's another big one: reflection and dynamic evaluation. Suppose I want to
read some expression from the user, evaluate it, store the result in a
variable, perhaps dynamically determine its type, and take some action.
This kind of thing is pretty difficult to accommodate with static
typing. Solutions I've seen (although I'm sure there are others) tend
to be of the type-case form, where even though some type verification
is done at run-time, it's done only when needed and the compiler can
still be sure that each branch of the type-case is safe. So something
like (pardon my pseudo-syntax):
(let ((result (eval-string some-string)))
(cond
((string? result) (treat-as-string result))
((integer? result) (treat-as-integer result))
(else (handle-failure))))
becomes something like:
type-case (eval-string some-string) of
x : String -> treat-as-string x
x : Integer -> treat-as-integer x
_ -> handle-failure
-- snip --
-----Original Message-----
From: Neel Krishnaswami [mailto:neelk@alum.mit.edu]
Sent: 23 May 2003 11:51
To: ll1-discuss@ai.mit.edu
Subject: Re: another take on hackers and painters
John Clements writes:
>
> Be careful. The distinction you're talking about is largely
> orthogonal to the dynamic vs. static typing issue. Case in point:
> Scheme is dynamically typed, but will not perform the coercion
> you're describing. At the opposite corner, there's no reason you
> can't have a statically typed language with coercion.
Haskell does this, and the way it does so is how I learned that
automatic coercions and overloading are the same thing. Numeric
literals like 123 aren't immediately interpreted as integers. Instead,
it gets the type 'Num a => a', which says that this expression is some
kind of number, and the specific kind it gets coerced to do depends on
the context in which it is used. So writing
let x :: Float = 3
won't cause a type error due to '3' being an integer and 'x' being a
float, like it would in ML. Haskell isn't as free-spirited with its
coercions as a language like Perl is, but that seems more a matter of
differing design sensibility rather than technical feasibility to me.
--
Neel Krishnaswami
neelk@alum.mit.edu
*****************************************************************
The information in this email and in any attachments is
confidential and intended solely for the attention and use
of the named addressee(s). This information may be
subject to legal professional or other privilege or may
otherwise be protected by work product immunity or other
legal rules. It must not be disclosed to any person without
our authority.
If you are not the intended recipient, or a person
responsible for delivering it to the intended recipient, you
are not authorised to and must not disclose, copy,
distribute, or retain this message or any part of it.
*****************************************************************