Roberto Zunino wrote:
Ah, silly me! I checked that inequality was preserved, but forgot that
(==) diverges on infinite list!
Indeed, strictly speaking, Eq [] does not satisfy the Eq invariant x==x.
All haskell types contain divergence. So all Eq types have exactly this
same problem.
We 'li
I really liked this explanation -- very clear, with good analogies.
Thanks!
Martin
My music: http://www.youtube.com/profile?user=thetonegrove
Claus Reinke wrote:
quantified types (forall/exist):
an easy way to memorize this is to think of 'forall' as a big 'and'
and of 'exists' as a big '
Tomasz Zielonka wrote:
On Wed, May 30, 2007 at 11:21:45PM +0200, Roberto Zunino wrote:
($!) Data.List.repeat -- ;-) unbounded types
You got me - I'm not sure how to respond to that. Let's try: this
function doesn't preserve computable equality.
Ah, silly me! I checked that inequality was
On Wed, May 30, 2007 at 05:12:48PM +0200, Henk-Jan van Tuyl wrote:
> On Wed, 30 May 2007 09:38:10 +0200, Tomasz Zielonka
> <[EMAIL PROTECTED]> wrote:
> >On Tue, May 29, 2007 at 09:43:03PM +0100, Andrew Coppin wrote:
> >>Henning Thielemann wrote:
> >>>On Sun, 27 May 2007, Andrew Coppin wrote:
> >>
On Wed, May 30, 2007 at 11:21:45PM +0200, Roberto Zunino wrote:
> Tomasz Zielonka wrote:
> > In the Ord variant, the result value pretty much has to come from the
> > input list or be bottom. It has to be bottom for the empty list. If
> > f :: Ord a => [a] -> a and g preserves order (is monotonic)
Tomasz Zielonka wrote:
> In the Ord variant, the result value pretty much has to come from the
> input list or be bottom. It has to be bottom for the empty list. If
> f :: Ord a => [a] -> a and g preserves order (is monotonic) then
> f (map g l) == g (f l)
> This could be nice for testing Ord i
On Wed, 30 May 2007 09:38:10 +0200, Tomasz Zielonka
<[EMAIL PROTECTED]> wrote:
On Tue, May 29, 2007 at 09:43:03PM +0100, Andrew Coppin wrote:
Henning Thielemann wrote:
>On Sun, 27 May 2007, Andrew Coppin wrote:
>>But every now and then I discover an expression which is apparently
not
>>exp
On 5/29/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
Claus Reinke wrote:
<>
> phantom types:
> the types of ghost values (in other words, we are only interested in
> the type, not in any value of that type).
Mmm... Still not seeing a great amount of use for this one.
quantified types (forall/exist):
an easy way to memorize this is to think of 'forall' as a big 'and'
and of 'exists' as a big 'or'.
e :: forall a. a -- e has type 'Int' and type 'Bool' and type ..
e :: exists a. a -- e has type 'Int' or type 'Bool' or type ..
That doesn't entirely
On Wed, May 30, 2007 at 02:35:38PM +0200, Henning Thielemann wrote:
>
> On Tue, 29 May 2007, Andrew Coppin wrote:
>
> > OTOH, how many function can you write with :: [Int] -> Int? I can think
> > of a few...
>
> You will probably more like to implement functions like
> Ord a => [a] -> a
> Nu
On Tue, 29 May 2007, Andrew Coppin wrote:
> OTOH, how many function can you write with :: [Int] -> Int? I can think
> of a few...
You will probably more like to implement functions like
Ord a => [a] -> a
Num a => [a] -> a
and those generalized signatures tell you more. :-)
_
Andrew Coppin wrote:
My point is for most programs, trying to figure out exactly what you
want the program to do is going to be much harder than implementing a
program that does it.
Also, for most programs the spec is far more complicated (and hence
prone to error) than the actual program, so
On 28/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
Then again, later on in the very same book there's a chapter entitled
"Fun with Phantom Types", which made precisely no sense at all...
(I find this a lot with Haskell. There is stuff that is clearly written,
fairly easily comprehensible, and
On Tue, May 29, 2007 at 09:43:03PM +0100, Andrew Coppin wrote:
> Henning Thielemann wrote:
> >On Sun, 27 May 2007, Andrew Coppin wrote:
> >>But every now and then I discover an expression which is apparently not
> >>expressible without them - which is odd, considering they're only
> >>"sugar"...
>
On Tue, 2007-05-29 at 21:39 +0100, Andrew Coppin wrote:
> My point is for most programs, trying to figure out exactly what you
> want the program to do is going to be much harder than implementing a
> program that does it.
And the solution is..to not say anything about what the program should
d
On Tue, 2007-05-29 at 21:28 +0100, Andrew Coppin wrote:
> > phantom types:
> > the types of ghost values (in other words, we are only interested in
> > the type, not in any value of that type).
> Mmm... Still not seeing a great amount of use for this one.
The point is to 'tag' something with a
True in principle. But if writing the spec is harder than writing
the actual program, all it means is you spend longer trying to
figure out how to express intuitively simple concepts using
advanced and very abstract and subtle predicate calculus.
As it turns out, Haskell sometimes makes a s
Tim Chevalier wrote:
On 5/29/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
My point is for most programs, trying to figure out exactly what you
want the program to do is going to be much harder than implementing a
program that does it.
Writing a spec can help with figuring out what you want you
On 5/29/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
My point is for most programs, trying to figure out exactly what you
want the program to do is going to be much harder than implementing a
program that does it.
Writing a spec can help with figuring out what you want your program to do.
Al
Henning Thielemann wrote:
On Sun, 27 May 2007, Andrew Coppin wrote:
Personally, I try to avoid ever using list comprehensions.
Me too. Successfully, I have to add.
But every now and then I discover an expression which is apparently not
expressible without them - which is odd, con
Tomasz Zielonka wrote:
On Mon, May 28, 2007 at 11:43:47AM +0100, Andrew Coppin wrote:
- Chapter 2 is... puzzling. Personally I've never seen the point of
trying to check a program against a specification. If you find a
mismatch then which thing is wrong - the program, or the spec?
Kno
Claus Reinke wrote:
I'm thinking more about things like phantom types, rank-N
polymorphism, functional dependencies, GADTs, etc etc etc that nobody
actually understands.
this seems to be overly polymorphic in generalising over all types of
Haskell programmers, rather than admitting the exist
On Tue, May 29, 2007 at 12:41:19PM -0400, Isaac Dupree wrote:
> Simon Peyton-Jones wrote:
> > | I wish the compilers would allow more fine grained switches on languages
> > | extensions. -fglasgow-exts switches them all on, but in most cases I'm
> > | interested only in one. Then typing errors or
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Peyton-Jones wrote:
> | I wish the compilers would allow more fine grained switches on languages
> | extensions. -fglasgow-exts switches them all on, but in most cases I'm
> | interested only in one. Then typing errors or design flaws (like 'typ
| I wish the compilers would allow more fine grained switches on languages
| extensions. -fglasgow-exts switches them all on, but in most cases I'm
| interested only in one. Then typing errors or design flaws (like 'type
| Synonym = Type', instead of wanted 'type Synonym a = Type a'; extended
| in
On Sun, 27 May 2007, Andrew Coppin wrote:
> Personally, I try to avoid ever using list comprehensions.
Me too. Successfully, I have to add.
> But every now and then I discover an expression which is apparently not
> expressible without them - which is odd, considering they're only
> "sugar"...
Hi Andrew!
I share your concerns about the simplicity of the language. Once
extensions exists, they are used widely, and readers of programs must
understand them, also if the extensions are used without need. I
understand the motivations for many type extensions, but library writers
tend to use l
On Mon, May 28, 2007 at 11:43:47AM +0100, Andrew Coppin wrote:
> - Chapter 2 is... puzzling. Personally I've never seen the point of
> trying to check a program against a specification. If you find a
> mismatch then which thing is wrong - the program, or the spec?
Knowing that one of them is wro
I'm thinking more about things like phantom types, rank-N polymorphism,
functional dependencies, GADTs, etc etc etc that nobody actually
understands.
this seems to be overly polymorphic in generalising over all types of
Haskell programmers, rather than admitting the existence of some types
of
On May 28, 2007, at 7:32 AM, Claus Reinke wrote:
I meant to imply more that "it's very difficult to understand why
it's useful". If an extension were truely *useless*, I doubt those
guys at GHC would have bothered spending years implementing them.
Most of the documents that describe these
Hello Andrew,
Monday, May 28, 2007, 2:43:47 PM, you wrote:
> - Chapter 12 is incomprehensible (to me at least). "Fun with Phantom
> Types" I've read it several times, and I still couldn't tell you what a
> phantom type is...
and noone else know! that is the whole fun is! :)
seriously, i'm known
On May 28, 2007, at 6:43 , Andrew Coppin wrote:
I find this with Haskell books. There are some brilliant bits.
There are some bits that are sort-of interesting but not really to
do with anything I'm passionate about, and then there are bits that
I can't comprehend...
This is a known prob
On May 28, 2007, at 5:39 , Andrew Coppin wrote:
I like to think I'm an intelligent, but... maybe I'm just kidding
myself...
Haskell's good at making people feel stupid. :)
Just a little background, btw: I'm no mathie, in fact I have some
problems with math for various reasons. Nor am I
On May 28, 2007, at 4:13 , Andrew Coppin wrote:
Haskell 98 does an excellent job of being extremely simple, yet
almost unbelievably powerful. Almost every day, I am blown away by
how powerful it is. I suppose it just defies belief that you could
possibly need even *more* power than is alre
I meant to imply more that "it's very difficult to understand why it's
useful". If an extension were truely *useless*, I doubt those guys at GHC
would have bothered spending years implementing them.
Most of the documents that describe these things begin with "suppose we have
this extremely com
Michael T. Richter wrote:
On Mon, 2007-28-05 at 10:35 +0100, Andrew Coppin wrote:
Most of the documents that describe these things begin with "suppose we
have this extremely complicated and difficult to understand situation...
now, we want to do X, but the type system won't let us." Which makes
On Mon, 2007-28-05 at 10:35 +0100, Andrew Coppin wrote:
> Most of the documents that describe these things begin with "suppose we
> have this extremely complicated and difficult to understand situation...
> now, we want to do X, but the type system won't let us." Which makes it
> seem like thes
Chaddaï Fouché wrote:
2007/5/28, Andrew Coppin <[EMAIL PROTECTED]>:
Then again, later on in the very same book there's a chapter entitled
"Fun with Phantom Types", which made precisely no sense at all...
You seem to think you're extremely clever since if something doesn't
make sense to you it
David House wrote:
I've read through pretty much all your arguments, and I think they
boil down to this:
"I don't understand why X is useful, and therefore it can't be useful."
I meant to imply more that "it's very difficult to understand why it's
useful". If an extension were truely *useless
On 27/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
Almost all language extensions seem to be of the form "hey, let's see
what happens if we randomly change the type checking rules so that
*this* is permitted. What would that be like?" Usually it's an extreme
struggle to even wrap my brain arou
On Sun, May 27, 2007 at 05:34:33PM -0400, Brandon S. Allbery KF8NH wrote:
>
> On May 27, 2007, at 17:23 , Andrew Coppin wrote:
>
> >Personally, I try to avoid ever using list comprehensions. But
> >every now and then I discover an expression which is apparently not
> >expressible without them
Jim Burton wrote:
Andrew Coppin wrote:
Haskell 98 does an excellent job of being extremely simple, yet almost
unbelievably powerful. Almost every day, I am blown away by how powerful
it is. I suppose it just defies belief that you could possibly need even
*more* power than is already in th
Andrew Coppin wrote:
>
>
> Haskell 98 does an excellent job of being extremely simple, yet almost
> unbelievably powerful. Almost every day, I am blown away by how powerful
> it is. I suppose it just defies belief that you could possibly need even
> *more* power than is already in the langu
Jim Burton wrote:
Speaking as someone who, like you, came to the language recently and for
whom many of haskell's outer corners are still confusing, I should firstly
say that I can see where you're coming from but that it puzzles me as to why
you think things ought to be obvious or why, when some
Brandon S. Allbery KF8NH wrote:
On May 27, 2007, at 17:23 , Andrew Coppin wrote:
Personally, I try to avoid ever using list comprehensions. But every
now and then I discover an expression which is apparently not
expressible without them - which is odd, considering they're only
"sugar"...
T
Andrew Coppin wrote:
>
>
> [snip]
>> You're missing a lot of the conceptual background
>
> Possibly. I find that most of what is written about Haskell tends to be
> aimed at absolute beginners, or at people with multiple PhDs. (As in,
> people to whom arcane terms like "denotational semanti
Hello Andrew,
Sunday, May 27, 2007, 5:19:51 PM, you wrote:
> Seriously. Haskell seems to attract weird and wonderful type system
> extensions like a 4 Tesla magnet attracts iron nails... And most of
> these extensions seem to serve no useful purpose, as far as I can
> determine.
existentials i
Type classes are very easy to explain, and quite obviously useful. This,
presumably, is why they're in the language.
You'd be surprised, I've seen people twist their brains in knots before
finally getting it.
Given the long debate I've just had about why "(/) 7 4" is a valid
expre
On May 27, 2007, at 17:23 , Andrew Coppin wrote:
Personally, I try to avoid ever using list comprehensions. But
every now and then I discover an expression which is apparently not
expressible without them - which is odd, considering they're only
"sugar"...
They are. But they're sugar fo
On Sun, 27 May 2007, Andrew Coppin wrote:
> I'm thinking more about things like phantom types, rank-N polymorphism,
> functional dependencies, GADTs, etc etc etc that nobody actually understands.
>
I think you'll find a fair number of people do in fact understand them!
> This worries me greatl
On Sun, 27 May 2007, Andrew Coppin wrote:
> Philippa Cowderoy wrote:
> > On Sun, 27 May 2007, Andrew Coppin wrote:
> >
> > > Seriously. Haskell seems to attract weird and wonderful type system
> > > extensions
> > > like a 4 Tesla magnet attracts iron nails... And most of these extensions
> > >
Brandon S. Allbery KF8NH wrote:
Seriously. Haskell seems to attract weird and wonderful type system
extensions like a 4 Tesla magnet attracts iron nails... And most of
these extensions seem to serve no useful purpose, as far as I can
determine. And yet, all nontrivial Haskell programs *require*
Philippa Cowderoy wrote:
On Sun, 27 May 2007, Andrew Coppin wrote:
Seriously. Haskell seems to attract weird and wonderful type system extensions
like a 4 Tesla magnet attracts iron nails... And most of these extensions seem
to serve no useful purpose, as far as I can determine.
Yeah,
On Sun, 27 May 2007, Andrew Coppin wrote:
> Seriously. Haskell seems to attract weird and wonderful type system extensions
> like a 4 Tesla magnet attracts iron nails... And most of these extensions seem
> to serve no useful purpose, as far as I can determine. And yet, all nontrivial
> Haskell pro
>> Erm... oh...kay... That kind of makes *slightly* more sense now...
>
> I wrote most of the second article, I'd appreciate any feedback you
> have on it.
If I'm understanding this correctly, existentially quantified types
(couldn't you find a name that's any harder to
remember/pronounce/spell?)
On May 27, 2007, at 9:19 , Andrew Coppin wrote:
So... ∀x . P means that P holds for *all* x, and ∃ x . P means
that x holds for *some* x? (More precisely, at least 1 possible
choice of x.)
Exactly.
Seriously. Haskell seems to attract weird and wonderful type system
extensions like a 4 T
On 27/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
So... ∀x . P means that P holds for *all* x, and ∃ x . P means that x
holds for *some* x? (More precisely, at least 1 possible choice of x.)
Exactly. There's also a lesser-used "there exists a unique", typically
written ∃!x. P, which means t
apfelmus wrote:
Andrew Coppin wrote:
OOC, can anybody tell me what ∀ actually means anyway?
http://en.wikipedia.org/wiki/Universal_quantification
http://en.wikipedia.org/wiki/System_F
So... ∀x . P means that P holds for *all* x, and ∃ x . P means that x
holds for *some* x? (M
58 matches
Mail list logo
