| 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
will
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: Funct
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 ob
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 reduc
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] shou
[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 syntac
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 sc
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 fol
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 (*
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 t
--- 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
Has anyone else encountered this? It’s ok for us, and for at least
some other people. Perhaps uninstall and reinstall? You can’t overlook anything
when installing, assuming you use the pre-packaged installer.
Simon
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
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 con
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
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, (*
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 accomplish
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 segmen
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 fin
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
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.
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 induction can't just be applied infinitely to prove
this.
The set of all non-negative
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 conventio
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 ma
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. Obvio
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 co
On Thu, Jun 22, 2006 at 11:06:38AM -0400, Robert Dockins wrote:
>
> 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 definitions,
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 inductio
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]>
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.
A
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 diffe
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
getN
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
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 exactl
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
other
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 th
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
reality.
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 b
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
http://www.haskell.org/mailman/listinfo/
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 func
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 part
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, supp
54 matches
Mail list logo