I wrote:
Here is one way to do it. First, you have to interpret operations on
matrices as being elementwise applied. E.g, (*) is interpreted as zipWith
(zipWith (*)) rather than matrix multiply, and similar for (+) etc. You then
obtain a lazy semantics for the operations, where the extent of the
Hello Ralf,
Thursday, June 22, 2006, 12:02:43 AM, you wrote:
limited to function types. Users of parser combinators heavily rely
on this feature. Just try to define/use parsing combinators
ins a strict language.
C++ Boost contains one parsing combinators library. part of it is, of
course, a
| Everything else about Haskell is so great and well thought out (eg
type
| classes, no side effects, higher rank polymorphism, existentials) it
seems a
| pity to throw all this away just because of one unfortunate feature
I thought it might be worth mentioning that GHC (well, the HEAD, which
Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
you may transform a recurrential equation yielding Y out of X:
Y[n+1] = a*X[n+1] + b*Y[n]
usually (imperatively) implemented as a loop, into a stream
definition:
...
Can you explain how this transformation was accomplished?
I don't see how
yq
On Thu, Jun 22, 2006 at 09:22:34AM +0100, Simon Peyton-Jones wrote:
To: Brian Hulley [EMAIL PROTECTED], Joel Reymont [EMAIL PROTECTED]
Cc: haskell-cafe@haskell.org
From: Simon Peyton-Jones [EMAIL PROTECTED]
Date: Thu, 22 Jun 2006 09:22:34 +0100
Subject: RE: [Haskell-cafe] Re: Functional
hi !
2006/6/22, Brian Hulley [EMAIL PROTECTED]:
[snip]
So:
1) Someone reading the code needs to do a lot of work to try to recover the
original equation
2) Wouldn't an imperative loop, using the original equation directly, have
made everything much simpler?
3) Therefore laziness has lead to
hi,
2006/6/22, Simon Peyton-Jones [EMAIL PROTECTED]:
[real big snip :)]
I think you're one of the best person to advocate pros and cons of
laziness/strictness.
So i'm a bit surprised to see this :
It's an experimental feature, and I'm interested to know how useful, or
otherwise, it turns out
Hi All,
I am confused by the notion of principal type in Haskell with type classes.
Consider a simple example:
f x y = [x] == [y]
GHCi yields type f :: (Eq [a]) = a - a - Bool.
But according to the paper Type classes: an exploration of the design
space, predicate Eq [a] should be reduced
According to Haskell 98 the principal type of f should be:
f :: (Eq a) = a - a - Bool.
GHC does only perform context-reduction using instance-declarations if
there are no type-variables in the type. Because the type in this
function is [a], ghc doesn't perform context-reduction. Ghc chooses
Bjorn Lisper wrote:
Here is one way to do it. First, you have to interpret operations on
matrices as being elementwise applied. E.g, (*) is interpreted as zipWith
(zipWith (*)) rather than matrix multiply
What's this, the principle of greatest surprise at work? Nonono, (*)
should be matrix
william kim wrote:
I am confused by the notion of principal type in Haskell with type
classes. Consider a simple example:
f x y = [x] == [y]
GHCi yields type f :: (Eq [a]) = a - a - Bool.
But according to the paper Type classes: an exploration of the design
space, predicate Eq [a] should
[EMAIL PROTECTED] wrote:
apparently - Clean has better handling of strictness
issues [saying at the same time that he/she doesn't use Clean...]
Uhm... well... and does it? From what I've heard, Clean has the same
mechanism as Haskell, which is the 'seq' primitive. Clean just adds
some
A genuine bug, thank you. I've just fixed it. We'll put the fix in
6.4.3.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of C
| Rodrigues
| Sent: 21 June 2006 21:55
| To: haskell-cafe@haskell.org
| Subject: [Haskell-cafe] Template haskell and
I am trying to define the following types
data MyStringType a = String deriving (Eq, Ord, Show)
data QADouble a = Double deriving (Eq, Ord, Show)
data HType a = QADouble a| DDTraceType a deriving (Eq, Ord, Show)
So HType can represent strings or doubles.
later I want to do something like the
On Thu, Jun 22, 2006 at 11:57:37AM +0200, Udo Stenzel wrote:
instance Num a = Num [[a]] where
(+) = zipWith (zipWith (+))
(-) = zipWith (zipWith (-))
negate = map (map negate)
fromInteger x = fix (((x : repeat 0) :) . map (0:))
m * n = [ [ sum $ zipWith (*) v w
2006/6/22, Vladimir Portnykh [EMAIL PROTECTED]:
I am trying to define the following types
data MyStringType a = String deriving (Eq, Ord, Show)
data QADouble a = Double deriving (Eq, Ord, Show)
data HType a = QADouble a| DDTraceType a deriving (Eq, Ord, Show)
So HType can represent strings or
minh thu wrote:
/about the stream algorithms, lazy style/
can you know a mean to express such computation but with elements
depending of time (in about the same way as languages as esterel)
(i.e. depending of IO)?
Paul Hudak uses a Channel in his book Haskell SOE .. but is there
another way ?
Hello william,
Thursday, June 22, 2006, 1:22:32 PM, you wrote:
GHCi yields type f :: (Eq [a]) = a - a - Bool.
But according to the paper Type classes: an exploration of the design
space, predicate Eq [a] should be reduced to Eq a. Is this reduction
performed here? What should be the
--- Matthias Fischmann [EMAIL PROTECTED] wrote:
On Thu, Jun 22,
2006 at 09:22:34AM +0100, Simon Peyton-Jones wrote:
To: Brian Hulley
[EMAIL PROTECTED], Joel Reymont [EMAIL PROTECTED]
Cc: haskell-cafe@haskell.org
From: Simon Peyton-Jones [EMAIL PROTECTED]
Date: Thu, 22 Jun
2006 09:22:34
Has anyone else encountered this? Its ok for us, and for at least
some other people. Perhaps uninstall and reinstall? You cant overlook anything
when installing, assuming you use the pre-packaged installer.
Simon
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jeff
Vladimir Portnykh wrote:
I am trying to define the following types
data MyStringType a = String deriving (Eq, Ord, Show)
data QADouble a = Double deriving (Eq, Ord, Show)
These are not what you think they are. MyStringType has a phantom type
parameter and only one value, which is the
On Thu, Jun 22, 2006 at 01:24:32PM +0200, Jerzy Karczmarczuk wrote:
I believe that ways of producing intricate streams by such languages or
Lustre are somehow based on continuation mechanisms. The paper on Esterel,
etc. : ftp://ftp-sop.inria.fr/esterel/pub/papers/foundations.pdf
gives you
Udo Stenzel:
Bjorn Lisper wrote:
Here is one way to do it. First, you have to interpret operations on
matrices as being elementwise applied. E.g, (*) is interpreted as zipWith
(zipWith (*)) rather than matrix multiply
What's this, the principle of greatest surprise at work? Nonono, (*)
should
Jerzy Karczmarczuk wrote:
Brian Hulley wrote:
[EMAIL PROTECTED] wrote:
you may transform a recurrential equation yielding Y out of X:
Y[n+1] = a*X[n+1] + b*Y[n]
usually (imperatively) implemented as a loop, into a stream
definition:
...
Can you explain how this transformation was
2006/6/22, Brian Hulley [EMAIL PROTECTED]:
Jerzy Karczmarczuk wrote:
Brian Hulley wrote:
[snip]
y IS NOT a longer list than yq, since co-recursive equations without
limiting cases, apply only to *infinite* streams. Obviously, the
consumer of such a stream will generate a finite segment
minh thu wrote:
2006/6/22, Brian Hulley [EMAIL PROTECTED]:
Jerzy Karczmarczuk wrote:
Brian Hulley wrote:
[snip]
y IS NOT a longer list than yq, since co-recursive equations without
limiting cases, apply only to *infinite* streams. Obviously, the
consumer of such a stream will generate a
On 2006-06-22 at 15:16BST Brian Hulley wrote:
minh thu wrote:
y and yq are infinite...
But how does this change the fact that y still has 1 more element than yq?
yq is after all, not a circular list.
infinity+1 = infinity
I don't see why induction can't just be applied infinitely
to
On Thu, 2006-06-22 at 15:16 +0100, Brian Hulley wrote:
. . .
But how does this change the fact that y still has 1 more element than yq?
yq is after all, not a circular list.
I don't see why induction can't just be applied infinitely to prove this.
The set of all non-negative integers has
2006/6/22, Brian Hulley [EMAIL PROTECTED]:
minh thu wrote:
2006/6/22, Brian Hulley [EMAIL PROTECTED]:
Jerzy Karczmarczuk wrote:
Brian Hulley wrote:
[snip]
y IS NOT a longer list than yq, since co-recursive equations without
limiting cases, apply only to *infinite* streams. Obviously, the
Bjorn Lisper wrote:
- your definition of fromInteger will behave strangely with the elementwise
extended operations, like (+). 1 + [[1,2],[3,4]] will become
[[2,2],[3,5]] rather than [[2,3],[4,5]]. Array languages supporting this
kind of overloading invariably have the second form of
Jon Fairbairn wrote:
On 2006-06-22 at 15:16BST Brian Hulley wrote:
minh thu wrote:
y and yq are infinite...
But how does this change the fact that y still has 1 more element
than yq? yq is after all, not a circular list.
infinity+1 = infinity
Surely this is just a mathematical
On 2006-06-22 at 15:45BST Brian Hulley wrote:
Jon Fairbairn wrote:
infinity+1 = infinity
Surely this is just a mathematical convention, not reality! :-)
I'm not sure how to answer that. The only equality worth
talking about on numbers (and lists) is the mathematical
one, and it's a
On Jun 22, 2006, at 10:16 AM, Brian Hulley wrote:
minh thu wrote:
2006/6/22, Brian Hulley [EMAIL PROTECTED]:
Jerzy Karczmarczuk wrote:
Brian Hulley wrote:
[snip]
y IS NOT a longer list than yq, since co-recursive equations
without
limiting cases, apply only to *infinite* streams.
Ralf Hinze wrote:
Also, in a non-strict language recursive definitions are not
limited to function types. Users of parser combinators heavily rely
on this feature. Just try to define/use parsing combinators
ins a strict language.
Anyone care to comment on what goes wrong with parser
On Thu, Jun 22, 2006 at 11:06:38AM -0400, Robert Dockins wrote:
aside
Every few months a discussion arises about induction and Haskell
datatypes, and I feel compelled to trot out this oft-misunderstood
fact about Haskell: 'data' declarations in Haskell introduce co-
inductive
Thanks. Do I therefore able to conclude that none of the reductions using
instance declarations are not performed because of potential overlapping
instances?
william
From: Bulat Ziganshin [EMAIL PROTECTED]
Reply-To: Bulat Ziganshin [EMAIL PROTECTED]
To: william kim [EMAIL PROTECTED]
CC:
On 6/22/06, Greg Buchholz [EMAIL PROTECTED] wrote:
Ralf Hinze wrote:
Also, in a non-strict language recursive definitions are not
limited to function types. Users of parser combinators heavily rely
on this feature. Just try to define/use parsing combinators
ins a strict language.
Anyone
Hello all,
Now I am trying with the function of polymorphic type: This function
returns the Nth element of list with type a. I try it as below.
getNthElem :: Int - [a] - Maybe a
getNthElemt _ []= Nothing
getNthElem 0 _ = Nothing
getNthElem n s
| n length s =
Therefore the list of non-negative integers is longer than the list of
positive integers. I agree they have the same cardinality but this doesn't
mean they have the same length.
Are you saying that some of the (0,1,2,3,4,5,...), (1,2,3,4,5,...) and
(1-1,2-1,3-1,4-1,5-1,...) lists have
On 6/22/06, Sara Kenedy [EMAIL PROTECTED] wrote:
Hello all,
Now I am trying with the function of polymorphic type: This function
returns the Nth element of list with type a. I try it as below.
getNthElem :: Int - [a] - Maybe a
getNthElemt _ []= Nothing
getNthElem 0 _ = Nothing
2006/6/22, Sara Kenedy [EMAIL PROTECTED]:
Hello all,
Now I am trying with the function of polymorphic type: This function
returns the Nth element of list with type a. I try it as below.
getNthElem :: Int - [a] - Maybe a
getNthElemt _ []= Nothing
getNthElem 0 _ = Nothing
getNthElem n s
minh thu wrote:
maybe i wrong, anyway :
induction can be used to prove a property.
we claim that the property is true for any finite i.
so what's the property that you want to prove by induction ?
you say 'by induction on the lenght of yq'.. but yq is just y (modulo
the a*xq + b*).
it's exactly
Stepan Golosunov wrote:
On Thu, Jun 22, 2006 at 03:32:25PM +0100, Brian Hulley wrote:
Bill Wood wrote:
On Thu, 2006-06-22 at 15:16 +0100, Brian Hulley wrote:
. . .
But how does this change the fact that y still has 1 more element
than yq? yq is after all, not a circular list.
I don't see why
Sara Kenedy wrote:
Hello all,
Now I am trying with the function of polymorphic type: This function
returns the Nth element of list with type a. I try it as below.
getNthElem :: Int - [a] - Maybe a
getNthElemt _ [] = Nothing
getNthElem 0 _ = Nothing
getNthElem n s
n length s = Nothing
On Thu, 2006-06-22 at 20:13 +0100, Brian Hulley wrote:
. . .
filter function), I can reason about my programs without entering the areas
of maths that I don't believe in, which is one more reason for my desire to
have a totally strict version of Haskell ;-)
This may also explain why
On 22/06/06, Brian Hulley [EMAIL PROTECTED] wrote:
...
This doesn't mean that these contradictions reflect reality - just that
maths hasn't yet reached a true understanding of reality imho.
Well, I for instance believe that contradiction IS the true nature of
reality... ;)
For example, why
Piotr Kalinowski wrote:
On 22/06/06, Brian Hulley [EMAIL PROTECTED] wrote:
...
This doesn't mean that these contradictions reflect reality - just
that maths hasn't yet reached a true understanding of reality imho.
Well, I for instance believe that contradiction IS the true nature of
On 23/06/06, Brian Hulley [EMAIL PROTECTED] wrote:
This equation is just a shortcut, so I can't see how can it be
ill-typed. It means something like: if you add one element to an
infinite list, will it be longer?
What does your intuition say about this?
It won't be longer. How can it be?
Brian Hulley wrote:
Couldn't an infinite list just be regarded as the maximum element of the
(infinite) set of all finite lists?
Brian, I will say something you might find acrimonious and impolite, but
it is serious, you might find this in some philosophical works.
If you are right, then
I was curious if there was any code floating around out there for
dealing with neural networks in haskell?
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Thanks all. I think for my function, I only need to throw an error
message for the out of range index. But through this, I know more some
ways to deal with the polymorphic type.
On 6/22/06, Brian Hulley [EMAIL PROTECTED] wrote:
Sara Kenedy wrote:
Hello all,
Now I am trying with the function
Actually Brian's intuition is right on target. One way to define an
infinite list is as the limit of an infinite chain of partial lists
(which, in domain theory, is essentially how all elements are defined).
A chain is a sequence a1 = a2 = ... = an, where = is the domain
ordering. A partial
G'day all.
Quoting [EMAIL PROTECTED]:
Recently Vo Minh Thu wondered if Haskell (or, I generalize, functional
programming) can be of much use for computer graphics programming.
As others have pointed out, it's Haskell (and its laziness) that he
perceived to be the problem.
However, I'd like
Hello william,
Thursday, June 22, 2006, 9:12:44 PM, you wrote:
sorry, i don't even understood your question
Thanks. Do I therefore able to conclude that none of the reductions using
instance declarations are not performed because of potential overlapping
instances?
Ghc, unlike H98, supports
54 matches
Mail list logo
