Alastair Reid <[EMAIL PROTECTED]> writes:
> Do you just want exceptions to be displayed by an interpreter or do you want
> them used in the compiler (i.e., part of the Haskell language).
I think it would be difficult, and perhaps undesirable, to make it
part of the language. So my immediate tho
> This sounds very tedious! The right thing to do if you don't handle
> them, is of course to propagate exceptions up; however, then you need
> to update a 'throws' clause as you modify your implementation.
>
> Sounds like a job for...Type Inference! Wouldn't it be nice if GHCi
> and Hugs' ":i f
>Sounds like a job for...Type Inference!
In Olegs post where he gave examples of how to make exceptions explicit
in type signatures:
oleg said:
> {-# OPTIONS -fglasgow-exts #-}
> {-# OPTIONS -fallow-undecidable-instances #-}
>
> module TER where
>
> class CERROR a c where
> darn:: a -> c->
André Pang <[EMAIL PROTECTED]> writes:
> As Keith said, Java will check at compile time whether or not you
> handle the exception.
This sounds very tedious! The right thing to do if you don't handle
them, is of course to propagate exceptions up; however, then you need
to update a 'throws' clause
On 06/08/2004, at 7:43 PM, Keith Wansbrough wrote:
Not so. In Java, the programmer is forced to handle most exceptions
by the type system. That is, if the exception is not handled, the
program will not compile, thus providing a static guarantee that
exceptions are handled.
One feature I've always
On 06/08/2004, at 6:56 PM, MR K P SCHUPKE wrote:
After all, Java basically does exactly what you're asking for with
Java's head/tail would be doing runtime checks if they are throwing
exceptions,
static guarantees mean the program would not be allowed to compile if
it broke
the static guarantees.
>class HLe n n'
>instance HLe HZero HZero
>instance HLe x y => HLe (HSucc x) (HSucc y)
Erm of course this was the definition for Equals, not less than or
equals!
class HLe n n'
instance HLe HZero x
instance HLe x y => HLe (HSucc x) (HSucc y)
Is the definition for less than or equals... but it
>You should include the definitions of the classes before saying
HOrderedList l' just has to prove by induction that for any element
in the list, the next element is greater, so the class is simply:
class HOrderedList l
instance HNil
instance HCons a HNil
instance (HOrderedList (HCons b l),HLe a
> correctly sorted lists under _all_ circunstances. This type signature
> is much simpler than the actual sort - hence is useful.
>
> sort :: (HList l,HOrderedList l') => l -> l'
>
> Nice and readable, and much simpler than the actual algorithm (be
> it bubble sort, or a quick sort)
The ty
>>Static guarantees are great, but if you have to explicitly change your
>>style of coding to cope with those extra constraints, it can become (very)
>>cumbersome.
I had to change coding style moving from imperative to declarative languages,
but I think it was worth it... Likewise I think having t
At 12:36 06/08/04 +1000, André Pang wrote:
Static guarantees are great, but if you have to explicitly change your
style of coding to cope with those extra constraints, it can become (very)
cumbersome.
[...] It's a human problem, not a technical one.
I think that's an important point. For some
>Not so. In Java, the programmer is forced to handle most exceptions
I forgot you had to do that... Exceptions are explicit in the type
signatures. I think Oleg posted a message a while back about how to
make exceptions explicit in haskell type signatures... But I would
rather use static guarante
> >After all, Java basically does exactly what you're asking for with
>
> Java's head/tail would be doing runtime checks if they are throwing exceptions,
> static guarantees mean the program would not be allowed to compile if it broke
> the static guarantees.
Not so. In Java, the programmer is f
>After all, Java basically does exactly what you're asking for with
Java's head/tail would be doing runtime checks if they are throwing exceptions,
static guarantees mean the program would not be allowed to compile if it broke
the static guarantees.
>end-programmers have to worry much less about
On 05/08/2004, at 7:40 PM, MR K P SCHUPKE wrote:
I have a hard time understanding why functional programmers would not
want
more static typing guarantees, after all they can always use C if they
dont like type systems!
Static guarantees are great, but if you have to explicitly change your
style o
>specify that a sort function (say) returns an ordered list
Fistly this is already possible in Haskell - see Oleg, Ralf and
My paper:
@misc{KLS04,
author = "Oleg Kiselyov and Ralf L{\"a}mmel and Keean Schupke",
title = "{Strongly typed heterogeneous collections}",
booktitle = "{ACM SIGPLAN Wo
Hi folks
Alastair Reid wrote:
>>I have a hard time understanding why functional programmers
>>would not want more static typing guarantees, after all they
>>can always use C if they dont like type systems!
>
> I think the value of Haskell's type system is that it catches a lot
of > bugs _cheaply_.
> I have a hard time understanding why functional programmers
> would not want more static typing guarantees, after all they
> can always use C if they dont like type systems!
I think the value of Haskell's type system is that it catches a lot of bugs
_cheaply_. That is, with little programmer
What can I say... Static typing guarantees is what made me switch from
object oriented languages like C++/ObjectiveC/Java (that and the availability
of a good compiler) - So I am obviously in favour of more static guarantees -
I believe programming by contract is the way to reliable _engineered_ so
On 04/08/2004, at 12:28 AM, MR K P SCHUPKE wrote:
f (case xs of (x:_) -> x; [] -> error "whoops") -- direct style
Yup, this is how I do it... I never use head!
I like to pass failures back up to the level where some kind of
sensible
error message can be generated. In your example the error is no
20 matches
Mail list logo
