Just in case there's anybody else out there who's as ignorant about the
theory underlying type systems as I am, I've found that Luca Cardelli
has written something about these issues.
You can get this in Postscript :-( or PDF :-) from..
http://www.luca.demon.co.uk/
This seems like a ve
On 28-May-1998, Adrian Hey <[EMAIL PROTECTED]> wrote:
> > A strong type system is supposed to prevent runtime errors.
> > Thus it makes sense to disallow anything that might
> > result in an attempt to access an unbound type.
>
> Yes, but in the cases we've been talking about we know that there w
On Thu 28 May, Fergus Henderson wrote:
> Unbound type variables can lead to runtime errors.
Its difficult to see how they can be always avoided without writing explicit
type signatures to do this.
> A strong type system is supposed to prevent runtime errors.
> Thus it makes sense to disallow any
Mr. Grumpy writes:
> What is the ultimate purpose of type checking a program? The answer has
> to be, to avoid run-time errors. Beyond this, the type system seems to
> serve no purpose and so should not reject definitions such as that
> above, in an ideal world.
I agree that a valuable purpos
On 27-May-1998, Mr. Grumpy <[EMAIL PROTECTED]> wrote:
> -
> Fergus Hendersons Example
> -
> > Note that the different types can lead to different semantics.
> > Consider the following code, which is similar to the code above:
> >
> > foo ::
Sorry to raise this old chestnut again, but my work dragged me away
before I had time to properly digest and respond to other peoples
messages on this subject. But now I'm back and I've spent some more
time cogitating type systems generally and the Haskell type system in
particular, and I'm more c
On 12-May-1998, Adrian Hey <[EMAIL PROTECTED]> wrote:
> My first reaction to this was to wonder how it could ever be advantageous
> to reduce the same expression several times instead of just once. Then,
> on reflection I thought Gosh!, I see what you mean, thats never occured
> to me before. Lazy
On Tue 12 May, Frank A. Christoph wrote:
> I'm experiencing a little bout of deja vu here, so excuse me if it turns out
> that I'm repeating myself. (I could swear I already posted this, but it's
> not in my "Messages Sent" folder...)
>
> With regard to merging Either instances, I agree with Sim
On 12-May-1998, Frank A. Christoph <[EMAIL PROTECTED]> wrote:
>
> With regard to merging Either instances, I agree with Simon that for most
> programs this will not buy you much, but there are two common kinds of
> programs where one could expect a significant effect on performance, just
> becaus
>> Actually, GHC does finally discard type information right at the
>> end, so we could do an extra bit of CSE there, but frankly I doubt
>> it would buy very much. But I'm willing to stand corrected.
>
>I don't think you can say this. Granted in this trivial example
>we are only talking about wa
On Tue, 12 May 1998, Mariano Suarez Alvarez wrote:
| On Tue, 12 May 1998, Koen Claessen wrote:
|
| > map :: (a -> b) -> [a] -> [b]
| > map f (x:xs) = f x : map f xs
| > map f xs = xs
|
| Where is the CSE in theis def of map? Why is it naive? (Hugs & ghc define
| map on lists e
Frank A. Christoph wrote:
| With regard to merging Either instances, I agree with Simon that for most
| programs this will not buy you much, but there are two common kinds of
| programs where one could expect a significant effect on performance, just
| because of sheer scale.
It is not only
Hello,
Thanks to everybody who replied on this thread. I'm afraid I've got
to go away for a couple of weeks, so I can't join in any more :-(
Here are my views on the most recent postings...
On Mon 11 May, Jon Mountjoy wrote:
--
> I would guess 'sometimes'. In s
On Tue, 12 May 1998, Koen Claessen wrote:
> Frank A. Christoph wrote:
>
> | With regard to merging Either instances, I agree with Simon that for most
> | programs this will not buy you much, but there are two common kinds of
> | programs where one could expect a significant effect on performa
On 11-May-1998, Simon L Peyton Jones <[EMAIL PROTECTED]> wrote:
>
> Since GHC keeps the types right through the compiler, it
> really can't do CSE on two terms of type
>
> Either Int Int
> Either Bool Int
>
> even if they are both applications of Right.
>
> Actually, GHC does final
While on this topic I would like to ask the question:
Is CSE very useful for Haskell programs?
I would guess 'sometimes'. In some cases of course is it, but in
other cases you might increase the scope of an expression and thereby
worsen the space behaviour. Have there been any attempts to
i
> Incidentally, I don't think it would be sensible to change
> the type system to allow the
>
> demo1 :: (a -> b) -> Either a c -> Either b c
> demo1 f (Left a) = Left (f a)
> demo1 _ r@(Right c) = r
>
> What type does r have? Either a c.
> What type does the result of the fn have? Eit
Yes, GHC does some CSE stuff, but not very much. I don't think it has a large
performance impact, but (as luck would have it) but I plan to work on it a bit
in the newt few months.
My advice would be: write clear code, and let the compiler do the
CSE. If it doesn't, complain to the compiler wri
On Fri 08 May, Victor M. Gulias wrote:
> I have found an example that seems to be related to this thread. The
> map function behaves like this:
>
>map f [a1,a2,...,an] = [f a1, f a2, ..., f an]
>
> Suppose a function f defined as:
>
> f :: Maybe a -> Int
> f Nothing = 1
> f _ = 0
>
>
I have found an example that seems to be related to this thread. The
map function behaves like this:
map f [a1,a2,...,an] = [f a1, f a2, ..., f an]
Suppose a function f defined as:
f :: Maybe a -> Int
f Nothing = 1
f _ = 0
the following expression is type checked successfully:
sum
I've had a few more thoughts on this subject..
As far as the problem with 'as patterns' is concerned (demo2) I think
it should be fairly easy to modify the type checker to allow such
function definitions, as follows
Wherever a varible (which is known to match a given pattern)
occurs in an
On Thu 07 May, [EMAIL PROTECTED] wrote:
>
> Adrian Hey writes:
>
> > Consider the following function..
>
> > demo1 :: (a -> b) -> Either a c -> Either b c
> > demo1 f (Left a) = Left (f a)
> > demo1 _ (Right c) = Right c
>
> > My first question is, can programmers safely assume that the
> > c
On 07-May-1998, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Adrian Hey writes:
>
> > Consider the following function..
>
> > demo1 :: (a -> b) -> Either a c -> Either b c
> > demo1 f (Left a) = Left (f a)
> > demo1 _ (Right c) = Right c
>
> > My first question is, can programmers safely
Adrian Hey writes:
> Consider the following function..
> demo1 :: (a -> b) -> Either a c -> Either b c
> demo1 f (Left a) = Left (f a)
> demo1 _ (Right c) = Right c
> My first question is, can programmers safely assume that the
> compiler is sufficiently smart to avoid duplicating the express
24 matches
Mail list logo
