-------------------------------------------- -- prelude-safeenum 0.1.0 -------------------------------------------- The prelude-safeenum package offers a safe alternative to the Prelude's Enum class in order to render it safe. While we're at it, we also generalize the notion of enumeration to support types which can only be enumerated in one direction. -------------------------------------------- -- Description -------------------------------------------- The prelude-safeenum package offers an alternative to the notion of enumeration provided by the Prelude. For now it is just a package, but the eventual goal is to be incorporated into haskell prime. Some salient characteristics of the new type-class hierarchy are: * Removes partial functions: The Haskell Language Report defines pred, succ, fromEnum, and toEnum to be partial functions when the type is Bounded[1], but this is unacceptable. The new classes remove this problem by correcting the type signatures for these functions. * Generalizes the notion of enumeration: Rather than requiring that the type is linearly enumerable, we distinguish between forward enumeration (which allows for multiple predecessors) and backward enumeration (which allows for multiple successors). * Adds new functions: enumDownFrom, enumDownFromTo One of the big problems with the partiality of pred is that there is no safe way to enumerate downwards since in the border case (enumFromThen x (pred x)) will throw an error rather than evaluating to [x] as desired. These new functions remove this problem. * Removes the requirement that the enumeration order coincides with the Ord ordering (if one exists). Though, of course, it's advisable to keep them in sync if possible, for your sanity. * Ensures that the notion of enumeration is well-defined: This much-needed rigor clarifies the meaning of enumeration. In addition, it rules out instances for Float and Double which are highly problematic and often confuse newcomers to Haskell. Unfortunately, this rigor does render the instance for Ratio problematic. However, Ratio instances /can/ be provided so long as the base type is enumerable (and Integral, naturally); but they must be done in an obscure order that does not coincide with Ord. * The obscure order required for well-defined enumeration of Ratio is provided. [1] http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1310006.... -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/prelude-safeenum Darcs: http://community.haskell.org/~wren/prelude-safeenum Haddock (Darcs version): http://community.haskell.org/~wren/prelude-safeenum/dist/doc/html/prelude-sa... -- Live well, ~wren
On Wed, 29 May 2013, wren ng thornton wrote:
-------------------------------------------- -- prelude-safeenum 0.1.0 --------------------------------------------
The prelude-safeenum package offers a safe alternative to the Prelude's Enum class in order to render it safe. While we're at it, we also generalize the notion of enumeration to support types which can only be enumerated in one direction.
I am concerned that we are using 'safe' for two very different meanings: 'safe' in the sense of SafeHaskell and unsafePerformanceIO and 'safe' in the sense of the package 'safe' and your safeenum. For my taste, there is no need to coin new terms for partiality and totality. Could we just call total functions total instead of safe?
On 5/30/13 3:54 AM, Henning Thielemann wrote:
On Wed, 29 May 2013, wren ng thornton wrote:
-------------------------------------------- -- prelude-safeenum 0.1.0 --------------------------------------------
The prelude-safeenum package offers a safe alternative to the Prelude's Enum class in order to render it safe. While we're at it, we also generalize the notion of enumeration to support types which can only be enumerated in one direction.
I am concerned that we are using 'safe' for two very different meanings: 'safe' in the sense of SafeHaskell and unsafePerformanceIO and 'safe' in the sense of the package 'safe' and your safeenum. For my taste, there is no need to coin new terms for partiality and totality. Could we just call total functions total instead of safe?
I consider partial functions to be unsafe, and I don't think I'm alone in that regard. -- Live well, ~wren
Čt 30. květen 2013, 19:56:07 CEST, wren ng thornton napsal:
On 5/30/13 3:54 AM, Henning Thielemann wrote:
On Wed, 29 May 2013, wren ng thornton wrote:
-------------------------------------------- -- prelude-safeenum 0.1.0 --------------------------------------------
The prelude-safeenum package offers a safe alternative to the Prelude's Enum class in order to render it safe. While we're at it, we also generalize the notion of enumeration to support types which can only be enumerated in one direction.
I am concerned that we are using 'safe' for two very different meanings: 'safe' in the sense of SafeHaskell and unsafePerformanceIO and 'safe' in the sense of the package 'safe' and your safeenum. For my taste, there is no need to coin new terms for partiality and totality. Could we just call total functions total instead of safe?
I consider partial functions to be unsafe, and I don't think I'm alone in that regard.
I'd say most people here do. The problem is that (as Henning T. wrote) the term "safe" is very general, and it's used already in the sense of "Safe Haskell" and "unsafe..." functions. So I also support his suggestion for naming it "total" or something like that instead of "safe". Otherwise, I like the idea of your package and I'm fond of this improvement. Best regards, Petr Pudlak
On Fri, May 31, 2013 at 2:14 AM, Petr Pudlák
Čt 30. květen 2013, 19:56:07 **CEST, wren ng thornton napsal:
On 5/30/13 3:54 AM, Henning Thielemann wrote:
On Wed, 29 May 2013, wren ng thornton wrote:
------------------------------**--------------
-- prelude-safeenum 0.1.0 ------------------------------**--------------
The prelude-safeenum package offers a safe alternative to the Prelude's Enum class in order to render it safe. While we're at it, we also generalize the notion of enumeration to support types which can only be enumerated in one direction.
I am concerned that we are using 'safe' for two very different meanings: 'safe' in the sense of SafeHaskell and unsafePerformanceIO and 'safe' in the sense of the package 'safe' and your safeenum. For my taste, there is no need to coin new terms for partiality and totality. Could we just call total functions total instead of safe?
I consider partial functions to be unsafe, and I don't think I'm alone in that regard.
I'd say most people here do. The problem is that (as Henning T. wrote) the term "safe" is very general, and it's used already in the sense of "Safe Haskell" and "unsafe..." functions. So I also support his suggestion for naming it "total" or something like that instead of "safe". Otherwise, I like the idea of your package and I'm fond of this improvement.
The name "safe" to denote "total, opposed to the more standard partial variants" predates Safe Haskell. See e.g. http://hackage.haskell.org/package/safe-0.2
participants (4)
-
Henning Thielemann -
John Lato -
Petr Pudlák -
wren ng thornton