[Haskell-cafe] 0/0 1 == False
Hi! Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 10 Jan 2008 10:22:03 +0200, Mitar [EMAIL PROTECTED] wrote: Hi! Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? Mitar I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Hi Mitar, On Jan 10, 2008 9:22 AM, Mitar [EMAIL PROTECTED] wrote: I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. My understanding is that common mathematical practice is that comparing an undefined value to anything (including itself) always yields false; x /= x is sometimes used to formalize x is undefined. If you have access to JSTOR, this article contains an overview of different fields' perspectives on dealing with undefinedness: http://links.jstor.org/sici?sici=0022-4812(199009)55%3A3%3C1269%3AAPFVOC%3E2.0.CO%3B2-T - Benja ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 10 Jan 2008 10:48:51 +0200, Benja Fallenstein [EMAIL PROTECTED] wrote: Hi Mitar, On Jan 10, 2008 9:22 AM, Mitar [EMAIL PROTECTED] wrote: I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. My understanding is that common mathematical practice is that comparing an undefined value to anything (including itself) always yields false; x /= x is sometimes used to formalize x is undefined. Why let a = a in a /= a is not False ? Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 10 Jan 2008 10:48:51 +0200, Benja Fallenstein [EMAIL PROTECTED] wrote: Hi Mitar, On Jan 10, 2008 9:22 AM, Mitar [EMAIL PROTECTED] wrote: I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. My understanding is that common mathematical practice is that comparing an undefined value to anything (including itself) always yields false; x /= x is sometimes used to formalize x is undefined. How about this: f 1 = 1 f 2 = 2 f 3 /= f 3 Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Mitar wrote: Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? Like nearly all programming languages, Haskell implements the standard IEEE behavior for floating point numbers. That leads to some mathematical infelicities that are especially irking to us in Haskell, but the consensus was that it is best to follow the standard. That is why NaN==NaN, NaNNaN, and NaNNan are all False, The special case of 1/0 is less clear, though. One might decide that it should be an error rather than NaN, as some languages have. Cristian Baboi wrote: I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) This does not violate referential transparency. f 0 is always the same value. (==) is a function like any other; in this case, it does not satisfy the mathematical laws we would like it to in order to conform to standard floating point behavior. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
and there is no such thing as the same bottom right ? On Thu, 10 Jan 2008 11:13:05 +0200, Ketil Malde [EMAIL PROTECTED] wrote: Cristian Baboi [EMAIL PROTECTED] writes: I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) I think you are wrong. Referential transparency says that you can replace any occurence of 'f 0' with another expression of the same value, it does not say anything about the behaviour of (==). -k Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Cristian Baboi wrote: and there is no such thing as the same bottom right ? Yes and no. Semantically, every bottom is the same. However, the Haskell Report makes bottom an explicit exceptional case. Compilers are allowed to do whatever they want with bottoms, including different results for different bottoms. There isn't any choice, really. In order to behave the same for every bottom, you would first have to solve the Halting Problem. Or hang forever on every bottom, which I don't think you would want. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Cristian Baboi [EMAIL PROTECTED] writes: I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) I think you are wrong. Referential transparency says that you can replace any occurence of 'f 0' with another expression of the same value, it does not say anything about the behaviour of (==). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 10 Jan 2008 11:23:51 +0200, Yitzchak Gale [EMAIL PROTECTED] wrote: Cristian Baboi wrote: and there is no such thing as the same bottom right ? Yes and no. Semantically, Yes and No is bottom ? Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Yitzchak Gale wrote: Mitar wrote: Why is 0/0 (which is NaN) 1 == False and at the same time 0/0 1 == False. This means that 0/0 == 1? No, because also 0/0 == 1 == False. I understand that proper mathematical behavior would be that as 0/0 is mathematically undefined that 0/0 cannot be even compared to 1. There is probably an implementation reason behind it, but do we really want such hidden behavior? Would not it be better to throw some kind of an error? Like nearly all programming languages, Haskell implements the standard IEEE behavior for floating point numbers. That leads to some mathematical infelicities that are especially irking to us in Haskell, but the consensus was that it is best to follow the standard. Nitpick: I think the haskell standard doesn't force you to implement IEEE floating point. Rather the haskell standard, for efficiency, permits you to reuse the native floating point of your host system. Since most of us are using haskell on top of IEEE C libraries / FPUs, most of us have IEEE floating point behaviour. Practically speaking, if you want different semantics from what the bare metal gives you, you have to wrap all kinds of things which would otherwise be directly compiled to opcodes, which robs you of any chance of getting the good performance you would hope for. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Cristian Baboi wrote: and there is no such thing as the same bottom right ? I wrote: Yes and no. Semantically, Yes and No is bottom ? Yes and no. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Cristian Baboi wrote: I think this should be put this way: Bottom is a part of the semantic domain which is not Haskell. Rather, something outside Haskell that describes what Haskell programs mean. Yes. In the semantic domain there is one bottom. In Haskell there are many expressions that represent bottom. One cannot test those for equality. Yes. The result of a Haskell function applied to some arguments cannot be bottom. I think you mean that they cannot be bottom if you want to compare them for equality. Yes. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
I wrote: Like nearly all programming languages, Haskell implements the standard IEEE behavior for floating point numbers. That leads to some mathematical infelicities that are especially irking to us in Haskell, but the consensus was that it is best to follow the standard. Jules Bean wrote: Nitpick: I think the haskell standard doesn't force you to implement IEEE floating point. Not a nitpick. I should have written Haskell compilers implement, not Haskell implements. Thanks for the correction, and for the additional illumination. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] viewing HS files in Firefox
Adding the following to my lighttpd config (on Ubuntu Feisty) solves the problem from the server side: external configuration files ## mimetype mapping # change mime type for haskell source files so they get displayed # inside the browser include_shell /usr/share/lighttpd/create-mime.assign.pl mimetype.assign += ( .hs = text/plain, .lhs = text/plain ) -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Yitzchak Gale [EMAIL PROTECTED] writes: In the semantic domain there is one bottom. In Haskell there are many expressions that represent bottom. One cannot test those for equality. If we are being pedantic, I can define data Foo = Foo instance Eq Foo where _ == _ = True (undefined :: Foo) == Foo -- True The result of a Haskell function applied to some arguments cannot be bottom. This function is bottom for any argument: f x = undefined I think you mean that they cannot be bottom if you want to compare them for equality. Yes. See above. What is the precise term for describing this? Structural equality? On the other hand, some bottoms are exceptions, you may be able to catch them and do something useful with them after all, no? How does that fit in? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, 10 Jan 2008, Ketil Malde wrote: I think you mean that they cannot be bottom if you want to compare them for equality. Yes. See above. What is the precise term for describing this? Structural equality? On the other hand, some bottoms are exceptions, you may be able to catch them and do something useful with them after all, no? How does that fit in? Catching errors is a hack: http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tim Sweeney (the gamer)
On 10/01/2008, Galchin Vasili [EMAIL PROTECTED] wrote: Hello, I have been reading with great interested Tim Sweeney's slides on the Next Generation Programming Language. Does anybody know his email address? Vasili is referring to these slides, which will probably interest many people on this list: http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf He refers to Haskell and its strengths (and some of its weaknesses) quite a bit. For those who don't know him, Tim Sweeney is the main programmer behind Epic Games's popular Unreal Engine. When he talks, many game developers will listen. Perhaps more importantly, anything he does will affect a large number of game developers. Apologies if this has been posted before. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Displaying steps in my interpreter
Hello,
I have little practice in Haskell. And I look forward for suggestions on how
to improve the code. Code is not working: some definitions are missed.
The goal of the code is to implement the evaluator for untyped lambda-calculus.
The main problem is how to display each step of reduction? More
detailed questions follows in the end of the code.
Terms of lambda-calculus is the following data-type:
data (Binder bndr) =
Term bndr =
Var bndr
| Lam bndr (Term bndr)
| App (Term bndr) (Term bndr)
Binder class is used to generate new unique binders and to compare binders
class (Eq bndr) = Binder bndr
where {- ... -}
Next we'll define the evaluator. Evaluator returns the WHNF for each
well-formed term, or _|_ if there is no WHNF
Straight forward version:
whnf :: Term bndr - Term bndr
whnf = reduce []
where reduce (a:as) (Lam b i) = reduce as $ subst b a i
reduce as (App f a) = reduce (a:as) f
reduce as term = foldl term App as
But our goal is to perform only one step of reduction. And to display term
after each reduction
We refactor the original definition to perform this:
whnfGen :: (Maybe String - Bool) - Term bndr - Term bndr
whnfGen isFinal = runSteps isFinal $ reduce' []
where reduce' (a:as) (Lam b i) = markStep beta reduce as $ subst b a i
reduce' as (App f a) = reduce (a:as) f
reduce' as term = unwind as term
reduce as term =
do final - checkFinal
if final
then unwind as term
else reduce' as term
unwind as term = return $ foldl term App as
Steps is the monad:
newtype Steps mark a =
Steps { unSteps :: StateT (Maybe mark) (Reader (Maybe mark - Bool)) a }
instance Monad (Steps mark)
where (Steps a) = f = Steps $ a = \x - unSteps (f x)
return a = Steps $ return a
runSteps :: (Maybe mark - Bool) - Steps a - (Maybe mark, a)
runSteps isFinal act = runReader (runStateT (unSteps act) Nothing) isFinal
checkFinal :: Steps mark Bool
checkFinal =
do st - Steps $ get
isFinal - Steps $ lift $ ask
return $ isFinal st
markStep :: mark - Steps mark ()
markStep = Steps . put . Just
Normal whnf can be written as follows:
whnf = whnfGen (const False)
To print the reduction steps we can use the following code
printReductions t =
do t' - whnfGen isJust t
print t'
printReductions t'
Is there any better ways to implement printReductions? Is there a way to
abstract out this steps pattern? For example if I want to show the process
of converting lambda-terms to combinatory logic terms (I, K, S basis).
I'll have to implement the same pattern. I can reuse Steps monad, but, I'll
have to use markStep, checkFinal and special version of recursion. Is there
a way to abstract this?
Is there a more effective way to perform this? In printReductions I have
to rescan the syntax tree over and over again to find the redex. Is there a
way to save the position in the tree, to print the tree and then to resume
from saved position?
Thanx for reading this :)
--
vir
http://vir.comtv.ru/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tim Sweeney (the gamer)
Nick Rolfe [EMAIL PROTECTED] wrote: http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf He refers to Haskell and its strengths (and some of its weaknesses) quite a bit. For those who don't know him, Tim Sweeney is the main programmer behind Epic Games's popular Unreal Engine. When he talks, many game developers will listen. We will dream, most likely. Perhaps more importantly, anything he does will affect a large number of game developers. Dreaming of pointy-haired bosses listening to him, that is. That said, he made the slides before the advent of the GHC API, which is the dream of anyone being worried about scripting performance... not to mention that it greatly reduces the edit/compile/test cycle once in place. Bytestring fusion wasn't in sight, too, afair... or spj worrying about pipeline stalls, to single out a single thing. All this is quite important in an industry where you test whether it's faster to properly generate the index numbers or rely on Java exceptions when you want to randomly index 3x3 portions of an NxM map where the indexed portion reduces to 2x3 or 2x2 in rare cases. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tim Sweeney (the gamer)
On Jan 10, 2008 11:51 AM, Achim Schneider [EMAIL PROTECTED] wrote: Nick Rolfe [EMAIL PROTECTED] wrote: http://morpheus.cs.ucdavis.edu/papers/sweeny.pdf He refers to Haskell and its strengths (and some of its weaknesses) quite a bit. For those who don't know him, Tim Sweeney is the main programmer behind Epic Games's popular Unreal Engine. When he talks, many game developers will listen. We will dream, most likely. Perhaps more importantly, anything he does will affect a large number of game developers. Dreaming of pointy-haired bosses listening to him, that is. I think he meant in the sense that the unreal engine has *lots* of licensees. If UnrealScript 4 is a Haskell-like language with lenient evaluation and limited dependent typing, etc., then that's what a large number of game developers will use in their day-to-day work. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.0.0.0
2008/1/10, Alfonso Acosta [EMAIL PROTECTED]: On Jan 8, 2008 1:28 PM, David Waern [EMAIL PROTECTED] wrote: Dear Haskell community, I'm proud to announce the release of Haddock 2.0.0.0! Great! I already tested a dracs spanshot before the release and seemed to work well with TH code. Any idea about when will hackage adopt this version to generate its documentation? Hmm, I'm not sure since I'm not involved in Hackage, but I can't think of anything that would stop Hackage from adopting it right away. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] viewing HS files in Firefox
Johan Tibell wrote: Adding the following to my lighttpd config (on Ubuntu Feisty) solves the problem from the server side: external configuration files ## mimetype mapping # change mime type for haskell source files so they get displayed # inside the browser include_shell /usr/share/lighttpd/create-mime.assign.pl mimetype.assign += ( .hs = text/plain, .lhs = text/plain ) Fortunately the new haddock uses hscolour, so HS files are served as (colourised!) HTML and the problem is no longer a problem, for me. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tim Sweeney (the gamer)
On Jan 10, 2008 12:41 PM, Achim Schneider [EMAIL PROTECTED] wrote: Sebastian Sylvan [EMAIL PROTECTED] wrote: For those who don't know him, Tim Sweeney is the main programmer behind Epic Games's popular Unreal Engine. When he talks, many game developers will listen. We will dream, most likely. Perhaps more importantly, anything he does will affect a large number of game developers. Dreaming of pointy-haired bosses listening to him, that is. I think he meant in the sense that the unreal engine has *lots* of licensees. If UnrealScript 4 is a Haskell-like language with lenient evaluation and limited dependent typing, etc., then that's what a large number of game developers will use in their day-to-day work. Er, yes. Some gameplay programmers will, and also some level designers, seen 3d-wise, that most likely means gfx guys, who would generally rather work with some warm, fuzzy, graphical switch-event thingy. The rest is still afaict left with C++ which gets linked into the engine. I would assume that if they did go this route of developing their own language, they would probably put a much larger part of the code-base in this new language, but this is all hypothetical. You make less bugs with that language? Fucking learn to write C++! Excuse me? I don't think you would get even close to 1000 people who use UnrealScript to earn their living. You don't need more than that. All you need to do is prove that it works, and other similar languages will have an easier time. If you get a couple of AAA titles using a purely functional language for 50% of the code, then the resistance towards switching languages will likely diminish. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] confusion about 'instance'....
Should be straight forwardsimplest example is...
class A a
data D = D1
instance A D
fine.D is declared to be a member of type class A
what about.
class A a
type T = (forall x.Num x=x)
instance A T
error!...
Illegal polymorphic or qualified type: forall x. (Num x) = x
In the instance declaration for `A T'
I am simply trying to state that all members of typeclass Num are of
typeclass A
Doesn't like it.
Does this mean that instance only operates on 'atomic' (for want of a
better word) types?
-Original Message-
From: Peter Verswyvelen [mailto:[EMAIL PROTECTED] On Behalf Of
Peter Verswyvelen
Sent: 03 January 2008 12:02
To: Nicholls, Mark
Cc: haskell-cafe@haskell.org
Subject: RE: [Haskell-cafe] Is there anyone out there who can translate
C# generics into Haskell?
Hi Mark,
foo1 :: Int - obj - String
Yep...I think that's what I'd dothough I would have done...
foo1 :: obj - Int - String
Does that matter?
Well, it's a good habit in Haskell to move the most important
parameter to
the end of the argument list. See e.g.
http://www.haskell.org/haskellwiki/Parameter_order.
OK but I was going to go onto
Interface IXA where A : IXA {}
and
Interface IXA,B where A : B {}
No, I would not know how to that in Haskell using type classes. It seems
Haskell does not allow cycles in type class definitions. But as I'm new,
this does not mean it's not possible. It's more important to know *what*
you
are trying to do, than to give a solution in a different language, since
OO
and FP are kind of orthogonal languages.
Where I cannot see a way to do the above in Haskell at allas
interfaces effectively operator on type classes not typeswhich
seems
inherently more powerful
Yeah, kind of makes sense. I liked interfaces in C# a lot, but when I
started doing everything with interfaces, I found the lack of support
for
mixins or default implementations problematic. This ended up in a
lot of
copy/paste or encapsulating the implementations into a static class with
plain functions, a mess.
But if these could be done in Haskell the see what could be made of
stuff likewhich is obviously problematic in C# it obviously
doesn't
workbut potentially does make 'sense'.
Interface IXA : A {}
Ah! That's one of the bigger restrictions in C# yes! C++ can do that;
ATL
uses it a lot, and I also like that approach. You can emulate mixins
with
that, and still stay in the single inheritance paradigm. In Haskell you
don't do that at all of course, since you avoid thinking about objects
and
inheritance in the first place.
OO is strange. They offer you the nice concept of inheritance, and then
the
guidelines tell you: don't use too many levels of inheritance...
Although
I've build huge projects using OO, it always felt a bit like unsafe
hacking.
I don't really have that feeling with Haskell, but that could also be
because I'm too new to the language ;-)
I'm looking at Haskell because of the formality of it's type
systembut I'm actually not convinced it is as powerful as an OO
onei.e. OO ones operatate principally (in Haskell speak) on type
classes not types
Maybe you are right, I don't know, my theoritical skills are not high
enough
to answer that. Haskell just feels better to me, although the lack of
a
friendly productive IDE and large standard framework remains a bit of a
burden.
Good luck,
Peter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nicholls, Mark
Sent: Wednesday, January 02, 2008 5:41 PM
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Is there anyone out there who can translate C#
generics into Haskell?
I'm trying to translate some standard C# constucts into Haskell... some
of this seems easy
Specifically
1)
Interface IX
{
}
2)
Interface IXA
{
}
3)
Interface IXA
Where A : IY
{
}
4)
Interface IXA : IZ
Where A : IY
{
}
I can take a punt at the first 2but then it all falls apart
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tim Sweeney (the gamer)
Sebastian Sylvan [EMAIL PROTECTED] wrote: For those who don't know him, Tim Sweeney is the main programmer behind Epic Games's popular Unreal Engine. When he talks, many game developers will listen. We will dream, most likely. Perhaps more importantly, anything he does will affect a large number of game developers. Dreaming of pointy-haired bosses listening to him, that is. I think he meant in the sense that the unreal engine has *lots* of licensees. If UnrealScript 4 is a Haskell-like language with lenient evaluation and limited dependent typing, etc., then that's what a large number of game developers will use in their day-to-day work. Er, yes. Some gameplay programmers will, and also some level designers, seen 3d-wise, that most likely means gfx guys, who would generally rather work with some warm, fuzzy, graphical switch-event thingy. The rest is still afaict left with C++ which gets linked into the engine. You make less bugs with that language? Fucking learn to write C++! I don't know how the UE is priced, but with the $10.000 that the cheapest id engine cost as I looked it up you can develop a whole game... CrystalSpace is sufficient for nearly everything one could want to do, except maybe ahead-of-the-art graphic demos pushed into markets by million-euro advertisement and game-mag-bribing budgets. I don't think you would get even close to 1000 people who use UnrealScript to earn their living. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] confusion about 'instance'....
class A a
type T = (forall x.Num x=x)
instance A T
type declares a synonym, like #define in C - but working only on types. So,
essentially, you wrote
instance A (forall x.Num x = x)
which is not very Haskelly.
I am simply trying to state that all members of typeclass Num are of
typeclass A
You can't do that. But, if there would not be any other instances of A, then
you don't need it at all, you can just use Num class. And if there are some,
for example
data D = D
instance A D
then it can happen (well, it's unlikely, but possible) that you or some other
developer working on your code would declare
instance Num D where ...
After that, you would have two instances of A for the type D, one defined
explicitly and one derived from the Num instance. That's not a problem for this
empty class, but if class A is not empty, say
class A x where a :: x
then the compiler would be unable to decide which instance (and which a) to
choose. So allowing that leads to non-obvious bugs.
However, if you trust yourself enough, you can do what you want to in this way:
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-}
class A a
instance Num a = A a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] confusion about 'instance'....
On Jan 10, 2008 1:03 PM, Nicholls, Mark [EMAIL PROTECTED] wrote:
Should be straight forwardsimplest example is...
class A a
data D = D1
instance A D
fine.D is declared to be a member of type class A
what about.
class A a
type T = (forall x.Num x=x)
instance A T
error!...
Illegal polymorphic or qualified type: forall x. (Num x) = x
In the instance declaration for `A T'
I am simply trying to state that all members of typeclass Num are of
typeclass A
Ahh, you want:
instance Num a = A a
Sorry to lead you on, but that actually is not legal (and
-fallow-undecidable-instances
will make it legal, but you don't want that, because instances of this
particular form
are very likely to lead to an infinite loop).
Adding supertypes like this is not possible in Haskell. I really want
it to be, but alas...
Luke
Doesn't like it.
Does this mean that instance only operates on 'atomic' (for want of a
better word) types?
-Original Message-
From: Peter Verswyvelen [mailto:[EMAIL PROTECTED] On Behalf Of
Peter Verswyvelen
Sent: 03 January 2008 12:02
To: Nicholls, Mark
Cc: haskell-cafe@haskell.org
Subject: RE: [Haskell-cafe] Is there anyone out there who can translate
C# generics into Haskell?
Hi Mark,
foo1 :: Int - obj - String
Yep...I think that's what I'd dothough I would have done...
foo1 :: obj - Int - String
Does that matter?
Well, it's a good habit in Haskell to move the most important
parameter to
the end of the argument list. See e.g.
http://www.haskell.org/haskellwiki/Parameter_order.
OK but I was going to go onto
Interface IXA where A : IXA {}
and
Interface IXA,B where A : B {}
No, I would not know how to that in Haskell using type classes. It seems
Haskell does not allow cycles in type class definitions. But as I'm new,
this does not mean it's not possible. It's more important to know *what*
you
are trying to do, than to give a solution in a different language, since
OO
and FP are kind of orthogonal languages.
Where I cannot see a way to do the above in Haskell at allas
interfaces effectively operator on type classes not typeswhich
seems
inherently more powerful
Yeah, kind of makes sense. I liked interfaces in C# a lot, but when I
started doing everything with interfaces, I found the lack of support
for
mixins or default implementations problematic. This ended up in a
lot of
copy/paste or encapsulating the implementations into a static class with
plain functions, a mess.
But if these could be done in Haskell the see what could be made of
stuff likewhich is obviously problematic in C# it obviously
doesn't
workbut potentially does make 'sense'.
Interface IXA : A {}
Ah! That's one of the bigger restrictions in C# yes! C++ can do that;
ATL
uses it a lot, and I also like that approach. You can emulate mixins
with
that, and still stay in the single inheritance paradigm. In Haskell you
don't do that at all of course, since you avoid thinking about objects
and
inheritance in the first place.
OO is strange. They offer you the nice concept of inheritance, and then
the
guidelines tell you: don't use too many levels of inheritance...
Although
I've build huge projects using OO, it always felt a bit like unsafe
hacking.
I don't really have that feeling with Haskell, but that could also be
because I'm too new to the language ;-)
I'm looking at Haskell because of the formality of it's type
systembut I'm actually not convinced it is as powerful as an OO
onei.e. OO ones operatate principally (in Haskell speak) on type
classes not types
Maybe you are right, I don't know, my theoritical skills are not high
enough
to answer that. Haskell just feels better to me, although the lack of
a
friendly productive IDE and large standard framework remains a bit of a
burden.
Good luck,
Peter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nicholls, Mark
Sent: Wednesday, January 02, 2008 5:41 PM
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Is there anyone out there who can translate C#
generics into Haskell?
I'm trying to translate some standard C# constucts into Haskell... some
of this seems easy
Specifically
1)
Interface IX
{
}
2)
Interface IXA
{
}
3)
Interface IXA
Where A : IY
{
}
4)
Interface IXA : IZ
Where A : IY
{
}
I can take a punt at the first 2but then it all falls apart
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] confusion about 'instance'....
Thanks for your response, I think you helped me on one of my previous
abberations.
Hmmmthis all slightly does my head inon one hand we have
typesthen type classes (which appear to be a relation defined on
types)then existential types...which now appear not to be treated
quite in the same way as 'normal' typesand in this instance the
syntax even seems to changedoes
instance Num a = A a
Mean the same thing as
instance A (forall a.Num a=a)
seems like a weird questions, as you're saying my version doesn't mean
anythingbut
does it mean that forall types 'a', if 'a' is a member of the class
Num, then 'a' is a member of class 'A'
and secondly in what way can this construct lead to undecidable
instances
What are the instances, and what about them is undecidableseems
pretty decidable to me?
What is the ramifications of turning this option on?
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Sent: 10 January 2008 13:14
To: Nicholls, Mark
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] confusion about 'instance'
On Jan 10, 2008 1:03 PM, Nicholls, Mark [EMAIL PROTECTED] wrote:
Should be straight forwardsimplest example is...
class A a
data D = D1
instance A D
fine.D is declared to be a member of type class A
what about.
class A a
type T = (forall x.Num x=x)
instance A T
error!...
Illegal polymorphic or qualified type: forall x. (Num x) = x
In the instance declaration for `A T'
I am simply trying to state that all members of typeclass Num are of
typeclass A
Ahh, you want:
instance Num a = A a
Sorry to lead you on, but that actually is not legal (and
-fallow-undecidable-instances
will make it legal, but you don't want that, because instances of this
particular form
are very likely to lead to an infinite loop).
Adding supertypes like this is not possible in Haskell. I really want
it to be, but alas...
Luke
Doesn't like it.
Does this mean that instance only operates on 'atomic' (for want of a
better word) types?
-Original Message-
From: Peter Verswyvelen [mailto:[EMAIL PROTECTED] On Behalf Of
Peter Verswyvelen
Sent: 03 January 2008 12:02
To: Nicholls, Mark
Cc: haskell-cafe@haskell.org
Subject: RE: [Haskell-cafe] Is there anyone out there who can
translate
C# generics into Haskell?
Hi Mark,
foo1 :: Int - obj - String
Yep...I think that's what I'd dothough I would have done...
foo1 :: obj - Int - String
Does that matter?
Well, it's a good habit in Haskell to move the most important
parameter to
the end of the argument list. See e.g.
http://www.haskell.org/haskellwiki/Parameter_order.
OK but I was going to go onto
Interface IXA where A : IXA {}
and
Interface IXA,B where A : B {}
No, I would not know how to that in Haskell using type classes. It
seems
Haskell does not allow cycles in type class definitions. But as I'm
new,
this does not mean it's not possible. It's more important to know
*what*
you
are trying to do, than to give a solution in a different language,
since
OO
and FP are kind of orthogonal languages.
Where I cannot see a way to do the above in Haskell at allas
interfaces effectively operator on type classes not typeswhich
seems
inherently more powerful
Yeah, kind of makes sense. I liked interfaces in C# a lot, but when I
started doing everything with interfaces, I found the lack of support
for
mixins or default implementations problematic. This ended up in a
lot of
copy/paste or encapsulating the implementations into a static class
with
plain functions, a mess.
But if these could be done in Haskell the see what could be made of
stuff likewhich is obviously problematic in C# it obviously
doesn't
workbut potentially does make 'sense'.
Interface IXA : A {}
Ah! That's one of the bigger restrictions in C# yes! C++ can do that;
ATL
uses it a lot, and I also like that approach. You can emulate mixins
with
that, and still stay in the single inheritance paradigm. In Haskell
you
don't do that at all of course, since you avoid thinking about
objects
and
inheritance in the first place.
OO is strange. They offer you the nice concept of inheritance, and
then
the
guidelines tell you: don't use too many levels of inheritance...
Although
I've build huge projects using OO, it always felt a bit like unsafe
hacking.
I don't really have that feeling with Haskell, but that could also be
because I'm too new to the language ;-)
I'm looking at Haskell because of the formality of it's type
systembut I'm actually not convinced it is as powerful as an OO
onei.e. OO ones operatate principally (in Haskell speak) on
type
classes not types
Maybe you are right, I don't know, my theoritical skills are not high
enough
to answer that. Haskell just feels better to me, although the lack
of
a
friendly productive IDE and large standard framework remains a bit of
a
Re[2]: [Haskell-cafe] confusion about 'instance'....
Hello Mark, Thursday, January 10, 2008, 4:25:20 PM, you wrote: instance Num a = A a Mean the same thing as instance A (forall a.Num a=a) programmers going from OOP world always forget that classes in Haskell doesn't the same as classes in C++. *implementation* of this instance require to pass dictionary of Num class along with type. now imagine the following code: f :: A a = a - a f cannot use your instance because it doesn't receive Num dictionary of type `a`. it is unlike OOP situation where every object carries the generic VMT which includes methods for every class/interface that object supports as usual, i suggest you to study http://haskell.org/haskellwiki/OOP_vs_type_classes first and especially two papers mentioned in References there -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] confusion about 'instance'....
class A a
type T = (forall x.Num x=x)
instance A T
type declares a synonym, like #define in C - but working only on
types.
So, essentially, you wrote
Yep that's fine..
instance A (forall x.Num x = x)
Yep
which is not very Haskelly.
Hmmm...
I am simply trying to state that all members of typeclass Num are of
typeclass A
You can't do that.
Because it wont let me...or because it makes no sense?
But, if there would not be any other instances of A,
then you don't need it at all, you can just use Num class. And if
there
are some, for example
Ok but there may beI'm just trying to get my head around Haskells
type system
data D = D
instance A D
Yep.
D is a member of A
then it can happen (well, it's unlikely, but possible) that you or
some
other developer working on your code would declare
instance Num D where ...
D is a member of Num
(and I'm assuming that we've gotAll Nums are also members of
Awhich is fine...so far).
So...Num x implies A x
So...D is a member of A
Fine.
After that, you would have two instances of A for the type D, one
defined
explicitly and one derived from the Num instance.
I would have 2 declarations that D is a member of Aboth consistent.
That's not a problem for
this empty class, but if class A is not empty, say
class A x where a :: x
then the compiler would be unable to decide which instance (and which
a)
to choose. So allowing that leads to non-obvious bugs.
This slightly bamboozles me.
I only have 1 type.
If I say my name is mark twice, it doesn't mean I belong to set of
objects called Mark twice
which makes me think that type classes are not simple relations on types
after allthey appear to be relations on declarations of types being
members of a class.
So in my example...there exists two instances of me claiming my name is
Mark.
However, if you trust yourself enough, you can do what you want to in
this
way:
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances #-}
class A a
instance Num a = A a
Hmmm...OK...
It all seems a little odd
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tim Sweeney (the gamer)
Sebastian Sylvan [EMAIL PROTECTED] wrote: You make less bugs with that language? Fucking learn to write C++! Excuse me? A probable exclamation of a pointy-haired boss, that is. What I wanted to say is that if you tell such a guy that you'll make less bugs in language X, he would assume that you can't program properly at all or in the language you're supposed to be programming in. As much as I agree with your idealism, the most rigorous proof of the earth being a sphere orbiting the sun could not convince people of the fact that the earth isn't a planar disk, and actual awareness on how the sun rises and the sun sets is rare even in these days where people accept the fact. Paradigm changes might only take a generation in a scientific community, but it takes close to eons in a society, as its members aren't nearly as involved in the scientific progress, and are (that's a guess now) equally likely to resist a new paradigm as the scientists themselves. The surest thing to make people switch is to make them not aware of it, i.e. make things look exactly like in C, with incremental updates of the same variable and everything, while still retaining a purely functional semantic under the hood. I guess that's why success has to be avoided at all cost. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Neil Mitchell wrote: Laziness and purity together help with equational reasoning, compiler transformations, less obscure bugs, better compositionality etc. Although it could be argued that laziness is the cause of some very obscure bugs... g Niko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tim Sweeney (the gamer)
Achim Schneider [EMAIL PROTECTED] wrote:
The surest thing to make people switch is to make them not aware of
it, i.e. make things look exactly like in C, with incremental updates
of the same variable and everything, while still retaining a purely
functional semantic under the hood.
I guess that's why success has to be avoided at all cost.
But, still, I bet people would like to see
Warning: Statements without effect:
c - return 1 = increment return 2
*** ^^^ ||
when they write
c = 1
++c
c = 2
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] confusion about 'instance'....
On Jan 10, 2008 1:25 PM, Nicholls, Mark [EMAIL PROTECTED] wrote: Thanks for your response, I think you helped me on one of my previous abberations. Hmmmthis all slightly does my head inon one hand we have typesthen type classes (which appear to be a relation defined on types)then existential types...which now appear not to be treated quite in the same way as 'normal' typesand in this instance the syntax even seems to changedoes instance Num a = A a Mean the same thing as instance A (forall a.Num a=a) Uh... that second one is pretty much nonsensical to me. I could imagine it meaning the type (forall a.Num a = a) itself is an instance of A, but not specializations of it (like Int). But without an identity in the type system, the meaning of that would be convoluted. It's kind of off topic, but just for the interested, here are two similar, legal constructions: Existential: newtype Numeric = forall a. Num a = Numeric a Universal: newtype Numeric' = Numeric' (forall a. Num a = a) Both of which are easily declared to be instances of Num. They're not what you want though, because Haskell doesn't support what you want :-(. Anyway, if you have a value of type Numeric, you know it contains some value of a Num type, but you don't know what type exactly (and you can never find out). If you have a value of type Numeric', then you can produce a value of any Num type you please (i.e. the value is built out of only operations in the Num class, nothing more specific). But that was a digression; ignore at your leisure (now that you've already read it :-). and secondly in what way can this construct lead to undecidable instances Okay, read: instance A a = B b (where a and be might be more complex expressions) not as b is an instance of B whenever a is an instance of A, but rather as b is an instance of B, and using it as such adds a constraint of A a. Let's look at a slightly more complex (and contrived) example: class Foo a where foo :: a - a instance (Foo [a]) = Foo a where foo x = head $ foo [x] Then when checking the type of the expression foo (0::Int), we'd have to check if Foo Int, Foo [Int], Foo [[Int]], Foo [[[Int]]], ad infinitum. What are the instances, and what about them is undecidableseems pretty decidable to me? What is the ramifications of turning this option on? Theoretically, compile time fails to guarantee to ever finish. Practically, ghc will give you a very-difficult-to-reason-about message when constraint checking stack overflows. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Re[2]: [Haskell-cafe] confusion about 'instance'....
-Original Message- From: Bulat Ziganshin [mailto:[EMAIL PROTECTED] Sent: 10 January 2008 13:36 To: Nicholls, Mark Cc: Luke Palmer; haskell-cafe@haskell.org Subject: Re[2]: [Haskell-cafe] confusion about 'instance' Hello Mark, Thursday, January 10, 2008, 4:25:20 PM, you wrote: instance Num a = A a Mean the same thing as instance A (forall a.Num a=a) programmers going from OOP world always forget that classes in Haskell doesn't the same as classes in C++. *implementation* of this instance require to pass dictionary of Num class along with type. now imagine the following code: My confusion is not between OO classes and Haskell classes, but exactly are the members of a Haskell type class...I'd naively believed them to be types (like it says on the packet!)...but now I'm not so sure. f :: A a = a - a f cannot use your instance because it doesn't receive Num dictionary of type `a`. it is unlike OOP situation where every object carries the generic VMT which includes methods for every class/interface that object supports as usual, i suggest you to study http://haskell.org/haskellwiki/OOP_vs_type_classes first and especially two papers mentioned in References there I have donelearning is not an atomic operationi.e. I can only believe what I understand...academic papers are especially beyond me at this point. I can translate OO into mathematical logic pretty easily, I was trying to do the same thing (informally of course) with Haskellbut things are not quite what they appearnot because of some OO hang up (which I probably have many)...but because of what type class actually means. So you may be right, I think I need to understand more about the sematics of Haskell...I was hoping to stay (initially) ignorant. I will try the postscript doc and see if it makes any sense. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] confusion about 'instance'....
On Jan 10, 2008 2:04 PM, Nicholls, Mark [EMAIL PROTECTED] wrote: I can translate OO into mathematical logic pretty easily, I was trying to do the same thing (informally of course) with Haskellbut things are not quite what they appearnot because of some OO hang up (which I probably have many)...but because of what type class actually means. But you can think of a type class as a set of types! The problem is that if we allow certain kinds of instances (such as the Foo instance I gave earlier) then the set is allowed to be non-recursive (only recursively enumerable), so determining whether a particular type is a member of it would be undecidable. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Niko Korhonen writes: ... Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] confusion about 'instance'....
Thanks for your response, I think you helped me on one of my previous abberations. Hmmmthis all slightly does my head inon one hand we have typesthen type classes (which appear to be a relation defined on types)then existential types...which now appear not to be treated quite in the same way as 'normal' typesand in this instance the syntax even seems to changedoes instance Num a = A a Mean the same thing as instance A (forall a.Num a=a) Uh... that second one is pretty much nonsensical to me. I could imagine it meaning the type (forall a.Num a = a) itself is an instance of A, but not specializations of it (like Int). But without an identity in the type system, the meaning of that would be convoluted. It's kind of off topic, but just for the interested, here are two similar, legal constructions: ok Existential: newtype Numeric = forall a. Num a = Numeric a My compiler doesn't like this A newtype constructor cannot have an existential context, Universal: newtype Numeric' = Numeric' (forall a. Num a = a) Not so sure I understand the difference here. Both of which are easily declared to be instances of Num. They're not what you want though, because Haskell doesn't support what you want :-(. Anyway, if you have a value of type Numeric, you know it contains some value of a Num type, but you don't know what type exactly (and you can never find out). If you have a value of type Numeric', then you can produce a value of any Num type you please (i.e. the value is built out of only operations in the Num class, nothing more specific). But that was a digression; ignore at your leisure (now that you've already read it :-). Makes little sense to meNumeric looks reasonable...I think... Numeric'...seems weirdand I'm not sure I understood the explanation. and secondly in what way can this construct lead to undecidable instances Okay, read: instance A a = B b (where a and be might be more complex expressions) not as b is an instance of B whenever a is an instance of A, but rather as b is an instance of B, and using it as such adds a constraint of A a. Let's look at a slightly more complex (and contrived) example: class Foo a where foo :: a - a instance (Foo [a]) = Foo a where foo x = head $ foo [x] Then when checking the type of the expression foo (0::Int), we'd have to check if Foo Int, Foo [Int], Foo [[Int]], Foo [[[Int]]], ad infinitum. Ooo blimeythat sort of makes sense. What are the instances, and what about them is undecidableseems pretty decidable to me? What is the ramifications of turning this option on? Theoretically, compile time fails to guarantee to ever finish. Practically, ghc will give you a very-difficult-to-reason-about message when constraint checking stack overflows. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] confusion about 'instance'....
Nicholls, Mark wrote: Thanks for your response, I think you helped me on one of my previous abberations. Hmmmthis all slightly does my head inon one hand we have typesthen type classes (which appear to be a relation defined on types)then existential types...which now appear not to be treated quite in the same way as 'normal' typesand in this instance the syntax even seems to changedoes instance Num a = A a This means: Given any type a. Any type at all. Yes, ANY type a, we accept that it might be an instance of A, and we add a Num context to the current inference. So, supposing: f :: (A a) = a - b and we're trying to type check: f x We first try to unify x's type with the type variable a, which is easy. Then we impose the constraint A a. At some later stage we will try to resolve this constraint. When we try to resolve it, we find that all types a are instances of A, but you have to add a Num constraint. So we add the Num constraint. This behaviour is not what everyone wants, but it is a consequence of they type classes are specified. GHC lets you turn off this behaviour somewhat with overlapping and undecidable instances but that's not really an ideal solution either. The ideal solution to this precise case is probably just to make the Num class a superclass of A. That seems to do what you want. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] confusion about 'instance'....
On Jan 10, 2008 1:36 PM, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Mark, Thursday, January 10, 2008, 4:25:20 PM, you wrote: instance Num a = A a Mean the same thing as instance A (forall a.Num a=a) programmers going from OOP world always forget that classes in Haskell doesn't the same as classes in C++. *implementation* of this instance require to pass dictionary of Num class along with type. now imagine the following code: f :: A a = a - a f cannot use your instance because it doesn't receive Num dictionary of type `a`. it is unlike OOP situation where every object carries the generic VMT which includes methods for every class/interface that object supports I'm not sure that's a good argument. It doesn't need a Num dictionary, it only needs an A dictionary. That's what it says. You only need a Num dictionary in order to construct an A dictionary, which seems perfectly reasonable. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] confusion about 'instance'....
Nicholls, Mark wrote: My confusion is not between OO classes and Haskell classes, but exactly are the members of a Haskell type class...I'd naively believed them to be types (like it says on the packet!)...but now I'm not so sure. Which packet? Classes are not types. Classes are groups of types. Sets of types. Classifications of types. For any type, you can ask the quesiton is this type a member of this class, or not? Without wishing to split hairs too finely, I find it a useful intuition not to consider the class context part of the type somehow. So, when you see this: (Num a, Eq b) = a - b - a Rather than thinking of that whole thing as a type, it helps to think of the part on the right of the = as the 'actual type' and the part on the left of the = as some extra constraints on the type. So you might say this has the type a - b - a, providing that a is a Num and b is an Eq. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Problems with Unicode Symbols as Infix Function Names in Propositional Calculus Haskell DSL
Cetin Sert wrote: I want to design a DSL in Haskell for propositional calculus. But instead of using natural language names for functions like or, and, implies etc. I want to use Unicode symbols as infix functions ¬, ˅, ˄, →, ↔ But I keep getting error messages from the GHC parser. Is there a way to make GHC parse my source files correctly? If it is not possible yet, please consider this as a “feature request”. GHC supports unicode source files encoded using UTF-8 by default. It should be possible to use many unicode symbols for infix symbols. Note that when -XUnicodeSyntax is on, certain symbols have special meanings (e.g. → means -). Without more information I can't tell exactly what problem you're encountering. If you supply the source code you're trying to compile, we might be able to help. Also, note that [EMAIL PROTECTED] is a better forum for GHC-specific issues. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] viewing HS files in Firefox
On Jan 10, 2008 1:55 PM, Jules Bean [EMAIL PROTECTED] wrote: Johan Tibell wrote: Adding the following to my lighttpd config (on Ubuntu Feisty) solves the problem from the server side: external configuration files ## mimetype mapping # change mime type for haskell source files so they get displayed # inside the browser include_shell /usr/share/lighttpd/create-mime.assign.pl mimetype.assign += ( .hs = text/plain, .lhs = text/plain ) Fortunately the new haddock uses hscolour, so HS files are served as (colourised!) HTML and the problem is no longer a problem, for me. Jules My problem is when viewing plain darcs repositories (like mine on darcs.johantibell.com which I recently fixed with the above mime type hack.) -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] confusion about 'instance'....
-Original Message- From: Jules Bean [mailto:[EMAIL PROTECTED] Sent: 10 January 2008 14:22 To: Nicholls, Mark Cc: Bulat Ziganshin; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] confusion about 'instance' Nicholls, Mark wrote: My confusion is not between OO classes and Haskell classes, but exactly are the members of a Haskell type class...I'd naively believed them to be types (like it says on the packet!)...but now I'm not so sure. Which packet? The packet labelled type classyou're from .co.ukyou should understand my English idioms. :-) Classes are not types. Yep. Classes are groups of types. Sets of types. Classifications of types. I had them down as an n-ary relation on typessomeone's said something somewhere that's made me question that...but I think I misinterpreted themso I may default back to n-ary relation. For any type, you can ask the quesiton is this type a member of this class, or not? yep Without wishing to split hairs too finely, I find it a useful intuition not to consider the class context part of the type somehow. So, when you see this: (Num a, Eq b) = a - b - a Rather than thinking of that whole thing as a type, it helps to think of the part on the right of the = as the 'actual type' and the part on the left of the = as some extra constraints on the type. Hmmm...I'm not sure that helpsit may just make me more confused. So you might say this has the type a - b - a, providing that a is a Num and b is an Eq. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Re[2]: [Haskell-cafe] confusion about 'instance'....
Someone said something about having 2 instances of the type in the typeclass.maybe I misinterpreted it. -Original Message- From: Luke Palmer [mailto:[EMAIL PROTECTED] Sent: 10 January 2008 14:12 To: Nicholls, Mark Cc: Bulat Ziganshin; haskell-cafe@haskell.org Subject: Re: Re[2]: [Haskell-cafe] confusion about 'instance' On Jan 10, 2008 2:04 PM, Nicholls, Mark [EMAIL PROTECTED] wrote: I can translate OO into mathematical logic pretty easily, I was trying to do the same thing (informally of course) with Haskellbut things are not quite what they appearnot because of some OO hang up (which I probably have many)...but because of what type class actually means. But you can think of a type class as a set of types! The problem is that if we allow certain kinds of instances (such as the Foo instance I gave earlier) then the set is allowed to be non-recursive (only recursively enumerable), so determining whether a particular type is a member of it would be undecidable. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Field updates in a state monad
Hello list,
still playing with monads and states, I have the following question:
Given:
import Control.Monad.State.Lazy
data MyData = MyData { content :: String }
foobar :: State MyData String
foobar = do
gets content
Ok, that looks nice and tidy. But:
foobar2 :: State MyData ()
foobar2 = do
modify $ \x - x { content = hello haskell}
...looks not so nice.
Exists there a way to write this cleaner without writing countless
set_xyz helper functions?
Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Field updates in a state monad
* Michael Roth wrote:
Exists there a way to write this cleaner without writing countless
set_xyz helper functions?
The syntactic sugar for record modifications is simply that: sugar.
You might write your own modifier functions:
set_bla x y = x { bla = y }
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: viewing HS files in Firefox
My problem is when viewing plain darcs repositories (like mine on
darcs.johantibell.com which I recently fixed with the above mime type
hack.)
Please complain to your browser('s authors): most browsers only provide
*one* way to view a given mime-type, which is stupid. It's not specific
to .hs files.
They could at least provide a way to override the provided mime-type, so
you can say display this application/octet-stream file as
a text/plain. Similarly they should allow you to choose (via
a context-menu, for example) to open a pdf file in the pdf plugin or in
a separate application.
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] wrote: Niko Korhonen writes: ... Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. [1..] == [1..] , for assumed operational semantics of ones own axiomatic semantics. Bugs are only a misunderstanding away. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] confusion about 'instance'....
Nicholls, Mark wrote: I only have 1 type. If I say my name is mark twice, it doesn't mean I belong to set of objects called Mark twice Typeclasses define not only sets of types, but a common interface for these types, too. An analogy would be to say: I have a name, and it is Marc. I have a name, and it is John. From a set of things perspective, there is no problem: you belong to the set of people having a name. But what name should I actually use when I want to adress you? Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: viewing HS files in Firefox
Stefan Monnier [EMAIL PROTECTED] wrote:
My problem is when viewing plain darcs repositories (like mine on
darcs.johantibell.com which I recently fixed with the above mime
type hack.)
Please complain to your browser('s authors): most browsers only
provide *one* way to view a given mime-type, which is stupid. It's
not specific to .hs files.
They could at least provide a way to override the provided mime-type,
so you can say display this application/octet-stream file as
a text/plain. Similarly they should allow you to choose (via
a context-menu, for example) to open a pdf file in the pdf plugin or
in a separate application.
Konqueror offers:
- mime default actions
- opening path/index.html if pointed to path/ or path when operating
locally
- for any hyperlink:
- save link as
- copy link address
- open with--
- preview with --
...as it does offer copy, move, open with and preview with for any file
in directory mode. Kpdf and likewise also nicely integrate their own
buttons into the toolbar, replacing the khtmlpart zoom ones and so on.
Vastly underestimated this thing is.
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Jan 10, 2008 3:36 PM, Achim Schneider [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Niko Korhonen writes: ... Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. [1..] == [1..] , for assumed operational semantics of ones own axiomatic semantics. Bugs are only a misunderstanding away. It has nothing to do with laziness, but with using an algebraic function (==) with a codata structure (stream). If Haskell kept laziness but enforced separation of data and codata such code wouldn't compile. Lazy lists or streams never are a problem, but you can't (generically) fold codata. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. Best regards, Daniel Yokomizo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Daniel Yokomizo [EMAIL PROTECTED] wrote: On Jan 10, 2008 3:36 PM, Achim Schneider [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Niko Korhonen writes: ... Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. [1..] == [1..] , for assumed operational semantics of ones own axiomatic semantics. Bugs are only a misunderstanding away. It has nothing to do with laziness, but with using an algebraic function (==) with a codata structure (stream). If Haskell kept laziness but enforced separation of data and codata such code wouldn't compile. Lazy lists or streams never are a problem, but you can't (generically) fold codata. Exactly. Denotationally it hasn't, but axiomatically it has. Because it looks like mathematical terms one can easily get lost in believing it reduces like mathematics, too. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] confusion about 'instance'....
On Thu, 10 Jan 2008, Nicholls, Mark wrote: Existential: newtype Numeric = forall a. Num a = Numeric a My compiler doesn't like this A newtype constructor cannot have an existential context, Universal: newtype Numeric' = Numeric' (forall a. Num a = a) Not so sure I understand the difference here. Looks like http://www.haskell.org/haskellwiki/Generic_number_type ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] confusion about 'instance'....
Nicholls, Mark wrote: Classes are groups of types. Sets of types. Classifications of types. I had them down as an n-ary relation on typessomeone's said something somewhere that's made me question that...but I think I misinterpreted themso I may default back to n-ary relation. Yes, and 1-ary relations are sets. And haskell98 only supports unary type classes, and all our discussion so far had been about unary type classes. But, since you mention it, yes MPTCs are n-ary relations. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
On Jan 9, 2008 5:42 PM, Henning Thielemann [EMAIL PROTECTED] wrote: I just want to point out that unsafePerformIO is at the core of the (safe) bytestring library. As SPJ et al pointed out, this is crucial functionality, and is only unsafe if unsafely used. Indeed, there are hacks and they are some times necessary. The good thing about Haskell is, that hacks look like hacks. In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html Maybe this is also an option for Haskell? I don't think this is a good idea. It comes down to a question of whether you think it should be allowed for Haskell code to be used to write core Haskell libraries in a first-class manner. Perhaps you think libraries should always be in C in order to avoid the use of unsafePerformIO, but I prefer to allow them to be written in Haskell. But then, I don't see unsafePerformIO as inherently a hack. It's the only possible way that certain useful abstractions can be impelemented--at least, that's understanding. I'd be curious as to how much of the Prelude would be marked unsafe if you had your wish... David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
Neil wrote: Laziness. It is very difficult to have a lazy language which is not pure. Exactly. Laziness and purity together help with equational reasoning, compiler transformations, less obscure bugs, better compositionality etc. Related, but nevertheless a shameless plug: Jurriaan Hage and myself did some thinking about this lately and put some stuff on paper that I presented two days ago at PEPM [1]. Here's a quote, taken from the introduction: Functional programming languages can be classified along several axes: we can distinguish between pure and impure langauges as well as between langauges with strict and nonstrict semantics. In practice, not all combinations make sense. Nonstrict languages better be pure, because reasoning about unrestricted side-effects becomes more complicated when the order of evaluation gets less predictable. Purity has some clear advantages. For example, it enables equational reasoning and it opens the road to memoization, common subexpression elimination, and parallel evaluation strategies. The driving force that enables these opportunities is referential transparency: in a pure language, each of a program's terms can, at any time, be replaced by its value without changing the meaning of the program as a whole. Cheers, Stefan - [1] Jurriaan Hage and Stefan Holdermans. Heap recycling for lazy languages. In John Hatcliff, Robert Glück, and Oege de Moor, editors, _Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation_, PEPM'08, San Francisco, California, USA, January 7--8, 2008, pages 189--197. ACM Press, 2008. http://doi.acm.org/10.1145/1328408.1328436 .___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Achim Schneider answers my question to somebody else (Niko Korhonen): Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. [1..] == [1..] Whatever you may say more, this is neither obscure nor a bug. I still wait for a relevant example. But I don't insist too much... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-mode 2.4
First of all, thanks. My Aqua Emacs (on OS X Leopard) hangs when I send a command like C-c C-l or C-c C-t to the interpreter (I can quit the command using C-g) . Starting the interpreter and using :l from inside it works fine. This is using GHC 6.8 (and I think I also tried 6.6.) What could be the problem? I also tried to eval this but it didn't make a difference: (setq inferior-haskell-find-project-root nil) It looks like this is a problem with 6.8.2 as haskell-mode-2.3 has the same problem? Seems like the commands being sent to the haskell process never reaches it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] wrote: Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Prelude sum [1..100] *** Exception: stack overflow Prelude Data.List.foldl' (+) 0 [1..100] 5050 Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] wrote: Achim Schneider answers my question to somebody else (Niko Korhonen): Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. [1..] == [1..] Whatever you may say more, this is neither obscure nor a bug. I still wait for a relevant example. But I don't insist too much... It's not an example of a bug, but of a cause. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comments and suggestions on code
Hi Jonathan On Wed, 2008-01-09 at 21:32 -0800, Jonathan Cast wrote: An actual coding question, abuse? We should be so lucky. :) Your comments are much appreciated. This function is fairly complicated, simply because of the number of separate definitions involved; I would be looking for opportunities to inline definitions here, so it's clearer what the definitions are. (Also, I would try to build a single, self-recursive function at the top level, put the call to procInfo there, and make everything else pure). I rewrote insertInTree like below. Now it is the only function that has a StateT return type, and I also got rid of addProc, insertPid and insertParent :) insertInTree :: Pid - StateT PsTree IO () insertInTree pid = do tree - get if Map.member pid tree then return () else do info - lift $ procInfo pid modify (Map.insert pid info) let ppid = parentPid info if ppid /= 0 then do insertInTree ppid modify (appendChild ppid pid) else return () I also rewrote createTree like this: createTree :: IO PsTree createTree = do entries - getDirectoryContents /proc let procs = filter (=~ ^[0-9]+$) entries execStateT (mapM_ insertInTree procs) Map.empty Is that a bad way to do it? If haskell wasn't lazy this would be 3 O(n) operations, and I could write it using readDirStream to process all entries in one pass. I'm not sure if that's really necessary when laziness is present though. Thanks a lot for the other comments. I'll look into using a record for PsInfo now. Best, Andre ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Field updates in a state monad
2008/1/10, Lutz Donnerhacke [EMAIL PROTECTED]:
* Michael Roth wrote:
Exists there a way to write this cleaner without writing countless
set_xyz helper functions?
The syntactic sugar for record modifications is simply that: sugar.
You might write your own modifier functions:
set_bla x y = x { bla = y }
That seems to be exactly what Michael search to avoid. And I don't see
any way to do that with the haskell records. Some extension of records
may have first-class label though.
A pretty interesting alternative could be HList, it has first-class
label and a bunch of other good stuff. I never used it though, so I
don't know how it affects the performances, if someone could give his
experience with it ?
--
Jedaï
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
rendel: [EMAIL PROTECTED] wrote: Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Prelude sum [1..100] *** Exception: stack overflow Prelude Data.List.foldl' (+) 0 [1..100] 5050 See, http://hackage.haskell.org/trac/ghc/ticket/1997 Strictness for for atomic numeric types is inconsitently applied across the base library. Fixing the inconsitencies would let fix a range of similar issues. Note the strictness analyser handles this in compiled code, but doesn't run in ghci. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
Achim Schneider: jerzy.karczmarczuk asks what's wrong with: [1..] == [1..] Whatever you may say more, this is neither obscure nor a bug. I still wait for a relevant example. But I don't insist too much... It's not an example of a bug, but of a cause. A cause of WHAT?? This is a perfect, nice, runaway computation, which agrees with all dogmas of my religion. Now, if somebody says that the fact that some people find it difficult to grasp the essence of laziness, and THIS is a source of bugs, I may believe. But not the laziness itself. (For some people the (==) operator seems to be a permanent source of bugs.) The difference between fold and stricter fold' won't convince me either. People who want to use laziness must simply read the documentation... On the other hand, what Don Stewart pointed out, the inconsistency between enumFrom and enumFromTo, and the difference of behaviours when one passes from Int to Integer, now, this is another story, worrying a little... Thanks. Perhaps another example is more relevant, the tradeoffs space-time in the optimized version of the powerset generator... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: A triple of new packages for talking tothe outside world
agl: On Jan 9, 2008 5:01 PM, David Roundy [EMAIL PROTECTED] wrote: But I can't imagine an implementation in which this change wouldn't slow down getBytes for the normal case. Perhaps the slowdown would be small, but it seems unwise to enforce that slowness at the API level, when we've already got a perfectly good API for fast binary IO. Maybe there's some type hackery you could do to avoid a speed penalty, but that's a lot to add for a somewhat dubious benefit. I believe that it would be an additional if statement in the fast path at least. How about a BitGet monad which get be run in the Get monad? test :: Get () test = do runBitGet 2 (do getBitField 2) So the first argument to runBitGet is the number of bytes to parse for bit fields and then functions in BitGet can extract bit-length ints etc. Anyone like that idea? That's pretty much what we envisaged as the approach to take. Monad transformers adding some bit-buffer state over Get/Put. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] confusion about 'instance'....
If I say my name is mark twice, it doesn't mean I belong to set of objects called Mark twice Yes, but instance declaration doesn't only state that some type belongs to some class. It also provides some operations on this type. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tim Sweeney (the gamer)
On Jan 10, 2008 1:49 PM, Achim Schneider [EMAIL PROTECTED] wrote: Sebastian Sylvan [EMAIL PROTECTED] wrote: You make less bugs with that language? Fucking learn to write C++! Excuse me? A probable exclamation of a pointy-haired boss, that is. What I wanted to say is that if you tell such a guy that you'll make less bugs in language X, he would assume that you can't program properly at all or in the language you're supposed to be programming in. Maybe I'm just lucky, but if we are still talking about the games industry I don't think this fits my experience of bosses. Games compete very much on performance, and we basically rewrite almost all of our code over a few years or so anyway (though not all at once). I think that means the games industry is very well suited to be at the forefront of adopting new technology, but there would have to be a fairly disruptive change in order for someone to say, for example, right, let's rewrite all our runtime code in Haskell. Concurrency does seem pretty disruptive. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC API?
Hello, I am reading http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API. Is the GHC API a means of reflection Haskell? Or to put more simply what is its intent? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC API?
vigalchin: Hello, I am reading [1]http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/API. Is the GHC API a means of reflection Haskell? Or to put more simply what is its intent? It can be used for reflection, since it exposes the interpreter at runtime. I think the original intent was a reusable code base of Haskell compiler/interpreter/type checker code, supporting all Haskell + GHC extensions, callable from Haskell, making language research, and new Haskell tools easier. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The reason why I want Tim Sweeney's email address ..
Hello, http://www.coverity.com/html/library.php *Ensuring Code Quality in Multi-threaded Applications* ** *This white paper touches on Haskell's STM but also issues that Sweeney brought up in his slides(parallel programming in huge multi-cores and why the current thread-based paradigm is woefully inadequate. I already sent to Simon Peyton-Jones and Simon Marlowe.* ** *Regards, Vasili* ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Not to load Prelude
Hi, Is it possible not to load Prelude module when compiling a Haskell module? Or instruct ghc to “unload” it? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not to load Prelude
On Jan 10, 2008, at 14:22 , Maurí cio wrote: Is it possible not to load Prelude module when compiling a Haskell module? Or instruct ghc to “unload” it? -fno-implicit-prelude -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not to load Prelude
Sorry for the double message, Mauricio. It's the first time I ever posted to haskell-cafe - figures I'd click on reply and not reply to all... On Jan 10, 2008 9:22 PM, Maurício [EMAIL PROTECTED] wrote: Hi, Is it possible not to load Prelude module when compiling a Haskell module? Or instruct ghc to unload it? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -XNoImplicitPrelude.does this in 6.8.x. In earlier versions (and apparently in 6.8 too), it's -fno-implicit-prelude. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not to load Prelude
Use: import Prelude () On Jan 10, 2008 11:22 AM, Maurício [EMAIL PROTECTED] wrote: Hi, Is it possible not to load Prelude module when compiling a Haskell module? Or instruct ghc to unload it? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Not to load Prelude
At Thu, 10 Jan 2008 17:22:02 -0200,
Maurício wrote:
Hi,
Is it possible not to load Prelude module
when compiling a Haskell module? Or instruct
ghc to “unload” it?
You can either do:
import Prelude()
or compile with the -fno-implicit-prelude flag, or add
{-# LANGUAGE NoImplicitPrelude #-}
to the top of the module.
NoImplicitPrelude is more aggressive than 'import Prelude()'. You will
have to look elsewhere for a better explanation of the difference.
j.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
David Roundy writes: It's unfortunate that there's no way to include strictness behavior in function types (at least that I'm aware of), so one has to rely on possibly-undocumented (and certainly never checked by a compiler) strictness behavior of many functions in order to write truly correct code. I wish there were a nice way around this issue (but can't really even imagine one). I wonder not how to get around, but WHY we can't help the strictness analyser in a way Clean permits, say: add :: !Integer - !Integer - Integer I thought it could be done without any serious revolution within the compiler, but perhaps I am too naïve (which in general is true...) Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tim Sweeney (the gamer)
Sebastian Sylvan [EMAIL PROTECTED] wrote: Concurrency does seem pretty disruptive. Yes, the thought of using par on a dual quad-core makes me salivate. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tim Sweeney (the gamer)
barsoap: Sebastian Sylvan [EMAIL PROTECTED] wrote: Concurrency does seem pretty disruptive. Yes, the thought of using par on a dual quad-core makes me salivate. Haskell is (in a very small part) driving sales of multicore boxes -- I've met half a dozen people who nominated Haskell's multicore support as a deciding reason to explicit get a multi-core box. Maybe we need to get some kickbacks from the hardware vendors, for helping their sales :) Intel, AMD, Nvidia -- are you guys listening?? In return, we can improve the parallelism support further. --Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
On Thu, 10 Jan 2008, David Roundy wrote: On Jan 9, 2008 5:42 PM, Henning Thielemann In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html Maybe this is also an option for Haskell? I don't think this is a good idea. It comes down to a question of whether you think it should be allowed for Haskell code to be used to write core Haskell libraries in a first-class manner. Perhaps you think libraries should always be in C in order to avoid the use of unsafePerformIO, but I prefer to allow them to be written in Haskell. The Modula-3 designers acknowledged that there are things that should not be done, but must be done, illustrated by the quotation: There are some cases that no law can be framed to cover. That is, marking a module as UNSAFE does not discourage their usage, but it swaps the burden of proof: For a safe module the compiler guarantees that nasty things can't happen, for an unsafe module the programmer must provide this warranty. If your program seg-faults you only have to scan the UNSAFE modules. For running untrusted Haskell code, this means, that if someone sends Haskell code to you (maybe as solution of an exercise) that is labelled 'safe' and uses no IO or a restricted IO wrapper type, then some especially nasty things can't happen - however the according Wiki page lists even more problems. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tim Sweeney (the gamer)
Don Stewart [EMAIL PROTECTED] wrote: In return, we can improve the parallelism support further. Now don't make me think of using par on a beowolf cluster of ps3's. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Thu, Jan 10, 2008 at 10:10:21AM -0800, Don Stewart wrote: rendel: [EMAIL PROTECTED] wrote: Although it could be argued that laziness is the cause of some very obscure bugs... g Niko Example, PLEASE. Prelude sum [1..100] *** Exception: stack overflow Prelude Data.List.foldl' (+) 0 [1..100] 5050 See, http://hackage.haskell.org/trac/ghc/ticket/1997 Strictness for for atomic numeric types is inconsitently applied across the base library. Fixing the inconsitencies would let fix a range of similar issues. Having followed this discussion, I agree with your analysis, but also think that rendel has chosen a good example of a pretty obscure bug caused by laziness in code written by folks who are actually decent Haskell programmers. It's unfortunate that there's no way to include strictness behavior in function types (at least that I'm aware of), so one has to rely on possibly-undocumented (and certainly never checked by a compiler) strictness behavior of many functions in order to write truly correct code. I wish there were a nice way around this issue (but can't really even imagine one). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] wrote: Achim Schneider: jerzy.karczmarczuk asks what's wrong with: [1..] == [1..] Whatever you may say more, this is neither obscure nor a bug. I still wait for a relevant example. But I don't insist too much... It's not an example of a bug, but of a cause. A cause of WHAT?? This is a perfect, nice, runaway computation, which ^^^ agrees with all dogmas of my religion. ^ The essence of laziness is to do the least work necessary to cause the desired effect, which is to see that the set of natural numbers equals the set of natural numbers, which, axiomatically, is always computable in O(1) by equality by identity. The essence of non-strictness, though, is another kind of story. Like a golem plowing half of the country until you remember that you placed him a bit absent-mindedly into your backyard and said plow, that still won't plow mountains. The essence of strictness is easy, though: get stuck on a stone, fall over and continue moving until you break. And people just think axiomatically and then translate their understanding more or less blindly into code, even if they can't name the axiom(s). Or, as I already mentioned: | , for assumed operational semantics of ones own axiomatic semantics. | Bugs are only a misunderstanding away. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
David Roundy [EMAIL PROTECTED] writes: I just want to point out that unsafePerformIO is at the core of the (safe) bytestring library. As SPJ et al pointed out, this is crucial functionality, and is only unsafe if unsafely used. In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html Maybe this is also an option for Haskell? I don't think this is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, and not when they just make use of potentially unsafe functionality. It is perfectly reasonable to write safe (pure) code that uses unsafe ones. You just have to trust the author to get it right. I'd be curious as to how much of the Prelude would be marked unsafe if you had your wish... All of it? In the end it is all passed to GCC (or generates assembly), which is inherently unsafe. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
On Jan 10, 2008 8:06 PM, Ketil Malde [EMAIL PROTECTED] wrote: David Roundy [EMAIL PROTECTED] writes: I just want to point out that unsafePerformIO is at the core of the (safe) bytestring library. As SPJ et al pointed out, this is crucial functionality, and is only unsafe if unsafely used. In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html Maybe this is also an option for Haskell? I don't think this is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, I think using the IO monad for this works well... -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
On Thu, Jan 10, 2008 at 08:10:57PM +, Sebastian Sylvan wrote: On Jan 10, 2008 8:06 PM, Ketil Malde [EMAIL PROTECTED] wrote: David Roundy [EMAIL PROTECTED] writes: I just want to point out that unsafePerformIO is at the core of the (safe) bytestring library. As SPJ et al pointed out, this is crucial functionality, and is only unsafe if unsafely used. In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html Maybe this is also an option for Haskell? I don't think this is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, I think using the IO monad for this works well... Would you suggest moving head and tail into the IO monad? -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
On Thu, Jan 10, 2008 at 11:17:18AM +0200, Yitzchak Gale wrote: The special case of 1/0 is less clear, though. One might decide that it should be an error rather than NaN, as some languages have. It is neither, 1/0 = Infinity -1/0 = -Infinity At least on IEEE style floating point systems. (this isn't mandated by the haskell standard though I believe) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: viewing HS files in Firefox
On Thu, Jan 10, 2008 at 10:07:25AM -0500, Stefan Monnier wrote:
My problem is when viewing plain darcs repositories (like mine on
darcs.johantibell.com which I recently fixed with the above mime type
hack.)
Please complain to your browser('s authors): most browsers only provide
*one* way to view a given mime-type, which is stupid. It's not specific
to .hs files.
This extension allows this in firefox. it gives you an 'open in browser as'
option that lets you view links in a variety of ways rather than being
forced to download it.
http://www.spasche.net/mozilla/
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 0/0 1 == False
John Meacham [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 11:17:18AM +0200, Yitzchak Gale wrote: The special case of 1/0 is less clear, though. One might decide that it should be an error rather than NaN, as some languages have. It is neither, 1/0 = Infinity -1/0 = -Infinity Just out of curiosity: 1/-0 = -Infinity? -1/-0 = Infinity? If you don't have two separate values for nothing, one approaching from negativeness and one from positiveness, defining the result to be infinite instead of NaN makes no sense IMHO. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
On Jan 10, 2008 8:12 PM, David Roundy [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 08:10:57PM +, Sebastian Sylvan wrote: On Jan 10, 2008 8:06 PM, Ketil Malde [EMAIL PROTECTED] wrote: David Roundy [EMAIL PROTECTED] writes: I just want to point out that unsafePerformIO is at the core of the (safe) bytestring library. As SPJ et al pointed out, this is crucial functionality, and is only unsafe if unsafely used. In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html Maybe this is also an option for Haskell? I don't think this is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, I think using the IO monad for this works well... Would you suggest moving head and tail into the IO monad? They're not really unsafe, though, they just have the potential to fail (from which you can recover). Unsafe to me mean may reformat your harddrive, kill your dog, and break up with your girlfriend. They really should return a Maybe type, but I recognize that this would be inconvenient (so would having e.g. integer division returning Maybe). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 0/0 1 == False
On Thu, Jan 10, 2008 at 09:24:34PM +0100, Achim Schneider wrote: John Meacham [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 11:17:18AM +0200, Yitzchak Gale wrote: The special case of 1/0 is less clear, though. One might decide that it should be an error rather than NaN, as some languages have. It is neither, 1/0 = Infinity -1/0 = -Infinity Just out of curiosity: 1/-0 = -Infinity? -1/-0 = Infinity? Yes. (You could have tried this for yourself, you know... but I suppose haskell-cafe isn't a bad interactive Haskell interpreter, perhaps more user friendly than ghci.) -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tim Sweeney (the gamer)
Sebastian Sylvan [EMAIL PROTECTED] writes: Maybe I'm just lucky, but if we are still talking about the games industry I don't think this fits my experience of bosses. Games compete very much on performance, and we basically rewrite almost all of our code over a few years or so anyway Another thing is that having the next big game means an incredible amount of money - more than a Hollywood blockbuster, according to popular rumor. Many companies may be willing to take a risk on promising but immature technology in the hope that it will give them the advantage they need to deliver the next Halo (or whatever). Very competitive industry, large money involved, lots of software rewritten or developed from scratch. Sounds ideal. Any boss who insists on doing things the way they've always done it won't last long. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Tim Sweeney (the gamer)
Ketil Malde [EMAIL PROTECTED] wrote: Sebastian Sylvan [EMAIL PROTECTED] writes: Maybe I'm just lucky, but if we are still talking about the games industry I don't think this fits my experience of bosses. Games compete very much on performance, and we basically rewrite almost all of our code over a few years or so anyway Another thing is that having the next big game means an incredible amount of money - more than a Hollywood blockbuster, according to popular rumor. Many companies may be willing to take a risk on promising but immature technology in the hope that it will give them the advantage they need to deliver the next Halo (or whatever). Very competitive industry, large money involved, lots of software rewritten or developed from scratch. Sounds ideal. Any boss who insists on doing things the way they've always done it won't last long. Just to set things straight: You can make more money selling mind trainers and party games like Nintendo does, or selling games with slideshow complexity but much visible flesh for handsets... at least here in Germany that's the much bigger portion of the industry. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 0/0 1 == False
David Roundy [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 09:24:34PM +0100, Achim Schneider wrote: John Meacham [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 11:17:18AM +0200, Yitzchak Gale wrote: The special case of 1/0 is less clear, though. One might decide that it should be an error rather than NaN, as some languages have. It is neither, 1/0 = Infinity -1/0 = -Infinity Just out of curiosity: 1/-0 = -Infinity? -1/-0 = Infinity? Yes. (You could have tried this for yourself, you know... but I suppose haskell-cafe isn't a bad interactive Haskell interpreter, perhaps more user friendly than ghci.) Prelude 1 `div` 0 *** Exception: divide by zero That's it. One just shouldn't just extrapolate and think you didn't mean GHC but IEEE... -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 0/0 1 == False
On Thu, Jan 10, 2008 at 09:41:53PM +0100, Achim Schneider wrote: David Roundy [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 09:24:34PM +0100, Achim Schneider wrote: John Meacham [EMAIL PROTECTED] wrote: 1/0 = Infinity -1/0 = -Infinity Just out of curiosity: 1/-0 = -Infinity? -1/-0 = Infinity? Yes. (You could have tried this for yourself, you know... but I suppose haskell-cafe isn't a bad interactive Haskell interpreter, perhaps more user friendly than ghci.) Prelude 1 `div` 0 *** Exception: divide by zero That's it. One just shouldn't just extrapolate and think you didn't mean GHC but IEEE... Prelude 1/(-0) -Infinity You need to use the / operator, if you want to do floating-point division. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: 0/0 1 == False
David Roundy [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 09:41:53PM +0100, Achim Schneider wrote: David Roundy [EMAIL PROTECTED] wrote: On Thu, Jan 10, 2008 at 09:24:34PM +0100, Achim Schneider wrote: John Meacham [EMAIL PROTECTED] wrote: 1/0 = Infinity -1/0 = -Infinity Just out of curiosity: 1/-0 = -Infinity? -1/-0 = Infinity? Yes. (You could have tried this for yourself, you know... but I suppose haskell-cafe isn't a bad interactive Haskell interpreter, perhaps more user friendly than ghci.) Prelude 1 `div` 0 *** Exception: divide by zero That's it. One just shouldn't just extrapolate and think you didn't mean GHC but IEEE... Prelude 1/(-0) -Infinity You need to use the / operator, if you want to do floating-point division. Yes, exactly, integers don't have +-0 and +-infinity... only (obviously) a kind of nan. It's just that with the stuff I do I know I have some logical problem in my formulas when I get any special floating point value anywhere, and using --excess-precision can only make the numbers more precise. Said differently: I don't know a thing about floats or numerics. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Difference lists and ShowS
On Wed, 9 Jan 2008, apfelmus wrote: So, difference lists are no eierlegende wollmilchsau either. LEO's forum suggests 'swiss army knife' as translation. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Difference lists and ShowS
Henning Thielemann [EMAIL PROTECTED] wrote: On Wed, 9 Jan 2008, apfelmus wrote: So, difference lists are no eierlegende wollmilchsau either. LEO's forum suggests 'swiss army knife' as translation. :-) But you really need one with 5 differently-sized blades plus three spezialized carving blades, an USB stick, microscope, 13 kinds of torx, imbus etc drivers each, a tv set (analogue/digital) with unfoldable touchscreen, at least 3-band GSM and WiFi connectivity, hydraulic car jack and chain saw to award it with the term egg-laying woolmilkpig. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Difference lists and ShowS
Achim Schneider wrote: Henning Thielemann wrote: apfelmus wrote: So, difference lists are no eierlegende wollmilchsau either. LEO's forum suggests 'swiss army knife' as translation. :-) But you really need one with 5 differently-sized blades plus three spezialized carving blades, an USB stick, microscope, 13 kinds of torx, imbus etc drivers each, a tv set (analogue/digital) with unfoldable touchscreen, at least 3-band GSM and WiFi connectivity, hydraulic car jack and chain saw to award it with the term egg-laying woolmilkpig. But even such knives still can't lay eggs :( Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
