Dan Licata wrote:
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
If you have any comments or suggestions about this design, we'd love to
hear them.
Simon Marlow wrote:
> Dan Licata wrote:
>> Simon PJ and I are implementing view patterns, a way of pattern matching
>> against abstract datatypes, in GHC. Our design is described here:
>>
>> http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
>>
>> If you have any comments or suggestions about t
| At the risk of being a spoil-sport, I have a somewhat negative take on
| view patterns. Not because I think they're particularly bad, but
| because I don't think they're significantly useful enough to warrant
| adding to the language, at least if we also have pattern guards.
Syntactic sugar is
Simon Peyton-Jones wrote:
> Views have been the subject of rather inconclusive debate for a long time,
> certainly since the inception of Haskell. I'm thinking of pattern
views as a way
> to break the logjam by implementing something that is a reasonable stab,
> and seeing whether it "sticks". I th
Jules Bean wrote:
> Have you tried using pattern guards for views?
>
> f s | y :< ys <- viewl s =
> | EmptyL <- viewl s =
Hm, I'd simply use a plain old case-expression here
f s = case viewl s of
y :< ys -> ...
EmptyL -> ...
In other words, case-expressions are as po
apfelmus wrote:
> Jules Bean wrote:
>> Have you tried using pattern guards for views?
>>
>> f s | y :< ys <- viewl s =
>> | EmptyL <- viewl s =
>
> Hm, I'd simply use a plain old case-expression here
>
> f s = case viewl s of
> y :< ys -> ...
> EmptyL -> ...
>
> In o
[I think we should move the rest of this thread to haskell-cafe, since
it's getting long. Note that there have already been some responses on
both lists.]
Hi Claus,
On Jul25, Claus Reinke wrote:
> >I think that the signature
> >
> >> type Typ
> >>
> >> unit :: Typ -> Maybe ()
> >> arrow ::
Benjamin Franksen wrote:
> apfelmus wrote:
>>
>> In other words, case-expressions are as powerful as any view pattern may
>> be in the single-parameter + no-nesting case.
>
> This is how I do it, no pattern guards, no view patterns:
>
> zip :: Seq a -> Seq b -> Seq (a,b)
> zip xs ys = case (viewl
Simon Marlow <[EMAIL PROTECTED]> writes:
> Dan Licata wrote:
>
> > Simon PJ and I are implementing view patterns, a way of
> > pattern matching against abstract datatypes, in GHC.
>
> At the risk of being a spoil-sport, I have a somewhat
> negative take on view patterns. Not because I think the
Jon Fairbairn wrote:
I currently only get f :: [t] -> something, so if I later
discover that I need to change the input representation to
be more efficient than lists, I have to rewrite f. Wouldn't
it be so much nicer if I could simply add a declaration
f:: Stream s => s t -> something
and ge
Dan Licata wrote:
> apfelmus wrote:
>> The idea is to introduce a new language extension, namely the ability to
>> pattern match a polymorphic type. For demonstration, let
>>
>> class ViewInt a where
>> view :: Integer -> a
>>
>> instance ViewInt [Bool] where
>> view n = ... -- binary r
Dan Licata wrote:
> There's actually a quite simple way of doing this. You make the view
> type polymorphic, but not in the way you did:
>
> myzip :: Queue a -> Queue b -> Queue (a,b)
> myzip a b = case (view a, view b) of
> (EmptyL, _) -> empty
> (_, EmptyL) -> empty
>
ChrisK <[EMAIL PROTECTED]> writes:
> Jon Fairbairn wrote:
> > I currently only get f :: [t] -> something, so if I later
> > discover that I need to change the input representation to
> > be more efficient than lists, I have to rewrite f. Wouldn't
> > it be so much nicer if I could simply add a dec
On 2007-07-27, David Roundy <[EMAIL PROTECTED]> wrote:
> The solution is to add explicit to the constructor for all single-argument
> constructors (except perhaps occasionally when you actually want explicit
> construction of objects).
>
> The reasoning behind this, of course, is to allow nice inte
And the readability is destroyed because you cannot do any type inference in
your head.
If you see
{
Matrix m = ;
Matrix x = m * y;
...;
}
Then you know very little about the possible types of y since can only conclude
that:
Matrix can be multiplied by one or more types 'sometype' becuas
ChrisK <[EMAIL PROTECTED]> writes:
> And the readability is destroyed because you cannot do any type inference in
> your head.
>
> If you see
>
> {
> Matrix m = ;
> Matrix x = m * y;
> ...;
> }
>
> Then you know very little about the possible types of y
> since can only conclude that:
[
Discussion continues below quoted text...
Stefan O'Rear wrote:
> On Tue, Jul 31, 2007 at 03:31:54PM -0700, David Roundy wrote:
>> On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
>>> ChrisK <[EMAIL PROTECTED]> writes:
>>>
And the readability is destroyed because you cannot do an
David Roundy <[EMAIL PROTECTED]> writes:
> On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
> > [snippage] This is all very horrid, but as far as I can tell
> > what I was proposing wouldn't lead to such a mess, except
> > possibly via defaulting, which, as the least important
> > as
On Monday 23 July 2007 16:57:08 Simon Marlow wrote:
> Dan Licata wrote:
> > Simon PJ and I are implementing view patterns, a way of pattern matching
> > against abstract datatypes, in GHC. Our design is described here:
> >
> > http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
> >
> > If you ha
apfelmus wrote:
IMHO, the long-time debate about views is not whether they're useful (I
think they are!) but which concrete form to choose. Unfortunately, all
of the proposals so far are somehow like Dr. Jekyll and Mr. Hyde: one
side is nice but the other is rather ugly.
In the end, I might end
Hi
Ok, I'm not quite under my rock yet,,,
On 25 Jul 2007, at 10:28, apfelmus wrote:
Jules Bean wrote:
Have you tried using pattern guards for views?
f s | y :< ys <- viewl s =
| EmptyL <- viewl s =
This is annoying because the intermediate computation gets repeated. I
don't
Hi Conor,
This is a really good point, especially in the presence of GADTs and
type-level functions and so on, which introduce aspects of dependency.
Why are you so fatalistic about "with" in Haskell? Is it harder to
implement than it looks? It seems to be roughly in the same category as
our vie
On Jul25, apfelmus wrote:
> The point is to be
> able to define both zip and pairs with one and the same operator :< .
There's actually a quite simple way of doing this. You make the view
type polymorphic, but not in the way you did:
type Queue elt
empty :: Queue elt
cons :: elt ->
On Wednesday 25 July 2007, Jon Fairbairn wrote:
> Simon Marlow <[EMAIL PROTECTED]> writes:
> > Dan Licata wrote:
> > > Simon PJ and I are implementing view patterns, a way of
> > > pattern matching against abstract datatypes, in GHC.
> >
> > At the risk of being a spoil-sport, I have a somewhat
> >
On Wed, 2007-07-25 at 14:12 +0200, Benjamin Franksen wrote:
> Cheers
> Ben, member of the we-want-real-views-or-nothing-at-all movement ;-)
Derek, member of the counter-culture,
we-don't-want-real-views-but-nothing-at-all-may-suffice movement.
___
Hask
On Wed, Jul 25, 2007 at 09:35:32PM +0200, apfelmus wrote:
> Integer
> => (forall a . ViewInt a => a)
>
> can even be done implicitly and for all types. Together with the magic
> class View, this would give real views.
>
>
> Jón Fairbairn wrote:
> > It's essential to this idea that it doesn'
On Jul25, apfelmus wrote:
> Dan Licata wrote:
> > There's actually a quite simple way of doing this. You make the view
> > type polymorphic, but not in the way you did:
> >
> > myzip :: Queue a -> Queue b -> Queue (a,b)
> > myzip a b = case (view a, view b) of
> > (EmptyL, _) -> empt
I think what you're describing is equivalent to making the "implicit
view function" syntax so terse that you don't write anything at all. So
the pattern 'p' is always (view -> p). This seems like a pretty
invasive change:
I don't think the version with the functional dependency works (unless
yo
On Thu, Jul 26, 2007 at 11:28:03AM -0400, Dan Licata wrote:
> I think what you're describing is equivalent to making the "implicit
> view function" syntax so terse that you don't write anything at all. So
> the pattern 'p' is always (view -> p).
Thanks, I wouldn't have thought of such a simple ex
> In the dependently typed setting, it's often the case that the
> "with-scrutinee" is an expression of interest precisely because it
> occurs
> in the *type* of the function being defined. Correspondingly, an
> Epigram implementation should (and the Agda 2 implementation now does)
> abstract occ
Hi Dan
On 25 Jul 2007, at 15:18, Dan Licata wrote:
Hi Conor,
[..]
Why are you so fatalistic about "with" in Haskell?
I guess I'm just fatalistic, generally. Plausibility is not something
I'm especially talented at.
Is it harder to
implement than it looks?
For Haskell, it ought to b
On Fri, Jul 27, 2007 at 05:22:37AM -0400, Dan Licata wrote:
> On Jul26, Stefan O'Rear wrote:
> > > So, this syntax affects a lot of code, existing or otherwise, that
> > > doesn't use view patterns, which is something we're trying to avoid.
> >
> > Eh? I *think* the typing rules are the same for
On Jul26, Stefan O'Rear wrote:
> > So, this syntax affects a lot of code, existing or otherwise, that
> > doesn't use view patterns, which is something we're trying to avoid.
>
> Eh? I *think* the typing rules are the same for the no-view case. If
> the auto-deriving hack isn't implemented, you
On Jul26, apfelmus wrote:
> Yes, the types of the patterns don't unify. But each one is a
> specialization of the argument type. Note that the type signature is
>
> bar :: (forall a . ViewInt a => a) -> String
>
> which is very different from
>
> bar :: forall a . ViewInt a => a -> String
>
Me:
> > In the dependently typed setting, it's often the case that the
> > "with-scrutinee" is an expression of interest precisely because it
> > occurs
> > in the *type* of the function being defined. Correspondingly, an
> > Epigram implementation should (and the Agda 2 implementation now
does)
On Friday 27 July 2007, Jon Fairbairn wrote:
> ChrisK <[EMAIL PROTECTED]> writes:
> > Jon Fairbairn wrote:
> > > I currently only get f :: [t] -> something, so if I later
> > > discover that I need to change the input representation to
> > > be more efficient than lists, I have to rewrite f. Wouldn
On Fri, Jul 27, 2007 at 09:02:42AM -0500, Jonathan Cast wrote:
> On Friday 27 July 2007, Jon Fairbairn wrote:
> > ChrisK <[EMAIL PROTECTED]> writes:
> > > Because this is starting to sound like one of the
> > > maddening things about C++.
> > >
> > > Namely, the automatic implicit casting conversio
With the functional dependency, you can't work with the view datatypes
at all. Once you write
type Typ
data TypView = Unit | Arrow Typ Typ
instance View Typ TypView where
view = ...
you're no longer allowed to take apart a TypView at all!
E.g. you can't write
outUnit :: TypView -> Bool
outU
On Mon, Jul 30, 2007 at 05:31:40AM -0400, Dan Licata wrote:
> With the functional dependency, you can't work with the view datatypes
> at all. Once you write
>
> type Typ
> data TypView = Unit | Arrow Typ Typ
>
> instance View Typ TypView where
> view = ...
>
> you're no longer allowed to tak
On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
> ChrisK <[EMAIL PROTECTED]> writes:
>
> > And the readability is destroyed because you cannot do any type inference in
> > your head.
> >
> > If you see
> >
> > {
> > Matrix m = ;
> > Matrix x = m * y;
> > ...;
> > }
> >
> >
On Tue, Jul 31, 2007 at 03:31:54PM -0700, David Roundy wrote:
> On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
> > ChrisK <[EMAIL PROTECTED]> writes:
> >
> > > And the readability is destroyed because you cannot do any type inference
> > > in
> > > your head.
> > >
> > > If you s
On Tue, Jul 31, 2007 at 04:04:17PM -0700, Stefan O'Rear wrote:
> On Tue, Jul 31, 2007 at 03:31:54PM -0700, David Roundy wrote:
> > On Mon, Jul 30, 2007 at 11:47:46AM +0100, Jon Fairbairn wrote:
> > > ChrisK <[EMAIL PROTECTED]> writes:
> > >
> > > > And the readability is destroyed because you cann
42 matches
Mail list logo
