Re: lambda case
Brent Yorgey byor...@seas.upenn.edu writes: Oh, PLEASE people. Let's not have another round of bikeshedding about this AFTER the feature is already implemented! This is not an argument about the colour of the bikeshed. In terms of that analogy, this has gone something like this: Someone says the bikeshed doorknob is hard to turn and we should have a handle. There’s some discussion, I say maybe, but lets not do it unless we have a good design. Someone else comes up with the beginnings of a good design for a handle, but there’s no consensus about that and it all goes quiet. Some time later a voice says that if nobody does anything it’ll get forgotten (which is what I was hoping would happen). I repeat that it’s better not to do it without a good design and nod off. When I wake up, a handle has been installed by hot-melt glueing a bit of rough sawn timber to the doorknob. I complain. Another voice tells me to shut up, we’ve done it now. — Jón ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] lambda case
Brandon Allbery allber...@gmail.com writes:
On Sat, Dec 1, 2012 at 5:30 AM, Roman Cheplyaka r...@ro-che.info wrote:
I find this discussion useful — there are some interesting points
(splitting case of into two parts) that I don't remember reading in the
original thread (but maybe it's just me).
Mentioned twice that I recall, as treating 'of' as a lambda and as '\of'.
I’m not quite sure what treating “of” as lambda means, and \of
raises the some of the same objections as \case.
Up until the introduction of “lambda-case”, \ was a clear
indication that what was coming next was a pattern that would
bind variables (except in degenerate cases, but anyone who
writes something like \Nothing - e should be taken out and sho-
wn why it’s a bad idea).
It got somewhat short shrift, likely because while it makes sense from an
existing language syntax viewpoint, it makes little to none from a
readability standpoint.
Of the available alternatives, it makes the most linguistic
sense. If you can’t read the subtext for that sentence, try
again :-) In the design I was suggesting, “of” is in no sense a
lambda, it simply introduces a list of alternative patterns
exactly as it does in the original design of case … of {alts}.
Arguing about whether “of” is the right keyword here without
arguing that case… of… should have different keywords is
inconsistent, and arguing for a change of those keywords really
would be fussing about the colour of the bikeshed after it was
painted.
--
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
On Tue, 27 Nov 2012 20:15:59 + Ian Lynagh i...@well-typed.com wrote: It will be easy to turn it off, but depending on the platform we might have removed support for GHCi when it's turned off. Why not provide RTS linker as a deprecated option at least until it's completely removed from all platforms? I mostly do static builds for Linux/x86 and Win32, and the prospect of compiling twice as much, possibly with a slower compiler, just to use ghci prompt(or even Template Haskell(?)) is not exactly exciting. And introducing more differences between Haskell on *nix and on Windows isn't going to make cross-platform development easier. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Patch to enable GHC runtime system with thr_debug_p options...
Dear Michał, Am Sonntag, den 02.12.2012, 22:44 +0100 schrieb Michał J. Gajda: On 12/02/2012 09:20 PM, Joachim Breitner wrote: I noticed that Ubuntu, as well as Debian and original packages come without some variants of threaded debugging binaries. A recent change added of printing a stack trace with -xc option requires using both -ticky and profiling compile options, which in turn forces program to be compiled in a -debug RTS way. Since stack trace looks like indispensable debugging tool, and convenient parallelization is strength of Haskell, I wonder is there any remaining reason to leave beginners with a cryptic error message when they try to debug a parallel or threaded application, and want to take advantage of stack trace? The resulting ghc-prof package would be increased by less than 1%. Here is a patch for Ubuntu/Debian GHC 7.4.2 package, as well as upstream --- ghc-7.4.2-orig/mk/config.mk.in 2012-06-06 19:10:25.0 +0200 +++ ghc-7.4.2/mk/config.mk.in 2012-12-01 00:22:29.055003842 +0100 @@ -256,7 +256,7 @@ # l : event logging # thr_l : threaded and event logging # -GhcRTSWays=l +GhcRTSWays=l thr_debug_p thr_debug # Usually want the debug version ifeq $(BootingFromHc) NO I notice that your patch modifies the defaults of GHC as shipped by upstream, and I wonder if there is a reason why these ways are not enabled by default. Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package? Thanks, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata 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
