[Haskell-cafe] functional languages and the financial industry
Hello, I have a job search agent/bot filtering for Haskell in particular ... it is interesting that a number are in the financial realm ... Check out ORIXnot to mention Jane Street ... Kind regards, Vasya ___ 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 Wed, 28 Nov 2007, Chris Smith wrote: 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 Why do the functions have different number types after differentiation? I thought, that just 'diff' diff :: (AD a - AD a) - (a - a) diff f x = let AD y dy = f (AD x 1) in dy must work. What you do, looks like numbers with errors, but I suspect you are right that 'automatic differentiation' is the term used for those kinds of computations. ___ 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 Thu, 29 Nov 2007, Henning Thielemann wrote: On Wed, 28 Nov 2007, Chris Smith wrote: 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 Why do the functions have different number types after differentiation? I thought, that just 'diff' diff :: (AD a - AD a) - (a - a) diff f x = let AD y dy = f (AD x 1) in dy must work. What you do, looks like numbers with errors, but I suspect you are right that 'automatic differentiation' is the term used for those kinds of computations. I like to add that I have written some code for working with Taylor expansions of functions, that is, with all derivatives of a function. You can get the derivatives of composed functions by composing the Taylor series of the elementary functions: http://darcs.haskell.org/htam/src/PowerSeries/Taylor.hs E.g. *PowerSeries.Taylor take 10 $ exp `compose` sin (pi/2) :: [Double] [2.718281828459045,1.664412599305428e-16,-1.3591409142295225,-1.109608399536952e-16,0.45304697140984085,4.299732548205689e-17,-0.11703713428087555,-1.2516118554300737e-17,2.5551309845882386e-2,3.0070240853853573e-18] Computes the (truncated) Taylor series for (exp . sin) at pi/2. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
Laurent Deniau 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.
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));
}
Well, I only remember that it took _me_ a page of C code :D Basically
due to a hand-coded intset and user interaction (no REPL for C, after all).
Regards,
apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] fast Array operations: foldl, drop
I thought operations like foldl' and drop must be very fast on arrays (especially UArray) with appropriate pointer tricks, I mean pointer incrementing instead of indexing for foldl' and a pointer into the array for drop. Is it planned to add such functions? Ok, if foldl f x . elems and listArray (i,sufficientlyBig) . drop n . elems are fused to high speed code, then these functions do not need to materialize in the API. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and DB : giving up
Don Stewart [EMAIL PROTECTED] writes: 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. I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance. You're probably right that one of them would work, but especially new users will have no way of knowing which one. Only after the user has given up do people post similar experiences. This is getting better, of course - hackage will grow usage and activity statistics and perhaps ratings, the wiki will be extended with recommendations, more people will get involved in development. But at the moment, this is a problem. -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] Haskell and DB : giving up
On Nov 29, 2007, at 10:49 AM, Ketil Malde wrote: I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance. Hello My post wasn't intended as raging criticism, I can guess that developping these libraries takes a lot of (unpaid) work. And I am grateful for these libraries no matter what. However, if what is needed to install and use MySQL (or another popular DB) from Haskell could be drastically made shorter and easier, more people might use Haskell in domains where it still is largely marginal (like say... websites). Manu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings and utf-8
Bulat Ziganshin wrote: 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 Which would mean that we have streams to do character I/O, ByteString to do binary I/O, and System.IO to do, eh, something in between. That seems rather unfortunate to me. While the truncate to 8 bits semantics may be nice to keep old code working, it really isn't all that intuitive. When I do 'putStr u\776', I want a u with an umlaut to appear, not to get it printed as if it were u\8. The strange thing is that Hugs at the moment _does_ print a u-umlaut, while ghci prints u\8, which is a u followed by a backspace, so I see nothing. Reinier ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
The following code is the direct translation of your Haskell code
void f(int x, intset s) {
printf(%d, , x);
f (intset_elem(s, x/2) ? 3*x : x/2, intset_put(s, x));
}
No, not that easy. The Haskell code works with arbitrary precision
Integer, the C code with a fixed size int. On a 32 bit machine, try to
calculate a_{1805133}, which equals to 19591041024. Or a_{8392780} =
26665583616. Or a_{850} = 10804333. These values are calculated with
the Haskell program in 370s and ~1GB memory usage.
Fair enough, on the same machine a C program (*two* pages long) was able
to calculate a_{23448481} = 594261577728 and a_{2500} = 192365946 in
50s and ~1GB memory usage.
/BR, Mirko Rahn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast Array operations: foldl, drop
Henning Thielemann wrote: I thought operations like foldl' and drop must be very fast on arrays (especially UArray) with appropriate pointer tricks, I mean pointer incrementing instead of indexing for foldl' and a pointer into the array for drop. Is it planned to add such functions? Ok, if foldl f x . elems and listArray (i,sufficientlyBig) . drop n . elems are fused to high speed code, then these functions do not need to materialize in the API. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe As far as I'm aware, our arrays don't support any kind of zero-copy slicing, which is what your 'drop' trick amounts to. Zero-copy slicing would seem like an obviously nice thing to have for IArrays, though, I agree. For various different kinds of slices including projections. ByteString supports zero-copy substring, but it's based on ForeignPtr not UArray. On the fusing point I believe that the stream fusers believe they can make things like foldl . elems fuse but I'm not sure. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
Simon Marlow writes: Perhaps Type Inference: deduces types automatically, so you don't have to clutter up your code with type declarations. You can still write type declarations for documentation purposes, and these will be automatically checked by the compiler. Perhaps it won't harm adding that manual signatures are useful semantically as well, for the disambiguation. What I'd *really* like to see is a bunch of links on the front page leading to pages that describe the main differences between Haskell and some other language (C, Python, Java, C#, F#, ...). ... and, perhaps, playing not only with the pedagogy by contrast, but also by similarities, to mention Clean. Jerzy Karczmarczuk ___ 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 21:00 +0100, Thomas Schilling wrote: On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote: [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. No actually it can, that was just a bug (which I've just fixed). Ben is indeed being a beta tester by using Cabal HEAD. I'd recommend the 1.2 branch: http://darcs.haskell.org/cabal-branches/cabal-1.2/ Or just darcs pull and try again. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Strings and utf-8
On Wed, 2007-11-28 at 17:38 -0200, Maurício 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? (...) 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. Be afraid of all your standard Unix utils in that case. They are all locale dependent, not just for encoding but also for sorting order and the language of messages. Using the locale is standard Unix behaviour (and these days the locale usually specifies UTF8 encoding). On OSX the default should be UTF8. On Windows it's a bit less clear, supposedly text files should use UTF16 but nobody actually does that as far as I can see. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Strings and utf-8
Duncan Coutts wrote: On Wed, 2007-11-28 at 17:38 -0200, Maurício 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? (...) 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. Be afraid of all your standard Unix utils in that case. They are all locale dependent, not just for encoding but also for sorting order and the language of messages. Language of messages is quite different from language of a file you read. Suppose I am English, and I have a russian friend, Vlad. My default locale is, say, latin-1, and his is something cyrillic. I might well open files including my own files, and his files. The locale of the current user is simple no guide to the correct encoding to read a file in, and not a particularly reliable guide to writing a file out. Locale makes perfect sense for messages (you are communicating with the user, his locale tells you what language he speaks). It makes much less sense for file IO. Jules ___ 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
Mirko Rahn wrote:
The following code is the direct translation of your Haskell code
void f(int x, intset s) {
printf(%d, , x);
f (intset_elem(s, x/2) ? 3*x : x/2, intset_put(s, x));
}
No, not that easy. The Haskell code works with arbitrary precision
Integer, the C code with a fixed size int. On a 32 bit machine, try to
calculate a_{1805133}, which equals to 19591041024. Or a_{8392780} =
26665583616. Or a_{850} = 10804333. These values are calculated with
the Haskell program in 370s and ~1GB memory usage.
This is also a work for a library (BTW like Haskell does), you can use
gmp or mpfr. This will just add one line to store x/2 in y and avoid its
recomputation. You will also have to switch from intset to set. And
there one can start to see the difference. The code refactoring will be
longer since C doesn't support parametric polymorphism nor operator
overloading.
Fair enough, on the same machine a C program (*two* pages long) was able
to calculate a_{23448481} = 594261577728 and a_{2500} = 192365946 in
50s and ~1GB memory usage.
;-)
a+, ld.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Strings and utf-8
On Thu, 2007-11-29 at 13:05 +, Jules Bean wrote: Language of messages is quite different from language of a file you read. Suppose I am English, and I have a russian friend, Vlad. My default locale is, say, latin-1, and his is something cyrillic. I might well open files including my own files, and his files. The locale of the current user is simple no guide to the correct encoding to read a file in, and not a particularly reliable guide to writing a file out. Locale makes perfect sense for messages (you are communicating with the user, his locale tells you what language he speaks). It makes much less sense for file IO. Yes, it's a fundamental limitation of the unix locale system and multi-user systems. However it's no less wrong than just picking UTF8 all the time. Obviously one needs a text file api that allows one to specify the encoding for the cases where you happen to know it, but for the H98 file api where there is no way of specifying an encoding, what's better than using the unix default method? (at least on unix) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell packaging on Windows cygwin ( POSIX on Windows ; ^)
On Thu, 2007-11-29 at 00:21 -0600, Galchin Vasili wrote: 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 ... Have you tried adding: build-depends: base you your .cabal file? Cabal enforces that your code may only use packages that you have explicitly stated your code depends on. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Sillyness in the standard libs.
Brandon S. Allbery KF8NH wrote: On Nov 19, 2007, at 16:06 , Arthur van Leeuwen wrote: here is a puzzle for you: try converting a System.Posix.Types.EpochTime into either a System.Time.CalendarTime or a Data.Time.Clock.UTCTime without going through read . show or a similar detour through strings. fromEnum and/or toEnum are helpful for this kind of thing, and I am occasionally tempted to bind cast = toEnum . fromEnum because I need it so much. Let's ignore System.Time since it's obsoleted by Data.Time. I just spent a little while trying to solve this puzzle, and it turns out there *is* a right way to do this: for t :: EpochTime, posixSecondsToUTCTime (fromRational (toRational t) :: POSIXTime) You want to go via Data.Time.Clock.POSIXTime, because that's what an EpochTime is. Now, EpochTime does not have an Integral instance, because it is the same as C's time_t type, which is not guaranteed to be an integral type. You have fromEnum, but that would be a hack: there's no guarantee that EpochTime fits in an Int, and if EpochTime is a fractional value you lose information. But you *can* convert to a Rational with toRational, and from there you can get to a POSIXTime with fromRational (also realToFrac would do). It turns out there are good reasons for all this, it just ends up being quite obscure. I'll put the above formula in the docs. Cheers, Simon ___ 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 Thu, 2007-11-29 at 13:51 +1100, Tim Docker 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? It's usually worse than that. The most likely situation is that the C library and header files are not even installed. This is a big problem for all packages that wrap C libs. Sometimes the C code is sufficiently simple that one can just bundle it. My zlib and bzlib packages on hackage do that and that's the only reason they work on Windows. This is not a realistic solution for most other binding packages. Duncan ___ 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 Wed, 2007-11-28 at 19:11 +0100, manu 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. Yes, you were unlucky in that you jumped in just after ghc 6.8.1 was released and before 90% of the packages on hackage had been updated to work with 6.8 yet. In the mean time you would indeed be better off with 6.6. Our hackage infrastructure is still fairly immature and lacks any mechanism for indicating which packages work on which platforms. I agree it's frustrating. Then additionally there is the complication that many packages that use C libs (like DB client libs) just don't build out of the box on windows because the development files are not installed. Probably the best eventual solution for Windows is to build infrastructure to make binary packages for Windows. People are working on that. Duncan ___ 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-CafeDigest, Vol 51, Issue 180)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Duncan Coutts On Thu, 2007-11-29 at 13:51 +1100, Tim Docker wrote: 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? It's usually worse than that. The most likely situation is that the C library and header files are not even installed. This is a big problem for all packages that wrap C libs. It can be done, with a bit of work, luck, and a brittle cabal Setup.hs :-) If you assume that the user has installed the 3rd party library correctly, and you know it's layout and an executable it uses (which is on the PATH), then you can do something like what HSQL does (and Takusen now, which copied HSQL's approach). That is, you ask for the location of the known executable in the PATH, and then build your header (include) and library paths relative to the location of the executable. That's what we've done in Takusen for the Oracle and Sqlite installations. For PostgreSQL there is a program you can run which will emit the installed locations of the include and library files, so that's slightly less brittle. Of course, if the particular libs are not on the PATH then this won't work :-( Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
Obviously heaps better than what I initially proposed. However, I would argue to go boldly with unsafePerformIO, which is the same thing Debug.Trace uses http://darcs.haskell.org/ghc-6.6/packages/base/Debug/Trace.hs since we are after debug.trace -like behavior. In particular, you wouldn't be able to use the unsafeInterleaveIO version to do a progress indicator for the function I initially proposed t = foldr (+) 0 [1..1] since your lift would wind up being lifted into IO. But you would be able to use the unsafePerformIO version, just like in what I initially proposed you could use trace. t = foldr (+) 0 ( lessSafeMonitoryProgress f [1..1] ) where f i | i mod 1000 == 0 = (putStrLn . show ) i | otherwise = return () Make sense? thomas. David Roundy [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/28/2007 06:16 PM To haskell-cafe@haskell.org cc Subject 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 --- 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] Re: Strings and utf-8
A translation of http://www.ahinea.com/en/tech/perl-unicode-struggle.html from perl to haskell would be a very useful piece of documentation, I think. That explanation really helped me get to grips with the encoding stuff, in a perl context. thomas. Duncan Coutts [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/29/2007 07:44 AM To Maurício [EMAIL PROTECTED] cc haskell-cafe@haskell.org Subject Re: [Haskell-cafe] Re: Strings and utf-8 On Wed, 2007-11-28 at 17:38 -0200, Maurício 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? (...) 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. Be afraid of all your standard Unix utils in that case. They are all locale dependent, not just for encoding but also for sorting order and the language of messages. Using the locale is standard Unix behaviour (and these days the locale usually specifies UTF8 encoding). On OSX the default should be UTF8. On Windows it's a bit less clear, supposedly text files should use UTF16 but nobody actually does that as far as I can see. Duncan ___ 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[2]: [Haskell-cafe] fast Array operations: foldl, drop
Hello Jules, Thursday, November 29, 2007, 2:29:08 PM, you wrote: I thought operations like foldl' and drop must be very fast on arrays (especially UArray) with appropriate pointer tricks, I mean pointer As far as I'm aware, our arrays don't support any kind of zero-copy slicing, which is what your 'drop' trick amounts to. of course - they don't contain first index element, so entire ByteArray# should be used for UArray -- 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: Strings and utf-8
Thomas Hartman wrote: A translation of http://www.ahinea.com/en/tech/perl-unicode-struggle.html from perl to haskell would be a very useful piece of documentation, I think. Perl encodes both Unicode and binary data as the same (dynamic) data type. Haskell - at least in theory - has two different types for them, namely [Char] for characters and [Word8] or ByteString for sequences of bytes. I think the Haskell approach is better, because the programmer in most cases knows whether he wants to treat his data as characters or as bytes. Perl does it the Perlish We guess at what the coder means way, which leads to a lot of frustration when Perl guesses wrong. The problems of the Haskeller trying to use Unicode, I think, will be different from those of the Perl hacker trying to use Unicode: the Haskeller will have to search for third-party modules to do what he wants, and finding those modules is the problem. The Perl hacker has all the Unicode support built in, but has to fight Perl occasionally to keep it from doing byte operations on his Unicode data. I had a colleague here go all but insane last week trying to use 'split' on a Unicode string in Perl on Windows. split would break the string in the middle of a UTF-8 wide character, crashing UTF-8 processing later on. Reinier ___ 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 Reinier, Thursday, November 29, 2007, 1:13:24 PM, 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. http://haskell.org/haskellwiki/Library/Streams already exists Which would mean that we have streams to do character I/O, ByteString to do binary I/O, and System.IO to do, eh, something in between. this means only that such proposal exists. i've worked on adding bytestream support too, but don't finished the work. at least it's possible. i hope that new i/o library will have modular design like this so it will be easy to add new features as 3rd-party libs -- 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: Sillyness in the standard libs.
On 29-nov-2007, at 14:44, Simon Marlow wrote: Brandon S. Allbery KF8NH wrote: On Nov 19, 2007, at 16:06 , Arthur van Leeuwen wrote: here is a puzzle for you: try converting a System.Posix.Types.EpochTime into either a System.Time.CalendarTime or a Data.Time.Clock.UTCTime without going through read . show or a similar detour through strings. fromEnum and/or toEnum are helpful for this kind of thing, and I am occasionally tempted to bind cast = toEnum . fromEnum because I need it so much. Let's ignore System.Time since it's obsoleted by Data.Time. Yes. That's what I wanted to do at first. :) I just spent a little while trying to solve this puzzle, and it turns out there *is* a right way to do this: for t :: EpochTime, posixSecondsToUTCTime (fromRational (toRational t) :: POSIXTime) Which, unfortunately, does not work with time-1.1.1 which is in GHC 6.6.1. Going through Rational is the right solution, though. My hackish detour was to use fromIntegral . toInteger . fromEnum You want to go via Data.Time.Clock.POSIXTime, because that's what an EpochTime is. Now, EpochTime does not have an Integral instance, because it is the same as C's time_t type, which is not guaranteed to be an integral type. You have fromEnum, but that would be a hack: there's no guarantee that EpochTime fits in an Int, and if EpochTime is a fractional value you lose information. But you *can* convert to a Rational with toRational, and from there you can get to a POSIXTime with fromRational (also realToFrac would do). It turns out there are good reasons for all this, it just ends up being quite obscure. I'll put the above formula in the docs. Yes, that would be good! Note that both the docs for DiffTime and EpochTime state that they contain seconds, and both are somewhat unclear as to whether they contain any higher precision than whole seconds. With kind regards, Arthur. -- /\/ | [EMAIL PROTECTED] | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt /\/__ | you can dare to be yourself | Dance like there's nobody watching ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
However, when I actually tried this out, I couldn't get it to compile. So I wound up back with trace. This does compile, and I think it does pretty much what we want in a noninvasive way, using unsafePerformIO via trace. import Debug.Trace t = foldr (+) 0 ( monitorprogress f [1..1] ) monitorprogress f xs = map g $ zip [1..] xs where g (i,a) | f i == True = trace (show i) a | otherwise = a f x | x `mod` 1000 == 0 = True | otherwise = False Thomas Hartman/ext/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/29/2007 10:43 AM To haskell-cafe@haskell.org, [EMAIL PROTECTED] cc Subject Re: [Haskell-cafe] Progress indications Obviously heaps better than what I initially proposed. However, I would argue to go boldly with unsafePerformIO, which is the same thing Debug.Trace uses http://darcs.haskell.org/ghc-6.6/packages/base/Debug/Trace.hs since we are after debug.trace -like behavior. In particular, you wouldn't be able to use the unsafeInterleaveIO version to do a progress indicator for the function I initially proposed t = foldr (+) 0 [1..1] since your lift would wind up being lifted into IO. But you would be able to use the unsafePerformIO version, just like in what I initially proposed you could use trace. t = foldr (+) 0 ( lessSafeMonitoryProgress f [1..1] ) where f i | i mod 1000 == 0 = (putStrLn . show ) i | otherwise = return () Make sense? thomas. David Roundy [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/28/2007 06:16 PM To haskell-cafe@haskell.org cc Subject 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 --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell packaging on Windows cygwin ( POSIX on Windows ; ^)
thank you everybody. my bad... a misspelling on my part ;^) Vasya On Nov 29, 2007 7:45 AM, Duncan Coutts [EMAIL PROTECTED] wrote: On Thu, 2007-11-29 at 00:21 -0600, Galchin Vasili wrote: 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 ... Have you tried adding: build-depends: base you your .cabal file? Cabal enforces that your code may only use packages that you have explicitly stated your code depends on. Duncan ___ 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, Nov 29, 2007 at 12:40:00PM +, Simon Marlow wrote: What I'd *really* like to see is a bunch of links on the front page leading to pages that describe the main differences between Haskell and some other language (C, Python, Java, C#, F#, ...). The easiest way to grasp what Haskell is all about is by reference to a known baseline, and programmers tend to have different baselines. e.g. the C page might start with Haskell is a functional language, whereas the Python page might start with Haskell is statically typed. As well as I am a $language programmer. linkWhy should I use Haskell?/link perhaps also things like I'm designing a programming course for undergraduates at a university. linkWhy should I use Haskell?/link I run a small company. linkWhy should my developers use Haskell?/link (but probably all with better wordings) Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Sillyness in the standard libs.
On Nov 29, 2007, at 12:12 , Arthur van Leeuwen wrote: Going through Rational is the right solution, though. My hackish detour was to use fromIntegral . toInteger . fromEnum ?? fromEnum produces an Int, which is an Integral such as fromIntegral requires; why is toInteger needed? Yes, that would be good! Note that both the docs for DiffTime and EpochTime state that they contain seconds, and both are somewhat unclear as to whether they contain any higher precision than whole seconds. (a) Whether EpochTime contains higher precision than seconds is system-dependent. (b) Use of a non-Integral type for EpochTime does not necessarily mean it has higher resolution than seconds. (Blame POSIX for both of these. Haskell's System.POSIX must deal, as must any other POSIX-compliant library.) -- 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] Progress indications
Lazy evaluation can sometimes be helpful here. I once wrote a raytracer that computed the resulting image using a pure function that returned a list of the RGB colors of the pixels: [(Word8, Word8, Word8)] When plotting the pixels to the screen in the IO monad, the value of each pixel would be computed on demand, and so the image was shown progressively as the calculations were performed. I was new to haskell when I made this program and when I ran the program for this first time I was expecting to experience a long pause and then a display of the final image. I was very surprised to see progressive rendering! On Nov 29, 2007 12:03 AM, Andrew Coppin [EMAIL PROTECTED] wrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast Array operations: foldl, drop
Henning Thielemann wrote: I thought operations like foldl' and drop must be very fast on arrays (especially UArray) with appropriate pointer tricks, These kinds of functions are only much use on one-dimensional arrays, which look sufficiently list-like that the ideas translate fairly cleanly. For higher dimensions, there are enough options in terms of traversal direction and what exactly e.g. a fold should fold over (single elements? lower-dimensional slices?) that a sensible API doesn't exactly leap out. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Sillyness in the standard libs.
Let's ignore System.Time since it's obsoleted by Data.Time. While you're updating the Data.Time docs, could you mention the above in System.Time? I recently looked at both and used System.Time because Data.Time looked too complicated. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
Daniel Fischer wrote: 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. I can't find the functions you're talking about. I have however changed the index type. (Make little or no noticable speed difference. But then, it's already pretty damn fast in the first place...) Another thing: you can stop sieving when p*p size, another speedup Saves a few hundred milliseconds. Fifth thing: better use an STUArray, don't drag IO in if it's not necessary. I don't understand the ST monad. 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, Probably. But it doesn't compare to the elegance and simplicity of being able to generate an arbitrary number of primes on an as-needed basis. Keep enjoying Project Euler, Daniel Well, I don't know about enjoy - generally I just find it quite frustrating. It's kind of addictive trying to increase your score though... (Anybody here reached 100% yet?) I find that a lot of the problems don't seem to involve much math. (E.g., here is some data, process it into a list of integers, find the highest one. Where is the deep mathematics in that?) A few of them do, but a lot are simply to do with prime numbers, and as far as I'm away, it is impossible to know anything about prime numbers. In other words, you must compute them all the hard way. ___ 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
Bryan O'Sullivan wrote: 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. Hmm... I was *sure* this was exposed in Control.Concurrent already... but, apparently, no. It seems you can only get at it from GHC.Conc. That's kind of a pitty... oh well! ;-) ___ 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 29, 2007, at 13:38 , Andrew Coppin wrote: Bryan O'Sullivan wrote: 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. Hmm... I was *sure* this was exposed in Control.Concurrent already... but, apparently, no. It seems you can only get at it from GHC.Conc. That's kind of a pitty... oh well! ;-) It's internal implementation foo; why would it be part of an interface intended to be reasonably portable? -- 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] New slogan for haskell.org
Dan Weston wrote: [...] and facilitates borrow-from-the-future techniques where useful with infinite data structures or recursive algorithms. And this, gentlemen, is just one of the reasons why Haskell gets labelled as scary. It's very hard to explain what this enigmatic riddle-like statement actually *means* without a very long exposition. (Heck, *I* haven't worked out how to borrow from the future yet...) [The other reason, of course, is that Haskell's syntax isn't C / C++ / Java / VB... which suits me just fine! ;-) ] ___ 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 29, 2007 6:43 PM, Andrew Coppin [EMAIL PROTECTED] wrote: Daniel Fischer wrote: 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. I can't find the functions you're talking about. I have however changed the index type. (Make little or no noticable speed difference. But then, it's already pretty damn fast in the first place...) Another thing: you can stop sieving when p*p size, another speedup Saves a few hundred milliseconds. Fifth thing: better use an STUArray, don't drag IO in if it's not necessary. I don't understand the ST monad. There's not a whole lot to understand if you just want to use it (though it's all very cool from a theoretical standpoint too). Here are my minor changes to your program. import Data.Array.ST import Control.Monad.ST calc_primes :: [Word64] calc_primes = runST ( do grid - newArray (2,size) True seive 2 grid ) where seive :: Word64 - STUArray s Word64 Bool - ST s [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 - STUArray s Word64 Bool - ST s (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 The benefit should be obvious: No pesky IO type, so you can use it in your pure code. You just need to give a type signature somewhere to show the type system that you're using STUArray, but the rest just uses the same type class as you already used for the IOUArrays. And here are the modifications to use the unsafe reads and writes (42% speedup for me): import Data.Array.Base size = 101 :: Word64 calc_primes :: [Word64] calc_primes = runST ( do grid - newArray (2,size) True seive 2 grid ) where seive :: Word64 - STUArray s Word64 Bool - ST s [Word64] seive p g = do mapM_ (\n - unsafeWrite g (fromIntegral 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 - STUArray s Word64 Bool - ST s (Maybe Word64) next p g = do if p == size then return Nothing else do t - unsafeRead g (fromIntegral p) if t then return (Just p) else next (p+1) g -- 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
Andrew Coppin writes: Dan Weston wrote: [...] and facilitates borrow-from-the-future techniques where useful with infinite data structures or recursive algorithms. And this, gentlemen, is just one of the reasons why Haskell gets labelled as scary. It's very hard to explain what this enigmatic riddle-like statement actually *means* without a very long exposition. (Heck, *I* haven't worked out how to borrow from the future yet...) Scary - schmary... If you want to be afraid of, say, Santa Claus, that's OK, you are a free man. But, perhaps before saying that you haven't worked out something, *try* to work it out. Read something about Richard Bird's circular programs. A nice Web article (Lloyd Allison) is here: http://www.csse.monash.edu.au/~lloyd/tildeFP/1989SPE/ A really complicated application by Janis Voigtländer http://wwwtcs.inf.tu-dresden.de/~voigt/HOSC.pdf will probably kill you, so don't. But The Web is full of articles. You can even read one or two of my own productions. I - sorry for shameless auto-ad - cited this paper *twice*, once it was after *your* similar statement... http://users.info.unicaen.fr/~karczma/arpap/lazypi.pdf It is called The Most Unreliable Technique in the World to Compute PI, and it has been written explicitly for fun and instruction. That's a possible answer to your dilemma. Another one shows something even worse than borrowing from the future, namely going backwards in time, applied to the Automatic Differentiation in Reverse Mode. http://users.info.unicaen.fr/~karczma/arpap/revpearl.pdf And, please, avoid saying that something is scary or difficult, unless you are really sure. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] doing builds using cygwin on Windows ....help
Hello, I have suceeded in doing a build on top of cygwin. However, after editing some of the cygwin bashrc files, teh darcs path and haddock path still don't show up when I do a echo $PATH. I am now reading http://cygwin.com/cygwin-ug-net/setup-env.html. The PATH environment variable is used by Cygwin applications as a list of directories to search for executable files to run. This environment variable is converted from Windows format (e.g. C:\WinNT\system32;C:\WinNT) to UNIX format (e.g., /WinNT/system32:/WinNT) when a Cygwin process first starts. Set it so that it contains at least the x:\cygwin\bin directory where x:\cygwin is the root of your cygwin installation if you wish to use cygwin tools outside of bash. .. however, I don't see in which file PATH can be set. Any help? I really want to get my Haskell build environment set up and cranking away. Kind regards, Vasya ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hit a wall with the type system
On Nov 28, 2007 9:20 PM, Chris Smith [EMAIL PROTECTED] wrote: 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). I must be missing the point of something. What's wrong with diff f x = let AD y dy = f (AD x 1) in dy ? In ghci we get *Main :t diff (\x - 2*x) (2::Int) diff (\x - 2*x) (2::Int) :: Int *Main :t diff (\x - 2*x) (2::Float) diff (\x - 2*x) (2::Float) :: Float I've used almost exactly that line of code myself a few times. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
On Thu, 29 Nov 2007, Simon Marlow wrote: What I'd *really* like to see is a bunch of links on the front page leading to pages that describe the main differences between Haskell and some other language (C, Python, Java, C#, F#, ...). The easiest way to grasp what Haskell is all about is by reference to a known baseline, and programmers tend to have different baselines. e.g. the C page might start with Haskell is a functional language, whereas the Python page might start with Haskell is statically typed. Python page could start with: You like 'map', 'filter', 'for x in ...' and lambda's in Python? Then you will like to learn where Python has borrowed these features. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
Henning Thielemann writes: Python page could start with: You like 'map', 'filter', 'for x in ...' and lambda's in Python? Then you will like to learn where Python has Henning, Python *may not* start in such a way. Those functionals are being obsoletised by Guido Van Rossum. for remains, obviously, but, please, don't try to convince anybody that Haskell was the first language with iterators... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: Hit a wall with the type system
Dan Piponi wrote: I must be missing the point of something. What's wrong with diff f x = let AD y dy = f (AD x 1) in dy ? In ghci we get *Main :t diff (\x - 2*x) (2::Int) diff (\x - 2*x) (2::Int) :: Int *Main :t diff (\x - 2*x) (2::Float) diff (\x - 2*x) (2::Float) :: Float I've used almost exactly that line of code myself a few times. Yep, that does what I want. Thank you (and Stefan, and ghci's :t) for pointing it out. If this were a practical thing, I'd certainly decide that's the best option and move on. But since this is me trying to figure out the Right Answer (tm), that still doesn't look like it. (Though I suspect if there were a Right Answer, it would have been pointed out by now.) From my perspective, what's wrong with it what Stefan mentioned when he suggested it: it breaks abstraction. Even if I don't expose the type AD (i.e., it's an implementation detail and the user of a library shouldn't care that it even exists), the inferred type signature for diff depends on it. Prelude AD :t diff diff :: forall a t. (Num a) = (AD.AD a - AD.AD t) - a - t But what's AD? If it's exported, then at least it will show up in Haddock with a list of its instances, so the type is merely misleading. but if it's not exported, then the type is just plain not useful. So I want the parameter to be more restricted. No one is going to write a function that *only* works on AD types. Instead, the parameter to diff ought to be required to be polymorphic. The rank n type does that, but it loses the ability to get the most general possible result type. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and DB : giving up
Ketil Malde wrote: I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance. You're probably right that one of them would work, but especially new users will have no way of knowing which one. Only after the user has given up do people post similar experiences. This is getting better, of course - hackage will grow usage and activity statistics and perhaps ratings, the wiki will be extended with recommendations, more people will get involved in development. But at the moment, this is a problem. This is one of the more frustrating aspects of Haskell. It's not that nobody has written DB bindings - they most certainly have. It's not that nobody has written compression or cryptography bindings - they have. It's that there is a small zoo of them, and it's really hard to pick out which ones are the good ones. I really hope this does improve in time. (And I really wish I could do something positive to make this happen...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast Array operations: foldl, drop
On Thu, 29 Nov 2007, Bryan O'Sullivan wrote: Henning Thielemann wrote: I thought operations like foldl' and drop must be very fast on arrays (especially UArray) with appropriate pointer tricks, These kinds of functions are only much use on one-dimensional arrays, which look sufficiently list-like that the ideas translate fairly cleanly. For higher dimensions, there are enough options in terms of traversal direction and what exactly e.g. a fold should fold over (single elements? lower-dimensional slices?) that a sensible API doesn't exactly leap out. That's unfortunately true. However, for my application (signal processing) I need mostly one-dimensional arrays and they should support fast foldl', slice, build. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast Array operations: foldl, drop
Jules Bean wrote: As far as I'm aware, our arrays don't support any kind of zero-copy slicing, which is what your 'drop' trick amounts to. Zero-copy slicing would seem like an obviously nice thing to have for IArrays, though, I agree. For various different kinds of slices including projections. ByteString supports zero-copy substring, but it's based on ForeignPtr not UArray. This is one of the many things I am often tempted to try to implement myself... In general, the IArray and MArray interfaces seem to be lacking a huge number of functions which logically *should* be quite possible on an array, they just aren't implemented. Maybe one day I'll sit down and make a serious attempt to catelogue and implement them all... ___ 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
Henning Thielemann wrote: 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. Well-said that man... Now, the question becomes what examples demonstrate the things that Haskell is good at? ___ 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
lemming wrote: Python page could start with: You like 'map', 'filter', 'for x in ...' and lambda's in Python? Then you will like to learn where Python has What about iterators - lazy lists - and generators - lazy function definitions. And list comprehensions, both lazy and strict. And zip. And the itertools module - containing analogues for lazy ++, [n..], cycle, dropWhile, groupBy, zipWith, takeWhile, etc. All inspired by Haskell. Jerzy Karczmarczuk wrote: Henning, Python *may not* start in such a way. Those functionals are being obsoletised by Guido Van Rossum. for remains, All of them are remaining. Guido's effort to deprecate them brought down a storm of protest. Folds, known as reduce in Python, are on their way out, though. They scared people (not Pythonic). please, don't try to convince anybody that Haskell was the first language with iterators... Python's iterators are not the same as iterators in C and other older languages. They are lazy lists. The reason they named them iterators is not to scare people. Haskell was not the first to have lazy lists, but Haskell was an important part of the inspiration for introducing them into Python. Guido was forced to do something - someone had written a new Python interpreter, called Stackless Python, in which every Python function was a Scheme-like continuation. People found this very, very scary. So Guido stopped it by introducing laziness, which could be made much less scary. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Working out which library to use (was: Haskell and DB)
andrewcoppin: Ketil Malde wrote: I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance. You're probably right that one of them would work, but especially new users will have no way of knowing which one. Only after the user has given up do people post similar experiences. This is getting better, of course - hackage will grow usage and activity statistics and perhaps ratings, the wiki will be extended with recommendations, more people will get involved in development. But at the moment, this is a problem. This is one of the more frustrating aspects of Haskell. It's not that nobody has written DB bindings - they most certainly have. It's not that nobody has written compression or cryptography bindings - they have. It's that there is a small zoo of them, and it's really hard to pick out which ones are the good ones. I really hope this does improve in time. (And I really wish I could do something positive to make this happen...) We have the start on a solution for how to pick the good ones. * Go to Hackage * Click on the 'experimental search interface' http://hackage.haskell.org/packages/search.html * Click on 'advanced search': http://hackage.haskell.org/packages/advancedsearch.html * Type the name of the library you're interested in, into the required-by field. We'll consider which binary IO library is most popular, from: * binary * NewBinary * safecopy The search engine returns the results: * binary, is used by 12 other packages: bencode, Etherbunny,GrowlNotify, harchive hmp3, hpaste, HPDF, infinity safecopy, tar, torrent, htar * NewBinary, is used by 4 other packages: ASN1, Crypto, GrowlNotify, Hmpf * safecopy, is used by 0 packages. So choose Data.Binary if you trust the wisdom of the crowd. So as a crude heuristic for measuring what the masses are saying, this seems reasonable. -- Don ___ 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 29, 2007 6:43 PM, Andrew Coppin [EMAIL PROTECTED] wrote: I don't understand the ST monad. There's not a whole lot to understand if you just want to use it (though it's all very cool from a theoretical standpoint too). From what I can tell, it's not definable without using strange language extensions. (I don't really like using things where it's unclear why it works.) Here are my minor changes to your program. import Data.Array.ST import Control.Monad.ST calc_primes :: [Word64] calc_primes = runST ( do grid - newArray (2,size) True seive 2 grid ) where seive :: Word64 - STUArray s Word64 Bool - ST s [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 - STUArray s Word64 Bool - ST s (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 The benefit should be obvious: No pesky IO type, so you can use it in your pure code. You just need to give a type signature somewhere to show the type system that you're using STUArray, but the rest just uses the same type class as you already used for the IOUArrays. How do you avoid accidentally recomputing the list multiple times? And here are the modifications to use the unsafe reads and writes (42% speedup for me): import Data.Array.Base size = 101 :: Word64 calc_primes :: [Word64] calc_primes = runST ( do grid - newArray (2,size) True seive 2 grid ) where seive :: Word64 - STUArray s Word64 Bool - ST s [Word64] seive p g = do mapM_ (\n - unsafeWrite g (fromIntegral 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 - STUArray s Word64 Bool - ST s (Maybe Word64) next p g = do if p == size then return Nothing else do t - unsafeRead g (fromIntegral p) if t then return (Just p) else next (p+1) g I don't see Data.Array.Base documented anywhere. (How did you know it exists?) ___ 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 Donnerstag, 29. November 2007 19:43 schrieb Andrew Coppin: Daniel Fischer wrote: 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. I can't find the functions you're talking about. As Sebastian already said, they're in Data.Array.Base, sorry, should've mentioned that. I have however changed the index type. (Make little or no noticable speed difference. But then, it's already pretty damn fast in the first place...) But it can be considerably faster. On my 5 yo 1200MHz thing, I can sieve up to 10 million in less than half a second: [EMAIL PROTECTED]:~/Documents/haskell/move time ./Sieve2 1000 664579 real0m0.419s user0m0.420s sys 0m0.000s And that's even faster than any sieve in C that I managed to write. (Okay, I don't know how to use bitsets in C, that might beat Haskell) Another thing: you can stop sieving when p*p size, another speedup Saves a few hundred milliseconds. Which is pretty much for a programme running below 1 second. Fifth thing: better use an STUArray, don't drag IO in if it's not necessary. I don't understand the ST monad. Nor do I. Just use it (and be prepared to use scoped type variables). 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, Probably. But it doesn't compare to the elegance and simplicity of being able to generate an arbitrary number of primes on an as-needed basis. True. But when speed matters, you have to bite the bullet. And if you don't know up to which bound you need the primes, but know it's a not too low bound, you can sieve the first part in an array and then go on using a list, that's what I do. Keep enjoying Project Euler, Daniel Well, I don't know about enjoy - generally I just find it quite frustrating. It's kind of addictive trying to increase your score though... (Anybody here reached 100% yet?) int-e (Bertram Felgenhauer, I believe), well he has not yet solved last week's, so currently he's at 99%, and there were a couple of others but they didn't persevere. I find that a lot of the problems don't seem to involve much math. (E.g., here is some data, process it into a list of integers, find the highest one. Where is the deep mathematics in that?) A few of them do, but a lot are simply to do with prime numbers, and as far as I'm away, it is impossible to know anything about prime numbers. In other words, you must compute them all the hard way. Some of the problems require little math, but more programming techniques. Others require a good grip of maths to find an efficient algorithm. Really deep maths can't be required, the site is not meant for professional mathematicians but for laypeople with mathematical interest. The aim is to make brute force unattractive (brute forcing times from 5 hours upwards), while a mathematical insight will often give the solution in a few nanoseconds. Many problems require both, some maths to find a good algorithm, and some programming techniques to make it run really fast. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and DB : giving up
Duncan Coutts wrote: Probably the best eventual solution for Windows is to build infrastructure to make binary packages for Windows. People are working on that. Do you mean the problem has been noticed or do you actually mean code is being written and tested? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
Bit Connor wrote: I was new to haskell when I made this program and when I ran the program for this first time I was expecting to experience a long pause and then a display of the final image. I was very surprised to see progressive rendering! Neat, isn't it? :-) On the other hand, if you do something like sort a list, you cannot see the first element of the result until the entire unsorted list has been computed... which can take a heck of a long time, depending on what the computation is. And since it's all calls to map and filter et al., it's not immediately clear how to provide any feedback on how much longer there is to wait. It seems unsafePerformIO is the way to go here. (BTW, what's the difference between unsafePerformIO and unsafeInterleaveIO?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Working out which library to use (was: Haskell and DB)
Hi We have the start on a solution for how to pick the good ones. We'll consider which binary IO library is most popular, from: The search engine returns the results: * binary, is used by 12 other packages: This only works with libraries that are lower-level, like binary, which other libraries are likely to use. For libraries such as HTML/XML parsing, its likely that the majority of users are applications, which are under-represented on hackage. I don't know what safecopy does, but I'm guessing its a wrapper around binary providing some functionality, so it follows that more people probably use the lower-level library than safecopy. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
[EMAIL PROTECTED] wrote: Andrew Coppin writes: Dan Weston wrote: [...] and facilitates borrow-from-the-future techniques where useful with infinite data structures or recursive algorithms. And this, gentlemen, is just one of the reasons why Haskell gets labelled as scary. It's very hard to explain what this enigmatic riddle-like statement actually *means* without a very long exposition. (Heck, *I* haven't worked out how to borrow from the future yet...) Scary - schmary... If you want to be afraid of, say, Santa Claus, that's OK, you are a free man. But, perhaps before saying that you haven't worked out something, *try* to work it out. Oh, I didn't mean *I* am scared of Haskell - I think Haskell is great! :-D I meant that other people perceive it as scary. And infinite data structures and borrowing from the future are two examples of things that scare them. And, relatedly, I said I hadn't worked out the latter yet. It doesn't scare me - I'm more curios than scared. ;-) I believe I did ask about it here once, but didn't get much of a clear answer. Read something about Richard Bird's circular programs. A nice Web article (Lloyd Allison) is here: http://www.csse.monash.edu.au/~lloyd/tildeFP/1989SPE/ A really complicated application by Janis Voigtländer http://wwwtcs.inf.tu-dresden.de/~voigt/HOSC.pdf will probably kill you, so don't. But The Web is full of articles. You can even read one or two of my own productions. I - sorry for shameless auto-ad - cited this paper *twice*, once it was after *your* similar statement... http://users.info.unicaen.fr/~karczma/arpap/lazypi.pdf It is called The Most Unreliable Technique in the World to Compute PI, and it has been written explicitly for fun and instruction. That's a possible answer to your dilemma. Another one shows something even worse than borrowing from the future, namely going backwards in time, applied to the Automatic Differentiation in Reverse Mode. http://users.info.unicaen.fr/~karczma/arpap/revpearl.pdf Should give me something interesting to read for a while... And, please, avoid saying that something is scary or difficult, unless you are really sure. Like I said, I think you're just misunderstanding what I'm trying to say, that's all. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
Yitzchak Gale writes: Python's iterators are not the same as iterators in C and other older languages. They are lazy lists. The reason they named them iterators is not to scare people. Haskell was not the first to have lazy lists, but Haskell was an important part of the inspiration for introducing them into Python. Actually, I would *sincerely* like to see some reference proving that. I cite Guido V.R., 2005: About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches. (http://www.artima.com/weblogs/viewpost.jsp?thread=98196) Give to Caesar...: It was Amrit Prem; one history page on WP says that no specific mention of any Lisp heritage is mentioned in the release notes at the time, so all speculations are still possible... ++ But, in fact, Python iterators - in general - are neither lazy nor lists. No linking! They are syntactic shortcuts to *objects* possessing the method 'next'. So, there is no call by need, no updated thunks, etc. Calling them lazy is an abuse of the language, although quite intuitive. I don't want to raise a war about that... The laziness, meant as deferred procedure calls *CAN* be used in Python, also in iterator context, through generators, that's true. But still there are no update'able automatically thunks, no lazy data! If generators remind me of something, it is co-routines. BTW. The BDFL Van Rossum never said anything about scaring. He said plainly that folds are things he *hates* most. Guido was forced to do something - someone had written a new Python interpreter, called Stackless Python, in which every Python function was a Scheme-like continuation. People found this very, very scary. So Guido stopped it by introducing laziness, which could be made much less scary. Give to Caesar... Someone, was Christian Tismer: http://www.python.org/workshops/2000-01/proceedings/papers/tismers/spcpaper. htm and I am doubtful about the statement that people found it very, very scary. Simply they - usually - felt no *need* for another complication to learn, you know, *some* people are lazy... But Stackless still exists, GVR stopped nothing, and the Grant Olson's tutorial http://members.verizon.net/olsongt/stackless/why_stackless.html is really interesting, although perhaps, as usual, not for Andrew Coppin. People, stop using this damned word: scare in the context of *learning* something! Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
Bit Connor wrote: computation is. And since it's all calls to map and filter et al., it's ...it's not immediately clear how to provide any feedback on how much longer there is to wait. Andrew Coppin wrote: It seems unsafePerformIO is the way to go here. ...unsafeInterleaveIO I disagree. The unsafe... functions are called that for a reason, and their use should be highly discouraged, except in cases where there is absolutely no other reasonable way. I don't believe that this is one of those cases. A better approach is to use pure monads. Instead of f :: ... - a write functions whose type is something like f :: ... - MyMonad a where MyMonad is defined in one and only one place in your program. Or, better yet, polymorphic things like f :: Monad m = ... - m a f :: MyMonadClass m = ... - m a Then when you later need to add something like progress indicators, you just add that to the capabilities of your monad, and add some updateProgress calls to your functions. By using do notation wisely, you can keep your abstractions just as clear as they were, and cleanly separated from the progress logic. Other things you may need to add later in real-world programs are exception handling, logging, trace, etc. All of these are easy if you started out in a monad. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
but there's no risk using trace is there? t. The unsafe... functions are called that for a reason, and their use should be highly discouraged, except in cases where there is absolutely no other reasonable way. Yitzchak Gale [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/29/2007 05:01 PM To Andrew Coppin [EMAIL PROTECTED] cc haskell-cafe@haskell.org Subject Re: [Haskell-cafe] Progress indications Bit Connor wrote: computation is. And since it's all calls to map and filter et al., it's ...it's not immediately clear how to provide any feedback on how much longer there is to wait. Andrew Coppin wrote: It seems unsafePerformIO is the way to go here. ...unsafeInterleaveIO I disagree. The unsafe... functions are called that for a reason, and their use should be highly discouraged, except in cases where there is absolutely no other reasonable way. I don't believe that this is one of those cases. A better approach is to use pure monads. Instead of f :: ... - a write functions whose type is something like f :: ... - MyMonad a where MyMonad is defined in one and only one place in your program. Or, better yet, polymorphic things like f :: Monad m = ... - m a f :: MyMonadClass m = ... - m a Then when you later need to add something like progress indicators, you just add that to the capabilities of your monad, and add some updateProgress calls to your functions. By using do notation wisely, you can keep your abstractions just as clear as they were, and cleanly separated from the progress logic. Other things you may need to add later in real-world programs are exception handling, logging, trace, etc. All of these are easy if you started out in a monad. -Yitz ___ 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
[Haskell-cafe] Re: Working out which library to use
Don Stewart wrote: We have the start on a solution for how to pick the good ones. * Go to Hackage * Click on the 'experimental search interface' http://hackage.haskell.org/packages/search.html * Click on 'advanced search': http://hackage.haskell.org/packages/advancedsearch.html * Type the name of the library you're interested in, into the required-by field. So as a crude heuristic for measuring what the masses are saying, this seems reasonable. From where I'm sitting, the main problems with Haskell packages are thus: 1. For certain tasks, there are multiple possible packages, and it's not really clear which one to go for. Having more than one choice is good. (E.g., there's Gtk2hs and there's wxHaskell, and you pick the one you want based on personal preference.) Having *dozens* of different packages for the same task, some more complete than others, some more maintained than others, etc., is just confusing. 2. Most things on Hackage don't seem to want to work on Windows. (Evidently this is being worked on. Stream Fusion installed just fine with a little help from Duncan...) 3. It's not easy to tell from the package summary whether it does what you want. (It looks like this too is being worked on with automatic generation of Haddoc information, which should help. Assuming there's any Haddoc comments to display, that is...) 4. General package quality. Some are excellent, some aren't. Given time, hopefully the excellent ones will rise to the top, and the less good ones will improve or dissappear. So it looks like this one is just a question of time and effort. Hopefully this will also somewhat solve #1 eventually... Just my opinion - others are welcomed to dissagree. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: Hit a wall with the type system
Chris, So I want the parameter to be more restricted. No one is going to write a function that *only* works on AD types. But exporting AD doesn't force people to write functions that work on AD types, people can write whatever functions they like. They're only constrained if they want to pass the function into 'diff', at which point it needs to work on AD. When you specify that a function has type a - b, you're entering into a bargain. You're saying that whatever object of type a you pass in, you'll get a type b object back. a - b is a statement of that contract. Now your automatic differentiation code can't differentiate any old function. It can only differentiate functions built out of the finite set of primitives you've implemented (and other polymorphic enough functions). So you have quite a complex contract to write. You want to say for any function you give me that is built out of these functions (and other ...), and no others, I can give you back the derivative. You need to say this somewhere otherwise it's like a contract for a house purchase that doesn't bother to say where the boundary line to the next house is (*). Luckily, there's a nice way to express this. We can just say diff :: (AD a - AD a) - a - a. So AD needs to be exported. It's an essential part of the language for expressing your bargain, and I think it *is* the Right Answer, and an elegant and compact way to express a difficult contract. -- Dan (*) I admit that I have bought a house like this, but it's not a good thing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Working out which library to use
Hi 1. For certain tasks, there are multiple possible packages, and it's not really clear which one to go for. Having more than one choice is good. (E.g., there's Gtk2hs and there's wxHaskell, and you pick the one you want based on personal preference.) Having *dozens* of different packages for the same task, some more complete than others, some more maintained than others, etc., is just confusing. + points 3 and 4 This can be solved easily using blogs. If you use a package successfully, blog about it. Write about how great it was, or what was lacking. Say what problems you ran into. Perhaps write a slightly tutorialish post saying what you used it for and a snippet of code. If a few people do this, Google will do the rest with search results. 2. Most things on Hackage don't seem to want to work on Windows. (Evidently this is being worked on. Stream Fusion installed just fine with a little help from Duncan...) Windows, the unloved Haskell platform... Not much you can do about this, short of breaking into peoples houses and reformatting their hard drive. I know most authors would be happy to accept a patch fixing whatever issue there is - so all it needs is more Windows users. Perhaps a wiki page listing the common mistakes a Linux user can make to render their package non-working on Windows? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell interface file (.hi) format?
Hello fellow Haskellers, Does anyone know if/where I can find a specification for the .hi files generated by GHC? I ask because I want to write an omni-completion plugin for Vim to make Haskell hacking a bit nicer. Thanks, Rob Hoelz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: cabal-install
Duncan Coutts wrote: On Wed, 2007-11-28 at 21:00 +0100, Thomas Schilling wrote: On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote: [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. No actually it can, that was just a bug (which I've just fixed). Ah, I wondered. If even 'the monster' (ghc) can build itself from earlier versions it should be possible for cabal to pull the same trick. Ben is indeed being a beta tester by using Cabal HEAD. I'd recommend the 1.2 branch: I was using HEAD as per Don's suggestion for how to build cabal-install. Now, re-reading this thread I see that you already mentioned that upgrading on the 2.1 branch would have been enough. Apropos beta-testing, cabal-1.3 seems to have introduced an incompatible API change; for instance, it can't build MissingH any longer. This might be ok by whatever versioning policy cabal uses, I didn't check; anyway: [EMAIL PROTECTED]: ~ cabal install MissingH Downloading 'MissingH-0.18.6'... [1 of 1] Compiling Main ( Setup.hs, dist/setup/Main.o ) Setup.hs:19:35: Couldn't match expected type `(Either GenericPackageDescription PackageDescription, HookedBuildInfo)' against inferred type `PackageDescription' In the first argument of `(confHook defaultUserHooks)', namely `mydescrip' In the expression: let mydescrip = case os of mingw32 - ... _ - ... in (confHook defaultUserHooks) mydescrip flags In the definition of `customConfHook': customConfHook descrip flags = let mydescrip = case ... of mingw32 - ... _ - ... in (confHook defaultUserHooks) mydescrip flags http://darcs.haskell.org/cabal-branches/cabal-1.2/ Ok, let's try the 1.2 branch, might be a bit more on the safe side. (*builds cabal-install with this version (hiding Cabal-1.3)...ok, installing, ok, ... oh wait, this version gives me exactly the same error as above ...thinking hard for a moment...). Ok, running again ./Setup configure this time with -v3: Dependency Cabal=1.2: using Cabal-1.3.1 O_o. I forgot that cabal ignores hidden/exposed status of packages (for good reasons IIRC). How do I tell it to use the newly installed 1.2.2.1? Is there a command line switch...(*stares at output of ./Setup configure --help; schade, no with-cabal=VERSION option*), no. To hell with it,I'll just add 1.3 to the cabal file and indeed it now says Dependency Cabal=1.21.3: using Cabal-1.2.2.1 One install of cabal-install later: same error with MissingH. So the package was broken to begin with an it wasn't related to the cabal upgrade! G. Not that it matters to me here at home (there is a debian package I can use), but at work we are still using debian /old-stable/ which is just a bit too outdated and anyway I don't have root access so I have to install everything from source. Unpacking MissingH and looking at the Setup.hs I see that I can simply replace it by a generic version, add unix dependency to the cabal file, and all works well. So much for never again runhaskell Setup blabla ;-) (I should add that for many packages cabal-install works perfectly well.) Thanks again for your help! Cheers Ben PS: a 'cabal remove' would also be nice to have. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: Re: Hit a wall with the type system
Hi Dan, thanks for answering. Dan Piponi wrote: When you specify that a function has type a - b, you're entering into a bargain. You're saying that whatever object of type a you pass in, you'll get a type b object back. a - b is a statement of that contract. Sure, that much makes perfect sense, and we agree on it. Now your automatic differentiation code can't differentiate any old function. It can only differentiate functions built out of the finite set of primitives you've implemented (and other polymorphic enough functions). Sure. To be more specific, here's the contract I would really like. 1. You need to pass in a polymorphic function a - a, where a is, at *most*, restricted to being an instance of Floating. This part I can already express via rank-N types. For example, the diffFloating function in my original post enforces this part of the contract. 2. I can give you back the derivative, of any type b - b, so long as b is an instance of Num, and b can be generalized to the type a from condition 1. It's that last part that I can't seem to express, without introducing this meaningless type called AD. There need be no type called AD involved in this contract at all. Indeed, the only role that AD plays in this whole exercise is to be an artifact of the implementation I've chosen. I could change my implementation; I could use Jerzy's implementation with a lazy infinite list of nth-order derivatives... or perhaps I could implement all the operations of Floating and its superclasses as data constructors, get back an expression tree, and launch Mathematica via unsafePerformIO to calculate its derivative symbolically, and then return a function that interprets the result. And who knows what other implementations I can come up with? In other words, the type AD is not actually related to the task at hand. [...] Luckily, there's a nice way to express this. We can just say diff :: (AD a - AD a) - a - a. So AD needs to be exported. It's an essential part of the language for expressing your bargain, and I think it *is* the Right Answer, and an elegant and compact way to express a difficult contract. Really? If you really mean you think it's the right answer, then I'll have to back up and try to understand how. It seems pretty clear to me that it breaks abstraction in a way that is really rather dangerous. If you mean you think it's good enough, then yes, I pretty much have conluded it's at least the best that's going to happen; I'm just not entirely comfortable with it. -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell interface file (.hi) format?
Rob Hoelz wrote: Does anyone know if/where I can find a specification for the .hi files generated by GHC? I ask because I want to write an omni-completion plugin for Vim to make Haskell hacking a bit nicer. I think it's pretty much considered unspecified; but there's code to read and write it in compiler/iface/BinIface.hs in any GHC source tree. -- Chris Smith ___ 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 Thu, Nov 29, 2007 at 09:10:16PM +, Andrew Coppin wrote: Sebastian Sylvan wrote: On Nov 29, 2007 6:43 PM, Andrew Coppin [EMAIL PROTECTED] wrote: I don't understand the ST monad. There's not a whole lot to understand if you just want to use it (though it's all very cool from a theoretical standpoint too). From what I can tell, it's not definable without using strange language extensions. (I don't really like using things where it's unclear why it works.) You can't implement IO in H98 either. You just have to accept it as a given. (As far as ST goes, runST is unsafePerformIO renamed. The only tricky bit is proving safety.) Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
On Thu, Nov 29, 2007 at 09:48:22AM +0100, apfelmus wrote:
Well, I only remember that it took _me_ a page of C code :D Basically due
to a hand-coded intset and user interaction (no REPL for C, after all).
In my C programming, I've taken to using gdb as a REPL:
[EMAIL PROTECTED]:/tmp$ vi foo.c
[EMAIL PROTECTED]:/tmp$ cat foo.c
int foo(int x) {
return x * x;
}
int main(){}
[EMAIL PROTECTED]:/tmp$ gcc foo.c
[EMAIL PROTECTED]:/tmp$ gdb -q ./a.out
Using host libthread_db library
/lib/i686/cmov/libthread_db.so.1.
(gdb) b main
Breakpoint 1 at 0x804835e
(gdb) run
Starting program: /tmp/a.out
Failed to read a valid object file image from memory.
Breakpoint 1, 0x0804835e in main ()
(gdb) p foo(2)
$1 = 4
(gdb) p foo(10)
$2 = 100
(gdb) p foo(-1)
$3 = 1
(gdb) p foo(0)
$4 = 0
(gdb) p foo(2)+foo(4)
$5 = 20
(gdb) quit
The program is running. Exit anyway? (y or n) y
[EMAIL PROTECTED]:/tmp$
Makes most debugging tasks much easier.
Stefan
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
On Thu, Nov 29, 2007 at 12:40:00PM +, Simon Marlow wrote: What I'd *really* like to see is a bunch of links on the front page leading to pages that describe the main differences between Haskell and some other language (C, Python, Java, C#, F#, ...). The easiest way to grasp what Haskell is all about is by reference to a known baseline, and programmers tend to have different baselines. e.g. the C page might start with Haskell is a functional language, whereas the Python page might start with Haskell is statically typed. I guess this is similar to Ian's suggestion. +1 Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A tale of Project Euler
On Nov 29, 2007, at 6:19 PM, Stefan O'Rear wrote: On Thu, Nov 29, 2007 at 09:10:16PM +, Andrew Coppin wrote: Sebastian Sylvan wrote: On Nov 29, 2007 6:43 PM, Andrew Coppin [EMAIL PROTECTED] wrote: I don't understand the ST monad. ...[and ST uses language extensions Andrew doesn't understand.] (As far as ST goes, runST is unsafePerformIO renamed. The only tricky bit is proving safety.) To put it another way, runST is unsafePerformIO where somebody has already done the safety proof for you (so you know it's 100% safe). The strange extensions are simply a device to make the safety proof work. Indeed, if you drop the extensions it can all be made to work (just say runST :: ST () a - a) but you lose the safety proof and it's equivalent to unsafePerformIO. -Jan [The trick used in runST is one of my all-time favorite bits of type theory, and is what convinced me we wanted second-order types back before the first Haskell workshop.] ___ 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 29, 2007, at 16:57 , [EMAIL PROTECTED] wrote: Yitzchak Gale writes: Guido was forced to do something - someone had written a new Python interpreter, called Stackless Python, in which every Python function was a Scheme-like continuation. People found this very, very scary. So Guido stopped it by introducing laziness, which could be made much less scary. Give to Caesar... Someone, was Christian Tismer: http://www.python.org/workshops/2000-01/proceedings/papers/tismers/ spcpaper. htm and I am doubtful about the statement that people found it very, very scary. Simply they - usually - felt no The only person I've ever heard of who was in any sense scared of Stackless Python was GvR himself. -- 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] Re: New slogan for haskell.org
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. I agree with this. Perhaps Type Inference: deduces types automatically, so you don't have to clutter up your code with type declarations. You can still write type declarations for documentation purposes, and these will be automatically checked by the compiler. I also write top-level signatures usually, but inference is still really nice inside the function. Things like let x = f y in ... + g x + ... don't make you declare the type of 'x' and change the declaration if 'f' changes return type. You just have to change 'g', not everyone in between 'f' and 'g'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Optimizing cellular automata evaluation (round 2)
I posted awhile back asking for help improving my cellular automata program. I am competing with a C program which evolves CAs using a fairly simple genetic algorithm. The algorithm involves evaluating 100 rules on 100 CAs, 100 times. In C this takes about 1 second. In my Haskell version, it takes about 20 minutes. That's an improvement from my first attempts, which took 7 hours. All the time is spent in the function that evaluates one iteration of a given CA. It examines each cell and its neighbors and, based on the values found, updates the cell to be white or black. Here is the code, followed by an explanation of what it's doing. I'm looking for any suggestions on making this faster. Prettier helps too but not at the expense of speed. http://hpaste.org/4151#a0 I represent the automata as an array of integers, where each bit represents a cell. Automata 'wrap' around, so marching through the array and determing the value of all neighbors is tricky around the edges. My goal was to minimize conditionals as much as possible and to avoid any modulo arithmetic. I wanted to use straightforward array access. My implemention uses three functions: fill, fillS and fillE. Each evalutaion of fill will determine the new values for cells represented by the current array element. fill handles two conditions - when the array element being examined is the last element or when it is not. It calls fillS with appropriate arguments, the results of which become the value for the integer in the current array position. fillS then handles two conditions - when the neighborhood of the bit being examined crosses to the next array element and when it does not. When the neighborhood crosses to the next array element, fillE is called. fillE finishes determining the values for the remaining cells in the integer and returns, ending the current evaluation. There are some other details in the code (for example firstRule) which could be made faster and/or cleaner, but their contribution is far outweighed by the fill function. If there is one thing I'm happy about, its the memory performance of this code. It runs in a constant 7 - 10MB of memory, even when I'm doing 100 generations with 100 rules and 100 CAs. Each CA is evaluated for 250 steps, which means every generation does 2.5M steps. That kind of memory usage is pretty sweet. Thanks in advance to those willing to take the time to look at this code! Justin ___ 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
I must be missing something, because to me the contract seems to be much
simpler to express (than the Functor + Isomorphism route you seem to me
to be heading towards):
diff :: (Eq x,
Dense x,
Subtractible x,
Subtractible y,
Divisible y x yOverX) = (x - y) - x - yOverX
class Densea where addEpsilon :: a - a
class Subtractible a where takeAway :: a - a - a
class Divisiblea b c | a b - c
where divide :: a - b - c
Then diff is just:
diff f a = if dx == dx' then error Zero denom else dydx
where a' = addEpsilon a
dx = a' `takeAway` a
dx' = a`takeAway` a'
dy = f a' `takeAway` f a
dydx = dy `divide` dx
With the instances:
instance Dense Double where addEpsilon x = x * 1.001 + 1.0e-10
instance Dense Intwhere addEpsilon x = x + 1
instance Subtractible Double where takeAway x y = x - y
instance Subtractible Intwhere takeAway x y = x - y
instance Divisible Double Double Double where divide x y = x / y
instance Divisible IntIntIntwhere divide x y = x `div` y
and throwing in {-# OPTIONS_GHC -fglasgow-exts #-}, I get:
*Diff diff sin (0.0::Double)
1.0
*Diff diff (\x - x*7+5) (4::Int)
7
Dan Weston
Chris Smith wrote:
Hi Dan, thanks for answering.
Dan Piponi wrote:
When you specify that a function has type a - b, you're entering into
a bargain. You're saying that whatever object of type a you pass in,
you'll get a type b object back. a - b is a statement of that
contract.
Sure, that much makes perfect sense, and we agree on it.
Now your automatic differentiation code can't differentiate
any old function. It can only differentiate functions built out of the
finite set of primitives you've implemented (and other polymorphic
enough functions).
Sure. To be more specific, here's the contract I would really like.
1. You need to pass in a polymorphic function a - a, where a is, at
*most*, restricted to being an instance of Floating. This part I can
already express via rank-N types. For example, the diffFloating
function in my original post enforces this part of the contract.
2. I can give you back the derivative, of any type b - b, so long as b
is an instance of Num, and b can be generalized to the type a from
condition 1. It's that last part that I can't seem to express, without
introducing this meaningless type called AD.
There need be no type called AD involved in this contract at all.
Indeed, the only role that AD plays in this whole exercise is to be an
artifact of the implementation I've chosen. I could change my
implementation; I could use Jerzy's implementation with a lazy infinite
list of nth-order derivatives... or perhaps I could implement all the
operations of Floating and its superclasses as data constructors, get
back an expression tree, and launch Mathematica via unsafePerformIO to
calculate its derivative symbolically, and then return a function that
interprets the result. And who knows what other implementations I can
come up with? In other words, the type AD is not actually related to
the task at hand.
[...]
Luckily, there's a nice way to
express this. We can just say diff :: (AD a - AD a) - a - a. So AD
needs to be exported. It's an essential part of the language for
expressing your bargain, and I think it *is* the Right Answer, and an
elegant and compact way to express a difficult contract.
Really? If you really mean you think it's the right answer, then I'll
have to back up and try to understand how. It seems pretty clear to me
that it breaks abstraction in a way that is really rather dangerous.
If you mean you think it's good enough, then yes, I pretty much have
conluded it's at least the best that's going to happen; I'm just not
entirely comfortable with it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
Thomas Davie wrote: There's no such check list of good stuff with the Haskell slogan, instead, we've got a list of buzzwords, as bad as company webpages preaching that they offer synergised solutions, but not actually telling anyone what they do. I couldn't disagree more. The words used in the 'Haskell slogan' may be technical jargon; however as such they have a precisely defined meaning and actually characterize the language fine. This is exactly the opposite of 'buzzwords', which usually lack a clear and unambiguous definition (but are loved by marketing people). Cheers Ben ___ 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
Speaking of Stackless Python, its homepage (http://www.stackless.com/) has a rather nice layout... maybe slightly less emphasis on the About section, but there you've got the links, the info and the news all on the one page. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimizing cellular automata evaluation (round 2)
On Nov 29, 2007 10:31 PM, Justin Bailey [EMAIL PROTECTED] wrote: I represent the automata as an array of integers, where each bit represents a cell. Why don't you use an UArray of Bools? They're implemented as bit arrays internally, AFAIK (e.g. see http://www.haskell.org/haskellwiki/Shootout/Nsieve ). And then you would get rid of a lot of shifts and masks in your code -- clearer and faster, the Haskell Way (TM). Well, I guess it would be faster, but I can't really tell. Could you provide a main function implementing an use case for benchmark? Good luck. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
Yitzchak Gale writes: Haskell was not the first to have lazy lists, but Haskell was an important part of the inspiration for introducing them into Python. Jerzy Karczmarczuk wrote: Actually, I would *sincerely* like to see some reference proving that. The Python Library Reference, itertools (section 6.5 in Python 2.5): This module implements a number of iterator building blocks inspired by constructs from the Haskell and SML programming languages. Each has been recast in a form suitable for Python. Yitz, we will not quarrel, after all, we belong to the same Haskell mafia, but don't forget that itertools have been introduced in the version 2.3! It contained 'cycle', 'chain', 'dropwhile', etc. Here, I willingly sacrifice a cow to Haskell gods. But we were speaking about map and filter, and this is 1994... So, perhaps some concrete references - if given - should be tested against the historical truth. [Ohhh, my goodness... I realize that I am getting really old...] ... Give to Caesar...: It was Amrit Prem; one history page on WP says that no specific mention of any Lisp heritage is mentioned in the release notes at the time, so all speculations are still possible... OK. (That is a quote from Wikipedia, yes?) Yes. Partly. Indirectly. All speculations is mine. My source was here: http://www.python.org/search/hypermail/python-1994q2/0143.html Look, I am not arguing that this pseudo-laziness is a central feature of Python, ... So I agree with others who wrote that pointing out beautiful Haskell-inspired or Haskell-like features in a person's current favorite language might be a good way to encourage that person to have a look at Haskell. That is perfectly alright, and I assure you that I did my best to popularize the language in my local environment. However... There *IS* one danger with hypes. Several people deeply buried within other programming niches, accuse in permanence the Functionalists of being sectarian. I think that we should be modest and simple. Haskell is as any other language. Just a *very good* language. As such, it inspired others, and also, I think, it was inspired by others. Don't underline the uniqueness of the language. Notice that thanks to Haskell the DrScheme has now a lazy module. (Unless Eli Barzilay denies it...) But that laziness can be found in Snobol unevaluated expressions and Icon co-expressions, and these preceded Haskell. (Although I doubt that they influenced Haskell...) Nevertheless I think that it is psychologically convenient to underline that potential new users will find *many* familiar, or at least venerable concepts, only represented differently. All the best. Jerzy Karczmarczuk ___ 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-CafeDigest, Vol 51, Issue 180)
Duncan Coutts wrote: Tim Docker wrote: 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? It's usually worse than that. The most likely situation is that the C library and header files are not even installed. This is a big problem for all packages that wrap C libs. I wonder if this could be addressed by discarding the desire to run magically out of the box, but make the requirements clearer. Currently the choices seem to be: * Require the user to install these libs+headers just right (on the PATH or in certain MSYS directories) so that they are found. * Edit the cabal package file to point to the libs+headers Perhaps a worthwhile addition to cabal would be for it to be able to read a local config file, in which a user would specify where each package should get the necessary headers and libs? You'd manually create this file, maybe like: package: SDL include-dirs: c:\libs\SDL\include lib-dirs: c:\libs\SDL\lib package: curl include-dirs: c:\dev\mycurl\include lib-dirs: c:\dev\mycurl\lib When building a package X, cabal would consult this file to work out localised options for that package. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
On Nov 29, 2007, at 17:13 , Thomas Hartman wrote: but there's no risk using trace is there? If you're doing any other I/O, you may be surprised by where the trace output shows up relative to it. -- 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] Re: Re: Re: Hit a wall with the type system
Chris, I could change my implementation; I could use Jerzy's implementation...launch Mathematica... But all of these could be implemented by introducing a different type constructor called AD for each one. You could switch the implementation of AD on the user and they wouldn't have to change a line of their code. I've no doubt there's a real problem you're trying to solve, but I'm trying to figure out what it is. Can you post an example piece of code that would break if you exposed AD, and which means you need to hide it? (I fully understand the idea of abstracting over the algorithm, I'm just trying to pin down exactly why you need the abstraction, and what breaks if you don't have it.) -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell interface file (.hi) format?
Claus Reinke [EMAIL PROTECTED] wrote: Does anyone know if/where I can find a specification for the .hi files generated by GHC? I ask because I want to write an omni-completion plugin for Vim to make Haskell hacking a bit nicer. you might find it easier to use GHCi's :browse command $ ghc -e ':browse Control.Concurrent.MVar' modifyMVar :: MVar a - (a - IO (a, b)) - IO b modifyMVar_ :: MVar a - (a - IO a) - IO () readMVar :: MVar a - IO a swapMVar :: MVar a - a - IO a withMVar :: MVar a - (a - IO b) - IO b data MVar a = GHC.IOBase.MVar (GHC.Prim.MVar# GHC.Prim.RealWorld a) addMVarFinalizer :: MVar a - IO () - IO () isEmptyMVar :: MVar a - IO Bool newEmptyMVar :: IO (MVar a) newMVar :: a - IO (MVar a) putMVar :: MVar a - a - IO () takeMVar :: MVar a - IO a tryPutMVar :: MVar a - a - IO Bool tryTakeMVar :: MVar a - IO (Maybe a) that is what the haskell mode plugins for vim use, for one of their completion modes, anyway;-) http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/Vim/ (actually, that completion is wrt to imported identifiers, so we simply do a ':browse *current_module'; another completion mode is based on haddock indices, and then there are the standard occurs-in-imported-source-files and occurs-in-tags-file completions) claus Wow! Thanks for saving me a ton of work, everyone! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell interface file (.hi) format?
Hi Does anyone know if/where I can find a specification for the .hi files generated by GHC? I ask because I want to write an omni-completion plugin for Vim to make Haskell hacking a bit nicer. you might find it easier to use GHCi's :browse command Or you might want to try haddock with the --hoogle command. Similar thing, slightly different format - depends what suits you. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] A tale of Project Euler
Hello Andrew, Friday, November 30, 2007, 12:10:16 AM, you wrote: I don't understand the ST monad. From what I can tell, it's not definable without using strange language extensions. (I don't really like using things where it's unclear why it works.) this extension used only to guarantee referential transparency, so you don't need to understand it to use ST if you still want, it's not that hard - rank-2 forall type used here to guarantee that code executed by runST is compatible with *any* return type which makes it impossible to return innards of this computation and therefore forces your code to be referential transparent runST may be defined without rank-2 type. it doesn't change anything in its low-level working (this rank-2 type is just empty value, like RealWorld), but allows you to break referential transparency: main = do a - runST (do a - newArray return a) ... x - runST (do x - readArray a return x) ... low-level implementation of all ST-bound operations is just direct call to equivalent IO operation: newSTArray = unsafeIOtoST newIOArray readSTArray = unsafeIOtoST readIOArray where unsafeIOtoST - just code-less cast operation -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Haskell and DB : giving up
Hello Andrew, Thursday, November 29, 2007, 11:51:32 PM, you wrote: This is one of the more frustrating aspects of Haskell. It's not that nobody has written DB bindings - they most certainly have. It's not that nobody has written compression or cryptography bindings - they have. It's that there is a small zoo of them, and it's really hard to pick out which ones are the good ones. I really hope this does improve in time. (And I really wish I could do something positive to make this happen...) when i come to using ftp/http in my program, i wrote binding to wininet.dll in two days. this may be not reasonable for occasional scriptiong but at least works for larger apps -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] A tale of Project Euler
Hello Andrew, Thursday, November 29, 2007, 9:43:48 PM, you wrote: Fifth thing: better use an STUArray, don't drag IO in if it's not necessary. I don't understand the ST monad. it's just a subset of IO monad, with renamed operations the subset is selected in the way that guarantees reference transparency, i.e. compiler is able to do more checks that your program is correct. so, instead of writing main = do a - newArray writeArray a 1 3.14 x - readArray a 1 print x you can write main = do x - runST (do a - newArray writeArray a 1 3.14 x - readArray a 1 return x) print x -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast Array operations: foldl, drop
Bryan O'Sullivan [EMAIL PROTECTED] writes: For higher dimensions, there are enough options in terms of traversal direction and what exactly e.g. a fold should fold over (single elements? lower-dimensional slices?) that a sensible API doesn't exactly leap out. How about a 'reduce' instead of 'foldl1'? I think that if you require a commutative operator, the order doesn't matter (except for efficiency and possible rounding issues, I guess). -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] Progress indications
Andrew Coppin [EMAIL PROTECTED] writes: (BTW, what's the difference between unsafePerformIO and unsafeInterleaveIO?) Prelude :m + System.IO.Unsafe Prelude System.IO.Unsafe :t unsafePerformIO unsafePerformIO :: IO a - a Prelude System.IO.Unsafe :t unsafeInterleaveIO unsafeInterleaveIO :: IO a - IO a The former lets you cheat by pretending an IO action is a pure function, the latter, which really should be called 'notQuiteAsUnsafeInterleaveIO', just makes a strict IO action lazier, deferring it to when the result is demanded. -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
