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: Program reliability and multiple data constructors;
polymorphism (umptious)
2. Re: Program reliability and multiple data constructors;
polymorphism (Markus L?ll)
3. Re: Program reliability and multiple data constructors;
polymorphism (Antoine Latter)
4. Re: Looking for vim text obejct plugin (John Tyree)
5. Re: Program reliability and multiple data constructors;
polymorphism (Stephen Tetley)
6. Re: Training tasks (Tom Murphy)
7. Re: Program reliability and multiple data constructors;
polymorphism (Stephen Tetley)
----------------------------------------------------------------------
Message: 1
Date: Wed, 18 Apr 2012 17:50:04 +0100
From: umptious <[email protected]>
Subject: Re: [Haskell-beginners] Program reliability and multiple data
constructors; polymorphism
To: [email protected]
Message-ID:
<CAE20bNur1ETRHC-uu+mXKxxGnNzUE7p1QvH8zbN5h=5ddhn...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
And in partially answering my own question I forgot to add that this gives
you a less queasy-making way of identifying the cstr used to create a
structure:
--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
>
Regarding my comments on the lack of good Haskell books, I just checked
LYAHFAGG and RWH and neither of them covered either the problem, or the two
mechanisms used for a solution. This is very poor, given that the problem
is such an obvious one and the solutions are such general mechanisms. I'm
pretty sure that Hutton doesn't cover this either - in fact "record syntax"
isn't even in the index.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120418/cad71a0d/attachment-0001.htm>
------------------------------
Message: 2
Date: Wed, 18 Apr 2012 19:51:45 +0300
From: Markus L?ll <[email protected]>
Subject: Re: [Haskell-beginners] Program reliability and multiple data
constructors; polymorphism
To: umptious <[email protected]>, [email protected]
Message-ID:
<caldaiucfi8uovstnmd6vozfve06q4gl_vd00tdt_uaudzju...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
If you want type safety, then use different types (data Circle, data
Rectangle, ..) and implement the properties you want via classes, i.e
'class HasRadius a', 'class HasSomethingElse a' and some such. Right
now you only have one type, and wanting it to be type safe at that is,
khm ..impossible.
In general, for all of what you program you should have some specific
goal in mind, a concrete outcome. For the radius problem the solution
could also be (instead of having it as a class) of giving it the type
of 'Shape -> Maybe Float' and have it return 'Nothing' when radius
isn't applicable. When you just tinker away and try to solve all of 2D
geometry with it, or any part of it at random, usually leads to
nowhere (for me at least).
Edit:
Just noticed the subject which says "polymorphism" at the end.
In Haskell you can have structural polymorphism, like 'data X a = X a'
where 'X a' is polymorphic at 'a' -- you can have any type at the
place of 'a'. Or or ad hoc polymorphism -- the thing that classes do.
The Shape data type in the initial post is monomorphic and recursive.
On Wed, Apr 18, 2012 at 7:14 PM, umptious <[email protected]> wrote:
> 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..)
>>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
--
Markus L?ll
------------------------------
Message: 3
Date: Wed, 18 Apr 2012 11:52:46 -0500
From: Antoine Latter <[email protected]>
Subject: Re: [Haskell-beginners] Program reliability and multiple data
constructors; polymorphism
To: umptious <[email protected]>
Cc: [email protected]
Message-ID:
<cakjsnqgudy+1twafspmyw8z-8u1llhlu9kp4tx2rkppbrr3...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Wed, Apr 18, 2012 at 10:10 AM, 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.
>
>
> ..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?
>
I think the usual answer is to use pattern matching. As in:
myFunc :: Sahpe -> Foo
myFunc (Composite xs) = ...
myFunc (Circle o r) = ...
etc.
Does this do what you want?
Antoine
------------------------------
Message: 4
Date: Wed, 18 Apr 2012 19:35:40 +0200
From: John Tyree <[email protected]>
Subject: Re: [Haskell-beginners] Looking for vim text obejct plugin
To: [email protected]
Message-ID:
<cacqtjgx77kwjexbrzxvtussslqhfucdqf0liwyf7zzqviv_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
There are some decent object plugins on github. Look at vim-textobj-user
for the parent plugin and then vim-textobj-indent for some useful ones
based on indent level. I don't think there's anything that can handle
haskell style arguments... although I think they are always either single
identifiers or something wrapped in parens, so yiw and yib should handle it
usually.
-John
------------------------------
Message: 6
Date: Wed, 18 Apr 2012 13:23:00 +0900
From: Mait <[email protected]>
Subject: [Haskell-beginners] Looking for vim text obejct plugin for
haskell.
To: [email protected]
Message-ID:
<cabqgwkxyhdad4_btef10n9nfswxbo9ekb-yom3jfmp0crtf...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Any good one there everybody knows except me? :)
--
Mait
------------------------------
Message: 7
Date: Wed, 18 Apr 2012 13:34:20 +0900
From: Mait <[email protected]>
Subject: Re: [Haskell-beginners] Looking for vim text obejct plugin
for haskell.
To: [email protected]
Message-ID:
<CABQgwkWcfa9mL3fSb7RkTuRG8OXhjG3q2Qke=yvp9zozoo+...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Especially looking for 'argument' object plugin.
function x:xs
^ <- cursor
ysaa) or ysia)
-> function (x:xs)
2012/4/18 Mait <[email protected]>:
> Any good one there everybody knows except me? :)
>
> --
> Mait
--
Mait
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20120418/62b7a61c/attachment-0001.htm>
------------------------------
Message: 5
Date: Wed, 18 Apr 2012 18:41:02 +0100
From: Stephen Tetley <[email protected]>
Subject: Re: [Haskell-beginners] Program reliability and multiple data
constructors; polymorphism
To: umptious <[email protected]>
Cc: [email protected]
Message-ID:
<cab2tprdm4sghw3gvtqommbfxrnlf5vr7744hhl_pv9tc2mn...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Idiomatic Haskell for *drawing* shapes is to represent Shapes as
functions from their origin to what they draw (e.g. Bitmap).
type Drawing = Pt2 -> Bitmap
-- Circle needs a radius
type Circle = Float -> Drawing
circle :: Circle
circle r = \pt -> {...}
-- Rect needs width and height
type Rect = Float -> Float -> Drawing
rect :: Rect
rect w h = \pt -> {...}
Transformations like scaling work by pre-transforming the arguments
uniform_scale_rect :: Float -> Rect
uniform_scale_rect sz = \w h -> rect (sz*w) (sz*h)
uniform_scale_scale :: Float -> Circle
uniform_scale_scale sz = \r -> cicle (sz*r)
If you want a polymorphic scale function you will have to make your
shapes individual newtypes so us can write specific instances for
them.
This works very well for drawing, but because Shapes are represented
as functions they cannot support introspection e.g. querying a circle
for its radius. Depending how you design your editor you might find
introspection wasn't a genuine requirement.
------------------------------
Message: 6
Date: Wed, 18 Apr 2012 13:44:32 -0400
From: Tom Murphy <[email protected]>
Subject: Re: [Haskell-beginners] Training tasks
To: umptious <[email protected]>
Cc: [email protected], Nikita Beloglazov <[email protected]>
Message-ID:
<cao9q0tu7lskit7x1vhtv5d0dbp_zc0sbbaojetea9ogbc_4...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I think that the idea is less to have a teaching tool, and more
to have a way to "shop around" for languages, by seeing what each
language is very good at.
Tom
On 4/18/12, umptious <[email protected]> wrote:
> 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",
>
------------------------------
Message: 7
Date: Wed, 18 Apr 2012 18:51:48 +0100
From: Stephen Tetley <[email protected]>
Subject: Re: [Haskell-beginners] Program reliability and multiple data
constructors; polymorphism
To: umptious <[email protected]>
Cc: [email protected]
Message-ID:
<CAB2TPRCeyGyQJPPPeNQxrV8Ga2UeGTyyg2hi=vo2p-_moe6...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Further to my last point - introspection is "controversial" for Shapes
if you have a concrete representation anyway:
If you want to make an ellipse you can non-uniformly scale a
circle[*], but if you only have a query for radius you can't do edge
detection on an ellipse; you might end up needing to store radius plus
a list of all the affine transformations you have applied.
[*] There is also the problem that a circle isn't a circle once it has
been non-uniformly scaled...
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 46, Issue 31
*****************************************
