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: splitWith and foldr stack overflow (Felipe Lessa)
2. Re: appropriateness of haskell for GUIs (Peter Verswyvelen)
3. Explicit specification of function types (Zachary Turner)
4. Re: Explicit specification of function types
(Brandon S. Allbery KF8NH)
5. Re: Explicit specification of function types (Zachary Turner)
----------------------------------------------------------------------
Message: 1
Date: Sun, 22 Mar 2009 14:02:18 -0300
From: Felipe Lessa <[email protected]>
Subject: Re: [Haskell-beginners] splitWith and foldr stack overflow
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Sun, Mar 22, 2009 at 12:26:35PM -0400, Sean Bartell wrote:
> splitWith p xs = let (ls, ts) = f xs in ts:ls
> where f [] = ([], [])
> f (x:xs) | p x = (ls, x:ts)
> | otherwise = (ts:ls, [])
> where (ls, ts) = f xs
>
> splitWith2 p xs = let (ls, ts) = foldr f ([],[]) xs in ts:ls
> where f x (ls, ts) | p x = (ls, x:ts)
> | otherwise = (ts:ls, [])
>
[snip]
> Don't they have the same recursive structure, though?
Err, no. In 'splitWith' you use 'where (ls, ts) = f xs', which means
that you are binding 'ls' and 'ts' lazily, while on 'splitWith2' you
use a pattern in the argument, which is strict. Being strict means
that you need to traverse the whole list in order to produce any
results. If you want to pattern match lazily, you just need to use an
irrefutable pattern, changing 'f x (ls, ts)' to 'f x ~(ls, ts)'.
And, just for the record, I'd prefer to write the function in
semi-pointfree style, as in
> splitWith3 p = uncurry (:) . foldr f ([],[])
> where f x ~(ts, ls) | p x = (x:ts, ls)
> | otherwise = ([], ts:ls)
HTH,
--
Felipe.
------------------------------
Message: 2
Date: Mon, 23 Mar 2009 18:15:22 +0100
From: Peter Verswyvelen <[email protected]>
Subject: Re: [Haskell-beginners] appropriateness of haskell for GUIs
To: Michael Mossey <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On Sat, Mar 21, 2009 at 1:30 PM, Michael Mossey <[email protected]>wrote:
> I can imagine that GUI programming is no easier (yet). It is inherently
> very "stateful." GUI's have modes, such as which screens are displayed,
> which dialogs are displayed, which options within those dialogs are valid
> given the other state of the program, etc. When I write GUIs, I often
> diagram them as state machines to get a handle on what's going on.
So, I'm not familiar with GUI programming on Haskell, but would you say the
> statefulness of GUIs (in their typical implementations) is the reason they
> are no easier on Haskell?
Even if you want to see GUIs as state machines, it is perfectly possible to
make pure stateful GUIs in Haskell without using IO.
I guess the problem is that a purely functional GUI library - be it stateful
or continuous- is only useful if it comes with lots of GUI controls, and
writing all these controls is a big task. It is much easier to wrap an
existing C toolkit to get the job done, even if it means making your hands
dirty :-) Furthermore modern GUI toolkits like perform real time animation,
styling, data binding, layout, etc... so this is a huge undertaking.
That being said, I think many many Haskellers really would love to use a
purely functional GUI toolkit, but unfortunately, a production quality
toolkit does not exist yet. I guess building all controls needed for a GUI
library could be a global community effort if we all agreed on a good FRP
(=functional reactive programming) library to build the GUI on, but
currently no clear winner exists.
I strongly prefer to use qtHaskell because I'm familiar with Qt, and Qt is
> extremely capable. For example, it can draw text and shapes with
> antialiasing, which will be great for a music score editor. Music scores
> have lots of small shapes to fit on the screen, and antialiasing will
> provide ease of reading. I don't know how much of Qt is implemented in
> qtHaskell, or whether the latest version of Qt (4.4) is implemented.
Cairo - part of GTK - can also do that, but I expect it to be slower than Qt
(at least on Windows)
My personal opinion: GUIs don't really "work" either in imperative or
functional programming. But we can make it work in the imperative world
because we can hack around the problems.
Thanks,
> Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090323/b44d5678/attachment-0001.htm
------------------------------
Message: 3
Date: Mon, 23 Mar 2009 21:02:56 -0500
From: Zachary Turner <[email protected]>
Subject: [Haskell-beginners] Explicit specification of function types
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Everything I've read has said that it's generally considered good practice
to specify the full type of a function before the definition. Why is this?
It almost seems to go against the principles of type inference. Why let the
compiler infer types if you're just going to tell it what types to use for
everything? Ok well, not really for everything, you don't typically specify
types for local bindings, but still why the inconsistency? I have a little
experience with ML and F# and there you're encouraged to -not- specify types
explicitly, and let the compiler infer them for you. In fact, it seems like
it would be fairly common where you specify a type that is -less- general
than the type that the compiler would infer for you, because the most
general type might involve a combination of type classes used in various
ways, and it may not always be obvious to the programmer how to specify it
correctly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090323/e6ffd34e/attachment-0001.htm
------------------------------
Message: 4
Date: Mon, 23 Mar 2009 22:51:25 -0400
From: "Brandon S. Allbery KF8NH" <[email protected]>
Subject: Re: [Haskell-beginners] Explicit specification of function
types
To: Zachary Turner <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Skipped content of type multipart/alternative-------------- next part
--------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url :
http://www.haskell.org/pipermail/beginners/attachments/20090323/ede07718/PGP-0001.bin
------------------------------
Message: 5
Date: Mon, 23 Mar 2009 22:02:01 -0500
From: Zachary Turner <[email protected]>
Subject: Re: [Haskell-beginners] Explicit specification of function
types
To: "Brandon S. Allbery KF8NH" <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On Mon, Mar 23, 2009 at 9:51 PM, Brandon S. Allbery KF8NH <
[email protected]> wrote:
> On 2009 Mar 23, at 22:02, Zachary Turner wrote:
>
> Everything I've read has said that it's generally considered good practice
> to specify the full type of a function before the definition. Why is this?
> It almost seems to go against the principles of type inference. Why let the
> compiler infer types if you're just going to tell it what types to use for
> everything? Ok well, not really for everything, you don't typically specify
>
>
>
> 1. Specifying the type of a top level binding avoids the monomorphism
> restriction.
>
> 2. Type inference is nice right up until you have to debug a type error;
> then the error gets reported at the point where the compiler realizes it
> can't match up the types, which could be somewhere not obviously related
> (depends on what the call chain looks like). The more concrete types you
> give the compiler, the better (both more complete and more correctly
> located) the type errors will be.
>
Regarding the second issue, this occurs in most other type inferring
languages as well, but usually you just specify types up until such time
that your function is fully tested and you deem that it's good, then
removing the type specification. Or, when you get strange type errors,
binding a few relevant values to the types you expect, and then the type
errors become clearer. Then once you fix them you can remove the type
annotations again.
Regarding the first issue, I haven't gotten deep enough into Haskell yet to
fully appreciate the monomorphism restriction, although I've run into it
once I believe. So I'll probably appreciate that aspect of it more later.
That being said, is it as common as I expect it would be that the progarmmer
unknowingly specifies a type that is not the most general type possible? I
would think this would be "bad", although not the end of the world or
anything it would still be desirable to be as generic as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090323/d47be13b/attachment.htm
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 9, Issue 27
****************************************
