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 any type
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
aspect of
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;
...;
}
Then you know very little
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 cannot do any type
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
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:
[snippage] This
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 take apart a
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'
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 declaration
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 only
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
Without
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't
it be so
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 conversions of
classes
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
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 get
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
you
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 representation
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 be
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 powerful as
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
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 other words,
[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 :: Type - Maybe
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 view
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 xs,viewl ys)
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 they're
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
negative take
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.
___
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't involve
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
| 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 thought
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
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 have any
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 this design,
37 matches
Mail list logo
