Small correction - the extensions listed at the bottom weren't
necessary. I had attempted to define a relationship among tables
automatically as:
instance (HasField fk child, HasField pk parent, HasRelation pk fk)
=> HasRelation parent child
But that was redundant with the signature on relation
Jonathan Cast <[EMAIL PROTECTED]> wrote:
> [...]
Right click -> Color Label -> Red.
--
(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
si
On Dec 31, 2007, at 11:21 AM, Achim Schneider wrote:
Jake McArthur <[EMAIL PROTECTED]> wrote:
I disagree. It might be the case that the _contents_ of the data
structure are lazy, in which case I would say the relevant
constructor parameters should be made strict. As long as the
structural part
On 31 Dec 2007, at 1:33 PM, Achim Schneider wrote:
Jonathan Cast <[EMAIL PROTECTED]> wrote:
On 31 Dec 2007, at 10:43 AM, Achim Schneider wrote:
Achim Schneider <[EMAIL PROTECTED]> wrote:
That's not specified though, the runtime could choose to let +
force the two chunks the different way
Jonathan Cast <[EMAIL PROTECTED]> wrote:
>
> On 31 Dec 2007, at 10:43 AM, Achim Schneider wrote:
>
> > Achim Schneider <[EMAIL PROTECTED]> wrote:
> >
> >> That's not specified though, the runtime could choose to let +
> >> force the two chunks the different way round.
> >>
> > And that is probab
On 31 Dec 2007, at 10:43 AM, Achim Schneider wrote:
Achim Schneider <[EMAIL PROTECTED]> wrote:
That's not specified though, the runtime could choose to let + force
the two chunks the different way round.
And that is probably also the reason why [1..] == [1..] is _|_.
Is "Something that can
Joost Behrends wrote:
We read
data Pair a b = Pair a b
in YetAnotherHaskellTutorial. And that is all ! If we omit "data" here, this
would be a silly pleonasm. And no single word about this strange behavior of
"data" in every tutorial i read.
When learning a language, I find it useful to co
On Dec 31, 2007, at 12:50 , L.Guo wrote:
And what is the difference between fromIntegral and fromInteger ?
Integer is a specific single type: unlimited-precision integers.
Integral is a typeclass which includes, among others: Integer, Int
(integers represented in machine words, so either
In addition to the other replies, take a look at this wiki page for
more conversion advice:
http://www.haskell.org/haskellwiki/Converting_numbers
Kurt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskel
Ah, thanks, it is my fault, for mis-understanding the hint from GHC.
And what is the difference between fromIntegral and fromInteger ?
--
L.Guo
2008-01-01
-
From: Mark T.B. Carroll
At: 2008
2007/12/31, L.Guo <[EMAIL PROTECTED]>:
> Hi MailList Haskell-Cafe:
>
> I am a new haskeller. And was farmilar with C.
>
> When tring to do some calculate, like this:
>
> input = 5 :: Int
> factor = 1.20 :: Float
> output = factor ** (toFloat input)
>
> I found that I do not know any function could
"L.Guo" <[EMAIL PROTECTED]> wrote:
> What should I do then ?
>
Use fromIntegral.
In general, conversion functions are conventionally named fromXXX, and
not toXXX, to emphasise functionality somewhat when using them.
--
(c) this sig last receiving data processing entity. Inspect headers for
pas
Hi MailList Haskell-Cafe:
I am a new haskeller. And was farmilar with C.
When tring to do some calculate, like this:
input = 5 :: Int
factor = 1.20 :: Float
output = factor ** (toFloat input)
I found that I do not know any function could do just what 'toFloat'
should do.
What should I do then
Jake McArthur <[EMAIL PROTECTED]> wrote:
> I disagree. It might be the case that the _contents_ of the data
> structure are lazy, in which case I would say the relevant
> constructor parameters should be made strict. As long as the
> structural parts are still lazy it should be okay.
>
> And th
Am Montag, 31. Dezember 2007 17:43 schrieb Achim Schneider:
> Achim Schneider <[EMAIL PROTECTED]> wrote:
> > That's not specified though, the runtime could choose to let + force
> > the two chunks the different way round.
>
> And that is probably also the reason why [1..] == [1..] is _|_.
>
> Is "S
On Dec 31, 2007, at 9:53 AM, Paul Johnson wrote:
I'd advise against trying to make your program stricter because you
might suddenly find yourself building an entire 6GB structure in
memory before traversing it, which would not be a Good Thing.
I disagree. It might be the case that the _cont
Achim Schneider <[EMAIL PROTECTED]> wrote:
> That's not specified though, the runtime could choose to let + force
> the two chunks the different way round.
>
And that is probably also the reason why [1..] == [1..] is _|_.
Is "Something that can be, in any evaluation strategy, be bottom, is
botto
On Dec 31, 2007, at 6:50 AM, Cristian Baboi wrote:
On Mon, 31 Dec 2007 14:36:02 +0200, Joost Behrends <[EMAIL PROTECTED]
> wrote:
I forgot 2 things:
The distinction between '=' and '==' is much like in C, although
mixing
them up is not so dangerous like in C. ':=' and '=' like in Wirth
l
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
> What is more strange is that a = a + 1 and a = 1 + a are somehow
> distinct. The second give a stack overflow almost instanly, but the
> first don't.
>
That's because what the runtime does looks in the second case like
a = 1 + 1 + 1 + 1 + 1 + ... + a
Hello Cristian,
Sunday, December 30, 2007, 8:16:33 PM, you wrote:
> Can you write the value of x to a file where x = (1:x) ?
yes, there are libraries that can do it
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Has
Ben Challenor wrote:
Hi
I'm learning Haskell through writing a compiler. I'm seeing huge
memory use in a function which converts the dataflow graph to the form
required by Data.Graph. [...]
I assume the allocation is being garbage-collected pretty quickly,
because a) 6,616,297,296 bytes is s
Hi,
> So how, prey tell, do you factor out an expression which includes
> ...? It is not Haskell,
> Haskell has no power there. Surely
> learning that mapping is easier than building your own (which will
> doubtlessly be worse (no
> offense, that's the first law of library use)).
>
> And since
Hi
I'm learning Haskell through writing a compiler. I'm seeing huge memory
use in a function which converts the dataflow graph to the form required
by Data.Graph. It needs to return a map from dataflow nodes to Vertexs,
a map in the other direction, and the list of edges (as Vertex pairs).
Twan van Laarhoven wrote:
Isaac Dupree wrote:
Unfortunately, I get puzzling type errors if I annotate either one of
them with their type (e.g.
(Applicative f) => f (a -> b) -> f a -> f (Int, b)
) in an expression. The very answer doesn't seem to typecheck.
> :t \f x -> fmap ((,) (0::Int)) (f
Isaac Dupree wrote:
Unfortunately, I get puzzling type errors if I annotate either one of
them with their type (e.g.
(Applicative f) => f (a -> b) -> f a -> f (Int, b)
) in an expression. The very answer doesn't seem to typecheck.
> :t \f x -> fmap ((,) (0::Int)) (f <*> x) :: (Applicative f)
On Dec 30, 2007 6:24 PM, Joost Behrends <[EMAIL PROTECTED]> wrote:
> I've already browsed through the docomentation of all that. Sorry, but i will
> not use WASH. I like things to be direct, to write >> p { ... } or similar
> things instead of ... is worsening things for me.
Haskell is not a goo
On Mon, 31 Dec 2007 14:36:02 +0200, Joost Behrends <[EMAIL PROTECTED]>
wrote:
I forgot 2 things:
The distinction between '=' and '==' is much like in C, although mixing
them up is not so dangerous like in C. ':=' and '=' like in Wirth
languages would be nicer.
Strangely nobody reacted on
I forgot 2 things:
>
> The distinction between '=' and '==' is much like in C, although mixing
> them up is not so dangerous like in C. ':=' and '=' like in Wirth
> languages would be nicer.
>
Strangely nobody reacted on this. That a=a+1 is an infinite recursion here
(but _|_ obviously not compl
Twan van Laarhoven wrote:
Robin Green wrote:
I am proving various statements relating to applicative functors, using
the Coq proof assistant (I am considering only Coq terms, which always
terminate so you don't have to worry about _|_). However, I'm not sure
how to go about proving a certain co
Nice! Thank you.
On Mon, 31 Dec 2007 12:56:42 +0200, Ryan Ingram <[EMAIL PROTECTED]>
wrote:
On 12/30/07, Cristian Baboi <[EMAIL PROTECTED]> wrote:
Thank you.
data Something = This | S Something
ppp :: Something -> String
ppp This = ""
ppp (S x) = 'S':(ppp x)
How can I prevent one to p
On 12/30/07, Cristian Baboi <[EMAIL PROTECTED]> wrote:
>
> Thank you.
>
> data Something = This | S Something
>
> ppp :: Something -> String
>
> ppp This = ""
> ppp (S x) = 'S':(ppp x)
>
>
> How can I prevent one to pass 'let x = S x in x' to ppp ?
{-# LANGUAGE GADTs, EmptyDataDecls #-}
data Z
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
> Well, it depends on what you think is nicer.
> For me it looks shorter than undefined and it don't rely on the
> library.
>
Well, for me undefined doesn't throw undeterministic behaviour at me
(throwing a stack overflow sooner or later or not, dependi
On Mon, 31 Dec 2007 11:14:39 +0200, Achim Schneider <[EMAIL PROTECTED]> wrote:
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
On Mon, 31 Dec 2007 10:59:28 +0200, Achim Schneider <[EMAIL PROTECTED]>
wrote:
I could have written this instead:
a :: Something
a = a
Which is nicer than undefined.
On Mon, 31 Dec 2007 11:14:39 +0200, Achim Schneider <[EMAIL PROTECTED]> wrote:
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
I could have written this instead:
a :: Something
a = a
Which is nicer than undefined.
[EMAIL PROTECTED] ~ % ghci
GHCi, version 6.8.2: http://www.haskell.org/ghc/ :
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
> On Mon, 31 Dec 2007 10:59:28 +0200, Achim Schneider <[EMAIL PROTECTED]>
> wrote:
>
> > Achim Schneider <[EMAIL PROTECTED]> wrote:
> >
> >> "Cristian Baboi" <[EMAIL PROTECTED]> wrote:
> >>
> >> > What is infinite in let x = x in x ?
> >>
On Mon, 31 Dec 2007 10:59:28 +0200, Achim Schneider <[EMAIL PROTECTED]> wrote:
Achim Schneider <[EMAIL PROTECTED]> wrote:
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
> What is infinite in let x = x in x ?
^ ||
|___/|
Achim Schneider <[EMAIL PROTECTED]> wrote:
> "Cristian Baboi" <[EMAIL PROTECTED]> wrote:
>
> > What is infinite in let x = x in x ?
> ^ ||
> |___/|
> \/
>
a = let x = x in x
is actually only quite ver
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
> What is infinite in let x = x in x ?
^ ||
|___/|
\/
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information.
On Mon, 31 Dec 2007 10:40:13 +0200, Achim Schneider <[EMAIL PROTECTED]> wrote:
It seems like you're trying to solve the halting problem.
I didn't know that.
Slurping any
infinite data structure makes your program perform rather badly, I'm
afraid.
What is infinite in let x = x in x ?
What
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
> It give Something.
>
You're right, I'm thinking too lispy. The point is that it doesn't have
to be passed an x to be infinite, and that a by itself is fully
polymorphic.
It seems like you're trying to solve the halting problem. Slurping any
infinite
It give Something.
On Mon, 31 Dec 2007 10:27:38 +0200, Achim Schneider <[EMAIL PROTECTED]> wrote:
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
How about
a :: Something
a = let x = x in x
:t a
would give (a -> [a]), not Something, or am I mistaken?
Information from NOD32 _
"Cristian Baboi" <[EMAIL PROTECTED]> wrote:
> How about
>
> a :: Something
> a = let x = x in x
>
:t a
would give (a -> [a]), not Something, or am I mistaken?
--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorise
42 matches
Mail list logo
