Re: Meta-point: backward compatibility

An interesting question. What is the goal of Haskell'? Is it to, like Python 3000, fix warts in the language in an (somewhat) incompatible way or is it to just standardize current practice? I think we need both, I just don't know which of the two Haskell' is. -- Johan On Wed, Apr 23, 2008 at

Re: Meta-point: backward compatibility

On Wed, Apr 23, 2008 at 4:52 PM, Niklas Broberg [EMAIL PROTECTED] wrote: I would hope it is both. Some changes simply cannot become current practice since they would not be compatible with existing code, and the only place that such changes *could* be made is in a new language version.

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

On Thu, Apr 24, 2008 at 3:41 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson: Haskell has now reached the point where backwards compatibility is something that must be taken very seriously. Would you be opposed to a Haskell 2

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

On Mon, Apr 28, 2008 at 6:56 PM, Simon Marlow [EMAIL PROTECTED] wrote: So I suggest we reject the proposal, and move any further discussion to haskell-cafe. Ok? Sounds good to me. ___ Haskell-prime mailing list Haskell-prime@haskell.org

Re: String != [Char]

Hi Greg, There are a few blog posts on Bryan's blog. Here are two of them: http://www.serpentine.com/blog/2009/10/09/announcing-a-major-revision-of-the-haskell-text-library/ http://www.serpentine.com/blog/2009/12/10/the-performance-of-data-text/ Unfortunately the blog seems partly

Re: String != [Char]

On Mon, Mar 19, 2012 at 8:45 AM, Thomas Schilling nomin...@googlemail.com wrote: Regarding the type class for converting to and from that type, there is a perhaps more complicated question: The current fromString method uses String as the source type which causes unnecessary overhead. This is

Re: String != [Char]

On Mon, Mar 19, 2012 at 9:02 AM, Christian Siefkes christ...@siefkes.net wrote: On 03/19/2012 04:53 PM, Johan Tibell wrote: I've been thinking about this question as well. How about class IsString s where     unpackCString :: Ptr Word8 - CSize - s What's the Ptr Word8 supposed to contain

Re: String != [Char]

On Mon, Mar 19, 2012 at 2:55 PM, Daniel Peebles pumpkin...@gmail.com wrote: If the input is specified to be UTF-8, wouldn't it be better to call the method unpackUTF8 or something like that? Sure. -- Johan ___ Haskell-prime mailing list

Re: String != [Char]

On Tue, Mar 20, 2012 at 2:25 AM, Simon Marlow simon...@microsoft.com wrote: Is there a reason not to put all these methods in the IsString class, with appropriate default definitions?  You would need a UTF-8 encoder ( decoder) of course, but it would reduce the burden on clients and improve

Re: String != [Char]

On Sat, Mar 24, 2012 at 2:31 PM, Brandon Allbery allber...@gmail.com wrote: I was under the impression they have been very carefully designed to do the right thing with characters represented by multiple codepoints, which is something the String version *cannot* do.  It would help if Bryan were

Re: String != [Char]

On Sat, Mar 24, 2012 at 3:45 PM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: How is Text for small strings currently (e.g. one English word, if not one character)?  Can we reasonably recommend it for that? This recent question suggests it's still not great:

Re: String != [Char]

On Sat, Mar 24, 2012 at 3:33 PM, Freddie Manners f.mann...@gmail.com wrote: To add my tuppence-worth on this, addressed to no-one in particular: (1) I think getting hung up on UTF-8 correctness is a distraction here.  I can't imagine anyone suggesting that the C/C++ standards removed support

Re: String != [Char]

On Sat, Mar 24, 2012 at 4:42 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: Hmm, std::u16string, std::u23string, and std::wstring are C++ standard types to process Unicode texts. Note that at least u16string is too small to encode all of Unicode and wstring might be as 16 bits is not

Re: String != [Char]

On Sat, Mar 24, 2012 at 5:54 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: I think there is a confusion here.  A Unicode character is an abstract entity.  For it to exist in some concrete form in a program, you need an encoding.  The fact that char16_t is 16-bit wide is irrelevant

Re: String != [Char]

On Mon, Mar 26, 2012 at 7:48 AM, Malcolm Wallace malcolm.wall...@me.com wrote: In the region of this side of the Atlantic Ocean where I teach, the student population is very diverse Prelude putStrLn (take 5 Fröhßen) Fröhß ghci putStrLn Fro\x0308hßen Fröhßen ghci putStrLn (take 5

Re: String != [Char]

On Mon, Mar 26, 2012 at 9:59 AM, Henrik Nilsson n...@cs.nott.ac.uk wrote: So, is the argument to deprecate Char, then? As long as Haskell allows Chars to be handled in isolation, it would seem impossible to prevent naive users from accidentally stumbling over the complexities of Unicode? I

Re: String != [Char]

On Mon, Mar 26, 2012 at 10:12 AM, Ian Lynagh ig...@earth.li wrote: I am very unicode-ignorant, so apologies if I have misunderstood something, but doesn't Text do the same thing? Prelude T import Data.Text.IO as T Prelude T T T.putStrLn (T.take 5 (T.pack Fro\x0308hßen)) Fröh Maybe your

Re: [Haskell] Status of Haskell'?

On Fri, Nov 30, 2012 at 1:42 PM, Jason Dusek jason.du...@gmail.com wrote: It would be nice for there to be a new standard so that many features in GHC -- such as overloaded strings, rank n types, MPTCs, c. -- were enabled by default without any pragmas. I think this is one of these nice gains

Re: Bang patterns

On Sun, Feb 3, 2013 at 4:44 PM, Ben Millwood hask...@benmachine.co.uk wrote: I have two proposals, I suppose: - make bang patterns in let altogether invalid I would prefer it to be valid. It's the syntactically most lightweight option we have to force some thunks before using the resulting

Re: proposal for trailing comma and semicolon

On Fri, May 17, 2013 at 9:17 AM, Garrett Mitchener garrett.mitche...@gmail.com wrote: Anyway, this is a paper cut in the language that has been bugging me for a while, and since there's now a call for suggestions for Haskell 2014, I thought I'd ask about it. I've also thought about this

Re: Proposal: NoImplicitPreludeImport

On Tue, May 28, 2013 at 8:23 AM, Ian Lynagh i...@well-typed.com wrote: Dear Haskellers, I have made a wiki page describing a new proposal, NoImplicitPreludeImport, which I intend to propose for Haskell 2014: http://hackage.haskell.org/trac/haskell-prime/wiki/NoImplicitPreludeImport What

Re: Remove Enum from Float and Double

Hi Harry, On Tue, Jun 11, 2013 at 3:51 AM, harry volderm...@hotmail.com wrote: There have been several discussions over the years regarding Enum instances for Float and Double. The conclusion each time appears to have been that there are no instances which are both sane and practical. Do

Re: Remove Enum from Float and Double

to write an explicit loop that tests against some lower/upper bound? It would have the same problem as enumFromTo. I think the issue here is really that floating point math on computers is hard to think about. On Tue, Jun 11, 2013 at 11:18 AM, harry volderm...@hotmail.com wrote: Johan Tibell

Re: Remove Enum from Float and Double

On Tue, Jun 11, 2013 at 3:00 PM, Roman Cheplyaka r...@ro-che.info wrote: Does such thing as a deprecation pragma for an instance exist? What triggers it? I don't know. We'll need one if we're going to deprecating core instances. Just deleting them is not an option (as it gives users with

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins wrote: > > On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote: > >> My understanding of the argument here, which seems to make sense to me, >> is that the AMP already introduced a significant breaking

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink wrote: > On 5 October 2015 at 20:58, Sven Panne wrote: > > 2015-10-05 17:09 GMT+02:00 Gershom B : > >> > >> [...] As for libraries, it has been pointed out, I believe, that without > >>

Re: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

It might be enough to just add a NOWARN pragma that acts on a single line/expression. I've seen it in both C++ and Python linters and it works reasonably well and it's quite general. On Tue, Oct 6, 2015 at 10:44 AM, Ben Gamari wrote: > Sven Panne

Re: MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`)

(Resending with smaller recipient list to avoid getting stuck in the moderator queue.) On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel <h...@gnu.org> wrote: > On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: > > On the libraries I maintain and have a copy of on my com