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 writes:
>
> > 2015-10-05 17:09 GMT+02:00 Gersho
(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 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 computer right n
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
> >> CPP one can write instances compatible with AMP, and also with
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 change with
>> regards to monads. Books and lectur
On Tue, Jun 11, 2013 at 3:00 PM, Roman Cheplyaka 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 large code
bases n
users 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 wrote:
> Johan Tibell writes:
>
Hi Harry,
On Tue, Jun 11, 2013 at 3:51 AM, harry 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 you have a link to so
On Tue, May 28, 2013 at 8:23 AM, Ian Lynagh 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 do you thin
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 t
On Sun, Feb 3, 2013 at 4:44 PM, Ben Millwood 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 values
in a constructor tha
On Fri, Nov 30, 2012 at 1:42 PM, Jason Dusek 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 for day-to-day Has
On Mon, Mar 26, 2012 at 10:12 AM, Ian Lynagh 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 point
On Mon, Mar 26, 2012 at 9:59 AM, Henrik Nilsson 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 haven't proposed
On Mon, Mar 26, 2012 at 9:42 AM, Christian Siefkes
wrote:
> On 03/26/2012 05:50 PM, Johan Tibell wrote:
>> Normalization isn't quite enough unfortunately, as it does solve e.g.
>>
>> upcase = map toUppper
>>
>> You need all-at-once functions on str
On Mon, Mar 26, 2012 at 8:34 AM, Malcolm Wallace wrote:
> Yes indeed. And I think it would be perfectly reasonable for the String (=
> [Char]) API to have a function "normalise :: String -> String" which would
> let the user deal with this issue as they see fit. After all, if you are
> aware
On Mon, Mar 26, 2012 at 7:48 AM, Malcolm Wallace 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 "Fro\x0308hßen")
Fröh
On Sat, Mar 24, 2012 at 5:54 PM, Gabriel Dos Reis
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 to
> whether it can be used
On Sat, Mar 24, 2012 at 4:42 PM, Gabriel Dos Reis
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 enough to encode all of Uni
On Sat, Mar 24, 2012 at 3:33 PM, Freddie Manners 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 for
> (char*) bec
On Sat, Mar 24, 2012 at 3:45 PM, Isaac Dupree
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:
> http://stackoverflow.com/questions/9398572/memory-effici
On Sat, Mar 24, 2012 at 2:31 PM, Brandon Allbery 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
> involved with
On Sat, Mar 24, 2012 at 1:16 PM, Ian Lynagh wrote:
> Data.Text seems to think that many of them are worth reimplementing for
> Text. It looks like someone's systematically gone through Data.List.
> And in fact, very few functions there /don't/ look like they are
> directly equivalent to list funct
Hi all,
On Sat, Mar 24, 2012 at 12:39 AM, Heinrich Apfelmus
wrote:
> Which brings me to the fundamental question behind this proposal: Why do we
> need Text at all? What are its virtues and how do they compare? What is the
> trade-off? (I'm not familiar enough with the Text library to answer thes
On Tue, Mar 20, 2012 at 2:25 AM, Simon Marlow 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 backwards
> compati
On Mon, Mar 19, 2012 at 2:55 PM, Daniel Peebles 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
Haskell-prime@haskell.org
http:
On Mon, Mar 19, 2012 at 9:02 AM, Christian Siefkes
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&
On Mon, Mar 19, 2012 at 8:45 AM, Thomas Schilling
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 unfortunate since GH
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 broke
On Thu, May 26, 2011 at 9:37 AM, Simon Peyton-Jones
wrote:
> Friends
>
> Thanks to those who responded to the message below, about improving the
> process for developing the core Haskell libraries.
> http://www.haskell.org/haskellwiki/Library_submissions/NewDraft
>
> Feedback has been broa
On Mon, Jan 26, 2009 at 9:57 AM, Peter Hercek wrote:
> I personally do not mind them in my source code if the leading isSpace
> characters on lines are everywhere of the same kind in one source file. If
> all indentations would be done only with tabs then one can easily change the
> indent size fo
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
http://ww
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 Ha
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
On Wed, Apr 23, 2008 at 2:53 PM, Philippa Cowderoy <[EMAIL PROTECTED]> wrote:
> Current practice often involves removing certain warts anyway - the MR
> being a great example.
I was more thinking of things like removing fail from the Monad class
and fixing the I/O libraries to use Unicode, etc.
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 2:16
On Jan 23, 2008 2:11 PM, Magnus Therning <[EMAIL PROTECTED]> wrote:
> Yes, this reflects my recent experience, Char is not a good representation
> for an 8-bit byte. This thread came out of my attempt to add a module to
> dataenc[1] that would make base64-string[2] obsolete. As you probably can
>
> > The benefit would be that if the input is not in latin-1 an exception
> > could be thrown rather than returning a Char representing the wrong
> > Unicode code point.
>
> I'm not sure what you mean here. All 256 possible values have a meaning.
You're of course right. So we don't have a problem
> > > > What *does* matter to the programmer is what encodings putStr and
> > > > getLine use. AFAIK, they use "lower 8 bits of unicode code point" which
> > > > is almost functionally equivalent to latin-1.
> > >
> > > Which is terrible! You should have to be explicit about what encoding
> > > you
Hi Bulat,
On Jan 17, 2008 6:18 PM, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> step 1: create library NewArray with modules Data.NewArray.* copied
> one-to-one from Data.Array.* and publish it as version 1
Having words like "new" for the purpose of versioning is quite
confusing because a library
39 matches
Mail list logo
