Re: Quasi quoting
Perhaps I missed this or I'm missing something, but seeing a mention of quasiquoting on another thread, I reread this entire thread just now before posting. If by stealing syntax we mean that the odd programmer who writes illegiblelinenoisewithoutspaceshastoaddtheoddspacehereandthere, then fine, sorry about the long post which you may freely ignore. What I read when I see stealing syntax is that a proposal makes some prior code impossible to write. Please clarify. I have no trouble distinguishing visually between the following forms [hex| 1.fp+1023 |] [ hex | hex - [ 0..8 ] ] for two different reasons: [1] I'd never leave out the spaces for the list comprehension, while I'd always leave out the spaces for quasiquoting. [2] It's completely obvious to a human reader that the first form can't be a list comprehension, because of the trailing |] which would be a parse error. Let's recall that indentation-based parsing like we use in Haskell, Python was once radical, and still jars some people. Spaces are already significant for everyone, this just leans on them a bit more. A Lisp programmer would have no issues distinguishing these forms, because [hex| is a single token for the Lisp programmer. A freshman parser for quasiquoting would get this right by accident, failing to catch the quasiquoting that used spaces, falling correctly through to the list comprehension. More generally, humans always resolve ambiguity by parsing several ways in parallel, and accepting the highest priority parse that succeeds. I always expect computer languages to work this way, and my heart is always broken. Why can't Haskell evolve in this direction, as proposals like this increase its code density? Reading Coders at Work, all of my coding zombie masters abandoned Lisp (as I did) because code density is a Good Thing. It's a mild nuisance to wait on the closing |] to decide, but only a mild nuisance. This reminds me of heredocs, where a traditional (e.g. Perl) heredoc help prog = “EOF” Usage: “prog” input output “prog” -h original input output EOF looks like it's stealing syntax, but there is utterly no issue at all, if one waits till the end to resolve the ambiguity, giving priority to a correct heredoc. (I need to wait till the end in any case to steal the indent.) Somehow this was never accepted as a reasonable idea in the heredoc thread either, yet I took this from working code that my custom literate preprocessor handles without incident. So what am I missing? Require no spaces to open quasiquoting, and/or require |] to close quasiquoting, falling through to whatever else Haskell will accept if these conditions aren't met? Then it remains possible to code any list comprehension. On Jan 31, 2010, at 10:50 PM, Simon Peyton-Jones wrote: So the proposed change will make things *more* uniform, by grabbing every [blah| as lexeme. On Feb 1, 2010, at 1:43 AM, Malcolm Wallace wrote: I am not myself a TH or QQ user, but it has always bothered me slightly that the syntax for them steals some valid list comprehensions. On Feb 22, 2010, at 5:15 AM, Simon Peyton-Jones wrote: Or, alternatively, use quasiquoting [hex| 1.fp+1023 |] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple by default
Isaac Dupree: We could try to find out how large Integers get, in practice, in existing Haskell code (this may be difficult to find out). Daniel Fischer wrote: Just as a data-point, my code rarely exceeds 128 bits (at least, beyond that performance isn't so important anymore). And Daniel, who is part of the Project Euler team, uses large integers far more than most people. As another data point, Python has also re-invented the GMP wheel, likely for the same licensing reasons. They have been using a simple implementation of Karatsuba multiplication for years. I have never heard of anyone complaining about it. Furthermore, they currently use naive multiplication and don't even bother with Karatsuba for less than about 2000 bits on most recent platforms. Regards, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple by default
As another data point, Python has also re-invented the GMP wheel, likely for the same licensing reasons. They have been using a simple implementation of Karatsuba multiplication for years. I have never heard of anyone complaining about it Thanks for the data point. Looks like they swapped out their integer implementation for Python3: http://gmplib.org/list-archives/gmp-discuss/2008-November/003434.html Here's the code from January 30, 2010: http://svn.python.org/view/python/trunk/Objects/longobject.c?view=markup More data points: http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic -Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Shared GHC libraries and the runtime system
I was working on a shared library that loads up the GHC runtime (via hs_init) and have been running into a bunch of undefined stg symbols. A bit of digging and it seems that GHC doesn't embed - the dependency libHSrts-ghc6.12.1.so, and - the associated rpath /usr/lib/ghc-6.12.1 into shared libraries that it builds. Thus, if your main executable isn't GHC generated (and hence has these), you run into unresolved symbols. I can work around this by manually adding them myself. Is there any reason GHC can't put this information by default into shared libraries though? Thanks! -Tyson PS: Further digging into the various shared libraries packaged with GHC (Debian GHC package 6.12.1-2) reveal that they are actually missing - the dependency libHSrts-ghc6.12.1.so, and - all rpaths (i.e., there are absolutely no rpaths in any of them) $ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so ... Dynamic Section: NEEDED libHSinteger-gmp-0.2.0.0-ghc6.12.1.so NEEDED libgmp.so.3 NEEDED libHSghc-prim-0.2.0.0-ghc6.12.1.so NEEDED libc.so.6 SONAME libHSbase-4.2.0.0-ghc6.12.1.so ... signature.asc Description: This is a digitally signed message part. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Shared GHC libraries and the runtime system
Hi Tyson, This blog post (http://blog.well-typed.com/2009/05/buildings-plugins-as-haskell-shared-libs/) might help explain the motivation (actually there are a few relevant posts on the well-typed site). Essentially, I believe that this is done so that you can vary the RTS by changing LD_LIBRARY_PATH. I've never used this facility so I'm unable to say how useful this actually is (or if it actually works at the moment). Cheers, Max On 22 February 2010 21:34, Tyson Whitehead twhiteh...@gmail.com wrote: I was working on a shared library that loads up the GHC runtime (via hs_init) and have been running into a bunch of undefined stg symbols. A bit of digging and it seems that GHC doesn't embed - the dependency libHSrts-ghc6.12.1.so, and - the associated rpath /usr/lib/ghc-6.12.1 into shared libraries that it builds. Thus, if your main executable isn't GHC generated (and hence has these), you run into unresolved symbols. I can work around this by manually adding them myself. Is there any reason GHC can't put this information by default into shared libraries though? Thanks! -Tyson PS: Further digging into the various shared libraries packaged with GHC (Debian GHC package 6.12.1-2) reveal that they are actually missing - the dependency libHSrts-ghc6.12.1.so, and - all rpaths (i.e., there are absolutely no rpaths in any of them) $ objdump -p /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.1.so ... Dynamic Section: NEEDED libHSinteger-gmp-0.2.0.0-ghc6.12.1.so NEEDED libgmp.so.3 NEEDED libHSghc-prim-0.2.0.0-ghc6.12.1.so NEEDED libc.so.6 SONAME libHSbase-4.2.0.0-ghc6.12.1.so ... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple by default
I think it would be great to have a benchmark, to test Integer performance at various implementations. Perhaps it could test speed of Int, Int64, Int32 as well (for computations that fit within them). I suppose tight numeric loops are key to measuring performance in a useful way (except for incredibly larger Integers). Are there existing benchmarks? (If not, is there a good benchmarking library that I ought to use if I try to write a benchmark?) On 02/22/10 15:15, Greg Fitzgerald wrote: ... More data points: ... Thanks! Code re-use is nice (if we can use one of those BSD-licensed versions) ; although it may turn out useful to write our Integer implementation in Haskell if it helps the optimizer out with small-valued Integers. -Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: integer-simple by default
I wrote: As another data point, Python has also re-invented the GMP wheel, likely for the same licensing reasons. They have been using a simple implementation of Karatsuba multiplication for years. I have never heard of anyone complaining about it Greg Fitzgerald wrote: Looks like they swapped out their integer implementation for Python3 Interesting! This will be new in Python 3.2 - the first changes in many years. It's not exactly swapped out, but there are many changes. At first glance, it looks like better 64-bit support, a new division algorithm via floating-point, a new exponentiation algorithm using a 5-bits-at-a-time trick in some cases, optimized Read and Show instances (pardon the expression), a few other things. A lot of the new stuff seems to be from HAC. As before, everything is fully explained in expository comments inside the code, with references; a worthwhile read. Multiplication is still the same basic idea though - naive up to about 2000 bits, followed by just Karatsuba and nothing more. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Shared GHC libraries and the runtime system
On February 22, 2010 17:00:25 Max Bolingbroke wrote: Hi Tyson, This blog post (/) might help explain the motivation (actually there are a few relevant posts on the well-typed site). Essentially, I believe that this is done so that you can vary the RTS by changing LD_LIBRARY_PATH. I've never used this facility so I'm unable to say how useful this actually is (or if it actually works at the moment). Thanks Max. Those were good write ups. I'm pleased to report that I've got GHC hooked into Perl as a shared library (i.e., can call my GHC code from Perl). I'm working on trying to get a reasonable build system solution now. So far I've been trying to build a single shared library, but I thinking the easiest/intended way might be to just get GHC to just build its own library and then specify it as a required shared library to the Perl stub library. This way I wouldn't have to mix flags from the build systems in the final link. (although a shared library of stubs to a shared library seems a bit strange) Cheers! -Tyson PS: Thanks to everyone responsible for getting shared libraries working. signature.asc Description: This is a digitally signed message part. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Shared GHC libraries and the runtime system
Tyson and others Would you like to gather some of what you have learned into a user-oriented Wiki page about how to use shared libraries in GHC? The right place for this is http://haskell.org/haskellwiki/GHC under Contributed documentation. You probably have all the material in the email thread, and it's a pity not to get full value from it. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Tyson Whitehead | Sent: 23 February 2010 03:44 | To: Max Bolingbroke | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Shared GHC libraries and the runtime system | | On February 22, 2010 17:00:25 Max Bolingbroke wrote: | Hi Tyson, | | This blog post | (/) might help explain the motivation (actually there are a few relevant | posts on the well-typed site). | | Essentially, I believe that this is done so that you can vary the RTS | by changing LD_LIBRARY_PATH. I've never used this facility so I'm | unable to say how useful this actually is (or if it actually works at | the moment). | | Thanks Max. Those were good write ups. I'm pleased to report that I've got | GHC hooked into Perl as a shared library (i.e., can call my GHC code from | Perl). I'm working on trying to get a reasonable build system solution now. | | So far I've been trying to build a single shared library, but I thinking the | easiest/intended way might be to just get GHC to just build its own library | and then specify it as a required shared library to the Perl stub library. | | This way I wouldn't have to mix flags from the build systems in the final | link. | | (although a shared library of stubs to a shared library seems a bit strange) | | Cheers! -Tyson | | PS: Thanks to everyone responsible for getting shared libraries working. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
