RE: [Haskell-cafe] Quasiquoter invocation no longer requires/allows a leading dollar sign.
Good point. I've done this. (Ian, could you merge) Fri Nov 12 08:30:52 GMT 2010 simo...@microsoft.com * Allow the old [$foo| ... |] syntax for quasi-quotes This is just a backward-compatibility thing, to be removed eventually. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Michael Snoyman | Sent: 11 November 2010 22:08 | To: Haskell Cafe | Subject: [Haskell-cafe] Quasiquoter invocation no longer requires/allows a leading | dollar sign. | | Sorry, maybe I missed the memo on this one, but I just noticed this | change to quasi-quotation syntax on the GHC 7 upgrade page[1]. So if | GHC 6.12 *requires* the dollar sign, and GHC 7 *rejects* the dollar | sign, is there any way to write code that will run on both? Is there a | reason we can't keep the dollar sign as supported syntax for a release | or two to make for a cleaner migration? | | Michael | | [1] | http://haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_7#Quasiquotation:_. | 5B.24foo.7C7C.5D_-.3E_.5Bfoo.7C7C.5D | ___ | 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] Serialization of (a - b) and IO a
On Thursday 11 November 2010 9:23:13 pm Luke Palmer wrote: Admittedly, the class of reasoning I usually use in my Haskell programs, and the one that you talked about using earlier this message, is essentially seq doesn't exist. However, I prefer to use this class of reasoning because I would prefer if seq actually didn't exist (er, I think the implication goes the other way). seq can still exist, I think. And I still want it (well, I could leave it for functions, really, I think). What doesn't exist, loosely speaking, is bottom, which means: forall x y. x `seq` y = y And so seq = flip const. That makes things like: foo ... = ... (x `seq` y) ... appear useless, unless we remember that denotational semantics aren't the end- all and be-all, in which case we can recognize that seq is used as an operational hint to the compiler, same as par and pseq. It just happens to be the case that in Haskell's ordinary semantics, merely giving the denotational semantics of seq is sufficient to induce the right operational behavior, provided the compiler isn't bone headed (and further, is lenient enough to allow sufficiently smart compilers to disregard our naive 'evaluate x before y' reading of seq if it's more efficient to do so). Not so for serialize: I would like a serialize function, but I don't want the semantic burden it brings. If only there were a way to... oh yeah. serialize :: (a - b) - IO String I still don't really get what we're arguing about. I don't know. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Manatee - The Haskell/Gtk+ Integrated Live Environment first version release!
Hi Karel, I think is your cabal too old BTW, i suggest install GHC-6.12.3 with gtk2hs-0.12.0 and manatee. -- Andy Karel Gardas karel.gar...@centrum.cz writes: On 11/12/10 04:37, Andy Stewart wrote: Hi all, I have write Simple Manual at http://haskell.org/haskellwiki/Manatee Enjoy! :) Hello! I'm trying to follow installation steps on OpenSolaris 2009.06, but glib installation fails with: $ cabal install --user glib Resolving dependencies... Downloading glib-0.12.0... /tmp/glib-0.12.015451/glib-0.12.0/Gtk2HsSetup.hs:25:0: warning: #warning Setup.hs is guessing the version of Cabal. If compilation of Setup.hs fails use -DCABAL_VERSION_MINOR=x for Cabal version 1.x.0 when building (prefixed by --ghc-option= when using the 'cabal' command) [1 of 2] Compiling Gtk2HsSetup ( /tmp/glib-0.12.015451/glib-0.12.0/Gtk2HsSetup.hs, /tmp/glib-0.12.015451/glib-0.12.0/dist/setup/Gtk2HsSetup.o ) /tmp/glib-0.12.015451/glib-0.12.0/Gtk2HsSetup.hs:56:2: Module `Distribution.Simple.PackageIndex' does not export `lookupPackageId' cabal: Error: some packages failed to install: glib-0.12.0 failed during the configure step. The exception was: ExitFailure 1 My cabal is: $ cabal --version cabal-install version 0.8.2 using version 1.8.0.2 of the Cabal library And ghc is: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 Do you have any idea what to do with this failure? i.e. is my cabal old or is it something different... Thanks, Karel PS: Manatee screenshots are amazing and your code lines list even more! -- Andy Andy Stewart lazycat.mana...@gmail.com writes: Hi all, I am proud to announce the release my gtk2hs project : Manatee - The Haskell/Gtk+ Integrated Live Environment http://hackage.haskell.org/package/manatee Screenshots at : http:goo.gl/MkVw Code at https://patch-tag.com/r/AndyStewart/ beginning with manatee-* Manatee is Haskell integrated environment written in Haskell. The goal of the Manatee project is to provide a fast, safe and flexible integrated environment for haskell hacking. You can consider it is new environment mix Gnome and Emacs. Like Gnome to provide friendly graphics interface and work efficient like Emacs. Manatee use multi-processes framework, any sub-module running in separate process to protected core won't crash. So it minimize your losses when some unexpected exception throw in extension. Now i have implement below sub-modules in Manatee: Editor Webkit Browser File Manager Image Viewer IRC Client Multimedia Player PDF Viewer Process Manager RSS/Atom reader From some friends feedback, manatee can't work in XMonad, i will fix it soon. You can play it in Gnome. Enjoy! :) Below are steps to build Manatee: 1) Install C library: In Debian use below command: sudo aptitude install libgtksourceview2.0-dev libgconf2-dev libwebkit-dev libcurl4-openssl-dev libgtkimageview-dev libpoppler-glib-dev poppler-data libtagc0-dev -y 2) Install Gtk2hs: cabal install gtk2hs-buildtools gtk And make sure HOME.cabalbin/ in your PATH. 3) Install Manatee: cabal install manatee-core manatee-anything manatee-browser manatee-editor manatee-filemanager manatee-imageviewer manatee-ircclient manatee-mplayer manatee-pdfviewer manatee-processmanager manatee-reader manatee That's all, then type command manatee to play it! :) manatee-core manatee-anything manatee are core packages, must be install, other extension package you can choose you want. Example, if you not install manatee-imageviewer, when you open Image file, manatee will call default image-viewer in your system instead. Manatee will show you search interface when you startup it. You can type some filepath or url to open it, example, you can type Haskell file to open in editor, and type url to open in browser. Below are quick play keys: F2 == startProcessManager F3 == startFeedReader F4 == startFileManager F5 == startBrowser F6 == loginIrcDefaultChannel F7 == startIrc Manatee project still in early develop stage, just core framework finish, many details still not perfect. But i think it's good start to build Real-World application in Haskell. Below are high task in my TODO list: Perfect current sub-module: IDE features, code completion browser JavaScript framework graphics custom system etc. Terminal emulator: support MVC design, not like VTE widget Mail-client BT-Client Proxy bridge: to build uniform proxy interface to fighting GFW!!! Jabbar client: video support etc. Spell checker CHM viewer DVI viewer LaTex editor PS viewer Multi-thread download manager Org-Mode :
Re: [Haskell-cafe] Serialization of (a - b) and IO a
C. McCann c...@uptoisomorphism.net writes: This was my first thought as well! However, reading to/from a file would of course be in IO, at which point you'd be free to read the file back in through normal means to get at the representation. So in that respect, this is equivalent to (a - b) - IO String. IMO, it's morally different, you're now operating on a file, and you shouldn't rely on the contents being predictable. You can make the sin-bin argument that IO can do anything, but I think there's a moral distinction between serialize :: a - IO ByteString x - serialize f and serialize :: a - Opaque store :: Opaque - FilePath - IO () do x - serialize f store x n B.readFile n You could probably already snarf chunks of the heap and dump them to file. I suppose one could object that this isn't actually serializing anything at all; to which I would respond that, in pure code, how do you expect to tell the difference? Nice one :-) I guess the real question is what are the useful, pure operations on an opaque type that can contain arbitrary functions. -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] Serialization of (a - b) and IO a
On Thu, Nov 11, 2010 at 10:28 PM, Dan Doel dan.d...@gmail.com wrote: On Thursday 11 November 2010 12:34:21 pm John Lato wrote: I think the only way this would work would be if you consider functions to be equal only to themselves, i.e. x+x and 2*x are not equal. That's not a trade-off I would be willing to make. In general, it doesn't even have to be based on a mathematical identity. As has been stated, this would in general simply break referential transparency. Are these two functions equal: f x = k (h x) (h x) g x = let y = h x in k y y Presumably, no, if serialize exists (and they may have different performance characteristics). You cannot factor out or inline subexpressions or without the difference being observable (presumably) by serialize. Yes, exactly. Thanks for this example, because it illustrates better how far-reaching this would be. And it's true not just when these transformations are manually performed, but also when they're performed by the compiler. Haskell without referential transparency simply wouldn't be Haskell any more. And any code that used a pure serialize may or may not work, depending on compiler magic. Of course, this is presuming that serialize is pure. I suppose it might be possible for a serialize with type a - IO ByteString to just dump stack+heap+whatever. You could use TH+Hint, LLVM, or likewise to get a similar effect now. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-cafe] Serialization of (a - b) and IO a
Message: 3 Date: Thu, 11 Nov 2010 18:56:00 +0100 From: Sjoerd Visscher sjo...@w3future.com On Nov 11, 2010, at 6:34 PM, John Lato wrote: I don't know to what extent it would apply in this hypothetical situation, but ghc (and probably other compilers) rely upon Haskell's semantics in performing various code transformations. If you break the semantics some transformations become invalid, resulting in incorrect code. I've experienced this with code that violated ref. transparency. The program behavior changed depending on the compiler's optimization settings. I'm not keen to go back to that. Then don't do that. Being able to serialize functions is just as dangerous as having unsafePerformIO. If you don't use it, you don't have problems. If you do use serialize, I think it would cause problems most of the time. A pure serialization would violate referential transparency. GHC relies upon referential transparency for some transformations to be valid. Therefore it's not possible to use a pure serialization function safely unless the user can guarantee that it's only used in a referentially transparent manner, which is an extremely high barrier IMO (higher than for unsafePerformIO). John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Opportunity for Haskell porting to java at RD labs in Bay Area, CA
David Fox dds...@gmail.com writes: I would hesitate to call it a terrible decision unless I had a good idea of what the ratio of Java programmers to Haskell programmers was out in the world. Just sayin... I'm not sure the ratio is very interesting, presumably they only need one or at most a few. Possibly they wouldn't be able to hire the experienced Haskell programmer anyway (which is what you imply) and then advertising for a Java programmer only is a good decision in that it saves them some advertising cost... :-) -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] Splittable random numbers
On 11/11/10 21:34, Luke Palmer wrote:
On Thu, Nov 11, 2010 at 3:13 AM, Richard Seningtonsc06...@leeds.ac.uk wrote:
I got hold of, and looked through the paper suggested in the root of this
thread “Pseudo random trees in Monte-Carlo, and based upon this
I have thrown together a version of the binary tree based random number
generator suggested.
I would like to point out that I do not know very much about random number
generators, the underlying mathematics or any subsequent papers on this
subject, this is just a very naive implementation based upon this one paper.
As a question, the following code actually generates a stream of numbers
that is more random than I was expecting, if anyone can explain why I would
be very interested.
What do you mean more random than you were expecting? Shouldn't they
be maximally random?
My issue is how it should react, given how the underlying data structure
works.
If you just use this tree to generate numbers, you are taking
Left,Left,Left .
If you split the tree, you get Left and Right.
So, in my test code at the bottom I have taken a generator and then
generated 10 numbers from it.
Then we split. The left hand branch (g1 in the test) should generate
numbers that are just tail.randoms $ gen
but this is not what happens, at least not for raw integers.
I have been doing some more testing, and if you limit the range (0-1000
seems to be stable) then it works as described above, however
if you use wider ranges, or even the maximum range, then the sequences
do not match as expected.
This worries me, as one advantage of PRNGs (see paper as I am
paraphrasing) is repeatability, or certain expected properties.
The underlying system is working, so I probably have the range or data
type conversion wrong somewhere.
You can test the underlying tree like so.
rawTest :: LehmerTree-IO()
rawTest t = do print $ myTake 10 t
print $ myTake 10 $ leftBranch t
print $ myTake 10 $ rightBranch t
where
myTake 0 _ = []
myTake x t = nextInt t : (myTake (x-1) (leftBranch t))
BTW, nice module. Do you want to hackage it up? If not, I will.
I would be happy to hackage it up, but I think this is a bit premature.
I started to read a bit more about PRNGs, and I came across tests for
randomness. It seemed that a library of test systems for RandomGens
would be quite cool, so I started coding last night. That is far too
premature to even post up here, but in short, this system gives some
very odd results.
For example, mean averages (I tried medians but that did not tell me
much, I am going to look at modals some time this weekend).
mean :: [Float]-Double
mean [] = error empty list has no mean?
mean xs = ((sum.(map realToFrac)) xs) / (fromIntegral.length $ xs)
rangedMeanTest :: RandomGen g=g-Int-(Int,Int)-Double
rangedMeanTest g count range = let p = take count $ randomRs range g
in mean (map fromIntegral p)
So, I am testing discrete randomness, ints. We take a range we wish to
generate (0-3 for example), and generate some number of test values (I
used 1000).
This list is converted into floats, and averaged. We can then predict
what we think the average should be, given that this is an unbiased
uniform (or nearly uniform) system.
It does not give the results you would want. This may have something to
do with picking good parameters for the mkLehmerTree function.
For example, using a random setup, I just got these results
result expected range
16.814 expected = 16.0 (1,31)
16.191 expected = 16.5 (1,32)
16.576 expected = 17.0 (1,33)
17.081 expected = 17.5 (1,34)
17.543 expected = 18.0 (1,35)
In short, I am worried by the properties of this random number
generator. I propose improving the testing system, and then posting both
the test suite and this random generator to
Hackage, unless you really want it up now in a very very preliminary form.
RS
import System.Random
data LehmerTree = LehmerTree {nextInt :: Int,
leftBranch :: LehmerTree,
rightBranch :: LehmerTree}
instance Show LehmerTree where
show g = LehmerTree, current root = ++(show $ nextInt g)
mkLehmerTree :: Int-Int-Int-Int-Int-Int-LehmerTree
mkLehmerTree aL aR cL cR m x0 = innerMkTree x0
where
mkLeft x = (aL * x + cL) `mod` m
mkRight x = (aR * x + cR) `mod` m
innerMkTree x = let l = innerMkTree (mkLeft x)
r = innerMkTree (mkRight x)
in LehmerTree x l r
mkLehmerTreeFromRandom :: IO LehmerTree
mkLehmerTreeFromRandom = do gen-getStdGen
let a:b:c:d:e:f:_ = randoms gen
return $ mkLehmerTree a b c d e f
This can be pure:
mkLehmerTreeFromRandom :: (RandomGen g) = g - LehmerTree
instance RandomGen LehmerTree where
next g = (fromIntegral.nextInt $ g, leftBranch g)
split g = (leftBranch g,
Re: [Haskell-cafe] Quasiquoter invocation no longer requires/allows a leading dollar sign.
Thank you very much. I was dreading the thought of figuring out some CPP hack to accomplish this, and applying it across my codebase. Much appreciated! MIchael On Fri, Nov 12, 2010 at 10:38 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Good point. I've done this. (Ian, could you merge) Fri Nov 12 08:30:52 GMT 2010 simo...@microsoft.com * Allow the old [$foo| ... |] syntax for quasi-quotes This is just a backward-compatibility thing, to be removed eventually. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On | Behalf Of Michael Snoyman | Sent: 11 November 2010 22:08 | To: Haskell Cafe | Subject: [Haskell-cafe] Quasiquoter invocation no longer requires/allows a leading | dollar sign. | | Sorry, maybe I missed the memo on this one, but I just noticed this | change to quasi-quotation syntax on the GHC 7 upgrade page[1]. So if | GHC 6.12 *requires* the dollar sign, and GHC 7 *rejects* the dollar | sign, is there any way to write code that will run on both? Is there a | reason we can't keep the dollar sign as supported syntax for a release | or two to make for a cleaner migration? | | Michael | | [1] | http://haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_7#Quasiquotation:_. | 5B.24foo.7C7C.5D_-.3E_.5Bfoo.7C7C.5D | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] dynamic loading of code on windows
Hello, I recently tried to cabal install plugins on a windows box and it failed with the following error: Resolving dependencies... Downloading plugins-1.5.1.4... Configuring plugins-1.5.1.4... cabal: The package has a './configure' script. This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. cabal: Error: some packages failed to install: plugins-1.5.1.4 failed during the configure step. The exception was: ExitFailure 1 What solution can I use to load dynamically code in a cross-platform way ? Thanks in advance Arnaud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Quasiquoter invocation no longer requires/allows a leading dollar sign.
On Fri, 12 Nov 2010 08:38:24 +, Simon Peyton-Jones simo...@microsoft.com wrote: Good point. I've done this. (Ian, could you merge) Thank you very much for this! I was afraid to see so much code broken as well as Michael. Best regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Manatee - The Haskell/Gtk+ Integrated Live Environment first version release!
On Thu, Nov 11, 2010 at 9:07 PM, Andy Stewart lazycat.mana...@gmail.comwrote: David Leimbach leim...@gmail.com writes: Wow! Is this just for Linux or is anyone able to run it on Mac OS X? I don't know whether can work on Mac. I design it for Linux. Fair enough, it's a great accomplishment all the same :-). Dave -- Andy Dave On Thu, Nov 11, 2010 at 7:51 PM, Andy Stewart lazycat.mana...@gmail.com wrote: My project want to provide a fact: Haskell not just can do GUI environment, and can do better! Gtk2hs + Haskell Threads is awesome! Below is source code lines of Manatee: All : 21651 Core and toolkit : 7047 Daemon and Window Manager: 3656 Multi-Threads input framework: 2537 Browser : 488 Editor : 813 File manager : 774 Image viewer : 565 IRC client : 2212 Multimedia player: 1358 PDF viewer : 457 Process Manager : 761 RSS/Atom reader : 893 -- Andy Andy Stewart lazycat.mana...@gmail.com writes: Hi all, I am proud to announce the release my gtk2hs project : Manatee - The Haskell/Gtk+ Integrated Live Environment http://hackage.haskell.org/package/manatee Screenshots at : http:goo.gl/MkVw Code at https://patch-tag.com/r/AndyStewart/ beginning with manatee-* Manatee is Haskell integrated environment written in Haskell. The goal of the Manatee project is to provide a fast, safe and flexible integrated environment for haskell hacking. You can consider it is new environment mix Gnome and Emacs. Like Gnome to provide friendly graphics interface and work efficient like Emacs. Manatee use multi-processes framework, any sub-module running in separate process to protected core won't crash. So it minimize your losses when some unexpected exception throw in extension. Now i have implement below sub-modules in Manatee: Editor Webkit Browser File Manager Image Viewer IRC Client Multimedia Player PDF Viewer Process Manager RSS/Atom reader From some friends feedback, manatee can't work in XMonad, i will fix it soon. You can play it in Gnome. Enjoy! :) Below are steps to build Manatee: 1) Install C library: In Debian use below command: sudo aptitude install libgtksourceview2.0-dev libgconf2-dev libwebkit-dev libcurl4-openssl-dev libgtkimageview-dev libpoppler-glib-dev poppler-data libtagc0-dev -y 2) Install Gtk2hs: cabal install gtk2hs-buildtools gtk And make sure HOME.cabalbin/ in your PATH. 3) Install Manatee: cabal install manatee-core manatee-anything manatee-browser manatee-editor manatee-filemanager manatee-imageviewer manatee-ircclient manatee-mplayer manatee-pdfviewer manatee-processmanager manatee-reader manatee That's all, then type command manatee to play it! :) manatee-core manatee-anything manatee are core packages, must be install, other extension package you can choose you want. Example, if you not install manatee-imageviewer, when you open Image file, manatee will call default image-viewer in your system instead. Manatee will show you search interface when you startup it. You can type some filepath or url to open it, example, you can type Haskell file to open in editor, and type url to open in browser. Below are quick play keys: F2 == startProcessManager F3 == startFeedReader F4 == startFileManager F5 == startBrowser F6 == loginIrcDefaultChannel F7 == startIrc Manatee project still in early develop stage, just core framework finish, many details still not perfect. But i think it's good start to build Real-World application in Haskell. Below are high task in my TODO list: Perfect current sub-module: IDE features, code completion browser JavaScript framework graphics custom system etc. Terminal emulator: support MVC design, not like VTE widget Mail-client BT-Client Proxy bridge: to build uniform proxy interface to fighting GFW!!! Jabbar client: video support etc.
[Haskell-cafe] Re: [Haskell] ANNOUNCE: The Fibon benchmark suite (v0.2.0)
Hi Jason, Sorry for the delayed response. Thanks for pointing out the darcs-benchmark package. I had not seen that before and there may be some room for sharing infrastructure. Parsing the runtime stats is pretty easy, but comparing different runs, computing statistics, and generating tables should be a common task. On a related note, when I uploaded the fibon package, I put it in a new Benchmarking category as opposed to the existing Testing category. In my mind testing is more for correctness and benchmarking is for performance. I think it would be useful to include other benchmarking packages (darcs-benchmark, criterion) in that category. -- From: Jason Dagit da...@codersbase.com Sent: Tuesday, November 09, 2010 7:58 PM To: David Peixotto d...@rice.edu Cc: hask...@haskell.org; haskell-cafe@haskell.org Subject: Re: [Haskell] ANNOUNCE: The Fibon benchmark suite (v0.2.0) On Tue, Nov 9, 2010 at 5:47 PM, David Peixotto d...@rice.edu wrote: On Nov 9, 2010, at 3:45 PM, Jason Dagit wrote: I have a few questions: * What differentiates fibon from criterion? I see both use the statistics package. I think the two packages have different benchmarking targets. Criterion allows you to easily test individual functions and gives some help with benchmarking in the presence of lazy evaluation. If some code does not execute for a long time it will run it multiple times to get sensible timings. Criterion does a much more sophisticated statistical analysis of the results, but I hope to incorporate that into the Fibon analysis in the future. Fibon is a more traditional benchmarking suite like SPEC or nofib. My interest is using it to test compiler optimizations. It can only benchmark at the whole program level by running an executable. It checks that the program produces the correct output, can collect extra metrics generated by the program, separates collecting results from analyzing results, and generates tables directly comparing the results from different benchmark runs. * Does it track memory statistics? I glanced at the FAQ but didn't see anything about it. Yes, it can read memory statistics dumped by the GHC runtime. It has built in support for reading the stats dumped by `+RTS -t --machine-readable` which includes things like bytes allocated and time spent in GC. Oh, I see. In that case, it's more similar to darcs-benchmark. Except that darcs-benchmark is tailored specifically at benchmarking darcs. Where they overlap is parsing the RTS statistics, running the whole program, and tabular reports. Darcs-benchmark adds to that an embedded DSL for specifying operations to do on the repository between benchmarks (and translating those operations to runnable shell snippets). I wonder if Fibon and darcs-benchmark could share common infrastructure beyond the statistics package. It sure sounds like it to me. Perhaps some collaboration is in order. * Are the numbers in the sample output seconds or milliseconds? What is the stddev (eg., what does the distribution of run-times look like)? I'm not sure which results you are referring to exactly (the numbers in the announcement were lines of code). I picked benchmarks that all ran for at least a second (and hopefully longer) with compiler optimizations enabled. On an 8-core Xeon, the median time over all benchmarks is 8.43 seconds, mean time is 12.57 seconds and standard deviation is 14.56 seconds. I probably read your email too fast, sorry. Thanks for the clarification. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: dynamic loading of code on windows
This isn't about the plugin functionality, it's about compiling code. As the message says : This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. You'll find that you need such a toolchain to compile much open source software, including many Haskell modules, on Windows. Personally I use MinGW+MSYS on my Windows machine. It works very well. Kevin On Nov 12, 3:20 pm, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to cabal install plugins on a windows box and it failed with the following error: Resolving dependencies... Downloading plugins-1.5.1.4... Configuring plugins-1.5.1.4... cabal: The package has a './configure' script. This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. cabal: Error: some packages failed to install: plugins-1.5.1.4 failed during the configure step. The exception was: ExitFailure 1 What solution can I use to load dynamically code in a cross-platform way ? Thanks in advance Arnaud ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://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] Serialization of (a - b) and IO a
On Fri, Nov 12, 2010 at 4:24 AM, Ketil Malde ke...@malde.org wrote: IMO, it's morally different, you're now operating on a file, and you shouldn't rely on the contents being predictable. You can make the sin-bin argument that IO can do anything, but I think there's a moral distinction between serialize :: a - IO ByteString x - serialize f and serialize :: a - Opaque store :: Opaque - FilePath - IO () Any distinction here is mostly at the level of API design and informal semantics; I'm inclined to agree with your preference, but as far as impacts on the formal semantics of pure code go, these are essentially equivalent. You could probably already snarf chunks of the heap and dump them to file. Yep, and this is pretty much the reason, taken to its logical conclusion, why almost all bets are off about what IO computations can potentially do. I suppose one could object that this isn't actually serializing anything at all; to which I would respond that, in pure code, how do you expect to tell the difference? Nice one :-) I guess the real question is what are the useful, pure operations on an opaque type that can contain arbitrary functions. I would be very surprised if there were any that couldn't just as well be done on the function directly. Even extracting type information could be problematic if done incorrectly! Consider a function (inspectType :: Opaque - Serialization.Type), where the Show instance for Type produces an approximation of the type signature the function was declared with. Reasonable? Nope, we just broke everything. Imagine a function taking an argument of type ((a, a) - a). If by serializing the argument it can recover the declared type signature it could distinguish between fst and ((\(x, _) - x) :: forall a. (a, a) - a), which again opens the door to non-parametric behavior. On the other hand, (inspectType :: Opaque - Data.Typeable.TypeRep) would probably be safe, because it supports only monomorphic types. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: dynamic loading of code on windows
Hello Kevin, Thanks. I understand that this is a toolchain issue, I just got used to the nice feeling of having 'cabal install foo' works seamlessly and flawlessly to get me some magic piece of software :-) I will try to be more patient and try to setup a proper toolchain for installing plugins package. Arnaud On Fri, Nov 12, 2010 at 7:01 PM, Kevin Jardine kevinjard...@gmail.com wrote: This isn't about the plugin functionality, it's about compiling code. As the message says : This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. You'll find that you need such a toolchain to compile much open source software, including many Haskell modules, on Windows. Personally I use MinGW+MSYS on my Windows machine. It works very well. Kevin On Nov 12, 3:20 pm, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to cabal install plugins on a windows box and it failed with the following error: Resolving dependencies... Downloading plugins-1.5.1.4... Configuring plugins-1.5.1.4... cabal: The package has a './configure' script. This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. cabal: Error: some packages failed to install: plugins-1.5.1.4 failed during the configure step. The exception was: ExitFailure 1 What solution can I use to load dynamically code in a cross-platform way ? Thanks in advance Arnaud ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serialization of (a - b) and IO a
On Thu, 11 Nov 2010, Dan Doel wrote:
intensional equality: two values are provably equal if they evaluate to the
same normal form
extensional equality: this incorporates non-computational rules, like the
point-wise equality of functions.
Now, in a type theory where equality is intensional, I cannot prove:
(forall x. f x = g x) - f = g
However, both these equalities (and others in between and on either side) are
*compatible*, in that I cannot disprove the above theorem in an intensional
theory.
What seq and serialize do is break from extensional equality, and allow us to
disprove the above (perhaps not for seq within a hypothetical theory, since
the invalidating case involves non-termination, but certainly for serialize).
And that's a big deal, because extensional equality is handy for the above
reasoning about programs.
As you are well aware in Coq, and in Agda we don't have an extensionality
axiom; however this is not a problem because we simply use setoid equality
to capture extenional reasoning and prove that in every specific case
where we want to use extensioanl reasoning it is sound to do so.
Now suppose I add the following consitent axiom to Coq:
Axiom Church-Turing :
forall f:Nat - Nat, exists e:Nat, forall n:Nat, {e}(n) = f(n)
This well-studied axiom is effectively what serialize is realizing[1].
Now, have I broken my old Coq proofs by adding this axiom? No, of course
not, because it is a consistent axioms and my proofs didn't use it. My
proofs were alreay explicity proving that extentional substitution was
sound in those cases I was using it.
The same will be true for reasoning in Haskell. Before serialization we
knew that extensional substitution was sound, but after adding
serialization we are now obligated to prove in the individual cases that
extensional subsitution is sound and/or add extentionally preconditions to
our proofs. So no big deal; people have already been doing this in Coq
and Agda for years.
[1]Actaully the realizer for serialize is *weaker* that this axioms. The
realizer for serialize would be (Nat - Nat) - IO Nat instead of (Nat -
Nat) - Nat, so should have less impact that the Church-Turing axiom.
--
Russell O'Connor http://r6.ca/
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] an evil type hangs GHC
Hi, I was playing with the following example I found in D.A.Turner's paper Total Functional Programming: data Bad a = C (Bad a - a) bad1 :: Bad a - a bad1 b@(C f) = f b bad2 :: a bad2 = bad1 (C bad1) To my surprise, instead of creating a bottom valued function (an infinite loop), I managed to send the GHC compiler (ver. 6.12.1) to an infinite loop. Could anybody suggest an explanation? Is this a GHC bug? Or is this Bad data type so evil that type checking fails? Thanks, Petr signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serialization of (a - b) and IO a
On Nov 12, 2010, at 10:40 AM, rocon...@theorem.ca wrote: [1]Actaully the realizer for serialize is *weaker* that this axioms. The realizer for serialize would be (Nat - Nat) - IO Nat instead of (Nat - Nat) - Nat, so should have less impact that the Church-Turing axiom. I don't see where IO comes in if you're dealing with pure functions. Serializing pure structures is really really easy and can be done entirely purely. The tricky part is finding a good encoding. As I said in my original message on this topic, you are embedding a compiler and interpreter into your runtime. That can be as easy as what is below, or as tricky as embedding GHC in your runtime, or anywhere in between. But you simply cannot serialize IO actions without the GHC runtime. The GHC runtime sequences IO actions in ways that depend on the unserializable environment. (Imposed) Sequencing + Concrete representation = Serialization. class Serialize a where serialize :: a - ByteString unSerialize :: ByteString - Maybe a -- Parsers can fail instance (Serialize a) = Serialize [a] where ... instance (Serialize a, Serialize b) = Serialize (a, b) where ... -- We can conclude that a and b must be enumerable from the requirement that -- f is recursively enumerable: instance (Serialize a, Enum a, Serialize b, Enum b) = Serialize (a - b) where serialize f = serialize $ ( zip [minBound..maxBound] (fmap f [minBound..maxBound]) ) -- A map instance might be better: we trade some serialization time for more -- deserialization time. instance (Serialize a, Serialize b) = Serialize (Map a b) where ... instance (Enum a, Enum b, Serialize a, Serialize b) = Serialize (a - b) where serialize f = serialize . fromList $ ( zip [minBound..maxBound] (fmap f [minBound..maxBound]) ) deserialize map = \x - lookup x (bytestring_decode_map map) where bytestring_decode_map = ...___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] an evil type hangs GHC
On Fri, Nov 12, 2010 at 07:52:53PM +0100, Petr Pudlak wrote: Hi, I was playing with the following example I found in D.A.Turner's paper Total Functional Programming: data Bad a = C (Bad a - a) bad1 :: Bad a - a bad1 b@(C f) = f b bad2 :: a bad2 = bad1 (C bad1) To my surprise, instead of creating a bottom valued function (an infinite loop), I managed to send the GHC compiler (ver. 6.12.1) to an infinite loop. Could anybody suggest an explanation? Is this a GHC bug? Or is this Bad data type so evil that type checking fails? Thanks, Petr PS: The following code compiles, the difference is just in modifying bad2 to include an argument: data Bad a = C (Bad a - a) bad1 :: Bad a - a bad1 b@(C f) = f b bad2 :: (a - a) - a bad2 f = bad1 (C $ f . bad1) [BTW, bad2 has the type of the Y combinator and indeed works as expected: factorial :: (Int - Int) - Int - Int factorial _ 0 = 1 factorial r n = n * (r (n-1)) main :: IO () main = print $ map (bad2 factorial) [1..10] ... so one can get general recursion just by crafting such a strange data type.] signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] an evil type hangs GHC
See http://www.haskell.org/pipermail/haskell/2006-September/018497.html On Fri, 12 Nov 2010, Petr Pudlak wrote: On Fri, Nov 12, 2010 at 07:52:53PM +0100, Petr Pudlak wrote: Hi, I was playing with the following example I found in D.A.Turner's paper Total Functional Programming: data Bad a = C (Bad a - a) bad1 :: Bad a - a bad1 b@(C f) = f b bad2 :: a bad2 = bad1 (C bad1) To my surprise, instead of creating a bottom valued function (an infinite loop), I managed to send the GHC compiler (ver. 6.12.1) to an infinite loop. Could anybody suggest an explanation? Is this a GHC bug? Or is this Bad data type so evil that type checking fails? Thanks, Petr PS: The following code compiles, the difference is just in modifying bad2 to include an argument: data Bad a = C (Bad a - a) bad1 :: Bad a - a bad1 b@(C f) = f b bad2 :: (a - a) - a bad2 f = bad1 (C $ f . bad1) [BTW, bad2 has the type of the Y combinator and indeed works as expected: factorial :: (Int - Int) - Int - Int factorial _ 0 = 1 factorial r n = n * (r (n-1)) main :: IO () main = print $ map (bad2 factorial) [1..10] ... so one can get general recursion just by crafting such a strange data type.] -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: dynamic loading of code on windows
Il 12/11/2010 19:01, Kevin Jardine ha scritto: This isn't about the plugin functionality, it's about compiling code. As the message says : This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. Is it really necessary to use autoconf? I have read the autoconf.ac file and I'm not sure to understand why autoconf is used. Regards Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: dynamic loading of code on windows
I use Hint for the same purpose. It has been tested under windows 2010/11/12 Arnaud Bailly arnaud.oq...@gmail.com Hello Kevin, Thanks. I understand that this is a toolchain issue, I just got used to the nice feeling of having 'cabal install foo' works seamlessly and flawlessly to get me some magic piece of software :-) I will try to be more patient and try to setup a proper toolchain for installing plugins package. Arnaud On Fri, Nov 12, 2010 at 7:01 PM, Kevin Jardine kevinjard...@gmail.com wrote: This isn't about the plugin functionality, it's about compiling code. As the message says : This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. You'll find that you need such a toolchain to compile much open source software, including many Haskell modules, on Windows. Personally I use MinGW+MSYS on my Windows machine. It works very well. Kevin On Nov 12, 3:20 pm, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, I recently tried to cabal install plugins on a windows box and it failed with the following error: Resolving dependencies... Downloading plugins-1.5.1.4... Configuring plugins-1.5.1.4... cabal: The package has a './configure' script. This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. cabal: Error: some packages failed to install: plugins-1.5.1.4 failed during the configure step. The exception was: ExitFailure 1 What solution can I use to load dynamically code in a cross-platform way ? Thanks in advance Arnaud ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp:// www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell is a scripting language inspired by Python.
On 11/11/2010 04:12 PM, Simon Marlow wrote: On 04/11/2010 22:38, Lennart Augustsson wrote: The smallest Haskell I know of is Gofer/Hugs; it originally ran on a 640k PCs. Before that languages like SASL and KRC ran on PDP-11 with 64k memory. None of these had a compiler that was bootstrapped, but I had a simple functional language that compiled itself and ran in 64K. The smallest bootstrapped Haskell compiler is NHC which (I think) runs in a few MB. I bootstrapped GHC from the intermediate C files on a 640K PC around 1993 or so. I don't remember exactly, but I think it might have worked, for some small value of work. Wow! Your name must be Simon or... oh, wait... And to think that in 1993 I was still playing with BASIC. :-( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Directed Name Resolution
On 11/11/2010 08:43 PM, Richard O'Keefe wrote: If length, map, and so on had always been part of a Sequence typeclass, people would not now be talking about We have a winner... It's always puzzled me that Haskell's standard containers almost completely lack any way to use them polymorphically. Maybe once people stop hating ATs it will start getting fixed... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Better Records was Re: [Haskell-cafe] Type Directed Name Resolution
On 11/11/2010 11:48 PM, John Lask wrote: again quoting http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html Haskell lacks a serious record system. (The existing mechanism for named fields in data types was always seen as a stop-gap measure.) isn't it about time this changed? Records do leave quite a bit to be desired. But does anybody actually have a concrete alternative proposal yet? Personally I'm not really keen on TDNR; I'd prefer records that aren't so inconvenient. But I have no idea how to design that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Directed Name Resolution
On 12 Nov 2010, at 20:21, Andrew Coppin wrote: On 11/11/2010 08:43 PM, Richard O'Keefe wrote: If length, map, and so on had always been part of a Sequence typeclass, people would not now be talking about It's always puzzled me that Haskell's standard containers almost completely lack any way to use them polymorphically. On the contrary, there is the Edison package of containers and algorithms, since at least the late 90's, which has type classes for all of the common operations. It is high quality, and kind-of the ideal standard in an academic sort of way, except that almost nobody uses it. In particular, ghc did not use it internally, choosing Data.Map instead, and the legendary suspicion of programmers who refuse to use a alternative library replacing one that already comes with their compiler, means that nobody else did either. Either that, or people find it awkward to deal with the substantial extra hierarchies of type classes. Edison-API and Edison-core are available on hackage by the way. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
On Fri, Nov 12, 2010 at 3:33 AM, Richard Senington sc06...@leeds.ac.uk wrote:
In short, I am worried by the properties of this random number generator. I
propose improving the testing system, and then posting both the test suite
and this random generator to
Hackage, unless you really want it up now in a very very preliminary form.
Yeah I think a package of randomness tests could be really useful. Cool :-)
RS
import System.Random
data LehmerTree = LehmerTree {nextInt :: Int,
leftBranch :: LehmerTree,
rightBranch :: LehmerTree}
instance Show LehmerTree where
show g = LehmerTree, current root = ++(show $ nextInt g)
mkLehmerTree :: Int-Int-Int-Int-Int-Int-LehmerTree
mkLehmerTree aL aR cL cR m x0 = innerMkTree x0
where
mkLeft x = (aL * x + cL) `mod` m
mkRight x = (aR * x + cR) `mod` m
innerMkTree x = let l = innerMkTree (mkLeft x)
r = innerMkTree (mkRight x)
in LehmerTree x l r
mkLehmerTreeFromRandom :: IO LehmerTree
mkLehmerTreeFromRandom = do gen-getStdGen
let a:b:c:d:e:f:_ = randoms gen
return $ mkLehmerTree a b c d e f
This can be pure:
mkLehmerTreeFromRandom :: (RandomGen g) = g - LehmerTree
instance RandomGen LehmerTree where
next g = (fromIntegral.nextInt $ g, leftBranch g)
split g = (leftBranch g, rightBranch g)
genRange _ = (0, 2147483562) -- duplicate of stdRange
test :: IO()
test = do gen-mkLehmerTreeFromRandom
print gen
let (g1,g2) = split gen
let p = take 10 $ randoms gen :: [Int]
let p' = take 10 $ randoms g1 :: [Int]
-- let p'' = take 10 $ randoms g2 :: [Float]
print p
print p'
-- print p''
___
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] Serialization of (a - b) and IO a
On 11/11/2010 08:07 PM, C. McCann wrote: Having a full serialization function without some restriction along those lines would be like renaming unsafePerformIO to runIO, moving it to Control.Monad.IO, and telling people hey, just don't misuse this and everything will be okay. There's been a lot of talk about if serialisation existed, you could do X, which is bad. Well you know what? unsafePerformIO exists. unsafeCoerce exists. And using FFI, you can do utterly evil things. And...? Just today I was thinking about how useful it would be if you could send a block of code from one PC to another to execute it remotely. The fact that you can't do this is basically why there's no distributed Haskell yet, despite what an obviously good idea that would be. It would be really cool if we could do this. And yes, it should of course be an IO operation. Because, let's face it, any result it produces is inherantly going to be pretty random. (Much like my favourite GHC function name, reallyUnsafePtrEquity#...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Directed Name Resolution
On 12/11/2010 08:33 PM, Malcolm Wallace wrote: On 12 Nov 2010, at 20:21, Andrew Coppin wrote: It's always puzzled me that Haskell's standard containers almost completely lack any way to use them polymorphically. On the contrary, there is the Edison package ...which sounds quite interesting, except that... except that almost nobody uses it. I must confess, I've never actually looked at Edison (I had assumed it bit-rotted years ago), so I have no idea what it's like. I guess it's a kind of if it was good, shouldn't everybody be using it by now? logic. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Directed Name Resolution
On 12 November 2010 20:33, Malcolm Wallace malcolm.wall...@me.com wrote: Either that, or people find it awkward to deal with the substantial extra hierarchies of type classes. After the initial version in in PDFS it also developed operation bloat. e.g. the added Sequence class has many methods that don't fit well for standard inductive List... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serialization of (a - b) and IO a
On 12 November 2010 20:44, Andrew Coppin andrewcop...@btinternet.com wrote: Just today I was thinking about how useful it would be if you could send a block of code from one PC to another to execute it remotely. The fact that you can't do this is basically why there's no distributed Haskell yet, despite what an obviously good idea that would be. It would be really cool if we could do this. There was Distributed Haskell a while back[*], search for work by Frank Huch. [*] Maybe it wasn't migratory which I think is what you are wanting - you'd have to check the tech reports. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
On Fri, Nov 12, 2010 at 12:34 PM, Luke Palmer lrpal...@gmail.com wrote: Yeah I think a package of randomness tests could be really useful. Cool :-) There are already well-established suites of very thorough PRNG tests, such as Diehard and Big Crush. Please don't invent another. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serialization of (a - b) and IO a
On Nov 12, 2010, at 12:44 PM, Andrew Coppin wrote: Just today I was thinking about how useful it would be if you could send a block of code from one PC to another to execute it remotely. The fact that you can't do this is basically why there's no distributed Haskell yet, despite what an obviously good idea that would be. It would be really cool if we could do this. What kind of code are you thinking about? If you have a daemon waiting on a foreign machine, you can send it bytecode to deserialize. The issue is one of /encodings/. My naive approach (enumerating the functions domain, applying the function, and serializing a list of pairs of results) doesn't work so well because it is slow and big. But it has all the properties we want, without having to go into the compiler and make enormous changes. We need to find an efficient representation of a function in that can be serialized. Haskell code is one option, but the compiler would need to pass it through to the run-time, so that the deserializer could run a compiler on it. Passing some kind of intermediate level code through would work as well. But we still face the same problem. We need to compile the intermediate code into executable Haskell. There is also the architecture independent approach I have described previously (with a Serialize type class, enumerating the functions domain and applying the function to each element, etc). This is architecture independent in virtue of being implemented as plain old run-time Haskell. It turns Haskell expressions into ByteStrings and back. In short, the deserializer is an embedded compiler for Haskell bytecode. It interprets bytecode in terms architecture specific code. To be honest, I'm not even sure how architecture independent Data.Binary and the like really are. I'm guessing some care in the serialization library could fix any issue, though. And yes, it should of course be an IO operation. Because, let's face it, any result it produces is inherantly going to be pretty random. (Much like my favourite GHC function name, reallyUnsafePtrEquity#...) Serialization and transport are orthogonal. Serialization is pure. Transport is not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
On 12/11/10 20:56, Bryan O'Sullivan wrote: On Fri, Nov 12, 2010 at 12:34 PM, Luke Palmer lrpal...@gmail.com mailto:lrpal...@gmail.com wrote: Yeah I think a package of randomness tests could be really useful. Cool :-) There are already well-established suites of very thorough PRNG tests, such as Diehard and Big Crush. Please don't invent another. Thankyou for the advice, but since I am just learning about some of this stuff, how about I have ago at implementing some of their tests? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Better Records was Re: [Haskell-cafe] Type Directed Name Resolution
Records do leave quite a bit to be desired. But does anybody actually have a
concrete alternative proposal yet?
A few months ago I proposed a couple of extensions [1] on -cafe.
The jist of it is in the following:
someUpdate :: MyRecord - MyRecord
someUpdate myRecord = myRecord
{ field1 = f $ field1 myRecord
, field2 = g $ field2 myRecord
, field3 = h $ filed3 myRecord
}
becomes
someUpdate :: MyRecord - MyRecord
someUpdate = \{field1 = f, field2 = g, field3 = h}
The two syntax changes here are:
1. '=' remains as assignment in record updates, but = is added and
means 'field is transformed by', and
2. \{...} is a first-class lambda update. It's made possible by
the 1 since with 1 you no longer need to reference the entire record
anywhere in the update
Consider what this would do for nested updates:
UpdateTripleInner :: (Inner-Inner) - MyTriplyNestedRecord -
MyTriplyNestedRecord
UpdateTripleInner f = \{inner1 = \{inner2 = \{inner3 = f }}}
I cringe to imagine what the equivalent is in current Haskell syntax.
Anyone want to try it? Not me!
These extensions, admittedly, don't do anything for the namespacing
problem, which might be a bigger issue than awkward updates. I submit
that it's a different and somewhat unrelated issue, though I'd love to
see something that addresses both (all?) of the issues!
--Jonathan Geddes
[1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg81509.html
On Fri, Nov 12, 2010 at 1:29 PM, Andrew Coppin
andrewcop...@btinternet.com wrote:
On 11/11/2010 11:48 PM, John Lask wrote:
again quoting
http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html
Haskell lacks a serious record system. (The existing mechanism for named
fields in data types was always seen as a stop-gap measure.)
isn't it about time this changed?
Records do leave quite a bit to be desired. But does anybody actually have a
concrete alternative proposal yet?
Personally I'm not really keen on TDNR; I'd prefer records that aren't so
inconvenient. But I have no idea how to design that.
___
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] an evil type hangs GHC
From http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/bugs.html#bugs-ghc: GHC's inliner can be persuaded into non-termination using the standard way to encode recursion via a data type: data U = MkU (U - Bool) russel :: U - Bool russel u@(MkU p) = not $ p u x :: Bool x = russel (MkU russel) On Fri, Nov 12, 2010 at 10:52 AM, Petr Pudlak d...@pudlak.name wrote: Hi, I was playing with the following example I found in D.A.Turner's paper Total Functional Programming: data Bad a = C (Bad a - a) bad1 :: Bad a - a bad1 b@(C f) = f b bad2 :: a bad2 = bad1 (C bad1) To my surprise, instead of creating a bottom valued function (an infinite loop), I managed to send the GHC compiler (ver. 6.12.1) to an infinite loop. Could anybody suggest an explanation? Is this a GHC bug? Or is this Bad data type so evil that type checking fails? Thanks, Petr -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJM3Y0FAAoJEC5dcKNjBzhn68cH/3NsoUWOheGXsjZqpYj5yp5F IvN7NabyrAf3nxHG5uvIRqS0U33t0wZj3xSetnzDFW6wAjVtaDR4Jo7jB2/xXhLb g+vN9pcyZXH/r6HPb0ozRMHva4rS6K1S5T9u0kHI8jF9oeml4/lJQDOj2oouFfn2 yxsW8FKSfYQaDfudI2Bap3mCl8xeKaABwWIcc+4LUU0r2nmpHxBlqet9yOTBAa57 RkQrMmpt11bEVs/OUBZ2uIbd8iRD51eYTPyMHqy14a1FaRvkAvYinXQPSbg2vYcP YEH2llj/hsi7oxK4LVSj85nk0Ss59qFasYdWEPmr3zLzlRSjSI9kIlM3MqTjil4= =R7yy -END PGP SIGNATURE- ___ 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: Better Records was Re: [Haskell-cafe] Type Directed Name Resolution
On 12 November 2010 21:48, Jonathan Geddes geddes.jonat...@gmail.com wrote:
I cringe to imagine what the equivalent is in current Haskell syntax.
Anyone want to try it? Not me!
Perhaps not pretty - but it is regular and avoids Template Haskell an
manages for the few times I have records-in-records:
doubleInner3OfA :: A - A
doubleInner3OfA =
(\s a - s { inner1 = f1 a }) * inner1
where
f1 = (\s a - s { inner2 = f2 a }) * inner2
f2 = (\s a - s { inner3 = 2 * a }) * inner3
data A = A { inner1 :: B }
deriving (Eq,Show)
data B = B { inner2 :: C }
deriving (Eq,Show)
data C = C { inner3 :: Int }
deriving (Eq,Show)
t1 = A (B (C 1))
demo1 = doubleInner3OfA $ t1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
On Fri, Nov 12, 2010 at 1:28 PM, Richard Senington sc06...@leeds.ac.ukwrote: Thankyou for the advice, but since I am just learning about some of this stuff, how about I have ago at implementing some of their tests? Sure. See http://www.iro.umontreal.ca/~simardr/testu01/tu01.html for the current state of the art. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splittable random numbers
On 11/12/10 5:33 AM, Richard Senington wrote: It does not give the results you would want. This may have something to do with picking good parameters for the mkLehmerTree function. For example, using a random setup, I just got these results result expected range 16.814 expected = 16.0 (1,31) 16.191 expected = 16.5 (1,32) 16.576 expected = 17.0 (1,33) 17.081 expected = 17.5 (1,34) 17.543 expected = 18.0 (1,35) Have you run any significance tests? I wouldn't be surprised to see +/-0.5 as within the bounds of expected randomness. I'm more worried about it seeming to be consistently on the -0.5 end of things, than I am about it not matching expectation (how many samples did you take again?). For small ranges like this, a consistent -0.5 (or +0.5) tends to indicate off-by-one errors in the generator. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] an evil type hangs GHC
On 11/12/10 4:53 PM, Ryan Ingram wrote:
From http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/bugs.html#bugs-ghc:
GHC's inliner can be persuaded into non-termination using the standard
way to encode recursion via a data type:
More specifically, since your bad2 does not look recursive, the inliner
will get inline happy and apply the definition of bad1, but then it'll
see a constant case match that it can reduce statically, and loop
{ okay, let's start with bad1 }
bad1 b@(C f) = f b
{ mmm, tasty tasty sugar }
bad1 = \b - case b of C f - f b
{ ha, dare you to optimize that further }
{ okay, now let's co compile bad2 }
bad2 = bad1 (C bad1)
{ oh look, it's nonrecursive so let's start inlining }
bad2 = (\b - case b of C f - f b) (C bad1)
{ oh look, an application we can evaluate statically }
bad2 = let b = (C bad1) in case b of C f - f b
{ meh, let's ignore sharing for now }
bad2 = case (C bad1) of C f - f (C bad1)
{ oh look, a case analysis we can evaluate statically }
bad2 = let f = bad1 in f (C bad1)
{ oh look, f is only used once so we can substitute the let }
{ and if we didn't ignore sharing before, then we'd see that b is only
used once now, so we could substitute that let too }
bad2 = bad1 (C bad1)
{ oh look, it's nonrecursive so let's start inlining }
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RegEx versus (Parsec, TagSoup, others...)
I've been working on a project that requires me to do screen scraping. When I first started this, I worked off of other people's examples. Not one used regex. By luck I found someone at work to help me along this project. His clues and hints don't use regex either. I was at a point where I had to make a decision concerning design, so I asked the guy sitting next to me at work. He's very experienced, and comes from a Perl perspective. I let him into what I was doing, and he opined I should be using pcre. So now I'm second guessing my choices. Why do people choose not to use regex for uri parsing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RegEx versus (Parsec, TagSoup, others...)
On 11/12/10 6:56 PM, Michael Litchard wrote: I've been working on a project that requires me to do screen scraping. When I first started this, I worked off of other people's examples. Not one used regex. By luck I found someone at work to help me along this project. His clues and hints don't use regex either. I was at a point where I had to make a decision concerning design, so I asked the guy sitting next to me at work. He's very experienced, and comes from a Perl perspective. I let him into what I was doing, and he opined I should be using pcre. So now I'm second guessing my choices. Why do people choose not to use regex for uri parsing? As the grammar becomes more complex (i.e., as your patterns become more nuanced), using a real parser framework helps to improve code legibility since you can factor parts of the grammar out, give them names, etc. In addition to the documentation effects, this refactoring also allows you to make your grammars modular by using the same subgrammar in multiple places. While technically you can do the same factoring for constructing the regex that gets handed off to pcre, almost noone does that in practice. Also, using a real parsing framework allows you to construct more powerful grammars than regular grammars, so if you need the power of unbounded recursion or of context sensitivity, then regular expressions are out. Technically Perl's regexen are Turing complete and aren't regular expressions at all; pcre has inherited some of that extra power, put the point still holds at large. Even with more restricted regexen than Perl has, the modern idea of a regex isn't regular at all. Beginning of sentence and end of sentence anchors are not regular properties, which allows you to have the worst kind of fun :) http://zmievski.org/2010/08/the-prime-that-wasnt Even if you did decide to go for regular expressions, pcre chooses a specific implementation for handling choice (namely backtracking search). Depending on your grammars and the text they'll be applied to, this may not be the most efficient implementation since backtracking can lead to exponential behaviors that other regex implementations don't have. Also, regexes are apparently very difficult to implement *correctly*: http://www.haskell.org/haskellwiki/Regex_Posix -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serialization of (a - b) and IO a
It took me a bit to decide whether this was an adequate counter to my
objection, but ultimately, I don't think it is. I'll try to explain as well as
possible.
On Friday 12 November 2010 1:40:10 pm rocon...@theorem.ca wrote:
As you are well aware in Coq, and in Agda we don't have an extensionality
axiom; however this is not a problem because we simply use setoid equality
to capture extenional reasoning and prove that in every specific case
where we want to use extensional reasoning it is sound to do so.
If we are talking about writing programs in a closed world, and proving things
about said world, this is fine. But this is not always what we are doing in
Haskell. For instance, if I am writing a library, am I justified in changing:
f (g x) (g x)
to:
let y = g x in f y y
without bumping the semantics breaking change version number? In a closed
world, where I have proved that all the relevant code I have written admits
extensionality, the answer is, yes. But in an open world, where people are
free to use serialize to inspect my implementations in pure code, the answer
is, no.
Now suppose I add the following consistent axiom to Coq:
Axiom Church-Turing :
forall f:Nat - Nat, exists e:Nat, forall n:Nat, {e}(n) = f(n)
So, your argument is, if I'm not mistaken, that intensional type theory can be
consistently extended with this axiom. I believe this. In fact, I'd even be
willing to accept that purely as an axiom, it might be consistent to add it to
extensional type theory. However, this is not the whole story.
One question I have to ask is: how does this compute? In Agda, and I suspect
Coq, axioms simply do not compute (and this is the reason I'd be willing to
believe Church-Turing is consistent with an extensional theory). However,
serialize *will* compute, and I expect it to compute like this:
forall e:Nat. serialize {e} = e
And I can believe that even this is consistent with intensional type theory.
In an intensional theory, I can imagine (Nat - Nat) being interpreted not as
a type of functions, but as a type of algorithms. There may be many algorithms
that compute the same function, and Nat - Nat contains them all.
serialize/Church-Turing returns the source code of each one.
When we assert extensionality, though, Nat - Nat can no longer be inhabited
by mere algorithms, though. In an extensional theory, Nat - Nat is a quotient
of the set of algorithms. And then we have only a few options:
1) serialize/Church-Turing violates the quotient
2) serialize/Church-Turing computes extensional equality of algorithms, and
chooses a single 'source code' representation for each equivalence class
3) It is impossible for two different pieces of source code to compute the
same function (so serialize {e} = e is valid because there is no e' /= e
such that forall x. {e} x = {e'} x)
*) ...
2 is, I think, impossible, and 3 is simply false, so the choice is 1, meaning
that ITT + a Church-Turing that actually computes cannot be consistently
extended with extensionality. And it is this that I care about, and what I was
referring to in the mail you replied to:
- Intensional type theory can be consistently extended to extensional type
theory.
- serialize is anti-extensional (similar to the way impredicative Set
and injective type constructors are anti-classical).
And it is this consistent extension that I care about. And, going back to my
library example, the reason to care about this is abstraction. I want clients
of my library to program to the abstraction of my code as functions, not as
algorithms/source code, because that allows me leeway to tweak the algorithms
as I see fit, so long as they compute the same function.
And, for that matter, the compiler can do this kind of mucking around with
algorithms. I think it's a big deal if, to enable optimization of a function,
we have to prove that all code in our program treats it extensionally (I don't
believe the compiler can do it, currently, barring serialize simply not being
used; and say goodbye to separate compilation).
[1]Actaully the realizer for serialize is *weaker* that this axioms. The
realizer for serialize would be (Nat - Nat) - IO Nat instead of (Nat -
Nat) - Nat, so should have less impact that the Church-Turing axiom.
I have no problem with serialize :: (Nat - Nat) - IO Nat. The problem is
with (Nat - Nat) - Nat. The former can respect the quotient in question via
IO hand waving. Perhaps this distinction is frivolous, but it seems wrong to
make the language in general anti-extensional when it could instead be put
inside the sin bin. My quarrel is more with, let's dump out the sin bin and
just be careful.
-- Dan
[*] I have seen a paper about a type theory with quotients that has a
function:
choose : T / R - T
such that:
choose (squish x) = x
but it was meticulously designed to allow that in ways that I don't really
remember, so I'm going to pretend it
[Haskell-cafe] a problem about Regex in Real World Haskell
hi ,folks , I'm a newbie of haskell and learn haskell using the textbook Real World Haskell. in the page 201, ghci good food =~ .ood :: [String] my output is here https://gist.github.com/675024 it doesn't match what the textbook gives . And I found the ebook of Real World Haskell doesn't match it ,either(just like my output ) . I was wondering How I can fix this problem about Regex. much thanks ~ -- wolf python london(WPL) Do as you soul should do ! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
