I'm relatively new to Haskell, so maybe this answer is a bit off, in
that I'm sure there are times when some sort of auto-existential
creation may have a point, but generally I've found that when I want
it I've been thinking about the problem wrong.
The bigger issue is that as soon as you
On Wed, Oct 24, 2007 at 11:00:14AM +0800, TJ wrote:
Tristan Allwood:
Very cool. I don't understand some (a lot of) parts though:
instance Show a = Reify (ShowConstraint a) where reify = ShowC
ShowC has type (Show a) = ShowConstraint a, whereas reify is
supposed to have type
Hi again,
Following up on my previous thread, I have figured out why it bothered
me that we cannot have a list such as the following: [abc, 123, (1,
2)] :: Show a = [a]
It seems to me that there is an annoying duality in treating simple
algebraic data type vs type classes. As it stands, I can
On 10/23/07, Luke Palmer [EMAIL PROTECTED] wrote:
On 10/23/07, TJ [EMAIL PROTECTED] wrote:
What I find strange is, if we can have functions with hidden
parameters, why can't we have the same for, say, elements of a list?
Suppose that I have a list of type Show a = [a], I imagine that it
On 10/23/07, TJ [EMAIL PROTECTED] wrote:
What I find strange is, if we can have functions with hidden
parameters, why can't we have the same for, say, elements of a list?
Suppose that I have a list of type Show a = [a], I imagine that it
would not be particularly difficult to have GHC insert
Short answer: You are worrying about syntax. The things you want are
possible.
TJ wrote:
Following up on my previous thread, I have figured out why it bothered
me that we cannot have a list such as the following: [abc, 123, (1,
2)] :: Show a = [a]
That type doesn't mean what you want it to
On 10/23/07, Jules Bean [EMAIL PROTECTED] wrote:
Short answer: You are worrying about syntax. The things you want are
possible.
TJ wrote:
Following up on my previous thread, I have figured out why it bothered
me that we cannot have a list such as the following: [abc, 123, (1,
2)] :: Show
TJ wrote:
No. I am saying that Haskell's type system forces me to write boilerplate.
Fair enough.
Why can't it automatically construct them then? Assuming we do have a
syntax for A list of objects, each of which is of some
possibly different type 'a', subject only to the restriction that a
On 10/23/07, Jules Bean [EMAIL PROTECTED] wrote:
I believe it is to do with the requirement that expressions have a
unique principle type. Certainly in principle the algorithm you outline
is possible, but I don't know what else you would lose.
I'm not familiar with the term principal type. I
Hello Luke,
Tuesday, October 23, 2007, 12:42:19 PM, you wrote:
of me whining about Haskell's lack of OO features. How are you
supposed to design your programs modularly if you can't have a
type-agnostic list?
But it doesn't bug me anymore. I can't really say why.
i tink because it's very
On Tue, 2007-10-23 at 17:40 +0800, TJ wrote:
On 10/23/07, Jules Bean [EMAIL PROTECTED] wrote:
That is, the type inference algorithm which GHC uses, which is not the
only one you can imagine, but for a variety of reasons is considered to
be one of the best choices, cannot 'automatically'
Why can't it automatically construct them then? Assuming we do have
a syntax for A list of objects, each of which is of some possibly
different type 'a', subject only to the restriction that a is a
member of typeclass Show, as the following:
ls :: [a where Show a]
Then I would
On 23/10/2007, Jules Bean [EMAIL PROTECTED] wrote:
I will also repeat the non-justified assertion that others have made,
and that I've made myself in the other thread, that you don't need
existentials as often in haskell as you do in OO languages, and they
certainly don't always need to be
Tristan Allwood:
Very cool. I don't understand some (a lot of) parts though:
instance Show a = Reify (ShowConstraint a) where
reify = ShowC
ShowC has type (Show a) = ShowConstraint a, whereas reify is
supposed to have type ShowConstraint a.
data SingleList (a :: * - *) where
Cons :: (a
14 matches
Mail list logo
