Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups: comp.programming
Subject: Re: Here is why C++ and C are bad...
Date: Wed, 30 Dec 2015 22:00:29 +0000
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <87a8or61he.fsf@bsb.me.uk>
References: <n5kdn4$cji$1@dont-email.me> <n5uqdd$gin$1@dont-email.me> <n5v0di$7i3$1@dont-email.me> <n5v0p5$8s3$1@dont-email.me> <n6063m$ccb$1@dont-email.me> <n60m14$lf$1@dont-email.me> <87h9j06ip1.fsf@bsb.me.uk> <n610v9$afu$1@dont-email.me> <87wprv679l.fsf@bsb.me.uk> <n61ds0$sn0$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="017616aa25f81ec581c44d76d61ba2f3"; logging-data="20226"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19XMG1qy/UdDejHWFhcPZZDlVEe375o6Rc="
Cancel-Lock: sha1:Xvyx26/bzU0m41K4W0SeQiCHyr0= sha1:VTjUNrW9z5ZurwKv64mp8HxyF8M=
X-BSB-Auth: 1.242f5cd39f65989422f5.20151230220029GMT.87a8or61he.fsf@bsb.me.uk
Xref: csiph.com comp.programming:6120

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 30/12/15 19:55, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
>>> I ran out of time to extend this alphabetical list any further,
>>
>> And just before my favourite -- Haskell.
>
> Yep, I was going to choose Haskell. But since it's your favourite, how
> does Haskell deal with signedness/unsignedness?

Haskell has no unsigned types in the core language, so in the normal
course of programming the question does not come up.

But some unsigned, fixed-width integer types have been added to the
standard library.  These use modular arithmetic and are probably there
for compatibility with other languages (I've never used them and I'm not
sure what they are for).

Fundamentally, mixed-type arithmetic is a type error in Haskell because
all Haskell arithmetic functions require the arguments to be of the same
type.  But it's not quite that simple, because Haskell can infer the
types of functions (like + and <) from the types of the arguments, and
it uses a system of type classes (whether a type is ordered, or numeric,
or bounded and so on) to determine what you can do with them.  As a
result, the behaviour depends on how the unsigned types are implemented.

The upshot is that, for the now standard type Data.Word, you can get
this situation which looks similar to C (this is an interactive ghci
session):

  Prelude Data.Word> let i = -6; j = 42::Word
  Prelude Data.Word> i < j
  False

This is because all Haskell knows about i is that it is numeric:

  Prelude Data.Word> :t i
  i :: Num a => a

If we are explicit about the types, you get a type error:

  Prelude Data.Word> let i = -6::Integer; j = 42::Word
  Prelude Data.Word> i < j
   
  <interactive>:6:5:
      Couldn't match expected type ‘Integer’ with actual type ‘Word’
      In the second argument of ‘(<)’, namely ‘j’
      In the expression: i < j

-- 
Ben.