Re: [Haskell-cafe] Re: Using haskell with emacs
I don't know enough about the details to know if :l and :r do exactly the same things in ghci. SM I don't either. But experimentation suggests that the only SM difference is that :r doesn't need an argument (which in the case SM of haskell-mode doesn't make any difference since the arg is SM provided by haskell-mode anyway). But sometimes it's not the right argument if you have several haskell source files opened. I don't find C-c C-r to be of much use, but it's useful sometimes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language support for imperative code. Was: Re: monad subexpressions
Brian Hulley wrote: Haskell is designed so that any attempt at abstracting mutable local state will infect the entire program (modulo use of a highly dangerous function whose semantics is entirely unclear, depending on the vagaries of evaluation strategy of the particular compiler) (Your email message is long and very interesting, and it does an a considerable injustice to take one sentence out of context, but...) This echoes a misconception that I see here on haskell-cafe quite often. Mutable local state *really* doesn't need to infect the whole program, and haskell is certainly not designed so it must. We have all kinds of techniques for ensuring that the pure parts of your code can remain pure, and only the impure parts get 'infected' with an IO signature. Additionally, if it's just refs, you can use ST, which is totally pure. If it's literally just state, you can use the techniques of the State monad and the Reader monad: but you don't necessarily have to use them explicitly with those names. Sometimes it is actually simpler just to use the types s - (a,s) and s - a directly; only in certain circumstances is the extra plumbing useful. Often different parts of your program have different needs; some parts actually need the ability to make fresh names (and so need STRefs) other parts merely read the state (and can use Reader techniques) and other parts alter it (and can use State techniques). You need some plumbing to connect the different parts together, but fortunately haskell has powerful abstraction and it's quite easy to slap together the higher-order functions (combinators!) to do this. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] How odd...
Indeed! Getting the library numerics to do the Right Thing is something that can only be done by people who know about numerics. People who build compilers aren't, alas. It's quite a specialised subject, and very easy to screw up. And there's performance to worry about too in the common case when the corner cases don't appear. So if there are folk out there who care about getting numerics correct, we would welcome your direct involvement. Look at the code, make it right, send patches to [EMAIL PROTECTED]mailto:[EMAIL PROTECTED]. It's all open source, and you'll be benefiting lots of people. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lennart Augustsson Sent: 04 August 2007 16:47 To: Andrew Coppin Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] How odd... Haskell doesn't know much about infinity, but Haskell implementations are allowed to use IEEE floating point which has infinity. And to get things right, there needs to be a few changes to the library to do the right thing for certain numbers, this is not news. In fact I filed a bug report a while back about it. -- Lennart On 8/4/07, Andrew Coppin [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Paul Johnson wrote: Andrew Coppin wrote: 0**2 0 (0 :+ 0)**2 NaN :+ NaN (Is this a bug?) According to the Standard Prelude, # x ** y = exp (log x * y) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Pure functional GUI (was a regressive view of support for imperativeprogramming in Haskell)
LOL. Yeah you are correct I guess. Oh well ;-) -Original Message- From: Bulat Ziganshin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 7:30 AM To: Peter Verswyvelen Cc: Donn Cave; haskell-cafe@haskell.org Subject: Re[2]: [Haskell-cafe] Pure functional GUI (was a regressive view of support for imperativeprogramming in Haskell) Hello Peter, Wednesday, August 8, 2007, 11:14:37 PM, you wrote: To me, having an imperative background, a graphical application is just a big tree of data that evolves when events from the OS come in. (this data is NOT per se the data for the GUI element; instead use the model-view-controller design pattern) In Haskell, instead of mutating the data (as done in C/C++), a infinite stream of this tree-data is generated responding to an infinite steam of events, as in Paul's SOE book (the reactive stuff). Since most of the data can be shared, the performance impact should be minimal. So could you please tell me more about the problem with pure functional GUIs seems that such program will have no effects :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI (was
On Thu, 2007-08-09 at 08:59 +0800, Hugh Perkins wrote: To be fair, GTK is pretty standard. This is so even for big name gc'd imperative languages such as C#. Sure, you can use Windows.Forms in C#, but you often wouldnt, because of the patent burden. Also, gtk in partnership with glade rocks! How easy is gtk to use from haskell by the way? In gc'd imperative languages, typically only one thread is allowed to communicate with the GUI, and you need to set up a whole bunch of message-parsing stuff to communicate with other threads. To what extent is this easier in Haskell? The story on this isn't as nice as it could be. It depends on which GHC runtime system you choose to use. In the single threaded rts, you can use threads willy nilly as they all run in the context of one OS thread (though it requires a little bit of code to set up cooperative scheduling). In the fully threaded rts you have to be very careful to only use GUI stuff from a single OS thread. Gtk2Hs provides a couple functions to post actions to the main GUI thread. We've been thinking of ways to make this more transparent but it's not so easy. Other question on using gtk from haskell: how easy is it to integrate with glade? ie, can we directly bind glade form elements to haskell variables? How easy is it to bind events to glade form elements from within Haskell? It's pretty easy, see the Gtk2Hs/Glade tutorial: http://haskell.org/gtk2hs/docs/tutorial/glade/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Slow IO or bad code?
Hi
I am practicing writing code in haskell, by solving problems at this
site. http://spoj.pl.
The problem http://spoj.pl/problems/FASHION , is pretty simple.
1. Given two lists A,B , of N numbers, sort them and take sum of products.
i.e. Sum ai * bi
I wrote a code, but seems to give Time limit exceeded!
Beginning of CODE
loop t function
| t == 1 = do function
| otherwise = do { function; loop (t - 1) function }
prod [] [] = 0
prod (a:as) (b:bs) = a*b + prod as bs
to_int :: [String] - [Integer]
to_int [] = []
to_int (x:xs) = (read x) : to_int xs
doit = do
n - getLine
a - getLine
b - getLine
let la = to_int (words a);
lb = to_int (words b); in
print (prod la lb)
main = do
t - getLine
loop (read t) doit
END OF CODE
I would love to see if there is any improvement that can be done, to
the code ...
Thanks!
Vimal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow IO or bad code?
j.vimal: Hi I am practicing writing code in haskell, by solving problems at this site. http://spoj.pl. The problem http://spoj.pl/problems/FASHION , is pretty simple. 1. Given two lists A,B , of N numbers, sort them and take sum of products. i.e. Sum ai * bi I wrote a code, but seems to give Time limit exceeded! We have a page for these SPOJ problems: http://haskell.org/haskellwiki/SPOJ#Techniques_for_dealing_with_problems_efficiently With bytestring IO, you can aim to be around the speed of OCaml or C++, according to the existing bytestring entries. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow IO or bad code?
* Vimal wrote:
Beginning of CODE
loop t function
| t == 1 = do function
| otherwise = do { function; loop (t - 1) function }
prod [] [] = 0
prod (a:as) (b:bs) = a*b + prod as bs
prod = sum . zipWith (*)
to_int :: [String] - [Integer]
to_int [] = []
to_int (x:xs) = (read x) : to_int xs
This is the slow part. Prelude.read ist really slow.
Futhermore use the recusion pattern again:
to_int = map read
doit = do
n - getLine
a - getLine
b - getLine
let la = to_int (words a);
lb = to_int (words b); in
print (prod la lb)
What is n used for?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a regressive view of support for imperative programming in Haskell
David Roundy wrote: On Wed, Aug 08, 2007 at 02:20:39PM -0400, Paul Hudak wrote: As long as the sugar has a pretty obvious desugaring (which I seem to recall it did), I don't see how it's likely to make things worse. And Some people are arguing that the desugaring isn't obvious. Although I like the proposal to start with, I am beginning to be convinced by those arguments. For example: do foo x can be simplified to foo x under the new proposals do x - bar y foo x would shorten to do foo (- bar y) and now you really really want to remove the do, to get simply foo (- bar y) but that would be illegal. The new sugar is going to remove all kinds of substitution and simplification lemmas that we have got used to. There is also the fact that if : foo x = bar x x then you call foo monadically as in do foo (- baz) You can no longer replace foo with its definition, because if replace that with do bar (- baz) (- baz) ...that means something rather different :( A third example is with nested dos: do x - bar y baz something $ do foo x is not the same as do baz something $ do foo (- bar y) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a regressive view of support for imperative programming in Haskell
For what it's worth from a Haskell newbie (and from someone who's been doing FP since November, mainly in Scala.) I really like Haskell's purity and having the clear separation between zero side effects and monads is most excellent. It was quite a brain change to program functionally. It took a lot of work and a lot of discipline. In Scala, I set myself the goal of not having any variables (except as instance variables of a very limited number of classes... Scala doesn't support monads), but to only use single-assignment values. At first, it was really hard to think in a new way. Now, I find that, even when I write Java code, I write in a functional style. The benefit for me is reducing the number of moving parts as well as forcing me to do significantly more design work up front. Now, the OO ideal was to model ones class hierarchy and the messages and the code will all flow automagically. In my 17 years, dozens of commercial applications, and 1M+ LoC of OO programming, it's never worked that way for me. On the other hand, programming in a state-minimized (or state-free) way makes me work a lot more to define my types and how the types interact with each other. I find that I'm spending a lot more time up front piecing the types together. I am spending no time worrying about hidden state (gee, if I call X before I call Y, the state will not be set up, so I have to shoe-horn some sort of test to make sure that the state is set up correctly.) I also find that my code is shorter and less dense at the same time. The what part of my code is easier to see because filter/map/zip constructs are a lot less distracting than new array/for/if/... constructs. The proof is in the output for me. My web framework (http://liftweb.net) and the commercial product that my team is building with Scala ( http://www.circleshare.com) have been remarkably stable and low in bugs. And the bugs have by and large been logic bugs rather than changing X which caused a bug in Z because the state was wrong bugs. The code bases are large enough, that I'd normally be expecting to see breakage from unexpected side effects from code changes. That hasn't started happening. Part of the challenge that Haskell and Scala and the other FP languages face is the pain developers face as they change the way they approach and solve problems. Based on my 28 years of professional coding, I think that FP is the single best and single most important technology that I've invested my time in. I think that Haskell's brand of purity is hyper-important and will allow for assembly of significantly more complex systems than will any other technology that I've seen. Please, keep to the vision. The vision is powerful, inspiring, and I believe correct. Thanks, David On 8/8/07, Paul Hudak [EMAIL PROTECTED] wrote: All of the recent talk of support for imperative programming in Haskell makes me really nervous. To be honest, I've always been a bit uncomfortable even with monad syntax. Instead of: do x - cmd1 y - cmd2 ... return e I was always perfectly happy with: cmd1 = \x- cmd2 = \y- ... return e Functions are in my comfort zone; syntax that hides them takes me out of my comfort zone. In my opinion one of the key principles in the design of Haskell has been the insistence on purity. It is arguably what led the Haskell designers to discover the monadic solution to IO, and is more generally what inspired many researchers to discover purely functional solutions to many seemingly imperative problems. With references and mutable data structures and IO and who-knows-what-else to support the Imperative Way, this discovery process becomes stunted. Well, you could argue, monad syntax is what really made Haskell become more accepted by the masses, and you may be right (although perhaps Simon's extraordinary performance at OSCOM is more of what we need). On the other hand, if we give imperative programmers the tools to do all the things they are used to doing in C++, then we will be depriving them of the joys of programming in the Functional Way. How many times have we seen responses to newbie posts along the lines of, That's how you'd do it in C++, but in Haskell here's a better way I hope I don't start a flame war with this post -- I'm just expressing my opinion, which admittedly is probably regressive rather than progressive :-). -Paul -- Professor Paul Hudak Department of Computer ScienceOffice: (203) 432-1235 Yale University FAX:(203) 432-0593 P.O. Box 208285 email: [EMAIL PROTECTED] New Haven, CT 06520-8285 WWW:www.cs.yale.edu/~hudak http://www.cs.yale.edu/%7Ehudak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- lift, the fast, powerful, easy web framework http://liftweb.net
Re: [Haskell-cafe] Slow IO or bad code?
@Donald: Thanks for the link. prod = sum . zipWith (*) This is the slow part. Prelude.read ist really slow. Futhermore use the recusion pattern again: to_int = map read What is n used for? @Lutz: Those are some nice tricks... Thanks! Now, the 'n' is for getting the number of numbers in the list. Which I don't need, since I had a way around it. I just had to skip that line... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow IO or bad code?
I wrote a code, but seems to give Time limit exceeded! ?? Your code writes 15 to stdout which is correct (with the example given on the page).. You have to explain what you mean by seems to give Time limit exceeded loop t function Does already exist. sequence $ replicate 10 function is a much shorter way :-) oor perhaps mapM_ [ function | i - [1..10] ] ) prod, to_int: You can both implement using higher order functions prod = sum . zipWith (*) to_int = map read Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] New Eq instance
Hello, I had defined the follwing data type: data Step = Step Id Scenario Action State Response How can I define Step as an Eq Instance, in such way that two steps are equals if they have the same Id (Id is defined as a synonimous for the String type). I tried the following code, but something is wrong instance Eq Step where Step id1 scenario1 action1 state1 response1 == Step id2 scenario2 action2 state2 response2 = id == id _ == _ = False ps.: sorry, this kind of basic question can be sent to this list? Thanks in advance. Rodrigo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Eq instance
rodrigo.bonifacio wrote: instance Eq Step where Step id1 scenario1 action1 state1 response1 == Step id2 scenario2 action2 state2 response2 = id == id _ == _ = False Almost. You just used 'id' and 'id' when you meant 'id1' and 'id2'. instance Eq Step where Step id1 scenario1 action1 state1 response1 == Step id2 scenario2 action2 state2 response2 = id1 == id2 but it's a common idiom not to bother to name unused parameters, so: instance Eq Step where Step id1 _ _ _ _ == Step id2 _ _ _ _ = id1 == id2 (and the default case is never reached so you don't need it) ps.: sorry, this kind of basic question can be sent to this list? Yes, that's fine. You may get quicker answers if you hop onto IRC at #haskell, though. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow IO or bad code?
On 8/9/07, Marc Weber [EMAIL PROTECTED] wrote: I wrote a code, but seems to give Time limit exceeded! ?? Your code writes 15 to stdout which is correct (with the example given on the page).. You have to explain what you mean by seems to give Time limit exceeded I think Vimal is referring to a message from SPOJ rather than the compiler. I.e. the program runs too slowly so it is rejected by the judging software. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Derivation of Eq given Ord
Dougal Stanton, Thu, 9 Aug 2007 16:57:26 +0100:
Is there a reason why automatic derivation of Ord without Eq doesn't
do the sensible thing and just derive Eq anyway?
newtype Id a = Id { a :: String }
deriving (Read, Show, Eq, Ord)
newtype Ego a = Ego { b :: String }
deriving (Read, Show, Ord)
Both will type check, but if you try any (in)equality operators on the
second they'll be spat back at you.
According to the output of ghci's info command, deriving Ord without
deriving Eq is equivalent to
instance Eq Ego = Eq Ord where ...
That is, if there's an Eq instance declaration for Ego, then Ego will be
an instance of Ord, too. This may come in handy if you want to declare
the Eq instance yourself, possibly even in another module. The
compiler cannot know about instances you're up to declare in other
places, so it would probably not be convenient for the compiler to
derive Eq behind the scenes.
It doesn't seem *much* of a hardship, but it wasn't what I expected.
I'm not used to GHC accepting input and silently dropping stuff it
doesn't like...
Well, obviously, you will still get a type error when trying to use the
instance without an Eq instance declaration, so it is not really a
matter of “silently dropping stuff”, I suppose.
Malte
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] how can I get template haskell macro-expanded code from inferStartState? (repeated post, now with subject)
(sorry, forgot the subject on my first post)
In the following code which uses template haskell, how can I get back the
macro-expanded code generated from
$(inferStartState ''MyState)
I *can* recover the macro-expanded code for
$(cnst 1 x)
using a debugging technique bulat describes on his tutorial at
http://www.haskell.org/bz/th3.htm
You can see what's going on in the function debugTemplates below.
I'm trying to do this actually, to better understand how HAppS deals with
state. It's a bit opaque now since the example on the tutorial uses TH. I
think I would understand it better if I had code that didn't depend on TH.
(MyState is from the happs tutorial at
http://www.haskell.org/haskellwiki/HAppS_tutorial )
thanks!
thomas.
{-# OPTIONS -fglasgow-exts -fth #-}
module MyState where
import HAppS
import HAppS.Protocols.SimpleHTTP2
import Data.Monoid
import Data.Typeable
import Control.Monad.State (get, put)
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
data MyState = MySt { appVal :: Int } deriving (Read, Show, Typeable)
instance Serialize MyState where
encodeStringM = defaultEncodeStringM
decodeStringM = defaultDecodeStringM
instance Monoid MyState where
mempty = MySt 0
mappend (MySt x) (MySt y) = MySt (x+y)
-- in ghci... -fth, :m +
-- ghci... :t (inferStartState ''MyState) :: (Quasi m) = m [Dec]
$(inferStartState ''MyState) -- boilerplate that will eventually be SYB
-- ghci... :t cnst 1 x :: (Monad m) = m Exp
cnst n s = return (LamE (replicate n WildP) (LitE (StringL s)))
dumpSplice splice = runQ splice = putStrLn . pprint
debugTemplates = do dumpSplice (cnst 1 x)
dumpSplice (inferStartState ''MyState)
{-
*MyState debugTemplates
\_ - x
Template Haskell error: Can't do `reify' in the IO monad
*** Exception: user error (Template Haskell failure)
-}
---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Derivation of Eq given Ord
I would say that qualifies as a bug because it relays an error from compile
time to run time.
Andreas
- Original Message -
From: Dougal Stanton [EMAIL PROTECTED]
To: haskell-cafe haskell-cafe@haskell.org
Sent: Thursday, August 09, 2007 5:57 PM
Subject: [Haskell-cafe] Derivation of Eq given Ord
Is there a reason why automatic derivation of Ord without Eq doesn't
do the sensible thing and just derive Eq anyway?
newtype Id a = Id { a :: String }
deriving (Read, Show, Eq, Ord)
newtype Ego a = Ego { b :: String }
deriving (Read, Show, Ord)
Both will type check, but if you try any (in)equality operators on the
second they'll be spat back at you.
*Main let e1 = Ego
*Main let e2 = Ego
*Main e1 e2
interactive:1:0:
No instance for (Eq (Ego a))
arising from use of `' at interactive:1:0-6
Possible fix: add an instance declaration for (Eq (Ego a))
In the expression: e1 e2
In the definition of `it': it = e1 e2
It doesn't seem *much* of a hardship, but it wasn't what I expected.
I'm not used to GHC accepting input and silently dropping stuff it
doesn't like...
Cheers,
D.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow IO or bad code?
Note that this code isn't more successful, clearly I have misunderstood one requirement : import qualified Data.ByteString.Char8 as B import Data.List (unfoldr) main = B.interact $ hot hot = B.unlines . map (B.pack . show) . processList . tail . unfoldr readInt1 readInt1 cs = do (n, cs') - B.readInt cs return (n, B.tail cs') processList [] = [] processList (x:xs) = (sum $ zipWith (*) men women) : processList rest where (men,r1) = splitAt x xs (women,rest) = splitAt x r1 -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Derivation of Eq given Ord
I wrote: instance Eq Ego = Eq Ord where ... This should have been instance Eq (Ego a) = Ord (Ego a) Malte ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how can I get template haskell macro-expanded code from inferStartState? (repeated post, now with subject)
On 09/08/07, Thomas Hartman [EMAIL PROTECTED] wrote: (sorry, forgot the subject on my first post) In the following code which uses template haskell, how can I get back the macro-expanded code generated from $(inferStartState ''MyState) I just recently used ghc -ddump-splices to debug this very same problem. It turns out to be due to overlapping instances - inferStartState generates a (from memory) specific StartStateEx instance, but actually theres a general StartState = StartStateEx, and also a general Monoid=StartState instance, and thats why the error message mentions Monoid. I guess this teaches us the reason that overlapping instances are bad: ***They don't work across modules Another module can add an instance which wasn't visible when a first module was compiled, and the two modules end up using different instances than expected. I've been meaning to start trying to contribute to improving the HAppS documentation, since its been such a struggle to start learning it. So the question to the HAppS people is, where is the canonical place for this documentation, where should one work? Is it the wiki page above, or the stuff inside the HAppS repository? -- [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI
Duncan Coutts wrote: On Thu, 2007-08-09 at 08:59 +0800, Hugh Perkins wrote: uestion on using gtk from haskell: how easy is it to integrate with glade? ie, can we directly bind glade form elements to haskell variables? How easy is it to bind events to glade form elements from within Haskell? It's pretty easy, see the Gtk2Hs/Glade tutorial: http://haskell.org/gtk2hs/docs/tutorial/glade/ Indeed - the *hard* part seems to be figuring out how to run Glade on Windoze... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Small question
Which of these is likely to go faster? type Quad = (Bool,Bool) foo (r,t) = let x = if r ... y = if t ... in ... data Quad = BL | BR | TL | TR foo q = let x = if q == TL | q == TR ... y = if q == BR | q == TR ... in ... (Unless somebody has a better idea...) I'm hoping that the latter one will more more strict / use less space. But I don't truely know... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Matters of precision
Hi folks. I'm trying to write a Mandelbrot generator, and I've having a few problems with precision. First of all, currently I'm just using Double to represent coordinates. Can anybody tell me what the smallest value you can represent with one is? (Not including denormals.) (I've built a function that checks for cycles in the orbit - by looking for previous points that are sufficiently near to the current one. But I want to know how much precision a Double gives me so I can figure out how near is near.) Next up, at some point I'm going to need more precision than a Double can give me. (But, obviously, I still want the thing to go as fast as humanly possible.) In particular, I do NOT want to go into infinite precision. (E.g., exact arithmetic with arbitrary fractions.) I want to be able to make the precision arbitrarily high, but still finite and fixed. (The idea being that the further you zoom in, the more the computer turns up the precision.) Is there anything useful for this in the standard libraries? Or will I have to write something? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with question 3 about knights and knaves on wikipedia
I was writing some haskell code for fun to solve some knights and knaves problems, and I have troubles with http://en.wikipedia.org/wiki/Knights_and_knaves#Question_3 So knights always tell the truth and knaves always lie. John and Bill are two persons, but you don't know what they are, and you have to find out. Question 3 You: Are you both knights? John: answers either Yes or No, but you don't have enough information to solve the problem. You: Are you both knaves? John: answers either Yes or No, and you can now solve the problem. My haskell code gave the following result: --(what is john, what is bill, first answer from john, second answer from john) (John is a knight,Bill is a knight,Yes,No ) (John is a knight,Bill is a knave ,No ,No ) (John is a knave ,Bill is a knight,Yes,Yes) (John is a knave ,Bill is a knave ,Yes,No ) Anyone has an idea what I missed here? Thanks, Peter PS: The (quick and dirty) haskell code I wrote for this is: infixl 1 = infixl 1 == -- Equivalence x = y = (x == y) -- Implication True == False = False _== _ = True -- Knights tell the truth name `isa` True = name ++ is a knight -- Knaves always lie name `isa` False = name ++ is a knave answer True = Yes answer False = No --Logician: Are you both knights? --John answers either Yes or No, but the Logician does not have enough information to solve the problem. --Logician: Are you both knaves? --John answers either Yes or No, and the Logician can now solve the problem. condition j b answer1 answer2 = (j = ((b j) == answer1)) (j = ((not b not j) == answer2)) solution = [(John `isa` j, Bill `isa` b, answer answer1, answer answer2) | j - [True,False], b - [True, False], answer1 - [True, False], answer2 - [True, False], condition j b answer1 answer2 ] main = mapM_ putStrLn (map show solution) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
On 09/08/07, Andrew Coppin [EMAIL PROTECTED] wrote:
Which of these is likely to go faster?
type Quad = (Bool,Bool)
foo (r,t) =
let
x = if r ...
y = if t ...
in ...
data Quad = BL | BR | TL | TR
foo q =
let
x = if q == TL | q == TR ...
y = if q == BR | q == TR ...
in ...
(Unless somebody has a better idea...)
I'm hoping that the latter one will more more strict / use less space.
But I don't truely know...
Sounds like the perfect candidate for a benchmark, then!
Another tool for your toolbox:
{-#OPTIONS -funbox-strict-fields #-}
data Quad = Quad !Bool !Bool
foo True True = ...
foo True False =
... etc...
The GHC option just causese GHC to unbox primitive types when they're
strict in the data type, and the bangs cause them to be strict.
--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
On Thu, Aug 09, 2007 at 07:12:12PM +0100, Sebastian Sylvan wrote:
{-#OPTIONS -funbox-strict-fields #-}
data Quad = Quad !Bool !Bool
foo True True = ...
foo True False =
... etc...
The GHC option just causese GHC to unbox primitive types when they're
strict in the data type, and the bangs cause them to be strict.
Unfortunately, Bool is not a sufficiently primitive type for that to
work.
Stefan
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Derivation of Eq given Ord
Andreas Marth wrote: I would say that qualifies as a bug because it relays an error from compile time to run time. It doesn't relay anything to run time - ghci has to _compile_ the expressions you give it too. If you _compile something_ successfully, you will know that _it_ will not fail in the stated way (which is all you need to know for a normal program with 'main'). However it does relay an error from deriving module to using [module/ghci], which may not be right. HOWEVER, I can't reproduce it - ghc (6.6.1) always tells me No instance for (Eq Foo) arising from the superclasses of an instance declaration whether data or newtype, deriving Ord, no Eq instance, and no using operations at all, and Hugs does too (in different words). Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow IO or bad code?
On 8/9/07, Chaddaï Fouché [EMAIL PROTECTED] wrote: I get Wrong answer with the following code for the same problem... Is there something strange in this code : This problem description is not worded very well. You have to figure out the matching that maximizes the sum of hotnesses; you don't necessarily just do a sum . zipWith (*). -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: a regressive view of support for imperative programming in Haskell
Donn Cave wrote: (I have a soft spot for O'Haskell, but alas I must be nearly alone on that.) You are /not/ alone :-) I always found it very sad that O'Haskell and also its sucessor Timber (with all the good real-time stuff added) died the 'quick death' of most research languages. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
On 09/08/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
On Thu, Aug 09, 2007 at 07:12:12PM +0100, Sebastian Sylvan wrote:
{-#OPTIONS -funbox-strict-fields #-}
data Quad = Quad !Bool !Bool
foo True True = ...
foo True False =
... etc...
The GHC option just causese GHC to unbox primitive types when they're
strict in the data type, and the bangs cause them to be strict.
Unfortunately, Bool is not a sufficiently primitive type for that to
work.
Ah good point. Well I'd guess a Word8 would do (might be faster to use
a Word32 or Word64 depending on your machine though?).
--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Pure functional GUI
Indeed - the *hard* part seems to be figuring out how to run Glade on Windoze... I did not dare to ask this question because I could not believe this was hard... So anybody know how to do this? Run Glade on Window$? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Coppin Sent: Thursday, August 09, 2007 7:31 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Pure functional GUI Duncan Coutts wrote: On Thu, 2007-08-09 at 08:59 +0800, Hugh Perkins wrote: uestion on using gtk from haskell: how easy is it to integrate with glade? ie, can we directly bind glade form elements to haskell variables? How easy is it to bind events to glade form elements from within Haskell? It's pretty easy, see the Gtk2Hs/Glade tutorial: http://haskell.org/gtk2hs/docs/tutorial/glade/ Indeed - the *hard* part seems to be figuring out how to run Glade on Windoze... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Operator overloading
On 8/9/07, rodrigo.bonifacio [EMAIL PROTECTED] wrote: Hi all. I want to overload the operator ^ for working instead of the following +++ operator: (+++) :: String - [[String]] - [[String]] x +++ y = [ x:e | e-y ] How can I overload the ^ operator? import Prelude hiding ( (^) ) -- this is the key (^) :: String - [[String]] - [[String]] x ^ y = [ x:e | e-y ] By the way, there's nothing special about Strings here: if you made the type of ^ (^) :: a - [[a]] - [[a]] it would work on lists of any type, including String. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a regressive view of support for imperative programming in Haskell
On Thu, Aug 09, 2007 at 04:02:05PM +1200, ok wrote: On 9 Aug 2007, at 8:41 am, David Roundy wrote: I may be stating the obvious here, but I strongly prefer the do syntax. It's nice to know the other also, but the combination of do +indenting makes complicated code much clearer than the nested parentheses that would be required with purely = syntax. Er, what nested parentheses would those be? do x1 - e1 if x1 then do x2 - e2 xx - if x2 then e3 else do x4 - e4 x5 - e5 e6 x4 x5 e7 xx x1 else do x8 - e8 x9 - e9 e10 x8 x9 x1 x11 would become something like e1 = \x1 - if x1 then e2 = \x2 - if x2 then e3 else e4 = \x4 - e5 = \x5 - e6 x4 x5 = (flip e7) x1 else e8 = \x8 - e9 = \x9 - e10 x8 x9 x1 x11 except that you'd have to figure out where to add parentheses. I'm sure I'd end up writing extra parentheses, but if you put in the minimal number of parentheses, then I doubt I'd be able to read the code. If you only consider the case of trivial code, then you're right, there are no extra parentheses required. This is the beauty of the do notation, it allows one to write actual real complicated monadic code in a form that is actually comprehensible. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: a regressive view of support for imperative programming in Haskell
David Roundy wrote: Several times since reading the beginning of this discussion I've wished I had the new syntax so I could write something like: do if predicateOnFileContents (- readFile foo) then ... instead of either do contents - readFile foo if predicateOnFileContents contents then ... or (as you'd prefer) readFile foo = \contents - if predicateOnFileContents contents then ... Isn't this problem, namely being forced to name intermediate results, also solved by some sort of idiom bracket sugar, maybe together with the lambda case proposal? I would prefer both very much to the proposed (- action) syntax for the same reasons that e.g. Jules Bean nicely summarized. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a regressive view of support for imperative programming in Haskell
On Thu, Aug 09, 2007 at 02:08:20PM +0100, Jules Bean wrote: David Roundy wrote: On Wed, Aug 08, 2007 at 02:20:39PM -0400, Paul Hudak wrote: As long as the sugar has a pretty obvious desugaring (which I seem to recall it did), I don't see how it's likely to make things worse. And Some people are arguing that the desugaring isn't obvious. That's a reasonable objection (although I disagree). Although I like the proposal to start with, I am beginning to be convinced by those arguments. For example: do foo x can be simplified to foo x under the new proposals do x - bar y foo x would shorten to do foo (- bar y) and now you really really want to remove the do, to get simply foo (- bar y) but that would be illegal. The new sugar is going to remove all kinds of substitution and simplification lemmas that we have got used to. I guess I'd just have to argue that like the - notation, the (- ) notation is *part* of the do notation. Just as you can't pull a - out of a do loop and expect it to behave identically, you can't do the same with a (- ). To me, the similarity with existing do-dependent syntax (and it helps that except for pattern guards, - is *only* used within a do block. There is also the fact that if : foo x = bar x x then you call foo monadically as in do foo (- baz) You can no longer replace foo with its definition, because if replace that with do bar (- baz) (- baz) ...that means something rather different :( Again, this seems obvious, and it doesn't seem like replace foo with its definition is something I think of. A third example is with nested dos: do x - bar y baz something $ do foo x is not the same as do baz something $ do foo (- bar y) Again, it all comes down to whether the find the nearest do is obvious. It seems pretty obvious to me. And I like the idea of someone just implementing this, and then those of us to whom it appeals can try it. I've longed for something like this (mostly for monadic ifs and cases) for quite a while now... -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: a regressive view of support for imperative programming in Haskell
On 8/9/07, Benjamin Franksen [EMAIL PROTECTED] wrote: Donn Cave wrote: (I have a soft spot for O'Haskell, but alas I must be nearly alone on that.) You are /not/ alone :-) I always found it very sad that O'Haskell and also its sucessor Timber (with all the good real-time stuff added) died the 'quick death' of most research languages. There is also RHaskell, which implements an O'Haskell-like system as a Haskell library. http://www.informatik.uni-freiburg.de/~wehr/haskell/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: a regressive view of support for imperative programming in Haskell
On Thu, Aug 09, 2007 at 08:45:14PM +0200, Benjamin Franksen wrote: David Roundy wrote: Several times since reading the beginning of this discussion I've wished I had the new syntax so I could write something like: do if predicateOnFileContents (- readFile foo) then ... instead of either do contents - readFile foo if predicateOnFileContents contents then ... or (as you'd prefer) readFile foo = \contents - if predicateOnFileContents contents then ... Isn't this problem, namely being forced to name intermediate results, also solved by some sort of idiom bracket sugar, maybe together with the lambda case proposal? I would prefer both very much to the proposed (- action) syntax for the same reasons that e.g. Jules Bean nicely summarized. I'm not familiar with the lambda case proposal, and don't know what you mean by idiom bracket sugar, but I haven't had an idea (or heard of one) that was nearly so elegant as the (- action) proposal, which neatly allows one to lift any existing pure function or syntactic construct (except lambda expressions?) into a monad. i.e. we don't need to define a separate 'if', 'case', etc, and we don't need liftM, liftM2, liftM3, liftM4andahalf, all of which are subsumed by a single pretty syntax. The only cost is that this syntax relies on the do notation, and thus makes the desugaring of that do notation slightly more complicated when used. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow IO or bad code?
On 8/9/07, Brent Yorgey [EMAIL PROTECTED] wrote: On 8/9/07, Chaddaï Fouché [EMAIL PROTECTED] wrote: I get Wrong answer with the following code for the same problem... Is there something strange in this code : This problem description is not worded very well. You have to figure out the matching that maximizes the sum of hotnesses; you don't necessarily just do a sum . zipWith (*). Exactly. The description says: Company XYZ has done the work for you, and now do xxx. This confused me a lot :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how can I get template haskell macro-expanded code from inferStartState? (repeated post, now with subject)
I would say both. The stuff under Examples in the repo should all run with 8.8. (I think currently it doesn't.) The stuff in the wiki should say what is 8.8, what is 8.4, and obviously also give examples that work. The advantage of the wiki is you can make a change that propogates to the community without having commit priviliges for the repo. at least, that's how I've been working. Just changing the wiki for now, and maybe someday when I'm more confident about what I'm doing I'll ask for a commit bit for the repo. thomas. Brian Brunswick [EMAIL PROTECTED] 08/09/2007 01:28 PM To Thomas Hartman/ext/[EMAIL PROTECTED] cc haskell-cafe haskell-cafe@haskell.org, [EMAIL PROTECTED] Subject Re: [Haskell-cafe] how can I get template haskell macro-expanded code from inferStartState? (repeated post, now with subject) On 09/08/07, Thomas Hartman [EMAIL PROTECTED] wrote: (sorry, forgot the subject on my first post) In the following code which uses template haskell, how can I get back the macro-expanded code generated from $(inferStartState ''MyState) I just recently used ghc -ddump-splices to debug this very same problem. It turns out to be due to overlapping instances - inferStartState generates a (from memory) specific StartStateEx instance, but actually theres a general StartState = StartStateEx, and also a general Monoid=StartState instance, and thats why the error message mentions Monoid. I guess this teaches us the reason that overlapping instances are bad: ***They don't work across modules Another module can add an instance which wasn't visible when a first module was compiled, and the two modules end up using different instances than expected. I've been meaning to start trying to contribute to improving the HAppS documentation, since its been such a struggle to start learning it. So the question to the HAppS people is, where is the canonical place for this documentation, where should one work? Is it the wiki page above, or the stuff inside the HAppS repository? -- [EMAIL PROTECTED] --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: a regressive view of support for imperative programming in Haskell
David Menendez wrote: On 8/9/07, Benjamin Franksen [EMAIL PROTECTED] wrote: Donn Cave wrote: (I have a soft spot for O'Haskell, but alas I must be nearly alone on that.) You are /not/ alone :-) I always found it very sad that O'Haskell and also its sucessor Timber (with all the good real-time stuff added) died the 'quick death' of most research languages. There is also RHaskell, which implements an O'Haskell-like system as a Haskell library. http://www.informatik.uni-freiburg.de/~wehr/haskell/ Thanks for the pointer, I didn't know about this. Will take a look. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell DB tutorial link is broken.
Hi, The following link is broken. http://www.haskell.org/hawiki/HaskellDbTutorial Edward Ing ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI
2007/8/9, Peter Verswyvelen [EMAIL PROTECTED]: Indeed - the *hard* part seems to be figuring out how to run Glade on Windoze... I did not dare to ask this question because I could not believe this was hard... So anybody know how to do this? Run Glade on Window$? The google knows?? http://gladewin32.sourceforge.net/modules/news/ Frankly, I'm using Linux now, and even under windows (I must use it at work) I use vmware with ubuntu.. But not so long ago I ran glade on windows using stuff from this page. HTH, Radek. -- Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
Stefan O'Rear wrote:
On Thu, Aug 09, 2007 at 07:12:12PM +0100, Sebastian Sylvan wrote:
{-#OPTIONS -funbox-strict-fields #-}
data Quad = Quad !Bool !Bool
foo True True = ...
foo True False =
... etc...
The GHC option just causese GHC to unbox primitive types when they're
strict in the data type, and the bangs cause them to be strict.
Unfortunately, Bool is not a sufficiently primitive type for that to
work.
Stefan
Don't ya just hate it when that happens? (I.e., you say something and
sound all cleaver, and then an expert points out that actually, no.)
Happens to me all the time... heh.
OOC, in what way is Bool not primitive enough? You mean because it's
an algebraic data type, rather than a bunch of bits in the machine? For
that matter, just how much space does such a type typically use?
(Questions, questions, so many questions...)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Explaining monads
(Better view the below in a fixed-width font!) With all the recent monad discussions, I embarked on trying to clarify my own thoughts about them, and started to think about things in terms of just /where/ extra structure is 'understood'. I think I can explain why 'a-IO b' is better than 'IO a-b'. The full title of this is really 'Explaining monads by comparison with comonads and arrows', but I didn't want to scare people off without putting in the above hook! We start with a simple single value of type 'a', and then we move into some other category, where the objects are 'thing a' instead, encapsulating some additional complexity - perhaps the possible absence or multiplicity of the value, perhaps extra state, opacity, etc. But whatever it is, the a-ness is still key for combing these objects. So lets look how they combine. Pay special attention to the f column. g f ??? g ??? f application a a-b flip ($) b monad bind m a a-m b= m b comonad cobind w a w a-b= w b arrowarr a b arr b c arr a c simple application: f takes one argument, returns one result. monad: f still takes one argument, but now understands how to put things /into/ m. (Perhaps it just uses return::a-m a) comonad: f has access to the entire complexity of 'w a', understands how to get thing(s) out of it (coreturn), and distills it all down to one simple b. arrow: f has access to the entire complexity of the 'input' of arr b c, and does whatever is needed, to make the complexity of the 'output' of arr b c. Input/output may even be bidirectional! Also we can look at the job that ??? does. Remember that ??? has access to f as a function and can call it as many or as few times as it wishes. $: feeds a to f, once. =: picks zero or more a's from 'm a', feeds each one separately to f. opens up each of the 'm b' results to combine them into one 'm b'. =: feeds one or more versions of 'w a' to f, then builds a 'w b' in some way using the single b's (Perhaps inspired by 'w a') : links g to f in some way, so they can interact in as complex a way as they like. Maybe it also contributes to that complexity. So now perhaps we can come to some conclusion about why monads are so useful and universal as control structures. It seems that monads are somehow the /simplest/ way of adding general control structure on top of single values. Notice how in a monad, the things that are combined together, the f's, still take just one 'a' argument. So theres no extra complexity for f in understanding its input. f can, however, put some additional complexity into its output - it can fail, or return multiple values, or whatever else is possible to encode in 'm a'. Still, f can be dumb, and just pass the problem onto some other function, maybe return. The complexity of the monad lives in one place, bind, =. It is bind that has the choice of calling f multiple times if it feels like it, and has the job of combining the results. bind is in control. f can only give it directions by returning one 'm b' for a given a. Contrast a comonad. Each f has to cope with an entire 'w a' on input. Moreover, it can't communicate any of that complexity back to cobind - it can only return one b. cobind only has the structure of 'w a' to inspire it in how to put together 'w b', it can receive /no/ instructions from f. Arrows are of course most general. Nothing is determined except that f talks with g in some way, and the compatibility is named 'b'. So given the choice of the above, which would /you/ choose, when the nature of the problem means one-on-one application is too simple? Surely a monad is the pick of the bunch! * f gives merely directions on control to = * f has to understand merely one single argument. (the monad can supply extra specialized functions like get/put, if we do want some complexity in there) * All the complex control structure is handled in one place - bind. And it has all the information available to do it well. Pity the poor comonad, only really suitable for infinite sequences! Shudder at the thought of the total complexity possible using arrows, and use them only when /really/ necessary. monad is king! -- [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: a regressive view of support for imperative programming in Haskell
David Roundy wrote: On Thu, Aug 09, 2007 at 08:45:14PM +0200, Benjamin Franksen wrote: David Roundy wrote: Several times since reading the beginning of this discussion I've wished I had the new syntax so I could write something like: do if predicateOnFileContents (- readFile foo) then ... instead of either do contents - readFile foo if predicateOnFileContents contents then ... or (as you'd prefer) readFile foo = \contents - if predicateOnFileContents contents then ... Isn't this problem, namely being forced to name intermediate results, also solved by some sort of idiom bracket sugar, maybe together with the lambda case proposal? I would prefer both very much to the proposed (- action) syntax for the same reasons that e.g. Jules Bean nicely summarized. I'm not familiar with the lambda case proposal, http://hackage.haskell.org/trac/haskell-prime/wiki/LambdaCase or, quoting from a recent post by Stefan O'Rear in this thread: I think the CaseLambda proposal on the Haskell' wiki solves this one nicely. mexpr = case of p1 - branch1 p2 - branch2 You still have to use =, but you don't have to name the scrutinee (and names are expensive cognitively). i.e. your example would become fmap predicateOnFileContents (readFile foo) = case of True - ... False - ... (use liftM instead of fmap, if you prefer) and don't know what you mean by idiom bracket sugar, As has been already mentioned in this thread, in http://www.soi.city.ac.uk/~ross/papers/Applicative.html Conor McBride and Ross Paterson invent/explain a new type class that is now part of the base package (Control.Applicative). They also use/propose syntactic sugar for it, i.e. pure f * u1 * ... * un ~~ (| f u1 ... un |) (I just made up the symbols '(|' and '|)', the concrete syntax would have to be fixed by people more knowledgeable than me.) As to the pros and cons of (- action) proposal, I think everything has been said. I'd vote for giving IdiomBrackets and/or LambdaCase a chance for being implemented, too, so we can try and evaluate different ways to simplify monadic code. One reason why I like IdiomBrackets is that they are more generally applicable (no pun intended ;:) i.e. they would work not just for Monads but for anything in Applicative. (Of course, that is also their weakness.) Similary, LambdaCase has more applications than just simplifying monadic code by avoiding to name an intermediate result. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
On Thu, Aug 09, 2007 at 09:27:23PM +0100, Andrew Coppin wrote: OOC, in what way is Bool not primitive enough? You mean because it's an algebraic data type, rather than a bunch of bits in the machine? For that matter, just how much space does such a type typically use? Yes. data Bool = False | True In general, GHC doesn't do unboxing. Instead it has a simpler and more general approach, where it passes the fields of a single-constructor type instead of the type itself; this is as good as true unboxing in most of the interesting cases: data Int = I# Int# data Float = F# Float# data Double = D# Double# data Char = C# Char# data Ptr = Ptr Addr# ... but not always: data Bool = False | True data Integer = S# Int# | J# ByteArray# Int# As far as actual heap usage goes, GHC creates single static values for all 0-argument constructors; so all Bool WHNFs are one of two addresses, one for True and one for False. But GHC isn't quite smart enough for the -funbox-strict-fields mechanism to understand this... (Questions, questions, so many questions...) I like answering them. :) Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Pure functional GUI
Yeah I tried that one, but only the runtime, because I assumed that glade would be part of it, but I could not find it. I guess I should install the development version. Windows users look differently at these things, they expect all tools to be precompiled ;) I'll try again and dig deeper. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Radoslaw Grzanka Sent: Thursday, August 09, 2007 10:22 PM To: Haskell-Cafe@haskell.org Subject: Re: [Haskell-cafe] Pure functional GUI 2007/8/9, Peter Verswyvelen [EMAIL PROTECTED]: Indeed - the *hard* part seems to be figuring out how to run Glade on Windoze... I did not dare to ask this question because I could not believe this was hard... So anybody know how to do this? Run Glade on Window$? The google knows?? http://gladewin32.sourceforge.net/modules/news/ Frankly, I'm using Linux now, and even under windows (I must use it at work) I use vmware with ubuntu.. But not so long ago I ran glade on windows using stuff from this page. HTH, Radek. -- Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
Stefan O'Rear wrote:
On Thu, Aug 09, 2007 at 09:27:23PM +0100, Andrew Coppin wrote:
OOC, in what way is Bool not primitive enough? You mean because it's an
algebraic data type, rather than a bunch of bits in the machine? For that
matter, just how much space does such a type typically use?
Yes.
data Bool = False | True
In general, GHC doesn't do unboxing. Instead it has a simpler and
more general approach, where it passes the fields of a
single-constructor type instead of the type itself; this is as good as
true unboxing in most of the interesting cases:
data Int = I# Int#
data Float = F# Float#
data Double = D# Double#
data Char = C# Char#
data Ptr = Ptr Addr#
...
I see. (I think!)
but not always:
data Bool = False | True
data Integer = S# Int# | J# ByteArray# Int#
As far as actual heap usage goes, GHC creates single static values for
all 0-argument constructors; so all Bool WHNFs are one of two addresses,
one for True and one for False. But GHC isn't quite smart enough for
the -funbox-strict-fields mechanism to understand this...
Right. So a Bool is a 32 or 64 bit quantity. (Rather like Smalltalk...)
That presumably means that a (Double,Double) is going to be a thunk that
evaluates to a (,) pointing to two thunks that evaluate to pointers...
IOW, something like 3 pointers' worth of space. Whereas my Quad object
is going to be a pointer to one of 4 values... so it looks like Quads
save space. (And they're more strict.) OTOH, I'm not sure what the time
penalty is like...
It would be nice if there were some general mechanism for turning a
bunch of Bool flags into a single machine word. E.g., if I did a
data Foo = Foo {flagX, flagY, flagZ :: !Bool}
and it ends up that a Foo value is just a single machine word, and GHC
picks which bit each flag is... I guess if you want that at present
you'd have to code it all by hand. Hmm, I think this might work out
better than my current Quad thing... I could do something like
type Quad = Word8
foo q = let
x = if testBit 0 q ...
y = if testBit 1 q ...
That should be quite fast... (?)
(Questions, questions, so many questions...)
I like answering them. :)
Heh. I'll have to pester you more often. :-P
PS. Somewhere they should write a page entitled Optimisations that GHC
does (and doesn't) do...
PPS. Hmm. Might be out of date fast? ;-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI
Radosław Grzanka wrote: The google knows?? http://gladewin32.sourceforge.net/modules/news/ Ah - most optimal... Now finally I can try Glade. :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with question 3 about knights and knaves onw ikipedia
On Thu, 9 Aug 2007 23:06:04 +0200, you wrote: Is still don't get it completely... Could you give me an extra hint? I'm getting crazy here, especially because I was really good at this stuff 20 years ago! :) Here's the reasoning The first answer could not be no because from that I can infer that John is a knight and Bill is a knave, which would mean the logician knows the answer. This leaves me with 3 possibilities: a) Both John and Bill are knights b) John is a knave and Bill could be anything Correct. But you forgot to recursively apply the hint. ;) The problem states that after John answers the second question, the Logician knows the solution. How can this be? What answer did John give that allows the Logician to solve the problem? Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] where to put handy functions?
Is there process for submitting functions for consideration for inclusion into future versions of the standard libraries? For example, I'd like to see this in Data.List: extract :: [Int] - [a] - [a] extract = f 0 where f _ _ [] = [] f _ [] _ = [] f k nss@(n:ns) (x:xs) = if n == k then x:f (k+1) ns xs else f (k+1) nss xs This behaves roughly as extract ns xs == map (xs !!) ns except that it's a lot more efficient, and it still works if ns or xs (but not both) are infinite. Oh, and ns are required to be ordered and non-negative. I'm guessing there are a lot of similarly simple handy functions, and I'm wondering if there's anything in place to avoid (1) reinventing the wheel, and (2) name clashes. Someone else may have written extract as well, meaning one of us wasted our time. And chances are, if they did, it has a different name, leading to forced qualified imports. Finally, even if no one else is using it, it would be good to settle on reasonable names for things more easily. Is there a better name for this function? Is there a reason not to call it extract? -- Chad Scherrer Time flies like an arrow; fruit flies like a banana -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pure functional GUI
2007/8/9, Peter Verswyvelen [EMAIL PROTECTED]: Yeah I tried that one, but only the runtime, because I assumed that glade would be part of it, but I could not find it. I guess I should install the development version. Windows users look differently at these things, they expect all tools to be precompiled ;) I'll try again and dig deeper. Runtime is enough.. But Glade is packaged separetly. http://gladewin32.sourceforge.net/modules/wfdownloads/viewcat.php?cid=2 I just cheked it and it works flawlessly (as far as my 1 minute test goes ;) ) (Oh. I seem to remember that I needed GTK runtime from THIS page. It didn't go nicely with runtime installed with GIMP for windows package.) Have fun, Radek -- Codeside: http://codeside.org/ Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Problem with question 3 about knights and knaves onw ikipedia
Indeed, I missed that. This rules out the first answer is no But I still keep the 3 other solutions then :( (John is a knight,Bill is a knight,Yes,No ) (John is a knave ,Bill is a knight,Yes,Yes) (John is a knave ,Bill is a knave ,Yes,No ) Any more help (or just the solution, I give up) is very welcome to help this poor man in logic hell ;-) Oh well, it seems I'm getting too old for this stuff ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Schafer Sent: Thursday, August 09, 2007 8:22 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Problem with question 3 about knights and knaves onw ikipedia On Thu, 9 Aug 2007 20:07:02 +0200, you wrote: (John is a knight,Bill is a knight,Yes,No ) (John is a knave ,Bill is a knight,Yes,Yes) (John is a knave ,Bill is a knave ,Yes,No ) Anyone has an idea what I missed here? You're missing a key element of the problem: After John answers the first question, the Logician doesn't have enough information to solve the problem. Think about that for a second, and you will see the light. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] where to put handy functions?
On Thu, Aug 09, 2007 at 02:29:50PM -0700, Chad Scherrer wrote: Is there process for submitting functions for consideration for inclusion into future versions of the standard libraries? For example, I'd like to see this in Data.List: extract :: [Int] - [a] - [a] extract = f 0 where f _ _ [] = [] f _ [] _ = [] f k nss@(n:ns) (x:xs) = if n == k then x:f (k+1) ns xs else f (k+1) nss xs This behaves roughly as extract ns xs == map (xs !!) ns except that it's a lot more efficient, and it still works if ns or xs (but not both) are infinite. Oh, and ns are required to be ordered and non-negative. I'm guessing there are a lot of similarly simple handy functions, and I'm wondering if there's anything in place to avoid (1) reinventing the wheel, and (2) name clashes. Someone else may have written extract as well, meaning one of us wasted our time. And chances are, if they did, it has a different name, leading to forced qualified imports. Finally, even if no one else is using it, it would be good to settle on reasonable names for things more easily. Is there a better name for this function? Is there a reason not to call it extract? http://www.haskell.org/haskellwiki/Library_submissions Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] can't build haxml under ghc 6.7, says HughesPJ is hidden... but ghc-pkg doesn't say it's hidden...
Can I get some help building HaXml (from hackage) under ghc 6.7? I'm hoping to get HAppS running under 6.7, and use the new debugger to better understand what's going on under the hood. Eg, when I'm in the h function, I can take a look at the args and just see what types they are. (I am finding building an intuition from the documentation alone to be overwhelming. Too many types, too many instances... total confusion.) HaXMl is a dependendency for happs, that's why I need it. Anyway building haxml this is what I get. The subject of my message more or less summarizes my confusion. [EMAIL PROTECTED]:~/installs/HaXml-1.13.2runghc Setup.hs build Setup.hs: Warning: The field hs-source-dir is deprecated, please use hs-source-dirs. Preprocessing library HaXml-1.13.2... Preprocessing executables for HaXml-1.13.2... Building HaXml-1.13.2... src/Text/XML/HaXml.hs:30:7: Could not find module `Text.PrettyPrint.HughesPJ': it is a member of package pretty-1.0, which is hidden [EMAIL PROTECTED]:~/installs/HaXml-1.13.2ghc-pkg list /usr/local/lib/ghc-6.7.20070719/package.conf: Cabal-1.1.7, base-2.1, directory-1.0, filepath-1.0, ghc-6.7.20070719, haskell98-1.0, hpc-0.5, old-locale-1.0, old-time-1.0, pretty-1.0, process-1.0, random-1.0, readline-1.0, rts-1.0, template-haskell-0.1, unix-2.0 [EMAIL PROTECTED]:~/installs/HaXml-1.13.2ghc-pkg list pretty-1.0 /usr/local/lib/ghc-6.7.20070719/package.conf: pretty-1.0 [EMAIL PROTECTED]:~/installs/HaXml-1.13.2ghc --version The Glorious Glasgow Haskell Compilation System, version 6.7.20070719 [EMAIL PROTECTED]:~/installs/HaXml-1.13.2ghc-pkg describe pretty-1.0 name: pretty version: 1.0 license: BSD3 copyright: maintainer: [EMAIL PROTECTED] stability: homepage: package-url: description: This package contains a pretty-printing library. category: author: exposed: True exposed-modules: Text.PrettyPrint Text.PrettyPrint.HughesPJ hidden-modules: import-dirs: $topdir/lib/pretty-1.0 library-dirs: $topdir/lib/pretty-1.0 hs-libraries: HSpretty-1.0 extra-libraries: extra-ghci-libraries: include-dirs: $topdir/lib/pretty-1.0/include includes: depends: base-2.1 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: $topdir/share/ghc/doc/html/pretty/pretty.haddock haddock-html: $topdir/share/ghc/doc/html/pretty [EMAIL PROTECTED]:~/installs/HaXml-1.13.2 [EMAIL PROTECTED]:~/ProjectRepos/miscAdminghc-pkg list /usr/local/lib/ghc-6.7.20070719/package.conf: Cabal-1.1.7, base-2.1, directory-1.0, filepath-1.0, ghc-6.7.20070719, haskell98-1.0, hpc-0.5, old-locale-1.0, old-time-1.0, pretty-1.0, process-1.0, random-1.0, readline-1.0, rts-1.0, template-haskell-0.1, unix-2.0 --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can't build haxml under ghc 6.7, says HughesPJ is hidden... but ghc-pkg doesn't say it's hidden...
On Thu, Aug 09, 2007 at 06:40:47PM -0400, Thomas Hartman wrote: Can I get some help building HaXml (from hackage) under ghc 6.7? I'm hoping to get HAppS running under 6.7, and use the new debugger to better understand what's going on under the hood. Eg, when I'm in the h function, I can take a look at the args and just see what types they are. (I am finding building an intuition from the documentation alone to be overwhelming. Too many types, too many instances... total confusion.) HaXMl is a dependendency for happs, that's why I need it. Anyway building haxml this is what I get. The subject of my message more or less summarizes my confusion. You're encountering one of my favorite features of Cabal. When you build a package, Cabal passess the -hide-all-packages option to GHC, which prevents the package from using any installed packages other than the ones explicitly listed in the Build-Depends: field. This is a Good Thing, because it means that whether or not a package builds depends *only* on the versions of the Build-Depended packages; other random packages on your system cannot possibly have any effect. Unfortunately, it means that splitting an existing package (base - base + pretty + directory + old-time, with much more to come) is less than transparent; all packages which use HughesPJ need their Build-Depends field modified to include pretty, etc. Thomas Schilling's configurations allows a package to build with split and unsplit bases, but requires the logic to handle this be present in every package that wants to use base, and is only in HEAD cabal. I personally advocate a Debian-style system of Provides and re-exposing, but haven't yet bothered to actually implement it at all. I'm sure other people have other approaches. For now, we just edit .cabal files when transporting code between GHC versions... Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a regressive view of support for imperative programming in Haskell
On Thu, Aug 09, 2007 at 11:52:17AM -0700, David Roundy wrote: On Thu, Aug 09, 2007 at 02:08:20PM +0100, Jules Bean wrote: *snip* A third example is with nested dos: do x - bar y baz something $ do foo x is not the same as do baz something $ do foo (- bar y) Again, it all comes down to whether the find the nearest do is obvious. It seems pretty obvious to me. And I like the idea of someone just implementing this, and then those of us to whom it appeals can try it. I've longed for something like this (mostly for monadic ifs and cases) for quite a while now... Funny, I've been longing for the monadic case (and if) for quite a while. A mondic case is simple, it's handy, and you don't have to worry about lots of interactions caseM e of alts == e = \x - case x of alts I'm convinced this would be plenty useful on its own, and also that trying to design any more comprehensive syntax quickly gets really tricky. The basic problem seems to be that functions can expect either monadic or pure arguments, and return pure or monadic values, so there are at least three possible conversion you might want at each application (considering pure-pure and monadic-monadic the same). Defaulting to make things work requires type information, and doesn't seem nearly so simple if you consider that programmers might actually want to pass around actions of the monad they are running in as values (Setting GUI callbacks, using [] for String processing, etc). Actually, deciding which tranformation gets juxtaposition and how to recurse into subterms seems to give a design space that might have reasonable solutions. More on that in a latter message. There is also the fact that if : foo x = bar x x then you call foo monadically as in do foo (- baz) You can no longer replace foo with its definition, because if replace that with do bar (- baz) (- baz) ...that means something rather different :( Again, this seems obvious, and it doesn't seem like replace foo with its definition is something I think of. One of the great things about haskell is how completely naive you can be when you replace foo with its definition, and still do valid equational reasoning. It would be sad if substituting a parenthesized subterm of something that looked like an expression wasn't valid. (expanding a definition can change sharing, but at least it's denotationally equivalent). The only slightly tricky things now are remembering that x - exp does not define x to be exp, and what to expand a class method to. I think I'd be happier if there was some bracketing around the expression to be transformed, to warn you to again be cautious and fearful about transforming your code. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: a regressive view of support for imperative programming in Haskell
On 8/9/07, Benjamin Franksen [EMAIL PROTECTED] wrote: David Menendez wrote: There is also RHaskell, which implements an O'Haskell-like system as a Haskell library. http://www.informatik.uni-freiburg.de/~wehr/haskell/ Thanks for the pointer, I didn't know about this. Will take a look. Perhaps a wiki page is in order. Reactive objects are an appealing way to organize programs, but there isn't much information on-line about people's experience with them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a regressive view of support for imperative programming in Haskell
On 10 Aug 2007, at 6:42 am, David Roundy wrote: do x1 - e1 if x1 then do x2 - e2 xx - if x2 then e3 else do x4 - e4 x5 - e5 e6 x4 x5 e7 xx x1 else do x8 - e8 x9 - e9 e10 x8 x9 x1 x11 Granted. If you desugar nested dos then you need extra parentheses. (Basically, the invisible curly braces turn visible as parentheses.) But then, I don't regard this example as readable, and in true lots of little functions style would name the steps. I especially dislike the irregular indentation one gets with do/if/do. Anyone remember when Haskell extended list comprehension syntax to monads? Just as I was about to get my head around it, it went away. This is the beauty of the do notation, it allows one to write actual real complicated monadic code in a form that is actually comprehensible. It seems we are now in complete agreement except for comprehensible. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Matters of precision
G'day. Quoting Andrew Coppin [EMAIL PROTECTED]: First of all, currently I'm just using Double to represent coordinates. Can anybody tell me what the smallest value you can represent with one is? (Not including denormals.) Remember that floating point numbers are stored in three parts. There's a sign, an exponent and a mantissa. Assuming that floatRadix n == 2, normalised numbers can be represented as: s * m * 2^e where s is 1 or -1, m is in the range [1/2,1) and stored using floatDigits n bits of precision, and e is in the range floatRange n. The reason why this is significant is that the precision of a floating point number is relative, not absolute. The relative error is measured by a number called epsilon: -- The recursion is just so that we don't need -fglasgow-exts; feel -- free to use lexically-scoped type variables instead if you like. epsilon :: (RealFloat a) = a epsilon = let eps = encodeFloat 1 (1 - floatDigits eps) in eps epsilon is the smallest number such that 1.0 + epsilon /= 1.0. It measures the minimum possible relative separation between two adjacent normalised floating-point numbers. That is, if both a and b are normalised floating-point numbers (this also means that they're not zero), and a /= b, then abs (a-b) / a = epsilon. Similarly, the maximum possible relative separation is epsilon * 2. (In general, epsilon * floatRadix n, but AFAIK no architectures that any Haskell implementation has been ported to has any floatRadix other than 2, so this is a safe assumption.) (I've built a function that checks for cycles in the orbit - by looking for previous points that are sufficiently near to the current one. But I want to know how much precision a Double gives me so I can figure out how near is near.) While epsilon is the minimum relative separation of RealFloat numbers, it is usually much smaller than the error of any nontrivial bunch of operations. For something as simple as a Mandelbrot iteration, it's usually okay to simply use epsilon multiplied by some factor which represents the accumulated error of a bunch of operations. If you were doing Serious Numeric Analysis(tm), you'd go through each step and work out the possible rounding error, and come up with a tight bound. But something like this will probably do: tolerance :: Double tolerance = 100 * epsilon near :: Double - Double - Bool near a b | a == 0 || isDenormalized a = abs (a-b) tolerance | otherwise = abs (a-b) tolerance * a Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
On Thu, Aug 09, 2007 at 06:37:32PM +0100, Andrew Coppin wrote: Which of these is likely to go faster? type Quad = (Bool,Bool) ... data Quad = BL | BR | TL | TR ... I'm hoping that the latter one will more more strict / use less space. But I don't truely know... The second one will be signifigantly better for a couple reasons. A simple counting of values that they can take on will show not only this but that they are not isomorphic even, (Bool,Bool) can be one of _|_ (True,True) (True,False) (False,True) (False,False) (_|_,True) (_|_,False) (_|_,_|_) (True,_|_) (False,_|_) that is a total of 10 different cases, each time a bottom might appear, a thunk evaluation (or indirection) is involved. now, take the second case data Quad = BL | BR | TL | TR the possible values are _|_ BL BR TL TR a whole half of the other representation. under jhc (and probably ghc at some point in the future) there is another very strong advantage to the second one, since it is an enumerated type, internally it can be represented by a simple unboxed byte that takes on a value of 0,1,2,or 3, which is a very enabling optimization, especially in the 'if' case in your code. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] where to put handy functions?
On 10 Aug 2007, at 9:37 am, Stefan O'Rear wrote: http://www.haskell.org/haskellwiki/Library_submissions I'd like to ask if it's possible to add expm1 and log1p to the Floating class: class ... Floating a where ... exp, log, sqrt :: a - a expm1, lop1p:: a - a-- new, copied from C99 ... expm1 x = exp x - 1 -- but done more accurately log1p x = log (1 + x) -- but done more accurately However, the Library_submissions page wants an implementation, and adding this sort of function seems to require getting into the guts of an implementation. (Difficult: I am having serious trouble getting GHC 6.6 to install at all, never mind changing it.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] where to put handy functions?
On 8/9/07, Chad Scherrer [EMAIL PROTECTED] wrote: Is there process for submitting functions for consideration for inclusion into future versions of the standard libraries? For example, I'd like to see this in Data.List: I imagine including it in std lib takes a while. Would it be a good idea to include it in MissingH http://software.complete.org/missingh in the mean time? Cheers, Rahul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] where to put handy functions?
rk: On 8/9/07, Chad Scherrer [EMAIL PROTECTED] wrote: Is there process for submitting functions for consideration for inclusion into future versions of the standard libraries? For example, I'd like to see this in Data.List: I imagine including it in std lib takes a while. Would it be a good idea to include it in MissingH http://software.complete.org/missingh in the mean time? It is probably better not to stick everything in MissingH -- its too big to be used easily. Smaller packages (say, Data.List.Extensions) make more sense. However, getting ok for stuff in Data.List isn't too hard. Just follow the libraries submission process: http://haskell.org/haskellwiki/Library_submissions Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
G'day all. Quoting Stefan O'Rear [EMAIL PROTECTED]: In general, GHC doesn't do unboxing. Instead it has a simpler and more general approach, [...] I'm not convinced that the phrase more general is appropriate here. :-) As far as actual heap usage goes, GHC creates single static values for all 0-argument constructors; so all Bool WHNFs are one of two addresses, one for True and one for False. And, of course, if it's a strict argument, then the values stored are ALWAYS one of two possibilities. So as a matter of curiosity, would there be any advantage at all for unboxing enumeration types? (Apart from, I suppose, the possibility of using fewer than 32/64 bits to store a flag.) Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic thread management?
hughperkins: Haskell/FP seems to have solved the hardest bit of threading, which is making it obvious which bits of a program are parallelizable, and which are not. Remains to actually parallelize out the programs. Am I being naive or is this trivial? Is there some reason why we cant just start a function running in a single thread, whilst running profiling, then after a while we check which bits of the function are taking time to run, and are parellizable, and we parallelize those out? Perhaps have a look at this new paper: Feedback directed implicit parallelism in Haskell http://research.microsoft.com/~tharris/papers/2007-fdip.pdf -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Small question
On Thu, Aug 09, 2007 at 11:09:36PM -0400, [EMAIL PROTECTED] wrote: Quoting Stefan O'Rear [EMAIL PROTECTED]: In general, GHC doesn't do unboxing. Instead it has a simpler and more general approach, [...] I'm not convinced that the phrase more general is appropriate here. :-) Not sure where that came from; my filters are usually better than that :) As far as actual heap usage goes, GHC creates single static values for all 0-argument constructors; so all Bool WHNFs are one of two addresses, one for True and one for False. And, of course, if it's a strict argument, then the values stored are ALWAYS one of two possibilities. So as a matter of curiosity, would there be any advantage at all for unboxing enumeration types? (Apart from, I suppose, the possibility of using fewer than 32/64 bits to store a flag.) That was actually described in the first paper on first-class unboxed types. The paper described a general mechanism for declaring user-defined unboxed types and procedures for unboxing any ADT. No idea if it was ever implemented, though. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Small question
Hello John, Friday, August 10, 2007, 5:15:56 AM, you wrote: data Quad = BL | BR | TL | TR under jhc (and probably ghc at some point in the future) there is another very strong advantage to the second one, since it is an enumerated type, internally it can be represented by a simple unboxed byte that takes on a value of 0,1,2,or 3, which is a very enabling optimization, especially in the 'if' case in your code. it was implemented and merged to ghc HEAD ~1 month ago -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Typeclasses and implicit parameters
{-# OPTIONS -fglasgow-exts #-}
-- G'day everyone.
-- This is okay.
f1 :: (?foo :: String) = String
f1 = ?foo
-- So is this.
f2 :: (Show a, ?foo :: a) = a - String
f2 _ = show ?foo
-- Hugs allows this. GHC rejects it on the grounds that a is unused
-- on the right-hand side of the (=). I think this is arguably a bug
-- in GHC.
f3 :: (Show a, ?foo :: a) = String
f3 = show ?foo
-- GHC rejects this. Hugs compiles it, but I can't call it as
-- let ?foo = Hello in show Foo
--
-- Is there a good reason to disallow this?
data Foo = Foo
instance (?foo :: String) = Show Foo where
showsPrec _ Foo = showString ?foo . showString Foo
-- Cheers,
-- Andrew Bromage
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
