Re: Remove Enum from Float and Double
I don't see much gain. It will break previously working code and the workaround to the breakage will likely be manually reimplementing enumFromTo in each instance. As an aside, many years ago I did exactly that after being bit by Enum infelicities, and while you could say it's a reimplementation, in my opinion it's a better implementation: -- | Enumerate an inclusive range. Uses multiplication instead of successive -- addition to avoid loss of precision. -- -- Also it doesn't require an Enum instance. range :: (Num a, Ord a) = a - a - a - [a] range start end step = go 0 where go i | step = 0 val end = [] | step 0 val end = [] | otherwise = val : go (i+1) where val = start + (i*step) -- | Enumerate a half-open range. range' :: (Num a, Ord a) = a - a - a - [a] range' start end step = go 0 where go i | step = 0 val = end = [] | step 0 val = end = [] | otherwise = val : go (i+1) where val = start + (i*step) -- | Infinite range. range_ :: (Num a) = a - a - [a] range_ start step = go 0 where go i = start + (i*step) : go (i+1) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Remove Enum from Float and Double
On Tue, Jun 11, 2013 at 2:18 PM, Johan Tibell johan.tib...@gmail.com wrote: If we truly believe that the instance is dangerous for users (and not merely for people who don't understand floating point arithmetic on computers), then we should add a deprecation pragma to the instance and discourage its use. But what would the deprecation message encourage instead, for users to write an explicit loop that tests against some lower/upper bound? It would have the same problem as enumFromTo. If the problem is increasing inaccuracy, then it likely wouldn't. E.g.: last [0, 0.1 .. 20] 20.195 last (range 0 20 0.1) 20.0 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: backslashes within quotes
On Fri, Oct 5, 2012 at 8:01 AM, Lennart Augustsson lenn...@augustsson.net wrote: I agree that backslash string wrapping is obscure. I do use it a lot, but I would not be sad to see it go. On Fri, Oct 5, 2012 at 9:50 AM, Henrik Nilsson henrik.nils...@nottingham.ac.uk wrote: I find it quite neat, also use it a lot, and would be sad to see it go. It is also a good feature for automatic formatting of code to a specific width. But what about just replacing those \s with ++? It's true it's a few more characters, but is it really that much more work? I actually just used the \s recently, and being 3 characters shorter is a bit nicer, but not that much nicer. And it messed up my simplistic syntax highlighting. However, I did notice that given OverloadedStrings, 'hello there :: Text' does not get optimized to 'Text.pack hello there', but for all I know the complicated thing it emits is just as efficient. The same is true for \a, \b, \f, \v, \EM, \DC1, etc. We do need \, though. What is \ used for? I never knew it existed until I reread that bit of the report, and couldn't figure out what it was for. I'm assuming that only terminal manipulation stuff needs those things, and that you would generally not want to write it inline, but write something like 'ringyDingy I'm going to nag and bell at you!', and ringyDingy is just as happy to build the bell with Char.chr. I guess this is pretty much bike-sheddery so I'll leave it at this, but it seems like the darker corners should be subject to some spring cleaning every 10 years or so... ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: String != [Char]
No-one's yet argued against OverloadedStrings. I think there /is/ an argument to be made, that it introduces ambiguity and could break existing programs (probably we can extend defaulting to take care of Definitely, I have ones that would need some :: sprinkled in. this, but I think there are people who'd be happier if we killed defaulting too). Too much polymorphism /can/ be a bad thing. But I Also me :) I'd like that 'default' keyword back too, it's too useful for variables names to waste on something so obscure. That said, I like OverloadedStrings. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: showing Ratios
This must be explained somewhere, but I can't find it. I've always been curious why ghc's Show avoids all unnecessary spaces. It's contrary to how most people format source so it can't be pasted into source, and can be hard to read. Other languages tend to put in spaces. I don't see anything in http://www.haskell.org/onlinereport/basic.html specifying the whitespace usage of Show. I notice that the examples don't use spaces, but those are just examples, right? What's the rationale? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: showing Ratios
On Sun, Feb 28, 2010 at 7:56 PM, Iavor Diatchki iavor.diatc...@gmail.com wrote: Hi, I am not sure about the rationale but if you need a program/library which re-renders Show-able values with more spaces, so that they are more human readable, I wrote one (http://hackage.haskell.org/package/pretty-show). I find it very useful for debugging. Oh nice, I'll take a look. I'm currently using a hacked up version of ipprint which works pretty well. The only reason I had to hack it was to change the hardcoded 137 column line length to 80. And to output Strings directly, which is a hack needed for my specific application. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: PROPOSAL: deprecate field labels as selectors (was Include field label puns in Haskell 2011
(I know how you're always looking for things to take out of Haskell ...) I can see the ugliness of having a name with two incompatible types (especially in the same scope). That's a good point, but even if not totally logical I think the automatic Rec - X function is more important than the X meaning. Functions are more resistant to change (for instance, I changed from String to Data.Text but could keep the old recString as a function when the field named changed), so while I think the sugar to bring names into scope is handy, I think functional access should be encouraged as the main way to do it. The whole tension between syntactic convenience of pattern matching and the flexibility of function accessors in the face of change is kind of unfortunate. It mirrors the OO dilemma of x.y vs. x.y(), which some OO languages do away with altogether. So I'd want to go the other way by making functional access and update more convenient and prominent rather than syntactical. Maybe we could have a little extension of view patterns where f (field -) = y is transformed to f (field - field) = y. It's still a shadow, but at least now it works with any function. It might be nice to do the same with update functions, but those aren't even generated automatically (anyone got a generics thing that cranks those out?). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields
On Wed, Feb 24, 2010 at 11:03 AM, John Meacham j...@repetae.net wrote: This isn't so much a proposal as a recommendation for terminology we use when talking about things on the list and proposals in general. Calling haskell's labeled field mechanism 'records' leads to all sorts of confusion for people that come from other languages where 'records' means something else, this is compounded by the fact there are several actual record proposals out there that are orthogonal to labeled fields, but calling fields 'records' confuses this issue. Just out of curiosity, what are the attributes associated with labeled fields and what are the ones associated with records? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: RECOMMENDATION: Use 'labeled fields' rather than records when talking about labeled fields
On Wed, Feb 24, 2010 at 11:50 AM, John Meacham j...@repetae.net wrote: On Wed, Feb 24, 2010 at 11:35:44AM -0800, Evan Laforge wrote: On Wed, Feb 24, 2010 at 11:03 AM, John Meacham j...@repetae.net wrote: This isn't so much a proposal as a recommendation for terminology we use when talking about things on the list and proposals in general. Calling haskell's labeled field mechanism 'records' leads to all sorts of confusion for people that come from other languages where 'records' means something else, this is compounded by the fact there are several actual record proposals out there that are orthogonal to labeled fields, but calling fields 'records' confuses this issue. Just out of curiosity, what are the attributes associated with labeled fields and what are the ones associated with records? Well, when you have a data constructor like data Foo = Foo Int Char your Int and Char are the two fields of your data constructor Foo, labeled fields are exactly that, a way to refer to them by labels rather than positionally. in particular, the run-time implementation and ability for optimization is exactly the same. it is simply a more convienient way to work with a construct that already exists in Haskell with no overhead, like a newtype. Ah, so to paraphrase, fields are just syntax sugar for an ADT + access functions + update syntax. Update syntax is just sugar for a \b - A a _ c - A a b c expression. Pure sugar. Records are basically anything more substantial than sugar but may imply a new label concept (i.e. not just reusing functions), literal syntax, extensibility, type system support for subtyping, etc. etc. This seems like a reasonable distinction. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
