Re: [Haskell-cafe] New slogan for haskell.org
On Tue, 2007-11-27 at 23:11 -0500, Sterling Clover wrote: On Nov 27, 2007, at 11:34 AM, David Fox wrote: In that case we need to identify all the groups that the front page is serving and create separate areas for each, all above the fold as it were: 1. A sales pitch for new users. I see how much this disturbs some people, but maybe it is better to think of it as a quick introduction with a focus on benefits and comparisons to things which are already familiar. This is what one needs when one is in the stage of deciding whether to pursue something. There should also be a bit of discussion on *who* folks want the pitch to attract. As I see it, there are a number of categories here as well, and maybe even links to breakout pages for different demographics could be in order. I expect any number of us have had the experience where we want to use Haskell on a project, and need to convince our project manager / other form of immediate supervisor / boss / whatever that this is a good idea -- so there needs to be a pitch geared to benefits that they'll latch on to -- reliability, clarity, maintainability, provability, speed, momentum and staying power, library support, etc. Then there should be a different sort of pitch for casual new users that want to get their feet wet in different sorts of programming concepts. Finally, there should be a pitch for people that really know what's up, so to speak, are looking for a place to expend some of their significant talent, and are going to be attracted by some of the mathematically cooler/geekier/blow-your-mind aspects of Haskell, the power of its type system, etc. Mindshare among these folks is key for more people that want to hack on getting Cabal to just work, adopt the maintenance of libraries and come up with new and useful proposals therein, get involved with compiler development (or at least generate really useful test-cases and bug reports), and all that. Sorry, but are you talking of *one* homepage? This can all go into own wiki pages that are aimed at certain audiences, but this really can't all fit on the front page. Go ahead, write them! I'm all for it, but at the moment I'm looking for concrete improvements of my suggested phrasing. Any ideas how we could succinctly address those demographics in that short paragraph? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] A tale of three shootout entries
| If, after investigation (and perhaps checking with Don) you find that adding bangs makes your program go | slower, even though the function is in fact strict (otherwise it might go slower because it's just doing more | work!) then I'd love to see a test case. | | I wonder if this could be related to what I observed with AVL trees and | mentioned a while back (using a strict data type is slower than using | explicit seqs to get the same strictness). Could indeed be. That message is still in my performance-tuning pile; it's not forgotten, just buried. But the more evidence, the stronger the incentive to investigate. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] A tale of three shootout entries
| There may well have been changes to the strictness analyser that make | some of the bangs (or most) unnecessary now. Also, its very likely | I didn't check all combinations of strict and lazy arguments for the | optimal evaluation strategy :) | | If it seems to be running consitently faster (and producing better Core | code), by all means submit. I don't think this is a ghc bug or anything | like that though: just overuse of bangs, leading to unnecessary work. You might think that unnecessary bangs shouldn't lead to unnecessary work -- if GHC knows it's strict *and* you bang the argument, it should still only be evaluated once. But it can happen. Consider f !xs = length xs Even though 'length' will evaluate its argument, f nevertheless evaluates it too. Bangs say evaluate it now, like seq, because we may be trying to control space usage. In this particular case it's silly, because the *first* thing length does is evaluate its argument, but that's not true of every strict function. That's why I say it'd be good to have well-characterised examples. It *may* be something like what I describe. Or it may be a silly omission somewhere. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Collections library
Ben Franksen [EMAIL PROTECTED] writes: PS (completely off-topic, sorry): I've been using the collections library throughout the project I must say it is a lot nicer to work with I tried to Google for this, and ended up at http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework The only link that seems to work is the one that is marked as outdated. I've replaced them with a link to Hackage, but somebody who knows more about this might want to recheck the facts on the page. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of three shootout entries
Simon Peyton-Jones wrote: You might think that unnecessary bangs shouldn't lead to unnecessary work -- if GHC knows it's strict *and* you bang the argument, it should still only be evaluated once. But it can happen. Consider f !xs = length xs Even though 'length' will evaluate its argument, f nevertheless evaluates it too. I'm replying to a guru here, so I should keep my voice low; but I'd like to point out what might result in a misunderstanding for other readers of haskell-cafe. Contrasting both the bang pattern and the usage of length causing f to be strict, one might suppose that a bang pattern, when used on a list, will cause it to be evaluated in the same way as length does. However, the *first* thing length does is evaluate its argument, and it will furthermore evaluate the argument list recursively, as much as is necessary to determine its length. On the other hand, given g !xs = () evaluating g [0..] will terminate, because g is only strict in the constructor of its argument, which is (:). The list data type itself, however, is non-strict. Kalman -- Free pop3 email with a spam filter. http://www.bluebottle.com/tag/5 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Collections library
Ketil Malde wrote: Ben Franksen [EMAIL PROTECTED] writes: PS (completely off-topic, sorry): I've been using the collections library throughout the project I must say it is a lot nicer to work with I tried to Google for this, and ended up at http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework The only link that seems to work is the one that is marked as outdated. I've replaced them with a link to Hackage, but somebody who knows more about this might want to recheck the facts on the page. It currently lives here as a darcs repo.. http://code.haskell.org/collections/collections-ghc6.8 ..and is in the process of being 6.8ified and split up into separate smaller packages for hackage. I think one of the problems with it as one package (apart from it's size) is that different bits of it were in different states of real world readiness. Some of it quite stable (e.g. all the AVL tree stuff and Data.Map/Set clones) and some was still actively being worked on (the Data.Trie.General stuff) and this kinda stopped a stable hackage package for everything. I recently withdrew from this project and offered up the libs I'd been working on as they are for a new owner. Didn't get any takers though (no surprises there!). I've always found the lack of apparent interest in all this somewhat puzzling myself. It's not as if there's no latent demand for efficient collections. (Data.Map is probably the most regularly whined about of all the standard libs.) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pb building HDBC-sqlite3
Hello still, trying to use a database with ghc 6.8.1 - patience running low however :) I now have troubles installing HDBC-sqlite3 the build fails like so : $ runhaskell Setup.lhs build Preprocessing library HDBC-sqlite3-1.1.3.0... Utils.hsc:31:33: error: hdbc-sqlite3-helper.h: No such file or directory Utils.hsc: In function ‘main’: Utils.hsc:70:0: error: parse error before ‘finalizeonce’ compiling dist/build/Database/HDBC/Sqlite3/Utils_hsc_make.c failed command was: /usr/local/bin/ghc -c -package base-3.0.0.0 -package mtl-1.1.0.0 -package HDBC-1.1.3 -I. dist/build/Database/HDBC/Sqlite3/ Utils_hsc_make.c -o dist/build/Database/HDBC/Sqlite3/Utils_hsc_make.o the hdbc-sqlite3-helper.h file is nowhere to be found on my system should it be part of the package ? Thanks M ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Downside of -fglasgow-extensions
On Wed, 28 Nov 2007, manu wrote:
Hello,
I'm trying to build diverse packages from Hackage with ghc 6.8.1,
they usually fail to build because of missing language extensions.
Sometimes I am unable to determine the proper name of the extension
missing in .cabal
I tend to slap {- #OPTIONS -fglasgow-exts #-} at the top of the
troublesome file.
It works, but out of curiosity, what is the downside of such an
approach ? (bigger executables ?)
Mistakes can slip through more easily. Things that aren't allowed in
Haskell 98 are now accepted, although they might just be mistakes. E.g.
when switched on glasgow-exts the compiler accepts
type List = []
Although not wrong, it is not Haskell 98 and can be easily replaced by
type List a = [a]
I wrote definitions like the former one several times, before becoming
aware that they use a language extension.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-install
On Tue, 2007-11-27 at 18:02 -0800, Don Stewart wrote: ben.franksen: Just thought I install the latest version (0.4.0) from hackage and test it. Build and install went fine, but then it gets strange: cabal: dist/Conftest.c: openFile: does not exist (No such file or directory) This one is due to having an out of date cabal. Upgrade to darcs cabal, then rebuild cabal-install, and things should go fine. Yes, this was rather unfortunate. A fix for something else that we put into Cabal at the last minute ended up breaking cabal-install. As Don says, it's fixed in the darcs version of Cabal (HEAD and 1.2 branch) which will also be released with ghc-6.8.2 (or possibly earlier if that looks like it's going to take a while). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings and utf-8
On Tue, 2007-11-27 at 18:38 +, Paul Johnson wrote: Brandon S. Allbery KF8NH wrote: However, the IO system truncates [characters] to 8 bits. Should this be considered a bug? A design problem. I presume that its because stdio.h was defined in the days of ASCII-only strings, and the functions in System.IO are defined in terms of stdio.h. But does this need to be the case in the future? When it's phrased as truncates to 8 bits it sounds so simple, surely all we need to do is not truncate to 8 bits right? The problem is, what encoding should it pick? UTF8, 16, 32, EBDIC? How would people specify that they really want to use a binary file. Whatever we change it'll break programs that use the existing meanings. One sensible suggestion many people have made is that H98 file IO should use the locale encoding and do Unicode/String - locale conversion. So that'd all be text files. Then openBinaryFile would be used for binary files. Of course then we'd need control over setting the encoding and what to do on encountering encoding errors. IMHO, someone should make a full proposal by implementing an alternative System.IO library that deals with all these encoding issues and implements H98 IO in terms of that. It doesn't have to be fast initially, it just has to get the API right and not design the API so as to exclude the possibility of a fast implementation later. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: is there a more concise way to generate helper functions for a datatype built on records?
apfelmus schrieb:
Benedikt Huber wrote:
So, the Ref deriviation is really nice for sequential updates;
parallel updates on the other hand need some work.
..
While the select part of the Ref is expressed using , I don't know
how the
parallel update can be expressed in terms of combinators. Any hints ?
You can't do that, and for good reason! While
players :: Lens Game (Player,Player)
is entirely fine since Game ~ (Player,Player,Object2D), there cannot be
a general parallel combinator
() :: Lens a b - Lens a c - Lens a (b,c)
Thanks for the nice overview.
I see there can't be a general purpose combinator () for lenses.
One could still define a helper function though:
combineDisjoint :: Lens a b - Lens a c - Lens a (b,c)
combineDisjoint l1 l2 = Lens $ select update
where
select = (fst . focus l1) (fst . focus l2)
update cx (a,b) = flip (snd . focus l2) b $ (snd . focus l1) cx a
which performs the first update using the initial context, and the
second one using the updated context. Just to have a simple way of
defining lensPlayers in term of lensPlayer1 `combineDisjoint`
lensPlayer2. While it is not a (general purpose) combinator, it is still
helpfull for combining lenses focusing on fields of a record.
--
I just want to rephrase my question about paralell updates; it has more
to do with records updates than with References / Lenses, though:
Suppose we have a record
data R = R { a:: A, b :: B, c :: C } deriving (Show {-! Ref !-})
and update functions
fa :: a - a, fb :: b - b, fc :: c - c
Now the standard way to perform the update on R would be
updateR = \r@(R {a=a,b=b,c=c}) - r { a = fa a,b = fb b,c = fc c }
which is 'a little bit' cumbersome.
With update deriviations (like Update using DrIFT), references (Ref
using Data.Derive) or lenses it is easy to perform the update
sequentially (using DrIFT style for simplicity):
updateR' = a_u fa . b_u fb . c_u fc
But this corresponds to
updateR' = (\f r - r { a = f (a r) }) fa .
(\f r - r { b = f (b r) }) fb .
(\f r - r { c = f (c r) }) fc
which (in some way) is not 'the same' as updateR.
First, I (uneducatedly) guess that the record updates cannot be
'executed' in paralell, i.e. the record has to be deconstructed and
build up again three times.
And second, neither the types of the updates (e.g. a_u fa :: R - R) nor
the structure of updateR' (composing R-R functions) do reflect the fact
that actually disjoint fields of the record are updated.
Now I know there are great record proposals (which extend the haskell
language or use some type hackery), but I wondered if there is also a
solution which can be used right now and which works fine with the
standard record types.
I'll give a naive ad-hoc example to illustrate the idea.
One could automatically derive the following data type and the
associated functions for R:
data R_upd = R_upd { updA :: A - A, updB :: B - B, updC :: C - C }
rUpd = R_upd id id id
updR :: R_upd - R - R
updR rupd r@(R { a=a,b=b,c=c }) = r
{ a = (updA rupd a),
b = (updB rupd b),
c = (updC rupd c) }
which would allow to write things like
updGame $
gameUpdate { updPlayer1 = increaseScore, updPlayer2 = decreaseScore })
Though simple, I hope it is possible to understand the idea (I know
there is a lot of namespace pollution).
And of course, someone has thought of something much more sophistacted
already :)
What are the drawbacks of such an approach ?
thanks,
benedikt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pb builind hdbc-sqlite3 (suite)
Hello, Still trying to build hdbc-sqlite3 it appears that the hdbc-sqlite3 package on Hackage is missing the C header file It is included with the hdbc-sqlite3 package found at http:// software.complete.org/hdbc-sqlite3/downloads however. Now I have another pb : Building HDBC-sqlite3-1.1.3.0... [3 of 7] Compiling Database.HDBC.Sqlite3.Utils ( dist/build/Database/ HDBC/Sqlite3/Utils.hs, dist/build/Database/HDBC/Sqlite3/Utils.o ) Database/HDBC/Sqlite3/Utils.hsc:74:8: parse error on input `import' manu:/Volumes/data/Downloads/HDBC/hdbc-sqlite3 manu$ line 74 is : foreign import ccall unsafe sqlite3.h sqlite3_errmsg I've checked and I have a sqlite3.h file in /usr/include what is this parse error on input `import' about ??? Thanks M___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Waiting for thread to finish
A safer gimmick...
Ben Franksen wrote:
tickWhileDoing :: String - IO a - IO a
tickWhileDoing msg act = do
hPutStr stderr msg hPutChar stderr ' ' hFlush stderr
start_time - getCPUTime
tickerId - forkIO ticker
... an async exception here will leave the ticker runnning
res - act `finally` killThread tickerId
The best way to make this safe that I know of is:
res - block $ do
tickerId - forkIO ticker
unblock act `finally` killThread tickerId
stop_time - getCPUTime
let time_diff = realToFrac (stop_time - start_time) / 1e12
hPutStrLn stderr $ done (took us ++ show time_diff ++ seconds)
return res
where
ticker = do
hPutChar stderr '.' hFlush stderr
threadDelay 10 {-microsec-}
ticker
I think nobody in his right mind would even try to do something like that in
C or Perl or whatever, at least not if it wasn't strictly a requirement and
correct operation is important (the script gets executed as part of our
build process and a subtle concurrency bug could lead to a wrong
configuration for the target control system). In Haskell it was so easy to
do that I just couldn't resist.
Cheers
Ben
PS (completely off-topic, sorry): I've been using the collections library
throughout the project I must say it is a lot nicer to work with than the
base library mumble-jumble of duplicate interfaces, qualified imports and
whatnot. The only disadvantages are that the API is not yet as complete as
e.g. Data.Map, and that I have to manually hide name-clashing Prelude
functions in almost every module. Many thanks to Jean-Philippe Bernardy for
pioneering this work.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pb builind hdbc-sqlite3 (the end)
Hello
I should think a bit before posting to the list, sorry for the
pollution !
this error :
Database/HDBC/Sqlite3/Utils.hsc:74:8: parse error on input `import'
manu:/Volumes/data/Downloads/HDBC/hdbc-sqlite3 manu$
can be avoided by adding ForeignFunctionInterface to the extensions
in the .cabal file
I also had to add EmptyDataDecls to the extensions
and since adding PatternSignatures cause a parse error (see http://
hackage.haskell.org/trac/hackage/attachment/ticket/160/cabal-1.2.0-
extensions.patch)
I added this pragma {-# LANGUAGE PatternSignatures #-}
at the top of Statement.hsc and Connection.hs
It did build ! Victory !
M
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
Sebastian Sylvan: primes :: [Integer] primes = 2 : filter (null . primeFactors) [3,5..] primeFactors :: Integer- [Integer] primeFactors n = factor n primes where factor m (p:ps) | p*p m= [] | m `mod` p == 0 = p : factor (m `div` p) (p:ps) | otherwise = factor m ps Your definition gives a strange meaning to primeFactors. I'd want that for all n, product (primeFactors n) == n. I think this law holds for the code posted by Olivier. Of course I'd beautify his definition slightly by writing primes = 2 : filter isPrime [3,5..] isPrime = null . drop 1 . primeFactors primeFactors n | n = 2 = factor primes n factor pr@(p:ps) n | p*p n = [n] | r == 0= p : factor pr q | otherwise = factor ps n where (q,r) = quotRem n p Kalman -- Get a free email account with anti spam protection. http://www.bluebottle.com/tag/2 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
On Nov 28, 2007 12:12 PM, Kalman Noel [EMAIL PROTECTED] wrote: Sebastian Sylvan: primes :: [Integer] primes = 2 : filter (null . primeFactors) [3,5..] primeFactors :: Integer- [Integer] primeFactors n = factor n primes where factor m (p:ps) | p*p m= [] | m `mod` p == 0 = p : factor (m `div` p) (p:ps) | otherwise = factor m ps Your definition gives a strange meaning to primeFactors. I'd want that for all n, product (primeFactors n) == n. I think this law holds for the code posted by Olivier. Yes you're right. That is property should clearly hold. -- 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] Why aren't Float and Double Bounded?
Josh Lee wrote: On Tue, 27 Nov 2007 14:41:59 -0500 Isaac Dupree [EMAIL PROTECTED] wrote: Henning Thielemann wrote: On Mon, 26 Nov 2007, Jason Dusek wrote: Among numeric types, it seems that only integer types are Bounded. Maybe because IEEE format supports Infinity? therefore, maxBound is Infinity and minBound negative infinity? Using Infinity would go against the meaning of Enum. In the Double/Float types, succ and pred mean add/subtract 1.0, as opposed to the unit of least precision. In fact, succ and pred lose meaning once the precision of the floats exceeds a certain value. That's not the meaning of Enum. That's brokenness :) It's there so that [1..10] :: [Double] works, but it's a horrible horrible thing. The overloaded [a..b] notation should not be in Enum but some other class (I suggest ICanHazInturval as the class name). Oh well. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: Waiting for thread to finish
On 28/11/2007, Ben Franksen [EMAIL PROTECTED] wrote: It was fun, too. For instance, the OP's question reminded me of a little generic wrapper I wrote -- more or less for my own amusement -- during the course of this project. It outputs dots during an operation that might take a little longer to finish (a database query in my case)... just so the user doesn't get nervous ;-) And because I enjoyed it so much (and to show off) I threw in the timing measurement... [...] I think nobody in his right mind would even try to do something like that in C or Perl or whatever, at least not if it wasn't strictly a requirement and correct operation is important (the script gets executed as part of our build process and a subtle concurrency bug could lead to a wrong configuration for the target control system). In Haskell it was so easy to do that I just couldn't resist. That's a neat idea. Just (a) because I like the idea, and (b) because I'm contrary :-) I coded up the equivalent in Python. It also looks beautifully clean: from __future__ import with_statement import threading import sys # Implementation of Ticker class class Ticker(threading.Thread): def __init__(self, msg): threading.Thread.__init__(self) self.msg = msg self.event = threading.Event() def __enter__(self): self.start() def __exit__(self, ex_type, ex_value, ex_traceback): self.event.set() self.join() def run(self): sys.stdout.write(self.msg) while not self.event.isSet(): sys.stdout.write(.) sys.stdout.flush() self.event.wait(1) # Here's how we use it... if __name__ == '__main__': import time with Ticker(A test): time.sleep(10) with Ticker(Second test): time.sleep(5) raise Exception(Bang!) Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RFI: HDBC-1.1.3 build error
ubuntu gutsy ghc-6.8.1 HDBC-1.1.3$ runghc Setup.lhs build Preprocessing library HDBC-1.1.3... Building HDBC-1.1.3... [3 of 6] Compiling Database.HDBC.Types ( Database/HDBC/Types.hs, dist/build/Database/HDBC/Types.o ) Database/HDBC/Types.hs:208:0: Illegal polymorphic or qualified type: forall conn. (IConnection conn) = conn - b In the type signature for `withWConn': withWConn :: forall b. ConnWrapper - (forall conn. (IConnection conn) = conn - b) - b TIA ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFI: HDBC-1.1.3 build error
put
{-# OPTIONS_GHC -fglasgow-exts #-}
at the the top of the file that complains.
Jim Stuttard [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/28/2007 08:06 AM
Please respond to
[EMAIL PROTECTED]
To
Haskell-Cafe@haskell.org
cc
Subject
[Haskell-cafe] RFI: HDBC-1.1.3 build error
ubuntu gutsy
ghc-6.8.1
HDBC-1.1.3$ runghc Setup.lhs build
Preprocessing library HDBC-1.1.3...
Building HDBC-1.1.3...
[3 of 6] Compiling Database.HDBC.Types ( Database/HDBC/Types.hs,
dist/build/Database/HDBC/Types.o )
Database/HDBC/Types.hs:208:0:
Illegal polymorphic or qualified type: forall conn.
(IConnection conn) =
conn - b
In the type signature for `withWConn':
withWConn :: forall b.
ConnWrapper - (forall conn. (IConnection conn) =
conn - b) - b
TIA
___
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] New slogan for haskell.org
On Wed, Nov 28, 2007 at 09:27:39AM +0100, Thomas Schilling wrote: Sorry, but are you talking of *one* homepage? This can all go into own wiki pages that are aimed at certain audiences, but this really can't all fit on the front page. I'm reminded of http://www.shiregames.com/shiregames/ We could do something similar, with a column for When you hear programming, if you immediately think of C or perl, then please read the following: and maybe ML or lisp for the other column. I don't know if it's a good idea or not, just something to think about. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Downside of -fglasgow-extensions
On Wed, Nov 28, 2007 at 12:08:30PM +0100, Henning Thielemann wrote: type List = [] Although not wrong, it is not Haskell 98 It's valid Haskell 98 as far as I know. Advantages of listing the extensions used are * Cabal knows whether hugs, for example, can compile the package * Assuming hugs can compile it, you don't have to have give a different flag to enable extensions in hugs * It allows us to see, by querying hackage, which extensions are used a lot and which are not used at all. Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On 28 Nov 2007, at 13:41, Ian Lynagh wrote: On Wed, Nov 28, 2007 at 09:27:39AM +0100, Thomas Schilling wrote: Sorry, but are you talking of *one* homepage? This can all go into own wiki pages that are aimed at certain audiences, but this really can't all fit on the front page. I'm reminded of http://www.shiregames.com/shiregames/ We could do something similar, with a column for When you hear programming, if you immediately think of C or perl, then please read the following: and maybe ML or lisp for the other column. I don't know if it's a good idea or not, just something to think about. That's an excellent idea as far as I'm concerned. We get the advertising pitch to the uninitiated, and the old hands keep their navigation routes to the important documentation. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Collections library
[snip] I recently withdrew from this project and offered up the libs I'd been working on as they are for a new owner. Didn't get any takers though (no surprises there!). I've always found the lack of apparent interest in all this somewhat puzzling myself. It's not as if there's no latent demand for efficient collections. (Data.Map is probably the most regularly whined about of all the standard libs.) FWIW, I find the same phenomenon with Edison. I get very little feedback about it positive or negative; I really have no idea how many people are using it. I guess people are more willing to roll their own data structures or use the standard libs. It might be from a desire to limit dependencies. If that's the case, perhaps continuing cabal developments will change that. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Collections library
On Wed, 28 Nov 2007, Robert Dockins wrote: FWIW, I find the same phenomenon with Edison. I get very little feedback about it positive or negative; I really have no idea how many people are using it. I guess people are more willing to roll their own data structures or use the standard libs. It might be from a desire to limit dependencies. For me this is a strong reason, yes. It's not only the immediate dependency, but the dependent library might rely on other libraries or compiler features and thus decreases portability. If that's the case, perhaps continuing cabal developments will change that. I hope that this will solve the problem. Since I recently got to know that Edison contains EnumSet, which I think is useful for many FFIs, I will certainly use Edison in future. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
apfelmus wrote:
Henning Thielemann wrote:
apfelmus wrote:
Back then, I was given the task to calculate some sequence
of numbers which I did in one page of C code. So far so good, but when I
asked the task assigner about his solution, he responded: Ah, this
problem, that's 1 line in Haskell. Well, 2 lines if the terminal is too
small.
Ah, a Haskell code contribution to the Encyclopedia of Integer Sequences?
The task was just for fun, but it's sequence A05.
import Data.Set
xs = let f x m = x: let y = x `div` 2
in f (if member y m then 3*x else y) (insert x m)
in f 1 (singleton 0)
As said, it's two lines if the terminal is too small :)
I can't see how it could be one page of C unless the page is 10 lines
long ;-) The following code is the direct translation of your Haskell
code (except that it prints the result instead of building a list).
a+, ld.
#include stdio.h
#include intset.h
void f(int x, intset s) {
printf(%d, , x);
f (intset_elem(s, x/2) ? 3*x : x/2, intset_put(s, x));
}
int main(void) {
f (1, intset_put(intset_new(), 0));
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
On Nov 28, 2007 6:16 PM, Laurent Deniau [EMAIL PROTECTED] wrote: I can't see how it could be one page of C unless the page is 10 lines long ;-) The following code is the direct translation of your Haskell code (except that it prints the result instead of building a list). a+, ld. #include stdio.h #include intset.h Which C standard defines intset.h? Juanma ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Parsing unstructured data
Hi all, This e-mail may be a bit off topic. My question is more about methods and algorithms than Haskell. I'm looking for links to methods or tools for parsing unstructured data. I'm currently working on data cleaning of a Customer Addresses database. Addresses are stored as 3 lines of text without any structure and people made used lots of imagination to create the data (20 years of data using no rules at all). Postal code, street, city, state, region, country and other details as suite, building, dock, doors, PO box, etc... are all stored in free form in those 3 lines. I already wrote a haskell program to do the job. It correctly parses about 2/3 addresses and parses much of the rest but with unrecognized parts left. The current program works by trying to recognize words used to tag parts like STE, SUITE, BLDG, street words (STR, AVE, CIRCLE, etc...) and countries from a list (including typos). It uses regular expressions to recognize variation of those words, lookup tables for countries, street words, regular expression rules for postal codes, etc... The most difficult task is splitting the address parts. There is no clearly defined separator for the fields. It can be dot, space, comma, dash, slash, or anything you can imagine using as a separator and this separator can of course also be found inside an address part. In the current application when part of an address is recognized it will not be parsed again by the other rules. A system trying all rules and tagging them with probabilities would probably give better results. Any link to tools or methods that could help me in that task would be greatly appreciated. I already searched for fuzzy, probabilistic or statistical parsing but without much success. Thanks, Olivier. PS: just in case someone's interested I attached the code and partial data to this e-mail. parseaddresses.tar.gz Description: GNU Zip compressed data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell and DB : giving up
Hello I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting) Well, I am giving up ! I seriously regret replacing ghc-6.6 with ghc-6.8, I didn't expect that building packages would be so ... unsucessfull and time-wasting. I just thought I'd let you know what's in store for PHP-style-users- like-me who want to use a database with ghc-6.8.1 at the moment, the hurdle is high ! I hope these packages will be fixed soon (I can't figure how to fix them myself obviously). And now I'm going to stay away from my computer for a while :) cheerio M ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing unstructured data
On 11/28/07, Hans van Thiel [EMAIL PROTECTED] wrote: Have you looked at the Java Rule Engine (I believe JSR 94) and in particular Jess? http://herzberg.ca.sandia.gov/ I have no experience with it myself, though, just heard of it. Regards, Hans van Thiel Hi Hans, Never heard of that tool but it looks interesting. I will definitely give it a try. Thanks for the link, Olivier. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and DB : giving up
emmanuel.delaborde: Hello I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting) Well, I am giving up ! I seriously regret replacing ghc-6.6 with ghc-6.8, I didn't expect that building packages would be so ... unsucessfull and time-wasting. I just thought I'd let you know what's in store for PHP-style-users- like-me who want to use a database with ghc-6.8.1 at the moment, the hurdle is high ! I hope these packages will be fixed soon (I can't figure how to fix them myself obviously). And now I'm going to stay away from my computer for a while :) It was HaskellDB in particular that you tried? If so, please report this to the maintainer. And it reminds me to release the galois sqlite3 bindings, which do happily work with 6.8. Surely one of the other 15 haskell db bindings would also work. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Downside of -fglasgow-extensions
emmanuel.delaborde:
Hello,
I'm trying to build diverse packages from Hackage with ghc 6.8.1,
they usually fail to build because of missing language extensions.
Sometimes I am unable to determine the proper name of the extension
missing in .cabal
I tend to slap {- #OPTIONS -fglasgow-exts #-} at the top of the
troublesome file.
It works, but out of curiosity, what is the downside of such an
approach ? (bigger executables ?)
Can you list which packages failed to build out of the box?
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing unstructured data
On Wed, 2007-11-28 at 12:58 -0500, Olivier Boudry wrote: Hi all, This e-mail may be a bit off topic. My question is more about methods and algorithms than Haskell. I'm looking for links to methods or tools for parsing unstructured data. I'm currently working on data cleaning of a Customer Addresses database. Addresses are stored as 3 lines of text without any structure and people made used lots of imagination to create the data (20 years of data using no rules at all). Postal code, street, city, state, region, country and other details as suite, building, dock, doors, PO box, etc... are all stored in free form in those 3 lines. I already wrote a haskell program to do the job. It correctly parses about 2/3 addresses and parses much of the rest but with unrecognized parts left. The current program works by trying to recognize words used to tag parts like STE, SUITE, BLDG, street words (STR, AVE, CIRCLE, etc...) and countries from a list (including typos). It uses regular expressions to recognize variation of those words, lookup tables for countries, street words, regular expression rules for postal codes, etc... The most difficult task is splitting the address parts. There is no clearly defined separator for the fields. It can be dot, space, comma, dash, slash, or anything you can imagine using as a separator and this separator can of course also be found inside an address part. In the current application when part of an address is recognized it will not be parsed again by the other rules. A system trying all rules and tagging them with probabilities would probably give better results. Have you looked at the Java Rule Engine (I believe JSR 94) and in particular Jess? http://herzberg.ca.sandia.gov/ I have no experience with it myself, though, just heard of it. Regards, Hans van Thiel Any link to tools or methods that could help me in that task would be greatly appreciated. I already searched for fuzzy, probabilistic or statistical parsing but without much success. Thanks, Olivier. PS: just in case someone's interested I attached the code and partial data to this e-mail. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] nbody (my own attempt) and performance problems
Just out of curiosity... --some getter functions pVel !(_,vel,_) = vel pPos !(pos,_,_) = pos pMass !(!_,!_,!mass) = mass What does the !(...) buy you? I thought tuples were already strict by default in patterns (you'd need ~(...) to make them irrefutable), so isn't the above equivalent to: --some getter functions pVel (_,vel,_) = vel pPos (pos,_,_) = pos pMass (!_,!_,!mass) = mass And why in any case are the tuple components for pMass strict but for pVel and pPos non-strict? Is is that mass is always used but position and velocity are not? Ryan Dickie wrote: I sat down tonight and did tons of good learning (which was my goal). Yes, the variable names in the unrolling is a little ugly but it helps to read the C++ version for context. There are two for loops (advN is each inner one unrolled). the other function names match the C++ version. It was my goal to implement an unrolled version of that. Fortunately, my performance is excellent now. It is only 4x slower than the C++ version and 2x slower than the Haskell one listed (which uses pointer trickery). I am sure there could be more done but I am at my limit of comprehension. But if I may guess, I would say that any speed issues now are related to a lack of in place updating for variables and structures. I'd also like to thank everyone for their help so far. I have attached my latest version. --ryan On Nov 27, 2007 7:14 PM, Sterling Clover [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The first step would be profiling -- i.e. compiling with -prof -auto- all to tag each function as a cost center, then running with +RTS -p to generate a cost profile. The problem here is you've got massive amounts of unrolling done already, so it's sort of hard to figure out what's doing what, and the names you've given the unrolled functions are... less than helpful. (first rule of optimization: optimize later.) The use of tuples shouldn't be a problem per se in terms of performance, but it really hurts readability to lack clear type signatures and types. You'd probably be better off constructing a vector data type as does the current Haskell entry -- and by forcing it to be strict and unboxed (you have nearly no strictness annotations I note -- and recall that $! only evaluates its argument to weak head normal form, which means that you're just checking if the top-level constructor is _|_) you'll probably get better performance to boot. In any case, declaring type aliases for the various units you're using would also help readability quite a bit. --S On Nov 27, 2007, at 5:41 PM, Ryan Dickie wrote: I thought it would be a nice exercise (and a good learning experience) to try and solve the nbody problem from the debian language shootout. Unfortunately, my code sucks. There is a massive space leak and performance is even worse. On the bright side, my implementation is purely functional. My twist: I manually unrolled a few loops from the C++ version. I believe that most of my performance problems stem from my abuse of tuple. The bodies are passed as a tuple of planets, a planet is a tuple of (position, velocity, mass) and the vectors position and velocity are also tuples of type double. My lame justification for that is to make it nice and handy to pass data around. Any tips would be greatly appreciated. --ryan nbody3.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and DB : giving up
On Nov 28, 2007 1:11 PM, manu [EMAIL PROTECTED] wrote: Hello I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting) Well, I am giving up ! I seriously regret replacing ghc-6.6 with ghc-6.8, I didn't expect that building packages would be so ... unsucessfull and time-wasting. I just thought I'd let you know what's in store for PHP-style-users- like-me who want to use a database with ghc-6.8.1 at the moment, the hurdle is high ! I hope these packages will be fixed soon (I can't figure how to fix them myself obviously). And now I'm going to stay away from my computer for a while :) cheerio M Hi Manu, I built HSQL MySQL on Windows using GHC-6.8.1. I had to replace the Setup.lhs file be able to build with Cabal-1.2.2.0 (I found a working one on the web) and had to modify the cabal file (build-depends list). If you're interested I attached a copy of the two files. HSQL also comes with a SQLite module but I didn't tried it. The problems I encountered when compiling using GHC 6.8.1 are almost always the same and are very well described in this document: http://haskell.org/haskellwiki/Upgrading_packages. Usually you just have to adapt the build-depends list and change the imports of Data.ByteString.Base which was split in Internal and Usafe. It sometimes requires some try/error iterations. Using this information I was able to build many modules on Win32 / GHC 6.8.1without problems (HTTP, HaXmL, polyparse, exif, gtk2hs, hxt, regex-pcre, compact-string). It can be more complicated when the package do not use a simple build script (as was the case for HSQL). Best regards, Olivier. HSQL-MySQL-6.8.1.tar.gz Description: GNU Zip compressed data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Strings and utf-8
(...) When it's phrased as truncates to 8 bits it sounds so simple, surely all we need to do is not truncate to 8 bits right? The problem is, what encoding should it pick? UTF8, 16, 32, EBDIC? (...) One sensible suggestion many people have made is that H98 file IO should use the locale encoding and do Unicode/String - locale conversion. (...) I'm really afraid of solutions where the behavior of your program changes with an environment variable that not everybody has configured properly, or even know to exist. Wouldn't it be sensible not to use the H98 file I/O operations at all anymore with binary files? A Char represents a Unicode code point value and is not the right data type to use to represent a byte from a binary stream. That seems nice, we would not have to create a wide char type just for Unicode. This topic made me search the net for that nice quote: Explanations exist: they have existed for all times, for there is always an easy solution to every problem — neat, plausible and wrong. (See: en.wikiquote.org/wiki/H._L._Mencken That guy has many quotes worth reading.) Strings as char lists is a very good example of that. It's simple and clean, but strings are not char lists in any reasonable sense. Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: cabal-install
On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote: Don Stewart wrote: ben.franksen: cabal: dist/Conftest.c: openFile: does not exist (No such file or directory) This one is due to having an out of date cabal. Upgrade to darcs cabal, then rebuild cabal-install, and things should go fine. Ok. So the package is broken in that it doesn't work with the advertised version of Cabal as stated on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install-0.4.0 See the line base (=2.02.2), Cabal (=1.2), filepath (=1.0), HTTP (=3000.03001.1), network, zlib (=0.3) Anyway, I'll follow your advice install latest cabal from darcs repo. (* looks for repo URL in Cabal home page; under Download, nothing, hmmm; ah it's under Source Code, right. Wait for darcs to finish getting...here we go *) [EMAIL PROTECTED]: .../software/haskell darcs get --partial http://darcs.haskell.org/cabal Copying patch 115 of 115... done! Applying patch 114 of 114... done. Finished getting. [EMAIL PROTECTED]: .../software/haskell cd cabal [EMAIL PROTECTED]: .../haskell/cabal runhaskell Setup.lhs configure Distribution/Simple/NHC.hs:77:1: lexical error at character 'i' Ups. Cheers Ben (feels like a real beta-tester now ;-) Well, Cabal cannot automatically compile itself with itself. Use: $ make ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: cabal-install
Don Stewart wrote: ben.franksen: cabal: dist/Conftest.c: openFile: does not exist (No such file or directory) This one is due to having an out of date cabal. Upgrade to darcs cabal, then rebuild cabal-install, and things should go fine. Ok. So the package is broken in that it doesn't work with the advertised version of Cabal as stated on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install-0.4.0 See the line base (=2.02.2), Cabal (=1.2), filepath (=1.0), HTTP (=3000.03001.1), network, zlib (=0.3) Anyway, I'll follow your advice install latest cabal from darcs repo. (* looks for repo URL in Cabal home page; under Download, nothing, hmmm; ah it's under Source Code, right. Wait for darcs to finish getting...here we go *) [EMAIL PROTECTED]: .../software/haskell darcs get --partial http://darcs.haskell.org/cabal Copying patch 115 of 115... done! Applying patch 114 of 114... done. Finished getting. [EMAIL PROTECTED]: .../software/haskell cd cabal [EMAIL PROTECTED]: .../haskell/cabal runhaskell Setup.lhs configure Distribution/Simple/NHC.hs:77:1: lexical error at character 'i' Ups. Cheers Ben (feels like a real beta-tester now ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] nbody (my own attempt) and performance problems
On Nov 28, 2007 11:18 AM, Dan Weston [EMAIL PROTECTED] wrote: Just out of curiosity... --some getter functions pVel !(_,vel,_) = vel pPos !(pos,_,_) = pos pMass !(!_,!_,!mass) = mass What does the !(...) buy you? I thought tuples were already strict by default in patterns (you'd need ~(...) to make them irrefutable), so isn't the above equivalent to: --some getter functions pVel (_,vel,_) = vel pPos (pos,_,_) = pos pMass (!_,!_,!mass) = mass Yes you are right. I did not need those extra ! in front of the tuples. And why in any case are the tuple components for pMass strict but for pVel and pPos non-strict? Is is that mass is always used but position and velocity are not? Without all three components of the tuple in pMass being !'d, I find a 2x slowdown. This include trying pMass (_,_,!mass), pMass(!_,_,!mass), and all other combinations. Why that happens.. I do not know. pMass is only used where its argument (the planet tuple) was defined strict like below. I would expect p1 to be fully evaluated before pMass p1 is ever called. offset_momentum (!p1,p2,p3,p4,p5) = ( pp1,p2,p3,p4,p5 ) where pp1 = ( pPos p1,ppvel,pMass p1 ) Ryan Dickie wrote: I sat down tonight and did tons of good learning (which was my goal). Yes, the variable names in the unrolling is a little ugly but it helps to read the C++ version for context. There are two for loops (advN is each inner one unrolled). the other function names match the C++ version. It was my goal to implement an unrolled version of that. Fortunately, my performance is excellent now. It is only 4x slower than the C++ version and 2x slower than the Haskell one listed (which uses pointer trickery). I am sure there could be more done but I am at my limit of comprehension. But if I may guess, I would say that any speed issues now are related to a lack of in place updating for variables and structures. I'd also like to thank everyone for their help so far. I have attached my latest version. --ryan On Nov 27, 2007 7:14 PM, Sterling Clover [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The first step would be profiling -- i.e. compiling with -prof -auto- all to tag each function as a cost center, then running with +RTS -p to generate a cost profile. The problem here is you've got massive amounts of unrolling done already, so it's sort of hard to figure out what's doing what, and the names you've given the unrolled functions are... less than helpful. (first rule of optimization: optimize later.) The use of tuples shouldn't be a problem per se in terms of performance, but it really hurts readability to lack clear type signatures and types. You'd probably be better off constructing a vector data type as does the current Haskell entry -- and by forcing it to be strict and unboxed (you have nearly no strictness annotations I note -- and recall that $! only evaluates its argument to weak head normal form, which means that you're just checking if the top-level constructor is _|_) you'll probably get better performance to boot. In any case, declaring type aliases for the various units you're using would also help readability quite a bit. --S On Nov 27, 2007, at 5:41 PM, Ryan Dickie wrote: I thought it would be a nice exercise (and a good learning experience) to try and solve the nbody problem from the debian language shootout. Unfortunately, my code sucks. There is a massive space leak and performance is even worse. On the bright side, my implementation is purely functional. My twist: I manually unrolled a few loops from the C++ version. I believe that most of my performance problems stem from my abuse of tuple. The bodies are passed as a tuple of planets, a planet is a tuple of (position, velocity, mass) and the vectors position and velocity are also tuples of type double. My lame justification for that is to make it nice and handy to pass data around. Any tips would be greatly appreciated. --ryan nbody3.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
I put up a draft page. Feel free to adjust it. http://haskell.org/haskellwiki/FrontpageDraft / Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 51, Issue 180
I'm trying to build diverse packages from Hackage with ghc 6.8.1,
they usually fail to build because of missing language extensions.
Sometimes I am unable to determine the proper name of the extension
missing in .cabal
I tend to slap {- #OPTIONS -fglasgow-exts #-} at the top of the
troublesome file.
It works, but out of curiosity, what is the downside of such an
approach ? (bigger executables ?)
Can you list which packages failed to build out of the box?
-- Don
Well I'd say none of the packages I've tried, build out of the box,
that include :
haskelldb
haskelldb-hdbc
haskelldb-hdbc-sqlite3
HDBC
HDBC-sqlite3
Agreed some of these compile right after tweeking the build-depends:
and extensions: lines in the .cabal file
(apart from the pesky PatternSignatures which require a LANGUAGE
pragma in the source file)
haskelldb-hdbc-sqlite3 is the one that I couldn't get past...
I didn't bother with hsql-mysql-1.7 since Duncan Coutts mentioned it
required significant work (and I cannot do much)
Manu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Nov 28, 2007 8:54 PM, Thomas Schilling [EMAIL PROTECTED] wrote: I put up a draft page. Feel free to adjust it. http://haskell.org/haskellwiki/FrontpageDraft Perhaps slightly OT, but while we're discussing the front page. Is there any way of getting rid of the numbering on the front page? It annoys me! -- 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] New slogan for haskell.org
On Wed, 2007-11-28 at 21:02 +, Sebastian Sylvan wrote: On Nov 28, 2007 8:54 PM, Thomas Schilling [EMAIL PROTECTED] wrote: I put up a draft page. Feel free to adjust it. http://haskell.org/haskellwiki/FrontpageDraft Perhaps slightly OT, but while we're discussing the front page. Is there any way of getting rid of the numbering on the front page? It annoys me! You can turn it off in your preferences under Misc. I guess someone with admin privileges could change the global defaults. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Nov 28, 2007 9:30 PM, Thomas Schilling [EMAIL PROTECTED] wrote: On Wed, 2007-11-28 at 21:02 +, Sebastian Sylvan wrote: On Nov 28, 2007 8:54 PM, Thomas Schilling [EMAIL PROTECTED] wrote: I put up a draft page. Feel free to adjust it. http://haskell.org/haskellwiki/FrontpageDraft Perhaps slightly OT, but while we're discussing the front page. Is there any way of getting rid of the numbering on the front page? It annoys me! You can turn it off in your preferences under Misc. I guess someone with admin privileges could change the global defaults. I like it for articles, but the front page has a very deliberate layout so that most of the important information can be accessed quickly, so the arbitrary numbering is distracting. So really I'd like the front page to be an exception, if possible. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: suggestion: add a .ehs file type
Alex Jacobson wrote: My original point (refined) was that I'd like a file extension (.ehs) that defaults to including all extensions that don't change the meaning of a .hs program but that may cause a small subset of them not to compile (e.g. ones that use forall as a type variable, foreign as a function, or 'd' as the result value of a list comprehension) This does not seem like a major change, does not break any existing code, and has the advantage of making it really obvious when people are going beyond haskell98. It'll break all sorts of things when .ehs has to get merged into .hs the next time this conversation comes around, unless it's guaranteed that all .hs processors will eventually be upgraded to cope with .ehs semantics. I don't think anyone's arguing for that... -- Alex -Alex- Simon Marlow wrote: I see, all you're saying is you'd like the default to be different. (That's not the same as saying Extensions that change syntax are effectively declared by the use of that syntax, which is what you said earlier, BTW.) Well, we could change the default. I don't think it's a great idea personally - I think we should default to compiling whatever is the most recent standard, i.e. Haskell 98. But you're arguing that the proportion of Haskell 98 code that would fail to compile is relatively small; that might well be true. This isn't a decision we could take lightly, though. Furthermore, it's only something we could change in 6.10, by which time it is likely that we'll have a clearer idea of what Haskell' is, so there might well be a -fhaskell-prime flag (or it might even be the default). Cheers, Simon Alex Jacobson wrote: Simon, I think we've been trying to be too clever... The simple question is: for a given extension, what is the risk of leaving it turned on by default? Clearly we don't want extensions turned on that causes code to compile but with a different meaning. We may not want extensions turned on that cause most reasonable code not to compile. But I would say neither risk is significant in the case of most extensions. To use your examples: * FFI doesn't not cause h98 code to compile to a different meaning. The worst case is that code that uses 'foreign' as a function name doesn't compile. That seems okay in that more code probably uses FFI than uses foreign as a function name and the user can apply a language pragma to turn it off if really desired. * Existential types won't cause h98 code to compile with a different meaning. The worst case is that code that uses 'forall' as a type variable won't compile. That seems ok * TemplateHaskell also not compatible with h98. The worst case is the loss [d| in list comprehensions. * MagicHash: Does not appear in the ToC or the Index of the user's guide so should probably be turned off. I have no idea what it does. Note, in all cases where the extension is turned on by default, there should be a language pragma to turn it off. -Alex- Simon Marlow wrote: Alex Jacobson wrote: Simon, from what I can tell, with GHC 6.8.1, use of foreign as a function name or forall as a type variable or leaving out a space in a list-comprehension doesn't parse differently when the relevant extensions are enabled, it causes a parse error. Extensions allow the same code to parse but with different meanings need to be declared explicitly. But, extensions that are obvious from syntax should be allowed to be declared simply from the use of that syntax. So for the first example I gave, f x y = x 3# y the MagicHash extension is one that you'd require to be explicitly declared, because the expression parses both with and without the extension. Now, Let's take the Template Haskell example: f x = [d|d-xs] So this is valid Haskell 98, but invalid H98+TH. You would therefore like this example to parse unambiguously as H98, correct? But in order to do that, our parser would need arbitrary lookahead: it can't tell whether the expression is legal H98+TH until it gets to the '-' in this case. Certainly it's possible to implement this using a backtracking parser, but Haskell is supposed to be parsable with a shift-reduce parser such as the one GHC uses. Or we could try parsing the whole module with various combinations of extensions turned on or off, but I'm sure you can see the problems with that. So basically the problem is that you need a parser that parses a strict superset of Haskell98 - and that's hard to achieve. Cheers, Simon I am not taking a position here on the merits of any extensions. -Alex- Simon Marlow wrote: Alex Jacobson wrote: Extensions that change syntax are effectively declared by the use of that syntax. If you can parse the source, then you know which extensions it uses. I thought we'd already established that this isn't possible. Here are some code fragments that parse differently depending on which extensions are enabled:
Re: [Haskell-cafe] Parsing unstructured data
Olivier Boudry wrote: Hi all, This e-mail may be a bit off topic. My question is more about methods and algorithms than Haskell. I'm looking for links to methods or tools for parsing unstructured data. I'm currently working on data cleaning of a Customer Addresses database. Addresses are stored as 3 lines of text without any structure and people made used lots of imagination to create the data (20 years of data using no rules at all). Postal code, street, city, state, region, country and other details as suite, building, dock, doors, PO box, etc... are all stored in free form in those 3 lines. I already wrote a haskell program to do the job. It correctly parses about 2/3 addresses and parses much of the rest but with unrecognized parts left. The current program works by trying to recognize words used to tag parts like STE, SUITE, BLDG, street words (STR, AVE, CIRCLE, etc...) and countries from a list (including typos). It uses regular expressions to recognize variation of those words, lookup tables for countries, street words, regular expression rules for postal codes, etc... The most difficult task is splitting the address parts. There is no clearly defined separator for the fields. It can be dot, space, comma, dash, slash, or anything you can imagine using as a separator and this separator can of course also be found inside an address part. In the current application when part of an address is recognized it will not be parsed again by the other rules. A system trying all rules and tagging them with probabilities would probably give better results. Any link to tools or methods that could help me in that task would be greatly appreciated. I already searched for fuzzy, probabilistic or statistical parsing but without much success. You may have better luck checking out methods used in parsing natural language. In order to use statistical parsing techniques such as Probabilistic Context Free Grammars ([1],[2] ) the standard approach is to extract rule probabilities from an annotated corpus, that is collection of strings with associated parse trees. Maybe you could use your 2/3 of addresses that you know are correctly parsed as your training material. A PCFG parser can output all (or n-best) parses ordered according to probabilities so that would seem to be fit your requirements. [1] http://en.wikipedia.org/wiki/Stochastic_context-free_grammar [2] http://www.cs.colorado.edu/~martin/slp2.html#Chapter14 -- Best, Grzegorz -- View this message in context: http://www.nabble.com/Parsing-unstructured-data-tf4892274.html#a14011334 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Waiting for thread to finish
After I have spawned a thread with 'forkIO', how can I check if that thread work has finished already? Or wait for it? The best way to do this is using Control.Exception.finally: (...) Changing ugly code for bad performance is not that usual in Haskell code :( I think you misunderstand Chris' remark. He's saying that MVars and forkIO give you bot clean control, and high performance. Sorry if I sound rude. I just saw a place for a small joke, and used it. Chris code is pretty elegant to what it is supposed to do. However, knowing if a thread has finished is just 1 bit of information. There's probably a reason why that would hurt performance, but I don't understand it. For most situations, I believe you want to know when a thread has finished, and have that in the implementation is probably more efficient than creating a MVar for each one. Please understand that I'm not criticising anyone's work, I just want to understand it better. Threads are a deep problem with many issues involved, and I have no proper knowledge of any of them. This code seems quite elegant, for the job you were asking: import Control.Concurrent import Control.Exception main = do done - run (print (last [1..1])) print Waiting takeMVar done print OK. where (...) Sorry, I don't agree. I try to write things in a way that when you read it you can get an intuition on why it's doing what it's doing; even when the code is for my reading only (which, in Haskell, is almost always the case). For instance: in the code I'm writing now, I need to know if threads have finished since only them I can use the files they generate. So, instead of checking if threads have finished, I decided to check if files exist and are available for writing. When I read 'takeMVar done', it's difficult to think why you want to read a value you are never going to use. But, of course, maybe this is just my prejudice, and if I understand anything about threads I would have a different feeling about it. And the lovely thread-ring benchmark, is also very nice: http://shootout.alioth.debian.org/gp4/benchmark.php?test=threadringlang=all (...) Sorry, I didn't think that's nice either. I read the description of the task, and it's one where in the real world you would never use threads to do it, except for benchmarking threads. Of course, that is important for many people, like those who study threads and their implementation. But do you know of a benchmark where the task is some kind of situation where you actually get a result faster by using threads than by using a single thread? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Waiting for thread to finish
On Nov 28, 2007 5:07 PM, Maurício [EMAIL PROTECTED] wrote: Sorry if I sound rude. I just saw a place for a small joke, and used it. Chris code is pretty elegant to what it is supposed to do. However, knowing if a thread has finished is just 1 bit of information. There's probably a reason why that would hurt performance, but I don't understand it. Most threads either communicate some result---and you'll care about setting up a channel for that---or run forever. Some threads run on different computation engines. There's nothing in the Haskell spec that says I have to run the threads on a shared-memory machine. If the threads are distributed, then the channel to communicate back that one has finished may be very expensive. -Brian -- Brian T. Sniffen [EMAIL PROTECTED]or[EMAIL PROTECTED] http://www.evenmere.org/~bts ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
Sebastian Sylvan wrote: On Nov 28, 2007 12:12 PM, Kalman Noel [EMAIL PROTECTED] wrote: Sebastian Sylvan: primes :: [Integer] primes = 2 : filter (null . primeFactors) [3,5..] primeFactors :: Integer- [Integer] primeFactors n = factor n primes where factor m (p:ps) | p*p m= [] | m `mod` p == 0 = p : factor (m `div` p) (p:ps) | otherwise = factor m ps Your definition gives a strange meaning to primeFactors. I'd want that for all n, product (primeFactors n) == n. I think this law holds for the code posted by Olivier. Yes you're right. That is property should clearly hold. There are problems for which it's important to know how many times a given prime factor occurs. And there are other problems where it is merely necessary to know which primes are factors. I would say it's useful to have *both* functions available... By the way, I'm now using a new and much uglier prime seive: size = 100 :: Word64 calc_primes :: IO [Word64] calc_primes = do grid - newArray (2,size) True seive 2 grid where seive :: Word64 - IOUArray Word64 Bool - IO [Word64] seive p g = do mapM_ (\n - writeArray g n False) [p, 2*p .. size] mp' - next (p+1) g case mp' of Nothing - return [p] Just p' - do ps - seive p' g return (p:ps) next :: Word64 - IOUArray Word64 Bool - IO (Maybe Word64) next p g = do if p == size then return Nothing else do t - readArray g p if t then return (Just p) else next (p+1) g Seems moderately fast. At least, I can find the 10,001st prime in under 1 second... The obvious downside of course is that you must know how big to make the array at the start of your program, and you must compute the entire array before you can use any of it. Both limitations not precent in the lazy recursive list implementation... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Waiting for thread to finish
Dan Weston wrote: Silly or not, if I compile with -threaded, I always link in the one-liner C file: char *ghc_rts_opts = -N2; so I don't have to remember at runtime whether it should run with 2 cores or not. This just changes the default to 2 cores, so I am still free to run on only one core with the runtime flags +RTS -N1, though I rarely need to. http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-hooks Ah... you learn something useful every day! I was going to ask on IRC whether there's any way to do this - but now I don't need to bother. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing unstructured data
On 11/28/07, Grzegorz Chrupala [EMAIL PROTECTED] wrote: You may have better luck checking out methods used in parsing natural language. In order to use statistical parsing techniques such as Probabilistic Context Free Grammars ([1],[2] ) the standard approach is to extract rule probabilities from an annotated corpus, that is collection of strings with associated parse trees. Maybe you could use your 2/3 of addresses that you know are correctly parsed as your training material. A PCFG parser can output all (or n-best) parses ordered according to probabilities so that would seem to be fit your requirements. [1] http://en.wikipedia.org/wiki/Stochastic_context-free_grammar [2] http://www.cs.colorado.edu/~martin/slp2.html#Chapter14 -- Best, Grzegorz -- Hi Grzegorz, Wow, Natural Language Processing looks quite complex! But it also seems to be closely related to my problem. If someone finds a NPL for dummies article or book I'm interested. ;-) Thanks for your help, Olivier. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Waiting for thread to finish
Andrew Coppin wrote: Dan Weston wrote: Silly or not, if I compile with -threaded, I always link in the one-liner C file: char *ghc_rts_opts = -N2; Ah... you learn something useful every day! I was going to ask on IRC whether there's any way to do this - but now I don't need to bother. :-) But wait, there's more! If you're using the threaded RTS, you often need to know how many threads you can run concurrently, for example to explicitly split up a compute-bound task. This value is exposed at runtime by the numCapabilities variable in the GHC.Conc module. http://www.haskell.org/ghc/docs/latest/html/libraries/base-3.0.0.0/GHC-Conc.html#v%3AnumCapabilities This variable is new in GHC 6.8.1 (thanks, Simon!), so don't try to use it with an older release. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: cabal-install
Thomas Schilling wrote: On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote: Don Stewart wrote: ben.franksen: cabal: dist/Conftest.c: openFile: does not exist (No such file or directory) This one is due to having an out of date cabal. Upgrade to darcs cabal, then rebuild cabal-install, and things should go fine. [EMAIL PROTECTED]: .../software/haskell darcs get --partial http://darcs.haskell.org/cabal Copying patch 115 of 115... done! Applying patch 114 of 114... done. Finished getting. [EMAIL PROTECTED]: .../software/haskell cd cabal [EMAIL PROTECTED]: .../haskell/cabal runhaskell Setup.lhs configure Distribution/Simple/NHC.hs:77:1: lexical error at character 'i' Well, Cabal cannot automatically compile itself with itself. Ok, I didn't know that. I thought it would work since I have the latest release of Cabal installed (1.2.2.0). Use: $ make That did it. Many thanks. No more runhaskell Setup.[l]hs for me ;-) Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
Michaeljohn Clement wrote:
Andrew Coppin wrote:
First, somebody else wrote this in C:
int n = 2 , m , primesFound = 0;
for( n=0;n MAX_NUMBERS;n++ )
if( prime[n] )
{
primesFound++;
if( primesFound == 10001 )
cout n is the 10001st prime. endl;
Um, I can't *believe* nobody else pointed this
out, but that isn't C, it's C++.
Really? How can you tell?
Well anyway, the guy who wrote it said it's C. I suppose it was a simple
oversight...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Progress indications
In a normal programming language, you might write something like this: for x = 1 to 100 print x ...do slow complex stuff... next x In Haskell, you're more likely to write something like result k = filter my_weird_condition $ map strange_conversion $ unfoldr ... That means that when you try to process the result, lots of processing happens, and your program just appears to lock up until a result is produced. So, like, how do you make it so that some kind of progress information is output while it's working? (Aside from dunking everything into the IO monad and ruining all your beautiful abstractions.) There doesn't seem to be a clean solution to this one... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings and utf-8
Duncan Coutts wrote: When it's phrased as truncates to 8 bits it sounds so simple, surely all we need to do is not truncate to 8 bits right? The problem is, what encoding should it pick? UTF8, 16, 32, EBDIC? How would people specify that they really want to use a binary file. Whatever we change it'll break programs that use the existing meanings. One sensible suggestion many people have made is that H98 file IO should use the locale encoding and do Unicode/String - locale conversion. So that'd all be text files. Then openBinaryFile would be used for binary files. Of course then we'd need control over setting the encoding and what to do on encountering encoding errors. IMHO, someone should make a full proposal by implementing an alternative System.IO library that deals with all these encoding issues and implements H98 IO in terms of that. It doesn't have to be fast initially, it just has to get the API right and not design the API so as to exclude the possibility of a fast implementation later. In my humble opinion, what should happen is this: We need two seperate interfaces. One for text-mode I/O, one for raw binary I/O. ByteString provides some of the latter. [Can you use that on network sockets?] I guess what's needed is a good binary library to go with it. [I know there's been quite a few people who've had a go at this part...] When doing text-mode I/O, the programmer needs to be able to explicitly specify exactly which character encoding is required. (Presumably default to the current 8-bit truncation encoding?) That way the programmer can decide exactly how to choose an encoding, rather than the library designer trying to guess what The Right Thing is for all possible application programs. And it needs to be possible to cleanly add new encodings too. I'd have a go at implementing all this myself, but I wouldn't know where to begin... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
Am Mittwoch, 28. November 2007 22:31 schrieb Andrew Coppin: There are problems for which it's important to know how many times a given prime factor occurs. And there are other problems where it is merely necessary to know which primes are factors. I would say it's useful to have *both* functions available... Yup By the way, I'm now using a new and much uglier prime seive: size = 100 :: Word64 calc_primes :: IO [Word64] calc_primes = do grid - newArray (2,size) True seive 2 grid where seive :: Word64 - IOUArray Word64 Bool - IO [Word64] seive p g = do mapM_ (\n - writeArray g n False) [p, 2*p .. size] mp' - next (p+1) g case mp' of Nothing - return [p] Just p' - do ps - seive p' g return (p:ps) next :: Word64 - IOUArray Word64 Bool - IO (Maybe Word64) next p g = do if p == size then return Nothing else do t - readArray g p if t then return (Just p) else next (p+1) g Seems moderately fast. At least, I can find the 10,001st prime in under 1 second... One thing: since You check the array bounds, the system needn't check them again, use unsafeWrite and unsafeRead. And use Int for the index, that would be MUCH faster. Another thing: you can stop sieving when p*p size, another speedup Third thing: In my experience mapM_ is relatively slow, hand coded loops are faster (though much uglier), but YMMV Fourth thing: sieve only odd numbers Fifth thing: better use an STUArray, don't drag IO in if it's not necessary. The obvious downside of course is that you must know how big to make the array at the start of your program, and you must compute the entire array before you can use any of it. Both limitations not precent in the lazy recursive list implementation... The size of the array can easily be estimated by the prime number theorem, pi(x) ~ x/log x, where pi(x) is the number of primes not exceeding x, so for 10,001 primes, find x with x/log x about 10,000, add a bit for safety, a bound of 120,000 will do. If you want the n-th prime, you don't want to use the smaller primes anyway, if you need all primes, chances are that prime generation will take negligible time in comparison to your main algo anyway. Keep enjoying Project Euler, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
On Wed, Nov 28, 2007 at 05:58:07PM -0500, Thomas Hartman wrote: maybe Debug.Trace? like... import Debug.Trace t = foldr debugf 0 [1..1] f :: Int - Int - Int f = (+) -- same typesig as f debugf :: Int - Int - Int debugf x y | y `mod` 1000 == 0 = x + (trace (show y) y) debugf x y = x + y Or, more flexibly: import System.IO.Unsafe ( unsafeInterleaveIO ) monitorProgress :: (Int - IO ()) - [a] - IO [a] monitorProgress f xs = mapM f' $ zip [0..] xs where f' (n,x) = unsafeInterleaveIO (f n return x) You could, of course, make this a function lessSafeMonitoryProgress :: (Int - IO ()) - [a] - [a] by using unsafePerformIO instead of unsafeInterleaveIO, but that seems slightly scary to me. In any case, you can stick this on whichever of the lists you want to monitor the progress of. -- 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] A tale of Project Euler
On Nov 28, 2007 9:28 PM, Andrew Coppin [EMAIL PROTECTED] wrote:
Michaeljohn Clement wrote:
Andrew Coppin wrote:
First, somebody else wrote this in C:
int n = 2 , m , primesFound = 0;
for( n=0;n MAX_NUMBERS;n++ )
if( prime[n] )
{
primesFound++;
if( primesFound == 10001 )
cout n is the 10001st prime. endl;
Um, I can't *believe* nobody else pointed this
out, but that isn't C, it's C++.
Really? How can you tell?
cout, endl etc.
--
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] A tale of Project Euler
On Nov 28, 2007, at 16:28 , Andrew Coppin wrote:
Michaeljohn Clement wrote:
Andrew Coppin wrote:
First, somebody else wrote this in C:
int n = 2 , m , primesFound = 0;
for( n=0;n MAX_NUMBERS;n++ )
if( prime[n] )
{
primesFound++;
if( primesFound == 10001 )
cout n is the 10001st prime. endl;
Um, I can't *believe* nobody else pointed this out, but that isn't
C, it's C++.
Really? How can you tell?
Strictly speaking, the I/O is done with C++ operators and variables.
But the actual algorithm is C, if you replace the cout ... with
printf() then the whole thing will be C.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Waiting for thread to finish
Brad Clow: When I (deeply) force the worker thread's results to be strict, I observe both cores working, but the execution time (elapsed) slower. I can only speculate, but since you emphasise deep forcing, I wonder how deep is the structure returned from the worker thread? Could it be deep enough to hurt CPU cache performance (compared to an unforced version where production and consumption are interleaved)? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
* Static typing, which increases robustness by allowing the compiler to catch many common errors automatically. * Type inference, which deduces types automatically and frees the programmer from writing superfluous type signatures. * Higher order functions, polymorphism, and lazy evaluation, which enable higher levels of abstraction and more compositional, thus more reusable code. frees the programmer from writing superfluous type signatures is a weak (and dubious) advantage. I very often write superfluous type signatures first (to be sure I know what I'm asking my program to do) and only then let Haskell check it. Then I leave it in as good documentation. Also, if you're going to stress the benefits for the casual or new reader, maybe you should spell them out explicitly: * Static typing - Compiler automatically infers a static type for every expression, completely eliminating any potential for runtime type mismatch errors, and checks any programmer-supplied type annotation for correctness. The absence of silent typecasting also eliminates a whole class of hard-to-find program logic errors. * Higher-order functions and polymorphism - Encourages higher-level abstraction and unshackles algorithm design from implementation details. * Lazy evaluation - Separates the concerns of the called function (what can I provide?) and the calling function (how much do I need to know?) and facilitates borrow-from-the-future techniques where useful with infinite data structures or recursive algorithms. Thomas Schilling wrote: On Mon, 2007-11-26 at 20:31 -0800, David Fox wrote: On Nov 26, 2007 11:38 AM, Thomas Schilling [EMAIL PROTECTED] wrote: Haskell is a general-purpose, pure functional programming languages that puts many interesting results from research into a practical programming language. It's features include: I think it is stronger to say many powerful results rather than many interesting results. Yes, good! Also it should be its rather than it's, but I didn't want to reply to my own message since it was meant as a draft to work with. I'd like to turn this into a refinement of a concrete proposal. I skimmed the original thread and it pretty much diverged into experience reports or meta-level discussions on what or how to advertise Haskell. This has its place, but I think we can get to a description that is good enough for now and addresses Don's issues mentioned in the thread-starting message. So, I would welcome more concrete adjustments to my proposal. / Thomas ___ 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
[Haskell-cafe] Question about takeMVar
Hi, 'takeMVar' documentation says if there are multiple threads blocked in takeMVar, and the MVar becomes full, only one thread will be woken up. Since 'takeMVar' is a reading function, i.e., it doesn't change the value of the variable, why waking up only one thread? If we wake multiple threads, there's no risk of one changing the value while the other is reading. Does that mean that all threads waiting for that MVar will get the same value, even if one of those threads change it's value just after reading? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal under windows (was Re: Haskell-Cafe Digest, Vol 51, Issue 180)
Well I'd say none of the packages I've tried, build out of the box... I'm not a windows developer, but Is it actually reasonable to expect any cabal packages that depend on external c libraries and headers to build out of the box on windows? How can cabal find out where those files are, without requiring a config file to be edited? Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc 6.8.1 bug?
SevenThunders wrote:
The new behavior is that under certain conditions a certain matrix inner
product produces undefined floats, that should not be there.
I now have a simple example that I have posted as ticket number 1944 for ghc
6.8.1. The behavior is that if I link to an external cblas .dll file and do
a simple matrix multiply I get NaNs in the answer. However this only seems
to happen after I call the round function. The behavior does not occur for
ghc 6.6.1.
I will show the source files that cause this below.
Test2.hs:
module Main where
foreign import ccall unsafe test2.h iprod iprod :: IO()
main = do
let base = round 0.03
print $ rounded base = ++ (show base)
iprod
The c source file ctest2.c:
#include math.h
#include stdio.h
#include ctest2.h
#define N 2
#define N4 8
/* 4 x N matrix */
double A[N4] ;
/* N x 1 matrix */
double B[N] ;
double C[4] = {0.0,0.0,0.0,0.0} ;
void iprod(void)
{
int k ;
double sum ;
for (k = 0 ; k N4 ; k++) {
A[k] = 1.0 ;
}
for (k = 0 ; k N ; k++) {
B[k] = 1.0 ;
}
cblas_dgemm(CblasColMajor, CblasNoTrans, CblasNoTrans, 4, 1, N, 1.0, A,
4, B, N, 0.0, C, 4) ;
for (k = 0 ; k 4 ; k++) {
printf(C[%d] = %g\n, k, C[k]) ;
}
}
The .h include file ctest2.h:
enum CBLAS_ORDER {CblasRowMajor=101, CblasColMajor=102 };
enum CBLAS_TRANSPOSE {CblasNoTrans=111, CblasTrans=112, CblasConjTrans=113,
AtlasConj=114};
enum CBLAS_UPLO {CblasUpper=121, CblasLower=122};
enum CBLAS_DIAG {CblasNonUnit=131, CblasUnit=132};
enum CBLAS_SIDE {CblasLeft=141, CblasRight=142};
void cblas_dgemm(const enum CBLAS_ORDER Order, const enum CBLAS_TRANSPOSE
TransA,
const enum CBLAS_TRANSPOSE TransB, const int M, const int
N,
const int K, const double alpha, const double *A,
const int lda, const double *B, const int ldb,
const double beta, double *C, const int ldc);
void iprod(void) ;
The .bat file I used to compile this:
set CLIB=atlas
set TopFile=Test2
set csrc=ctest2.c
set OutFile=%TopFile%.exe
dlltool.exe -D %CLIB%.dll -l %CLIB%.lib
set XFLAGS=-threaded -O -XForeignFunctionInterface
rem set XFLAGS=-prof -auto-all
rem -caf-all
ghc %XFLAGS% -I. -I..\matrixstack --make %TopFile%.hs %csrc% -o %OutFile%
-optl-l%CLIB% -optl-L.
and finally the output which prints the NaNs after calling Test2.exe,
rounded base =
C[0] = -1.#IND
C[1] = 2
C[2] = 2
C[3] = -1.#IND
--
View this message in context:
http://www.nabble.com/ghc-6.8.1-bug--tf4810375.html#a14018323
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal under windows (was Re: Haskell-Cafe Digest, Vol 51, Issue 180)
On 11/28/07, Tim Docker [EMAIL PROTECTED] wrote: Well I'd say none of the packages I've tried, build out of the box... I'm not a windows developer, but Is it actually reasonable to expect any cabal packages that depend on external c libraries and headers to build out of the box on windows? How can cabal find out where those files are, without requiring a config file to be edited? Tim Tim, It is reasonable if you set the LIB and INCLUDE environment variables to point to the MSYS /usr/local/lib and /usr/local/include directories. Of course you'll have to build the c library from source in MSYS/MinGW for this to work. You'll also have to manually copy the dll files to a location in the PATH. set LIB=%LIB%;C:\MSYS\1.0\local\lib set INCLUDE=%INCLUDE%;C:\msys\1.0\local\include You can this as a one time change in the Systems control panel. If you install the C library from a binary distribution (usually installed in some arbitrary location on the pc) then the easiest way is to edit the cabal file. Cheers, Olivier. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hit a wall with the type system
I was talking to a few people about this on #haskell, and it was suggested I ask here. I should say that I'm playing around here; don't mistake this for an urgent request or a serious problem. Suppose I wanted to implement automatic differentiation of simple functions on real numbers; then I'd take the operations from Num, Fractional, and Floating, and define how to perform them on pairs of values and their differentials, and then I'd write a differentiate function... but finding an appropriate type for that function seems to be a challenge. We have: 1. Differentiating a function of the most general type (Num a = a - a) should produce a result of type (Num a = a - a). 2. Differentiating a function of the more specific type (Fractional a = a - a) should produce a result of that type (Fractional a = a - a). 3. Differentiating a function of the most specific type (Floating a = a - a) should produce a result of type (Floating a = a - a). 4. BUT, differentiating a function which is of a more specific type than (Floating a = a - a) is not, in general, possible. So differentiate should have type A a = (forall b. A b = b - b) - a - a, but ONLY if the type class A is a superclass of Floating. Two partial solutions are: I can just define the differentiate function for Floating; but that means if I differentiate (\x - x + 1), the result is a function only on floating point numbers, which is less than desirable. Or, I can define several functions: say, diffNum, diffFractional, and diffFloating... all of which have precisely the same implementation, but different types and require copy/paste to make them work. Any thoughts? For reference, here's the code I kludged together. (Again, I'm only playing around... so I wrote this very quickly and may have gotten some things wrong; don't use my code without checking it first! In particular, I know that this code produces derivative functions whose domain is too large.) data AD a = AD a a deriving Eq instance Show a = Show (AD a) where show (AD x e) = show x ++ + ++ show e ++ eps instance Num a = Num (AD a) where (AD x e) + (AD y f) = AD (x + y) (e + f) (AD x e) - (AD y f) = AD (x - y) (e - f) (AD x e) * (AD y f) = AD (x * y) (e * y + x * f) negate (AD x e) = AD (negate x) (negate e) abs (AD 0 _) = error not differentiable: |0| abs (AD x e) = AD (abs x) (e * signum x) signum (AD 0 e) = error not differentiable: signum(0) signum (AD x e) = AD (signum x) 0 fromInteger i = AD (fromInteger i) 0 instance Fractional a = Fractional (AD a) where (AD x e) / (AD y f) = AD (x / y) ((e * y - x * f) / (y * y)) recip (AD x e)= AD (1 / x) ((-e) / (x * x)) fromRational x= AD (fromRational x) 0 instance Floating a = Floating (AD a) where pi= AD pi0 exp (AD x e) = AD (exp x) (e * exp x) sqrt (AD x e) = AD (sqrt x) (e / (2 * sqrt x)) log (AD x e) = AD (log x) (e / x) (AD x e) ** (AD y f) = AD (x ** y) (e * y * (x ** (y-1)) + f * (x ** y) * log x) sin (AD x e) = AD (sin x) (e * cos x) cos (AD x e) = AD (cos x) (-e * sin x) asin (AD x e) = AD (asin x) (e / sqrt (1 - x ** 2)) acos (AD x e) = AD (acos x) (-e / sqrt (1 - x ** 2)) atan (AD x e) = AD (atan x) (e / (1 + x ** 2)) sinh (AD x e) = AD (sinh x) (e * cosh x) cosh (AD x e) = AD (cosh x) (e * sinh x) asinh (AD x e)= AD (asinh x) (e / sqrt (x^2 + 1)) acosh (AD x e)= AD (acosh x) (e / sqrt (x^2 - 1)) atanh (AD x e)= AD (atanh x) (e / (1 - x^2)) diffNum:: Num b= (forall a. Num a= a - a) - b - b diffFractional :: Fractional b = (forall a. Fractional a = a - a) - b - b diffFloating :: Floating b = (forall a. Floating a = a - a) - b - b diffNum f x= let AD y dy = f (AD x 1) in dy diffFractional f x = let AD y dy = f (AD x 1) in dy diffFloating f x = let AD y dy = f (AD x 1) in dy -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hit a wall with the type system
I'll repeat, just for the heck of it, that what I want is a type something like: diff :: forall A a. (A : Floating, A a) = (forall b. A b = b - b) - b - b where A is quantified over all type classes, and : denotes is a superclass of. The syntax is made up, of course, and entirely unworkable since (:) is a user-definable contructor name... but that's the intuition anyway. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the role of $!?
Hi Thanks for the explanation. I would be grateful for some examples accompanying the text. I will indicate the right places for real life (Haskell code) examples in the paragraphs below: PJ: As I understand it, the distinction is between the mathematical term non-strict and the implementation method of lazy. Non-strict means that reduction (the mathematical term for evaluation) proceeds from the outside in, so if I have (a+(b*c)) then first you reduce the +, then you reduce the inner (b*c). PRS: No problems so far.. PJ: Strict languages work the other way around, starting with the innermost brackets and working outwards. This matters to the semantics because if you have an expression that evaluates to bottom (i.e. an error, exception or endless loop) then any language that starts at the inside and works outwards will always find that bottom value, and hence the bottom will propogate outwards. PRS: You would also get different results - e.g. let a = 3, b = 7, c = 2 therefore 20 = strict ( ( (a+(b*c)) ) therefore 17 = non-strict ( (a+(b*c)) ) or am I misunderstanding the concept? PJ: However if you start from the outside and work in then some of the sub-expressions are eliminated by the outer reductions, so they don't get evaluated and you don't get bottom. PRS: I'm not sure if I fully understand the bottom idea here. I thought it related to the base value in a recursive pattern. For example: f (.) [] = [] f . (x:xs) = x . f xs What's a sub-expression? PJ: Lazy evaluation, on the other hand, means only evaluating an expression when its results are needed (note the shift from reduction to evaluation). So when the evaluation engine sees an expression it builds a thunk data structure containing whatever values are needed to evaluate the expression, plus a pointer to the expression itself. When the result is actually needed the evaluation engine calls the expression and then replaces the thunk with the result for future reference. PRS: A thunk data structure? Again, a example would be nice. PJ: Obviously there is a strong correspondance between a thunk and a partly-evaluated expression. Hence in most cases the terms lazy and non-strict are synonyms. But not quite. For instance you could imagine an evaluation engine on highly parallel hardware that fires off sub-expression evaluation eagerly, but then throws away results that are not needed. In practice Haskell is not a purely lazy language: for instance pattern matching is usually strict (so trying a pattern match forces evaluation to happen at least far enough to accept or reject the match). The optimiser also looks for cases where sub-expressions are *always* required by the outer expression, and converts those into eager evaluation. It can do this because the semantics (in terms of bottom) don't change. Programmers can also use the seq primitive to force an expression to evaluate regardless of whether the result will ever be used. $! is defined in terms of seq. PRS: More examples please. Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hit a wall with the type system
On Nov 29, 2007 4:02 AM, Chris Smith [EMAIL PROTECTED] wrote: I was talking to a few people about this on #haskell, and it was suggested I ask here. I should say that I'm playing around here; don't mistake this for an urgent request or a serious problem. Suppose I wanted to implement automatic differentiation of simple functions on real numbers; then I'd take the operations from Num, Fractional, and Floating, and define how to perform them on pairs of values and their differentials, and then I'd write a differentiate function... but finding an appropriate type for that function seems to be a challenge. We have: 1. Differentiating a function of the most general type (Num a = a - a) should produce a result of type (Num a = a - a). I don't see why this should be true. Int - Int is an instance of this type, but derivatives require limits, which integers don't have. Do you intend to output the difference sequence of the function in this case? But then Double - Double is also an instance of this type. Do you intend to approximate the real derivative when it's specialized to this? Instead of worrying about the types, first tell us what semantics you want. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hit a wall with the type system
On Nov 29, 2007 4:31 AM, Luke Palmer [EMAIL PROTECTED] wrote: On Nov 29, 2007 4:02 AM, Chris Smith [EMAIL PROTECTED] wrote: I was talking to a few people about this on #haskell, and it was suggested I ask here. I should say that I'm playing around here; don't mistake this for an urgent request or a serious problem. Suppose I wanted to implement automatic differentiation of simple functions on real numbers; then I'd take the operations from Num, Fractional, and Floating, and define how to perform them on pairs of values and their differentials, and then I'd write a differentiate function... but finding an appropriate type for that function seems to be a challenge. Oh, I think I totally missed the point. I missed the word simple. I think the problem is that a function of type Num a = a - a can be any function whatsoever, it does not have to be a simple combination of operators (it could, for example, use show, do a string transformation, and then read the result). So while you can do your AD type, I think a function which differentiates (Num a = a - a) is not possible using this approach. You must resort to numerical methods... Luke We have: 1. Differentiating a function of the most general type (Num a = a - a) should produce a result of type (Num a = a - a). I don't see why this should be true. Int - Int is an instance of this type, but derivatives require limits, which integers don't have. Do you intend to output the difference sequence of the function in this case? But then Double - Double is also an instance of this type. Do you intend to approximate the real derivative when it's specialized to this? Instead of worrying about the types, first tell us what semantics you want. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the role of $!?
On Nov 29, 2007 4:23 AM, PR Stanley [EMAIL PROTECTED] wrote: PRS: You would also get different results - e.g. let a = 3, b = 7, c = 2 therefore 20 = strict ( ( (a+(b*c)) ) therefore 17 = non-strict ( (a+(b*c)) ) or am I misunderstanding the concept? Yes. If the strict program does not error, then the strict program and the lazy program will have the same results. Numerics are not the best way to illustrate the difference, because they are essentially strict in their semantics. How about a list function: head [] = error empty list head (x:xs) = x map f [] = [] map f (x:xs) = f x:map f xs head (map (+1) [1,2,3]) -- rewrite as... head (map (+1) (1:2:3:[])) Strictly would go like this: head (map (+1) (1:2:3:[])) -- evaluate map (+1) (1:2:3:[]) head ((1+1) : map (+1) (2:3:[])) -- evaluate 1+1 head (2 : map (+1) (2:3:[])) -- evaluate map (+1) (2:3:[]) head (2 : (2+1) : map (+1) (3:[])) -- evaluate 2+1 head (2 : 3 : map (+1) (3:[])) -- evaluate map (+1) (3:[]) head (2 : 3 : (3+1) : [])-- evaluate 3+1 head (2 : 3 : 4 : [])-- evaluate [] (nothing to do) head (2 : 3 : 4 : [])-- evaluate head 2 Lazily would go like this: head (map (+1) (1:2:3:[])) -- evaluate head -- try to match map (+1) (1:2:3:[]) -- against x:xs, need to evaluate map head ((1+1) : map (+1) (2:3:[])) -- evaluate head -- match (1+1):map (+1) (2:3:[]) against -- x:xs succeeds, with x = (1+1) (1+1) -- evaluate (1+1) 2 Here I'm describing lazy evaluation rather than non-strict semantics, but they're pretty closely related. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hit a wall with the type system
The question I asked is about how to type the differentiation function. Whether the function is correct is a different question, which I'm happy to talk about; but understand that it's just an example I was playing with. Luke Palmer wrote: Oh, I think I totally missed the point. I missed the word simple. No, I don't think you did miss the point in terms of what the code is doing. I said simple because I'm not thinking about vector-valued or multidimensional functions, partial derivatives, gradients, etc. This is on functions from numbers to numbers, where numbers are defined by the three type classes Num, Fractional, and Floating. I (probably incorrectly) used simple to say so. I think the problem is that a function of type Num a = a - a can be any function whatsoever, it does not have to be a simple combination of operators (it could, for example, use show, do a string transformation, and then read the result). Well, no you couldn't read the result directly, since Num is a subclass of only Eq and Show. You could read as an integer and then use fromInteger to do so, but that the code I wrote would treat the result as a constant, so the derivative would always be reported as zero. I realize this is strictly an incorrect implementation of fromInteger (and fromRational in the Fractional class), but at the same time, there is no correct implementation. For functions that refrain from using fromInteger or fromRational except on constants, and modulo any coding errors (as I said, I didn't implement this cautiously), this should give you the correct derivative for any function when the derivative exists. What it doesn't do is evaluate properly to bottom/NaN when the derivative fails to exist. Part of that is my lazy lack of interest in writing the code correctly. For example, log (-1) is NaN, but my code will give you (-1) as the derivative, suggesting (incorrectly, of course) that log is undefined but still differentiable at that point. But another part of it is endemic; for example, f x = if signum x == (-1) then (-x) else x redefines the absolute value function, which is not differentiable at 0, but this implementation will claim f'(0) = 1, and there's no obvious way to avoid it without changing a lot. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hit a wall with the type system
Luke Palmer wrote: I don't see why this should be true. Int - Int is an instance of this type, but derivatives require limits, which integers don't have. Do you intend to output the difference sequence of the function in this case? But then Double - Double is also an instance of this type. Do you intend to approximate the real derivative when it's specialized to this? Instead of worrying about the types, first tell us what semantics you want. I intend to naively treat each function as being from the reals to the reals, and then take advantage of the fact (which is proven by the type system in the code I posted) that when the derivative is evaluated at integer inputs for functions defined using only ring operations, the result is an integer (and similarly for rationals and field operations). Note that the functions here are defined over real numbers rather than *merely* intervals, because the type given for diffNum, for example, requires that the first parameter be no more specific than Num a = a - a... so one may not actually pass in a function of type Int - Int and expect the code to compile. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell packaging on Windows cygwin ( POSIX on Windows ; ^)
The message I actually receive is: runhaskell Setup.lhs build . ./Haq.hs:6:7: Could not find module `System.Environment': it is a member of a package base, which is hidden BTW I haven't actually checked source in via darcs due to cygwin $PATH problems ... vasya On Nov 29, 2007 12:08 AM, Galchin Vasili [EMAIL PROTECTED] wrote: Hello, I trying to get a library to build ... I am following the instructions in http://en.wikibooks.org/wiki/Haskell/Packaging. Under the Build your project section in this web page, when I try to do an actual build (runhaskell Setup.lhs build), the imported module System.Environment cannot be found. I suspect that there is a cygwin (Linux/Posix) environment variable that needs to be set to point to the Haskell libraries/packages. ?? Kind regards, Vasya ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell packaging on Windows cygwin ( POSIX on Windows ; ^)
Hello, I trying to get a library to build ... I am following the instructions in http://en.wikibooks.org/wiki/Haskell/Packaging. Under the Build your project section in this web page, when I try to do an actual build (runhaskell Setup.lhs build), the imported module System.Environment cannot be found. I suspect that there is a cygwin (Linux/Posix) environment variable that needs to be set to point to the Haskell libraries/packages. ?? Kind regards, Vasya ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the role of $!?
Hi Thanks for the response. JCC: In most languages, if you have some expression E, and when the computer attempts to evaluate E it goes in to an infinite loop, then when the computer attempts to evaluate the expression f(E), it also goes into an infinite loop, regardless of what f is. That's the definition of a strict language. PRS: Does that mean that a strict language is also imperative? Either e or f(e) could result in an infinite loop. JCC: In Haskell, this isn't the case ---we can write functions f such that the computation f(E) terminates, even when E does not. (:) is one such function, as are some functions built from it, such as (++); xn ++ ys terminates whenever xn does, even if ys is an infinite loop. This is what makes it easy and convenient to build infinite loops in Haskell; in most strict languages, if you said let fibs = 0 : 1 : zipWith (+) fibs (tail fibs) the language would insist on evaluating fibs before it actually assigned anything to the memory cell for fibs, giving rise to an infinite loop. (For this reason, most strict languages make such definitions compile-time errors). Unfortunately, non-strictness turns out to be a pain in the ass to implement, since it means when the code generator sees an expression, it can't just generate code to evaluate it --- it has to hide the code somewhere else, and then substitute a pointer to that code for the value of the expression. PRS: Is there a kind of strictness applied when the compiler/interpreter sorts the various sub-expressions into little memory compartments indexed with pointers for later evaluation? To put it another way, does lazy evaluation begin with the outer-most expression, the most abstract, and determine what sshould go where in relation to the subsequent inner expressions? For example: takeWhile (20) [0..9] ++ [10..] The compiler determiens at the outset that the result of takeWhile is a list followed by the calculation of the length of that list based on the predicate (20), and then calls ++ which is for all intents and purposes on its own an infinite loop. Is this what happens? This is a very simple example, that's to say, I am aware that the compiler may be faced with a much more complex job of applying lazy evaluation. Nevertheless, I wonder if there are a set of fundamental rules to which the compiler must always adhere in lazy evaluation. JCC: There are a number of clever optimizations you can use here (indeed, most of the history of Haskell compilation techniques is a list of clever techniques to get around the limitations of compiling non-strict languages), but most of them rely on the compiler knowing that, in this case, if a sub- expression is an infinite loop, the entire expression is an infinite loop. This is actually pretty easy to figure out (most of the time), but sometimes the compiler needs a little help. That's where $! (usually) comes in. When the compiler sees (f $ x), it has to look at f to see whether, if x is an infinite loop, f $ x is one as well. When the compiler sees (f $! x), it doesn't need to look at f --- if x is an infinite loop, (f $! x) always is one as well. So, where in (f $ x) the compiler sometimes needs to put the code for x in a separate top-level block, to be called later when it's needed, in (f $! x) the compiler can always generate code for x inline, like a compiler for a normal language would. Since most CPU architectures are optimized for normal languages that compile f(E) by generating code for E inline, this is frequently a big speed-up. PrS: Your description of $! reminds me of the difference between inline functions and ordinary functions in C++ with the former being faster. Am I on the right track? In either case, (f $ x) and (f $! x), lazy evaluation must be applied at a higher level otherwise either instruction could result in an infinite loop. Therefore, is efficiency the only consideration here? If Haskell is a lazy language and $ merely implies lazy evaluation then what's the difference between (f $ x \oplus y) and (f (x \oplus y))? Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about takeMVar
Maurício wrote: Hi, 'takeMVar' documentation says if there are multiple threads blocked in takeMVar, and the MVar becomes full, only one thread will be woken up. Since 'takeMVar' is a reading function, i.e., it doesn't change the value of the variable, why waking up only one thread? If we wake multiple threads, there's no risk of one changing the value while the other is reading. Why? Because this turns out to be useful primitive. It is very useful to be able to be sure that only a single thread picks up a value for all kinds of concurrency styles. In fact, takeMVar does change the value of the variable: it makes it empty. Does that mean that all threads waiting for that MVar will get the same value, even if one of those threads change it's value just after reading? No, only one thread gets that value. It's a one time only offer!. Another thread waiting will get the next value which is 'putMVar'ed. There are two higher-level constructs, both built from MVars: readMVar is take followed by put (with a little exception handling) so that other threads can also get the same value. A Chan, using the special dupChan facility, gives a stronger guarantee that each thread reads the same value exactly once. It's something like a shared queue with multiple readers. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Strings and utf-8
Hello Andrew, Thursday, November 29, 2007, 1:11:38 AM, you wrote: IMHO, someone should make a full proposal by implementing an alternative System.IO library that deals with all these encoding issues and implements H98 IO in terms of that. We need two seperate interfaces. One for text-mode I/O, one for raw binary I/O. When doing text-mode I/O, the programmer needs to be able to explicitly specify exactly which character encoding is required. (Presumably default to the current 8-bit truncation encoding?) http://haskell.org/haskellwiki/Library/Streams already exists -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
On Thu, 29 Nov 2007, Ben Franksen wrote: Thomas Schilling wrote: I put up a draft page. Feel free to adjust it. http://haskell.org/haskellwiki/FrontpageDraft I like the current version better. It is /very/ difficult to pack in such a short paragraph a list of the most important concepts /and/ advertising about how useful all this is. Rather than an advertising front page paragraph, I'd like to have a good introductory page. It should mention all the distinguishing features of Haskell, give a short explanation of the concepts with pointers (links) to more detailed texts (preferably on the wiki), and then go on to give the reader some idea about how and why this is all practically useful, maybe using one or two examples. +1 When I want to judge a programming language I like to see a gallery, a collection of beautiful programs. This shows me 1. what are the problems, the language developers want to tackle (does general purpose for the developers mean web, XML and data base processing or computationally intensive numerical stuff) 2. how do they solve them, i.e. what are the special features of the language and how do they help solving the problem, what style of programming does the language support. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the role of $!?
On 29 Nov 2007, at 06:32, PR Stanley wrote: Hi Thanks for the response. JCC: In most languages, if you have some expression E, and when the computer attempts to evaluate E it goes in to an infinite loop, then when the computer attempts to evaluate the expression f(E), it also goes into an infinite loop, regardless of what f is. That's the definition of a strict language. PRS: Does that mean that a strict language is also imperative? Nope, not at all. Just a strict language has slightly fewer programs it can evaluate correctly, as more will loop infinitely. Either e or f(e) could result in an infinite loop. JCC: In Haskell, this isn't the case ---we can write functions f such that the computation f(E) terminates, even when E does not. (:) is one such function, as are some functions built from it, such as (++); xn ++ ys terminates whenever xn does, even if ys is an infinite loop. This is what makes it easy and convenient to build infinite loops in Haskell; in most strict languages, if you said let fibs = 0 : 1 : zipWith (+) fibs (tail fibs) the language would insist on evaluating fibs before it actually assigned anything to the memory cell for fibs, giving rise to an infinite loop. (For this reason, most strict languages make such definitions compile-time errors). Unfortunately, non-strictness turns out to be a pain in the ass to implement, since it means when the code generator sees an expression, it can't just generate code to evaluate it --- it has to hide the code somewhere else, and then substitute a pointer to that code for the value of the expression. PRS: Is there a kind of strictness applied when the compiler/ interpreter sorts the various sub-expressions into little memory compartments indexed with pointers for later evaluation? To put it another way, does lazy evaluation begin with the outer-most expression, the most abstract, and determine what sshould go where in relation to the subsequent inner expressions? For example: takeWhile (20) [0..9] ++ [10..] The compiler determiens at the outset that the result of takeWhile is a list followed by the calculation of the length of that list based on the predicate (20), and then calls ++ which is for all intents and purposes on its own an infinite loop. Is this what happens? Not really. For lazy evaluation the compiler doesn't decide the order statically -- it merely gives the program rules to follow for what the next expression to be evaluated should be. Lets look at a slightly simpler example: takeWhile ( 2) (map (+1) [0..]) We will always attempt to evaluate the outermost left most expression. We do this by matching against the rules given in the program, to make this clearer, here are the rules for takeWhile and map: takeWhile _ []= [] takeWhile p (x:xs) | p x = x : takeWhile p xs | otherwise = [] map _ [] = [] map f (x:xs) = f x : map f xs takeWhile ( 2) (map (+1) [0..]) -- We start by evaluating the leftmost outermost expression. We attempt to match on the first rule of takeWhile, and discover that we can't because we don't know whether the result of (map (+1) [0..]) is the empty list or not. Therefore we demand the evaluation of (map +1) [0..]) - takeWhile ( 2) ((+1) 0 : map (+1) [1..]) -- We now know that we don't have the empty list, so we must use the second rule of takeWhile. We must evaluate the guard first though: - (2) ((+1) 0) | -- To do this, we must evaluate ((+1) 0) - (2) 1 | -- This evaluates to True, so we may insert the right hand side -- note that x remains evaluated - True | 1 : takeWhile (2) (map (+1) [1..]) -- We can drop the guard now, but lets carry on. We have already evaluated the outermost expression, so lets evaluate the next in. Again pattern matching on takeWhile demands the evaluation of map: - 1 : takeWhile (2) ((+1) 1 : map (+1) [2..]) -- We again, can pattern match on takeWhile, and must evaluate the guard again: - 1 : ((2) ((+1) 1) |) -- Again, we must evaluate the result of the addition - 1 : ((2) 2 |) -- This time we get False, so we must evaluate the next guard - 1 : (otherwise |) -- otherwise is a synonym for True, so we use this right hand side. - 1 : (True | []) -- and we can get rid of the guard, and prettify the result, giving us: - [1] Note that we followed a set of rules that gave us non-strict semantics. The set of rules is called lazy evaluation. We may come up with several other sets of rules that give us different evaluation orders, but still non-strict semantics (e.g. Optimistic Evaluation). This is a very simple example, that's to say, I am aware that the compiler may be faced with a much more complex job of applying lazy evaluation. Nevertheless, I wonder if there are a set of fundamental rules to which the compiler must always adhere in lazy
