On Wed, Jun 12, 2013 at 07:47:22AM +, harry wrote:
> Tillmann Rendel writes:
>
> > In general, I would be against removing features just because they are
> > confusing for beginners. I don't think that's a good design principle
> > for a language that is primarily targeted at professional p
Tillmann Rendel writes:
> In general, I would be against removing features just because they are
> confusing for beginners. I don't think that's a good design principle
> for a language that is primarily targeted at professional programmers
> and computer scientists.
They're confusing to begi
Johan Tibell writes:
> 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 encou
* Johan Tibell [2013-06-11 15:03:10-0700]
> 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
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
Does such thing as a deprecation pragma for an instance exist?
What triggers it?
Roman
* Johan Tibell [2013-06-11 14:18:41-0700]
> 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 sho
Hi,
The primary motivation for removing these instances is that they cause
endless confusion for beginners [...]
Not sure what that means for this discussion, but enumFromTo is already
confusing without considering floating point numbers:
Prelude> [fromInteger 1, fromInteger 3 .. fromInteg
On Tue, Jun 11, 2013 at 2:18 PM, Johan Tibell 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 wha
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 t
More to supply evidence in answer to your question than to present a point
of view, the following is an example of code I wrote fairly recently:
phi :: Double -> Double -> Complex Double
phi x y = sum [ exp((-pi * (x + n)^2) :+ (2 * pi * n * y)) | n <-
[-100..100] ]
I wouldn't claim for a second
Johan Tibell writes:
> 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.
I forgot the main point of my post :-)
The primary motivation for removing these instances is that they caus
> 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 reimplementa
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
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.
I would like to propose that these instances be removed from Haskell 2014.
This may be cove
14 matches
Mail list logo