[EMAIL PROTECTED] wrote:
> One thing that hasn't come up yet is that empty instance declarations
> are the only decent option (that I know of) that we have in the
> absence of real class aliases.
It does seem to me that compilers could reasonably distinguish between
incomplete definition:
> > cl
[EMAIL PROTECTED] wrote:
> One thing that hasn't come up yet is that empty instance declarations are
> the only decent option (that I know of) that we have in the absence of
> real class aliases.
I agree. I use this in my code in a number of places.
It helps to write readable signatures.
Best
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
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).
>
>
>
> instance Show WeekDay where
> (empty)
You see, an empty instance like that may serve various purposes. In
type-level programming, for example, they (roughly) correspond to facts in
logic programming. However, in the case at hand, this is what happens: the
doc for class Show reads thus:
"Mini
Dear all
A student from a beginners course on Functional Programming came to me with
a problem, he declared a type like:
data WeekDay = Mon | Tue | Fri -- ...
He had forgot to complete a Show instance definition.
instance Show WeekDay where
(empty)
Then he complained about getting *** Excepti
17 matches
Mail list logo
