On Wed, Jun 12, 2013 at 07:47:22AM +, harry wrote:
Tillmann Rendel 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
Johan Tibell 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
Tillmann Rendel 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
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
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
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
Johan Tibell 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
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
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
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
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 ..
Does such thing as a deprecation pragma for an instance exist?
What triggers it?
Roman
* Johan Tibell johan.tib...@gmail.com [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
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
* Johan Tibell johan.tib...@gmail.com [2013-06-11 15:03:10-0700]
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
14 matches
Mail list logo
