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: Cross-platform .hs files on Linux and Windows (Vinay
Sajip)
2. Re: Seq question (Brent Yorgey)
3. Program reliability and multiple data constructors;
polymorphism (umptious)
4. Re: Training tasks (umptious)
5. Re: Program reliability and multiple data constructors;
polymorphism (Lyndon Maydwell)
6. Re: Program reliability and multiple data constructors;
polymorphism (umptious)
----------------------------------------------------------------------
Message: 1
Date: Wed, 18 Apr 2012 13:16:52 +0000 (UTC)
From: Vinay Sajip <[email protected]>
Subject: Re: [Haskell-beginners] Cross-platform .hs files on Linux
and
Windows
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Henk-Jan van Tuyl <hjgtuyl <at> chello.nl> writes:
> I've already tried that; if I use Notepad to convert the file to UTF-8,
> GHC does not accept the shebang.
I've raised an issue:
http://hackage.haskell.org/trac/ghc/ticket/6016
Thanks for your help with this.
Regards,
Vinay Sajip
------------------------------
Message: 2
Date: Wed, 18 Apr 2012 10:45:05 -0400
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] Seq question
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Tue, Apr 17, 2012 at 02:41:15PM -0700, Tim Perry wrote:
> seq evaluates to Weak Head Normal Form (WHNF). WHNF is the first
> contructor. So your use of seq only evaluates the first number and the
> cons. I.E., it evaluates to:
> s:(Thunk)
Actually, it doesn't even force the first number. You just get
Thunk : Thunk
-Brent
------------------------------
Message: 3
Date: Wed, 18 Apr 2012 16:10:32 +0100
From: umptious <[email protected]>
Subject: [Haskell-beginners] Program reliability and multiple data
constructors; polymorphism
To: [email protected]
Message-ID:
<CAE20bNsdndBr_DvU7Fps4=od+jt7ead_jratwmdm4pyuftp...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
One of the programming exercises I keep evolving as I learn Haskell is a
toy 2D shape editor with four primitives:
data Shape = Circle {origin::Pt2, radius::Float}
| Square {origin::Pt2, side ::Float}
| Rect {origin::Pt2, other ::Pt2}
| Composite {shapes::[Shape]}
deriving (Show, Read)
The intent is Composites can contain Shapes of any kind, including other
Composites so that you can apply transformations to a Composite and these
will be applied to the contained Shapes recursively. So an arm might
contain a hand which constains a dozen or so Rects. Transform the arm and
the hand and rects should transform; transform the hand and its rects
should transform but the not arm. Big deal.
And the above makes that really easy when you know you're talking to a
Composite. But now I've hit an intellectual stumbling point and the books
and source I have don't seem to address it: I can apply the destructuring
command "shapes" defined in the cstr "Composite" to ANY Shape. And if I do
that to say a circle, BLAM! Or if I apply "radius" to Rect, BLAM! At
runtime. No type checking support (because yes, they're the same type.)
To me this seems alarming. It means that I can't reason about the safety of
my program based on type checking as I'd like. And none of the answers I
can think seem at all elegant:
- I could use exception handling, but that means carefully checking which
data declarations are potential bombs and using exceptions only when they
are involved - hideously error prone - or using exceptions everywhere.
Which is just hideous.
- I could hack run time type checking using the ctsr info in "show". But
again I'd have to know when to use it or use it everywhere. And it seems
like a ridiculous kludge to bring to a language that has been designed for
elegance.
..So what is the Haskell idiom for dealing with this??? In fact I suppose
I'm asking two questions:
1. How do I re-design this program so it is safe (use class and instance
maybe, abandoning use of a single data type? but I then have to have
separate Lists for each type, even if they derived from a common class?)
2. How can one use compile time checking or (less good) coding practices to
eliminate the possibilty of such runtime exceptions?
And come to think of it
3. is there a Haskell book which addresses design and structural problems
like this one - which I would have thought was both obvious and fundamental
- because of the books I've looked at so far seem to do a tolerable job.
The best of them present an adequate "on rails" tour, but none of them seem
to give you the tools to address issues like this one. Whereas with C++and
Stroustrupp, Common Lisp and Graham, the Smalltalk book, and I Erlang and
Armstrong I'd know exactly what to do. Admittedly the C++ solutions
wouldn't be pretty, but anything the compiled would be safe to run (unless
I went to great efforts otherwise..)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120418/3b1499e8/attachment-0001.htm>
------------------------------
Message: 4
Date: Wed, 18 Apr 2012 16:17:39 +0100
From: umptious <[email protected]>
Subject: Re: [Haskell-beginners] Training tasks
To: Nikita Beloglazov <[email protected]>
Cc: [email protected]
Message-ID:
<cae20bnvpznvoao_wzlucwc5tsbh3rkaptyawqn+mv2yzq5i...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On 16 April 2012 17:46, Nikita Beloglazov <[email protected]> wrote:
> Hi.
> I'm building website where people can try and "taste" new languages by
> solving small or mediums size tasks. Tasks are language specific and should
> show best features of the language. Website is not meant to teach new
> language but to give idea what is this language good for.
> Now I want to add Haskell. I need about 7-10 tasks for now. First three of
> four tasks are introductory, they should show/check basics of haskell. E.g.
> given n, return sum of squares of first n even numbers. Other tasks are
> more complicated and show advantages of functional programming in general
> or some specific haskell features.
>
I'd say that's the wrong criteria for a set of tasks and solutions. A
better one would be to structure the list of tasks so that it teaches
people what they need to know to write a fair range of programs in Haskell.
This means working out what the main intellectual hurdles are in Haskell
and structuring problems around them. So some "koans" as well as pieces
designed to show "advantages",
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120418/2186cd8e/attachment-0001.htm>
------------------------------
Message: 5
Date: Thu, 19 Apr 2012 00:06:26 +0800
From: Lyndon Maydwell <[email protected]>
Subject: Re: [Haskell-beginners] Program reliability and multiple data
constructors; polymorphism
To: umptious <[email protected]>
Cc: [email protected]
Message-ID:
<cam5qztzt1rxpho_skjnlww9ea2cwzzglkhi9grsxqxrt0wd...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
There is some funkyness going on with records there.
You can sidestep the issue by giving each constructor its own type of
argument record:
type Pt2 = (Float, Float)
data Shape = Circle CircleData
| Square SquareData
| Rect RectData
| Composite CompData
deriving (Show, Read)
data CircleData = CircD {circleOrigin :: Pt2, radius :: Float}
deriving (Show, Read)
data SquareData = SquareD {squareOrigin :: Pt2, side :: Float}
deriving (Show, Read)
data RectData = RectD {bottomLeft :: Pt2, topRight :: Pt2}
deriving (Show, Read)
newtype CompData = CompD {shapes :: [Shape] }
deriving (Show, Read)
x = shapes $ RectD (0,0) (1,1) -- Throws an error on compile
I'm not sure what is going on in your example, but it seems like each
constructor adds its record argument's fields to a shared record type
or some such magic. Nasty.
On Wed, Apr 18, 2012 at 11:10 PM, umptious <[email protected]> wrote:
> One of the programming exercises I keep evolving as I learn Haskell is a toy
> 2D shape editor with four primitives:
>
> data Shape =?? Circle?? {origin::Pt2, radius::Float}
> ? ? ? ? ?? ??????????? | Square?? {origin::Pt2, side? ::Float}
> ?? ???????? ? ? ? ?? ? | Rect???? {origin::Pt2, other ::Pt2}
> ? ? ? ? ? ?? ????????? | Composite {shapes::[Shape]}
> ??????????? ? ? ? ? ?? ? deriving (Show, Read)
>
> The intent? is Composites can contain Shapes of any kind, including other
> Composites so that you can apply transformations to a Composite and these
> will be applied to the contained Shapes recursively. So an arm might contain
> a hand which constains a dozen or so Rects. Transform the arm and the hand
> and rects should transform; transform the hand and its rects should
> transform but the not arm. Big deal.
>
> And the above makes that really easy when you know you're talking to a
> Composite. But now I've hit an intellectual stumbling point and the books
> and source I have don't seem to address it:? I can apply the destructuring
> command "shapes" defined in the cstr "Composite" to ANY Shape. And if I do
> that to say a circle, BLAM! Or if I apply "radius" to Rect, BLAM! At
> runtime. No type checking support (because yes, they're the same type.)
>
> To me this seems alarming. It means that I can't reason about the safety of
> my program based on type checking as I'd like. And none of the answers I can
> think seem at all elegant:
>
> - I could use exception handling, but that means carefully checking which
> data declarations are potential bombs and using exceptions only when they
> are involved - hideously error prone - or using exceptions everywhere. Which
> is just hideous.
>
> - I could hack run time type checking using the ctsr info in "show". But
> again I'd have to know when to use it or use it everywhere. And it seems
> like a ridiculous kludge to bring to a language that has been designed for
> elegance.
>
> ..So what is the Haskell idiom for dealing with this??? In fact I suppose
> I'm asking two questions:
>
> 1. How do I re-design this program so it is safe (use class and instance
> maybe, abandoning use of a single data type? but I then have to have
> separate Lists for each type, even if they derived from a common class?)
>
> 2. How can one use compile time checking or (less good) coding practices to
> eliminate the possibilty of such runtime exceptions?
>
> And come to think of it
>
> 3. is there a Haskell book which addresses design and structural problems
> like this one - which I would have thought was both obvious and fundamental
> - because of the books I've looked at so far seem to do a tolerable job. The
> best of them present an adequate "on rails" tour, but none of them seem to
> give you the tools to address issues like this one. Whereas with C++and
> Stroustrupp, Common Lisp and Graham, the Smalltalk book, and I Erlang and
> Armstrong I'd know exactly what to do. Admittedly the C++ solutions wouldn't
> be pretty, but anything the compiled would be safe to run (unless I went to
> great efforts otherwise..)
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
------------------------------
Message: 6
Date: Wed, 18 Apr 2012 17:14:16 +0100
From: umptious <[email protected]>
Subject: Re: [Haskell-beginners] Program reliability and multiple data
constructors; polymorphism
To: [email protected]
Message-ID:
<cae20bnt0oten+4tptam+iluz5wrhxhm0_sw6fsblc04erwh...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Re. my previous post below, I'm guessing that the most elegant solution to
the problem of how to get the program to work is to hide all the cstrs and
only let access be through functions using record syntax like this Haskell
wiki example:
data Foo2 = Bar2 | Baz2 {barNumber::Int, barName::String}
--Using records allows doing matching and binding only for the variables
relevant to the function we're writing, making code much clearer:
h :: Foo2 -> Int
h Baz2 {barName=name} = length name
h Bar2 {} = 0
--Also, the {} pattern can be used for matching a constructor regardless of
the datatype elements even if you don't use records in the data declaration:
data Foo = Bar | Baz Int
g :: Foo -> Bool
g Bar {} = True
g Baz {} = False
main = do
print $ h a
print $ h b
where
a = Bar2
b = Baz2{barNumber=1, barName="fredikins"}
...Is this correct? And if so, is the answer to my second question "There's
no way of getting the compiler to guarantee runtime safety, so when you
have record syntax ctsrs for the same type which create objects with
different data, hide the ctsrs"?
On 18 April 2012 16:10, umptious <[email protected]> wrote:
> One of the programming exercises I keep evolving as I learn Haskell is a
> toy 2D shape editor with four primitives:
>
> data Shape = Circle {origin::Pt2, radius::Float}
> | Square {origin::Pt2, side ::Float}
> | Rect {origin::Pt2, other ::Pt2}
> | Composite {shapes::[Shape]}
> deriving (Show, Read)
>
> The intent is Composites can contain Shapes of any kind, including other
> Composites so that you can apply transformations to a Composite and these
> will be applied to the contained Shapes recursively. So an arm might
> contain a hand which constains a dozen or so Rects. Transform the arm and
> the hand and rects should transform; transform the hand and its rects
> should transform but the not arm. Big deal.
>
> And the above makes that really easy when you know you're talking to a
> Composite. But now I've hit an intellectual stumbling point and the books
> and source I have don't seem to address it: I can apply the destructuring
> command "shapes" defined in the cstr "Composite" to ANY Shape. And if I do
> that to say a circle, BLAM! Or if I apply "radius" to Rect, BLAM! At
> runtime. No type checking support (because yes, they're the same type.)
>
> To me this seems alarming. It means that I can't reason about the safety
> of my program based on type checking as I'd like. And none of the answers I
> can think seem at all elegant:
>
> - I could use exception handling, but that means carefully checking which
> data declarations are potential bombs and using exceptions only when they
> are involved - hideously error prone - or using exceptions everywhere.
> Which is just hideous.
>
> - I could hack run time type checking using the ctsr info in "show". But
> again I'd have to know when to use it or use it everywhere. And it seems
> like a ridiculous kludge to bring to a language that has been designed for
> elegance.
>
> ..So what is the Haskell idiom for dealing with this??? In fact I suppose
> I'm asking two questions:
>
> 1. How do I re-design this program so it is safe (use class and instance
> maybe, abandoning use of a single data type? but I then have to have
> separate Lists for each type, even if they derived from a common class?)
>
> 2. How can one use compile time checking or (less good) coding practices
> to eliminate the possibilty of such runtime exceptions?
>
> And come to think of it
>
> 3. is there a Haskell book which addresses design and structural problems
> like this one - which I would have thought was both obvious and fundamental
> - because of the books I've looked at so far seem to do a tolerable job.
> The best of them present an adequate "on rails" tour, but none of them seem
> to give you the tools to address issues like this one. Whereas with C++and
> Stroustrupp, Common Lisp and Graham, the Smalltalk book, and I Erlang and
> Armstrong I'd know exactly what to do. Admittedly the C++ solutions
> wouldn't be pretty, but anything the compiled would be safe to run (unless
> I went to great efforts otherwise..)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120418/0746ee9e/attachment.htm>
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 46, Issue 30
*****************************************
