Tomasz Zielonka wrote:
[A bit late reply - I've just returned from vacation]
On Sun, Jan 08, 2006 at 05:47:19PM -, Brian Hulley wrote:
All I'm proposing is that the compiler should do all this painful
work for you, so that you don't need to bother creating a different
file that then needs
Tomasz Zielonka wrote:
On Sun, Jan 08, 2006 at 01:06:18PM -, Brian Hulley wrote:
5) We can get all the advantages of automatic namespace management
the OOP programmers take for granted, in functional programming, by
using value spaces as the analogue of objects, and can thereby get
rid of
On Tuesday 17 January 2006 22:44, Brian Hulley wrote:
Tomasz Zielonka wrote:
On Sun, Jan 08, 2006 at 01:06:18PM -, Brian Hulley wrote:
5) We can get all the advantages of automatic namespace management
the OOP programmers take for granted, in functional programming,
by using value
On Tue, Jan 17, 2006 at 08:43:55PM -, Brian Hulley wrote:
An advantage of this would be that you'd no longer need to think up
different field names for each record that you use to keep track of state
when traversing a data structure - something that quickly becomes extremely
difficult
[A bit late reply - I've just returned from vacation]
On Sun, Jan 08, 2006 at 05:47:19PM -, Brian Hulley wrote:
All I'm proposing is that the compiler should do all this painful work for
you, so that you don't need to bother creating a different file that then
needs two import directives
On Sun, Jan 08, 2006 at 01:06:18PM -, Brian Hulley wrote:
5) We can get all the advantages of automatic namespace management the OOP
programmers take for granted, in functional programming, by using value
spaces as the analogue of objects, and can thereby get rid of complicated
Hi -
A main problem I've found with Haskell is that within a module, too many
things are put into the same scope. For example
data Tree a b = Leaf a | Node {elem::b, lhs::Tree a b, rhs::Tree a b}
puts Leaf, Node, elem, lhs, and rhs, into the module's namespace,
as well as Tree. This means
Am Sonntag, 8. Januar 2006 14:06 schrieb Brian Hulley:
Hi -
A main problem I've found with Haskell is that within a module, too many
things are put into the same scope. For example
data Tree a b = Leaf a | Node {elem::b, lhs::Tree a b, rhs::Tree a b}
puts Leaf, Node, elem, lhs, and rhs,
- Original Message -
From: Daniel Fischer [EMAIL PROTECTED]
To: Brian Hulley [EMAIL PROTECTED]
Cc: Haskell-cafe haskell-cafe@haskell.org
Sent: Sunday, January 08, 2006 3:47 PM
Subject: Re: [Haskell-cafe] Avoiding name collisions by using value spaces
instead of modules
Am Sonntag
On 08/01/06, Brian Hulley [EMAIL PROTECTED] wrote:
For example, suppose I'm writing a module M that deals with grammar, where
the elements in a grammar rule are parameterised so that rules can be
written using strings but processed as if we'd used ints instead:
data Element a = Terminal a
- Original Message -
From: Cale Gibbard [EMAIL PROTECTED]
To: Brian Hulley [EMAIL PROTECTED]
Cc: Daniel Fischer [EMAIL PROTECTED]; Haskell-cafe
haskell-cafe@haskell.org
Sent: Sunday, January 08, 2006 5:54 PM
Subject: Re: [Haskell-cafe] Avoiding name collisions by using value spaces
-cafe] Avoiding name collisions by using value spaces
instead of modules
On 08/01/06, Brian Hulley [EMAIL PROTECTED] wrote:
For example, suppose I'm writing a module M that deals with grammar,
where
the elements in a grammar rule are parameterised so that rules can be
written using strings
Cale Gibbard wrote:
snip
Thanks for the illustration - I see another advantage with type classes is
that you only need to write the type signature once (in the class
declaration) instead of before each instance binding.
Secondly, if the functions are really different, and you never plan
On 08/01/06, Brian Hulley [EMAIL PROTECTED] wrote:
Cale Gibbard wrote:
snip
Thanks for the illustration - I see another advantage with type classes is
that you only need to write the type signature once (in the class
declaration) instead of before each instance binding.
Secondly, if the
Unifying these two under a single operation is certainly trickier, and
it's a little more questionable that it should be done at all, given
that their types are so different -- below is the closest I could come
to it off-hand.
---
{-# OPTIONS_GHC -fglasgow-exts #-} -- for
Cale Gibbard wrote:
Unifying these two under a single operation is certainly trickier,
and it's a little more questionable that it should be done at all,
given that their types are so different -- below is the closest I
could come to it off-hand.
---
{-# OPTIONS_GHC -fglasgow-exts #-} -- for
16 matches
Mail list logo
