The current ghc-4.03 from the repository contains two bugs:
* In the modules Int and Word: The fromInteger methods handle
the J# cases only, but not the S# cases. Example:
import Word
main = print ((fromInteger 42)::Word32)
yields
Fail: Word.lhs:573:
On 19-Feb-1999, S. Alexander Jacobson [EMAIL PROTECTED] wrote:
Do existential types makes algebraic types obsolete?
I mean there seems to be a large semantic overlap between the two
concepts.
For example, once you can implement lists with just the product type (,),
why bother with
The basic problem that I have with this is that although dependent types
do allow you to specify a lot of things in the type system, I'm not sure
that using the type system is really the best way to specify these things.
Well, I think types are just the place for these things. People already
On 19-Feb-1999, Nick Kallen [EMAIL PROTECTED] wrote:
I'll admit to not having yet written something in Cayenne, but I'm an
adamant supporter of adding dependant types to the language. I remember a
year ago, I was writing a small (trivial) program. One of the essential ways
I was structuring
[EMAIL PROTECTED] writes:
enabling types to express all properties you want is, IMO, the right way.
Why do I feel that there must be another approach to programming?
How many people do you expect to program in Haskell once you are done adding all
it takes to "express all imaginable properties
Well if the ComplicatedTypeToSpecifySorting is correct (I don't know if
this is possible, but I suspect it isn't) it will of course not type check.
Of course it is possible. The types in Cayenne have the same power
as predicate logic, so you can specify most anything you like.
Here's a
F a * = member (map (F a) [0..]) // member [a] a - Bool
I mave no clue what this means. What is `member'?
Member is memq, in, etc. Checks for membership in a list.
I'm still lost. What is // and how does it bind?
This is how I parse it:
(member (map (F a) [0..])) // ( (member [a] a)
Well, yes, up to a point, but it may be clearer if the simple
regular types part is kept separate from the undecidable part,
as was done in NU-Prolog, or as is done in Eiffel.
I'm not necesssarily advocating that the properties and proofs of these
properties should be mixed with the regular
On 21-Feb-1999, Lennart Augustsson [EMAIL PROTECTED] wrote:
[Fergus wrote:]
The basic problem that I have with this is that although dependent types
do allow you to specify a lot of things in the type system, I'm not sure
that using the type system is really the best way to specify these