Alex Ferguson <[EMAIL PROTECTED]> wrote in reply to Jeff Lewis:
| > ... I can't think of a good rationale for it (aside from the "don't
break
| > old code" argument, which, if that's the only argument, doesn't seem
| > strong enough to me).
|
| For Standard Haskell at least, it ought to be a
| This sounds great, but it could break old code, of course. This would have a
| different type under Ralf's proposal than Haskell 1.4:
| (id :: a -> a, id :: a -> a)
| However, I think something like it is the only sane way to go. Whatever we do, type
| variables should scope consistently
| > > Just as a sanity check, following an augmented proposal "A" where we can also
| > > annotate the return type as well, consider these:
| > >
| > > f :: a -> (a -> a) -> a
| > > f x = \g -> (g :: a -> a) x
| > >
| > > f (x :: a) :: (a -> a) -> a = \g -> (g :: a -> a) x
| > >
| > >
Jeff Lewis:
> I'm not sure what the parenthetical comment about the interpretation of a
means -
> take the definition at face value.
My point was: were they _intended_ to be same "a", or different? What
is "face value" is surely simply begging the question.
> It's not at all clear to me that
Hi Jeff.
> > http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
> >
> > I think "A" is fine, it's "B" (and hence, SPJ's Composite Motion, A+B)
> > that worries me, for the reasons I alluded to. If "beefed up A"
> > does the job, I'm equally happy as with a more conservation syn
Ok, back to the main list we go!
| But the problem is that I need the type name c inside the body of
| the function! I'm assuming always that I can solve a typeing
| problem by adding an explicit type signature wherever it's needed;
| however, that implies that I need to be able to get at the ty
Hi Alex,
| > I think the way that Hugs 1.3c handles it ...
| ...
| AKA "Proposal A" in SPJ's recent message on this topic:
|
| http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
Exactly, although I hadn't been referring to that at the
time. The only negative point for proposal
Hi Mark (and all).
> I think the way that Hugs 1.3c handles it would meet your goals. All that
> it requires is a strict extension to the syntax for patterns to allow type
> annotations. These can be useful in their own right, but also can be
> applied to problems like the one that you gave:
>
type names.
--
From: mpj
Sent: 22 July 1998 14:44
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Scoped typed variables.
| Yes, I've always tended to think that the parameters of a function need
| to be given types explicity.
I'm not
Ralf Hinze wrote:
> One could also argue that the culprit is Haskell's interpretation of
> type variables of which Report (p. 34) says: `[...] the type variables
> in a Haskell expression are all assumed to be universally quantified
> [..]'. Here is an even more irritating list of possibilities .
12:00
To: Simon L Peyton Jones <[EMAIL PROTECTED]>;
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Scoped typed variables.
To: Simon L Peyton Jones <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: RE: Scoped typed variables.
| Michael suggested
|
| f :: [a] -> c
| f xs
Alex Ferguson wrote:
> Hi Jeff.
>
> > > http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=274
> > >
> > > I think "A" is fine, it's "B" (and hence, SPJ's Composite Motion, A+B)
> > > that worries me, for the reasons I alluded to. If "beefed up A"
> > > does the job, I'm equally hap
| Michael suggested
|
| f :: [a] -> c
| f xs = if len > fromInteger 3 then len else 0
| where
| len :: c
| len = length xs
|
| This relies on the 'c' from the type signature scoping over
| the definition, which is on alternative notation for scoped
| type variables.
Hmm,
Alex Ferguson wrote:
> > I think the way that Hugs 1.3c handles it would meet your goals. All that
> > it requires is a strict extension to the syntax for patterns to allow type
> > annotations. These can be useful in their own right, but also can be
> > applied to problems like the one that yo
> I think the way that Hugs 1.3c handles it would meet your goals. All that
> it requires is a strict extension to the syntax for patterns to allow type
> annotations. These can be useful in their own right, but also can be
> applied
> to problems like the one that you gave:
>
> f :: [a] -> a
Hi Alex,
| Further to discussion on the StdHask site, and (of all places) ghc-bugs,
| I remain concerned about the program-breaking proposal to have typesigs
| scope over equation groups, thereby binding any type variable occurrences
| in local signatures. But I agree with the need to add this e
Further to discussion on the StdHask site, and (of all places) ghc-bugs,
I remain concerned about the program-breaking proposal to have typesigs
scope over equation groups, thereby binding any type variable occurrences
in local signatures. But I agree with the need to add this expressivity.
Sure
17 matches
Mail list logo
