On Jul 27, 2010, at 3:02 AM, Brandon S Allbery KF8NH wrote:
> As I understand it:
> 1) carrying [contexts] around complicates Haskell98 (and now Haskell2010)
> compatibility (also see below);
Like the availability of so many other features,
this one could be controlled by a language pragma.
> 2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/26/10 06:02 , John Lato wrote:
> If the behavior of class contexts on data types were changed to what
> you think it should mean, i.e. contexts specified in a data
> declaration are carried around for all uses of that type instead of
> just the da
Richard,
I'm not sure that I agree or disagree with you; I think the decision
is above my pay grade.
On Mon, Jul 26, 2010 at 4:49 AM, Richard O'Keefe wrote:
>
> On Jul 26, 2010, at 12:35 PM, John Lato wrote:
>> Incidentally, there seems to be a consensus that this a Bad Idea [1].
>> Even when yo
On Jul 26, 2010, at 12:35 PM, John Lato wrote:
> Incidentally, there seems to be a consensus that this a Bad Idea [1].
> Even when you specify a type class context on a data declaration,
> Haskell still requires you to specify the context on functions that
> use that data (Address c a).
This has
> From: Patrick Browne
>
> Andrew,
> Thanks for your detailed feedback, it is a great help.
> I appreciate that the code does not do anything useful, nor is it an
> appropriate way to write Haskell, but it does help me
> understand language constructs. I have seen statements like
>
data C3 c3
Vo Minh Thu wrote:
2010/7/25 Andrew Coppin :
Since you're interested in comparisons... A method is simply a way of giving
the same name to several different functions, and have the compiler pick the
correct one based on the argument types.
[snip]
Actually in Haskell, the choice of the
2010/7/25 Andrew Coppin :
> Patrick Browne wrote:
>>
>> Andrew,
>> Thanks for your detailed feedback, it is a great help.
>>
>
> Well, I like to be helpful.
>
>> I appreciate that the code does not do anything useful, nor is it an
>> appropriate way to write Haskell, but it does help me
>> understa
Patrick Browne wrote:
Andrew,
Thanks for your detailed feedback, it is a great help.
Well, I like to be helpful.
I appreciate that the code does not do anything useful, nor is it an
appropriate way to write Haskell, but it does help me
understand language constructs.
Personally, I find i
Andrew,
Thanks for your detailed feedback, it is a great help.
I appreciate that the code does not do anything useful, nor is it an
appropriate way to write Haskell, but it does help me
understand language constructs. I have seen statements like
>>> data C3 c3 a => Address c3 a = Address c3 a
a
On 25 July 2010 13:09, Andrew Coppin wrote:
> This is not valid in Haskell '98. This is actually a type system extension
> known as "multi-parameter type classes", which do not even vaguely
> correspond to anything in normal OOP. (Except for being very slightly
> similar to generics, perhaps.)
Patrick Browne wrote:
Hi,
I am trying to understand the data type declaration below.
What is the relation between class C3 and the data type Address below?
Where is such a technique used?
OK, let's see what we can come up with...
module A where
data Person = Person String Integer deriving
Hi,
I am trying to understand the data type declaration below.
What is the relation between class C3 and the data type Address below?
Where is such a technique used?
Thanks,
Pat
module A where
data Person = Person String Integer deriving Show
data Employee = Employee String Integer deriving Sho
12 matches
Mail list logo