G'day all.
Quoting Isaac Dupree <[EMAIL PROTECTED]>:
I know! I said so! My question is whether anyone has an example of
doing either of those in mutually-recursive DEFAULT METHOD definitions?
class (Eq a) => StupidEqList a where
eqList :: [a] -> [a] -> Bool
neqList :: [a] -> [a] ->
G'day all.
Quoting Hugo Macedo <[EMAIL PROTECTED]>:
After checking the Haskell98 grammar I found out that this is allowed
syntactically and probably semantically too. Is there any reason to do that?
One thing that hasn't come up yet is that empty instance declarations are
the only decent opti
On Dec 28, 2007, at 12:06 PM, Ralf Laemmel wrote:
You did not say anything that's imprecise about "mentioning each
other
in a cycle", just the well-known fact that it's not equivalent to
total
termination checking (in fact, it's neither fully an overestimate nor
underestimate of termination
Neil Mitchell wrote:
If the default
methods form a cycle, and the user has not broken that cycle by
inserting a real implementation, that's almost certainly a bug - I'd
go as far as to say its an error rather than a warning.
I'd agree except that
"instance Num () where"
with no specified defi
Ralf Laemmel wrote:
You did not say anything that's imprecise about "mentioning each other
in a cycle", just the well-known fact that it's not equivalent to total
termination checking (in fact, it's neither fully an overestimate nor
underestimate of termination -- it's just an estimate that's lik
> You did not say anything that's imprecise about "mentioning each other
> in a cycle", just the well-known fact that it's not equivalent to total
> termination checking (in fact, it's neither fully an overestimate nor
> underestimate of termination -- it's just an estimate that's likely to
> be ri
Neil Mitchell wrote:
The trouble, of course, is that classes could have rather complicated
"minimum instance" requirements. Still, if someone came up with a
decent syntax such as (but better than)
You don't need a syntax, the information is already there. You also
don't need to do complicated
Ralf Laemmel wrote:
Isaac wrote:
I wonder whether it would be safe for the compiler to infer simply by
the default methods mentioning each other in a cycle. It might miss
some cases when (probably involving laziness) the default methods
actually terminate and form an intended set of implementi
Isaac wrote:
> I wonder whether it would be safe for the compiler to infer simply by
> the default methods mentioning each other in a cycle. It might miss
> some cases when (probably involving laziness) the default methods
> actually terminate and form an intended set of implemention, and warn
>
On Dec 28, 2007 5:14 PM, Mike Haskel <[EMAIL PROTECTED]> wrote:
> You can define Show as a data type, rather than a type class:
>
> type Show a = Either (a -> String) (Int -> a -> String -> String)
...
> The constructors for Show make explicit the two ways to define an
> instance. This technique a
You may be interested in a trick relating to type classes which can
address this issue, though it's not the "Haskell way to do it."
You can define Show as a data type, rather than a type class:
type Show a = Either (a -> String) (Int -> a -> String -> String)
show :: Show a -> a -> String
show (
Hi
> The trouble, of course, is that classes could have rather complicated
> "minimum instance" requirements. Still, if someone came up with a
> decent syntax such as (but better than)
You don't need a syntax, the information is already there. You also
don't need to do complicated non-terminatio
David Roundy wrote:
The trouble, of course, is that classes could have rather complicated
"minimum instance" requirements. Still, if someone came up with a
decent syntax such as (but better than)
class Foo f where
foo :: f
foo = bar
bar :: f
bar = foo
requiring ( foo || bar )
it
On Dec 27, 2007 2:20 PM, Jorge Marques Pelizzoni <[EMAIL PROTECTED]> wrote:
> The problem is, when you declare an empty instance, all functions (if any)
> assume their default definitions. Therefore, when you call show/showsPrec
> (even indirectly) you end up in an endless loop because of (ii).
>
>
Linguistic Field(s): Computational Linguistics
Topic: Surface realisation and large scale over-generation detection
Deadline: February 15, 2008.
Employer: INRIA (French National Institute for Research in Computer
Science) Nancy Grand Est (France)
Job Description: The Lorraine Laboratory of IT R
15 matches
Mail list logo
