Malcolm Wallace wrote:
> Christian Maeder <[EMAIL PROTECTED]> writes:
>
>>>voidcast v@(VariantWithOne{}) = v { field1 = Void , field2 = Void }
>>Setting field2 only assures type correctness, but the value of field2
>>would be ignored at runtime.
>
> Exactly what I was proposing.
I know, but how
Christian Maeder wrote:
> Malcolm Wallace wrote:
>>Christian Maeder <[EMAIL PROTECTED]> writes:
>>
voidcast v@(VariantWithOne{}) = v { field1 = Void , field2 = Void }
>>>Setting field2 only assures type correctness, but the value of field2
>>>would be ignored at runtime.
>>Exactly what I was pr
Malcolm Wallace wrote:
> Yes, I find it interesting that consecutive updates are not equivalent
> to a combined update. I believe this is largely because named fields
> are defined as sugar - they behave in some sense like textual macros
> in other languages, which can often turn out to have unexp
Malcolm Wallace wrote:
> > Yes, I find it interesting that consecutive updates are not equivalent
> > to a combined update. I believe this is largely because named fields
> > are defined as sugar - they behave in some sense like textual macros
> > in other languages, which can often turn out to ha
Malcolm Wallace wrote:
> I believe this is a very different question from the consecutive
> update one.
I agree, consecutive and parallel updates are quite different.
> I can see no
> reason to outlaw a type change, where all the relevant types change
> at the same time:
>
> update_ok v@(A{
Hi there,
> but GHC complains:
> > Illegal instance declaration for `Foo (Either b b)'
> > (The instance type must be of form (T a b c)
> > where T is not a synonym, and a,b,c are distinct type variables)
> > In the instance declaration for `Foo (Either b b)'
unless I'm t
but GHC complains:
Illegal instance declaration for `Foo (Either b b)'
(The instance type must be of form (T a b c)
where T is not a synonym, and a,b,c are distinct type variables)
In the instance declaration for `Foo (Either b b)'
unless I'm totally mistaken, your proble
Christian Maeder <[EMAIL PROTECTED]> writes:
> Typing fails in your original example:
> voidcast [EMAIL PROTECTED] = v {field1 = Void}
> but not in the "lambda equivalent"
> voidcast [EMAIL PROTECTED] =
>(\ (VariantWithOne a) -> VariantWithOne Void) v
Hmm. Yes, that was my origin
Am Sonntag, 26. Juni 2005 21:02 schrieben Sie:
> On Sun, 26 Jun 2005, Daniel Fischer wrote:
> > >m x y = if x==0 then 0 else x*y
> >
> > Plain
> >
> > foldr m 1
> >
> > does fine, in fact much better than
> >
> > foldl' (*) 1 . upTo (== 0),
> >
> > both in hugs and ghc, regarding speed and memo
On Mon, 27 Jun 2005, Malcolm Wallace wrote:
> I can only repeat myself, that the field being updated (and
> type-converted) is only one of many, and all other fields should
> carry the same value in the updated structure as in the original.
> There is no good way to write this at the moment. If
On Mon, 27 Jun 2005, Daniel Fischer wrote:
> Am Sonntag, 26. Juni 2005 21:02 schrieben Sie:
> > On Sun, 26 Jun 2005, Daniel Fischer wrote:
> > > >m x y = if x==0 then 0 else x*y
> > >
> > > Plain
> > >
> > > foldr m 1
> > >
> > > does fine, in fact much better than
> > >
> > > foldl' (*) 1 .
On 6/27/05, robert dockins <[EMAIL PROTECTED]> wrote:
>
> I think that you are mistaken. The OP listed:
>
> > class Foo a
> > instance Foo (Either b b)
>
> Without further information, Haskell compilers will assume that the
> type(s) in a class declaration has/have kind * (Report section 4.6).
I have an extremely large source file of about 11 MB. It's the all-pairs
shortest paths data for a map of the Hyde Park area of Chicago (no real
reason, really). I generated information in Scheme and printed the result to
a Haskell source file as a list. I then edited the file to initialized
On 6/26/05, Henning Thielemann <[EMAIL PROTECTED]> wrote:
> On Sun, 26 Jun 2005, Daniel Fischer wrote:
> > [...]
> > I don't know, why the tyvars must be distinct in Haskell 98,
>
> This is certainly to prevent from overlapping instances. An implementation
> for general (Either a b) could also be
Arjun Guha wrote:
I have an extremely large source file of about 11 MB. It's the all-pairs
shortest paths data for a map of the Hyde Park area of Chicago (no real
reason, really). I generated information in Scheme and printed the result to
a Haskell source file as a list. I then edited the
Hi John
> Also, I defined this in my source file:
>
> test :: forall a. (Num a) => a
> test = 2 * 5 + 3
>
> Now, it can be used:
>
> NumTest> test
> 13
> NumTest> rpnShow test
> "2 5 * 3 +"
> NumTest> prettyShow test
> "(2*5)+3"
> NumTest> test + 5
> 18
I had newer seen anybody use "forall a
On 2005-06-27, Mads Lindstrøm <[EMAIL PROTECTED]> wrote:
> Hi John
>
>> test :: forall a. (Num a) => a
>> test = 2 * 5 + 3
[ snip ]
> I had newer seen anybody use "forall a." in function signatures before,
> and therefore was curious about its effect. This is probably do to my
> inexperience rega
Hi John Goerzen
> On 2005-06-27, Mads Lindstrøm <[EMAIL PROTECTED]> wrote:
> > Hi John
> >
> >> test :: forall a. (Num a) => a
> >> test = 2 * 5 + 3
>
> [ snip ]
>
> > I had newer seen anybody use "forall a." in function signatures before,
> > and therefore was curious about its effect. This is
On 27 June 2005 19:24, Arjun Guha wrote:
> I have an extremely large source file of about 11 MB. It's the
> all-pairs shortest paths data for a map of the Hyde Park area of
> Chicago (no real reason, really). I generated information in Scheme
> and printed the result to a Haskell source file as
On Mon, 2005-06-27 at 22:12 +0200, Mads Lindstrøm wrote:
> > > I had newer seen anybody use "forall a." in function signatures before,
> > > and therefore was curious about its effect. This is probably do to my
> > > inexperience regarding Haskell.
The "forall a." syntax is not Haskell 98. The u
20 matches
Mail list logo
