In a later posting Marcin Kowalczyk says:
If (+) can be implicitly lifted to functions, then why not signum?
Note that I would lift neither signum nor (+). I don't feel the need.
...
On Mon, Feb 12, 2001 at 09:33:03AM +, Jerzy Karczmarczuk wrote:
I not only feel the need, but I feel
On Mon, 12 Feb 2001, Jerzy Karczmarczuk wrote:
I not only feel the need, but I feel that this is important that the
additive structure in the codomain is inherited by functions.
It could support only the basic arithmetic. It would not automatically
lift an expression which uses () and if. It
On Mon, 12 Feb 2001, Jerzy Karczmarczuk wrote:
I want to be *able* to define mathematical operations upon objects
which by their intrinsic nature permit so!
You can't do it in Haskell as it stands now, no matter what the Prelude
would be.
For example I would say that with the definition
Marcin Kowalczyk continues:
On Mon, 12 Feb 2001, Jerzy Karczmarczuk wrote:
I want to be *able* to define mathematical operations upon objects
which by their intrinsic nature permit so!
You can't do it in Haskell as it stands now, no matter what the Prelude
would be.
For example I
[incomprehensible (not necessarily wrong!) stuff about polynomials,
rings, modules over Z and complaints about the current prelude nuked]
--- Marcin 'Qrczak' Kowalczyk pisze ---
Please show a concrete proposal how Prelude classes could be improved.
--- Jerzy Karczmarczuk repondre ---
I am
Sun, 11 Feb 2001 13:37:28 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
Can you demonstrate a revised hierarchy without Eq? What would
happen to Ord and the numeric classes with default class method
definitions that use (==) either explicitly or in pattern matching
against numeric literals?
Sun, 11 Feb 2001 13:37:28 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
Can you demonstrate a revised hierarchy without Eq? What would
happen to Ord and the numeric classes with default class method
definitions that use (==) either explicitly or in pattern matching
against numeric literals?
I
Marcin 'Qrczak' Kowalczyk wrote:
I'm against removing Eq from the numeric hierarchy, against making Num
instances for functions, but I would probably remove Show. I haven't
seen a sensible proposal of a replacement of the whole hierarchy.
Then we probably are in agreement.
--brian
On 11-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
There may be some misunderstanding here. If you are talking about type
for which equality is always undefined, then I agree with you, but that
is not what I was talking about. I was thinking about types where
equality is defined for some
Marcin 'Qrczak' Kowalczyk writes:
| Fri, 9 Feb 2001 17:29:09 +1300, Tom Pledger [EMAIL PROTECTED] pisze:
|
| (x + y) + z
|
| we know from the explicit type signature (in your question that I was
| responding to) that x,y::Int and z::Double. Type inference does not
| need to
Marcin 'Qrczak' Kowalczyk wrote:
Sat, 10 Feb 2001 14:09:59 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
Can you demonstrate a revised hierarchy without Eq? What would happen to
Ord, and the numeric classes that require Eq because they need signum?
signum doesn't require Eq. You can
Fergus Henderson wrote:
On 09-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
Patrik Jansson wrote:
The fact that equality can be trivially defined as bottom does not imply
that it should be a superclass of Num, it only explains that there is an
ugly way of working around the
On 11-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
Fergus Henderson wrote:
On 09-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
Patrik Jansson wrote:
The fact that equality can be trivially defined as bottom does not imply
that it should be a superclass of Num, it only
Brian Boutel [EMAIL PROTECTED] writes:
The fact that equality can be trivially defined as bottom does not imply
that it should be a superclass of Num, it only explains that there is an
ugly way of working around the problem.
There is nothing trivial or ugly about a definition that reflects
Marcin 'Qrczak' Kowalczyk wrote:
JK Now, signum and abs seem to be quite distincts beasts. Signum seem
JK to require Ord (and a generic zero...).
Signum doesn't require Ord.
signum z = z / abs z
for complex numbers.
Thank you, I know. And I ignore it. Calling "signum" the result of
Fri, 09 Feb 2001 10:52:39 +, Jerzy Karczmarczuk pisze:
Again, a violation of the orthogonality principle. Needing division
just to define signum. And of course a completely different approach
do define the signum of integers. Or of polynomials...
On Fri, Feb 09, 2001 at 07:19:21PM +,
Ketil Malde wrote:
Brian Boutel [EMAIL PROTECTED] writes:
- Having a class hierarchy at all (or making any design decision)
implies compromise.
I think the argument is that we should move Eq and Show *out* of the
Num hierarchy. Less hierarchy - less compromise.
Can you demonstrate
On 08-Feb-2001, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
I don't like the idea of treating the case "no explicit definitions
were given because all have default definitions which are OK"
differently than "some explicit definitions were given".
I don't really like it that much
On 09-Feb-2001, Brian Boutel [EMAIL PROTECTED] wrote:
Patrik Jansson wrote:
The fact that equality can be trivially defined as bottom does not imply
that it should be a superclass of Num, it only explains that there is an
ugly way of working around the problem.
...
There is nothing
Sat, 10 Feb 2001 14:09:59 +1300, Brian Boutel [EMAIL PROTECTED] pisze:
Can you demonstrate a revised hierarchy without Eq? What would happen to
Ord, and the numeric classes that require Eq because they need signum?
signum doesn't require Eq. You can use signum without having Eq, and
you can
On Thu, 8 Feb 2001, Tom Pledger wrote:
nice answer: give the numeric literal 10 the range type 10..10, which
is defined implicitly and is a subtype of both -128..127 (Int8) and
0..255 (Word8).
What are the inferred types for
f = map (\x - x+10)
g l = l ++ f l
? I hope I can use them
First, a general remark which has nothing to do with Num.
PLEASE WATCH YOUR DESTINATION ADDRESSES
People send regularly their postings to haskell-cafe with
several private receiver addresses, which is a bit annoying
when you click "reply all"...
Brian Boutel after Dylan Thurston:
Why
On Thu, Feb 08, 2001 at 11:24:49AM +, Jerzy Karczmarczuk wrote:
First, a general remark which has nothing to do with Num.
PLEASE WATCH YOUR DESTINATION ADDRESSES
People send regularly their postings to haskell-cafe with
several private receiver addresses, which is a bit annoying
when
Thu, 8 Feb 2001 10:51:58 -0500, Peter Douglass [EMAIL PROTECTED] pisze:
The first part of my question (not contained in your reply) is
whether it is feasible to disable a developer's access to the
"unsafe" numerical operations.
import Prelude hiding (quot, rem, (/) {- etc. -})
import
Thu, 8 Feb 2001 21:41:56 +1100, Fergus Henderson [EMAIL PROTECTED] pisze:
Should this define an instance for `foo T'?
(I think not.)
How about if the instance declaration is changed to
instance bar T where
f = 41
-- no definition for f2
Thu, 08 Feb 2001 11:24:49 +, Jerzy Karczmarczuk [EMAIL PROTECTED] pisze:
The implicit coercion of numeric constants: 3.14 -=- (fromDouble
3.14) etc. is sick.
What do you propose instead?
(BTW, it's fromRational, to keep arbitrarily large precision.)
Now, signum and abs seem to be
On Thu, Feb 08, 2001 at 08:30:31PM +, Marcin 'Qrczak' Kowalczyk wrote:
Signum doesn't require Ord.
signum z = z / abs z
for complex numbers.
I'd be careful here.
\begin{code}
signum 0 = 0
signum z = z / abs z
\end{code}
This is, perhaps, neither precise nor general
Marcin 'Qrczak' Kowalczyk writes:
| On Thu, 8 Feb 2001, Tom Pledger wrote:
|
| nice answer: give the numeric literal 10 the range type 10..10, which
| is defined implicitly and is a subtype of both -128..127 (Int8) and
| 0..255 (Word8).
|
| What are the inferred types for
| f =
William Lee Irwin III wrote:
The Standard Prelude serves its purpose well and accommodates the
largest cross-section of users. Perhaps a Geek Prelude could
accommodate the few of us who do need these sorts of schenanigans.
Amen.
--brian
___
moved to haskell-cafe
Ketil E.g. way back, I wrote a simple differential equation solver.
Ketil Now, the same function *could* have been applied to vector
Ketil functions, except that I'd have to decide on how to implement
Ketil all the "Num" stuff that really didn't fit well.
"Ch. A. Herrmann" answers my questions:
Jerzy What do you mean "predefined" operators? Predefined where?
In hugs, ":t (*)" tells you:
(*) :: Num a = a - a - a
which is an intended property of Haskell, I suppose.
Aha. But I would never call this a DEFINITION of this operator.
This
07 Feb 2001 11:47:11 +0100, Ketil Malde [EMAIL PROTECTED] pisze:
If it is useful to have a fine granularity of classes, you can
imagine doing:
class Multiplicative a b c where
(*) :: a - b - c
Then a*b*c is ambiguous no matter what are types of a,b,c and the
Other people have been making great points for me. (I particularly
liked the example of Dollars as a type with addition but not
multiplication.) One point that has not been made: given a class
setup like
class Additive a where
(+) :: a - a - a
(-) :: a - a - a
negate :: a - a
zero :: a
On Wed, Feb 07, 2001 at 11:47:11AM +0100, Ketil Malde wrote:
"Ch. A. Herrmann" [EMAIL PROTECTED] writes:
[...]
the problem is that the --majority, I suppose?-- of mathematicians
tend to overload operators. They use "*" for matrix-matrix
multiplication as well as for matrix-vector
I have some questions about how Haskell's numeric classes might be
revamped.
Is it possible in Haskell to circumscribe the availability of certain
"unsafe" numeric operations such as div, /, mod? If this is not possible
already, could perhaps a compiler flag "-noUnsafeDivide" could be added
Dylan Thurston writes:
:
| (A question in the above context is whether the literal '0' should
| be interpreted as 'fromInteger (0::Integer)' or as 'zero'.
| Opinions?)
Opinions? Be careful what you wish for. ;-)
In a similar discussion last year, I was making wistful noises about
36 matches
Mail list logo
