Re: Humble message of support and concern from an interested newbie

ome feature removal or modifications in areas where people feel > strongly about. But even with those, I feel like this work is very much > doable. > > Best, > Haowen > On 11/8/2021 3:45 PM, Cale Gibbard wrote: > > The tricky thing is that while a new document describing the

Re: Humble message of support and concern from an interested newbie

The tricky thing is that while a new document describing the language in detail would be welcomed, it's hard for people to justify doing all the work that's involved in producing a new document that's substantially more helpful than the Haskell 2010 or '98 Report. Right at the moment, there's

Re: LAST CALL to comment on the Applicative/Monad Proposal

Somehow every time I see messages from this list I'm again tempted to suggest that it would all be so much easier if the goal were to document the language as it exists in a fixed, already-released version of GHC. But I'm not a member either. If I were, I'd pick a version and veto anything which

Re: LAST CALL to comment on the Appicative/Monad Proposal

edge, > I would've done so explicitly! If someone wants to tell me where to nag the > GHC folks I guess I might find the time. But I'm definitely looking at > removing warts in the context of things that are already happening myself. > On 18/12/2018 14:52, Cale Gibbard wrote: >

Re: LAST CALL to comment on the Appicative/Monad Proposal

Is it just me, or is all the discussion in these threads much more easily resolved if the Report is simply a report? Describe what is, rather than what you wish it was, and there's much less room for disagreement. A future Report can describe the way that these things work differently in the

Re: A question about run-time errors when class members are undefined

This and the fact that you may leave record fields unspecified when initially constructing a record are two things I'd probably change if I could. In the rare case of a class with a method that will usually be an error, you could still define that as the default method implementation in the class.

Re: Remove eq and show from num class

I fully agree with Edward here. This change to Num has been a positive one. It also seemed fairly uncontroversial as far as Prelude changes go - many people wanted to see that change for years. While it caused a handful of hiccups when it happened, it was generally easy enough to fix code to

Re: Remove eq and show from num class

If you don't do it, the Report will just be inaccurate. On Thu, 7 Sep 2017 at 11:43 Carter Schonwald wrote: > All yays from committee members please reply with yes to this email :) > > -Carter > ___ > Haskell-prime mailing

Re: type (++) = (<>)

On the other hand, it's unusual, at least in my mind, for "plus" to be used as notation for an operation which is noncommutative. (++) is something else of course... While I can see moving in that direction being reasonable the migration path is a political nightmare as Edward points out. I'm

Re: Limber separators

I can't really be the only one here who thinks that this kind of discussion of extensions to the syntax of Haskell is totally inappropriate when we have a large number of already implemented extensions to the language whose interactions with each other are largely undocumented. The Haskell Report

Re: Are there GHC extensions we'd like to incorporate wholesale?

This question implicitly has two parts: 1) Are there GHC extensions which the Report ought to describe in their entirety? To this question, I would say "yes" - pretty much anything which can be done in that direction will be productive, it's more a question of what people are willing to put the

Re: Evaluation order control between two expressions

Well, the value of par x y is identical to that of y, so any expression which you could use to semantically distinguish pseq from seq using par could be rewritten into one which did so without involving par. If the way in which we're telling programs apart involves performance characteristics

Re: Proposal: require spaces around the dot operator

On 12 February 2012 18:00, Evan Laforge qdun...@gmail.com wrote: On Thu, Feb 9, 2012 at 6:11 PM, Greg Weber g...@gregweber.info wrote: Similar to proposal #20, which wants to remove it, but immediately less drastic, even though the long-term goal is the same. This helps clear the way for the

Re: Proposal: Make gcd total

+1 On 9 May 2011 19:11, Jacques Carette care...@mcmaster.ca wrote: +1 Jacques On 09/05/2011 6:49 PM, Daniel Fischer wrote: I would like to propose the elimination of the special error case gcd 0 0 = error Prelude.gcd: gcd 0 0 is undefined to replace it with gcd 0 0 = 0 (which would

Re: nubBy, groupBy specification

2010/1/2 a.biurvo...@asuhan.com: I'm inclined to agree with you. Could you please post the sources to both nubBy and groupBy to see what has changed? Thanks, Kim-Ee y...@cs.wisc.edu Sure thing, Here is the report's implementation of nubBy: --- nubBy:: (a -

nubBy, groupBy specification

Hello, I've recently been irritated with (what I consider to be) broken versions of nubBy in GHC 6.10.4 and 6.12.1. For a while, groupBy was broken in the same way, but it seems to be fixed at least in 6.10.4. The problem is roughly caused by nubBy being specified only for symmetric relations,

Re: Outlaw tabs

2009/1/24 Duncan Coutts duncan.cou...@worc.ox.ac.uk: A lot of projects use -Wall. If there is consensus on the tabs issue then we could ask for -fwarn-tabs to be included in -Wall. That should be a good first step. If we cannot achieve consensus within the community for having -Wall include

Re: Suggestion regarding (.) and map

2008/4/24 Wolfgang Jeltsch [EMAIL PROTECTED]: Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard: […] Rename fmap to map This would be really great! There is no point in having a map just for lists and a general map for functors since the list map is the same as the list

Re: Meta-point: backward compatibility

2008/4/24 Chris Smith [EMAIL PROTECTED]: 3. Don't get me wrong; I'm definitely not arguing for this ($) associativity change, for example, and my objection is the backward compatibility. But ultimately, it's more like a combination of incompatibility and the lack of a really compelling

Re: Suggestion regarding (.) and map

2008/4/24 Dan Doel [EMAIL PROTECTED]: On Thursday 24 April 2008, Wolfgang Jeltsch wrote: I don't think that this is reasonable. (.) corresponds to the little circle in math which is a composition. So (.) = () would be far better. Were I building a library, this might be the direction

Re: Suggestion regarding (.) and map

2008/4/24 Twan van Laarhoven [EMAIL PROTECTED]: Cale Gibbard wrote: Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion which I think is elegant and worth considering for the Haskell' Prelude: Rename

Re: Suggestion regarding (.) and map

2008/4/24 David Menendez [EMAIL PROTECTED]: On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven [EMAIL PROTECTED] wrote: Cale Gibbard wrote: Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion

Re: Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application

2008/4/23 Bulat Ziganshin [EMAIL PROTECTED]: Hello Cale, Wednesday, April 23, 2008, 10:54:06 AM, you wrote: By the way, as Don suggests, I do strongly advocate this change, and i agree that the change by itself is reasonable, but fixing all the old issues and providing new beautiful

Re: patch applied (haskell-prime-status): add Make $ left associative, like application

2008/4/23 Sittampalam, Ganesh [EMAIL PROTECTED]: but it also seems not to make much sense to standardise a Prelude which people strongly want to change. I'm strongly against this change, both on its own merits - in most cases when there is a real argument being passed, I find chains of

Re: patch applied (haskell-prime-status): add Make $ left associative, like application

2008/4/23 apfelmus [EMAIL PROTECTED]: Dan Doel wrote: Note that setting (.) or ($) = fmap subsumes function application, because we have fmap :: (a - b) - a - b for the /identity functor/. In other words, the current ($) and (.) are just special cases of the general fmap .

Re: patch applied (haskell-prime-status): add Make $ left associative, like application

2008/4/23 Neil Mitchell [EMAIL PROTECTED]: We also should remember that a large number of academic papers are written in Haskell, and unlike libraries, don't get update releases made. This is not a minor tweak - it will break a massive number of programs. How many research papers have you

Suggestion regarding (.) and map

Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion which I think is elegant and worth considering for the Haskell' Prelude: Rename fmap to map (like it was in Haskell 1.4), and define (.) as a synonym for it.

Re: Indentation of If-Then-Else

On 23/10/06, Henning Thielemann [EMAIL PROTECTED] wrote: I like to convince other programmers of Haskell by telling them, that Haskell can abstract so powerful, that you can define your own control structures, and consequently most control structures are actually library functions. Two people

Re: Indentation of If-Then-Else

On 23/10/06, Henning Thielemann [EMAIL PROTECTED] wrote: Cale Gibbard cgibbard at gmail.com, Sun Oct 22 12:23:18 EDT 2006 The 'then' and 'else' visually separate the parts of the if-expression, and serve to guide one's eyes when reading code silently, and one's words when speaking it aloud

Re: map and fmap

I haven't really been able to follow this entire thread, but I'd just like to note here that I agree completely with Jón's take here on the map issue. It's almost embarassing to have to tell people that there are 3 functions in the basic libraries which do exactly the same thing up to type

Re: map and fmap

Indeed, I agree. On 30/08/06, Ashley Yakeley [EMAIL PROTECTED] wrote: Cale Gibbard wrote: While we're at it, let's split MonadZero and MonadPlus -- the decision to merge them was not well thought-out, and a lot of expressive power in type signatures is lost there. This should be split

Re: A modest proposal

On 16/04/06, Taral [EMAIL PROTECTED] wrote: On 4/15/06, John Goerzen [EMAIL PROTECTED] wrote: On the downside, this means that I couldn't just say: take 5 mylist I'd instead have to write: take (5::Int) mylist Wouldn't defaulting do this? Yeah, defaulting should make that 5 an

Re: MonadPlus Reform

I'd like to put a me too on that one. This part of the class hierarchy is currently a bit inexpressive. I've been annoyed by the fact that if I want to express in the type signature of a function that a monad has a failure mechanism, I'm forced to go all the way up to MonadPlus, which makes it

Re: realToFrac issues

On 28/02/06, John Meacham [EMAIL PROTECTED] wrote: On Tue, Feb 28, 2006 at 12:44:04AM -0500, Cale Gibbard wrote: I'm almost scared to ask: does this mean we need negative zero as well? good point. probably. This change means that Rational is no longer a field. It makes me feel uneasy

Re: Re[2]: Array interface refactoring

On 23/02/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello John, Thursday, February 23, 2006, 4:07:52 PM, you wrote: JM That is the plan. none of the current Array implementations will JM change, they will still be instances of both MArray and HasBounds. it is JM just that HasBounds will

Re: Export lists in modules

On 21/02/06, Malcolm Wallace [EMAIL PROTECTED] wrote: There is also the issue that we might adopt the proposal to allow (and perhaps eventually, to require) type signatures on export lists. If so, then it would be kind of ridiculous to have interface signatures only for the things you are

Re: The worst piece of syntax in Haskell

On 21/02/06, Ashley Yakeley [EMAIL PROTECTED] wrote: Sebastian Sylvan wrote: Not quite the same complaint, but I've always been bothered by the inconsistent use of =. I would prefer A = B to mean if A, then B. Accordingly: class Monad m = MonadPlus m By your definition, couldn't

Re: Re[2]: Priorities

On 05/02/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Tomasz, Sunday, February 05, 2006, 2:45:44 PM, you wrote: We don't have any problems with ensuring good cooperation between mutable variables and concurrency synchronisation primitives, because the language doesn't have

Re: separate class and type namespace

On the other hand, it is recommended practice to define only one data type per module, isn't it? Only by very few people as far as I know. I know that Henning Thielemann advocates this, but it seems like a rather arbitrary restriction to me. I find it quite common to define several data types

Re: The dreaded M-R

On 28/01/06, Taral [EMAIL PROTECTED] wrote: On 1/28/06, Cale Gibbard [EMAIL PROTECTED] wrote: Do you have an example of such a program handy? b = (x, x) where { x :: Num a = a; x = fromInteger 1 } fromInteger is called twice. --- mr.hs --- {-# OPTIONS_GHC -fno-monomorphism-restriction

Re: The dreaded M-R

On 28/01/06, Lennart Augustsson [EMAIL PROTECTED] wrote: Remove the type signature for b and you will see the loss of sharing. Nope, still not seeing it with either profiling or Debug.Trace. Also -- the type signature I gave was polymorphic, so what's the deal? If adding a polymorphic type

Re: The dreaded M-R

runtime machinery to find that the dictionaries are the same. -- Lennart Cale Gibbard wrote: On 28/01/06, Lennart Augustsson [EMAIL PROTECTED] wrote: Remove the type signature for b and you will see the loss of sharing. Nope, still not seeing it with either profiling