Re: Chimeric syntax
On Tue, Apr 28, 2009 at 1:09 PM, Max Bolingbroke wrote: > 2009/4/28 Scott Michel : >> This got me to thinking that either ghc has issues or I have some >> fundamental misunderstanding of Haskell syntax. Or, maybe I should use >> someone else's grammar. > > GHC's parser is over-generous by design. See > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Parser. A > precise description of what is valid Haskell it is certainly NOT, but > it will certainly accept any valid Haskell program. This may not be > quite what you want for an IDE - but it might be good enough for a > first cut. Actually, given what ghc will accept, I seriously doubt that the LR grammar can ever successfully translate to a LL(*) grammar. Liberal, it may be, but it probably should be valid. I just followed the current parser rules to their ultimate conclusion. I suspect that people would be quite surprised by what Parser.y.pp will actually accept. Basically, my understanding is that a 'let' should not be allowed in a 'class' declaration and yet, ghc is quite happy to allow it. So my understanding is correct, but ghc grammar is (perhaps) too flexible. -scooter PS: Anyone got a multicore Haskell experience they want to share at Supercomputing this year? The guys from Galois did a great job shocking the audience last year. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Chimeric syntax
2009/4/28 Scott Michel : > This got me to thinking that either ghc has issues or I have some > fundamental misunderstanding of Haskell syntax. Or, maybe I should use > someone else's grammar. GHC's parser is over-generous by design. See http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Parser. A precise description of what is valid Haskell it is certainly NOT, but it will certainly accept any valid Haskell program. This may not be quite what you want for an IDE - but it might be good enough for a first cut. Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Chimeric syntax
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Apr 28, 2009, at 01:24 , Scott Michel wrote:
I've been hacking along on a NetBeans Haskell plugin (*) Looking at
Parser.y.pp, because both Eclipse and NetBeans work with antlr, it
seems like there are interesting cases in which chimeric constructions
parse correctly. Here's an example:
class ParsedModule m where
let { a = 1; b = 2; } in a + b :: Int :: Int
This is mostly accepted by ghc, which complains with an invalid type
signature.
Looking at the Online Report, my guess is it parses as:
exp^0 = "let {a = 1; b = 2; } in a + b"
type = "Int :: Int"
and of course "Int :: Int" is an invalid type signature. (::) parses
as if it were a very low precedence operator.
- --
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
iEYEARECAAYFAkn3Xg4ACgkQIn7hlCsL25XQpgCdFnKgoxE8DlJWMpLTabR6gkIW
tZIAnjnR8HheL8RtO87Z3ZteRqfHewUo
=eptK
-END PGP SIGNATURE-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Threads and memory management
Thanks for your comments. > Check whether it is GC-bound by using +RTS -sstderr. Well yes, it does a lot of GC (there's no way for the compiler to optimize away the list of primes) because that was the point of the example: to confirm (or disprove) that GC hurts parallelism (at the moment). INIT time0.00s ( 0.00s elapsed) MUT time 13.23s ( 7.98s elapsed) GCtime 14.12s ( 14.11s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 27.35s ( 22.09s elapsed) %GC time 51.6% (63.9% elapsed) > Try a recent HEAD snapshot if you can, or wait for 6.12.1. I did with 6.11.20090425 and it coredumps with +RTS -N2 (on x86_64) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41001950 (LWP 1007)] 0x0044e831 in yieldCapability () Current language: auto; currently asm (gdb) where #0 0x0044e831 in yieldCapability () #1 0x0042d8d3 in schedule () #2 0x0042e485 in workerStart () #3 0x2b680cdcdfc7 in start_thread () from /lib/libpthread.so.0 #4 0x2b680d0b25ad in clone () from /lib/libc.so.6 #5 0x in ?? () but it runs with +RTS -N2 -q1 (I don't know exactly what this does) and the numbers did not change much - down from 22 sec to 21 sec maybe) PS: yes, I confirmed that the OS can run the two "primes" enumerations (as separately compiled executables) in parallel in 6 sec wall time. Best regards, J.W. signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Threads and memory management
On 27/04/2009 11:29, Bulat Ziganshin wrote: Hello Simon, Monday, April 27, 2009, 2:13:26 PM, you wrote: This is a very strange result: the user time should not *decrease*, but rather should stay the same or increase a bit when adding cores. If ability to run two threads simultaneous may increase performance in some scenarios. one example is consumer+producer threads. with 2 OS threads all produced data are consumed immediately, so we live inside L2 cache. with 1 OS thread produced data overflow the cache before threads are switched, making execution much slower Yes, good point. Though I'd be surprised if that was happening here. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
