Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Understanding inheritance (Kyle Murphy)
2. Re: Understanding inheritance (Emanuel Koczwara)
3. Re: Overflow when reading C types (Patrick Redmond)
4. Re: Overflow when reading C types (Michael Orlitzky)
5. Re: Overflow when reading C types (Isaac Dupree)
6. Re: Overflow when reading C types (Daniel Fischer)
7. Re: Overflow when reading C types (Isaac Dupree)
----------------------------------------------------------------------
Message: 1
Date: Mon, 2 Dec 2013 09:21:02 -0500
From: Kyle Murphy <[email protected]>
To: beginners <[email protected]>
Subject: Re: [Haskell-beginners] Understanding inheritance
Message-ID:
<CA+y6JcwHh1kODy-5eti+4Ay+QTie2mi4eTug+hba8S5X=fy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I think you're headed down a path that's only going to cause you confusion.
You shouldn't think in OO terms like sub and super classes. Each class is
its own thing, they aren't sub and super classes in the OO sense. A class
my have a constraint applied to it such that any type that is an instance
of that class, must also be an instance of one or more other classes. That
constraint is what allows you to use functions that belong to other classes
inside of default function definitions. Semantically this behaves much like
inheritance in an OO language, however functionally it's very different.
On Dec 1, 2013 7:08 PM, "Patrick Browne" <[email protected]> wrote:
> Hi,
> In the example below does the concept of inheritance only apply to classes
> and not instances?
> By inheritance I mean that a method in a sub-class can use a method from
> the super-class but not vice versa.
> Would the inclusion of instance contexts such as 'instance (Eq a, Show b)
> => MyClass a b' apply such inheritance semantics between LHS => RHS of
> instances?
> My current misunderstandings are in the comments.
> Thanks,
> Pat
> -- Any instance of SUPER must define the super method. The super method
> definition may use any function in scope on the RHS of equations.
> -- If the default method is defined in the class it may use any method in
> scope except those from the sub-class
> class SUPER a where
> super :: a -> a
> -- Any instance of SUB must define sub. The sub method definition may use
> super or any function in scope on the RHS of equations
> class SUPER a => SUB a where
> sub :: a -> a
>
> -- This instance defines super and can use sub because sub it is defined
> and is in scope
> instance SUPER Int where
> super n = 1 + (sub n)
>
> -- This instance defines sub
> instance SUB Int where
> sub n = 6 + n
>
> -- The Char instances differs from the Int instances in that the SUB uses
> super.
> instance SUPER Char where
> super n = 's'
>
> -- The use of super here because it is defined and is in scope.
> instance SUB Char where
> sub n = super n
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20131202/7f70a701/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 02 Dec 2013 15:35:53 +0100
From: Emanuel Koczwara <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Understanding inheritance
Message-ID: <1385994953.13699.7.camel@emanuel-laptop>
Content-Type: text/plain; charset="UTF-8"
Hi,
From perspective of a haskell beginner coming from OOP:
Tt's like interfaces. If a class supports interface X, then it must
also supports interface Y. That's all. It's a simple thing, but can be
complicated if you will try to understand it in OOP terms.
Emanuel
------------------------------
Message: 3
Date: Tue, 3 Dec 2013 11:05:06 +1300
From: Patrick Redmond <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Overflow when reading C types
Message-ID:
<CAHUea4G86KXSGD-+Km_R+i2pdTkB0NFW=mfy8_6kzda8dwx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yeah, the unsigned is to demonstrate how "-10" is being interpreted as a
number before being cast to an unsigned.
My question is: Why isn't this just a read/parse error? "-10" isn't a valid
representation for any value of the CUInt type.
On Monday, December 2, 2013, wrote:
> On Mon, Dec 02, 2013 at 11:38:33AM +1300, [email protected]
> <javascript:;>wrote:
> > On Mon, Dec 02, 2013 at 11:30:50AM +1300, Patrick Redmond wrote:
> > > Prelude> import Foreign.C.Types
> > > Prelude Foreign.C.Types> read "-10" :: CUInt
> > > 4294967286
> > > Prelude Foreign.C.Types> read "300" :: CChar
> > > 44
> > >
> >
> > CUInt? I would try CInt instead.
> >
>
> Whoops, that is not related to the original question, sorry.
>
> _______________________________________________
> Beginners mailing list
> [email protected] <javascript:;>
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20131203/f63a68da/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 02 Dec 2013 17:09:22 -0500
From: Michael Orlitzky <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Overflow when reading C types
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/02/2013 05:05 PM, Patrick Redmond wrote:
> Yeah, the unsigned is to demonstrate how "-10" is being interpreted as a
> number before being cast to an unsigned.
>
> My question is: Why isn't this just a read/parse error? "-10" isn't a
> valid representation for any value of the CUInt type.
>
Sure it is,
unsigned int x = -10;
If you don't want a CUInt, don't use a CUInt =)
------------------------------
Message: 5
Date: Mon, 02 Dec 2013 18:14:20 -0500
From: Isaac Dupree <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Overflow when reading C types
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/02/2013 05:09 PM, Michael Orlitzky wrote:
> On 12/02/2013 05:05 PM, Patrick Redmond wrote:
>> Yeah, the unsigned is to demonstrate how "-10" is being interpreted as a
>> number before being cast to an unsigned.
>>
>> My question is: Why isn't this just a read/parse error? "-10" isn't a
>> valid representation for any value of the CUInt type.
>>
>
> Sure it is,
>
> unsigned int x = -10;
>
> If you don't want a CUInt, don't use a CUInt =)
That is a C integral->integral conversion. A better comparison for
Haskell "read", if you think C gets to define the Haskell conversion
from Haskell string to C integral type, would be strtol()/strtoul(),
which are standard C functions that convert from C string to C integral
type.
strtol() saturates at LONG_MIN and LONG_MAX.
strtoul() saturates at ULONG_MAX and is modulo at 0 (the first time; if
the number is too negative then it saturates to ULONG_MAX).
Both set errno to ERANGE when they saturate.
C conversions from floating-point to signed or unsigned integral also
saturate.
Unsigned types being Z/nZ is mathematically sound, but C is not very
dedicated to this interpretation. Furthermore, C signed arithmetic is
undefined behavior if you overflow. Haskell is much more dedicated to
thinking both signed and unsigned C types are modulo than C is.
I too am curious whether it would make more sense for Haskell
read/readsPrec to fail to read out-of-range integers.
-Isaac
------------------------------
Message: 6
Date: Tue, 03 Dec 2013 01:14:09 +0100
From: Daniel Fischer <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Overflow when reading C types
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
On Monday 02 December 2013, 18:14:20, Isaac Dupree wrote:
> C conversions from floating-point to signed or unsigned integral also
> saturate.
Not really. Clause 6.3.1.4 is quite explicit:
"When a finite value of real floating type is converted to an integer type
other than _Bool, the fractional part is discarded (i.e., the value is
truncated toward zero). If the value of the integral part cannot be
represented by the integer type, the behavior is undefined."
and adds a footnote to make it unmistakeably clear that the remaindering
operation need not be carried out when the target type is unsigned.
>
> Unsigned types being Z/nZ is mathematically sound, but C is not very
> dedicated to this interpretation.
It's mandated in 6.2.5 (9),
"A computation involving unsigned operands can never overflow, because a
result that cannot be represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the largest value that can
be represented by the resulting type."
> Furthermore, C signed arithmetic is undefined behavior if you overflow.
That cannot be stressed too much.
------------------------------
Message: 7
Date: Mon, 02 Dec 2013 21:40:01 -0500
From: Isaac Dupree <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] Overflow when reading C types
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/02/2013 07:14 PM, Daniel Fischer wrote:
> On Monday 02 December 2013, 18:14:20, Isaac Dupree wrote:
>> C conversions from floating-point to signed or unsigned integral also
>> saturate.
>
> Not really. Clause 6.3.1.4 is quite explicit:
>
> "When a finite value of real floating type is converted to an integer type
> other than _Bool, the fractional part is discarded (i.e., the value is
> truncated toward zero). If the value of the integral part cannot be
> represented by the integer type, the behavior is undefined."
>
> and adds a footnote to make it unmistakeably clear that the remaindering
> operation need not be carried out when the target type is unsigned.
Whoops! Thank you for correcting me.
>> Unsigned types being Z/nZ is mathematically sound, but C is not very
>> dedicated to this interpretation.
>
> It's mandated in 6.2.5 (9),
>
> "A computation involving unsigned operands can never overflow, because a
> result that cannot be represented by the resulting unsigned integer type is
> reduced modulo the number that is one greater than the largest value that can
> be represented by the resulting type."
Yes, indeed, C unsigned arithmetic *is* Z/nZ and that is lovely (when
you want it, at least).
My point there was that some functions/operations specified by the C
standard that are related to unsigned types, like conversion from
strings (strtoul()) and floats (casting), aren't modulo 2^n. I see
that's a weak point since each of those only differ from modulo in error
conditions (errno set, or undefined behaviour). If C was as good as(?)
Haskell it might use modulo for those conversions too.
-Isaac
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 66, Issue 4
****************************************
